[openstack-dev] [kolla] Proposing duonghq for core
Jeffrey Zhang
zhang.lei.fly at gmail.com
Sun Mar 12 05:35:38 UTC 2017
1392607554 at qq.com is zhubingbing, he configured him mail client in a wrong.
So this vote is valid. ;)
On Sun, Mar 12, 2017 at 12:36 AM, Steven Dake (stdake) <stdake at cisco.com>
wrote:
> Hello,
>
>
>
> I’m not sure who 1392607554 at qq.com is. Could you identify yourself
> please for the mailing list? Note only core reviewers may vote on core
> reviewer nominations and you may be a core reviewer, so as I core reviewer,
> I want to verify you are indeed a core reviewer such that your vote is
> counted. I think I know who you are, but I am not certain.
>
>
>
> Thanks
>
> -steve
>
>
>
>
>
> *From: *1392607554 <1392607554 at qq.com>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev at lists.openstack.org>
> *Date: *Wednesday, March 8, 2017 at 8:49 PM
> *To: *OpenStack-dev-request <openstack-dev at lists.openstack.org>
> *Subject: *Re: [openstack-dev] [kolla] Proposing duonghq for core
>
>
>
>
>
> +1
>
>
>
> ------------------ Original ------------------
>
> *From: * "OpenStack-dev-request";<openstack-dev-request at lists.
> openstack.org>;
>
> *Date: * Thu, Mar 9, 2017 03:25 AM
>
> *To: * "openstack-dev"<openstack-dev at lists.openstack.org>;
>
> *Subject: * OpenStack-dev Digest, Vol 59, Issue 24
>
>
>
> Send OpenStack-dev mailing list submissions to
> openstack-dev at lists.openstack.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> or, via email, send a message with subject or body 'help' to
> openstack-dev-request at lists.openstack.org
>
> You can reach the person managing the list at
> openstack-dev-owner at lists.openstack.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenStack-dev digest..."
>
>
> Today's Topics:
>
> 1. [acceleration] No team meeting today, resume next Wed
> (Zhipeng Huang)
> 2. Re: [ironic] OpenStack client default ironic API version
> (Dmitry Tantsur)
> 3. Re: [release][tripleo][fuel][kolla][ansible] Ocata Release
> countdown for R+2 Week, 6-10 March (Doug Hellmann)
> 4. Re: [tc][appcat][murano][app-catalog] The future of the App
> Catalog (Ian Cordasco)
> 5. Re: [telemetry][requirements] ceilometer grenade gate failure
> (gordon chung)
> 6. Re: [acceleration] No team meeting today, resume next Wed
> (Harm Sluiman)
> 7. [trove] today weekly meeting (Amrith Kumar)
> 8. Re: [kolla][ubuntu][libvirt] Is libvirt 2.5.0 in ubuntu cloud
> archive ocata repo bust (Corey Bryant)
> 9. Re: [ironic] OpenStack client default ironic API version
> (Mario Villaplana)
> 10. [neutron] [infra] Depends-on tag effect (Hirofumi Ichihara)
> 11. Re: [nova] Question to clarify versioned notifications
> (Matt Riedemann)
> 12. Re: [neutron] [infra] Depends-on tag effect (ZZelle)
> 13. Re: [tc][appcat] The future of the App Catalog (Jay Pipes)
> 14. [nova][placement-api] Is there any document about
> openstack-placement-api for installation and configure? (Yu Wei)
> 15. Re: [neutron] [infra] Depends-on tag effect (Andreas Jaeger)
> 16. Re: [TripleO][Heat] Selectively disabling deployment
> resources (James Slagle)
> 17. [ironic] Pike PTG report (Dmitry Tantsur)
> 18. Re: [nova][placement-api] Is there any document about
> openstack-placement-api for installation and configure? (Chris Dent)
> 19. [cinder][glance][horizon][keystone][nova][qa][swift] Feedback
> needed: Removal of legacy per-project vanity domain redirects
> (Monty Taylor)
> 20. Re: [nova][placement-api] Is there any document about
> openstack-placement-api for installation and configure? (Yu Wei)
> 21. Re: [nova][placement-api] Is there any document about
> openstack-placement-api for installation and configure? (Chris Dent)
> 22. Re: [neutron] [infra] Depends-on tag effect (Hirofumi Ichihara)
> 23. Re: [cinder][glance][horizon][keystone][nova][qa][swift]
> Feedback needed: Removal of legacy per-project vanity domain
> redirects (Lance Bragstad)
> 24. Re: [nova][placement-api] Is there any document about
> openstack-placement-api for installation and configure? (Yu Wei)
> 25. Re: [puppet] puppet-cep beaker test (Scheglmann, Stefan)
> 26. Re: [puppet] puppet-cep beaker test (Alex Schultz)
> 27. Re: [tc][appcat] The future of the App Catalog
> (David Moreau Simard)
> 28. Re: [cinder][glance][horizon][keystone][nova][qa][swift]
> Feedback needed: Removal of legacy per-project vanity domain
> redirects (Brian Rosmaita)
> 29. Re: [nova][placement-api] Is there any document about
> openstack-placement-api for installation and configure? (Chris Dent)
> 30. Re: [cinder][glance][horizon][keystone][nova][qa][swift]
> Feedback needed: Removal of legacy per-project vanity domain
> redirects (Daniel P. Berrange)
> 31. Re: [kolla][ubuntu][libvirt] Is libvirt 2.5.0 in ubuntu cloud
> archive ocata repo bust (Jeffrey Zhang)
> 32. Re: [TripleO][Heat] Selectively disabling deployment
> resources (James Slagle)
> 33. Re: [neutron] [infra] Depends-on tag effect (Armando M.)
> 34. Re: [ironic] OpenStack client default ironic API version
> (Jim Rollenhagen)
> 35. Re: [tc][appcat] The future of the App Catalog (Fox, Kevin M)
> 36. Re: [kolla] Proposing duonghq for core (Kwasniewska, Alicja)
> 37. Re: [kolla][ubuntu][libvirt] Is libvirt 2.5.0 in ubuntu cloud
> archive ocata repo bust (Corey Bryant)
> 38. Re: [infra][tripleo] initial discussion for a new periodic
> pipeline (Jeremy Stanley)
> 39. [requirements] pycrypto is dead, long live pycryptodome... or
> cryptography... (Matthew Thode)
> 40. Re: [cinder][glance][horizon][keystone][nova][qa][swift]
> Feedback needed: Removal of legacy per-project vanity domain
> redirects (Andreas Jaeger)
> 41. [kolla] kolla 4.0.0.0rc2 (ocata) (no-reply at openstack.org)
> 42. Re: [requirements] pycrypto is dead, long live
> pycryptodome... or cryptography... (Davanum Srinivas)
> 43. [kolla] kolla-ansible 4.0.0.0rc2 (ocata) (no-reply at openstack.org)
> 44. Re: [cinder][glance][horizon][keystone][nova][qa][swift]
> Feedback needed: Removal of legacy per-project vanity domain
> redirects (Steve Martinelli)
> 45. Re: [requirements] pycrypto is dead, long live
> pycryptodome... or cryptography... (Matthew Thode)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 8 Mar 2017 20:22:29 +0800
> From: Zhipeng Huang <zhipengh512 at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [acceleration] No team meeting today, resume
> next Wed
> Message-ID:
> <CAHZqm+VCPs-yU5_EQp41VS4Pm2Va9pqe4nuOK=r5cLnuxLLuSg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi team,
>
> As agreed per our PTG/VTG session, we will have the team meeting two weeks
> after to give people enough time to prepare the BPs we discussed.
>
> Therefore there will be no team meeting today, and the next meeting is on
> next Wed.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170308/813cb6b7/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 8 Mar 2017 13:40:37 +0100
> From: Dmitry Tantsur <dtantsur at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [ironic] OpenStack client default ironic
> API version
> Message-ID: <f33ad8bf-73ef-bfe6-61d4-7f6ec03f8758 at redhat.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 03/07/2017 04:59 PM, Loo, Ruby wrote:
> > On 2017-03-06, 3:46 PM, "Mario Villaplana" <mario.villaplana at gmail.com>
> wrote:
> >
> > Hi ironic,
> >
> > At the PTG, an issue regarding the default version of the ironic API
> > used in our python-openstackclient plugin was discussed. [0] In
> short,
> > the issue is that we default to a very old API version when the user
> > doesn't otherwise specify it. This limits discoverability of new
> > features and makes the client more difficult to use for deployments
> > running the latest version of the code.
> >
> > We came to the following consensus:
> >
> > 1. For a deprecation period, we should log a warning whenever the
> user
> > doesn't specify an API version, informing them of this change.
> >
> > 2. After the deprecation period:
> >
> > a) OSC baremetal plugin will default to the latest available version
> >
> > I think OSC and ironic CLI have the same behaviour -- are we only
> interested in OSC or are we interested in both, except that we also want to
> at some point soon perhaps, deprecate ironic CLI?
>
> I think we should only touch OSC, because of planned deprecation you
> mention.
>
> >
> > Also, by 'latest available version', the OSC plugin knows (or thinks it
> knows) what the latest version is [1]. Will you be using that, or 'latest'?
>
> It will pass "latest" to the API, so it may end up with a version the
> client
> side does not know about. This is intended, I think. It does have some
> consequences if we make breaking changes like removing parameters. As
> we're not
> overly keen on breaking changes anyway, this may not be a huge concern.
>
> >
> > b) Specifying just macroversion will default to latest microversion
> > within that macroversion (example: --os-baremetal-api-version=1 would
> > default to 1.31 if 1.31 is the last microversion with 1 macroversion,
> > even if we have API 2.2 supported)
> >
> > I have a patch up for review with the deprecation warning:
> > https://review.openstack.org/442153
> >
> > Do you have an RFE? I'd like a spec for this too please.
>
> Dunno if this change really requires a spec, but if you want one - let's
> have one :)
>
> We should have an RFE anyway, obviously.
>
> >
> > Please comment on that patch with any concerns.
> >
> > We also still have yet to decide what a suitable deprecation period
> is
> > for this change, as far as I'm aware. Please respond to this email
> > with any suggestions on the deprecation period.
> >
> > Thanks,
> > Mario
> >
> >
> > [0] https://etherpad.openstack.org/p/ironic-pike-ptg-operations L30
> >
> > Thank YOU!
> >
> > --ruby
> >
> > [1] https://github.com/openstack/python-ironicclient/blob/
> f242c6af3b295051019aeabb4ec7cf82eb085874/ironicclient/osc/plugin.py#L29
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 08 Mar 2017 07:52:23 -0500
> From: Doug Hellmann <doug at doughellmann.com>
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [release][tripleo][fuel][kolla][ansible]
> Ocata Release countdown for R+2 Week, 6-10 March
> Message-ID: <1488977242-sup-5435 at lrrr.local>
> Content-Type: text/plain; charset=UTF-8
>
> Excerpts from Vladimir Kuklin's message of 2017-03-08 01:20:21 +0300:
> > Doug
> >
> > I have proposed the change for Fuel RC2 [0], but it has W-1 set as I am
> > waiting for the final tests result. If everything goes alright, I will
> > check the Worfklow off and this RC2 can be the cut as the release.
>
> I've approved the RC2 tag and prepared
> https://review.openstack.org/443116 with the final release tag. Please
> +1 if that looks OK. I will approve it tomorrow.
>
> Doug
>
> >
> > [0] https://review.openstack.org/#/c/442775/
> >
> > On Tue, Mar 7, 2017 at 3:39 AM, Jeffrey Zhang <zhang.lei.fly at gmail.com>
> > wrote:
> >
> > > Sorry for late. But Kolla project need a new release candidate. I will
> > > push it today.
> > >
> > > On Tue, Mar 7, 2017 at 6:27 AM, Doug Hellmann <doug at doughellmann.com>
> > > wrote:
> > >
> > >> Excerpts from Doug Hellmann's message of 2017-03-06 11:00:15 -0500:
> > >> > Excerpts from Doug Hellmann's message of 2017-03-02 18:24:12 -0500:
> > >> > >
> > >> > > Release Tasks
> > >> > > -------------
> > >> > >
> > >> > > Liaisons for cycle-trailing projects should prepare their final
> > >> > > release candidate tags by Monday 6 March. The release team will
> > >> > > prepare a patch showing the final release versions on Wednesday 7
> > >> > > March, and PTLs and liaisons for affected projects should +1. We
> > >> > > will then approve the final releases on Thursday 8 March.
> > >> >
> > >> > We have 13 cycle-trailing deliverables without final releases for
> Ocata.
> > >> > All have at least one release candidate, so if no new release
> candidates
> > >> > are proposed *today* I will prepare a patch using these versions as
> the
> > >> > final and we will approve that early Wednesday.
> > >> >
> > >> > If you know that you need a new release candidate, please speak up
> now.
> > >> >
> > >> > If you know that you do not need a new release candidate, please
> also
> > >> > let me know that.
> > >> >
> > >> > Thanks!
> > >> > Doug
> > >> >
> > >> > $ list-deliverables --series ocata --missing-final -v
> > >> > fuel fuel 11.0.0.0rc1
> other
> > >> cycle-trailing
> > >> > instack-undercloud tripleo 6.0.0.0rc1 other
> > >> cycle-trailing
> > >> > kolla-ansible kolla 4.0.0.0rc1 other
> > >> cycle-trailing
> > >> > kolla kolla 4.0.0.0rc1 other
> > >> cycle-trailing
> > >> > openstack-ansible OpenStackAnsible 15.0.0.0rc1
> other
> > >> cycle-trailing
> > >> > os-apply-config tripleo 6.0.0.0rc1 other
> > >> cycle-with-milestones
> > >> > os-cloud-config tripleo 6.0.0.0rc1 other
> > >> cycle-with-milestones
> > >> > os-collect-config tripleo 6.0.0.0rc1 other
> > >> cycle-with-milestones
> > >> > os-net-config tripleo 6.0.0.0rc1 other
> > >> cycle-with-milestones
> > >> > os-refresh-config tripleo 6.0.0.0rc1 other
> > >> cycle-with-milestones
> > >> > tripleo-heat-templates tripleo 6.0.0.0rc1 other
> > >> cycle-trailing
> > >> > tripleo-image-elements tripleo 6.0.0.0rc1 other
> > >> cycle-trailing
> > >> > tripleo-puppet-elements tripleo 6.0.0.0rc1 other
> > >> cycle-trailing
> > >> >
> > >>
> > >> I have lined up patches with the final release tags for all 3
> projects.
> > >> Please review and +1 or propose a new patch with an updated release
> > >> candidate.
> > >>
> > >> Ansible: https://review.openstack.org/442138
> > >> Kolla: https://review.openstack.org/442137
> > >> TripleO: https://review.openstack.org/442129
> > >>
> > >> Doug
> > >>
> > >> ____________________________________________________________
> > >> ______________
> > >> OpenStack Development Mailing List (not for usage questions)
> > >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscrib
> > >> e
> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >>
> > >
> > >
> > >
> > > --
> > > Regards,
> > > Jeffrey Zhang
> > > Blog: http://xcodest.me
> > >
> > > ____________________________________________________________
> ______________
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> >
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 8 Mar 2017 08:25:21 -0500
> From: Ian Cordasco <sigmavirus24 at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [tc][appcat][murano][app-catalog] The
> future of the App Catalog
> Message-ID:
> <CAORZOQZ-ZC4x9sd=E12v8+4Tj+v6yoFnEJDWpc=bq4m3tSmefw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> -----Original Message-----
> From:?Christopher Aedo <doc at aedo.net>
> Reply:?OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Date:?March 7, 2017 at 22:11:22
> To:?OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Subject:? Re: [openstack-dev] [tc][appcat][murano][app-catalog] The
> future of the App Catalog
>
> > On Mon, Mar 6, 2017 at 3:26 AM, Thierry Carrez wrote:
> > > Hello everyone,
> > >
> > > The App Catalog was created early 2015 as a marketplace of pre-packaged
> > > applications that you can deploy using Murano. Initially a demo by
> > > Mirantis, it was converted into an open upstream project team, and
> > > deployed as a "beta" as apps.openstack.org.
> > >
> > > Since then it grew additional categories (Glance images, Heat & Tosca
> > > templates), but otherwise did not pick up a lot of steam. The website
> > > (still labeled "beta") features 45 glance images, 6 Tosca templates, 13
> > > heat templates and 94 murano packages (~30% of which are just thin
> > > wrappers around Docker containers). Traffic stats show around 100
> visits
> > > per week, 75% of which only read the index page.
> > >
> > > In parallel, Docker developed a pretty successful containerized
> > > application marketplace (the Docker Hub), with hundreds of thousands of
> > > regularly-updated apps. Keeping the App Catalog around (including its
> > > thinly-wrapped Docker container Murano packages) make us look like we
> > > are unsuccessfully trying to compete with that ecosystem, while
> > > OpenStack is in fact completely complementary.
> >
> > Without something like Murano "thinly wrapping" docker apps, how would
> > you propose current users of OpenStack clouds deploy docker apps? Or
> > any other app for that matter? It seems a little unfair to talk about
> > murano apps this way when no reasonable alternative exists for easily
> > deploying docker apps. When I look back at the recent history of how
> > we've handled containers (nova-docker, magnum, kubernetes, etc) it
> > does not seem like we're making it easy for the folks who want to
> > deploy a container on their cloud...
> >
> > Please understand I am not pleading to keep the Community App Catalog
> > alive in perpetuity. This just sounds like an unfair point of
> > comparison. One of the biggest challenges we've faced with the app
> > catalog since day one is that there is no such thing as a simple
> > definition of an "OpenStack Application". OpenStack is an IaaS before
> > anything else, and to my knowledge there is no universally accepted
> > application deployment mechanism for OpenStack clouds. Heat doesn't
> > solve that problem as its very operator focused, and while being very
> > popular and used heavily, it's not used as a way to share generic
> > templates suitable for deploying apps across different clouds. Murano
> > is not widely adopted (last time I checked it's not available on any
> > public clouds, though I hear it is actually used on a several
> > university clouds, and it's also used on a few private clouds I'm
> > aware of.)
> >
> > As a place to find things that run on OpenStack clouds, the app
> > catalog did a reasonable job. If anything, the experiment showed that
> > there is no community looking for a place to share OpenStack-specific
> > applications. There are definitely communities for PaaS layers (cloud
> > foundry, mesosphere, docker, kubernetes), but I don't see any
> > community for openstack-native applications that can be deployed on
> > any cloud, nor a commonly accepted way to deploy them.
> >
> > > In the past we have retired projects that were dead upstream. The App
> > > Catalog is not in this case: it has an active maintenance team, which
> > > has been successfully maintaining the framework and accepting
> > > applications. If we end up retiring the App Catalog, it would clearly
> > > not be a reflection on that team performance, which has been stellar
> > > despite limited resources. It would be because the beta was arguably
> not
> > > successful in building an active marketplace of applications, and
> > > because its continuous existence is not a great fit from a strategy
> > > perspective. Such removal would be a first for our community, but I
> > > think it's now time to consider it.
> > >
> > > Before we discuss or decide anything at the TC level, I'd like to
> > > collect everyone thoughts (and questions) on this. Please feel free to
> > > reply to this thread (or reach out to me privately if you prefer).
> Thanks !
> >
> > As the former PTL I am obviously a little bit biased. Even though my
> > focus has shifted and I've stepped away from the app catalog, I had
> > been spending a lot of time trying to figure out how to make
> > applications an easy to run thing on OpenStack. I've also been trying
> > to find a community of people who are looking for that, and it doesn't
> > seem like they've materialized; possibly because that community
> > doesn't exist? Or else we just haven't been able to figure out where
> > they're hiding ;)
> >
> > The one consideration that is pretty important here is what this would
> > mean to the Murano community. Those folks have been contributed time
> > and resources to the app catalog project. They've also standardized
> > on the app catalog as the distribution mechanism, intending to make
> > the app catalog UI a native component for Murano. We do need to make
> > sure that if the app catalog is retired, it doesn't hamper or impact
> > people who have already deployed Murano and are counting on finding
> > the apps in the app catalog.
>
> All of this is true. But Murano still doesn't have a stable way to
> store artifacts. In fact, it seems like Murano relies on a lot of
> unstable OpenStack infrastructure. While lots of people have
> contributed time, energy, sweat, and tears to the project there are
> still plenty of things that make Murano less than desirable. Perhaps
> that's why the project has found so few adopters. I'm sure there are
> plenty of people who want to use an OpenStack cloud to deploy
> applications. In fact, I know there are companies that try to provide
> that kind of support via Heat templates. All that said, I don't think
> allowing for competition with Murano is a bad thing.
>
> --
> Ian Cordasco
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 8 Mar 2017 13:27:12 +0000
> From: gordon chung <gord at live.ca>
> To: "openstack-dev at lists.openstack.org"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [telemetry][requirements] ceilometer
> grenade gate failure
> Message-ID:
> <BN6PR16MB1697E72DC578DC1FD8C24E6ADE2E0 at BN6PR16MB1697.
> namprd16.prod.outlook.com>
>
> Content-Type: text/plain; charset="Windows-1252"
>
>
>
> On 07/03/17 11:16 PM, Tony Breeds wrote:
> > Sure.
> >
> > I've approved it but it's blocked behind https://review.openstack.org/#
> /c/442886/1
>
> awesome! thanks Tony!
>
> cheers,
>
> --
> gord
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 8 Mar 2017 09:01:00 -0500
> From: Harm Sluiman <harm.sluiman at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [acceleration] No team meeting today,
> resume next Wed
> Message-ID: <DC117932-5897-4A7F-B521-522E06D2115F at gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
> Thanks for the update. Unfortunately I could not attend and can't seem to
> find a summary or anything about what took place. A pointer would be
> appreciated please ;-)
>
> Thanks for your time
> Harm Sluiman
> harm.sluiman at gmail.com
>
>
> > On Mar 8, 2017, at 7:22 AM, Zhipeng Huang <zhipengh512 at gmail.com> wrote:
> >
> > Hi team,
> >
> > As agreed per our PTG/VTG session, we will have the team meeting two
> weeks after to give people enough time to prepare the BPs we discussed.
> >
> > Therefore there will be no team meeting today, and the next meeting is
> on next Wed.
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 8 Mar 2017 09:03:21 -0500
> From: "Amrith Kumar" <amrith.kumar at gmail.com>
> To: <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [trove] today weekly meeting
> Message-ID: <00bf01d29814$bf3fe810$3dbfb830$@gmail.com>
> Content-Type: text/plain; charset="us-ascii"
>
> While I try to schedule my life to not conflict with the weekly Trove
> meeting, it appears that Wednesday afternoon at 1pm is a particularly
> popular time for people to want to meet me.
>
>
>
> This week, and next week are no exception. While I'd tried to avoid these
> conflicts, I've managed to be unable to do it (again).
>
>
>
> Nikhil (slicknik) has kindly agreed to run the meeting today, same place,
> same time as always.
>
>
>
> Thanks Nikhil.
>
>
>
> -amrith
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170308/f20b7aec/attachment-0001.html>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 8 Mar 2017 09:03:27 -0500
> From: Corey Bryant <corey.bryant at canonical.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Cc: openstack <openstack at lists.openstack.org>
> Subject: Re: [openstack-dev] [kolla][ubuntu][libvirt] Is libvirt 2.5.0
> in ubuntu cloud archive ocata repo bust
> Message-ID:
> <CADn0iZ2udvnhnDiwFSG90frHBncCFN6X0ZwBvXRTCFpoh2_reg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Tue, Mar 7, 2017 at 10:28 PM, Jeffrey Zhang <zhang.lei.fly at gmail.com>
> wrote:
>
> > Kolla deploy ubuntu gate is red now. here is the related bug[0].
> >
> > libvirt failed to access the console.log file when booting instance.
> After
> > made some debugging, i got following.
> >
> >
> Jeffrey, This is likely fixed in ocata-proposed and should be promoted to
> ocata-updates soon after testing completes.
> https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1667033.
>
> Corey
>
>
> # how console.log works
> > nova create a empty console.log with nova:nova ( this is another bug
> > workaround actually[1]), then libvirt ( running with root ) will change
> the
> > file owner to qemu process user/group ( configured by dynamic_ownership
> ).
> > Now qemu process can write logs into this file.
> >
> > # what's wrong now
> > libvirt 2.5.0 stop change the file owner, then qemu/libvirt failed to
> write
> > logs into console.log file
> >
> > # other test
> >
> > * ubuntu + fallback libvirt 1.3.x works [2]
> > * ubuntu + libvirt 2.5.0 + chang the qemu process user/group to
> > nova:nova works, too.[3]
> > * centos + libvirt 2.0.0 works, never saw such issue in centos.
> >
> > # conclusion
> > I guess there are something wrong in libvirt 2.5.0 with dynamic_ownership
> >
> >
> > [0] https://bugs.launchpad.net/kolla-ansible/+bug/1668654
> > [1] https://github.com/openstack/nova/blob/master/
> > nova/virt/libvirt/driver.py#L2922,L2952
> > [2] https://review.openstack.org/442673
> > [3] https://review.openstack.org/442850
> >
> > --
> > Regards,
> > Jeffrey Zhang
> > Blog: http://xcodest.me
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170308/d6d12817/attachment-0001.html>
>
> ------------------------------
>
> Message: 9
> Date: Wed, 8 Mar 2017 09:05:07 -0500
> From: Mario Villaplana <mario.villaplana at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [ironic] OpenStack client default ironic
> API version
> Message-ID:
> <CAHii5L4CVPRz=g==5rQHp_Nq6i_LNZbfCKEFGq_dhjjqytmt3Q at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> We want to deprecate ironic CLI soon, but I would prefer if that were
> discussed on a separate thread if possible, aside from concerns about
> versioning in ironic CLI. Feature parity should exist in Pike, then we
> can issue a warning in Queens and deprecate the cycle after. More
> information is on L56:
> https://etherpad.openstack.org/p/ironic-pike-ptg-operations
>
> I'm a bit torn on whether to use the API version coded in the OSC
> plugin or not. On one hand, it'd be good to be able to test out new
> features as soon as they're available. On the other hand, it's
> possible that the client won't know how to parse certain items after a
> microversion bump. I think I prefer using the hard-coded version to
> avoid breakage, but we'd have to be disciplined about updating the
> client when the API version is bumped (if needed). Opinions on this
> are welcome. In either case, I think the deprecation warning could
> land without specifying that.
>
> I'll certainly make an RFE when I update the patch later this week,
> great suggestion.
>
> I can make a spec, but it might be mostly empty except for the client
> impact section. Also, this is a < 40 line change. :)
>
> Mario
>
> On Tue, Mar 7, 2017 at 10:59 AM, Loo, Ruby <ruby.loo at intel.com> wrote:
> > On 2017-03-06, 3:46 PM, "Mario Villaplana" <mario.villaplana at gmail.com>
> wrote:
> >
> > Hi ironic,
> >
> > At the PTG, an issue regarding the default version of the ironic API
> > used in our python-openstackclient plugin was discussed. [0] In
> short,
> > the issue is that we default to a very old API version when the user
> > doesn't otherwise specify it. This limits discoverability of new
> > features and makes the client more difficult to use for deployments
> > running the latest version of the code.
> >
> > We came to the following consensus:
> >
> > 1. For a deprecation period, we should log a warning whenever the
> user
> > doesn't specify an API version, informing them of this change.
> >
> > 2. After the deprecation period:
> >
> > a) OSC baremetal plugin will default to the latest available version
> >
> > I think OSC and ironic CLI have the same behaviour -- are we only
> interested in OSC or are we interested in both, except that we also want to
> at some point soon perhaps, deprecate ironic CLI?
> >
> > Also, by 'latest available version', the OSC plugin knows (or thinks it
> knows) what the latest version is [1]. Will you be using that, or 'latest'?
> >
> > b) Specifying just macroversion will default to latest microversion
> > within that macroversion (example: --os-baremetal-api-version=1 would
> > default to 1.31 if 1.31 is the last microversion with 1 macroversion,
> > even if we have API 2.2 supported)
> >
> > I have a patch up for review with the deprecation warning:
> > https://review.openstack.org/442153
> >
> > Do you have an RFE? I'd like a spec for this too please.
> >
> > Please comment on that patch with any concerns.
> >
> > We also still have yet to decide what a suitable deprecation period
> is
> > for this change, as far as I'm aware. Please respond to this email
> > with any suggestions on the deprecation period.
> >
> > Thanks,
> > Mario
> >
> >
> > [0] https://etherpad.openstack.org/p/ironic-pike-ptg-operations L30
> >
> > Thank YOU!
> >
> > --ruby
> >
> > [1] https://github.com/openstack/python-ironicclient/blob/
> f242c6af3b295051019aeabb4ec7cf82eb085874/ironicclient/osc/plugin.py#L29
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 10
> Date: Wed, 8 Mar 2017 23:16:54 +0900
> From: Hirofumi Ichihara <ichihara.hirofumi at lab.ntt.co.jp>
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [neutron] [infra] Depends-on tag effect
> Message-ID: <00bc73ee-06bc-76e2-ea11-dd0b0a321314 at lab.ntt.co.jp>
> Content-Type: text/plain; charset=iso-2022-jp; format=flowed;
> delsp=yes
>
> Hi,
>
> I thought that we can post neutron patch depending on neutron-lib patch
> under review.
> However, I saw it doesn't work[1, 2]. In the patches, neutron patch[1]
> has Depends-on tag with neutron-lib patch[2] but the pep8 and unit test
> fails because the test doesn't use the neutron-lib patch.
>
> Please correct me if it's my misunderstanding.
>
> [1]: https://review.openstack.org/#/c/424340/
> [2]: https://review.openstack.org/#/c/424868/
>
> Thanks,
> Hirofumi
>
>
>
>
>
> ------------------------------
>
> Message: 11
> Date: Wed, 8 Mar 2017 08:33:16 -0600
> From: Matt Riedemann <mriedemos at gmail.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova] Question to clarify versioned
> notifications
> Message-ID: <3e95e057-b332-6c65-231b-f26001f6d5a8 at gmail.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 3/8/2017 4:19 AM, Balazs Gibizer wrote:
> >
> > Honestly, If searchlight needs to be adapted to the versioned
> > notifications then the smallest thing to change is to handle the removed
> > prefix from the event_type. The biggest difference is the format and the
> > content of the payload. In the legacy notifications the payload was a
> > simply json dict in the versioned notification the payload is a json
> > serialized ovo. Which means quite a different data structure. E.g. extra
> > keys, deeper nesting, etc.
> >
> > Cheers,
> > gibi
> >
>
> Heh, yeah, I agree. Thanks for the confirmation and details. I was just
> making sure I had this all straight since I was jumping around from
> specs and docs and code quite a bit yesterday piecing this together and
> wanted to make sure I had it straight. Plus you don't apparently work 20
> hours a day gibi so I couldn't ask you in IRC. :)
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
> ------------------------------
>
> Message: 12
> Date: Wed, 8 Mar 2017 15:40:53 +0100
> From: ZZelle <zzelle at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron] [infra] Depends-on tag effect
> Message-ID:
> <CAMS-DWhB3PWdoCLFsOx5ss7eYSa7dMsWr-6+R=FuOmDMGjvaYw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> iiuc, neutron uses a released version of neutron-lib not neutron-lib master
> ... So the change should depends on a change in requirements repo
> incrementing neutron-lib version
>
> On Wed, Mar 8, 2017 at 3:16 PM, Hirofumi Ichihara <
> ichihara.hirofumi at lab.ntt.co.jp> wrote:
>
> > Hi,
> >
> > I thought that we can post neutron patch depending on neutron-lib patch
> > under review.
> > However, I saw it doesn't work[1, 2]. In the patches, neutron patch[1]
> has
> > Depends-on tag with neutron-lib patch[2] but the pep8 and unit test fails
> > because the test doesn't use the neutron-lib patch.
> >
> > Please correct me if it's my misunderstanding.
> >
> > [1]: https://review.openstack.org/#/c/424340/
> > [2]: https://review.openstack.org/#/c/424868/
> >
> > Thanks,
> > Hirofumi
> >
> >
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170308/64fe77fc/attachment-0001.html>
>
> ------------------------------
>
> Message: 13
> Date: Wed, 8 Mar 2017 09:41:05 -0500
> From: Jay Pipes <jaypipes at gmail.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [tc][appcat] The future of the App
> Catalog
> Message-ID: <c8147907-6d4b-6bac-f9b3-6b8b07d75494 at gmail.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 03/06/2017 06:26 AM, Thierry Carrez wrote:
> > Hello everyone,
> >
> > The App Catalog was created early 2015 as a marketplace of pre-packaged
> > applications that you can deploy using Murano. Initially a demo by
> > Mirantis, it was converted into an open upstream project team, and
> > deployed as a "beta" as apps.openstack.org.
> >
> > Since then it grew additional categories (Glance images, Heat & Tosca
> > templates), but otherwise did not pick up a lot of steam. The website
> > (still labeled "beta") features 45 glance images, 6 Tosca templates, 13
> > heat templates and 94 murano packages (~30% of which are just thin
> > wrappers around Docker containers). Traffic stats show around 100 visits
> > per week, 75% of which only read the index page.
> >
> > In parallel, Docker developed a pretty successful containerized
> > application marketplace (the Docker Hub), with hundreds of thousands of
> > regularly-updated apps. Keeping the App Catalog around (including its
> > thinly-wrapped Docker container Murano packages) make us look like we
> > are unsuccessfully trying to compete with that ecosystem, while
> > OpenStack is in fact completely complementary.
> >
> > In the past we have retired projects that were dead upstream. The App
> > Catalog is not in this case: it has an active maintenance team, which
> > has been successfully maintaining the framework and accepting
> > applications. If we end up retiring the App Catalog, it would clearly
> > not be a reflection on that team performance, which has been stellar
> > despite limited resources. It would be because the beta was arguably not
> > successful in building an active marketplace of applications, and
> > because its continuous existence is not a great fit from a strategy
> > perspective. Such removal would be a first for our community, but I
> > think it's now time to consider it.
> >
> > Before we discuss or decide anything at the TC level, I'd like to
> > collect everyone thoughts (and questions) on this. Please feel free to
> > reply to this thread (or reach out to me privately if you prefer).
> Thanks !
>
> Mirantis' position is that the App Catalog was a good idea, but we agree
> with you that other application repositories like DockerHub and Quay.io
> are both more useful and more actively used.
>
> The OpenStack App Catalog does indeed seem to unnecessarily compete with
> those application repositories, and we would support its retirement if
> that is what the community would like to do. We'll provide resources and
> help in winding anything down if needed.
>
> Best,
> -jay
>
>
>
> ------------------------------
>
> Message: 14
> Date: Wed, 8 Mar 2017 14:59:41 +0000
> From: Yu Wei <yu2003w at hotmail.com>
> To: "openstack-dev at lists.openstack.org"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [nova][placement-api] Is there any document
> about openstack-placement-api for installation and configure?
> Message-ID:
> <HK2PR03MB0561E869146E75415BAD8DFBB52E0 at HK2PR03MB0561.
> apcprd03.prod.outlook.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Guys,
> I'm new to openstack.
> I tried to install openstack-ocata.
> As placement-api is required since Ocata, is there any detailed document
> about how to install and configure placement-api?
>
> Thanks,
> Jared
>
>
> ------------------------------
>
> Message: 15
> Date: Wed, 8 Mar 2017 15:59:59 +0100
> From: Andreas Jaeger <aj at suse.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron] [infra] Depends-on tag effect
> Message-ID: <c141c37b-53df-0983-5857-9980b6e2b16e at suse.com>
> Content-Type: text/plain; charset="windows-1252"
>
> On 2017-03-08 15:40, ZZelle wrote:
> > Hi,
> >
> > iiuc, neutron uses a released version of neutron-lib not neutron-lib
> > master ... So the change should depends on a change in requirements repo
> > incrementing neutron-lib version
>
> This is documented also at - together with some other caveats:
>
> https://docs.openstack.org/infra/manual/developers.html#
> limitations-and-caveats
>
>
> Note a depends-on requirements won't work either - you really need to
> release it. Or you need to change the test to pull neutron-lib from source,
>
> Andreas
> >
> > On Wed, Mar 8, 2017 at 3:16 PM, Hirofumi Ichihara
> > <ichihara.hirofumi at lab.ntt.co.jp
> > <mailto:ichihara.hirofumi at lab.ntt.co.jp>> wrote:
> >
> > Hi,
> >
> > I thought that we can post neutron patch depending on neutron-lib
> > patch under review.
> > However, I saw it doesn't work[1, 2]. In the patches, neutron
> > patch[1] has Depends-on tag with neutron-lib patch[2] but the pep8
> > and unit test fails because the test doesn't use the neutron-lib
> patch.
> >
> > Please correct me if it's my misunderstanding.
> >
> > [1]: https://review.openstack.org/#/c/424340/
> > <https://review.openstack.org/#/c/424340/>
> > [2]: https://review.openstack.org/#/c/424868/
> > <https://review.openstack.org/#/c/424868/>
> >
> > Thanks,
> > Hirofumi
> >
> >
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > <http://OpenStack-dev-request@lists.openstack.org?subject:
> unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> >
> >
> >
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
> GF: Felix Imend?rffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG N?rnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
>
>
>
> ------------------------------
>
> Message: 16
> Date: Wed, 8 Mar 2017 10:05:45 -0500
> From: James Slagle <james.slagle at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [TripleO][Heat] Selectively disabling
> deployment resources
> Message-ID:
> <CAHV77z-JdSvgfUc7RORCXmz13kcRGR5u2grtX+MyZR-dPKV0Ug at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, Mar 7, 2017 at 7:24 PM, Zane Bitter <zbitter at redhat.com> wrote:
> > On 07/03/17 14:34, James Slagle wrote:
> >>
> >> I've been working on this spec for TripleO:
> >> https://review.openstack.org/#/c/431745/
> >>
> >> which allows users to selectively disable Heat deployment resources
> >> for a given server (or server in the case of a *DeloymentGroup
> >> resource).
> >
> >
> > I'm not completely clear on what this means. You can selectively disable
> > resources with conditionals. But I think you mean that you want to
> > selectively disable *changes* to resources?
>
> Yes, that's right. The reason I can't use conditionals is that I still
> want the SoftwareDeploymentGroup resources to be updated, but I may
> want to selectively exclude servers from the group that is passed in
> via the servers property. E.g., instead of updating the deployment
> metadata for *all* computes, I may want to exclude a single compute
> that is temporarily unreachable, without that failing the whole
> stack-update.
>
> >> I started by taking an approach that would be specific to TripleO.
> >> Basically mapping all the deployment resources to a nested stack
> >> containing the logic to selectively disable servers from the
> >> deployment (using yaql) based on a provided parameter value. Here's
> >> the main patch: https://review.openstack.org/#/c/442681/
> >>
> >> After considering that complexity, particularly the yaql expression,
> >> I'm wondering if it would be better to add this support natively to
> >> Heat.
> >>
> >> I was looking at the restricted_actions key in the resource_registry
> >> and was thinking this might be a reasonable place to add such support.
> >> It would require some changes to how restricted_actions work.
> >>
> >> One change would be a method for specifying that restricted_actions
> >> should not fail the stack operation if an action would have otherwise
> >> been triggered. Currently the behavior is to raise an exception and
> >> mark the stack failed if an action needs to be taken but has been
> >> marked restricted. That would need to be tweaked to allow specifying
> >> that that we don't want the stack to fail. One thought would be to
> >> change the allowed values of restricted_actions to:
> >>
> >> replace_fail
> >> replace_ignore
> >> update_fail
> >> update_ignore
> >> replace
> >> update
> >>
> >> where replace and update were synonyms for replace_fail/update_fail to
> >> maintain backwards compatibility.
> >
> >
> > Anything that involves the resource definition in the template changing
> but
> > Heat not modifying the resource is problematic, because that messes with
> > Heat's internal bookkeeping.
>
> I don't think this case would violate that principle. The template +
> environment files would match what Heat has done. After an update, the
> 2 would be in sync as to what servers the updated Deployment resource
> was triggered.
>
> >
> >> Another change would be to add logic to the Deployment resources
> >> themselves to consider if any restricted_actions have been set on an
> >> Server resources before triggering an updated deployment for a given
> >> server.
> >
> >
> > Why not just a property, "no_new_deployments_please: true"?
>
> That would actually work and be pretty straightforward I think. We
> could have a map parameter with server names and the property that the
> user could use to set the value.
>
> The reason why I was initially not considering this route was because
> it doesn't allow the user to disable only some deployments for a given
> server. It's all or nothing. However, it's much simpler than a totally
> flexible option, and it addresses 2 of the largest use cases of this
> feature. I'll look into this route a bit more.
>
> --
> -- James Slagle
> --
>
>
>
> ------------------------------
>
> Message: 17
> Date: Wed, 8 Mar 2017 16:06:59 +0100
> From: Dmitry Tantsur <dtantsur at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [ironic] Pike PTG report
> Message-ID: <23821f81-9509-3600-6b9c-693984aa0132 at redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi all!
>
> I've finished my Pike PTG report. It is spread over four blog posts:
>
> http://dtantsur.github.io/posts/ironic-ptg-atlanta-2017-1.html
> http://dtantsur.github.io/posts/ironic-ptg-atlanta-2017-2.html
> http://dtantsur.github.io/posts/ironic-ptg-atlanta-2017-3.html
> http://dtantsur.github.io/posts/ironic-ptg-atlanta-2017-4.html
>
> It was a lot of typing, please pardon mistakes. The whole text (in RST
> format)
> for archiving purposes is copy-pasted in the end of this message.
>
> Please feel free to respond here or in the blog comments.
>
> Cheers,
> Dmitry
>
>
> Ongoing work and status updates
> -------------------------------
>
> Etherpad: https://etherpad.openstack.org/p/ironic-pike-ptg-ongoing-work.
>
> We spent the first half of Wednesday discussing this. There was a lot of
> incomplete work left from Ocata, and some major ongoing work that we did
> not
> even plan to finish in Ocata.
>
> Boot-from-volume
> ~~~~~~~~~~~~~~~~
>
> Got some progress, most of the Ironic patches are up. Desperately needs
> review
> and testing, though. The Nova part is also lagging behind, and should be
> brought to the Nova team attention.
>
> **Actions**
> **mgoddard** and **dtantsur** volunteered to help with testing, while
> **mjturek**, **hsiina** and **crushil** volunteered to do some coding.
> **Goals for Pike**
> finish the first (iSCSI using iPXE) case and the Nova part.
>
> Networking
> ~~~~~~~~~~
>
> A lot of progress here during Ocata, completed bonding and attach/detach
> API.
>
> VLAN-aware instances should work. However, it requires an expensive ToR
> switch,
> supporting VLAN/VLAN and VLAN/VXLAN rewriting, and, of course ML2 plugin
> support. Also, reusing an existing segmentation ID requires more work: we
> have
> no current way to put the right ID in the configdrive.
>
> **Actions**
> **vsaienko**, **armando** and **kevinbenton** are looking into the
> Neutron
> part of the configdrive problem.
>
> Routed networks support require Ironic to be aware of which physical
> network(s)
> each node is connected to.
>
> **Goals for Pike**
> * model physical networks on Ironic ports,
> * update VIF attach logic to no longer attach things to wrong
> physnets.
>
> We discussed introducing notifications from Neutron to Ironic about events
> of interest for us. We are going to use the same model as between Neutron
> and
> Nova: create a Neutron plugin that filters out interesting events and posts
> to a new Ironic API endpoint.
>
> **Goals for Pike**
> have this notification system in place.
>
> Finally, we agreed that we need to work on a reference architecture
> document,
> describing the best practices of deploying Ironic, especially around
> multi-tenant networking setup.
>
> **Actions**
> **jroll** to kickstart this document, **JayF** and **mariojv** to
> help.
>
> Rolling upgrades
> ~~~~~~~~~~~~~~~~
>
> Missed Ocata by a small margin. The code is up and needs reviewing. The CI
> is waiting for the multinode job to start working (should be close as
> well).
>
> **Goals for Pike**
> rolling upgrade Ocata -> Pike.
>
> Driver composition reform
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Most of the code landed in Ocata already. Some client changes landed in
> Pike,
> some are still on review. As we released Ocata with the driver composition
> changes being experimental, we are not ready to deprecate old-style
> drivers in
> Pike. Documentation is also still lacking.
>
> **Goals for Pike**
> * make new-style dynamic drivers the recommend way of writing and
> using
> drivers,
> * fill in missing documentation,
> * *recommend* vendors to have hardware types for their hardware, as
> well
> as 3rdparty CI support for it.
> **Important decisions**
> * no new classic drivers are accepted in-tree (please check when
> accepting
> specifications),
> * no new interfaces additions for classic
> drivers(``volume_interface`` is
> the last accepted from them),
> * remove the SSH drivers by Pike final (probably around M3).
>
> Ironic Inspector HA
> ~~~~~~~~~~~~~~~~~~~
>
> Preliminary work (switch to a real state machine) done in Ocata. Splitting
> the
> service into API and conductor/engine parts correlates with the WSGI
> cross-project goal.
>
> We also had a deeper discussion about ironic-inspector architecture earlier
> that week, where we were `looking
> <https://etherpad.openstack.org/p/ironic-pike-ptg-inspector-arch>`_ into
> potential future work to make ironic-inspector both HA and multi-tenancy
> friendly. It was suggested to split *discovery* process (simple process to
> detect MACs and/or power credentials) and *inspection* process (full
> process
> when a MAC is known).
>
> **Goals for Pike**
> * switch locking to ``tooz`` (with Redis probably being the default
> backend for now),
> * split away API process with WSGI support,
> * leader election using ``tooz`` for periodic tasks,
> * stop messing with ``iptables`` and start directly managing
> ``dnsmasq``
> instead (similarly to how Neutron does it),
> * try using ``dnsmasq`` in active/active configuration with
> non-intersecting IP addresses pools from the same subnet.
> **Actions**
> also **sambetts** will write a spec on a potential workflow split.
>
> Ironic UI
> ~~~~~~~~~
>
> The project got some important features implemented, and an RDO package
> emerged during Ocata. Still, it desperately needs volunteers for coding and
> testing. A `spreadsheet
> <https://docs.google.com/spreadsheets/d/1petifqVxOT70H2Krz7igV2m9YqgXa
> AiCHR8CXgoi9a0/edit?usp=sharing>`_
> captures the current (as of beginning of Pike) status of features.
>
> **Actions**
> **dtantsur**, **davidlenwell**, **bradjones** and **crushil** agreed
> to
> dedicate some time to the UI.
>
> Rescue
> ~~~~~~
>
> Most of the patches are up, the feature is tested with the CoreOS-based
> ramdisk for now. Still, the ramdisk side poses a problem: while using DHCP
> is
> easy, static network configuration seems not. It's especially problematic
> in
> CoreOS. Might be much easier in the DIB-based ramdisk, but we don't
> support it
> officially in the Ironic community.
>
> RedFish driver
> ~~~~~~~~~~~~~~
>
> We want to get a driver supporting RedFish soon. There was some critics
> raised
> around the currently proposed python-redfish library. As an alternative,
> `a new library <https://github.com/openstack/sushy>`_ was written. Is it
> lightweight, covered by unit tests and only contain what Ironic needs.
> We agreed to start our driver implementation with it, and switch to the
> python-redfish library when/if it is ready to be consumed by us.
>
> We postponed discussing advanced features like nodes composition till after
> we get the basic driver in.
>
> Small status updates
> ~~~~~~~~~~~~~~~~~~~~
>
> * Of the API evolution initiative, only E-Tag work got some progress. The
> spec
> needs reviewing now.
>
> * Node tags work needs review and is close to landing. We decided to
> discuss
> port tags as part of a separate RFE, if anybody is interested.
>
> * IPA API versioning also needs reviews, there are several moderately
> contentions points about it. It was suggested that we only support one
> direction of IPA/ironic upgrades to simplify testing. We'll probably
> only
> support old IPA with new ironic, which is already tested by our grenade
> job.
>
> CI and testing
> --------------
>
> Etherpad: https://etherpad.openstack.org/p/ironic-pike-ptg-ci-testing
>
> Missing CI coverage
> ~~~~~~~~~~~~~~~~~~~
>
> UEFI
> Cirros finally released a stable version with UEFI support built in.
> A non-voting job is running with partition images, should be made
> voting
> soon. A test with whole disk images will be introduced as part of
> `standalone tests <https://review.openstack.org/#/c/423556/>`_.
> Local bootloader
> Requires small enough instance images with Grub2 present (Cirros does
> not
> have it). We agreed to create a new repository with scripts to build
> suitable images. Potentially can be shared with other teams (e.g.
> Neutron).
>
> Actions: **lucasagomes** and/or **vsaienko** to look into it.
> Adopt state
> Tests have been up for some time, but have ordering issues with
> nova-based
> tests. Suggesting **TheJulia** to move them to `standalone tests`_.
> Root device hints
> Not covered by any CI. Will need modifying how we create virtual
> machines.
> First step is to get size-based hints work. Check two cases: with size
> strictly equal and greater than requested.
>
> Actions: **dtantsur** to look into it.
> Capabilities-based scheduling
> This may actually go to Nova gate, not ours. Still, it relies on some
> code
> in our driver, so we'd better cover it to ensure that the placement
> API
> changes don't break it.
>
> Actions: **vsaienko** to look into it.
> Port groups
> The same image problem as with local boot - the same action item to
> create
> a repository with build scripts to build our images.
> VLAN-aware instances
> The same image problem + requires `reworking our network simulation
> code
> <https://review.openstack.org/#/c/392959/>`_.
> Conductor take over and hash ring
> Requires a separate multi-node job.
>
> Action: **vsaienko** to investigate.
>
> DIB-based IPA image
> ^^^^^^^^^^^^^^^^^^^
>
> Currently the ``ironic-agent`` element to build such image is in the DIB
> repository outside of our control. If we want to properly support it, we
> need
> to gate on its changes, and to gate IPA changes on its job. Some time ago
> we
> had a tentative agreement to move the element to our tree.
>
> It was blocked by the fact that DIB rarely or never removes elements, and
> does
> not have a way to properly de-duplicate elements with the same name.
>
> An obvious solution we are going to propose is to take this element in IPA
> tree under a different name (``ironic-python-agent``?). The old element
> will
> get deprecated and only critical fixes will be accepted for it.
>
> Action
> **dtantsur** to (re)start this discussion with the TripleO and DIB
> teams.
>
> API microversions testing
> ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> We are not sure we have tests covering all microversions. We seem to have
> API
> tests using ``fake`` driver that cover at least some of them. We should
> start
> paying more attention to this part of our testing.
>
> Actions
> **dtantsur** to check if these tests are up-to-date and split them to
> a
> separate CI job.
> **pas-ha** to write API tests for internal API (i.e.
> lookup/heartbeat).
>
> Global OpenStack goals
> ~~~~~~~~~~~~~~~~~~~~~~
>
> Splitting away tempest plugins
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> It did not end up a goal for Pike, and there are still some concerns in the
> community. Still, as we already apply ugly hacks in our jobs to use the
> tempest plugin from master, we agreed to proceed with the split.
>
> To simplify both maintenance and consuming our tests, we agreed to merge
> ironic and ironic-inspector plugins. The introspection tests will or will
> not run based on ironic-inspector presence.
>
> We propose having a merged core team (i.e. ironic-inspector-core which
> already includes ironic-core) for this repository. We trust people who
> only have core rights on ironic-inspector to not approve things they're
> not authorized to approve.
>
> Python 3 support
> ^^^^^^^^^^^^^^^^
>
> We've been running Python 3 unit tests for quite some time. Additionally,
> ironic-inspector runs a non-voting Python 3 functional test. Ironic has an
> experimental job which fails, apparently, because of swift. We can start
> with
> switching this job to the ``pxe_ipmitool`` driver (not requiring swift).
> Inspector does not have a Python 3 integration tests job proposed yet.
>
> Actions
> **JayF** and **hurricanerix** will drive this work in both ironic and
> ironic-inspector.
>
> **lucasagomes** to check pyghmi and virtualbmc compatibility.
>
> **krtaylor** and/or **mjturek** to check MoltenIron.
>
> We agreed that Bifrost is out of scope for this task. Its Python 3
> compatibility mostly depends on one of Ansible anyway. Similarly, for the
> UI
> we need horizon to be fully Python 3 compatible first.
>
> Important decisions
> We recommend vendors to make their libraries compatible with Python 3.
> It may become a strict requirement in one of the coming releases.
>
> API behind WSGI container
> ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> This seems quite straightforward. The work has started to switch ironic CI
> to
> WSGI already. For ironic-inspector it's going to be done as part of the HA
> work.
>
> Operations
> ----------
>
> Etherpad: https://etherpad.openstack.org/p/ironic-pike-ptg-operations
>
> OSC plugin and API versioning
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Currently we default the OSC plugin (and old client too) to a really old
> API
> version. We agreed that this situation is not desired, and that we should
> take
> the same approach as Nova and default to the latest version. We are
> planning
> to announce the change this cycle, both via the ML and via a warning issues
> when no versions are specified.
>
> Next, in the Queens cycle, we will have to make the change, bearing in mind
> that OSC does not support values like ``latest`` for API versions. So the
> plan
> is as follows:
>
> * make the default ``--os-baremetal-api-version=1`` in
>
> https://github.com/openstack/python-ironicclient/blob/
> f242c6af3b295051019aeabb4ec7cf82eb085874/ironicclient/osc/plugin.py#L67
>
> * when instantiating the ironic client in the OSC plugin, replace '1' with
> 'latest':
>
> https://github.com/openstack/python-ironicclient/blob/
> f242c6af3b295051019aeabb4ec7cf82eb085874/ironicclient/osc/plugin.py#L41
>
> * when handling ``--os-baremetal-api-version=latest``, replace it with
> ``1``,
> so that it's later replaced with ``latest`` again:
>
> https://github.com/openstack/python-ironicclient/blob/
> f242c6af3b295051019aeabb4ec7cf82eb085874/ironicclient/osc/plugin.py#L85
>
> As a side effect, that will make ``1`` equivalent to ``latest`` as well.
>
> It was also suggested to have an new command, displaying both server
> supported
> and client supported API versions.
>
> Deprecating the standalone ironic CLI in favor of the OSC plugin
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> We do not want to maintain two CLI in the long run. We agreed to start
> thinking about deprecating the old ``ironic`` command. Main concerns:
>
> * lack of feature parity,
>
> * ugly way to work without authentication, for example::
>
> openstack baremetal --os-url http://ironic --os-token fake <COMMAND>
>
> Plan for Pike
> * Ensure complete feature parity between two clients.
> * Only use ``openstack baremetal`` commands in the documentation.
>
> The actual deprecation is planned for Queens.
>
> RAID configuration enhancements
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> A few suggestions were made:
>
> * Support ordered list of logical disk definition. The first possible
> configuration is applied to the node. For example:
>
> * Top of list - RAID 10 but we don't have enough drives
> * Fallback to next preference in list - RAID 1 on a pair of available
> drives
> * Finally, JBOD or RAID 0 on only available drive
>
> * Specify the number of instances for a logical disk definition to create.
>
> * Specify backing physical disks by stating preference for the smallest,
> e.g.
> smallest like-sized pair or two smallest disks.
>
> * Specify location of physical disks, e.g. first two or last two as
> perceived
> by the hardware, front/rear/internal location.
>
> Actions
> **rpioso** will write RFE(s)
>
> Smaller topics
> ~~~~~~~~~~~~~~
>
> Non-aborteable clean steps stuck in ``clean wait`` state
> We discussed a potential ``force-abort`` functionality, but the only
> thing
> we agreed on is check that all current clean steps are marked as
> ``abortable`` if they really are.
>
> Status of long-running cleaning operations
> There is a request to be able to get status of e.g. disk shredding
> (which
> may take hours). We found out that the current IPA API design
> essentially
> prevents running several commands in parallel. We agreed that we need
> IPA
> API versioning first, and that this work is not a huge priority right
> now.
>
> OSC command for listing driver and RAID properties
> We cannot agree on the exact form of these two commands. The primary
> candidates discussed on the PTG were::
>
> openstack baremetal driver property list <DRIVER>
> openstack baremetal driver property show <DRIVER>
>
> We agreed to move this to the spec: https://review.openstack.org/
> 439907.
>
> Abandoning an active node
> I.e. an opposite to adopt. It's unclear how such operation would play
> with
> nova, maybe it's only useful for a standalone case.
>
> Future Work
> -----------
>
> Etherpad: https://etherpad.openstack.org/p/ironic-pike-ptg-future-work.
>
> Neutron event processing
> ~~~~~~~~~~~~~~~~~~~~~~~~
>
> RFE: https://bugs.launchpad.net/ironic/+bug/1304673, spec:
> https://review.openstack.org/343684.
>
> We need to wait for certain events from neutron (like port bindings).
> Currently we just wait some time, and hope it went well. We agreed to
> follow
> the same pattern that nova does for neutron to nova notifications.
> The neutron part is
> https://github.com/openstack/neutron/blob/master/neutron/notifiers/nova.py
> .
> We agreed with the Neutron team that notifier and the other ironic-specific
> stuff for neutron would live in a separate repo under Baremetal governance.
> Draft code is https://review.openstack.org/#/c/357780.
>
> Splitting node.properties[capabilities] into a separate table
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> This is something we've planned on for long time. Currently, it's not
> possible
> to update capabilities atomically, and the format is quite hard to work
> with:
> ``k1:v1,k2:v2``. We discussed going away from using word ``capability``.
> It's
> already overused in the OpenStack world, and nova is switching to the
> notion
> of "traits". It also looks like traits will be qualitative-only while, we
> have
> proposals from quantitative capabilities (like ``gpu_count``).
>
> It was proposed to model a typical CRUD API for traits in Ironic::
>
> GET /v1/nodes/<NODE>/traits
> POST /v1/nodes/<NODE>/traits
> GET /v1/nodes/<NODE>/traits/<trait>
> DELETE /v1/nodes/<NODE>/traits/<trait>
>
> In API versions before this addition, we would make
> ``properties/capabilities`` a transparent proxy to new tables.
>
> It was noted that the database change can be done first, with API change
> following it.
>
> Actions
> **rloo** to propose two separate RFEs for database and API parts.
>
> Avoid changing behavior based on properties[capabilities]
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Currently our capabilities have a dual role. They serve both for scheduling
> (to inform nova of what nodes can) and for making decisions based on flavor
> (e.g. request UEFI boot). It is complicated by the fact that sometimes the
> same capability (e.g. UEFI) can be of both types depending on a driver.
> This is quite confusing for users, and may be incompatible with future
> changes
> both in ironic and nova.
>
> For things like boot option and (potentially) BIOS setting, we need to be
> able
> to get requests from flavors and/or nova boot arguments without abusing
> capabilities for it. Maybe similar to how NUMA support does it:
> https://docs.openstack.org/admin-guide/compute-cpu-topologies.html.
>
> For example::
>
> flavor.extra_specs[traits:has_ssd]=True
>
> (tells the scheduler to find a node with SSD disk; does not change
> behavior/config of node)
>
> ::
>
> flavor.extra_specs[configuration:use_uefi]=True
>
> (configures the node to boot UEFI; has no impact on scheduling)
>
> ::
>
> flavor.extra_specs[traits:has_uefi]=True
> flavor.extra_specs[configuration:use_uefi]=True
>
> (tells the scheduler to find a node supporting UEFI; if this support is
> dynamic, configures the node to enable UEFI boot).
>
> Actions
> **jroll** to start conversation with nova folks about how/if to have a
> replacement for this elsewhere.
>
> Stop accepting driver features relying on
> ``properties[capabilities]`` (as
> opposed to ``instance_info[capabilities]``).
>
> Potential actions
> * Remove ``instance_info[capabilities]`` into
> ``instance_info[configuration]`` for clarity.
>
> Deploy-time RAID
> ~~~~~~~~~~~~~~~~
>
> This was discussed on the last design summit. Since then we've got a `nova
> spec <https://review.openstack.org/408151>`_, which, however, hasn't got
> many
> reviews so far. The spec continues using ``block_device_mapping_v2``, other
> options apparently were not considered.
>
> We discussed how to inform Nova whether or not RAID can be built for
> a particular node. Ideally, we need to tell the scheduler about many
> things:
> RAID support, disk number, disk sizes. We decided that it's an overkill, at
> least for the beginning. We'll only rely on a "supports RAID" trait for
> now.
>
> It's still unclear what to do about ``local_gb`` property, but with planned
> Nova changes it may not be required any more.
>
> Advanced partitioning
> ~~~~~~~~~~~~~~~~~~~~~
>
> There is a desire for flexible partitioning in ironic, both in case of
> partition and whole disk images (in the latter case - partition other
> disks).
> Generally, there was no consensus on the PTG. Some people were very much in
> favor of this feature, some - quite against. It's unclear how to pass
> partitioning information from Nova. There is a concern that such feature
> will
> get us too much into OS-specific details. We agreed that someone interested
> will collect the requirements, create a more detailed proposal, and we'll
> discuss it on the next PTG.
>
> Splitting nodes into separate pools
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> This feature is about dedicating some nodes to a tenant, essentially
> adding a
> tenant_id field to nodes. This can be helpful e.g. for a hardware provider
> to
> reserve hardware for a tenant, so that it's always available.
>
> This seems relatively easy to implement in Ironic. We need a new field on
> nodes, then only show non-admin users their hardware. A bit trickier to
> make
> it work with Nova. We agreed to investigate passing a token from Nova to
> Ironic, as opposed to always using a service user admin token.
>
> Actions
> **vdrok** to work out the details and propose a spec.
>
> Requirements for routed networks
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> We discussed requirements for achieving routed architecture like
> spine-and-leaf. It seems that most of the requirements are already in our
> plans. The outstanding items are:
>
> * Multiple subnets support for ironic-inspector. Can be solved in
> ``dnsmasq.conf`` level, an appropriate change was merged into
> puppet-ironic.
>
> * Per-node provision and cleaning networks. There is an RFE, somebody just
> has to do the work.
>
> This does not seem to be a Pike goal for us, but many of the dependencies
> are planned for Pike.
>
> Configuring BIOS setting for nodes
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Preparing a node to be configured to serve a certain rule by tweaking its
> settings. Currently, it is implemented by the Drac driver in a vendor
> pass-thru.
>
> We agreed that such feature would better fit cleaning, rather then
> pre-deployment. Thus, it does not depend on deploy steps. It was suggested
> to
> extend the management interface to support passing it an arbitrary JSON
> with
> configuration. Then a clean step would pick it (similar to RAID).
>
> Actions
> **rpioso** to write a spec for this feature.
>
> Deploy steps
> ~~~~~~~~~~~~
>
> We discussed `the deploy steps proposal <https://review.openstack.org/
> 412523>`_
> in depth. We agreed on partially splitting the deployment procedure into
> pluggable bits. We will leave the very core of the deployment - flashing
> the
> image onto a target disk - hardcoded, at least for now. The drivers will be
> able to define steps to run before and after this core deployment. Pre- and
> post-deployment steps will have different priorities ranges, something
> like::
>
> 0 < pre-max/deploy-min < deploy-max/post-min < infinity
>
> We plan on making partitioning a pre-deploy step, and installing a
> bootloader
> a post-deploy step. We will not allow IPA hardware managers to define
> deploy
> steps, at least for now.
>
> Actions
> **yolanda** is planning to work on this feature, **rloo** and
> **TheJulia**
> to help.
>
> Authenticating IPA
> ~~~~~~~~~~~~~~~~~~
>
> IPA HTTP endpoints, and the endpoints Ironic provides for ramdisk callbacks
> are completely insecure right now. We hesitated to add any authentication
> to
> them, as any secrets published for the ramdisk to use (be it part of kernel
> command line or image itself) are readily available to anyone on the
> network.
>
> We agreed on several things to look into:
>
> * A random CSRF-like token to use for each node. This will somewhat limit
> the
> attack surface by requiring an attacker to intercept a token for the
> specific node, rather then just access the endpoints.
>
> * Document splitting out public and private Ironic API as part of our
> future
> reference architecture guide.
>
> * Make sure we support TLS between Ironic and IPA, which is particularly
> helpful when virtual media is used (and secrets are not leaked).
>
> Actions
> **jroll** and **joanna** to look into the random token idea.
> **jroll** to write an RFE for TLS between IPA and Ironic.
>
> Smaller things
> ~~~~~~~~~~~~~~
>
> Using ansible-networking as a ML2 driver for ironic-neutron integration
> work
> It was suggested to make it one of backends for
> ``networking-generic-switch`` in addition to ``netmiko``. Potential
> concurrency issues when using SSH were raised, and still require a
> solution.
>
> Extending and standardizing the list of capabilities the drivers may
> discover
> It was proposed to use `os-traits <https://github.com/jaypipes/
> os-traits>`_
> for standardizing qualitative capabilities. **jroll** will look into
> quantitative capabilities.
>
> Pluggable interface for long-running processes
> This was proposed as an optional way to mitigate certain problems with
> local long-running services, like console. E.g. if a conductor
> crashes,
> its console services keep running. It was noted that this is a bug to
> be
> fixed (**TheJulia** volunteered to triage it).
> The proposed solution involved optionally run processes on a remote
> cluster, e.g. k8s. Concerns were voiced on the PTG around complicating
> support matrix and adding more decisions to make for operators.
> There was no apparent consensus on implementing this feature due to
> that.
>
> Setting specific boot device for PXE booting
> It was found to be already solved by setting ``pxe_enabled`` on ports.
> We just need to update ironic-inspector to set this flag.
>
> Priorities and planning
> -----------------------
>
> The suggested priorities list is now finalized in
> https://review.openstack.org/439710.
>
> We also agreed on the following priorities for ironic-inspector subteam:
>
> * Inspector HA (**milan**)
> * Community goal - python 3.5 (**JayF**, **hurricanerix**)
> * Community goal - devstack+apache+wsgi (**aarefiev**, **ovoshchana**)
> * Inspector needs to update ``pxe_enabled`` flag on ports (**dtantsur**)
>
>
>
> ------------------------------
>
> Message: 18
> Date: Wed, 8 Mar 2017 15:07:06 +0000 (GMT)
> From: Chris Dent <cdent+os at anticdent.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][placement-api] Is there any
> document about openstack-placement-api for installation and configure?
> Message-ID: <alpine.OSX.2.20.1703081500570.59117 at shine.local>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On Wed, 8 Mar 2017, Yu Wei wrote:
>
> > I'm new to openstack.
> > I tried to install openstack-ocata.
> > As placement-api is required since Ocata, is there any detailed document
> > about how to install and configure placement-api?
>
> There are two different things which might be useful to you. Some
> nova "in-tree" docs about placement:
>
> https://docs.openstack.org/developer/nova/placement.html
> https://docs.openstack.org/developer/nova/placement_dev.html
>
> and some in progress documents about installing placement:
>
> https://review.openstack.org/#/c/438328/
>
> That latter has some errors that are in the process of being fixed,
> so make sure you read the associated comments.
>
> --
> Chris Dent ?\_(?)_/? https://anticdent.org/
> freenode: cdent tw: @anticdent
>
> ------------------------------
>
> Message: 19
> Date: Wed, 8 Mar 2017 09:12:59 -0600
> From: Monty Taylor <mordred at inaugust.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev]
> [cinder][glance][horizon][keystone][nova][qa][swift] Feedback needed:
> Removal of legacy per-project vanity domain redirects
> Message-ID: <9b5cf68a-39bf-5d33-2f4c-77c5f5ff7f78 at inaugust.com>
> Content-Type: text/plain; charset=utf-8
>
> Hey all,
>
> We have a set of old vanity redirect URLs from back when we made a URL
> for each project:
>
> cinder.openstack.org
> glance.openstack.org
> horizon.openstack.org
> keystone.openstack.org
> nova.openstack.org
> qa.openstack.org
> swift.openstack.org
>
> They are being served from an old server we'd like to retire. Obviously,
> moving a set of http redirects is trivial, but these domains have been
> deprecated for about 4 now, so we figured we'd clean house if we can.
>
> We know that the swift team has previously expressed that there are
> links out in the wild pointing to swift.o.o/content that still work and
> that they don't want to break anyone, which is fine. (although if the
> swift team has changed their minds, that's also welcome)
>
> for the rest of you, can we kill these rather than transfer them?
>
> Thanks!
> Monty
>
>
>
> ------------------------------
>
> Message: 20
> Date: Wed, 8 Mar 2017 15:29:05 +0000
> From: Yu Wei <yu2003w at hotmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][placement-api] Is there any
> document about openstack-placement-api for installation and configure?
> Message-ID:
> <HK2PR03MB056153C43DF0C645B2037225B52E0 at HK2PR03MB0561.
> apcprd03.prod.outlook.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> @Chris, Thanks for replying.
>
> When I tried to configure placement-api, I met following problems,
>
> AH01630: client denied by server configuration: /usr/bin/nova-placement-api
>
> I will read the links you pointed out.
>
> Thanks again,
>
> Jared
>
>
> On 2017?03?08? 23:07, Chris Dent wrote:
> On Wed, 8 Mar 2017, Yu Wei wrote:
>
> I'm new to openstack.
> I tried to install openstack-ocata.
> As placement-api is required since Ocata, is there any detailed document
> about how to install and configure placement-api?
>
> There are two different things which might be useful to you. Some
> nova "in-tree" docs about placement:
>
> https://docs.openstack.org/developer/nova/placement.html
> https://docs.openstack.org/developer/nova/placement_dev.html
>
> and some in progress documents about installing placement:
>
> https://review.openstack.org/#/c/438328/
>
> That latter has some errors that are in the process of being fixed,
> so make sure you read the associated comments.
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> <mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170308/cd8b8a70/attachment-0001.html>
>
> ------------------------------
>
> Message: 21
> Date: Wed, 8 Mar 2017 15:35:34 +0000 (GMT)
> From: Chris Dent <cdent+os at anticdent.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][placement-api] Is there any
> document about openstack-placement-api for installation and configure?
> Message-ID: <alpine.OSX.2.20.1703081532490.59117 at shine.local>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On Wed, 8 Mar 2017, Yu Wei wrote:
>
> > When I tried to configure placement-api, I met following problems,
> >
> > AH01630: client denied by server configuration:
> /usr/bin/nova-placement-api
>
> That can be fixed by doing (somewhere in your apache config):
>
> <Directory /usr/bin>
> Require all granted
> </Directory>
>
> but rather than doing that you may wish to move nova-placement-api
> to a less global directory and grant access to that directory.
> Providing wide access to /usr/bin is not a great idea.
>
> --
> Chris Dent ?\_(?)_/? https://anticdent.org/
> freenode: cdent tw: @anticdent
>
> ------------------------------
>
> Message: 22
> Date: Thu, 9 Mar 2017 00:39:03 +0900
> From: Hirofumi Ichihara <ichihara.hirofumi at lab.ntt.co.jp>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron] [infra] Depends-on tag effect
> Message-ID: <6664232b-37bc-9a2b-f06e-812318f62b67 at lab.ntt.co.jp>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
>
>
> On 2017/03/08 23:59, Andreas Jaeger wrote:
> > On 2017-03-08 15:40, ZZelle wrote:
> >> Hi,
> >>
> >> iiuc, neutron uses a released version of neutron-lib not neutron-lib
> >> master ... So the change should depends on a change in requirements repo
> >> incrementing neutron-lib version
> > This is documented also at - together with some other caveats:
> >
> > https://docs.openstack.org/infra/manual/developers.html#
> limitations-and-caveats
> Thank you for the pointer. I understand.
>
> Hirofumi
>
> >
> >
> > Note a depends-on requirements won't work either - you really need to
> > release it. Or you need to change the test to pull neutron-lib from
> source,
> >
> > Andreas
> >> On Wed, Mar 8, 2017 at 3:16 PM, Hirofumi Ichihara
> >> <ichihara.hirofumi at lab.ntt.co.jp
> >> <mailto:ichihara.hirofumi at lab.ntt.co.jp>> wrote:
> >>
> >> Hi,
> >>
> >> I thought that we can post neutron patch depending on neutron-lib
> >> patch under review.
> >> However, I saw it doesn't work[1, 2]. In the patches, neutron
> >> patch[1] has Depends-on tag with neutron-lib patch[2] but the pep8
> >> and unit test fails because the test doesn't use the neutron-lib
> patch.
> >>
> >> Please correct me if it's my misunderstanding.
> >>
> >> [1]: https://review.openstack.org/#/c/424340/
> >> <https://review.openstack.org/#/c/424340/>
> >> [2]: https://review.openstack.org/#/c/424868/
> >> <https://review.openstack.org/#/c/424868/>
> >>
> >> Thanks,
> >> Hirofumi
> >>
> >>
> >>
> >> ____________________________________________________________
> ______________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> <http://OpenStack-dev-request@lists.openstack.org?subject:
> unsubscribe>
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >>
> >>
> >>
> >>
> >> ____________________________________________________________
> ______________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
>
>
>
>
>
>
> ------------------------------
>
> Message: 23
> Date: Wed, 8 Mar 2017 09:50:34 -0600
> From: Lance Bragstad <lbragstad at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev]
> [cinder][glance][horizon][keystone][nova][qa][swift] Feedback needed:
> Removal of legacy per-project vanity domain redirects
> Message-ID:
> <CAE6oFcGTu7tesJO28aB8sr2vfS-XRhfm_OYhZ_+VVqGb1fTmkQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> >From a keystone-perspective, I'm fine killing keystone.openstack.org.
> Unless another team member with more context/history has a reason to keep
> it around.
>
> On Wed, Mar 8, 2017 at 9:12 AM, Monty Taylor <mordred at inaugust.com> wrote:
>
> > Hey all,
> >
> > We have a set of old vanity redirect URLs from back when we made a URL
> > for each project:
> >
> > cinder.openstack.org
> > glance.openstack.org
> > horizon.openstack.org
> > keystone.openstack.org
> > nova.openstack.org
> > qa.openstack.org
> > swift.openstack.org
> >
> > They are being served from an old server we'd like to retire. Obviously,
> > moving a set of http redirects is trivial, but these domains have been
> > deprecated for about 4 now, so we figured we'd clean house if we can.
> >
> > We know that the swift team has previously expressed that there are
> > links out in the wild pointing to swift.o.o/content that still work and
> > that they don't want to break anyone, which is fine. (although if the
> > swift team has changed their minds, that's also welcome)
> >
> > for the rest of you, can we kill these rather than transfer them?
> >
> > Thanks!
> > Monty
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170308/ea4f7d2d/attachment-0001.html>
>
> ------------------------------
>
> Message: 24
> Date: Wed, 8 Mar 2017 15:55:19 +0000
> From: Yu Wei <yu2003w at hotmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][placement-api] Is there any
> document about openstack-placement-api for installation and configure?
> Message-ID:
> <HK2PR03MB0561C71A3A7EB17971201AD0B52E0 at HK2PR03MB0561.
> apcprd03.prod.outlook.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> It seems that nova-placement-api acts as a CGI module.
>
> Is it?
>
> On 2017?03?08? 23:35, Chris Dent wrote:
> On Wed, 8 Mar 2017, Yu Wei wrote:
>
> When I tried to configure placement-api, I met following problems,
>
> AH01630: client denied by server configuration: /usr/bin/nova-placement-api
>
> That can be fixed by doing (somewhere in your apache config):
>
> <Directory /usr/bin>
> Require all granted
> </Directory>
>
> but rather than doing that you may wish to move nova-placement-api
> to a less global directory and grant access to that directory.
> Providing wide access to /usr/bin is not a great idea.
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> <mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170308/e9888a76/attachment-0001.html>
>
> ------------------------------
>
> Message: 25
> Date: Wed, 8 Mar 2017 16:02:12 +0000
> From: "Scheglmann, Stefan" <scheglmann at strato.de>
> To: "openstack-dev at lists.openstack.org"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [puppet] puppet-cep beaker test
> Message-ID: <AA214AA9-86CB-4DC6-8BDE-627F9067D6F8 at strato.de>
> Content-Type: text/plain; charset="utf-8"
>
> Hey Alex,
>
> thx for the reply, unfortunately it doesn?t seem to work. Adding
> PUPPET_MAJ_VERSION to the call seems not to have any effect.
>
>
> Stefan
> > On Tue, Mar 7, 2017 at 7:09 AM, Scheglmann, Stefan <scheglmann at strato.de>
> wrote:
> >> Hi,
> >>
> >> currently got some problems running the beaker test for the puppet-cep
> module. Working on OSX using Vagrant version 1.8.6 and VirtualBox version
> 5.1.14. Call is 'BEAKER_destroy=no BEAKER_debug=1 bundle exec --verbose
> rspec spec/acceptance? output in http://pastebin.com/w5ifgrvd
> >>
> >
> > Try running:
> > PUPPET_MAJ_VERSION=4 BEAKER_destroy=no BEAKER_debug=1 bundle exec
> > --verbose rspec spec/acceptance
> >
> > Thanks,
> > -Alex
> >
>
> Tried this, this just changes the trace a bit, now it seems like that it
> worked in the first place but then failed for the same reason.
> Trace here:
>
>
> >> Trace:
> >> An error occurred in a `before(:suite)` hook.
> >> Failure/Error: raise CommandFailure, "Host '#{self}' exited with
> #{result.exit_code} running:\n #{cmdline}\nLast #{@options[:trace_limit]}
> lines of output were:\n#{result.formatted_output(@options[:trace_limit])}"
> >> Beaker::Host::CommandFailure:
> >> Host 'first' exited with 127 running:
> >> ZUUL_REF= ZUUL_BRANCH= ZUUL_URL= PUPPET_MAJ_VERSION= bash
> openstack/puppet-openstack-integration/install_modules.sh
> >> Last 10 lines of output were:
> >> + '[' -n 'SHELLOPTS=braceexpand:hashall:interactive-comments:
> xtrace
> >> if [ -n "$(set | grep xtrace)" ]; then
> >> local enable_xtrace='\''yes'\'';
> >> if [ -n "${enable_xtrace}" ]; then' ']'
> >> + set +x
> >> ------------------------------------------------------------
> --------------------
> >> | Install r10k
> |
> >> ------------------------------------------------------------
> --------------------
> >> + gem install fast_gettext -v '< 1.2.0'
> >> openstack/puppet-openstack-integration/install_modules.sh: line
> 29: gem: command not found
> >>
> >> It seems like that the box beaker is using (puppetlabs/ubuntu-14.04-64-nocm),
> somehow ends up with has puppet 4.x installed. I could not exactly pin down
> how this happens, cause when i sin up some VM just from that base box and
> install puppet, i end up with 3.4. But during the beaker tests it ends up
> with puppet 4 and in puppet 4 some paths have changed. /opt/puppetlabs/bin
> is just for the 'public' applications and the ?private' ones like gem or
> ruby are in /opt/puppetlabs/puppet/bin. Therefore the
> openstack/puppet-openstack-integration/install_modules.sh script fails on
> installation of r10k, cause it cannot find gem and later on it fails on the
> r10k call cause it is also installed to /opt/puppetlabs/puppet/bin.
> >> Symlinking gem and r10k in an provisioned machine, and rerun the tests
> fixes the problem. Currently i am doing all this cause i added some
> functionalities for the puppet-cep manifests to support bluestone/rocksdb
> and some additional config params which i would like to see in upstream.
> >>
> >>
> >> Greets Stefan
> >> ____________________________________________________________
> ______________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ------------------------------
>
> Message: 26
> Date: Wed, 8 Mar 2017 09:15:04 -0700
> From: Alex Schultz <aschultz at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [puppet] puppet-cep beaker test
> Message-ID:
> <CAFsb3b4rG0ribX0bRvcnO6349ydM+zv5RsE2=X8zoOGMOms9pg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Mar 8, 2017 at 9:02 AM, Scheglmann, Stefan <scheglmann at strato.de>
> wrote:
> > Hey Alex,
> >
> > thx for the reply, unfortunately it doesn?t seem to work. Adding
> PUPPET_MAJ_VERSION to the call seems not to have any effect.
> >
>
> I just read the bottom part of the original message and it's getting a
> 14.04 box from puppet-ceph/spec/acceptance/nodesets/default.yml. You
> could try changing that to 16.04. For our CI we're using the
> nodepool-xenial.yml via BEAKER_set=nodepool-xenial.yml but that
> assumes you're running on localhost. You could try grabbing the 1604
> configuration from puppet-openstack_extras[0] and putting that in your
> spec/acceptance/nodesets folder to see if that works for you. Then you
> should able to run:
>
> PUPPET_MAJ_VERSION=4 BEAKER_destroy=no BEAKER_debug=1
> BEAKER_set=ubuntu-server-1604-x86 bundle exec --verbose rspec
> spec/acceptance
>
> If you run in to more problems, you may want to try hopping on IRC and
> we can help you in #puppet-openstack on freenode.
>
> Thanks,
> -Alex
>
> [0] https://github.com/openstack/puppet-openstack_extras/blob/
> master/spec/acceptance/nodesets/ubuntu-server-1604-x64.yml
>
>
> >
> > Stefan
> >> On Tue, Mar 7, 2017 at 7:09 AM, Scheglmann, Stefan <
> scheglmann at strato.de> wrote:
> >>> Hi,
> >>>
> >>> currently got some problems running the beaker test for the puppet-cep
> module. Working on OSX using Vagrant version 1.8.6 and VirtualBox version
> 5.1.14. Call is 'BEAKER_destroy=no BEAKER_debug=1 bundle exec --verbose
> rspec spec/acceptance? output in http://pastebin.com/w5ifgrvd
> >>>
> >>
> >> Try running:
> >> PUPPET_MAJ_VERSION=4 BEAKER_destroy=no BEAKER_debug=1 bundle exec
> >> --verbose rspec spec/acceptance
> >>
> >> Thanks,
> >> -Alex
> >>
> >
> > Tried this, this just changes the trace a bit, now it seems like that it
> worked in the first place but then failed for the same reason.
> > Trace here:
> >
> >
> >>> Trace:
> >>> An error occurred in a `before(:suite)` hook.
> >>> Failure/Error: raise CommandFailure, "Host '#{self}' exited with
> #{result.exit_code} running:\n #{cmdline}\nLast #{@options[:trace_limit]}
> lines of output were:\n#{result.formatted_output(@options[:trace_limit])}"
> >>> Beaker::Host::CommandFailure:
> >>> Host 'first' exited with 127 running:
> >>> ZUUL_REF= ZUUL_BRANCH= ZUUL_URL= PUPPET_MAJ_VERSION= bash
> openstack/puppet-openstack-integration/install_modules.sh
> >>> Last 10 lines of output were:
> >>> + '[' -n 'SHELLOPTS=braceexpand:hashall:interactive-comments:
> xtrace
> >>> if [ -n "$(set | grep xtrace)" ]; then
> >>> local enable_xtrace='\''yes'\'';
> >>> if [ -n "${enable_xtrace}" ]; then' ']'
> >>> + set +x
> >>> ------------------------------------------------------------
> --------------------
> >>> | Install r10k
> |
> >>> ------------------------------------------------------------
> --------------------
> >>> + gem install fast_gettext -v '< 1.2.0'
> >>> openstack/puppet-openstack-integration/install_modules.sh:
> line 29: gem: command not found
> >>>
> >>> It seems like that the box beaker is using (puppetlabs/ubuntu-14.04-64-nocm),
> somehow ends up with has puppet 4.x installed. I could not exactly pin down
> how this happens, cause when i sin up some VM just from that base box and
> install puppet, i end up with 3.4. But during the beaker tests it ends up
> with puppet 4 and in puppet 4 some paths have changed. /opt/puppetlabs/bin
> is just for the 'public' applications and the ?private' ones like gem or
> ruby are in /opt/puppetlabs/puppet/bin. Therefore the
> openstack/puppet-openstack-integration/install_modules.sh script fails on
> installation of r10k, cause it cannot find gem and later on it fails on the
> r10k call cause it is also installed to /opt/puppetlabs/puppet/bin.
> >>> Symlinking gem and r10k in an provisioned machine, and rerun the tests
> fixes the problem. Currently i am doing all this cause i added some
> functionalities for the puppet-cep manifests to support bluestone/rocksdb
> and some additional config params which i would like to see in upstream.
> >>>
> >>>
> >>> Greets Stefan
> >>> ____________________________________________________________
> ______________
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 27
> Date: Wed, 8 Mar 2017 11:23:50 -0500
> From: David Moreau Simard <dms at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [tc][appcat] The future of the App
> Catalog
> Message-ID:
> <CAH7C+Poe+u86P2myBqAybQdcrcAEFTbS0gZapuaXMjXrotGqWA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> The App Catalog, to me, sounds sort of like a weird message that
> OpenStack somehow requires applications to be
> packaged/installed/deployed differently.
> If anything, perhaps we should spend more effort on advertising that
> OpenStack provides bare metal or virtual compute resources and that
> apps will work just like any other places.
>
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
>
> dmsimard = [irc, github, twitter]
>
>
> On Wed, Mar 8, 2017 at 9:41 AM, Jay Pipes <jaypipes at gmail.com> wrote:
> > On 03/06/2017 06:26 AM, Thierry Carrez wrote:
> >>
> >> Hello everyone,
> >>
> >> The App Catalog was created early 2015 as a marketplace of pre-packaged
> >> applications that you can deploy using Murano. Initially a demo by
> >> Mirantis, it was converted into an open upstream project team, and
> >> deployed as a "beta" as apps.openstack.org.
> >>
> >> Since then it grew additional categories (Glance images, Heat & Tosca
> >> templates), but otherwise did not pick up a lot of steam. The website
> >> (still labeled "beta") features 45 glance images, 6 Tosca templates, 13
> >> heat templates and 94 murano packages (~30% of which are just thin
> >> wrappers around Docker containers). Traffic stats show around 100 visits
> >> per week, 75% of which only read the index page.
> >>
> >> In parallel, Docker developed a pretty successful containerized
> >> application marketplace (the Docker Hub), with hundreds of thousands of
> >> regularly-updated apps. Keeping the App Catalog around (including its
> >> thinly-wrapped Docker container Murano packages) make us look like we
> >> are unsuccessfully trying to compete with that ecosystem, while
> >> OpenStack is in fact completely complementary.
> >>
> >> In the past we have retired projects that were dead upstream. The App
> >> Catalog is not in this case: it has an active maintenance team, which
> >> has been successfully maintaining the framework and accepting
> >> applications. If we end up retiring the App Catalog, it would clearly
> >> not be a reflection on that team performance, which has been stellar
> >> despite limited resources. It would be because the beta was arguably not
> >> successful in building an active marketplace of applications, and
> >> because its continuous existence is not a great fit from a strategy
> >> perspective. Such removal would be a first for our community, but I
> >> think it's now time to consider it.
> >>
> >> Before we discuss or decide anything at the TC level, I'd like to
> >> collect everyone thoughts (and questions) on this. Please feel free to
> >> reply to this thread (or reach out to me privately if you prefer).
> Thanks
> >> !
> >
> >
> > Mirantis' position is that the App Catalog was a good idea, but we agree
> > with you that other application repositories like DockerHub and Quay.io
> are
> > both more useful and more actively used.
> >
> > The OpenStack App Catalog does indeed seem to unnecessarily compete with
> > those application repositories, and we would support its retirement if
> that
> > is what the community would like to do. We'll provide resources and help
> in
> > winding anything down if needed.
> >
> > Best,
> > -jay
> >
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 28
> Date: Wed, 8 Mar 2017 11:23:50 -0500
> From: Brian Rosmaita <rosmaita.fossdev at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev]
> [cinder][glance][horizon][keystone][nova][qa][swift] Feedback needed:
> Removal of legacy per-project vanity domain redirects
> Message-ID: <ddb8d3a0-85b3-fd6f-31e1-5724b51b99c3 at gmail.com>
> Content-Type: text/plain; charset=windows-1252
>
> On 3/8/17 10:12 AM, Monty Taylor wrote:
> > Hey all,
> >
> > We have a set of old vanity redirect URLs from back when we made a URL
> > for each project:
> >
> > cinder.openstack.org
> > glance.openstack.org
> > horizon.openstack.org
> > keystone.openstack.org
> > nova.openstack.org
> > qa.openstack.org
> > swift.openstack.org
> >
> > They are being served from an old server we'd like to retire. Obviously,
> > moving a set of http redirects is trivial, but these domains have been
> > deprecated for about 4 now, so we figured we'd clean house if we can.
> >
> > We know that the swift team has previously expressed that there are
> > links out in the wild pointing to swift.o.o/content that still work and
> > that they don't want to break anyone, which is fine. (although if the
> > swift team has changed their minds, that's also welcome)
> >
> > for the rest of you, can we kill these rather than transfer them?
>
> My concern is that glance.openstack.org is easy to remember and type, so
> I imagine there are links out there that we have no control over using
> that URL. So what are the consequences of it 404'ing or "site cannot be
> reached" in a browser?
>
> glance.o.o currently redirects to docs.o.o/developer/glance
>
> If glance.o.o failed for me, I'd next try openstack.org (or
> www.openstack.org). Those would give me a page with a top bar of links,
> one of which is DOCS. If I took that link, I'd get the docs home page.
>
> There's a search bar there; typing in 'glance' gets me
> docs.o.o/developer/glance as the first hit.
>
> If instead I scroll past the search bar, I have to scroll down to
> "Project-Specific Guides" and follow "Services & Libraries" ->
> "Openstack Services" -> "image service (glance) ->
> docs.o.o/developer/glance
>
> Which sounds kind of bad ... until I type "glance docs" into google.
> Right now the first hit is docs.o.o/developer/glance. And all the kids
> these days use the google. So by trying to be clever and hack the URL,
> I could get lost, but if I just google 'glance docs', I find what I'm
> looking for right away.
>
> So I'm willing to go with the majority on this, with the caveat that if
> one or two teams keep the redirect, it's going to be confusing to end
> users if the redirect doesn't work for other projects.
>
> cheers,
> brian
>
> >
> > Thanks!
> > Monty
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
>
> ------------------------------
>
> Message: 29
> Date: Wed, 8 Mar 2017 16:27:56 +0000 (GMT)
> From: Chris Dent <cdent+os at anticdent.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][placement-api] Is there any
> document about openstack-placement-api for installation and configure?
> Message-ID: <alpine.OSX.2.20.1703081625580.59117 at shine.local>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On Wed, 8 Mar 2017, Yu Wei wrote:
>
> > It seems that nova-placement-api acts as a CGI module.
> >
> > Is it?
>
> It's a WSGI application module, which is configured and accessed via
> some mod wsgi configuration settings, if you're using mod_wsgi with
> apache2:
>
> https://modwsgi.readthedocs.io/en/develop/configuration-
> directives/WSGIDaemonProcess.html
> https://modwsgi.readthedocs.io/en/develop/configuration-
> directives/WSGIScriptAlias.html
>
> It's a similar concept with other WSGI servers.
>
> --
> Chris Dent ?\_(?)_/? https://anticdent.org/
> freenode: cdent tw: @anticdent
>
> ------------------------------
>
> Message: 30
> Date: Wed, 8 Mar 2017 16:31:23 +0000
> From: "Daniel P. Berrange" <berrange at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev]
> [cinder][glance][horizon][keystone][nova][qa][swift] Feedback needed:
> Removal of legacy per-project vanity domain redirects
> Message-ID: <20170308163123.GT7470 at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> On Wed, Mar 08, 2017 at 09:12:59AM -0600, Monty Taylor wrote:
> > Hey all,
> >
> > We have a set of old vanity redirect URLs from back when we made a URL
> > for each project:
> >
> > cinder.openstack.org
> > glance.openstack.org
> > horizon.openstack.org
> > keystone.openstack.org
> > nova.openstack.org
> > qa.openstack.org
> > swift.openstack.org
> >
> > They are being served from an old server we'd like to retire. Obviously,
> > moving a set of http redirects is trivial, but these domains have been
> > deprecated for about 4 now, so we figured we'd clean house if we can.
> >
> > We know that the swift team has previously expressed that there are
> > links out in the wild pointing to swift.o.o/content that still work and
> > that they don't want to break anyone, which is fine. (although if the
> > swift team has changed their minds, that's also welcome)
> >
> > for the rest of you, can we kill these rather than transfer them?
>
> Does the server have any access log that could provide stats on whether
> any of the subdomains are a receiving a meaningful amount of traffic ?
> Easy to justify removing them if they're not seeing any real traffic.
>
> If there's any referrer logs present, that might highlight which places
> still have outdated links that need updating to kill off remaining
> traffic.
>
> Regards,
> Daniel
> --
> |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org -o- http://virt-manager.org
> :|
> |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/
> :|
>
>
>
> ------------------------------
>
> Message: 31
> Date: Thu, 9 Mar 2017 00:50:56 +0800
> From: Jeffrey Zhang <zhang.lei.fly at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Cc: openstack <openstack at lists.openstack.org>
> Subject: Re: [openstack-dev] [kolla][ubuntu][libvirt] Is libvirt 2.5.0
> in ubuntu cloud archive ocata repo bust
> Message-ID:
> <CAATxhGe9fo7PDr_WGapp85LKz4Uj9LdMPVRzz=qZd0ub2d2_Yw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks Corey, But i tried ocata proposed repo, the issue is still
> happening.
>
> On Wed, Mar 8, 2017 at 10:03 PM, Corey Bryant <corey.bryant at canonical.com>
> wrote:
>
> >
> >
> > On Tue, Mar 7, 2017 at 10:28 PM, Jeffrey Zhang <zhang.lei.fly at gmail.com>
> > wrote:
> >
> >> Kolla deploy ubuntu gate is red now. here is the related bug[0].
> >>
> >> libvirt failed to access the console.log file when booting instance.
> After
> >> made some debugging, i got following.
> >>
> >>
> > Jeffrey, This is likely fixed in ocata-proposed and should be promoted
> to
> > ocata-updates soon after testing completes. https://bugs.launchpad.net/
> > ubuntu/+source/libvirt/+bug/1667033.
> >
> > Corey
> >
> >
> > # how console.log works
> >> nova create a empty console.log with nova:nova ( this is another bug
> >> workaround actually[1]), then libvirt ( running with root ) will change
> >> the
> >> file owner to qemu process user/group ( configured by dynamic_ownership
> >> ).
> >> Now qemu process can write logs into this file.
> >>
> >> # what's wrong now
> >> libvirt 2.5.0 stop change the file owner, then qemu/libvirt failed to
> >> write
> >> logs into console.log file
> >>
> >> # other test
> >>
> >> * ubuntu + fallback libvirt 1.3.x works [2]
> >> * ubuntu + libvirt 2.5.0 + chang the qemu process user/group to
> >> nova:nova works, too.[3]
> >> * centos + libvirt 2.0.0 works, never saw such issue in centos.
> >>
> >> # conclusion
> >> I guess there are something wrong in libvirt 2.5.0 with
> dynamic_ownership
> >>
> >>
> >> [0] https://bugs.launchpad.net/kolla-ansible/+bug/1668654
> >> [1] https://github.com/openstack/nova/blob/master/nova/virt/
> >> libvirt/driver.py#L2922,L2952
> >> [2] https://review.openstack.org/442673
> >> [3] https://review.openstack.org/442850
> >>
> >> --
> >> Regards,
> >> Jeffrey Zhang
> >> Blog: http://xcodest.me
> >>
> >> ____________________________________________________________
> >> ______________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscrib
> >> e
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170309/8cf01a23/attachment-0001.html>
>
> ------------------------------
>
> Message: 32
> Date: Wed, 8 Mar 2017 12:08:11 -0500
> From: James Slagle <james.slagle at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [TripleO][Heat] Selectively disabling
> deployment resources
> Message-ID:
> <CAHV77z9oPkjrZ=e1TMJLDC3PZS=df01NEA1_ihAee=ymbz-X-Q at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Mar 8, 2017 at 4:08 AM, Steven Hardy <shardy at redhat.com> wrote:
> > On Tue, Mar 07, 2017 at 02:34:50PM -0500, James Slagle wrote:
> >> I've been working on this spec for TripleO:
> >> https://review.openstack.org/#/c/431745/
> >>
> >> which allows users to selectively disable Heat deployment resources
> >> for a given server (or server in the case of a *DeloymentGroup
> >> resource).
> >>
> >> Some of the main use cases in TripleO for such a feature are scaling
> >> out compute nodes where you do not need to rerun Puppet (or make any
> >> changes at all) on non-compute nodes, or to exclude nodes from hanging
> >> a stack-update if you know they are unreachable or degraded for some
> >> reason. There are others, but those are 2 of the major use cases.
> >
> > Thanks for raising this, I know it's been a pain point for some users of
> > TripleO.
> >
> > However I think we're conflating two different issues here:
> >
> > 1. Don't re-run puppet (or yum update) when no other changes have
> happened
> >
> > 2. Disable deployment resources when changes have happened
>
> Yea, possibly, but (1) doesn't really solve the use cases in the spec.
> It'd certainly be a small improvement, but it's not really what users
> are asking for.
>
> (2) is much more difficult to reason about because we in fact have to
> execute puppet to fully determine if changes have happened.
>
> I don't really think these two are conflated. For some purposes, the
> 2nd is just a more abstract definition of the first. For better or
> worse, part of the reason people are asking for this feature is
> because they don't want to undo manual changes. While that's not
> something we should really spend a lot of time solving for, the fact
> is that OpenStack architecture allows for horizontally scaling compute
> nodes without have to touch every other single node in your deployment
> but TripleO can't take advantage of that.
>
> So, just giving users a way to opt out of the generated unique
> identifier triggering the puppet applys and other deployments,
> wouldn't help them if they unintentionally changed some other hiera
> data that triggers a deployment.
>
> Plus, we have some deployments that are going to execute every time
> outside of unique identifiers being generated (hosts-config.yaml).
>
> > (1) is actually very simple, and is the default behavior of Heat
> > (SoftwareDeployment resources never update unless either the config
> > referenced or the input_values change). We just need to provide an
> option
> > to disable the DeployIdentifier/UpdateIdentifier timestamps from being
> > generated in tripleoclient.
> >
> > (2) is harder, because the whole point of SoftwareDeploymentGroup is to
> run
> > the exact same configuration on a group of servers, with no exceptions.
> >
> > As Zane mentions (2) is related to the way ResourceGroup works, but the
> > problem here isn't ResourceGroup per-se, as it would in theory be pretty
> > easy to reimplement SoftwareDeploymentGroup to generate it's nested stack
> > without inheriting from ResourceGroup (which may be needed if you want a
> > flag to make existing Deployments in the group immutable).
> >
> > I'd suggest we solve (1) and do some testing, it may be enough to solve
> the
> > "don't change computes on scale-out" case at least?
>
> Possibly, as long as no other deployments are triggered. I think of
> the use case more as:
>
> add a compute node(s), don't touch any existing nodes to minimize risk
>
> as opposed to:
>
> add a compute node(s), don't re-run puppet on any existing nodes as I
> know that it's not needed
>
> For the scale out case, the desire to minimize risk is a big part of
> why other nodes don't need to be touched.
>
> >
> > One way to potentially solve (2) would be to unroll the
> > SoftwareDeploymentGroup resources and instead generate the Deployment
> > resources via jinja2 - this would enable completely removing them on
> update
> > if that's what is desired, similar to what we already do for upgrades to
> > e.g not upgrade any compute nodes.
>
> Thanks, I hadn't considered that approach, but will look into it. I'd
> guess you'd still need a parameter or map data fed into the jinja2
> templating, so that it would not generate the deployment resources
> based on what was desired to be disabled. Or, this could use
> conditionals perhaps.
>
>
>
> --
> -- James Slagle
> --
>
>
>
> ------------------------------
>
> Message: 33
> Date: Wed, 8 Mar 2017 09:33:29 -0800
> From: "Armando M." <armamig at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron] [infra] Depends-on tag effect
> Message-ID:
> <CAK+RQeao6355sxRxDiOcfy18VaarTndyiypzXy1z1TB6dbJcVQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 8 March 2017 at 07:39, Hirofumi Ichihara <ichihara.hirofumi at lab.ntt.co.
> jp
> > wrote:
>
> >
> >
> > On 2017/03/08 23:59, Andreas Jaeger wrote:
> >
> >> On 2017-03-08 15:40, ZZelle wrote:
> >>
> >>> Hi,
> >>>
> >>> iiuc, neutron uses a released version of neutron-lib not neutron-lib
> >>> master ... So the change should depends on a change in requirements
> repo
> >>> incrementing neutron-lib version
> >>>
> >> This is documented also at - together with some other caveats:
> >>
> >> https://docs.openstack.org/infra/manual/developers.html#limi
> >> tations-and-caveats
> >>
> > Thank you for the pointer. I understand.
>
>
> You can do the reverse as documented in [1]: i.e. file a dummy patch
> against neutron-lib that pulls in both neutron's and neutron-lib changes.
> One example is [2]
>
> [1] https://docs.openstack.org/developer/neutron-lib/review-
> guidelines.html
> [2] https://review.openstack.org/#/c/386846/
>
>
> >
> > Hirofumi
> >
> >
> >
> >>
> >> Note a depends-on requirements won't work either - you really need to
> >> release it. Or you need to change the test to pull neutron-lib from
> >> source,
> >>
> >> Andreas
> >>
> >>> On Wed, Mar 8, 2017 at 3:16 PM, Hirofumi Ichihara
> >>> <ichihara.hirofumi at lab.ntt.co.jp
> >>> <mailto:ichihara.hirofumi at lab.ntt.co.jp>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I thought that we can post neutron patch depending on neutron-lib
> >>> patch under review.
> >>> However, I saw it doesn't work[1, 2]. In the patches, neutron
> >>> patch[1] has Depends-on tag with neutron-lib patch[2] but the pep8
> >>> and unit test fails because the test doesn't use the neutron-lib
> >>> patch.
> >>>
> >>> Please correct me if it's my misunderstanding.
> >>>
> >>> [1]: https://review.openstack.org/#/c/424340/
> >>> <https://review.openstack.org/#/c/424340/>
> >>> [2]: https://review.openstack.org/#/c/424868/
> >>> <https://review.openstack.org/#/c/424868/>
> >>>
> >>> Thanks,
> >>> Hirofumi
> >>>
> >>>
> >>>
> >>> ___________________________________________________________
> >>> _______________
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>> <http://OpenStack-dev-request@lists.openstack.org?
> >>> subject:unsubscribe>
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev>
> >>>
> >>>
> >>>
> >>>
> >>> ____________________________________________________________
> >>> ______________
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe: OpenStack-dev-request at lists.op
> >>> enstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> >>
> >
> >
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170308/b2c20643/attachment-0001.html>
>
> ------------------------------
>
> Message: 34
> Date: Wed, 8 Mar 2017 12:38:01 -0500
> From: Jim Rollenhagen <jim at jimrollenhagen.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [ironic] OpenStack client default ironic
> API version
> Message-ID:
> <CAJCXu8eXJwEH_r-iPFFUzTMJa9Gq7QUqmtR74s6KFrKW=2+AyQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Mar 8, 2017 at 9:05 AM, Mario Villaplana <
> mario.villaplana at gmail.com
> > wrote:
>
> > We want to deprecate ironic CLI soon, but I would prefer if that were
> > discussed on a separate thread if possible, aside from concerns about
> > versioning in ironic CLI. Feature parity should exist in Pike, then we
> > can issue a warning in Queens and deprecate the cycle after. More
> > information is on L56:
> > https://etherpad.openstack.org/p/ironic-pike-ptg-operations
> >
> > I'm a bit torn on whether to use the API version coded in the OSC
> > plugin or not. On one hand, it'd be good to be able to test out new
> > features as soon as they're available. On the other hand, it's
> > possible that the client won't know how to parse certain items after a
> > microversion bump. I think I prefer using the hard-coded version to
> > avoid breakage, but we'd have to be disciplined about updating the
> > client when the API version is bumped (if needed). Opinions on this
> > are welcome. In either case, I think the deprecation warning could
> > land without specifying that.
> >
>
> I agree, I think we should pin it, otherwise it's one more hump to
> overcome when we do want to make a breaking change.
>
> FWIW, nova pins (both clients) to the max the client knows about,
> specifically for this reason:
> https://github.com/openstack/python-openstackclient/blob/
> master/openstackclient/compute/client.py#L52-L57
> https://github.com/openstack/python-novaclient/blob/master/
> novaclient/__init__.py#L23-L28
>
>
> > I'll certainly make an RFE when I update the patch later this week,
> > great suggestion.
> >
> > I can make a spec, but it might be mostly empty except for the client
> > impact section. Also, this is a < 40 line change. :)
> >
>
> I tend to think a spec is a bit overkill for this, but I won't deny Ruby's
> request.
> Ping me when it's up and I'm happy to review it ASAP.
>
> // jim
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170308/275471ee/attachment-0001.html>
>
> ------------------------------
>
> Message: 35
> Date: Wed, 8 Mar 2017 17:42:02 +0000
> From: "Fox, Kevin M" <Kevin.Fox at pnnl.gov>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [tc][appcat] The future of the App
> Catalog
> Message-ID:
> <1A3C52DFCD06494D8528644858247BF01BECDB80 at EX10MBOX03.pnnl.gov>
> Content-Type: text/plain; charset="us-ascii"
>
> For the OpenStack Applications Catalog to be successful in its mission, it
> required other parts of OpenStack to consider the use case a priority. Over
> the years it became quite clear to me that a significant part of the
> OpenStack community does not want OpenStack to become a place where cloud
> native applications would be built/packaged/provided to users using
> OpenStacks apis but instead just a place to run virtual machines on which
> you might deploy a cloud native platform to handle that use case. As time
> goes on, and COE's gain multitenancy, I see a big contraction in the number
> of OpenStack deployments or deployed node count and a shifting of OpenStack
> based workloads more towards managing pet vm's, as the cloud native stuff
> moves more and more towards containers/COE's which don't actually need vm's.
>
> This I think will bring the issue to a head in the OpenStack community
> soon. What is OpenStack? Is it purely an IaaS implementation? Its pretty
> good at that now. But something that will be very niche soon I think. Is it
> an Cloud Operating system? The community seems to have made that a
> resounding no. Is it an OpenSource competitor to AWS? Today, its getting
> further and further behind in that. If nothing changes, that will be
> impossible.
>
> My 2 cents? I think the world does need an OpenSource implementation of
> what AWS provides. That can't happen on the path we're all going down now.
> We're struggling with division of vision between the two ideologies and
> lack of decision around a COE, causing us to spend a huge amount of effort
> on things like Trove/Sahara/etc to reproduce functionality in AWS, but not
> being as agile as AWS so we can't ever make headway. If we want to be an
> OpenSource AWS competitor, that requires us to make some hard calls, pick a
> COE (Kubernetes has won that space I believe), start integrating it
> quickly, and retool advanced services like Trove/Sahara/etc to target the
> COE rather then VM's for deployment. This should greatly enhance our
> ability to produce functional solutions quickly.
>
> But, its ultimately the Community who decide what OpenStack will become.
> If we're ok with the path its headed down, to basically just be an IaaS,
> that's fine with me. I'd just like it to be a conscious decision rather
> then one that just happens. If thats the way it goes, lets just decide on
> it now, and let the folks that are spinning their wheels move on to a
> system that will help them make headway in their goals. It will be better
> for everyone.
>
> Thanks,
> Kevin
>
> ________________________________________
> From: David Moreau Simard [dms at redhat.com]
> Sent: Wednesday, March 08, 2017 8:23 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tc][appcat] The future of the App Catalog
>
> The App Catalog, to me, sounds sort of like a weird message that
> OpenStack somehow requires applications to be
> packaged/installed/deployed differently.
> If anything, perhaps we should spend more effort on advertising that
> OpenStack provides bare metal or virtual compute resources and that
> apps will work just like any other places.
>
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
>
> dmsimard = [irc, github, twitter]
>
>
> On Wed, Mar 8, 2017 at 9:41 AM, Jay Pipes <jaypipes at gmail.com> wrote:
> > On 03/06/2017 06:26 AM, Thierry Carrez wrote:
> >>
> >> Hello everyone,
> >>
> >> The App Catalog was created early 2015 as a marketplace of pre-packaged
> >> applications that you can deploy using Murano. Initially a demo by
> >> Mirantis, it was converted into an open upstream project team, and
> >> deployed as a "beta" as apps.openstack.org.
> >>
> >> Since then it grew additional categories (Glance images, Heat & Tosca
> >> templates), but otherwise did not pick up a lot of steam. The website
> >> (still labeled "beta") features 45 glance images, 6 Tosca templates, 13
> >> heat templates and 94 murano packages (~30% of which are just thin
> >> wrappers around Docker containers). Traffic stats show around 100 visits
> >> per week, 75% of which only read the index page.
> >>
> >> In parallel, Docker developed a pretty successful containerized
> >> application marketplace (the Docker Hub), with hundreds of thousands of
> >> regularly-updated apps. Keeping the App Catalog around (including its
> >> thinly-wrapped Docker container Murano packages) make us look like we
> >> are unsuccessfully trying to compete with that ecosystem, while
> >> OpenStack is in fact completely complementary.
> >>
> >> In the past we have retired projects that were dead upstream. The App
> >> Catalog is not in this case: it has an active maintenance team, which
> >> has been successfully maintaining the framework and accepting
> >> applications. If we end up retiring the App Catalog, it would clearly
> >> not be a reflection on that team performance, which has been stellar
> >> despite limited resources. It would be because the beta was arguably not
> >> successful in building an active marketplace of applications, and
> >> because its continuous existence is not a great fit from a strategy
> >> perspective. Such removal would be a first for our community, but I
> >> think it's now time to consider it.
> >>
> >> Before we discuss or decide anything at the TC level, I'd like to
> >> collect everyone thoughts (and questions) on this. Please feel free to
> >> reply to this thread (or reach out to me privately if you prefer).
> Thanks
> >> !
> >
> >
> > Mirantis' position is that the App Catalog was a good idea, but we agree
> > with you that other application repositories like DockerHub and Quay.io
> are
> > both more useful and more actively used.
> >
> > The OpenStack App Catalog does indeed seem to unnecessarily compete with
> > those application repositories, and we would support its retirement if
> that
> > is what the community would like to do. We'll provide resources and help
> in
> > winding anything down if needed.
> >
> > Best,
> > -jay
> >
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 36
> Date: Wed, 8 Mar 2017 17:52:43 +0000
> From: "Kwasniewska, Alicja" <alicja.kwasniewska at intel.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [kolla] Proposing duonghq for core
> Message-ID: <E5DE2A5A-DCA7-4900-BFB7-4849CE6D9DAF at intel.com>
> Content-Type: text/plain; charset="utf-8"
>
> +1
>
> From: Mauricio Lima <mauriciolimab at gmail.com<mailto:
> mauriciolimab at gmail.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org
> >>
> Date: Wednesday, March 8, 2017 at 5:34 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org
> >>
> Subject: Re: [openstack-dev] [kolla] Proposing duonghq for core
>
> +1
>
> 2017-03-08 7:34 GMT-03:00 Christian Berendt <berendt at betacloud-solutions.
> de<mailto:berendt at betacloud-solutions.de>>:
> +1
>
> > On 8 Mar 2017, at 07:41, Micha? Jastrz?bski <inc007 at gmail.com<mailto:
> inc007 at gmail.com>> wrote:
> >
> > Hello,
> >
> > I'd like to start voting to include Duong (duonghq) in Kolla and
> > Kolla-ansible core teams. Voting will be open for 2 weeks (ends at
> > 21st of March).
> >
> > Consider this my +1 vote.
> >
> > Cheers,
> > Michal
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe<http://OpenStack-dev-request@lists.openstack.
> org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> Christian Berendt
> Chief Executive Officer (CEO)
>
> Mail: berendt at betacloud-solutions.de<mailto:berendt at betacloud-solutions.de
> >
> Web: https://www.betacloud-solutions.de
>
> Betacloud Solutions GmbH
> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>
> Gesch?ftsf?hrer: Christian Berendt
> Unternehmenssitz: Stuttgart
> Amtsgericht: Stuttgart, HRB 756139
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170308/9a7973c9/attachment-0001.html>
>
> ------------------------------
>
> Message: 37
> Date: Wed, 8 Mar 2017 13:17:14 -0500
> From: Corey Bryant <corey.bryant at canonical.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Cc: openstack <openstack at lists.openstack.org>
> Subject: Re: [openstack-dev] [kolla][ubuntu][libvirt] Is libvirt 2.5.0
> in ubuntu cloud archive ocata repo bust
> Message-ID:
> <CADn0iZ1aS=riCG1_nqWi9X8OPU5VPMt0DkfCxk2TE5C2izc1yQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Mar 8, 2017 at 11:50 AM, Jeffrey Zhang <zhang.lei.fly at gmail.com>
> wrote:
>
> > Thanks Corey, But i tried ocata proposed repo, the issue is still
> > happening.
> >
>
> In that case, would you mind opening a bug if you haven't already?
>
> Thanks,
> Corey
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170308/1ae05ae9/attachment-0001.html>
>
> ------------------------------
>
> Message: 38
> Date: Wed, 8 Mar 2017 18:29:52 +0000
> From: Jeremy Stanley <fungi at yuggoth.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [infra][tripleo] initial discussion for a
> new periodic pipeline
> Message-ID: <20170308182952.GG12827 at yuggoth.org>
> Content-Type: text/plain; charset=us-ascii
>
> On 2017-03-07 10:12:58 -0500 (-0500), Wesley Hayutin wrote:
> > The TripleO team would like to initiate a conversation about the
> > possibility of creating a new pipeline in Openstack Infra to allow
> > a set of jobs to run periodically every four hours
> [...]
>
> The request doesn't strike me as contentious/controversial. Why not
> just propose your addition to the zuul/layout.yaml file in the
> openstack-infra/project-config repo and hash out any resulting
> concerns via code review?
> --
> Jeremy Stanley
>
>
>
> ------------------------------
>
> Message: 39
> Date: Wed, 8 Mar 2017 13:03:58 -0600
> From: Matthew Thode <prometheanfire at gentoo.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [requirements] pycrypto is dead, long live
> pycryptodome... or cryptography...
> Message-ID: <cba43a52-7c71-5ad0-15c1-5127ff4c302e at gentoo.org>
> Content-Type: text/plain; charset="utf-8"
>
> So, pycrypto upstream is dead and has been for a while, we should look
> at moving off of it for both bugfix and security reasons.
>
> Currently it's used by the following.
>
> barbican, cinder, trove, glance, heat, keystoneauth, keystonemiddleware,
> kolla, openstack-ansible, and a couple of other smaller places.
>
> Development of it was forked into pycryptodome, which is supposed to be
> a drop in replacement. The problem is that due to co-installability
> requirements we can't have half of packages out there using pycrypto and
> the other half using pycryptodome. We'd need to hard switch everyone as
> both packages install into the same namespace.
>
> Another alternative would be to use something like cryptography instead,
> though it is not a drop in replacement, the migration would be able to
> be done piecemeal.
>
> I'd be interested in hearing about migration plans, especially from the
> affected projects.
>
> --
> Matthew Thode (prometheanfire)
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: OpenPGP digital signature
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170308/60a34707/attachment-0001.pgp>
>
> ------------------------------
>
> Message: 40
> Date: Wed, 8 Mar 2017 20:04:10 +0100
> From: Andreas Jaeger <aj at suse.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev]
> [cinder][glance][horizon][keystone][nova][qa][swift] Feedback needed:
> Removal of legacy per-project vanity domain redirects
> Message-ID: <9617a5f5-2f01-c713-c1bf-86c6308422f3 at suse.com>
> Content-Type: text/plain; charset="windows-1252"
>
> On 2017-03-08 17:23, Brian Rosmaita wrote:
> > On 3/8/17 10:12 AM, Monty Taylor wrote:
> >> Hey all,
> >>
> >> We have a set of old vanity redirect URLs from back when we made a URL
> >> for each project:
> >>
> >> cinder.openstack.org
> >> glance.openstack.org
> >> horizon.openstack.org
> >> keystone.openstack.org
> >> nova.openstack.org
> >> qa.openstack.org
> >> swift.openstack.org
> >>
> >> They are being served from an old server we'd like to retire. Obviously,
> >> moving a set of http redirects is trivial, but these domains have been
> >> deprecated for about 4 now, so we figured we'd clean house if we can.
> >>
> >> We know that the swift team has previously expressed that there are
> >> links out in the wild pointing to swift.o.o/content that still work and
> >> that they don't want to break anyone, which is fine. (although if the
> >> swift team has changed their minds, that's also welcome)
> >>
> >> for the rest of you, can we kill these rather than transfer them?
> >
> > My concern is that glance.openstack.org is easy to remember and type, so
> > I imagine there are links out there that we have no control over using
> > that URL. So what are the consequences of it 404'ing or "site cannot be
> > reached" in a browser?
> >
> > glance.o.o currently redirects to docs.o.o/developer/glance
> >
> > If glance.o.o failed for me, I'd next try openstack.org (or
> > www.openstack.org). Those would give me a page with a top bar of links,
> > one of which is DOCS. If I took that link, I'd get the docs home page.
> >
> > There's a search bar there; typing in 'glance' gets me
> > docs.o.o/developer/glance as the first hit.
> >
> > If instead I scroll past the search bar, I have to scroll down to
> > "Project-Specific Guides" and follow "Services & Libraries" ->
> > "Openstack Services" -> "image service (glance) ->
> docs.o.o/developer/glance
> >
> > Which sounds kind of bad ... until I type "glance docs" into google.
> > Right now the first hit is docs.o.o/developer/glance. And all the kids
> > these days use the google. So by trying to be clever and hack the URL,
> > I could get lost, but if I just google 'glance docs', I find what I'm
> > looking for right away.
> >
> > So I'm willing to go with the majority on this, with the caveat that if
> > one or two teams keep the redirect, it's going to be confusing to end
> > users if the redirect doesn't work for other projects.
>
> Very few people know about these URLs at all and there are only a few
> places that use it in openstack (I just send a few patches for those).
> If you google for "openstack glance", you won't get this URL at all,
>
> Andreas
> --
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
> GF: Felix Imend?rffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG N?rnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
>
>
>
> ------------------------------
>
> Message: 41
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [kolla] kolla 4.0.0.0rc2 (ocata)
> Message-ID:
> <mailman.43.1489001100.16299.openstack-dev at lists.openstack.org>
>
>
> Hello everyone,
>
> A new release candidate for kolla for the end of the Ocata
> cycle is available! You can find the source code tarball at:
>
> https://tarballs.openstack.org/kolla/
>
> Unless release-critical issues are found that warrant a release
> candidate respin, this candidate will be formally released as the
> final Ocata release. You are therefore strongly
> encouraged to test and validate this tarball!
>
> Alternatively, you can directly test the stable/ocata release
> branch at:
>
> http://git.openstack.org/cgit/openstack/kolla/log/?h=stable/ocata
>
> Release notes for kolla can be found at:
>
> http://docs.openstack.org/releasenotes/kolla/
>
>
>
>
>
> ------------------------------
>
> Message: 42
> Date: Wed, 8 Mar 2017 14:11:59 -0500
> From: Davanum Srinivas <davanum at gmail.com>
> To: prometheanfire at gentoo.org, "OpenStack Development Mailing List
> (not for usage questions)" <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [requirements] pycrypto is dead, long
> live pycryptodome... or cryptography...
> Message-ID:
> <CANw6fcGdUcLiUme3mVEdf-EL=gsFYzGj6y0soR4313atLAWUFg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Matthew,
>
> Please see the last time i took inventory:
> https://review.openstack.org/#/q/pycryptodome+owner:dims-v
>
> Thanks,
> Dims
>
> On Wed, Mar 8, 2017 at 2:03 PM, Matthew Thode <prometheanfire at gentoo.org>
> wrote:
> > So, pycrypto upstream is dead and has been for a while, we should look
> > at moving off of it for both bugfix and security reasons.
> >
> > Currently it's used by the following.
> >
> > barbican, cinder, trove, glance, heat, keystoneauth, keystonemiddleware,
> > kolla, openstack-ansible, and a couple of other smaller places.
> >
> > Development of it was forked into pycryptodome, which is supposed to be
> > a drop in replacement. The problem is that due to co-installability
> > requirements we can't have half of packages out there using pycrypto and
> > the other half using pycryptodome. We'd need to hard switch everyone as
> > both packages install into the same namespace.
> >
> > Another alternative would be to use something like cryptography instead,
> > though it is not a drop in replacement, the migration would be able to
> > be done piecemeal.
> >
> > I'd be interested in hearing about migration plans, especially from the
> > affected projects.
> >
> > --
> > Matthew Thode (prometheanfire)
> >
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
>
>
> ------------------------------
>
> Message: 43
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [kolla] kolla-ansible 4.0.0.0rc2 (ocata)
> Message-ID:
> <mailman.44.1489001100.16299.openstack-dev at lists.openstack.org>
>
>
> Hello everyone,
>
> A new release candidate for kolla-ansible for the end of the Ocata
> cycle is available! You can find the source code tarball at:
>
> https://tarballs.openstack.org/kolla-ansible/
>
> Unless release-critical issues are found that warrant a release
> candidate respin, this candidate will be formally released as the
> final Ocata release. You are therefore strongly
> encouraged to test and validate this tarball!
>
> Alternatively, you can directly test the stable/ocata release
> branch at:
>
> http://git.openstack.org/cgit/openstack/kolla-ansible/log/?
> h=stable/ocata
>
> Release notes for kolla-ansible can be found at:
>
> http://docs.openstack.org/releasenotes/kolla-ansible/
>
>
>
>
>
> ------------------------------
>
> Message: 44
> Date: Wed, 8 Mar 2017 14:17:59 -0500
> From: Steve Martinelli <s.martinelli at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev]
> [cinder][glance][horizon][keystone][nova][qa][swift] Feedback needed:
> Removal of legacy per-project vanity domain redirects
> Message-ID:
> <CAHc_MXFwSyZE8Uisk6gkw=TiZvZduS-_PE0DAWVuqb0CfrEzSQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Mar 8, 2017 at 2:04 PM, Andreas Jaeger <aj at suse.com> wrote:
> >
> > Very few people know about these URLs at all and there are only a few
> > places that use it in openstack (I just send a few patches for those).
> >
>
> ++
>
> I had no idea they existed...
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170308/984fa20f/attachment-0001.html>
>
> ------------------------------
>
> Message: 45
> Date: Wed, 8 Mar 2017 13:24:50 -0600
> From: Matthew Thode <prometheanfire at gentoo.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [requirements] pycrypto is dead, long
> live pycryptodome... or cryptography...
> Message-ID: <b6af5257-85dd-28be-2629-0ada5af81b7c at gentoo.org>
> Content-Type: text/plain; charset="utf-8"
>
> I'm aware, iirc it was brought up when pysaml2 had to be fixed due to a
> CVE. This thread is more looking for a long term fix.
>
> On 03/08/2017 01:11 PM, Davanum Srinivas wrote:
> > Matthew,
> >
> > Please see the last time i took inventory:
> > https://review.openstack.org/#/q/pycryptodome+owner:dims-v
> >
> > Thanks,
> > Dims
> >
> > On Wed, Mar 8, 2017 at 2:03 PM, Matthew Thode <prometheanfire at gentoo.org>
> wrote:
> >> So, pycrypto upstream is dead and has been for a while, we should look
> >> at moving off of it for both bugfix and security reasons.
> >>
> >> Currently it's used by the following.
> >>
> >> barbican, cinder, trove, glance, heat, keystoneauth, keystonemiddleware,
> >> kolla, openstack-ansible, and a couple of other smaller places.
> >>
> >> Development of it was forked into pycryptodome, which is supposed to be
> >> a drop in replacement. The problem is that due to co-installability
> >> requirements we can't have half of packages out there using pycrypto and
> >> the other half using pycryptodome. We'd need to hard switch everyone as
> >> both packages install into the same namespace.
> >>
> >> Another alternative would be to use something like cryptography instead,
> >> though it is not a drop in replacement, the migration would be able to
> >> be done piecemeal.
> >>
> >> I'd be interested in hearing about migration plans, especially from the
> >> affected projects.
> >>
> >> --
> >> Matthew Thode (prometheanfire)
> >>
> >>
> >> ____________________________________________________________
> ______________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
>
>
> --
> Matthew Thode (prometheanfire)
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: OpenPGP digital signature
> URL: <http://lists.openstack.org/pipermail/openstack-dev/
> attachments/20170308/b44eb072/attachment.pgp>
>
> ------------------------------
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> End of OpenStack-dev Digest, Vol 59, Issue 24
> *********************************************
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170312/2f45dbe0/attachment-0001.html>
More information about the OpenStack-dev
mailing list