openstack team mailing list archive

[Justin Santa Barbara <justin@xxxxxxxxxxxx>]

Some thoughts...

General:


   - Are we writing the OpenStack API, or are we writing the document for
   the next version of Cloud Servers?  In my opinion, the two need to be
   separate.  For example, specifications of resource limits and rate limits,
   supported compression encodings, timeout on persistent connections,
   pagination, caching, polling and resize confirmation windows don't belong in
   the core OpenStack API.  These should be put in the CloudServers v1.1
   documentation, but a different OpenStack provider will not impose the same
   limitations that Rackspace will.


Metadata:


   - The 5 item limit will probably need to be raised if we start using the
   metadata for hints etc, but this is no big deal
   - What is the behaviour of the metadata collection update when metadata
   is already present (merge or replace)?  Can this return the new metadata
   values instead of no-return-value?
   - Should we allow custom metadata on all items?  Should we replace some
   properties with well-known metadata?  e.g. on flavors, should the disk
   property move to openstack:disk metadata?  This way we don't need to define
   the exact set of metadata on all items for eternity (e.g. authors on
   extensions)
   - Are duplicate metadata keys allowed?
   - Can we please reserve the openstack: prefix, just like AWS reserves the
   aws: prefix


IP Addresses:


   - Instead of just supporting a public and private network, how about
   specifying <network id="public"> and <network id="private">.  This way we
   can also support more networks e.g. SAN, private VPN networks, HPC
   interconnects etc
   - Is it useful to know which IPV4 addresses and IPV6 addresses map to
   network cards?  Right now if there are multiple addresses on the same
   network, the correspondence is undefined.
   - What happens when a machine has a block of addresses?  Is each address
   listed individually?  What happens in IPv6 land where a machine could well
   have a huge block?  I think we need a netmask.


Extensions:


   - How are the XML schemas going to work with extension elements?  Right
   now, it's very free-form, which can cause problems with useful schemas.  Are
   the proposed schemas available?


Volumes:


   - Volume support is core to OpenStack (and has been since launch).  This
   needs therefore to be in the core API, not in an extension.  Or if it is an
   extension then compute, images and flavors should all be in extensions also
   (which would be cool, if a little complicated.)




Justin





On Mon, Feb 14, 2011 at 11:30 AM, John Purrier <john@xxxxxxxxxxxxx> wrote:

> Bumping this to the top of the list. One of the key deliverables for Cactus
> is a complete and usable OpenStack Compute API. This means that using only
> the API and tools that interact with the OpenStack Compute API Nova can be
> installed and configured; once running all of the Nova features and
> functions for VM, Network, and Volume provisioning and management are
> accessible and operable through the API.
>
>
>
> We need your eyes on this, to ensure that the spec is correct. Please take
> the time to review and comment, the more up-front work we do here the better
> the implementation will be.
>
>
>
> Thanks,
>
>
>
> John
>
>
>
> -----Original Message-----
> From: openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx [mailto:
> openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Gabe Westmaas
> Sent: Wednesday, February 09, 2011 3:03 PM
> To: openstack@xxxxxxxxxxxxxxxxxxx
> Subject: [Openstack] OpenStack API 1.1
>
>
>
> A blueprint and proposed spec for OpenStack API 1.1 has been posted and I
> would love to get feedback on the specification.
>
>
>
> Blueprint:
>
> https://blueprints.launchpad.net/nova/+spec/openstack-api-1-1
>
>
>
> Spec wiki:
>
> http://wiki.openstack.org/OpenStackAPI_1-1
>
>
>
> Detailed Spec:
>
>
> http://wiki.openstack.org/OpenStackAPI_1-1?action=AttachFile&do=view&target=c11-devguide-20110209.pdf
>
>
>
> We'd like to finish up as much of the API implementation for cactus as
> possible, and in particular we want to make sure that we get API extensions
> correct as early as possible.  Other new features in the 1.1 spec include
> the ability to view both IPv4 and v6 addresses, migration to the OpenStack
> namespace and moving from image IDs in responses to URIs (imageRef) for the
> image.  There may be some additional changes as well, please jump in if I
> missed some.
>
>
>
> I will add details to the wiki page as needed based on discussions on the
> mailing list.
>
>
>
> Thanks, and let me know if you have questions.
>
>
>
> Gabe
>
>
>
>
>
> _______________________________________________
>
> Mailing list: https://launchpad.net/~openstack
>
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>
> Unsubscribe : https://launchpad.net/~openstack
>
> More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>