marios log - Deltacloud

Deltacloud Networks API - a work in progress

2013-03-20 00:00:00 +0200

Deltacloud Networks API - a work in progress

The Deltacloud API is missing the management of network resources. Many IaaS APIs still don’t have a notion of ‘network’ resource management whilst for others the Network API is relatively new. However, the Deltacoud project has received requests for the addition of network management related functionality and we’ve been discussing this on and off for the past year or so. Towards the end of 2012 we made a first attempt with some network models to fuel discussion and this blog post introduces the second iteration of the code for further comments.

Each member of the ‘networks team’ took ‘ownership’ of a particular cloud provider to discuss how the initial model would ‘fit’ against that provider’s network API. This etherpad has some of our preliminary notes; Jan Provaznik looked at RHEV-M, Michal Fojtik looked at vSphere, Dies Koper looked at FGCP, Francesco Vollero looked at EC2 and I looked at OpenStack and CIMI. Tomas Sedovic acted as UN weapons inspector and sanity checker.

Angus Thomas developed the use cases to guide development. For this first iteration I focused on the simplest use case: “Place an Instance into a particular Network”. Furthermore, I decided to focus on putting down some fully working code for EC2 and OpenStack to explore the feasibility of the Networks abstractions and guide further development for the other drivers.

The Network Models
Common Operations and Driver Patterns
Patches
Open Issues/Questions

The Network Models

The original model had three entities - Network, Subnet and Port. The ‘Port’ entity proved to be problematic, because for some cloud providers this represented a ‘switch port’ whereas for others it represented a ‘network interface’. In Deltacloud we just want to model the connection of an Instance to a Network. So I decided to remove the Port model altogether and replace it with an ‘instance_bindings’ attribute on the Instance resource. This attempts to abstract away or reconcile the differences between the two ‘types’ of Port resource found in the various cloud provider APIs.

As I attempt to illustrate above, Network and Subnet remain as stand alone resources implying full CRUD operations for these where supported. The Network and Subnet models are pretty similar with respect to their attributes. One not so obvious distinction worth noting is that Network has an ‘address_blocks’ attribute whereas Subnet has an ‘address_block’ attribute. This is because for Openstack Quantum, the Subnets that are associated with a given Network do not have to utilise/occupy contiguous CIDR address blocks - that is it is perfectly legal for one subnet to use “10.0.0.0/8” and the other to use “192.168.0.0/16”. These two address blocks cannot be described using a single CIDR string. Hence, for Network, address_blocks is an array of CIDR address strings to accommodate for this difference.

The Instance model is extended with the network_bindings attribute - an array - because an Instance can be associated with more than one Network (in some providers). Each network_binding contains a reference to the network and subnet as well as the IP address resulting from this association. Moving forward we can either extend this abstraction to contain more attributes or if necessary and feasible, extract it back into a stand-alone entity.

Common Operations and Driver Patterns

Networks

For EC2 the Network resource is mapped to the EC2 VPC, whilst for Openstack it is mapped to the Quantum Network. In EC2, each Netowrk (VPC) has a ‘cidr’ attribute whereas for Openstack a Quantum network does not (cidr is present on the Quantum Subnet resource). For Openstack, each Network ‘knows’ which subnets belong to it, whereas for EC2 this information must be deduced by filtering the Subnets.

Populating the list of Network resources in the case of EC2:

    def networks(credentials, opts={})
      ec2 = new_client(credentials)
      networks = []
      safely do
        subnets = subnets(credentials) #get all subnets once
        ec2.describe_vpcs.each do |vpc|
          vpc_subnets = subnets.inject([]){|res,cur| res<<cur if cur.network==vpc[:vpc_id]  ;res} #collect subnets for this.network
          networks << convert_vpc(vpc, vpc_subnets)
        end
      end
      networks = filter_on(networks, :id, opts)
    end

    def convert_vpc(vpc, subnets=[])
      addr_blocks = subnets.inject([]){|res,cur| res << cur.address_block  ; res}
      Network.new({ :id => vpc[:vpc_id],
                    :name => vpc[:vpc_id],
                    :state=> vpc[:state],
                    :subnets => subnets.inject([]){|res,cur| res << cur.id  ;res},
                    :address_blocks=> (addr_blocks.empty? ? [vpc[:cidr_block]] : addr_blocks)  })
    end

In other words, you retrieve the list of subnets, then for each VPC returned create a Deltacloud::Network resource using the VPC and the subset of the Subnets that are associated with that. One distinction/point of discussion here is that for the ‘addr_blocks’ attribute (cidr), when there are subnets in the given VPC, I only report the CIDR addresses of those subnets in address_blocks. The alternative is to simply use the :cidr_block of the entire VPC, but it made more sense to me to report only the addresses that an Instance can actually use at a given time.

For Openstack however, each Network resource ‘knows’ which subnets belong to it. However, a Network does not ‘know’ about the CIDR address blocks in use on those subnets. Hence:

    def networks(credentials, opts={})
      os = new_client(credentials, "network")
      networks = []
      safely do
        subnets = os.subnets
        os.networks.each do |net|
          addr_blocks = get_address_blocks_for(net.id, subnets)
          networks << convert_network(net, addr_blocks)
        end
      end

    def get_address_blocks_for(network_id, subnets)
      return [] if subnets.empty?
      addr_blocks = []
      subnets.each do |sn|
        if sn.network_id == network_id
          addr_blocks << sn.cidr
        end
      end
      addr_blocks
    end

    def convert_network(net, addr_blocks)
      Network.new({ :id => net.id,
                    :name => net.name,
                    :subnets => net.subnets,
                    :state => (net.admin_state_up ? "UP" : "DOWN"),
                    :address_blocks => addr_blocks
      })
    end

In other words, you must retrieve the list of subnets to determine the CIDR address blocks for those subnets belonging to the given Network, before converting the result into a Deltacloud::Network.

One final implication of the difference between EC2 VPC ‘knowing’ about CIDR and Openstack Network not knowing, is that creation of a Network in EC2 demands a cidr block. This difference will have to be somehow reconciled - either by making ‘cidr’ a compulsory parameter that is ignored for Openstack, or making it optional and choosing a default for EC2 when it isn’t supplied. We could also advertise the difference using a driver ‘feature’.

Subnets

Listing of subnets is thankfully more straightforward without any big differences between the two providers. Each returned subnet resource contains all the attributes required to build the Deltacloud::Subnet. In both cases, a subnet ‘knows’ about the Network it belongs to as well as the CIDR block it occupies/uses. For the create operation in both cases you must supply network_id and address_block parameters:

    def create_subnet(credentials, opts={})
      ec2 = new_client(credentials)
      safely do
        subnet = ec2.create_subnet(opts[:network_id], opts[:address_block])
        convert_subnet(subnet)
      end
    end

    def convert_subnet(subnet)
      Subnet.new({  :id => subnet[:subnet_id],
                    :name => subnet[:subnet_id],
                    :network =>subnet[:vpc_id],
                    :address_block => subnet[:cidr_block],
                    :state => subnet[:state] })
    end

Instances

The Instance operations impacted for this initial use case are creation, listing (retrieval) as well as deletion. When creating an Instance a client must provide the network_id and subnet_id parameters.

For EC2, placing an Instance into a particular Network during Instance creation is very straightforward, because the EC2 compute and network APIs are exposed via the same interface (the EC2 API). You simply pass the ‘subnet_id’ parameter to the EC2 instance creation operation and extract the required ‘network_bindings’ from the response:

    def convert_instance(instance)
    ...
      if instance[:vpc_id]
        inst_params.merge!(:network_bindings => [{:network=>instance[:vpc_id], :subnet=>instance[:subnet_id], :ip_address=> instance[:aws_private_ip_address]}])
      end
      Instance.new(inst_params)
    end

However, in the case of Openstack, the Quantum and Nova APIs do not have such a straightforward interface. To place an Instance into a particular Network, you must first create the Instance, then create a Quantum Port on the required Network and Subnet and then set the Port to refer to the created Instance:

    def create_instance(credentials, image_id, opts)
      (...)
      safely do
        server = os.create_server(params)
        net_bind = []
        if opts[:network_id] && opts[:subnet_id] && (quantum=have_quantum?(credentials)) #place instance into a network
          port = quantum.create_port(opts[:network_id], {"fixed_ips"=>[{"subnet_id"=>opts[:subnet_id]}], "device_id"=>server.id})
          net_bind = [{:network=>opts[:network], :subnet=>opts[:subnet_id], :ip_address=>port.fixed_ips.first["ip_address"]}]
          server.refresh
        end
        result = convert_from_server(server, os.connection.authuser, get_attachments(server.id, os), net_bind)
      end
      result
    end

For the same reasons (interplay between compute and network APIs), creation of the network_bindings attribute when listing Instance(s) is much simpler for EC2 - you simply extract the required information from the EC2 response. For Openstack however you must deduce the network bindings by retrieving a list of Quantum Ports and discovering which of those refers to the given Instance:

    def instances(credentials, opts={})
      (...)
      insts = attachments = ports = []
      safely do
        if quantum = have_quantum?(credentials)
          ports = quantum.ports
        end
        (...)
          insts = os.list_servers_detail.collect do |s|
            net_bind = get_net_bindings_for(s[:id], ports)
            convert_from_server(s, os.connection.authuser,get_attachments(s[:id], os), net_bind)
          end
        end
      end
      insts = filter_on( insts, :state, opts )
      insts
    end

    def get_net_bindings_for(server_id, ports)
      return [] if ports.empty?
      net_bind = []
      ports.each do |port|
        if port.device_id == server_id
          port.fixed_ips.each do |fix_ip|
            net_bind << {:network=> port.network_id, :subnet=>fix_ip["subnet_id"] , :ip_address=>fix_ip["ip_address"]}
          end
        end
      end
      net_bind
    end

A final note is that for the destroy_instance operation in the Openstack driver I added an extra ‘cleanup’ step to destroy any ports associated with the given Instance:

    def destroy_instance(credentials, instance_id)
      os = new_client(credentials)
      server = instance = nil
      safely do
        server = os.get_server(instance_id)
        server.delete!
        if quantum = have_quantum?(credentials) #destroy ports if any
          quantum.ports.each do |port|
            if port.device_id == server.id
              quantum.delete_port(port.id)
            end
          end
        end
      (...)
    end

back top

Patches

The patches implementing this functionality have been sent to the dev@deltacloud.apache.org mailing list. They are also available from tracker as set 395. One note is that in order to use the Openstack Quantum code you need to build from my fork of ruby-openstack; I’ll be releasing a newer version of the gem (1.10) that includes this functionality in the next few days.

Note that the current patches have incomplete ‘views’ - in particular the XML/JSON views are not fully implemented. I mainly used the HTML interface for testing and so the HTML UI should be used to review this set for now.

Open Issues/Questions

How do these revised models and operations fit for your IaaS API (RHEV-M, vSphere, FGCP, CIMI).

For example, for RHEV-M we know that there is no separation of Network and Subnet. Furthermore, creation of Networks is an admin-level task and so the create_network method likely wouldn’t be exposed for the RHEV-M driver. With respect to placing an Instance into a particular Network I understand the procedure is similar to Openstack Quantum: create an instance and then create a network interface on that instance which is associated with a particular Network. I will likely be targetting the RHEV-M driver next to explore these issues further.

How do we reconcile the fact that in some clouds, there is no ‘subnet’ entity (e.g. RHEV-M).

