Open Stack

Here is the Glance Priorities for Mitaka discussion:
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074360.html
It shows some of the problems the projects have communicating across project boundaries

This is Jay Frankhauser's summary:

  *   From conversations at the Ops Midcycle meetup and email threads with regards to Glance issues, Doug Hellmann put together a list of proposed priorities for the Glance team:  Focus attention on DefCore:
     *   DefCore goals: Ensure all OpenStack deployments are interoperable at REST level (users can write software for one OpenStack cloud and move to another without changes to the code).
     *   Provide a well documented API with arguments that don't change based on deployment choices.
     *   Integration tests in Tempest that test Glance's API directly, in addition to the the current tests that proxy through Nova and Cinder.
     *   Once incorporated into DefCore, the APIs need to remain stable for an extended period of time, and follow deprecation timelines defined by complete V2 adoption in Nova and Cinder.
     *   In Nova, some specs didn't land in Liberty. Both teams need to work together.
     *   In Cinder, the work is more complete, but needs to be reviewed that the API is used correctly.
     *   Security audits and bug fixes
     *   5 out of the 18 recent security reports were related to Glance [2]
     *   Two ways to upload images to Glance V2:
1) POST image bits to Glance API server.
              a) Not widely deployed. Potential DOS vector.
2) Task API, to have Glance download it asynchronously.
              a) Not widely deployed.
  b) Assumes you know what task "types" are supported by which cloud, and the expected arguments (i.e. JSON blob). (e.g. Glance docs give a url for a source, but Rackspace gives a Swift location as a source)

Here is the thread on troubleshooting cross project communications, etc:
http://lists.openstack.org/pipermail/openstack-dev/2015-September/074950.html

And here is a summary of the first (or maybe second) attempt at getting interoperable User APIs:

  *   New Proposed 'default' network model<http://lists.openstack.org/pipermail/openstack-dev/2015-September/074527.html>
     *   Monty hates floating IPs.
     *   Observed with 5 public clouds, requiring you to use a floating IP to get an outbound address. Others directly attach you to the public network.
     *   Some allow you to create a private network and attach virtual machines to it, create a router with a gateway.
     *    Monty wants an easier way to have a virtual machine on the external facing network of a cloud.
     *   Users shouldn't have to learn about how to make that work with floating tips. This should be consistent behavior across public clouds. There is an effort set for Mitaka to work on Monty's request [3]. This will be done for 'nova boot' and work with multiple networks.
     *    If you have a more complicated network setup, this spec isn't for you.


Enjoy!

--Rocky