lp:~danwent/nova/trunk

Branch merges

Propose for merging

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

1476. By Tushar Patil on 2011-08-23

Our goal is to add optional parameter to the Create server OS 1.0 and 1.1 API to achieve following objectives:-

1) Specify number and order of networks to the create server API.

In the current implementation every instance you launch for a project having 3 networks assigned to it will always have 3 vnics. In this case it is not possible to have one instance with 2 vnics ,another with 1 vnic and so on. This is not flexible enough and the network resources are not used effectively.

2) Specify fixed IP address to the vnic at the boot time. When you launch a server, you can specify the fixed IP address you want to be assigned to the vnic from a particular network. If this fixed IP address is already in use, it will give exception.

Example of Server Create API request XML:
<?xml version="1.0" encoding="UTF-8"?>

<server xmlns="http://docs.nttpflab.com/servers/api/v1.0"
        name="new-server-test" imageId="1" flavorId="1">
  <metadata>
    <meta key="My Server Name">Apache1</meta>
  </metadata>
  <personality>
    <file path="/etc/banner.txt">
        ICAgICAgDQoiQSBjbG91ZCBkb2VzIG5vdCBrbm93IHdoeSBp
    </file>
  </personality>
  <networks>
      <network uuid="6622436e-5289-460f-8479-e4dcc63f16c5" fixed_ip="10.0.0.3">
      <network uuid="d97efefc-e071-4174-b6dd-b33af0a37706" fixed_ip="10.0.1.3">
  </networks>
</server>

3) Networks is an optional parameter, so if you don't provide any networks to the server Create API, it will behave exactly the same as of today.

This feature is supported to all of the network models.

1475. By Alex Meade on 2011-08-23

Fixes bug 831627 where nova-manage does not exit when given a non-existent network address

1474. By Soren Hansen on 2011-08-23

Move documentation from nova.virt.fake into nova.virt.driver.

1473. By Alex Meade on 2011-08-22

The FixedIpCommandsTestCase in test_nova_manage previously accessed the database. This branch stubs out the database for these tests, lowering their run time from 104 secs -> .02 secs total.

I have verified the tested functionality is still being tested.

1472. By William Wolf on 2011-08-22

implemented tenant ids to be included in request uris.

1471. By Alex Meade on 2011-08-22

Adds accessIPv4 and accessIPv6 to servers requests and responses as per the current spec.

1470. By Sandy Walsh on 2011-08-22

Fixes utils.to_primitive (again) to handle modules, builtins and whatever other crap might be hiding in an object.

1469. By Tushar Patil on 2011-08-21

Added OS APIs to associate/disassociate security groups to/from instances.

I will add views to return list of security groups associated with the servers later after this branch is merged into trunk. The reason I will do this later is because my previous merge proposal (https://code.launchpad.net/~tpatil/nova/add-options-network-create-os-apis/+merge/68292) is dependent on this work. In this merge proposal I have added a new extension which still uses default OS v1.1 controllers and views, but I am going to override views in this extension to send extra information like security groups.

1468. By Anthony Young on 2011-08-19

Assorted fixes to os-floating-ips to make it play nicely with an in-progress novaclient implementation, as well as some changes to make it more consistent with other os rest apis. Changes include:

* switch associate/disassociate to PUTs. Previously, it was doing create calls with one-off parameter resources.
* allow graceful handling when there are no floating ips for a tenant
* allow graceful handling when disassociating an already disassociated address

1467. By Vish Ishaya on 2011-08-19

Next round of prep for keystone integration.

 * adds middleware for authenticating ec2 signature with keystone
 * adds middleware for converting keystone response into request context
 * gives examples of alternative pipelines for keystone integration

Next steps:
 * provide default config with no keystone integration (perhaps setting every context to admin?)
 * write authmanager to keystone conversion code
 * add api extension to create and destroy access/secret keys
 * deprecate authmanager
 * rename project to tenant