One implication is that for operations such as ‘create_instance’ where we may mandate that a user must supply both a network_id as well as a subnet_id. We could only require the subnet_id (with the network_id being deduced from that). However, this brings us back to the ‘what if there is no subnet’? Do we then map given IaaS provider’s ‘Network’ resource to the Deltacloud ‘Subnet’ (and only expose ‘Subnet’ but not ‘Network’ at the top-level /api entry point?)?

Do we want to merge the Network and Subnet models?

The logic here is that for all the operations regarding an Instance and indeed the network_binding association of Instance <–> Network+Subnet involves both network_id and subnet_id. In a given IaaS provider that supports both Network and Subnet models, you associate your Instances with a Subnet, not a Network. So if you have 2 networks each containing 3 subnets, in effect you have a choice of 6 subnets to which an Instance can be associated - each Network+Subnet combination becomes one target for the association. This idea needs further exploration/discussion, though it may solve the issue with those providers that don’t support a 2 tier Networking model (like RHEV-M, CIMI).

Deltacloud CIMI API - CIMI Volumes, Machines and the MachineVolume collection

2012-11-28 00:00:00 +0200

Deltacloud CIMI API - CIMI Volumes, Machines and the MachineVolume collection

In case you didnt know, Deltacloud implements the DMTF Cloud Infrastructure Management Interface API (CIMI). This means that you can ‘talk’ CIMI to any of the cloud providers supported by Deltacloud, including Amazon EC2, Openstack, RHEV-M and vSphere. The documentation on the Deltacloud website is in dire need of update to include CIMI-specific information; this should be addressed soon but until then here are some notes showing how to work with CIMI Volumes and Machines in Deltacloud.

Starting Deltacloud with the CIMI frontend enabled
Listing Machines
Listing Volumes
Working with the MachineVolume collection

Starting Deltacloud with the CIMI frontend enabled

The ‘-f’ flag is used to tell deltacloud which ‘frontend’ to enable. By default, only the ‘classic’ Deltacloud API is exposed. Right now you can enable ‘cimi’, ‘ec2’ or ‘deltacloud’; in fact you can expose all three with a single instance of the Deltacloud server:

deltacloudd -i mock -f cimi,ec2,deltacloud

The deltacloud API is exposed at /api, the CIMI API is exposed at /cimi and the EC2 API is exposed at /ec2. You can get the these locations by requesting the deltacloud URI in a web browser (by default the server is started at localhost:3001).

So we can request the CIMI CloudEntryPoint:

[marios@name server]$ curl -H "Accept: application/xml"
            http://localhost:3001/cimi/cloudEntryPoint

<CloudEntryPoint xmlns="http://schemas.dmtf.org/cimi/1">
  <id>http://localhost:3001/cimi/cloudEntryPoint</id>
  <name>mock</name>
  <description>Cloud Entry Point for the Deltacloud mock driver</description>
  <created>2012-11-28 12:48:40 +0200</created>
  <baseURI>http://localhost:3001/cimi</baseURI>
  <resourceMetadata href="http://localhost:3001/cimi/resource_metadata" />
  <machines href="http://localhost:3001/cimi/machines" />
  <machineConfigs href="http://localhost:3001/cimi/machine_configurations" />
  <machineImages href="http://localhost:3001/cimi/machine_images" />
  <credentials href="http://localhost:3001/cimi/credentials" />
  <volumes href="http://localhost:3001/cimi/volumes" />
  <volumeConfigs href="http://localhost:3001/cimi/volume_configurations" />
  <volumeImages href="http://localhost:3001/cimi/volume_images" />
  <networks href="http://localhost:3001/cimi/networks" />
  <networkTemplates href="http://localhost:3001/cimi/network_templates" />
  <networkConfigs href="http://localhost:3001/cimi/network_configurations" />
  <networkPorts href="http://localhost:3001/cimi/network_ports" />
  <networkPortTemplates href="http://localhost:3001/cimi/network_port_templates" />
  <networkPortConfigs href="http://localhost:3001/cimi/network_port_configurations" />
  <addresses href="http://localhost:3001/cimi/addresses" />
  <addressTemplates href="http://localhost:3001/cimi/address_templates" />
  <forwardingGroups href="http://localhost:3001/cimi/forwarding_groups" />
  <forwardingGroupTemplates href="http://localhost:3001/cimi/forwarding_group_templates" />
</CloudEntryPoint>

Listing Machines

Following the link obtained from the cloudEntryPoint:

[marios@name server]$ curl --user "mockuser:mockpassword"
    -H "Accept: application/xml"
    http://localhost:3001/cimi/machines

<Collection xmlns="http://schemas.dmtf.org/cimi/1">
  <id>http://localhost:3001/cimi/machines</id>
  <name>default</name>
  <description>Machine Collection for the Mock driver</description>
  <count>2</count>
  <Machine>
    <id>http://localhost:3001/cimi/machines/inst0</id>
    <name>inst0</name>
    <description>Mock Instance With Profile Change</description>
    <property name="machine_image">http://localhost:3001/cimi/machine_images/img1</property>
    <property name="credential">http://localhost:3001/cimi/credentials</property>
    <state>STARTED</state>
    <cpu>1</cpu>
    <memory>12582912</memory>
    <disks href="http://localhost:3001/cimi/machines/inst0/disks">
      <id>http://localhost:3001/cimi/machines/inst0/disks</id>
      <count>1</count>
      <Disk>
        <id>http://localhost:3001/cimi/machines/inst0/disks/inst0_disk_891289600</id>
        <name>inst0_disk_891289600</name>
        <description>DiskCollection for Machine inst0</description>
        <capacity>891289600</capacity>
      </Disk>
    </disks>
    <volumes href="http://localhost:3001/cimi/machines/inst0/volumes" />
    <operation rel="http://schemas.dmtf.org/cimi/1/action/restart"
          href="http://localhost:3001/cimi/machines/inst0/restart" />
    <operation rel="http://schemas.dmtf.org/cimi/1/action/stop"
          href="http://localhost:3001/cimi/machines/inst0/stop" />
  </Machine>

  (...)
</Collection>

Again, following the URI we can obtain the MachineVolume collection for a specific Machine:

[marios@name server]$ curl --user "mockuser:mockpassword"
        -H "Accept: application/xml"
         http://localhost:3001/cimi/machines/inst1/volumes

<Collection xmlns="http://schemas.dmtf.org/cimi/1"
      resourceURI="http://schemas.dmtf.org/cimi/1/MachineVolumeCollection">
  <id>http://localhost:3001/cimi/machines/inst1/volumes</id>
  <count>1</count>
  <MachineVolume>
    <id>http://localhost:3001/cimi/machines/inst1/volumes/vol3</id>
    <name>vol3</name>
    <description>MachineVolume vol3 for Machine inst1</description>
    <created>2009-07-30T14:35:11Z</created>
    <initialLocation>/dev/sda1</initialLocation>
    <volume href="http://localhost:3001/cimi/volumes/vol3" />
    <operation rel="delete"
      href="http://localhost:3001/cimi/machines/inst1/volumes/vol3" />
  </MachineVolume>
  <operation rel="add"
      href="http://localhost:3001/cimi/machines/inst1/volume_attach" />
</Collection>

Notice the ‘addURI’ of the MachineVolume collection (/inst1/volume_attach) which we will use later to attach a new Volume to this instance. Also, notice the ‘deleteURI’ of the MachineVolume, which is used to detach the particular Volume from this Machine.

Listing Volumes

You can retrieve the Volume collection in order to select the volume you would like to attach to a Machine:

curl --user "mockuser:mockpassword" -H "Accept: application/xml"
    http://localhost:3001/cimi/volumes

<Collection xmlns="http://schemas.dmtf.org/cimi/1"
     resourceURI="http://schemas.dmtf.org/cimi/1/VolumeCollection">
  <id>http://localhost:3001/cimi/volumes</id>
  <count>3</count>
  <Volume>
    <id>http://localhost:3001/cimi/volumes/vol2</id>
    <name>vol2</name>
    <description>vol2</description>
    <created>2009-07-30T14:35:11Z</created>
    <state>AVAILABLE</state>
    <type>http://schemas.dmtf.org/cimi/1/mapped</type>
    <capacity>1048576</capacity>
    <bootable>false</bootable>
  </Volume>
(...)
</Collection>

Working with the MachineVolume collection

Once you’ve selected a Volume, you can attach it to a Machine with:

curl -v --user "mockuser:mockpassword" -H "Content-Type: application/xml"
    -H "Accept: application/xml" -X PUT -d
    '<MachineVolume xmlns="http://schemas.dmtf.org/cimi/1/MachineVolume">
      <initialLocation> /dev/sdf </initialLocation>
      <volume href="http://localhost:3001/cimi/volumes/vol2"/>
    </MachineVolume>'  http://localhost:3001/cimi/machines/inst1/volume_attach

The URI for the attach operation is obtained from the MachineVolume collection - the “addURI”. In JSON format the same request looks like:

curl -v --user "mockuser:mockpassword" -H "Content-Type: application/json"
    -H "Accept: application/xml" -X PUT -d
    '{"resourceURI":"http://schemas.dmtf.org/cimi/1/MachineVolume",
    "initialLocation": "/dev/sdf",
    "volume": {"href":"http://localhost:3001/cimi/volumes/vol2"}}'
    http://localhost:3001/cimi/machines/inst1/volume_attach

The response in the newly created MachineVolume entity:

< HTTP/1.1 201 Created
< Content-Type: application/xml
< CIMI-Specification-Version: 1.0.1
< Content-Length: 522
< ETag: 8379f00a2f8d73091758a62591874082
< Cache-Control: max-age=0, private, must-revalidate
< Date: Wed, 28 Nov 2012 11:12:49 GMT
< Connection: keep-alive
<
<MachineVolume xmlns="http://schemas.dmtf.org/cimi/1"
    resourceURI="http://schemas.dmtf.org/cimi/1/MachineVolume">
  <id>http://localhost:3001/cimi/machines/inst1/volumes/vol2</id>
  <name>vol2</name>
  <description>MachineVolume vol2 for Machine inst1</description>
  <created>2009-07-30T14:35:11Z</created>
  <initialLocation>/dev/sdf</initialLocation>
  <volume href="http://localhost:3001/cimi/volumes/vol2" />
  <operation rel="delete"
    href="http://localhost:3001/cimi/machines/inst1/volumes/vol2" />
</MachineVolume>

To detach a Volume from a Machine we use the ‘delete’ URI given in the serialization of the MachineVolume:

curl -v --user "mockuser:mockpassword" -H "Accept: application/xml"
    -X DELETE http://localhost:3001/cimi/machines/inst1/volumes/vol2

< HTTP/1.1 200 OK
< Content-Type: application/xml
< CIMI-Specification-Version: 1.0.1
< Content-Length: 747
< ETag: 8e2d333a3747634c04942b7d219a8d59
< Cache-Control: max-age=0, private, must-revalidate
< Date: Wed, 28 Nov 2012 11:15:53 GMT
< Connection: keep-alive
<
<Collection xmlns="http://schemas.dmtf.org/cimi/1"
    resourceURI="http://schemas.dmtf.org/cimi/1/MachineVolumeCollection">
  <id>http://localhost:3001/cimi/machines/inst1/volumes</id>
  <count>1</count>
  <MachineVolume>
    <id>http://localhost:3001/cimi/machines/inst1/volumes/vol3</id>
    <name>vol3</name>
    <description>MachineVolume vol3 for Machine inst1</description>
    <created>2009-07-30T14:35:11Z</created>
    <initialLocation>/dev/sda1</initialLocation>
    <volume href="http://localhost:3001/cimi/volumes/vol3" />
    <operation rel="delete" href="http://localhost:3001/cimi/machines/inst1/volumes/vol3" />
  </MachineVolume>
  <operation rel="add" href="http://localhost:3001/cimi/machines/inst1/volume_attach" />
