{"id":7280,"date":"2015-09-25T14:43:11","date_gmt":"2015-09-25T19:43:11","guid":{"rendered":"http:\/\/www.openstack.org\/blog\/?p=7280"},"modified":"2015-11-04T14:56:58","modified_gmt":"2015-11-04T20:56:58","slug":"openstack-weekly-community-newsletter-sept-19-25","status":"publish","type":"post","link":"https:\/\/www.openstack.org\/blog\/openstack-weekly-community-newsletter-sept-19-25\/","title":{"rendered":"OpenStack Weekly Community Newsletter (Sept.,19 &#8211; 25)"},"content":{"rendered":"<h1 style=\"text-align: left\"><a href=\"https:\/\/www.eventbrite.com\/e\/openstack-summit-october-2015-tokyo-tickets-17356780598\">Register for OpenStack Summit Tokyo 2015<\/a><\/h1>\n<p style=\"text-align: left\" class=\"lead\">Full access registration prices increase on <strong>9\/29 at 11:59pm PT<\/strong><\/p>\n<h1 style=\"text-align: left\"><a href=\"http:\/\/superuser.openstack.org\/articles\/this-trove-of-user-stories-highlights-what-people-want-in-openstack\">This trove of user stories highlights what people want in OpenStack<\/a><\/h1>\n<p style=\"text-align: left\">The Product Working Group recently launched a Git repository to collect requirements ranging from encrypted storage to rolling upgrades.<\/p>\n<h1 style=\"text-align: left\"><a href=\"http:\/\/superuser.openstack.org\/articles\/how-storage-works-in-containers\">How storage works in containers<\/a><\/h1>\n<p style=\"text-align: left\">Nick Gerasimatos, senior director of cloud services engineering at FICO, dives into the lack of persistent storage with containers and how Docker volumes and data containers provide a fix.<\/p>\n<h1 class=\"p4\" style=\"text-align: left\"><span class=\"s1\">The Road to Tokyo\u00a0<\/span><\/h1>\n<ul class=\"ul1\" style=\"text-align: left\">\n<li class=\"li5\"><span class=\"s4\"><span class=\"s5\"><a href=\"http:\/\/superuser.openstack.org\/articles\/get-your-openstack-summit-tokyo-visa-in-five-steps\">Get your OpenStack Summit Tokyo visa in five steps: Deadline for Visa invitation requests is\u00a0<strong>10\/1<\/strong><\/a><\/span><\/span><\/li>\n<li class=\"li5\"><a href=\"https:\/\/www.openstack.org\/summit\/tokyo-2015\/schedule\/\">The schedule and mobile app for the OpenStack Summit in Tokyo are now available<\/a><\/li>\n<\/ul>\n<h1 style=\"text-align: left\">Community feedback<\/h1>\n<p style=\"text-align: left\">OpenStack is always interested in feedback and community contributions, if you would like to see a new section in the\u00a0OpenStack Weekly Community Newsletter\u00a0or have ideas on how to present content please get in touch:\u00a0<span class=\"s1\"><a href=\"mailto:community@openstack.org\">community@openstack.org<\/a>.<\/span><\/p>\n<h1 class=\"p4\" style=\"text-align: left\"><span class=\"s1\">Reports from Previous Events\u00a0<\/span><\/h1>\n<ul class=\"ul1\" style=\"text-align: left\">\n<li class=\"li5\"><a href=\"https:\/\/developer.ibm.com\/opentech\/2015\/09\/20\/openstack-heats-up-silicon-valley\/\">OpenStack Heats up Silicon Valley<\/a><\/li>\n<li class=\"li5\"><a href=\"http:\/\/superuser.openstack.org\/articles\/openstack-day-benelux-2015\">OpenStack Day Benelux<\/a><\/li>\n<\/ul>\n<h1 class=\"p4\" style=\"text-align: left\"><span class=\"s1\">Deadlines and Contributors Notifications<\/span><\/h1>\n<ul class=\"ul1\" style=\"text-align: left\">\n<li class=\"li5\"><a href=\"https:\/\/wiki.openstack.org\/wiki\/Liberty_Release_Schedule\">Liberty Release Oct., 15, 2015<\/a><\/li>\n<\/ul>\n<h1 class=\"p4\" style=\"text-align: left\"><span class=\"s1\">Security Advisories and Notices\u00a0<\/span><\/h1>\n<ul class=\"ul1\" style=\"text-align: left\">\n<li class=\"li5\"><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-announce\/2015-September\/000655.html\" target=\"_blank\">[openstack-announce] [OSSA 2015-019] Glance image status manipulation (CVE-2015-5251)<\/a><\/li>\n<\/ul>\n<h1 class=\"p4\" style=\"text-align: left\"><span class=\"s1\">Tips \u2018n Tricks\u00a0<\/span><\/h1>\n<ul class=\"ul1\" style=\"text-align: left\">\n<li class=\"li5\">By\u00a0<a href=\"http:\/\/blog.coolsvap.net\/\" target=\"_blank\">Swapnil Kulkarni<\/a>:\u00a0<a href=\"http:\/\/blog.coolsvap.net\/2015\/09\/24\/openstackrdo-test-day-liberty\/\" target=\"_blank\">[OpenStack][RDO] Liberty Test-Day<\/a><\/li>\n<\/ul>\n<h1 class=\"p6\" style=\"text-align: left\"><span class=\"s2\"><a href=\"https:\/\/www.openstack.org\/community\/events\">Upcoming Events<\/a><\/span><span class=\"s3\">\u00a0<\/span><\/h1>\n<ul style=\"text-align: left\">\n<li><a href=\"https:\/\/us.pycon.org\/2016\/speaking\/\">Sep 28, 2015\u00a0\u2013\u00a0Jan 3, 2016\u00a0Presenting At PyCon (call for papers) Portland,OR, US\u00a0<\/a><\/li>\n<li><a href=\"https:\/\/groups.openstack.org\/groups\/frederick-md\/cloud-storage-openstack\">Sep 29\u00a0\u2013 30, 2015 Cloud Storage in OpenStack<\/a><\/li>\n<li><a href=\"http:\/\/www.meetup.com\/OpenStackRomania\/events\/222910344\/\">Oct 01, 2015\u00a0OpenStack Meetup Cluj\u00a0Cluj-Napoc, Cluj, RO<\/a><\/li>\n<li><a href=\"http:\/\/www.meetup.com\/openstack\/events\/221806052\/\">Oct 01, 2015\u00a0South Bay OpenStack Meetup, Beginner track San Francisco, CA, US<\/a><\/li>\n<li><a href=\"http:\/\/www.meetup.com\/meetup-group-NjZdcegA\/events\/225081881\/\">Oct 01 \u2013 02, 2015\u00a0October OpenStack Meetup \u2013 SDN and Containers\u00a0Chicago, IL, US<\/a><\/li>\n<li><a href=\"http:\/\/www.gartner.com\/events\/na\/orlando-symposium\">Oct 04 \u2013 08, 2015\u00a0Gartner SymposiumITxpo\u00a0Orlando, FL, US<\/a><\/li>\n<li><a href=\"http:\/\/www.meetup.com\/Australian-OpenStack-User-Group\/events\/220202327\/\">Oct 06, 2015\u00a0October Sydney Meetup<\/a><\/li>\n<li><a href=\"http:\/\/www.meetup.com\/openstackhoustonmeetup\/events\/224870393\/?eventId=224870393&amp;action=detail\">Oct 07, 2015\u00a0Houston OpenStack Meetup\u00a0Houston, TX, US<\/a><\/li>\n<li><a href=\"http:\/\/www.meetup.com\/OpenStack-DFW\/events\/225014699\/\">Oct 07 \u2013 08, 2015\u00a0OpenStack Liberty Release\u00a0Richardson, TX, US<\/a><\/li>\n<li><a href=\"http:\/\/www.meetup.com\/openstackhoustonmeetup\/events\/224870393\/\">Oct 07 \u2013 08, 2015\u00a0OpenStack 101\u00a0Houston, TX, US<\/a><\/li>\n<\/ul>\n<h1 id=\"dev-digest\" class=\"p4\" style=\"text-align: left\"><span class=\"s1\">What you need to know from the developer&#8217;s list<\/span><\/h1>\n<h3 style=\"text-align: left\"><span style=\"font-weight: 400\"><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2015-September\/075227.html\" target=\"_blank\">Handling Projects with no PTL candidates<\/a><\/span><\/h3>\n<ul style=\"text-align: left\">\n<li><span style=\"font-weight: 400\">The technical committee will appoint a PTL [1] if there is no identified eligible candidate.<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Appointed PTLs:<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Robert Clark nominated security PTL<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Serg Melikyan nominated Murano PTL<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Douglas Mendizabal nominated Barbican PTL<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Election for Magnum PTL between Adrian Otto and Hongbin Lu<\/span><\/li>\n<\/ul>\n<\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">MagnetoDB being abandoned, not PTL was chosen. Instead, it will be fast tracked for removal [2] from the official list of OpenStack projects.<\/span><\/li>\n<\/ul>\n<h3 style=\"text-align: left\"><span style=\"font-weight: 400\"><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2015-September\/075075.html\" target=\"_blank\">Release help needed &#8211; we are incompatible with ourselves<\/a><\/span><\/h3>\n<ul style=\"text-align: left\">\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Robert Collins raises that while the constraints system in place for how we recognize incompatible components in our release is working, the release team needs help from the community to fix the incompatibility that exists so we can cut the full Liberty release.<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Issues that exist:<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">OpenStack client not able to create an image.<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Fix is merged [3].<\/span><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h3 style=\"text-align: left\"><span style=\"font-weight: 400\"><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2015-September\/075107.html\" target=\"_blank\">Semver and dependency changes<\/a><\/span><\/h3>\n<ul style=\"text-align: left\">\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Robert Collins says currently we don\u2019t provide guidance on what happens when the only changes in a project are dependency changes and a release is made.<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Today the release team treats dependency changes as a \u201cfeature\u201d rather than a bug fix. (e.g. if the previous release 1.2.3, requirement sync happens, the next version is \u00a01.3.0.)<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Reasons behind this are complex, some guidance is needed to answer the questions:<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Is this requirements change an API break?<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Is this requirements change feature work?<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Is this requirements change a bug fix?<\/span><\/li>\n<\/ul>\n<\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">All of these questions can be true. Some examples:<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">If library X exposes library Y as part of its API, and library Y\u2019s dependency changes from Y&gt;=1 to Y&gt;=2. X does this because it needs a feature from Y==2.<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Library Y is not exposed in library X\u2019s API, however, a change in Y\u2019s dependencies for X will impact users who independently use Y. (ignoring intricacies surrounding PIP here.)<\/span><\/li>\n<\/ul>\n<\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Proposal:<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">nothing -&gt; a requirement -&gt; major version change<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">1.x.y -&gt; 2.0.0 -&gt; major version change<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">1.2.y -&gt; 1.3.0 -&gt; minor version change<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">1.2.3. -&gt; 1.2.4 -&gt; patch version change<\/span><\/li>\n<\/ul>\n<\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Thierry Carrez is ok with the last two proposals. Defaulting to a major version bump sounds a bit overkill.<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Doug Hellmann reminds that we can\u2019t assume the dependency is using semver itself. We would need something other than the version number to determine from the outside whether the API is in fact breaking.<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Due this problem being so complicated, Doug would rather over-simplify the analysis of requirements updates until we\u2019re better at identifying our own API breaking changes and differentiating between features and bug fixes. This will allow us to be consistent, if not 100% correct.<\/span><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h3 style=\"text-align: left\"><span style=\"font-weight: 400\"><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2015-September\/073435.html\" target=\"_blank\">Criteria for applying vulnerability:managed tag<\/a><\/span><\/h3>\n<ul style=\"text-align: left\">\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">The vulnerability management processes were brought to the big tent a couple of months ago [4].<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Initially we listed what repos the Vulnerability Manage Team (VMT) tracks for vulnerabilities.<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">TC decided to change this from repos to deliverables as per-repo tags were decided against.<\/span><\/li>\n<\/ul>\n<\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Jeremy Stanley provides transparency for how deliverables can qualify for this tag:<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">All repos in a given deliverable must qualify. If one repo doesn\u2019t, they all don\u2019t in a given deliverable.<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Points of contact:<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Deliverable must have a dedicated point of contact.<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">The VMT will engage with this contact to triage reports. <\/span><\/li>\n<\/ul>\n<\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">A group of core reviewers should be part of the &lt;project&gt;-corsec team and will:<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Confirm whether a bug is accurate\/applicable.<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Provide pre-approval of patches attached to reports. <\/span><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">The PTLs for the deliverable should agree to act as (or delegate) a vulnerability management liaison to escalate for the VMT.<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">The bug tracker for the repos within a deliverable should have a bug tracker configured to initially provide access to privately reported vulnerabilities initially to the VMT.<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">The VMT will determine if the vulnerability is reported against the correct deliverable and redirect when possible.<\/span><\/li>\n<\/ul>\n<\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">The deliverable repos should undergo a third-party review\/audit looking for obvious signs of insecure design or risky implementation.<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">This aims to keep the VMT\u2019s workload down.<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">It has not been identified who will perform this review. Maybe the OpenStack Security project team?<\/span><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Review of this proposal is posted [5].<\/span><\/li>\n<\/ul>\n<h3 style=\"text-align: left\"><span style=\"font-weight: 400\"><a href=\"http:\/\/lists.openstack.org\/pipermail\/openstack-dev\/2015-September\/074871.html\" target=\"_blank\">Consistent support for SSL termination proxies across all APIs<\/a><\/span><\/h3>\n<ul style=\"text-align: left\">\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">While a bug [6] was being debugged, an issue was identified where an API sitting behind a proxy performing SSL termination would not generate the right redirection (http instead of https).<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">A review [7] has been given to have a config option \u2018secure_proxy_ssl_header\u2019 which allows the API service to detect ssl termination based on the header X-Forwarded-Proto.<\/span><\/li>\n<\/ul>\n<\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Another bug back in 2014 was open with the same issue [8].<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Several projects applied patches to fix this issue, but are inconsistent:<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Glance added public_endpoint config<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Cinder added public_endpoint config<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Heat added secure_proxy_ssl_header config (through heat.api.openstack:sslmiddleware_filter)<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Nova added secure_proxy_ssl_header config<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Manila added secure_proxy_ssl_header config (through oslo_middleware.ssl:SSLMiddleware.factory)<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Ironic added public_endpoint config<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Keystone added secure_proxy_ssl_header config<\/span><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Ben Nemec comments that solving this at the service level is the wrong place, due to this requiring changes in a bunch of different API services. Instead it should be fixed in the proxy that\u2019s converting the traffic to http.<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Sean Dague notes that this should be done in the service catalog. Service discovery is a base thing that all services should use in talking to each other. There\u2019s an OpenStack spec [9] in an attempt to get a handle on this<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Mathieu Gagn\u00e9 notes that this won\u2019t work. There is a \u201csplit view\u201d in the service catalog where internal management nodes have a specific catalog and public nodes (for users) have a different one.<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Suggestion to use oslo middleware SSL for supporting the \u2018secure_proxy_ssl_header\u2019 config to fix the problem with little code.<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Sean agrees the split view needs to be considered, however, another layer of work shouldn\u2019t decide if the service catalog is a good way to keep track of what our service urls are. We shouldn\u2019t push a model where Keystone is optional.<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Sean notes that while the \u2018secure_proxy_ssl_header\u2019 config solution supports the cases where there\u2019s a 1 HA proxy with SSL termination to 1 API service, it may not work in the cases where there\u2019s a 1 API service to N HA Proxies for:<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Clients needing to understand the \u201cLocation:\u201d headers correctly.<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Libraries like request\/phatomjs can follow the links provided in REST documents, and they\u2019re correct.<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">The minority of services that \u201coperate without keystone\u201d as an option are able to function.<\/span><\/li>\n<\/ul>\n<\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">ZZelle mentions this solution does not work in the cases when the service itself acts as a proxy (e.g. nova image-list).<\/span><\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Would this solution work in the HA Proxy case where there is one terminating address for multiple backend servers?<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Yes, by honoring the headers X-Forwarded-Host and X-Forwarded-Port which are set by HTTP proxies, making WSGI applications unaware of the fact that there is a request in front of them.<\/span><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Jamie Lennox says this same topic came up as a block in a Devstack patch to get TLS testing in the gate with HA Proxy.<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Longer term solution, transition services to use relative links.<\/span>\n<ul>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">This is a pretty serious change. We\u2019ve been returning absolute URLs forever, so assuming that all client code out there would with relative code is a big assumption. That\u2019s a major version for sure.<\/span><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<li style=\"font-weight: 400\"><span style=\"font-weight: 400\">Sean agrees that we have enough pieces to get something better with proxy headers for Mitaka. We can do the remaining edge cases if clean up the service catalog use.<\/span><\/li>\n<\/ul>\n<p style=\"text-align: left\"><span style=\"font-weight: 400\">[1] &#8211; <\/span><a href=\"http:\/\/governance.openstack.org\/resolutions\/20141128-elections-process-for-leaderless-programs.html\"><span style=\"font-weight: 400\">http:\/\/governance.openstack.org\/resolutions\/20141128-elections-process-for-leaderless-programs.html<\/span><\/a><\/p>\n<p style=\"text-align: left\"><span style=\"font-weight: 400\">[2] &#8211; <a href=\"https:\/\/review.openstack.org\/#\/c\/224743\/\" target=\"_blank\">https:\/\/review.openstack.org\/#\/c\/224743\/<\/a><\/span><\/p>\n<p style=\"text-align: left\"><span style=\"font-weight: 400\">[3] &#8211; <\/span><a href=\"https:\/\/review.openstack.org\/#\/c\/225443\/\"><span style=\"font-weight: 400\">https:\/\/review.openstack.org\/#\/c\/225443\/<\/span><\/a><\/p>\n<p style=\"text-align: left\"><span style=\"font-weight: 400\">[4] &#8211; <\/span><a href=\"http:\/\/governance.openstack.org\/reference\/tags\/vulnerability_managed.html\"><span style=\"font-weight: 400\">http:\/\/governance.openstack.org\/reference\/tags\/vulnerability_managed.html<\/span><\/a><\/p>\n<p style=\"text-align: left\"><span style=\"font-weight: 400\">[5] &#8211; <\/span><a href=\"https:\/\/review.openstack.org\/#\/c\/226869\/\"><span style=\"font-weight: 400\">https:\/\/review.openstack.org\/#\/c\/226869\/<\/span><\/a><\/p>\n<p style=\"text-align: left\"><span style=\"font-weight: 400\">[6] &#8211; <a href=\"https:\/\/bugs.launchpad.net\/python-novaclient\/+bug\/1491579\" target=\"_blank\">https:\/\/bugs.launchpad.net\/python-novaclient\/+bug\/1491579<\/a><\/span><\/p>\n<p style=\"text-align: left\"><span style=\"font-weight: 400\">[7] &#8211; <\/span><a href=\"https:\/\/review.openstack.org\/#\/c\/206479\/\"><span style=\"font-weight: 400\">https:\/\/review.openstack.org\/#\/c\/206479\/<\/span><\/a><\/p>\n<p style=\"text-align: left\"><span style=\"font-weight: 400\">[8] &#8211; <\/span><a href=\"https:\/\/bugs.launchpad.net\/glance\/+bug\/1384379\"><span style=\"font-weight: 400\">https:\/\/bugs.launchpad.net\/glance\/+bug\/1384379<\/span><\/a><\/p>\n<p style=\"text-align: left\"><span style=\"font-weight: 400\">[9] &#8211; <a href=\"https:\/\/review.openstack.org\/#\/c\/181393\/\" target=\"_blank\">https:\/\/review.openstack.org\/#\/c\/181393\/<\/a><\/span><\/p>\n<h1 style=\"text-align: left\"><\/h1>\n","protected":false},"excerpt":{"rendered":"<p>Register for OpenStack Summit Tokyo 2015 Full access registration prices increase on 9\/29 at 11:59pm PT This trove of user stories highlights what people want in OpenStack The Product Working Group recently launched a Git repository to collect requirements ranging from encrypted storage to rolling upgrades. How storage works in containers Nick Gerasimatos, senior director&#8230;  <a href=\"https:\/\/www.openstack.org\/blog\/openstack-weekly-community-newsletter-sept-19-25\/\" class=\"more-link\" title=\"Read OpenStack Weekly Community Newsletter (Sept.,19 &#8211; 25)\">Read more &raquo;<\/a><\/p>\n","protected":false},"author":81,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/posts\/7280"}],"collection":[{"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/users\/81"}],"replies":[{"embeddable":true,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/comments?post=7280"}],"version-history":[{"count":18,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/posts\/7280\/revisions"}],"predecessor-version":[{"id":7421,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/posts\/7280\/revisions\/7421"}],"wp:attachment":[{"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/media?parent=7280"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/categories?post=7280"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/tags?post=7280"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}