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

Liberty Release Oct., 15, 2015

Security Advisories and Notices

None this week

Tips ‘n Tricks

By Nicole Martinelli: Confused about the OpenStack release cycle? Check out this handy chart
By Superuser: How to migrate from VMware and Hyper-V to OpenStack
By Madhu Kashyap: Bringing NFV into OpenStack with Tacker
By Nicholas Cammorato: Building an OpenStack lab from scratch with PackStack on AWS and Google Cloud – Installing OpenStack via Packstack
By Miguel Grinberg: Keystone-to-Keystone Federation with the OpenStack-Ansible Project

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.