</Collection>

The response shows the updated MachineVolume collection, which in this case still contains one MachineVolume.

Volumes Support in the Deltacloud Openstack Driver

2012-11-19 00:00:00 +0200

Volumes Support in the Deltacloud Openstack Driver

Adding a new feature to a deltacloud driver means first checking that this feature is supported in the cloud provider client being used by that driver. For the Deltacloud Openstack driver, the client is the openstack rubygem. The following are some notes about how/why I implemented the Volumes support on both the rubygem side and the deltacloud side.

Many thanks to HPCloud for granting me access to the private beta of their Block Storage service which I used to implement this functionality - fwiw I didn’t come across any issues with any of the API calls as documented.

Note: I haven’t yet implemented the storage snapshot support - this will follow soon.

Volumes support in the Openstack rubygem:

The main issue that I had to resolve here was quite simply… which API. Basically there is the bona fide, stand-alone Volume service (aka Cinder?) which is exposed @ v1/{tenant_id}/volumes. This volume service is returned in the serviceCatalog after authentication against the Keystone service, together with all the other deployed services (compute/nova, object-store/swift etc). Right now (mid November 2012) the full specification for the Volume API 1.0 is not yet available; at the Openstack API specs page the text reads: “Check back for the specification for the Volume API 1.0, all calls are shown on api.openstack.org.”.

There is however another Volume service which exists as an extension to the compute/nova service. This extension volume service is exposed @ v1/{tenant_id}/os-volumes. Mercifully, the actual API calls are the same for both exposed endpoints, although the ‘bona-fide’ Volume service does not expose operations for attach/detach volume from server.

To get around this I put some code in the definition of Openstack::Volume::Connection to determine which of the two is deployed and so set the endpoint accordingly.

Another detail point is that since the attach/detach operations aren’t yet exposed for the ‘full’ Volume service but only for the extension, I added the attach/detach functions in the definition of Openstack::Compute. Partly because this is where the other extensions live but mainly since the attach/detach operations are called against a given server, that is, against the compute service and not the volume service, e.g.

POST v2/{tenant_id}/servers/{server_id}/os-volume_attachments
{
  'volumeAttachment': {
    'volumeId': volume_id,
    'device': device
  }
}

The result of this is that in order to fully work with storage volumes and servers you need both a handle to the compute service and a handle to the volume service:

#get volume service, create a volume:
vs = OpenStack::Connection.create({:username => "username", :api_key=>"pass",
  :auth_url => "https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/",
  :authtenant=>"username-default-tenant", :service_type=>"volume"})

volume = vs.create_volume({:display_name=>"marios volume", :size=>1,
                      :display_description=>"some new volume bla"})

#get the compute service and attach volume to a running server:
os = OpenStack::Connection.create(:username => USERNAME, :api_key => API_KEY,
      :authtenant => TENANT, :auth_url => API_URL, :service_type => "compute")
os.attach_volume(704289, 90805, "/dev/sde") #svr_id, vol_id, device

The latest version of the Openstack rubygem, 1.0.7 (at time of writing) contains the new Volume functionality.

Volumes support in the Deltacloud Openstack driver:

Storage Volumes support for Openstack on the Deltacloud side is pretty ‘standard’ - the StorageVolumes collection already exists and is implemented for those cloud provider drivers that support it - rhevm, fgcp, aruba, ec2.

After defining the standard operations, the only new addition I made was defining two new features - :volume_name and :volume_description. These signal to clients that the given driver will accept a ‘name’ and a ‘description’ parameter for the ‘create storage volume’ API call:

===> REQUEST:
curl --user "uname+tenant_name:password" -H "Accept: application/xml"
        http://localhost:3001/api

===> RESPONSE:
<api driver='openstack' provider='https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/'
        version='1.0.5'>

...

<link href='http://localhost:3001/api/storage_volumes' rel='storage_volumes'>
  <feature name='volume_name' rel='create'>
    <param name='name' />
  </feature>
  <feature name='volume_description' rel='create'>
    <param name='description' />
  </feature>
</link>

...

</api>

Segmenting Huge Blobs - Part II

2012-10-24 00:00:00 +0300

Segmenting Huge Blobs - Part II

I implemented the ‘multipart’/’segmented blob’ upload as described in my previous post. This ‘segmented blob’ API is not yet an official part of the Deltacloud API as it still needs to be discussed/improved/prodded etc. Right now I’ve implemented this functionality for the Openstack and EC2 drivers (i.e. swift and S3 respectively) as a proof of concept - so azure and google storage are still pending.

For the EC2 driver, some changes were required in the aws rubygem and I’m waiting for those to be pulled in - otherwise this functionality (for S3 at least) is not yet available. You could build the gem with this code included from my fork.

The notes here show the “segmented blob” upload in action using cURL examples:

initiate,
upload segment,
complete.

1. Initiate:

Need to set the ‘X-Deltacloud-BlobType’ header to ‘segmented’:

Request:

[marios@name ~]$ curl -v --user "KEY:PASS" -X PUT -H "X-Deltacloud-BlobType: segmented"
http://localhost:3001/api/buckets/mariosbucket/segmentedblob

> PUT /api/buckets/mariosbucket/segmentedblob HTTP/1.1
> Authorization: Basic DdCeFNttJQJNkdfUVDhXdQUlXRM2KZVEE62N2lLc05MeitIMi9Lg==
> X-Deltacloud-BlobType: segmented
> User-Agent: curl/7.24.0
> Host: localhost:3001
> Accept: */*

Response:

Note the ‘segmented blob ID’ returned in the X-Deltacloud-SegmentedBlob header. This will be needed to upload any segments and to complete the segmented blob upload.

< HTTP/1.1 204 No Content
< X-Frame-Options: sameorigin
< X-XSS-Protection: 1; mode=block
< X-Deltacloud-SegmentedBlob: WL7dk8sqbtk3Rg6410mLF81T6fpof2Ha_0Upt
< Server: Apache-Deltacloud/1.0.4
< X-Deltacloud-Driver: ec2
< Date: Tue, 23 Oct 2012 13:16:26 GMT
< Connection: close
<
* Closing connection #0

2. Upload Segment:

As before clients must specify that this is a segmented blob operation with the X-DeltacloudBlobType header set to ‘segmented’. You need to specify the segmented blob ID obtained from step 1 with the X-Deltacloud-SegmentedBlob header, and also specify the order that this given segment should appear when the blob is reassembled using the X-Deltacloud-SegmentOrder header.

One final note here: each cloud provider may specify a minimum for the size of a blob ‘segment’. For example, in AWS S3 this is 5 MB whereas Openstack doesn’t specify a minimum. The back-end provider specified minimums notwithstanding, for Deltacloud a blob segment must be at least 112 Kbytes or you’ll get a “500 Internal Server Error”. The reason for this is because anything with a body less than 112 KBytes is stored by the Thin server in memory rather than being moved to a tempfile. Which means that it wouldn’t hit our Thin monkeypatch for streaming blobs - which is where the process of sending the blob data out to the providers begins.

Request:

[marios@name ~]$ curl -v --user "KEY:PASS" -H "X-Deltacloud-BlobType: segmented"
 -H "X-Deltacloud-SegmentedBlob: WL7dk8sqbtk3Rg6410mLF81T6fpof2Ha_0Upt"
 -H "X-Deltacloud-SegmentOrder: 2" --upload-file "/home/herp/derp/files/blob2.txt"
 http://localhost:3001/api/buckets/mariosbucket/segmentedblob

> PUT /api/buckets/mariosbucket/segmentedblob HTTP/1.1
> Authorization: Basic DdCeFNttJQJNkdfUVDhXdQUlXRM2KZVEE62N2lLc05MeitIMi9Lg
> X-Deltacloud-BlobType: segmented
> X-Deltacloud-SegmentedBlob: WL7dk8sqbtk3Rg6410mLF81T6fpof2Ha_0Upt
> X-Deltacloud-SegmentOrder: 2
> User-Agent: curl/7.24.0
> Host: localhost:3001
> Accept: */*
> Content-Length: 7454095
> Expect: 100-continue
>

Response:

The response contains the blob segment ID in the ‘X-Deltacloud-BlobSegmentId’ header. This will be needed in order to complete the segmented blob upload in step 3.

< HTTP/1.1 204 No Content
< X-Frame-Options: sameorigin
< X-XSS-Protection: 1; mode=block
< X-Deltacloud-BlobSegmentId: e7b94a1e959ca066026da3ec63aad321
< Server: Apache-Deltacloud/1.0.4
< X-Deltacloud-Driver: ec2
< Date: Tue, 23 Oct 2012 13:52:57 GMT
< Connection: close
<
* Closing connection #0

This step needs to be repeated for as many segments as you have divided your blob into, each time specifying a different value for the ‘X-Deltacloud-SegmentOrder’ header.

3. Complete Upload:

Finally you need to provide the segmented blob ‘manifest’ in the message body. This specifies the order and ID of each blob segment you have uploaded - e.g. when you uploaded blob segment with “X-Deltacloud-SegmentOrder: 1” and got “X-Deltacloud-BlobSegmentId: FOO” in the response, you would specify this as “1=FOO, 2=BAR… “ etc for each segment. As before, the “X-Deltacloud-BlobType” and “X-Deltacloud-SegmentedBlob” headers must be provided.

Request:

curl -v --user "KEY:PASS" -X PUT -H "X-Deltacloud-BlobType: segmented"
-H "X-Deltacloud-SegmentedBlob: WL7dk8sqbtk3Rg6410mLF81T6fpof2Ha_0Upt"
-d "1=78f871f6f01673a4aca05b1f8e26df08, 2=e7b94a1e959ca066026da3ec63aad321"
http://localhost:3001/api/buckets/mariosbucket/segmentedblob?format=xml

