OpenStack Community Weekly Newsletter (Sept., 12 – 18)

The content below is taken from the original (OpenStack Community Weekly Newsletter (Sept., 12 – 18)), to continue reading please visit the site. Remember to respect the Author & Copyright.

Running OpenStack? You have the power to influence the roadmap

Complete the User Survey by September 25

Call for Outreachy Mentors 

If you are a  full-time contributor, please consider sharing your time, knowledge and experience to make our community more diverse and you’ll have the opportunity to meet new talents. Ask for further directions in #OpenStack-opw on Freenode.

A starter guide to DefCore, OpenStack’s interoperability project

Rob Hirschfeld, co-chair of the DefCore committee, shares more on DefCore, which defines capabilities, code and must-pass tests, creating the minimum standards for products labeled OpenStack

The Road to Tokyo 

Reports from Previous Events 

  • None this week

Deadlines and Contributors Notifications 

Security Advisories and Notices 

  • None this week

Tips ‘n Tricks 

Upcoming Events 

What you need to know from the developer’s list

  • PTL Nominations Are Over, Lets Start Elections!
  • Five projects don’t have candidates. According to OpenStack governance, the TC will appoint the new PTL [1].
    •   Barbican
    •   MagnetoDB
    •   Magnum
    •   Murano
    •   Security
    • Seven projects will have an election:
    •   Cinder
    •   Glance
    •   Ironic
    •   Keystone
    •   Mistral
    •   Neutron
    •   Oslo   
    •  There was confusion in UTC and how to submit nominations through Gerrit, but the TC will work with those candidates in Magnum, Barbican, Murano, Security. 
    • Doug Hellmann says MagnetoDB will be discussed for removal due to inactivity.​ [1]
  • Proposed Priorities For Glance
  • 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.

  • Not widely deployed. Potential DOS vector.

2) Task API, to have Glance download it asynchronously.

  • Not widely deployed.
  • 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).
  • New Proposed ‘default’ network model
    • 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.
  •  Base Feature Deprecation Policy
    • Thierry proposes a standard way to communicate and perform removal of user-visible behaviors and capabilities.
    • We sort of have something today, but not written of “to remove a feature, you mark it deprecated for n releases, then remove it”.
    • Tag proposed [4].
    • We need to survey existing projects to see what their deprecation policy is.
    • Proposed options for deprecation period:
    • n+2 for features and capabilities, n+1 for config options
    • n+1 for everything
    • n+2 for everything
    • Ben Swartzlander thinks this discussion also needs to cover long term support (LTS).
    • Fungi thinks this is premature. Icehouse stable branch made it to 14 months before it was dropped due to not enough effort was given to keep it working.
    • It was agreed “config options and features will have to be marked deprecated for a minimum of one stable release branch and a minimum of 3 months”.​
  • team:danger-not-diverse tag
    • Josh Harlow is concerned that most projects start off small and not diverse, and this tag [5] would create negative connotations for those projects.
    • Thierry raises it’s important to see the intent of the tag, rather by it’s name.
    • The tag system is there to help our ecosystem navigate the big tent by providing bits of information.
    • Example of information: how risky is it to invest on a given project?
    • Some projects are dependent on a single company and can disappear in one day by the CEO’s decision.
    • For this reason, Thierry supports describing project teams that are *extremely* fragile.
    • As a result, the big tent is more inclusive. On the flip side, we need to inform our ecosystem that some project are less mature. Otherwise, you’re hiding this information.

[1] –

[2] –

[3] –

[4] –

[5] –

Other News 

OpenStack Reactions


When people say they have a full, Active:Active, HA OpenStack deployed


Using and unit test logs to hunt down race conditions that are blocking the gate