> PUT /api/buckets/mariosbucket/segmentedblob?format=xml HTTP/1.1
> Authorization: Basic DdCeFNttJQJNkdfUVDhXdQUlXRM2KZVEE62N2lLc05MeitIMi9Lg
> X-Deltacloud-BlobType: segmented
> X-Deltacloud-SegmentedBlob: WL7dk8sqbtk3Rg6410mLF81T6fpof2Ha_0Upt
> User-Agent: curl/7.24.0
> Host: localhost:3001
> Accept: */*
> Content-Length: 70
> Content-Type: application/x-www-form-urlencoded

Response:

< HTTP/1.1 200 OK
< Content-Type: application/xml
< Server: Apache-Deltacloud/1.0.4
< X-Deltacloud-Driver: ec2
< Content-Length: 430
< ETag: 59f1ee57a61a3ce2c2d5d8923ed77ee9
< Cache-Control: max-age=0, private, must-revalidate
< Date: Thu, 25 Oct 2012 10:13:45 GMT
< Connection: keep-alive
<
<?xml version='1.0' encoding='utf-8' ?>
<blob href='http://localhost:3001/api/buckets/mariosbucket/segmentedblob' id='segmentedblob'>
  <bucket>mariosbucket</bucket>
  <content_length></content_length>
  <content_type></content_type>
  <last_modified></last_modified>
  <user_metadata>
  </user_metadata>
  <content href='http://localhost:3001/api/buckets/mariosbucket/segmentedblob/content' rel='blob_content'></content>
</blob>

Segmenting Huge Blobs

2012-10-08 00:00:00 +0300

Segmenting Huge Blobs

Apart from the compute infrastructure abstractions, Deltacloud has support for blob storage via the 'buckets' collection. Right now you can create a 'blob' via a HTTP PUT on the 'bucket' in which you want the blob to be created:

PUT /api/buckets/mybucket/12Jul2011blob?format=xml HTTP/1.1
Authorization: Basic AU1J3UB2121Afd1DdyQWxLaTYTmJMNF4zTXBoRGdhMDh2RUw5ZDAN9zVXVa==
Content-Type: text/plain
Content-Length: 128988
X-Deltacloud-Blobmeta-Version:2.1
X-Deltacloud-Blobmeta-Author:msa

... BLOB DATA ...

All the blob-storage cloud providers that deltacloud supports offer a way to do 'multipart' blob uploads - i.e. upload a number of segments or parts individually that will eventually make up a single blob on the provider. We recently had a request for adding this functionality for the Openstack driver. But since Deltacloud is all about cloud abstraction we need to find a 'common' way to implement this across all supported providers. This post is primarily an attempt to organise my notes and help to explore the different approaches that might be taken. I’m leaning towards the term ‘segments’ to describe the individual ‘bits’ or ‘parts’ of the huge blob - hence s/segments/parts/ in the text below:

The native way

The ways in which the various supported providers handle segmented blob uploads:

Openstack Swift
Amazon S3
Microsoft Azure
Google Cloud Storage

Openstack Swift

Possibly the simplest approach - relevant api docs:

Upload ‘segments’. The rules are that their name must have a common ‘prefix’ and this prefix will determine the order in which the segments will be reassembled.
```
 PUT /v1.1/12345/my_container/large1

 PUT /v1.1/12345/my_container/large2 ...
```
Finalise - Once you’ve uploaded all the segments, upload a ‘manifest’ which informs the Openstack swift server that you’d like to create a single blob out of all the segments that are named with a particular prefix in a particular container (bucket). The manifest is specified with the ‘X-Object-Manifest’ HTTP header in the request:
```
 PUT /v1.1/12345/my_container/large_object
 X-Object-Manifest: my_container/large
```

Amazon S3

AWS uses a 3-step process - relevant API docs initiate, send segments, complete:

Initiate the multipart upload - by using the ‘?uploads’ parameter in the POST URL. This will return a unique UploadId which needs to be supplied when sending any of the segments that will make up the large blob:

 POST /myobject?uploads

 <InitiateMultipartUploadResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
   <Bucket>example-bucket</Bucket>
   <Key>example-object</Key>
   <UploadId>VXBsb2FkIElEIGZvciA2aWWpbmcncyBteS1tb3ZpZS5tMnRzIHVwbG9hZA</UploadId>
 </InitiateMultipartUploadResult>

Upload segments - specifying both the partNumber and the uploadId obtained from step 1 above. The response will include an ‘etag’ for the part, which clients must retain for use in completing the upload in step 3:
```
 PUT /ObjectName?partNumber=PartNumber&uploadId=UploadId HTTP/1.1

 HTTP/1.1 200 OK
 ETag: "b54357faf0632cce46e942fa68356b38"
```
Finalize the upload - by performing a POST on the object itself and providing the uploadId in the POST URL. Here, the POST body must include a structure detailing the e-tag and part number for each of the uploaded segments:
```
 POST /ObjectName?uploadId=foo
 <CompleteMultipartUpload>
   <Part>
     <PartNumber>PartNumber</PartNumber>
     <ETag>ETag</ETag>
   </Part>
 ...
 </CompleteMultipartUpload>
```

Microsoft Azure

Azure has 2 types of blob - page and block. Deltacloud support for Azure blob storage applies to page blobs as do the notes here. The approach here is somewhere between that taken by Openstack and that taken by AWS S3 - it is a 2-step process. Relevant API docs - upload segments and upload segment list which is a manifest detailing all the parts and how they go together:

Upload segments - using the ?comp=block URL parameter and specifying the blockId which is a unique Base64 string value. If the named blob doesn’t yet exist it is created after you upload the first segment.
```
 PUT http://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=some_id
```
Upload manifest - using the ?comp=blocklist URL parameter and specifying the segments in the request body. The ordering will determine the way the blob is created from the segments. Furthermore, you can also specify whether the given blockId is from the committed (blocks already committed as part of a previous put block list operation and which now form part of an existing blob) or the uncommitted block list (uploaded segments that haven’t yet been committed) - as explained here.
```
 PUT http://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1
 Request Body:
 <?xml version="1.0" encoding="utf-8"?>
 <BlockList>
   <Uncommitted>ANAAAA==</Uncommitted>
   <Committed>AQAAAA==</Committed>
   <Uncommitted>AZAAAA==</Uncommitted>
 </BlockList>
```

Google Cloud Storage

Google uses a 2-step process, involving initiating the upload to obtain the uploadId and then sending segments using that ID - relevant API docs

Initiate - specifying the ‘x-goog-resumable’ HTTP header and getting the upload_id from the returned Location header:

 POST /myFile.zip HTTP/1.1
 x-goog-resumable: start

 HTTP 201 Created
 Location: https://example.storage.googleapis.com/music.mp3?upload_id=tvA0ExBntDa...gAAEnB2Uowrot

Upload segments - supplying the upload_id obtained from step 1 above as a URL parameter. The caveat here though is the size of each segment must be a multiple of 256 kilobytes (except the last). Each uploaded segment must include a ‘Content-Range’ header specifying the relational position of the segment in the blob:
```
 PUT /myFile.zip?upload_id=tvA0ExBntDa...gAAEnB2Uowrot HTTP/1.1
 Content-Length: 524288
 Content-Range: bytes 0-524287/*
```

The Deltacloud way?

Approach 1 - lowest common denominator (aka ‘brute force’)

Here we’d use a 3-step approach - initiate, upload segments, upload manifest/finalize. The hope is that all the approaches above ‘fit’ into this model:

Initiate - using a URL parameter or HTTP header to signify that this is the start of a ‘segmented’ blob:

 PUT /api/buckets/my_bucket/blob_id?segmented
 X-Deltacloud-BlobType=segmented

 HTTP 200 OK
 X-Deltacloud-SegmentedBlob=ID

Upload Segments - specifying the segment order via an integer/string and supplying the ID returned from step 1 above. Again, these can be supplied through the URI or via HTTP headers. This operation would respond with a segment ID in the response:
```
 PUT /api/buckets/my_bucket/blob_id?segmented&segmented_blob=id&segment_order=1
 X-Deltacloud-BlobType=segmented
 X-Deltacloud-SegmentedBlob=id
 X-Deltacloud-SegmentOrder=1

 HTTP 202 Accepted
 X-Deltacloud-SegmentId=foo123
```

Finalize - complete the upload by specifying the segment order and their ids:

 PUT /api/buckets/my_bucket/blob_id?segmented&segmented_blob=id
 X-Deltacloud-BlobType=segmented
 X-Deltacloud-SegmentedBlob=id

 1=foo123, 2=bar345, 3=baz678 etc

The biggest disadvantage of this approach is that it would make the process more complex for certain providers - like Openstack for example. Of course the advantage is that you could use the same generic process for working with multiple blob storage providers. Perhaps approach 2 can help:

Approach 2 - hybrid

We could use the approach above (or some variant - I’m not convinced/happy with the names of the various parameters yet - segmented_blob, segment_order, segmentId etc) and in addition also allow for ‘shortcuts’. So for example, let’s say you need to work with Openstack and you’re already familiar with the Swift process for uploading segmented blobs. Right now, the only thing missing from the Deltacloud API is the ability to pass in the ‘manifest’ header. We could just allow this header to pass through (or perhaps rename and document it as a ‘Deltacloud-Blob-Manifest’ for example). Thus, if you need to use Deltacloud predominantly with Openstack, you’d use this method. And when you need to work across providers you’d fall back to the generic 3-step process.

The cost of this of course is adding complexity - exceptions for particular cloud providers. I’m still undecided on the way forward. Comments and suggestions are very very welcome.

An updated ruby-openstack rubygem

2012-08-03 00:00:00 +0300

An updated ruby-openstack rubygem

This post is so long overdue that I’ve forgotten much of the details involved. In short, there’s a new rubygem in town for talking to Openstack. Well - ‘new’ is definitely an exaggeration; the ruby-openstack gem is the merger between the ruby-openstack-compute and ruby-cloudfiles gems.

Now why would you want to do that?!

The deltacloud openstack driver was recently (o_O) updated to work with v2 of the OS (Nova) API. At that time I used the the ruby-openstack-compute gem to handle the calls out to the Openstack Nova service. I got talking to Dan Prince who was the main contributer and maintainer of ruby-openstack-compute and we agreed it would be nice to have a single ruby gem to handle all Openstack services. Right now ruby-openstack does v2 authentication (Keystone) and handles Nova (Openstack Compute) as well as Swift (Openstack Object storage). The idea is that the codebase will be expanded to add all Openstack services.

How do I use it?

The README is pretty self-explanatory. Basically:

  sudo gem install openstack
  [sudo] password for herp:
  Successfully installed openstack-1.0.1

  [herp@name lib]$ irb -rubygems
  irb(main):001:0> require 'openstack'
  => true

  irb(main):002:0> os = OpenStack::Connection.create({:username => "herp@derp.net", :api_key=>"1234abcd", :auth_method=>"password", :auth_url => "https://regionerer-g.go-bar.identity.dacloudfoo.herpy:13327/v2.0/", :authtenant_name =>"herp@derp.net-default-tenant", :service_type=>"compute"})

  => #<OpenStack::Compute::Connection:0xb7339070 @connection=#<OpenStack::Connection:0xb73392dc @service_scheme="https", @auth_host="regionerer-g.go-bar.identity.dacloudfoo.herpy", @http={}, @service_name=nil, @authuser="herp@derp.net", @proxy_port=nil, @auth_path="/v2.0/", @authtenant={:type=>"tenantName", :value=>"herp@derp.net-default-tenant"}, @service_port=443, @authkey="1235abcd", @authok=true, @service_type="compute", @auth_method="password", @auth_scheme="https", @service_host="az-2.region-a.geo-1.dacloudfoo.herpy", @is_debug=nil, @proxy_host=nil, @service_path="/v1.1/482195756462871", @auth_port=35357, @auth_url="https://regionerer-g.go-bar.identity.dacloudfoo.herpy:13327/v2.0/", @region=nil, @authtoken="Auth_543254fdsasabd546543a3", @retry_auth=nil>>

i.e., you use OpenStack::Connection.create to get a handle to an OpenStack service - setting the :service_type parameter to either “compute” or “object-store”.

The latest update to the gem adds support for api_extensions. Right now the keypairs extension is implemented (list/create/delete and include in server instance params) with more to follow. The ‘team’ consists of many of the deltacloud core developers and we can certainly do with more help/bug-reports/docs/beer. So if you are using ruby and need to talk to Openstack - check it out and feel free to jump in!

CIMI Networking in Deltacloud - A Work in Progress

2012-04-06 00:00:00 +0300

CIMI Networking in Deltacloud - A Work in Progress

I’m currently implementing the CIMI Network entities for Deltacloud - this post introduces these and shows some examples of how a client can use Deltacloud to interact with a CIMI server, using the CIMI REST API.

The DMTF Cloud Infrastructure Management Interface (CIMI) is still a work-in-progress. As far as I am aware, Deltacloud is currently the only project offering an implementation of the CIMI REST API. Since CIMI itself is still a work-in-progress, it naturally follows that its implementation in Deltacloud is also a work-in-progress. Thats all just a round about way of saying the following is very likely to change before CIMI v1.0 ships later this year (likely late Q2 or early Q3 2012) - though hopefully not too much.

Implemented network entities and the Deltacloud mock driver
Operation examples with cURL:

Implemented network entities and the Deltacloud mock driver

The currently implemented entities are:

Network,NetworkTemplate, NetworkConfiguration (+collections)
VSP, VSPTemplate, VSPConfiguration (+collections)
RoutingGroup, RoutingGroupTemplate (+collections)
Address, AddressTemplate (+collections)

The simple ‘GET’ and operation is implemented for all of these - however creation/deletion is currently only supported by Network, VSP and Address.

Since there aren’t any cloud providers out there that offer a CIMI API - the Deltacloud server is actually using the ‘mock’ driver to simulate a CIMI cloud provider. The mock driver pretends to be a cloud in a way that is transparent to consumers (‘client’ in CIMI); that is a consumer interacts with the mock driver in the same way as they would interact with a ‘real’ CIMI cloud provider. This allows us to implement and test the CIMI API until the ‘real’ implementations arrive.

For the mock driver, each ‘entity’ is actually a ‘json’ file on disk. json was an arbitrary choice - we could have used xml, or even yaml as is used for the Deltacloud API entities. To start the deltacloud server, exposing the CIMI API and talking to the ‘mock’ cloud provider:

deltacloudd --cimi -i mock

This will start the deltacloud server on localhost port 3001. There is more information about getting Deltacloud and running it on the project website. Please [get in touch] (http://deltacloud.apache.org/contact.html) if you need any help getting started.

index

Operation examples with cURL

Getting the Cloud Entry Point

[marios@name ~]$ curl --user "mockuser:mockpassword"
                 http://localhost:3001/cimi/cloudEntryPoint?format=xml

<CloudEntryPoint xmlns="http://www.dmtf.org/cimi">
  <volumeImages href="http://localhost:3001/cimi/volume_images" />
  <entityMetadata></entityMetadata>
  <addressTemplates href="http://localhost:3001/cimi/address_templates" />
  <vspConfigurations href="http://localhost:3001/cimi/vsp_configurations" />
  <routingGroupTemplates href="http://localhost:3001/cimi/routing_group_templates" />
  <id>http://localhost:3001/cimi/cloudEntryPoint</id>
  <networkTemplates href="http://localhost:3001/cimi/network_templates" />
  <machines href="http://localhost:3001/cimi/machines" />
  <addresses href="http://localhost:3001/cimi/addresses" />
  <networks href="http://localhost:3001/cimi/networks" />
  <volumeConfigurations href="http://localhost:3001/cimi/volume_configurations" />
  <machineAdmins href="http://localhost:3001/cimi/machine_admins" />
  <volumes href="http://localhost:3001/cimi/volumes" />
  <created>Fri Apr 06 16:59:18 +0300 2012</created>
  <vsps href="http://localhost:3001/cimi/vsps" />
  <routingGroups href="http://localhost:3001/cimi/routing_groups" />
  <networkConfigurations href="http://localhost:3001/cimi/network_configurations" />
  <machineConfigurations href="http://localhost:3001/cimi/machine_configurations" />
  <machineImages href="http://localhost:3001/cimi/machine_images" />
  <name>mock</name>
  <vspTemplates href="http://localhost:3001/cimi/vsp_templates" />
  <description>Cloud Entry Point for the Deltacloud mock driver</description>
</CloudEntryPoint>

index

Getting the NetworkCollection

[marios@name ~]$ curl --user "mockuser:mockpassword"
                 http://localhost:3001/cimi/networks?format=xml

<NetworkCollection xmlns="http://www.dmtf.org/cimi">
  <id>http://localhost:3001/cimi/networks</id>
  <created>Fri Apr 06 17:08:40 +0300 2012</created>
  <network href="http://localhost:3001/cimi/networks/network1" />
  <network href="http://localhost:3001/cimi/networks/network2" />
  <name>default</name>
  <description>Mock NetworkCollection</description>
</NetworkCollection>

index

Getting a specific VSP

[marios@name ~]$ curl --user "mockuser:mockpassword"
            http://localhost:3001/cimi/vsps/vsp1?format=xml

<VSP xmlns="http://www.dmtf.org/cimi">
  <state>STARTED</state>
  <maxTrafficLoss>100</maxTrafficLoss>
  <id>http://localhost:3001/cimi/vsps/vsp1</id>
  <maxTrafficJitter>100000</maxTrafficJitter>
  <operation href="http://localhost:3001/cimi/vsps/vsp1" rel="edit" />
  <operation href="http://localhost:3001/cimi/vsps/vsp1" rel="delete" />
  <maxTrafficDelay>500000</maxTrafficDelay>
  <created>Fri Mar 16 17:06:41 EET 2012</created>
  <trafficPriority>1</trafficPriority>
  <network href="http://localhost:3001/cimi/networks/network1" />
  <name>vsp1</name>
  <bandwidthReservation>0.5</bandwidthReservation>
  <description>a mock switchport</description>
</VSP>

index

Create/Delete Networks

Deleting a Network is the easiest case so we deal with that first. To delete a Network called “my_test_network”:

curl -X DELETE --user "mockuser:mockpassword" http://localhost:3001/cimi/networks/my_test_network?format=xml

There are 3 ways to create a network, with respect to the NetworkTemplate used. A consumer can i) specify a NetworkTemplate by reference, ii) specify NetworkTemplate by value, but with a NetworkConfig by reference, iii) specify a NetworkTemplate by value, with a NetworkConfig by value:

Create a Network, specifying a NetworkTemplate by reference:

XML:

curl -X POST --user "mockuser:mockpassword" -H "Content-Type: application/CIMI-NetworkCreate+xml"
-d '<NetworkCreate>
      <name> my_test_network </name>
      <description> A test network </description>
      <networkTemplate href="http://localhost:3001/cimi/network_templates/template1">
      </networkTemplate>
    </NetworkCreate>' http://localhost:3001/cimi/networks

JSON:

curl -X POST --user "mockuser:mockpassword" -H "Content-Type: application/CIMI-NetworkCreate+json"
-d '{ "name": "my_test_network", "description": "a foo network",
      "networkTemplate": {
        "href": "http://localhost:3001/cimi/network_templates/template1"}}'
http://localhost:3001/cimi/networks

Create a Network with NetworkTemplate by value and NetworkConfiguration by reference:

XML:

curl -X POST --user "mockuser:mockpassword" -H "Content-Type: application/CIMI-NetworkCreate+xml"
-d '<NetworkCreate>
      <name> my_test_network </name>
      <description> A test network </description>
      <networkTemplate>
        <networkConfig href="http://localhost:3001/cimi/network_configurations/network_config1">
        </networkConfig>
        <routingGroup href="http://localhost:3001/cimi/routing_groups/group1">
        </routingGroup>
      </networkTemplate>
    </NetworkCreate>' http://localhost:3001/cimi/networks

JSON:

curl -X POST --user "mockuser:mockpassword" -H "Content-Type: application/CIMI-NetworkCreate+json"
-d '{ "name": "my_test_network", "description": "a foo network",
      "networkTemplate": {
        "networkConfig":{
          "href": "http://localhost:3001/cimi/network_configurations/network_config1"},
        "routingGroup": {
          "href": "http://localhost:3001/cimi/routing_groups/group1"}}}'
http://localhost:3001/cimi/networks?format=json

Create a Network with NetworkTemplate by value and NetworkConfiguration by value:

XML:

curl -X POST --user "mockuser:mockpassword" -H "Content-Type: application/CIMI-NetworkCreate+xml"
-d '<NetworkCreate>
      <name> my_test_network </name>
      <description> A test network </description>
      <networkTemplate>
        <networkConfig>
          <access> public </access>
          <bandwidthLimit> 2 </bandwidthLimit>
          <trafficPriority> 1 </trafficPriority>
          <maxTrafficDelay> 500000 </maxTrafficDelay>
          <maxTrafficLoss> 100 </maxTrafficLoss>
          <maxTrafficJitter> 100000 </maxTrafficJitter>
        </networkConfig>
        <routingGroup href="http://localhost:3001/cimi/routing_groups/group1">
        </routingGroup>
      </networkTemplate> </NetworkCreate>'
http://localhost:3001/cimi/networks?format=xml

JSON:

curl -X POST --user "mockuser:mockpassword" -H "Content-Type: application/CIMI-NetworkCreate+json"
-d '{ "name": "my_test_network", "description": "a foo network",
    "networkTemplate": {
      "networkConfig": {
        "access": "public", "bandwidthLimit": 2, "trafficPriority": 1,
        "maxTrafficDelay": 500000, "maxTrafficLoss": 100, "maxTrafficJitter": 100000},
      "routingGroup": {
        "href": "http://localhost:3001/cimi/routing_groups/group1" } } }'
http://localhost:3001/cimi/networks?format=json

In all cases, the consumer gets a representation of the newly created Network - either in json or xml format as specified by the “?format=” parameter of the url (http://localhost:3001/cimi/networks?format=xml):

<Network xmlns="http://www.dmtf.org/cimi">
  <state>STARTED</state>
  <maxTrafficLoss>100</maxTrafficLoss>
  <id>http://localhost:3001/cimi/networks/my_test_network </id>
  <routingGroup href="http://localhost:3001/cimi/routing_groups/group1" />
  <maxTrafficJitter>100000</maxTrafficJitter>
  <operation href="http://localhost:3001/cimi/networks/my_test_network" rel="edit" />
  <operation href="http://localhost:3001/cimi/networks/my_test_network" rel="delete" />
  <maxTrafficDelay>500000</maxTrafficDelay>
  <access>Public</access>
  <created>Fri Apr 06 17:15:20 +0300 2012</created>
  <trafficPriority>1</trafficPriority>
  <name> my_test_network </name>
  <description> A test network </description>
</Network>

index

Network state change

Networks respond to start, stop and suspend actions. In CIMI, an ‘Action’ entity is used to effect state changes. Below I show only the ‘stop’ example as the others are very similar (using ‘start’ and ‘suspend’ actions to the Network start/suspend URL respectively).

XML:

curl -iv -X POST --user "mockuser:mockpassword" -H "Content-Type: application/xml"
-d '<Action xmlns="http://www.dmtf.org/cimi">
      <action> http://www.dmtf.org/cimi/action/stop </action>
    </Action> ' http://localhost:3001/cimi/networks/my_test_network/stop?format=xml

JSON:

curl -iv -X POST --user "mockuser:mockpassword" -H "Content-Type: application/json"
-d '{"entityURI": "http://www.dmtf.org/cimi/Action",
    "action":"http://www.dmtf.org/cimi/action/stop"}'
http://localhost:3001/cimi/networks/my_test_network/stop?format=json

index

Create/Delete Address

Again, the delete operation is the simplest:

curl -X DELETE --user "mockuser:mockpassword"
http://localhost:3001/cimi/addresses/address1?format=xml

To create an Address, a consumer can either pass an AddressTemplate by value (inline) or by reference:

Create Address using AddressTemplate by value

XML:

curl -X POST --user "mockuser:mockpassword" -H "Content-Type: application/xml"
-d '<AddressCreate>
      <name> an_address </name>
      <description> an IP Address </description>
      <addressTemplate>
        <ip> 192.168.10.100 </ip>
        <hostname> marios.local </hostname>
        <allocation> static </allocation>
        <defaultGateway> 192.168.0.1 </defaultGateway>
        <dns> 192.168.0.10 </dns>
        <macAddress></macAddress>
        <protocol> IPv4 </protocol>
        <mask> 255.255.0.0 </mask>
        <network href="http://localhost:3001/cimi/networks/network1">
        </network>
      </addressTemplate>
    </AddressCreate>' http://localhost:3001/cimi/addresses?format=xml

JSON:

curl -X POST --user "mockuser:mockpassword" -H "Content-Type: application/json"
-d '{ "name": "an_address", "description": "an IP Address",
"addressTemplate": {
  "ip": "192.168.10.100", "hostname": "marios.local",
  "allocation": "static", "defaultGateway": "192.168.0.1",
  "dns": "192.168.0.10","macAddress": "",
  "protocol": "IPv4", "mask": "255.255.0.0",
  "network": {"href": "http://localhost:3001/cimi/networks/network1" }}}'
http://localhost:3001/cimi/addresses?format=json

Create Address using AddressTemplate by reference:

XML:

curl -X POST --user "mockuser:mockpassword" -H "Content-Type: application/xml"
-d '<AddressCreate>
      <name> an_address </name>
      <description> an IP Address </description>
      <addressTemplate href="http://localhost:3001/cimi/address_templates/addr_template1">
      </addressTemplate>
    </AddressCreate>' http://localhost:3001/cimi/addresses?format=xml

JSON:

curl -X POST --user "mockuser:mockpassword" -H "Content-Type: application/json"
-d '{ "name": "an_address", "description": "an IP Address",
"addressTemplate": {
  "href": "http://localhost:3001/cimi/address_templates/addr_template1"}}'
http://localhost:3001/cimi/addresses?format=json

index

Create/Delete VSP

To delete a VSP:

curl -X DELETE --user "mockuser:mockpassword" http://localhost:3001/cimi/vsps/vsp1

As with Networks, there are 3 ways to create a vsp: i) With a VSPTemplate by value, using a VSPConfiguration by value, ii) with a VSPTemplate by value and a VSPConfiguration by reference, iii) with a VSPTemplate by reference:

VSPTemplate by value, with a VSPConfiguration by value

XML:

curl -X POST --user "mockuser:mockpassword" -H "Content-Type: application/xml"
-d '<VSPCreate>
      <name> my_vsp </name> <description> a Virtual Switch Port </description>
      <vspTemplate>
        <vspConfig>
          <bandwidthReservation> 0.5 </bandwidthReservation>
          <trafficPriority> 1 </trafficPriority>
          <maxTrafficDelay> 500000 </maxTrafficDelay>
          <maxTrafficLoss> 100 </maxTrafficLoss>
          <maxTrafficJitter> 100000 </maxTrafficJitter>
        </vspConfig>
        <network href="http://localhost:3001/cimi/networks/network1">
        </network>
      </vspTemplate>
    </VSPCreate>' http://localhost:3001/cimi/vsps?format=xml

JSON:

curl -X POST --user "mockuser:mockpassword" -H "Content-Type: application/json"
-d '{ "name": "my_vsp", "description": "a Virtual Switch Port",
"vspTemplate": {
  "vspConfig": {
    "bandwidthReservation": 0.5, "trafficPriority": 1, "maxTrafficDelay": 500000,
    "maxTrafficLoss": 100, "maxTrafficJitter": 100000},
  "network": {"href": "http://localhost:3001/cimi/networks/network1" }}}'
http://localhost:3001/cimi/vsps?format=json

VSPTemplate by value, with a VSPConfiguration by reference

XML:

curl -X POST --user "mockuser:mockpassword" -H "Content-Type: application/xml"
-d '<VSPCreate>
      <name> my_vsp </name>
      <description> a Virtual Switch Port </description>
      <vspTemplate>
        <vspConfig href="http://localhost:3001/cimi/vsp_configurations/vspconfig1">
        </vspConfig>
        <network href="http://localhost:3001/cimi/networks/network1"> </network>
      </vspTemplate>
    </VSPCreate>' http://localhost:3001/cimi/vsps?format=xml

JSON:

curl -X POST --user "mockuser:mockpassword" -H "Content-Type: application/json"
-d '{ "name": "my_vsp", "description": "a Virtual Switch Port",
"vspTemplate": {
  "vspConfig": {"href": "http://localhost:3001/cimi/vsp_configurations/vspconfig1"},
  "network": {"href": "http://localhost:3001/cimi/networks/network1" }}}'
http://localhost:3001/cimi/vsps?format=json

VSPTemplate by reference

XML:

curl -X POST --user "mockuser:mockpassword" -H "Content-Type: application/xml"
-d '<VSPCreate>
      <name> my_vsp </name>
      <description> a Virtual Switch Port </description>
      <vspTemplate href="http://localhost:3001/cimi/vsp_templates/template1">
      </vspTemplate>
    </VSPCreate>' http://localhost:3001/cimi/vsps?format=xml

JSON:

curl -X POST --user "mockuser:mockpassword" -H "Content-Type: application/json"
-d '{ "name": "my_vsp", "description": "a Virtual Switch Port",
"vspTemplate": {
  "href": "http://localhost:3001/cimi/vsp_templates/template1"}}'
http://localhost:3001/cimi/vsps?format=json

index

VSP state change

VSPs respond to start and stop actions. In CIMI, an ‘Action’ entity is used to effect state changes. Below I show only the ‘stop’ example as start is very similar (using a ‘start’ action to the Network start URL instead).

XML:

curl -iv -X POST --user "mockuser:mockpassword" -H "Content-Type: application/xml"
-d '<Action xmlns="http://www.dmtf.org/cimi">
      <action> http://www.dmtf.org/cimi/action/stop </action>
    </Action>' http://localhost:3001/cimi/vsps/my_vsp/stop?format=xml

JSON:

curl -iv -X POST --user "mockuser:mockpassword" -H "Content-Type: application/json"
-d '{"entityURI": "http://www.dmtf.org/cimi/Action",
      "action":"http://www.dmtf.org/cimi/action/stop"}'
http://localhost:3001/cimi/vsps/my_vsp/stop?format=json

index

A look at networking in CIMI and Openstack

2012-03-05 00:00:00 +0200

A look at networking in CIMI and Openstack

First off I should note that the following is not really a head-to-head comparison; that wouldn’t be fair. CIMI is still a work in progress - current version at time of writing is 1.0.0c. Similarly, the Openstack Networking API - Quantum - is still an incubator document.

Furthermore, whilst CIMI contains all the ‘bits’ of the Networking API required to (for example) put two Machines on the same subnet, Quantum is only 2/3 of the story. Quantum defines the network entities but relies on Nova (i.e. the ‘compute’ bit of Openstack) to manage the Virtual Interfaces. The current Nova API doesn’t have any notion of Virtual Interfaces or how these are to be associated with servers.

Thus the following is more of a summary of the networking entities and concepts in each API, followed by some high-level conclusions.

Openstack Quantum networking API:

The main entities are:

Network is a “virtual isolated layer-2 broadcast domain”. Networks have ports and ports have Attachments (aka ‘Virtual Interfaces’ VIFs). As I understand it, each Network represents a single logical (layer 2) network switch.
Port is a “port on a logical network switch”. Each port can have an Attachment ‘plugged into’ it (attachments are VIFs - virtual interfaces).
Attachment is a VIF - Virtual Interface. These are owned/managed by an “external service” such as Nova. Once you have a VIF, you can use it as an attachment into a port of a network.

###Network

Standard CRUD operations are offered for each of these entities. Each of the GET ops come in two flavors: ‘standard’ and ‘detail’.

For instance, a ‘standard’ GET on a specified Network (examples shamelessly copied from the Quantum API:

GET /tenants/foo/networks/8bec1293-16bd-4568-ba75-1f58bec0b4c3

<network id="8bec1293-16bd-4568-ba75-1f58bec0b4c3" name="test_network"/>

and a ‘detail’ GET on the same Network:

GET /tenants/foo/networks/8bec1293-16bd-4568-ba75-1f58bec0b4c3/detail

<network id="8bec1293-16bd-4568-ba75-1f58bec0b4c3" name="test_network">
  <ports>
    <port id="98017ddc-efc8-4c25-a915-774b2a633855" status="DOWN"/>
    <port id="b832be00-6553-4f69-af33-acd554e36d08" status="ACTIVE">
      <attachment id="some_VIF_id"/>
    </port>
  </ports>
</network>

Networks are created by specifying only a ‘name’:

POST /tenants/foo/networks

<network name="test_create_network"/>

(the operations of adding Port(s) is actually done on the ports collection).

###Port

As with Network, the GET operation has a ‘standard’ and a ‘detail’ version. Ports have an ‘id’ and a ‘state’ - which is either DOWN or ACTIVE.

GET /tenants/foo/networks/8bec1293-16bd-4568-ba75-1f58bec0b4c3/ports/98017ddc-efc8-4c25-a915-774b2a633855/detail

<port id="98017ddc-efc8-4c25-a915-774b2a633855" state="DOWN">
  <attachment id="test_interface_identifier"/>
</port>

You create a port on a Network specified in the POST URL. A message body is optional for this operation - you may specify the state in which the port will be created (defaults to ‘DOWN’):

Request:

POST /tenants/foo/networks/8bec1293-16bd-4568-ba75-1f58bec0b4c3/ports

<port state="ACTIVE"/>

Response:

<port id="98017ddc-efc8-4c25-a915-774b2a633855"/>

Ports are deleted with a DELETE operation specifying the port and network in the DELETE URL (failing if the port has Attachments):

DELETE /tenants/foo/networks/8bec1293-16bd-4568-ba75-1f58bec0b4c3/ports/98017ddc-efc8-4c25-a915-774b2a633855

###Attachment

These are ‘owned’ by an external service “which uses Quantum, for instance the OpenStack Compute service, Nova”. Thus the Quantum API does not provide operations for creating or deleting Attachments; rather Quantum provides operations for plugging and unplugging an Attachment from a specified Network port.

Attach operation (I assume that the ‘test_interface_identified’ is provided by the service which created the VIF/Attachment, like Nova):

PUT /tenants/foo/networks/8bec1293-16bd-4568-ba75-1f58bec0b4c3/ports/98017ddc-efc8-4c25-a915-774b2a633855/attachment/

<attachment id="test_interface_identifier"/>

Detach operation:

DELETE /tenants/foo/networks/8bec1293-16bd-4568-ba75-1f58bec0b4c3/ports/98017ddc-efc8-4c25-a915-774b2a633855/attachment

Show Attachment in a given port:

GET /tenants/foo/networks/8bec1293-16bd-4568-ba75-1f58bec0b4c3/ports/98017ddc-efc8-4c25-a915-774b2a633855/attachment

<attachment id="test_interface_identifier"/>

###CIMI networking API:

The main entities are:

Network - is an “Abstraction of a layer 2 broadcast domain”. As such a Network has a number of attributes which define the operational properties of the physical Network which is being abstracted. These include a state, bandwidthLimit, trafficPriority, access (public/privately routable network), maxTrafficDelay, maxTrafficLoss, maxTrafficJitter and a routingGroup. As with Openstack Quantum, my understanding is that a Network is essentially a logical layer-2 network switch.
VSP - is a Virtual Switch Port and thus defines the “connection parameters of a network port.” The attributes of a VSP include the Network (i.e. layer-2 switch) to which the port is associated: state, network, bandwidthReservation, trafficPriority, maxTrafficDelay, maxTrafficLoss, maxTrafficJitter
RoutingGroup - is simply a “collection of Networks that route to each other”.

The link between the Network and the Compute entities of CIMI is through the CIMI Machine entity. A Machine has an array of NetworkInterfaces - each NetworkInterface includes a reference to a VSP (and other attributes such as MAC address, protocol, IP address etc).

Before looking at some of the API operations for the network entities, it is necessary to provide a little background on the creation pattern common to all CIMI entities:

Each entity has an equivalent collection which is the grouping of all instances of the given entity. So Network also has a NetworkCollection. Besides the grouping, the collection also provides the URI to which a consumer (a ‘client’ in CIMI parlance) should POST for creation of the given entity.
Each entity has a configuration which is the collection of values used in the instantiation of the given entity. Thus, a NetworkConfiguration is used to define the parameters of a to-be-created Network.
The actual creation of a given entity is achieved through an entity template. Thus, a Network is created using a NetworkTemplate, which in turn contains a NetworkConfiguration together with any other values required for the creation.

The above explains why at first sight, the number of entities defined by the CIMI API may seem overwhelming. The CIMI Primer may be a good place to start when looking at the CIMI API (DSP 2027). Using Network as an example, the CIMI API defines six related entities in total:

Network,
NetworkCollection,
NetworkConfiguration,
NetworkConfigurationCollection,
NetworkTemplate,
NetworkTemplateCollection.

Network

A Network is created using a NetworkTemplate. A NetworkTemplate contains the NetworkConfiguration and the RoutingGroup to which the created Network will belong (if any):

POST /example.com/networks

<NetworkCreate>
  <name> my_test_network </name>
  <description> A test network </description>
  <networkTemplate>
    <networkConfig>
      <access> public </access>
      <bandwidthLimit> 2 <bandwidthLimit>
      <trafficPriority> 1 </trafficPriority>
      <maxTrafficDelay> 500,000 </maxTrafficDelay>
      <maxTrafficLoss> 100 </maxTrafficLoss>
      <maxTrafficJitter> 100,000 </maxTrafficJitter>
    </networkConfig>
    <routingGroup href="http://example.com/routinggroups/group1">
  </networkTemplate>
</NetworkCreate>

Note that the above specifies the NetworkConfiguration by-value; it is possible for a client to specify this by-reference, that is, using a pre-defined NetworkConfiguration given by the cloud service provider. In such a case, the body for create operation is simplified:

<NetworkCreate>
  <name> my_test_network </name>
  <description> A test network </description>
  <networkTemplate>
    <networkConfig href="http://example.com/networkconfigs/config1"/>
    <routingGroup href="http://example.com/routinggroups/group1">
  </networkTemplate>
</NetworkCreate>

A GET on the URL of a Network will return the serialized (xml or json) format of that Network. Note that the serialization, as with all CIMI entities, will contain the ‘DELETE’ URL (i.e. the URL to be used for a DELETE operation on that entity):

GET /example.com/networks/my_test_network

<Network xmlns="http://www.dmtf.org/cimi">
  <id> /example.com/networks/my_test_network </id>
  <name> my_test_network </name>
  <description> A test network </description>
  <created> Mar 1 12:55:02 EET 2012 </created>
  <updated> Mar 1 12:55:02 EET 2012 </updated>
  <state>STARTED</state>
  <access> public </access>
  <bandwidthLimit> 2 <bandwidthLimit>
  <trafficPriority> 1 </trafficPriority>
  <maxTrafficDelay> 500,000 </maxTrafficDelay>
  <maxTrafficLoss> 100 </maxTrafficLoss>
  <maxTrafficJitter> 100,000 </maxTrafficJitter>
  <routingGroup href="http://example.com/routinggroups/group1"/>
  <eventLog href="http://example.com/events/networks/event1"/>
  <operation rel="edit" href="http://example.com/networks/my_test_network"/>
  <operation rel="delete" href="http://example.com/networks/my_test_network"/>
</Network>

A Network is deleted using the URL for the ‘delete’ operation returned in the xml/json serialization:

DELETE /example.com/networks/my_test_network

###VSP

As with Network, the URL to be used for the VSP creation operation is provided by the VSPCollection. Similarly, a VSP is created using a VSPTemplate, which defines a VSPConfiguration. The VSPTemplate also includes a ‘network’ attribute, identifying the Network to which this VSP will be associated:

POST /example.com/vsps

<VSPCreate>
  <name> my_switchport </name>
  <description> A test switchport </description>
  <vspTemplate>
    <network href="http://example.com/networks/my_test_network"/>
    <vspConfig>
      <bandwidthReservation> 1 </bandwidthReservation>
      <trafficPriority> 2 </trafficPriority>
      <maxTrafficDelay> 500,000 </maxTrafficDelay>
      <maxTrafficLoss> 100 </maxTrafficLoss>
      <maxTrafficJitter> 100,000 </maxTrafficJitter>
    </vspConfig>
  </vspTemplate>
</VSPCreate>

Again and as with Network a VSPConfiguration may be passed by-reference rather than by-value (i.e. as shown above) simplifying the body of the create operation.

GET /example.com/vsps/my_switchport

<VSP xmlns="http://www.dmtf.org/cimi">
  <id> /example.com/vsps/my_switchport </id>
  <name> my_switchport </name>
  <description> A test switchport </description>
  <state> STARTED </state>
  <created> Mar 1 12:56:02 EET 2012 </created>
  <updated> Mar 1 12:56:02 EET 2012 </updated>
  <network href="http://example.com/networks/my_test_network"/>
  <bandwidthReservation> 1 </bandwidthReservation>
  <trafficPriority> 2 </trafficPriority>
  <maxTrafficDelay> 500,000 </maxTrafficDelay>
  <maxTrafficLoss> 100 </maxTrafficLoss>
  <maxTrafficJitter> 100,000 </maxTrafficJitter>
  <eventLog href="http://example.com/events/vsps/event1"/>
  <operation rel="edit" href="http://example.com/vsps/my_switchport"/>
  <operation rel="delete" href="http://example.com/vsps/my_switchport"/>
</VSP>

Following the same pattern as Network (and all CIMI entities for that matter), retrieving the xml/json serialization of a VSP will also provide the DELETE URL:

DELETE /example.com/vsps/my_switchport

###RoutingGroup

Finally, as with all other CIMI entities, the URL for creation of a RoutingGroup is provided by the RoutingGroupCollection. Furthermore, creation of a RoutingGroup is achieved by specifying a RoutingGroupTemplate:

POST /example.com/routing_groups

<RoutingGroupCreate>
  <name> developer_net_group </name>
  <description> routing group for all developer networks </description>
  <routingGroupTemplate>
    <network href="http://example.com/networks/my_test_network"/>
    <network href="http://example.com/networks/my_test_network2"/>
  </routingGroupTemplate>
</RoutingGroupCreate>

Retrieving a RoutingGroup provides the DELETE and EDIT URLs:

GET /example.com/routing_groups/developer_net_group

<RoutingGroup xmlns="http://www.dmtf.org/cimi">
  <id> /example.com/routing_groups/developer_net_group </id>
  <name> developer_net_group </name>
  <description> routing group for all developer networks </description>
  <created> Mar 1 12:57:02 EET 2012 </created>
  <updated> Mar 1 12:57:02 EET 2012 </updated>
  <network href="http://example.com/networks/my_test_network"/>
  <network href="http://example.com/networks/my_test_network2"/>
  <operation rel="edit" href="http://example.com/routing_groups/developer_net_group"/>
  <operation rel="delete" href="http://example.com/routing_groups/developer_net_group"/>
</RoutingGroup>

Using the DELETE URL returned above to Delete a Network:

DELETE /example.com/routing_groups/developer_net_group

A client may use the EDIT URL to add a new network to the RoutingGroup. In CIMI Update/Edit operations are achieved with HTTP PUT and must include the full description of the entity, together with any new/updated values. Thus, to add the new “dev_net1” Network to the RoutingGroup:

PUT /example.com/routing_groups/developer_net_group

<RoutingGroup xmlns="http://www.dmtf.org/cimi">
  <id> /example.com/routing_groups/developer_net_group </id>
  <name> developer_net_group </name>
  <description> routing group for all developer networks </description>
  <network href="http://example.com/networks/my_test_network"/>
  <network href="http://example.com/networks/my_test_network2"/>
  <network href="http://example.com/networks/dev_net1"/>
</RoutingGroup>

###Conclusions As stated earlier, I will not attempt to judge which of the 2 APIs is ‘better’; for starters that would be entirely subjective and will depend on the use-case. Furthermore, the Quantum API is not a ‘stand-alone’ Networking API and relies on parts of Nova which are yet to be implemented (management of the VIFs/Attachments).

Both APIs have a similar concept of ‘Network’. Essentially a Network defines a logical layer-2 network switch.
A CIMI VSP is essentially a Quantum Port plus VIF/Attachment. That is, a VSP defines the operational parameters of the network port, but also serves as the connection for a given CIMI Machine (remember, a Machine has a reference to a VSP). On the other hand, a Quantum Port needs an Attachment to achieve a connection with a given Openstack Compute server.
The CIMI concept of RoutingGroup is missing from Quantum.
The CIMI Network API is undoubtedly the more complex of the two though it allows for more fine-grained control of specific Network parameters, exposing concepts such as bandwidthLimit, trafficPriority, maxTrafficDelay, maxTrafficLoss, maxTrafficJitter and routingGroup.
Equivalently, one might say that Quantum is more ‘elegant’ but is of course much simpler and affords less control over the virtualised network. It may be that Quantum will evolve before it is finalised, adding similar concepts to the CIMI network API, though this is entirely speculative.
In general, the CIMI API is an attempt at a unified interface that can be implemented and provided by cloud service providers with heterogeneous back-end infrastructure. That is, CIMI API makes no assumptions about the hardware or more simply the ‘internal workings’ of the cloud provider infrastructure (e.g. virtualisation technology being used). However, the Openstack API by definition is designed to be served as the interface to an Openstack installation. This may in part explain the (potential) perceived complexity inherent in CIMI networking.

Updated Openstack v2 API driver in Deltacloud

2012-02-23 00:00:00 +0200

Updated Openstack v2 API driver in Deltacloud

The first iteration of the updated Openstack driver for deltacloud has just been sent to the dev@deltacloud.apache.org mailing list. For now only ‘compute’ (nova) is implemented… ‘object-storage’ (swift) will follow soon. Some work will be needed on the ‘cloudfiles’ rubygem to make it work with the Keystone identity service (will likely end up merging cloudfiles and the openstack/compute rubygem or some such).

###Calling all testers!

If you’ve been looking for a reason to get involved with Deltacloud then please consider testing this new driver. There are likely many issues and bugs that need fixing and all suggestions are welcome.

###Getting the new driver:

At the time of writing the new driver is just a patch sitting on the dev@deltacloud.apache.org mailing list. If you are really keen then you can grab that patch and apply it to the HEAD of the git repo at https://git-wip-us.apache.org/repos/asf/deltacloud.git . The info here may be of use.

Within a couple of days and once any obvious issues are resolved the driver will be pushed to the git repo, in which case you can just grab the latest HEAD containing the pushed driver. There is more developer info here but essentially:

    mkdir DeltacloudProject
    cd DeltacloudProject
    git clone  https://git-wip-us.apache.org/repos/asf/deltacloud.git <br>

###Testing the new driver:

Assuming you are in a directory “DeltacloudProject” and you have cloned the git repo into it (so you have a directory called deltacloud):

    cd deltacloud
    ./server/bin/deltacloudd -i openstack -P "URI_OF_OPENSTACK_IDENTITY_SERVICE"

The URI_OF_OPENSTACK_IDENTITY_SERVICE will be provided by your Openstack server administrator. For example, identity service URL for the Openstack deployment at HP Cloud Service beta looks like https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/. So to use deltacloud against that Openstack setup:

    ./server/bin/deltacloudd -i openstack -P "https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/"

Using v2 authentication requires three parameters: username, password and tenant-name. To provide these when prompted (i.e. if using the HTML UI - by default you should point your browser @ localhost:3001/api), you should concatenate ‘username’ and ‘tenant-name’ with a ‘+’. With cURL this looks like:

    curl -iv --user "you@domain.com+you@domain.com-default-tenant:f81jD23F3521FSS!" http://localhost:3001/api/realms?format=xml

    [RESPONSE]:
    <?xml version='1.0' encoding='utf-8' ?>
    <realms>
      <realm href='http://localhost:3001/api/realms/default' id='default'>
      <name>default</name>
      <state>AVAILABLE</state>
      <limit>ABSOLUTE >> Max. Instances: 20 Max. RAM: 20480   ||   SERVERS >> Total: 50  Remaining: 50 Time Unit: per DAY</limit>
      </realm>
    </realms>

Where you@domain.com is the username and you@domain.com-default-tenant is the tenant name. Using ‘+’ as a delimiter is probably not the best solution so suggestions are very welcome!

Using the openstack-compute rubygem with HP Cloud Services

2012-02-16 00:00:00 +0200

Using the openstack-compute rubygem with HP Cloud Services

So the folks at HP are running a private beta of their HP Cloud Services. They were kind enough to give me access to their beta program and it was perfect timing as I’m trying to update the Deltacloud Openstack driver to v1.1 of the Openstack API.

I’m using the openstack-compute rubygem to talk to the HP cloud. I had some issues getting it all to work, mainly because I’m new to the Openstack API and also because I was trying to authenticate with the new (?) v2.0 Keystone service.

###1. About the openstack-compute rubygem:

Supports both v1.0 and v2.0 authentication. This is distinguished by the URL of the identity service:

(using v1.1.6 this is in /lib/openstack/compute/authentication.rb)
if conn.auth_path =~ /.*v2.0\/?$/
  AuthV20.new(conn)
else
  AuthV10.new(conn)
end

For v2.0 authentication, it expects ‘username’, ‘password’ and ‘tenantName’. It is important to note that this is tenantName and not tenantId. The ‘username’ and ‘password’ are actually the credentials that you use to login to https://manage.hpcloud.com/login.
Generally, keystone (i.e. v2.0) Identity service allows you to authenticate in a number of ways… using your API access key/private keys, OR username/password, AND your tenantId OR tenantName. For now though and since I want to use the openstack-compute gem I have to use username, password, tenantName. Right.

###2. About the hp cloud credentials.

Once logged into the HP Cloud web console you will find credentials under ‘Account’. You need to use the ‘Tenant Name’ and the URL of the ‘Identity’ service under ‘Service Endpoints’. They look something like:
```
Service Endpoints

  Tenant ID    98765432109876
  Tenant Name  you@domain.com-default-tenant

  Identity
    https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/
```

###3. Getting it all to work.

    [marios@name deltacloud]$ irb -rubygems

    irb(main):001:0> require 'openstack/compute'

    => true

    irb(main):002:0> os = OpenStack::Compute::Connection.new(:username => 
    "your_user_name", :api_key =>    "your_password", 
    :auth_url => "https://region-a.geo-1.identity.hpcloudsvc.com:35357v2.0/", 
    :authtenant=>"you@domain.com-default-tenant")

    => #<OpenStack::Compute::Connection:0xb7408ec4 @svrmgmtpath="/v1.1/98765432109876", 
    @authok=true, @region=nil, @authtoken="HPAuth_3f3sd1a14e4b2f8f253735d1", 
    @auth_scheme="https", @auth_url="https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/",     
    @svrmgmtscheme="https", @proxy_host=nil, @service_name="compute", 
    @auth_port=35357, @authuser="foo@bar.com", @svrmgmtport=443,
    @retry_auth=nil, @authtenant="you@domain.com-default-tenant", 
    @auth_host="region-a.geo-1.identity.hpcloudsvc.com", 
    @authkey="password", @http={}, @is_debug=nil,
    @svrmgmthost="az-2.region-a.geo-1.compute.hpcloudsvc.com", @proxy_port=nil, 
    @auth_path="/v2.0/">

###4. Doing it with cURL:

Using v1.0 authentication:
```
  curl -iv -H "X-Auth-User: your_username" -H "X-Auth-Key: your_password" 
  "https://region-a.geo-1.identity.hpcloudsvc.com:35357/v1.0/"
```
Note that the same credentials are used here, i.e. username and password that you use to login to https://manage.hpcloud.com/login.
Using v2.0 authentication:

A main difference in v2.0 is that we POST our credentials to the Identity service, rather than using HTTP headers:
```
  curl -ivX POST -H "Content-Type: application/json" https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/tokens
  -d '{"auth":{"passwordCredentials":{"username":"your_username", "password":"your_password"},
  "tenantId":"yourtenantId"}}'
```
Note that here I specified the tenantId, but you can just as easily use “tenantName”:”yourtenantNAME” in the curl POST data. Since we’re using cURL, we can also use the other credentials if we like, rather than username and password… i.e. the AccessKey and SecretKey (ala EC2). However to use this the Identity service expects slightly different data:
```
  curl -ivX POST -H "Content-Type: application/json" https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/tokens 
  -d '{"auth":{"apiAccessKeyCredentials":{"accessKey":"AW313FDNF3192W6VBW9X",
  "secretKey":"JKL:79823jlkjlkJKLLKJfdFSFSD"}, "tenantName":"you@domain.com-default-tenant"}}'
```
i.e. apiAccessKeyCredentials, accessKey and secretKey. You can also use tenantId instead if you prefer.

Now that I’ve got a working Openstack cloud to play with, all I have to do it write the driver …

Deltacloud - supporting OpenNebula 3.x API

2012-02-15 00:00:00 +0200

Deltacloud - supporting OpenNebula 3.x API

The OpenNebula driver in Deltacloud has been updated to support version 3.x of the OpenNebula API . The driver is contributed to Deltacloud by Daniel Molina and it ‘speaks’ to the OpenNebula OCCI endpoint (OpenNebula exposes both EC2 and OCCI interfaces).

Daniel Molina has put together a great ‘how-to’ for using OpenNebula through Deltacloud here.

Essentially:

If you aren’t yet ready to install OpenNebula and just want to try out the Deltacloud-OpenNebula setup, you can use the ‘mock’ OpenNebula cloud; request an account from here
Start your deltacloud server:
```
 deltacloudd -i opennebula -P https://cloud.opennebula.org/occi
```
where https://cloud.opennebula.org/occi is the endpoint for the OpenNebula mock OCCI interface. Alternatively you can specify this using environment variables:
```
 export OCCI_URL="https://cloud.opennebula.org/occi"
 deltacloudd -i opennebula
```
You can also do the same per request on the client side by specifying the provider using the client request HTTP headers; e.g. using cURL and assuming deltacloud running at localhost:3001:
```
 curl -iv --user "username:userkey" -H "X-Deltacloud-Provider: https://cloud.opennebula.org/occi" http://localhost:3001/api/images?format=xml
```

FOSDEM - 2012

2012-02-13 00:00:00 +0200

FOSDEM - 2012

FOSDEM 2012 was excellent. Red Hat had a very strong presence at FOSDEM this year and especially so in the Virtualization and Cloud Devroom where I spent most of my time. On Saturday Richard Jones talked about libguestfs, Francesco Vollero gave an introduction to the Aeolus Project, Michal Fojtik spoke about Deltacloud and I gave a talk DMTF CIMI and the work-in-progress implementation of this API in Deltacloud. There were more talks by Red Hatters, including Ryan Lane, Padraig Brady and Daniel Berrange.

Daniel Molina gave an introduction to the OpenNebula Project. It was great to finally meet Daniel in person; Daniel has contributed the OpenNebula driver to the Deltacloud project and has recently updated this to support v3 of the OpenNebula API.

On Sunday Itamar Heim gave an overview of oVirt, Omer Frenkel spoke more about the oVirt Engine Core and Federico Simoncelli spoke about VDSM.

I picked up a geek-chic t-shirt for my work-in-progress newborn (expected later this year :) ) from the FSFE stand (thanks to my very Italian friend Franscesco Vollero for the photo). This was my first FOSDEM and I was very impressed by the scale and organisation of the event. It was great to finally put some faces to names and compared to other (e.g. academic) conferences the atmosphere was very friendly and relaxed - especially for those giving talks. I really hope to go again next year.

marios log - Deltacloud

Deltacloud Networks API - a work in progress

The Network Models

Common Operations and Driver Patterns

Networks

Subnets

Instances

Patches

Open Issues/Questions

Deltacloud CIMI API - CIMI Volumes, Machines and the MachineVolume collection

Starting Deltacloud with the CIMI frontend enabled

Listing Machines

Listing Volumes

Working with the MachineVolume collection

Volumes Support in the Deltacloud Openstack Driver

Volumes support in the Openstack rubygem:

Volumes support in the Deltacloud Openstack driver:

Segmenting Huge Blobs - Part II

1. Initiate:

Request:

Response:

2. Upload Segment:

Request:

Response:

3. Complete Upload:

Request:

Response:

Segmenting Huge Blobs

The native way

Openstack Swift

Amazon S3

Microsoft Azure

Google Cloud Storage

The Deltacloud way?

Approach 1 - lowest common denominator (aka ‘brute force’)

Approach 2 - hybrid

An updated ruby-openstack rubygem

Now why would you want to do that?!

How do I use it?

Next

CIMI Networking in Deltacloud - A Work in Progress

Implemented network entities and the Deltacloud mock driver

Operation examples with cURL

Getting the Cloud Entry Point

Getting the NetworkCollection

Getting a specific VSP

Create/Delete Networks

Create a Network, specifying a NetworkTemplate by reference:

Create a Network with NetworkTemplate by value and NetworkConfiguration by reference:

Create a Network with NetworkTemplate by value and NetworkConfiguration by value:

Network state change

Create/Delete Address

Create Address using AddressTemplate by value

Create Address using AddressTemplate by reference:

Create/Delete VSP

VSPTemplate by value, with a VSPConfiguration by value

VSPTemplate by value, with a VSPConfiguration by reference

VSPTemplate by reference

VSP state change

A look at networking in CIMI and Openstack

Openstack Quantum networking API:

Network

Updated Openstack v2 API driver in Deltacloud

Using the openstack-compute rubygem with HP Cloud Services

Deltacloud - supporting OpenNebula 3.x API

FOSDEM - 2012