[openstack-dev] OpenStack-dev Digest, Vol 51, Issue 42
Data Chennai
13datacaptain at gmail.com
Wed Jul 20 19:31:06 UTC 2016
On Thu, Jul 21, 2016 at 12:53 AM, <openstack-dev-request at lists.openstack.org
> wrote:
> 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. Re: [horizon] Plugin stability, failing tests etc. (Hayes, Graham)
> 2. Re: [Magnum] Does Docker-Swarm not support inter-node/vm
> inter-container networking ? (Ton Ngo)
> 3. [monasca] Monasca Mid-Cycle Minutes (Fabio Giannetti (fgiannet))
> 4. Re: [Glare][Heat][TripleO] Heat artifact type (Mikhail Fedosin)
> 5. [requirements] Project Mascot (Swapnil Kulkarni (coolsvap))
> 6. Re: [devstack] How to enable SSL in devStack? (Rob Crittenden)
> 7. Re: [horizon] Plugin stability, failing tests etc. (Rob Cresswell)
> 8. [Monasca] Virtual Mid Cycle Coordinates - July 20
> (Fabio Giannetti (fgiannet))
> 9. Re: [heat][yaql] Heat map replacement options (Zane Bitter)
> 10. Re: [Glare][Heat][TripleO] Heat artifact type (Randall Burt)
> 11. Re: [tc][all] Big tent? (Related to Plugins for all)
> (James Bottomley)
> 12. [searchlight] Thursday July 21 meeting cancelled
> (Tripp, Travis S)
> 13. Re: [TripleO] Delorean fail blocks CI for stable branches
> (Sagi Shnaidman)
> 14. [new][glance] glance_store 0.14.0 release (newton)
> (no-reply at openstack.org)
> 15. Re: [tc][all] Big tent? (Related to Plugins for all)
> (Fox, Kevin M)
> 16. Re: FPGA as a dynamic nested resources (Ed Leafe)
> 17. Re: [horizon] Plugin stability, failing tests etc.
> (Kirill Zaitsev)
> 18. Re: [Glare][Heat][TripleO] Heat artifact type (Fox, Kevin M)
> 19. Re: [horizon] Plugin stability, failing tests etc. (Hayes, Graham)
> 20. Re: [TripleO] Delorean fail blocks CI for stable branches
> (Alan Pevec)
> 21. Re: [TripleO] Delorean fail blocks CI for stable branches
> (Alan Pevec)
> 22. Re: OpenStack Kolla - External Ceph (Jeffrey Zhang)
> 23. Re: [tc][all] Big tent? (Related to Plugins for all)
> (James Bottomley)
> 24. Re: OpenStack Kolla - External Ceph (Fox, Kevin M)
> 25. Re: [horizon] Plugin stability, failing tests etc. (Rob Cresswell)
> 26. Re: [devstack] How to enable SSL in devStack? (Rob Crittenden)
> 27. Re: [tc][all] Big tent? (Related to Plugins for all) (Clint Byrum)
> 28. Re: [TripleO] Delorean fail blocks CI for stable branches
> (Sagi Shnaidman)
> 29. Re: [Nova] [RFC] ResourceProviderTags - Manage Capabilities
> with ResourceProvider (Jay Pipes)
> 30. Re: [Nova] [RFC] ResourceProviderTags - Manage Capabilities
> with ResourceProvider (Jay Pipes)
> 31. Re: [tc][all] Big tent? (Related to Plugins for all)
> (Fox, Kevin M)
> 32. Re: [tc][all] Big tent? (Related to Plugins for all)
> (Duncan Thomas)
> 33. Re: [charms] Project mascot (Billy Olsen)
> 34. Re: [Nova] [RFC] ResourceProviderTags - Manage Capabilities
> with ResourceProvider (Mooney, Sean K)
> 35. Re: Mascot/logo for your project (Amrith Kumar)
> 36. [trove] no weekly meeting next week (Amrith Kumar)
> 37. Re: [tc][all] Big tent? (Related to Plugins for all)
> (Joshua Harlow)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 20 Jul 2016 12:38:33 +0000
> From: "Hayes, Graham" <graham.hayes at hpe.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [horizon] Plugin stability, failing tests
> etc.
> Message-ID:
> <
> CS1PR84MB021511BB0BBDADAC50DC8BE090080 at CS1PR84MB0215.NAMPRD84.PROD.OUTLOOK.COM
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> On 20/07/2016 10:16, Rob Cresswell wrote:
> > Hey all,
> >
> > So we've had a few issues with plugin stability recently, and its
> > apparent that many plugins are building off Horizon master as a
> > dependency. I would really advise against this. A more manageable
> > development process may be to:
> >
> > - Base stable plugins against a stable release of Horizon
> > - Base WIP versions/new plugins off the last Horizon milestone, b2 in
> > this case, and then bump the version and capture issues within the same
> > patch. This should prevent random breakages, and should allow you to
> > just look at the release notes for that milestone.
>
> So this would mean changing tox.ini or requirements files after each
> horizon release?
>
> This dovetails nicely with the other thread about how we should be doing
> cross project interactions.
>
> What would be best, would be having horizon released as a separate
> library on pypi like the clients and oslo libs.
>
> Then openstack-dashboard, and all the plugins could rely on the same
> base library, without hacks like:
>
> deps =
> -r{toxinidir}/requirements.txt
> -r{toxinidir}/test-requirements.txt
> http://tarballs.openstack.org/horizon/horizon-master.tar.gz
>
> in tox.ini or
>
> # Testing Requirements
> http://tarballs.openstack.org/horizon/horizon-master.tar.gz#egg=horizon
>
> in (test-)requirements.txt
>
> Is that on roadmap?
>
> > On the Horizon side, we've moved our FF a week earlier, so I think that
> > week combined with the usual RC period should be enough time to fix
> > bugs. We'll aim to make sure our release notes are complete with regards
> > to breaking issues for plugins, and deprecate appropriately.
> >
> > Rob
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 20 Jul 2016 06:43:05 -0700
> From: "Ton Ngo" <ton at us.ibm.com>
> To: "OpenStack Development Mailing List \(not for usage questions\)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Magnum] Does Docker-Swarm not support
> inter-node/vm inter-container networking ?
> Message-ID:
> <
> OFA8186E94.941C9302-ON88257FF6.004B1912-88257FF6.004B5B66 at notes.na.collabserv.com
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Greg,
> We should have patches in the next few weeks and the target is to have
> this functionality in the Newton cycle.
> Ton Ngo,
>
>
>
> From: "Waines, Greg" <Greg.Waines at windriver.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Date: 07/20/2016 04:51 AM
> Subject: Re: [openstack-dev] [Magnum] Does Docker-Swarm not support
> inter-node/vm inter-container networking ?
>
>
>
> Thanks Ton,
>
> When is the Docker libnetwork functionality forecasted to be available ?
>
> Greg.
>
> From: Ton Ngo <ton at us.ibm.com>
> Reply-To: "openstack-dev at lists.openstack.org"
> <openstack-dev at lists.openstack.org>
> Date: Tuesday, July 19, 2016 at 6:58 PM
> To: "openstack-dev at lists.openstack.org" <openstack-dev at lists.openstack.org
> >
> Subject: Re: [openstack-dev] [Magnum] Does Docker-Swarm not support
> inter-node/vm inter-container networking ?
>
>
>
> Hi Greg,
> This is a capability that we are working on at this time: enabling Docker
> libnetwork using the Kuryr driver.
> This will let you set up networks where the containers are connected to and
> they will be allocated unique routable IP.
> In the current default networking mode, you can still let container
> provides service to each other through Docker
> port mapping. The end point for the container service would be the IP
> address of the VM where the container is hosted
> together with the port mapped. You just cannot ping from one container to
> another across VM's in this mode.
> Ton Ngo,
>
>
> nactive hide details for "Waines, Greg" ---07/19/2016 11:12:50 AM---I hav
> "Waines, Greg" ---07/19/2016 11:12:50 AM---I have successfully setup
> devstack with Magnum, following this link https://github.com/openstack/mag
>
> From: "Waines, Greg" <Greg.Waines at windriver.com>
> To: "openstack-dev at lists.openstack.org" <openstack-dev at lists.openstack.org
> >
> Date: 07/19/2016 11:12 AM
> Subject: [openstack-dev] [Magnum] Does Docker-Swarm not support
> inter-node/vm inter-container networking ?
>
>
>
>
> I have successfully setup devstack with Magnum,
> following this link
>
> https://github.com/openstack/magnum/blob/master/doc/source/dev/quickstart.rst#building-and-using-a-swarm-bay
>
>
> I created a Docker-Swarm bay and successfully launched some simple
> containers.
>
> I noticed that Docker-Swarm?s Container Networking Solution seems to simply
> be an SNAT on its swarm-node VM.
> And noticed that Docker-Swarm assigns the same Container subnet to each
> swarm-node VM ? and re-uses Container IP Addresses from this subnet across
> swarm-node VMs.
>
> Given this ? it does not appear that Docker-Swarm can support networking
> between two containers on different swarm-node VMs.
> Is this True ?
> OR
> Is there a configuration option, thru Magnum or Docker-Swarm to enable this
> inter-node inter-container Networking ?
>
> Greg.
> __________________________________________________________________________
> 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
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/051032da/attachment-0001.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: graycol.gif
> Type: image/gif
> Size: 105 bytes
> Desc: not available
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/051032da/attachment-0002.gif
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: 16652257.gif
> Type: image/gif
> Size: 106 bytes
> Desc: not available
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/051032da/attachment-0003.gif
> >
>
> ------------------------------
>
> Message: 3
> Date: Wed, 20 Jul 2016 13:54:05 +0000
> From: "Fabio Giannetti (fgiannet)" <fgiannet at cisco.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [monasca] Monasca Mid-Cycle Minutes
> Message-ID: <D3B4D03A.23C26%fgiannet at cisco.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Notes for Monasca July Mid Cycle 2016
>
> Minutes July 19 from 10:30am PDT to
>
> Dimensions Names/Values resources
>
> This blueprint needs to be updated. The PATCH part needs to be updated.
> The new URL is metrics/dimensions/names/values
> The use case is driven by Grafana and is part of the templating. In order
> to get the list of unique dimension names you have to do a query for all
> the metrics.
> The blueprint is implemented already in Java and Python and the
> implementation has been gone through a good testing. It has been
> implemented for Vertica and InfluxDB.
> Brad to update the blueprint to relect the latest design changes.
>
> Open Discussion
> Is the vision for this project to be only for Openstack or it is possible
> to extend it to other projects?
> The only dependency of the project is on Keystone and once that is removed
> the project can be used.
> It is possible in the Python version to remove Keystone from the Pipeline
> and manually provide the header data so then the API will find the context.
> Making Monasca more separate from Openstack. This will require a pluggable
> authentication mechanism.
> Grafana already supports various Multitenancy capabilties but Kibana is
> not that flexible. It seems both support LDAP.
>
> Retrospective
>
> What we have done good
> Cool New feature added. Logging API, deterministic alarms, periodic
> notificaitons
> Good progress in adding new features
> Multiple metrics was a good perfomance improvement. From 60s to 1s.
> Well integrated in the Openstack process.
> Good/Flexible architecture
> More visibility in the community. Limited contributions from the "other"
> teams.
>
> What we could have done better
> Installation is still complex and cumbersome, not well documented. Need of
> a Monasca administration guide. Better docs in general would help.
> Create an official tutorial.
> Replacing Java API in Persister. It is difficult for new contributor to
> come to the project. Single API change can take 2 weeks. Java+Python and 3
> databases.
> Focus on polishing what is already available instead of expanding the
> scope.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/29ee6c53/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Wed, 20 Jul 2016 16:58:31 +0300
> From: Mikhail Fedosin <mfedosin at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Glare][Heat][TripleO] Heat artifact type
> Message-ID:
> <CAGk9pwa39AJcFqv7gSP8jVRa08kcjcv5dabBqxs4SfNs==
> hZWg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Jul 20, 2016 at 5:12 AM, Qiming Teng <tengqim at linux.vnet.ibm.com>
> wrote:
>
> > On Tue, Jul 19, 2016 at 06:44:06PM +0300, Oleksii Chuprykov wrote:
> > > Hello!
> > >
> > > Today it was announced that Glare is ready for public review
> > >
> http://lists.openstack.org/pipermail/openstack-dev/2016-July/099553.html
> > So
> > > we are ready to start working on integration Heat with Glare and
> > > implementing a POC. After discussions with Glare team we see two design
> > > options:
> > >
> > > 1) Create one artifact type that will contain template, nested
> templates
> > > and environments.
> > > Pros: It is easy to maintain integrity. Since artifact is immutable, we
> > can
> > > guarantee the consistency and prevent from accidentally removing of
> > > dependent environment.
> > > Cons: If we need to add new environments to use them with template, we
> > need
> > > to create new artifact.
> > >
> > > 2) Create 2 artifact types: environment and template.
> > > Pros: It is easy to add new environments. You just need to create new
> > > dependency from template artifact to environment one.
> > > Cons: Some environment can be (mistakenly) removed, and template that
> > have
> > > dependencies on it will be in inconsistent state.
> >
> > Option 2 looks more flexible to me. I'm not sure we are encouraging
> > users to introduce or rely on a hard dependency from a template to an
> > environment file. With that, it is still good to know whether glare
> > supports the concept of 'reference' where a referenced artifact cannot
> > be deleted.
> >
>
> Hey!
>
> Indeed, option 2 is more flexible, but in this case users have to manually
> control dependencies, which is may be hard sometimes. Also, initially Glare
> won't support 'hard' dependencies, this feature will be added in next
> version, because it requires additional discussions. For this reason I
> recommend option 1 and let Glare control template consistency for you, it
> won't allow users to break anything.
>
> Best,
> Mike
>
>
> >
> > - Qiming
> >
>
> > > So we want to hear your opinions and suggestions on the matter. Thanks
> in
> > > advance!
> > >
> > > Best regards,
> > > Oleksii Chuprykov
> >
> >
> >
> __________________________________________________________________________
> > 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/20160720/17bcbda0/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Wed, 20 Jul 2016 19:30:08 +0530
> From: "Swapnil Kulkarni (coolsvap)" <me at coolsvap.net>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [requirements] Project Mascot
> Message-ID:
> <CAKO+H++QN0YmL=
> 27FCaOWB09MOEELqf2gtmjVmzz2O6zzbEJRQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hello,
>
> We had a discussion about project mascot for requirements team today
> at the team meeting. Some of the options mentioned are added to [1].
> If you have any option, please add to the list.
> Also do not forget to provide preference. We will finalize the mascot
> on Monday July 25.
>
> [1] https://etherpad.openstack.org/p/requirements-team-mascot
>
> --
> Best Regards,
> Swapnil
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 20 Jul 2016 10:01:03 -0400
> From: Rob Crittenden <rcritten at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>, "Wenzhi Yu (yuywz)"
> <wenzhi_yu at 163.com>
> Subject: Re: [openstack-dev] [devstack] How to enable SSL in devStack?
> Message-ID: <578F841F.50000 at redhat.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Andrey Pavlov wrote:
> > Hi,
> >
> > When I ran devstack with SSL I found a bug and tried to fix it -
> > https://review.openstack.org/#/c/242812/
> > But no one agree with me.
> > Try to apply this patch - it may help.
> > Also there is a chance that new bugs present in devstack that
> > prevented to install it with SSL.
>
> Seeing how some other things in your local.conf might help but when I
> tried to reproduce it I got the same error and it failed because Apache
> didn't have an SSL listener on 443.
>
> I'm not sure I'd recommend direct SSL in any case. I'd recommend the
> tls-proxy service instead. Note that I'm pretty sure it has the same
> problem: it hasn't been updated to handle port 443 for Keystone.
>
> I'm working on switching from stud to mod_proxy if you want to take a
> look and this problem is fixed there, https://review.openstack.org/301172
>
> I'll see about adding a SSL listener to Keystone for the USE_SSL case in
> the next few days.
>
> And yeah, it's a moving target. I have an experimental gate test for
> tlsproxy but it has to be requested explicitly. My plan is to enable it
> as non-voting once the mod_proxy changes land so it will at least be
> more obvious when things break (or maybe we can making it voting).
>
> rob
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 20 Jul 2016 14:08:56 +0000
> From: Rob Cresswell <robert.cresswell at outlook.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [horizon] Plugin stability, failing tests
> etc.
> Message-ID:
> <
> AM3PR06MB0936D0ABDF274888858D5A7088080 at AM3PR06MB0936.eurprd06.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> Yes, it would mean changing your requirements after a release. So, for
> example you might run two gate tests:
>
> - A voting Horizon-stable/milestone test, (or both)
> - A non-voting Horizon-master test
>
> That gives you a lot of control over making your tests passing (multiple
> patches to make the Horizon-master test pass, or all in one patch set
> alongside the horizon-milestone test bump), rather than random failures
> each week. You'd still be able to track the failures as they come in, but
> they won't break your gate each time.
>
> I don't think where horizon (the library) lives would change how you
> version against it. We don't currently have any plans to separate the two;
> while we realise its a desirable change, weighing the work and risk
> involved in the split architecture vs the end result, we've chosen to work
> on other higher priority items for now (performance, filtering
> improvements, angular work etc.)
>
> Rob
>
>
>
> On 20 July 2016 at 13:38, Hayes, Graham <graham.hayes at hpe.com<mailto:
> graham.hayes at hpe.com>> wrote:
> On 20/07/2016 10:16, Rob Cresswell wrote:
> > Hey all,
> >
> > So we've had a few issues with plugin stability recently, and its
> > apparent that many plugins are building off Horizon master as a
> > dependency. I would really advise against this. A more manageable
> > development process may be to:
> >
> > - Base stable plugins against a stable release of Horizon
> > - Base WIP versions/new plugins off the last Horizon milestone, b2 in
> > this case, and then bump the version and capture issues within the same
> > patch. This should prevent random breakages, and should allow you to
> > just look at the release notes for that milestone.
>
> So this would mean changing tox.ini or requirements files after each
> horizon release?
>
> This dovetails nicely with the other thread about how we should be doing
> cross project interactions.
>
> What would be best, would be having horizon released as a separate
> library on pypi like the clients and oslo libs.
>
> Then openstack-dashboard, and all the plugins could rely on the same
> base library, without hacks like:
>
> deps =
> -r{toxinidir}/requirements.txt
> -r{toxinidir}/test-requirements.txt
> http://tarballs.openstack.org/horizon/horizon-master.tar.gz
>
> in tox.ini or
>
> # Testing Requirements
> http://tarballs.openstack.org/horizon/horizon-master.tar.gz#egg=horizon
>
> in (test-)requirements.txt
>
> Is that on roadmap?
>
> > On the Horizon side, we've moved our FF a week earlier, so I think that
> > week combined with the usual RC period should be enough time to fix
> > bugs. We'll aim to make sure our release notes are complete with regards
> > to breaking issues for plugins, and deprecate appropriately.
> >
> > Rob
>
>
> __________________________________________________________________________
> 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/20160720/5f737d0e/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 8
> Date: Wed, 20 Jul 2016 14:10:07 +0000
> From: "Fabio Giannetti (fgiannet)" <fgiannet at cisco.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [Monasca] Virtual Mid Cycle Coordinates -
> July 20
> Message-ID: <D3B4D43B.23C36%fgiannet at cisco.com>
> Content-Type: text/plain; charset="us-ascii"
>
> >Monasca Mid Cycle Day 2
> >July 20 2016
> >7am to noon PDT
> >
> >Webex
> >
> >
> >Join WebEx meeting:
> >
> https://cisco.webex.com/ciscosales/j.php?MTID=m84f9f81d7c1c171be6365716522
> >d
> >e15e
> >
> >Meeting number: 205 141 519
> >Meeting password: 8VyzUiyr
> >
> >Join by phone
> >+1-408-525-6800 Call-in toll number (US/Canada)
> >+1-866-432-9903 Call-in toll-free number (US/Canada)
> >Access code: 205 141 519
> >Numeric meeting password: 01558880
>
>
>
>
> ------------------------------
>
> Message: 9
> Date: Wed, 20 Jul 2016 10:32:04 -0400
> From: Zane Bitter <zbitter at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [heat][yaql] Heat map replacement options
> Message-ID: <38d79a1d-282a-93ab-2314-767c1773b455 at redhat.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 19/07/16 11:04, Steven Hardy wrote:
> > On Fri, Jul 15, 2016 at 10:25:39AM +0100, Steven Hardy wrote:
> >> Hi all,
> >>
> >> I'm trying to figure out the cleanest way to do a replacement of values
> in
> >> a mapping (json parameter) in a heat template, e.g:
> >>
> >> ServiceNetMap:
> >> type: json
> >> default:
> >> IronicApiNetwork: internal_api
> >> CephPublicNetwork: storage
> >>
> >> NetIpMap:
> >> type: json
> >> default:
> >> storage: 192.0.2.2
> >> internal_api: 192.0.2.5
> >>
> >> How do I get
> >> OutputMap:
> >> IronicApiNetwork: 192.0.2.5
> >> CephPublicNetwork: 192.0.2.2
> >>
> >> It seems like something yaql should be able to do, but I've so far
> failed
> >> to figure out the syntax.
> >>
> >> The other (possibly simpler) possibility is to implement a new hot
> >> function, e.g something like:
> >>
> >> map_replace:
> >> template: {get_param: ServiceNetMap}
> >> value_replacements: {get_param: NetIpMap}
> >
> > As a follow-up to this, I have posted this spec and implementation for
> > map_replace (syntax differs slightly from the keys above):
> >
> > https://review.openstack.org/#/c/343696/
> >
> > https://review.openstack.org/#/c/343731/
> >
> > My aim is a simpler interface to the yaql example previously discussed,
> and
> > a better error path when things like key collisions occur. Reviews
> welcome! :)
>
> This all merged in super-quick time before I even had the chance to
> look, but I was wondering... is there really any difference between this
> and str_replace?
>
> Right now str_replace requires the template to be a string, but I can't
> see any reason for that to be the case. Why not just relax that
> requirement so the user can pass map or a list and any strings in the
> values/items will get (recursively) replaced by values from the params?
>
> That'd be simpler than adding a separate function, and more flexible too
> since you can replace parts of values not just the whole thing (and it
> would also handle lists and nested data). The map_replace is very tied
> to this one particular use case, where the input is a map and the things
> you want to replace are top-level values in their entirety.
>
> Just a thought.
>
> cheers,
> Zane.
>
>
>
> ------------------------------
>
> Message: 10
> Date: Wed, 20 Jul 2016 15:18:41 +0000
> From: Randall Burt <randall.burt at RACKSPACE.COM>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Glare][Heat][TripleO] Heat artifact type
> Message-ID: <D5365681-FA7A-47D2-838A-8F258D6B4E46 at rackspace.com>
> Content-Type: text/plain; charset="us-ascii"
>
> FWIW, option 2 is almost required unless we plan to be able to bundle
> multiple environments with a single template. While having a single
> environment for a single template can be useful, the even *more* useful
> scenario (and the primary one driving the development of environments
> initially) is when you have options as to how a template behaves (use Trove
> for the backend or pop vms and software config to install a database). IMO,
> you'd want to de-couple environments from the templates given that multiple
> environment could work for the same template.
>
> On Jul 20, 2016, at 8:58 AM, "Mikhail Fedosin" <mfedosin at mirantis.com>
> wrote:
>
> >
> >
> > On Wed, Jul 20, 2016 at 5:12 AM, Qiming Teng <tengqim at linux.vnet.ibm.com>
> wrote:
> > On Tue, Jul 19, 2016 at 06:44:06PM +0300, Oleksii Chuprykov wrote:
> > > Hello!
> > >
> > > Today it was announced that Glare is ready for public review
> > >
> http://lists.openstack.org/pipermail/openstack-dev/2016-July/099553.html
> So
> > > we are ready to start working on integration Heat with Glare and
> > > implementing a POC. After discussions with Glare team we see two design
> > > options:
> > >
> > > 1) Create one artifact type that will contain template, nested
> templates
> > > and environments.
> > > Pros: It is easy to maintain integrity. Since artifact is immutable,
> we can
> > > guarantee the consistency and prevent from accidentally removing of
> > > dependent environment.
> > > Cons: If we need to add new environments to use them with template, we
> need
> > > to create new artifact.
> > >
> > > 2) Create 2 artifact types: environment and template.
> > > Pros: It is easy to add new environments. You just need to create new
> > > dependency from template artifact to environment one.
> > > Cons: Some environment can be (mistakenly) removed, and template that
> have
> > > dependencies on it will be in inconsistent state.
> >
> > Option 2 looks more flexible to me. I'm not sure we are encouraging
> > users to introduce or rely on a hard dependency from a template to an
> > environment file. With that, it is still good to know whether glare
> > supports the concept of 'reference' where a referenced artifact cannot
> > be deleted.
> >
> > Hey!
> >
> > Indeed, option 2 is more flexible, but in this case users have to
> manually control dependencies, which is may be hard sometimes. Also,
> initially Glare won't support 'hard' dependencies, this feature will be
> added in next version, because it requires additional discussions. For this
> reason I recommend option 1 and let Glare control template consistency for
> you, it won't allow users to break anything.
> >
> > Best,
> > Mike
> >
> >
> > - Qiming
> >
> > > So we want to hear your opinions and suggestions on the matter. Thanks
> in
> > > advance!
> > >
> > > Best regards,
> > > Oleksii Chuprykov
> >
> >
> >
> __________________________________________________________________________
> > 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: 11
> Date: Wed, 20 Jul 2016 08:31:34 -0700
> From: James Bottomley <James.Bottomley at HansenPartnership.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>, Clint Byrum <clint at fewbar.com
> >
> Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins
> for all)
> Message-ID: <1469028694.2424.49.camel at HansenPartnership.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, 2016-07-20 at 11:58 +0200, Julien Danjou wrote:
> > On Tue, Jul 19 2016, Clint Byrum wrote:
> >
> > > Perhaps if we form and start working together as a group, we can
> > > disect why nothing happened, build consensus on the most important
> > > thing to do next, and actually fix some architectural problems.
>
> Architecture is often blamed for lack of interlock but most people
> forget that the need for interlock often isn't appreciated until after
> the components are built. This is why a lot of people embrace agile
> methodology (an excuse for not seeing the problem a priori).
>
> Conversely, architects who try to foresee all interlocks often end up
> with a combinatorial explosion that makes it a huge burden simply to
> begin the project (and then often get sidelined as 'powerpoint
> engineers').
>
> The trick is to do something in the middle: try to foresee and build
> the most common interlocks, but sidestep the combinatorial explosion by
> building something simple enough to adapt to any interlock requirement
> that arises after completion.
>
> > > The social structure that teams have is a huge part of the
> > > deadlock we find ourselves in with certain controversial changes.
> > > The idea is to unroll the dependency loop and start _somewhere_
> > > rather than where a lot of these efforts die: starting
> > > _everywhere_.
> >
> > I agree with your analysis, but I fail to see how e.g. a group of
> > people X stating that Y should work this way in Cinder is going to
> > achieve any change if nobody from Cinder is in X from the beginning.
> >
> > This is basically what seems to happen in many [working] groups as
> > far as I can see.
>
> So this is where the Open Source method takes over. Change is produced
> by those people who most care about it because they're invested. To
> take your Cinder example, you're unlikely to find them within Cinder
> because any project has inertia that resists change. It takes the
> energy of the outside group X to force the change to Y, but this means
> that X often gets to propose, develop and even code Y. Essentially
> they become drive by coders for Cinder. This is where Open Source
> differs from Enterprise because you have the code and the access, you
> can do this. However, you have to remember the inertia problem and
> build what you're trying to do as incrementally as possible: the larger
> the change, the bigger the resistance to it. It's also a good test of
> the value of the change: if group X can't really be bothered to code it
> (and Cinder doesn't want it) then perhaps there's not really enough
> value in it anyway and it shouldn't happen.
>
> This latter observation is also an improvement over the enterprise
> methods because enterprise architects do often mandate interlocks that
> later turn out to be unnecessary (or at least of a lot less value than
> was initially thought).
>
> I suppose the executive summary of the above is that I don't think
> you're describing a bug, I think you're describing a feature.
>
> James
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 819 bytes
> Desc: This is a digitally signed message part
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/807333ce/attachment-0001.pgp
> >
>
> ------------------------------
>
> Message: 12
> Date: Wed, 20 Jul 2016 15:48:25 +0000
> From: "Tripp, Travis S" <travis.tripp at hpe.com>
> To: OpenStack List <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [searchlight] Thursday July 21 meeting
> cancelled
> Message-ID: <EF47110A-C82D-4B00-B407-531422A210D1 at hpe.com>
> Content-Type: text/plain; charset="utf-8"
>
> Due to our midcycle hangout today [0], we are cancelling the searchlight
> IRC meeting tomorrow (Thursday July 21).
>
> [0] https://etherpad.openstack.org/p/searchlight-newton-hangout
>
> ------------------------------
>
> Message: 13
> Date: Wed, 20 Jul 2016 18:50:23 +0300
> From: Sagi Shnaidman <sshnaidm at redhat.com>
> To: Alan Pevec <alan.pevec at redhat.com>
> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [TripleO] Delorean fail blocks CI for
> stable branches
> Message-ID:
> <CAGHQP9wzuYF=
> s9Dt6bzD_-EmP_7BU5WbicL1w_UG-azd8xGXtw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Jul 20, 2016 at 2:29 PM, Alan Pevec <apevec at redhat.com> wrote:
>
> > > git clone https://git.openstack.org/openstack/tripleo-heat-templates
> > > cd tripleo-heat-templates/
> > > git checkout -b stable/mitaka origin/stable/mitaka
> >
> > ^ this is manually switching to the stable source branch
> >
> > > sed -i -e "s%distro=.*%distro=rpm-mitaka%" projects.ini
> > > sed -i -e "s%source=.*%source=stable/mitaka%" projects.ini
> >
> > ^ this configures dlrn to the correct combination of distro and source
> > branches, but ...
> >
> > > ./venv/bin/dlrn --config-file projects.ini --head-only --package-name
> > > openstack-tripleo-heat-templates --local
> >
> > ^ ... --local here keeps local checkout untouched, so you end up with
> > default rpm-master in distro git checkout.
> > If you remove --local it will reset local checkouts to the branches
> > specified in projects.ini
> >
> > Alan,
> I don't want to reset local checkouts and reset branches - I need to build
> with these checkout, it's all CI is for.
>
>
> > Alan
> >
>
>
>
> --
> Best regards
> Sagi Shnaidman
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/90088167/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 14
> From: no-reply at openstack.org
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [new][glance] glance_store 0.14.0 release
> (newton)
> Message-ID:
> <mailman.22599.1469042581.7714.openstack-dev at lists.openstack.org>
>
> We are psyched to announce the release of:
>
> glance_store 0.14.0: OpenStack Image Service Store Library
>
> This release is part of the newton release series.
>
> With source available at:
>
> http://git.openstack.org/cgit/openstack/glance_store
>
> With package available at:
>
> https://pypi.python.org/pypi/glance_store
>
> Please report issues through launchpad:
>
> http://bugs.launchpad.net/glance-store
>
> For more details, please see below.
>
> Changes in glance_store 0.13.0..0.14.0
> --------------------------------------
>
> 79532ea Add bandit to pep8 and bandit testenv
> fd84300 Remove unused variable in vmware store
> 84e6354 Imported Translations from Zanata
> 6e7c722 Updated from global requirements
> 4b6818d Check that size is a number
> 19d8df3 Replace dict.iterkeys with six.iterkeys to make PY3 compatible
> 3e20ff9 cinder: Fix get_size return value
> 5c07499 The function add calculation size_gb need improve
> 4b10efd Updated from global requirements
> a3b298e Updated from global requirements
> fd1e846 Fix argument order for assertEqual to (expected, observed)
> f0087f3 Updated from global requirements
> a678c26 Updated from global requirements
> 5829046 Remove -c from tox.ini
> ea4483c tox respects upper-constraints.txt
> 9a58812 Updated from global requirements
> 922233f Updated from global requirements
> 55af8b5 Updated from global requirements
> 75cd233 Updated from global requirements
> 0a6124f Fix minor misspellings affecting Config Reference Guide
> 6f4bf26 Remove verbose option from glance_store tests
> 2e93319 Updated from global requirements
> 8eda73b Updated from global requirements
> 0a606a5 Improve help text of swift driver opts
> 40dded6 Updated from global requirements
> 1e87dfd Add functional tests for swift
> 25e5d19 Imported Translations from Zanata
> 7b439d6 Updated from global requirements
> 32d964f Updated from global requirements
> 4412580 Fix releasenotes to pass reno gates
> 3758022 Updated from global requirements
> 7b94d3c tox: use os-testr instead of testr
> 9addf29 Fix swiftclient mocks
> ba8e51f Deprecate swift driver options properly
> da74173 Fix typos in config files
> 1ae475c Setup defaults for swift driver authentication
> 1ce1f40 Fix doc generation warnings and errors
> 200249a trivial:fixing one W503 pep8 error
> 5c6c6e6 Module docs are not generated
> 3b53b0b Fix cinder store to support Cinder RemoteFS backends
> 3b637b4 Missing params in store_add_to_backend docstring
> 851508c Mock swiftclient's functions in tests
> 1d2474b Update reno for stable/mitaka
> a9d6cce Add base for functional tests
>
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> .gitignore | 3 +
> .testr.conf | 2 +-
> functional_testing.conf.sample | 9 +
> glance_store/_drivers/cinder.py | 12 +-
> glance_store/_drivers/filesystem.py | 4 +-
> glance_store/_drivers/http.py | 2 +-
> glance_store/_drivers/sheepdog.py | 7 +-
> glance_store/_drivers/swift/store.py | 196 +++++++++++---
> glance_store/_drivers/swift/utils.py | 36 ++-
> glance_store/_drivers/vmware_datastore.py | 7 +-
> glance_store/backend.py | 2 +
> .../en_GB/LC_MESSAGES/glance_store-log-warning.po | 19 ++
> .../locale/en_GB/LC_MESSAGES/glance_store.po | 246 +++++++++++++++++
> .../es/LC_MESSAGES/glance_store-log-warning.po | 8 +-
> .../fr/LC_MESSAGES/glance_store-log-warning.po | 8 +-
> glance_store/locale/glance_store-log-warning.pot | 25 --
> glance_store/locale/glance_store.pot | 290
> ---------------------
> ...event-unauthorized-errors-ebb9cf2236595cd0.yaml | 12 +-
> releasenotes/source/index.rst | 1 +
> .../locale/en_GB/LC_MESSAGES/releasenotes.po | 113 ++++++++
> releasenotes/source/mitaka.rst | 6 +
> requirements.txt | 12 +-
> setup.cfg | 8 +-
> test-requirements.txt | 12 +-
> tools/colorizer.py | 3 +-
> tools/tox_install.sh | 55 ++++
> tox.ini | 34 ++-
> 42 files changed, 1167 insertions(+), 557 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/requirements.txt b/requirements.txt
> index f102881..a83ce1a 100644
> --- a/requirements.txt
> +++ b/requirements.txt
> @@ -4 +4 @@
> -oslo.config>=3.7.0 # Apache-2.0
> +oslo.config>=3.10.0 # Apache-2.0
> @@ -7,3 +7,3 @@ oslo.serialization>=1.10.0 # Apache-2.0
> -oslo.utils>=3.5.0 # Apache-2.0
> -oslo.concurrency>=3.5.0 # Apache-2.0
> -stevedore>=1.5.0 # Apache-2.0
> +oslo.utils>=3.14.0 # Apache-2.0
> +oslo.concurrency>=3.8.0 # Apache-2.0
> +stevedore>=1.10.0 # Apache-2.0
> @@ -17,2 +17,2 @@ jsonschema!=2.5.0,<3.0.0,>=2.0.0 # MIT
> -python-keystoneclient!=1.8.0,!=2.1.0,>=1.6.0 # Apache-2.0
> -requests!=2.9.0,>=2.8.1 # Apache-2.0
> +python-keystoneclient!=1.8.0,!=2.1.0,>=1.7.0 # Apache-2.0
> +requests>=2.10.0 # Apache-2.0
> diff --git a/test-requirements.txt b/test-requirements.txt
> index 8c6627d..b45ee6f 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -8 +8 @@ hacking<0.11,>=0.10.0
> -mock>=1.2 # BSD
> +mock>=2.0 # BSD
> @@ -12 +12 @@ coverage>=3.6 # Apache-2.0
> -fixtures>=1.3.1 # Apache-2.0/BSD
> +fixtures>=3.0.0 # Apache-2.0/BSD
> @@ -14 +14 @@ python-subunit>=0.0.18 # Apache-2.0/BSD
> -requests-mock>=0.7.0 # Apache-2.0
> +requests-mock>=1.0 # Apache-2.0
> @@ -18,0 +19,2 @@ oslotest>=1.10.0 # Apache-2.0
> +os-testr>=0.7.0 # Apache-2.0
> +bandit>=1.0.1 # Apache-2.0
> @@ -21 +23 @@ oslotest>=1.10.0 # Apache-2.0
> -sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
> +sphinx!=1.3b1,<1.3,>=1.2.1 # BSD
> @@ -23 +25 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
> -reno>=0.1.1 # Apache2
> +reno>=1.8.0 # Apache2
>
>
>
>
>
> ------------------------------
>
> Message: 15
> Date: Wed, 20 Jul 2016 16:08:22 +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>, Clint Byrum <clint at fewbar.com
> >
> Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins
> for all)
> Message-ID:
> <1A3C52DFCD06494D8528644858247BF01B9A6B50 at EX10MBOX03.pnnl.gov>
> Content-Type: text/plain; charset="us-ascii"
>
> +1 to the finding of a middle ground.
>
> The problem I've seen with your suggested OpenSource solution is the
> current social monetary system of OpenStack makes it extremely difficult.
>
> Each project currently prints its own currency. Reviews. It takes quite a
> few Reviews (time/effort) on a project to gain enough currency that you get
> payed attention to. And, one project doesn't honor another projects
> currency.
>
> When these sorts of major cross project things need to be done though, you
> need to have folks with capital in many different projects and its very
> difficult to amass that much.
>
> There is no OpenStack level currency (other then being elected as a TC
> member) that gets one project to stop and take the time to carefully
> consider what someone is saying when bringing up cross project issues.
>
> Without some shared currency, then the problem becomes, the person
> invested in getting a solution, can propose and prototype and implement the
> feature all they want (often several times), but it never actually is
> accepted into the projects because a project:
> a) doesn't take the time to really understand the problem, feeling its
> trivial and just not accepting any reviews
> b) doesn't take the time to really understand the problem, so minimize it
> in their mind to a 'you should just use existing thing X...' or a heavy
> handily propose alternate solutions that really aren't solutions.
> c) they decide its better handled by another project and stall/block
> reviews, trying to push the implementation to go elsewhere. When multiple
> projects decide this, the ball just keeps getting bounced around without
> any solution for years.
>
> The status quo is not working here. The current governance structure
> doesn't support progress.
>
> Thanks,
> Kevin
> ________________________________________
> From: James Bottomley [James.Bottomley at HansenPartnership.com]
> Sent: Wednesday, July 20, 2016 8:31 AM
> To: OpenStack Development Mailing List (not for usage questions); Clint
> Byrum
> Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for
> all)
>
> On Wed, 2016-07-20 at 11:58 +0200, Julien Danjou wrote:
> > On Tue, Jul 19 2016, Clint Byrum wrote:
> >
> > > Perhaps if we form and start working together as a group, we can
> > > disect why nothing happened, build consensus on the most important
> > > thing to do next, and actually fix some architectural problems.
>
> Architecture is often blamed for lack of interlock but most people
> forget that the need for interlock often isn't appreciated until after
> the components are built. This is why a lot of people embrace agile
> methodology (an excuse for not seeing the problem a priori).
>
> Conversely, architects who try to foresee all interlocks often end up
> with a combinatorial explosion that makes it a huge burden simply to
> begin the project (and then often get sidelined as 'powerpoint
> engineers').
>
> The trick is to do something in the middle: try to foresee and build
> the most common interlocks, but sidestep the combinatorial explosion by
> building something simple enough to adapt to any interlock requirement
> that arises after completion.
>
> > > The social structure that teams have is a huge part of the
> > > deadlock we find ourselves in with certain controversial changes.
> > > The idea is to unroll the dependency loop and start _somewhere_
> > > rather than where a lot of these efforts die: starting
> > > _everywhere_.
> >
> > I agree with your analysis, but I fail to see how e.g. a group of
> > people X stating that Y should work this way in Cinder is going to
> > achieve any change if nobody from Cinder is in X from the beginning.
> >
> > This is basically what seems to happen in many [working] groups as
> > far as I can see.
>
> So this is where the Open Source method takes over. Change is produced
> by those people who most care about it because they're invested. To
> take your Cinder example, you're unlikely to find them within Cinder
> because any project has inertia that resists change. It takes the
> energy of the outside group X to force the change to Y, but this means
> that X often gets to propose, develop and even code Y. Essentially
> they become drive by coders for Cinder. This is where Open Source
> differs from Enterprise because you have the code and the access, you
> can do this. However, you have to remember the inertia problem and
> build what you're trying to do as incrementally as possible: the larger
> the change, the bigger the resistance to it. It's also a good test of
> the value of the change: if group X can't really be bothered to code it
> (and Cinder doesn't want it) then perhaps there's not really enough
> value in it anyway and it shouldn't happen.
>
> This latter observation is also an improvement over the enterprise
> methods because enterprise architects do often mandate interlocks that
> later turn out to be unnecessary (or at least of a lot less value than
> was initially thought).
>
> I suppose the executive summary of the above is that I don't think
> you're describing a bug, I think you're describing a feature.
>
> James
>
>
>
> ------------------------------
>
> Message: 16
> Date: Wed, 20 Jul 2016 09:15:08 -0700
> From: Ed Leafe <ed at leafe.com>
> To: "Daniel P. Berrange" <berrange at redhat.com>, "OpenStack Development
> Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] FPGA as a dynamic nested resources
> Message-ID: <FC9FDA36-B300-4363-AFD6-29A0947C0B00 at leafe.com>
> Content-Type: text/plain; charset=utf-8
>
> On Jul 20, 2016, at 2:07 AM, Daniel P. Berrange <berrange at redhat.com>
> wrote:
>
> > For FPGA, I'd like to see an initial proposal that assumed the FPGA
> > is pre-programmed & pre-divided into a fixed number of slots and simply
> > deal with this. This is similar to how we dealt with PCI SR-IOV initially
> > where we assumed the dev is in VF-mode only. Only later did we start to
> > add cleverness around switching VF vs PF mode. For FPGA I think any kind
> > of dynamic re-allocation/re-configuration is better done as a stage 2
>
> +1 to this approach. I?m not convinced yet that Nova should be in the
> business of FPGA management, but once we get the basic functionality
> supporting FPGA working well, seeing what would be needed to add it would
> be much easier, and we could make a clearer determination as to whether
> this is feasible or not.
>
>
> -- Ed Leafe
>
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 17
> Date: Wed, 20 Jul 2016 19:21:04 +0300
> From: Kirill Zaitsev <kzaitsev at mirantis.com>
> To: Rob Cresswell <robert.cresswell at outlook.com>, "OpenStack
> Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [horizon] Plugin stability, failing tests
> etc.
> Message-ID: <etPan.578fa4f0.1c21aa30.186 at mirantis.com>
> Content-Type: text/plain; charset="utf-8"
>
> Initially I don?t think I like the idea of making master-horizon job
> non-voting for murano-dashboard.
>
> Here are some reasons:?
> 1) We would still need to fix murano-dashboard to work with master
> horizon (since we would need to be released together)
> 2) The breakage would be less visible
> 3) I can imagine a situation when a change would pass on master
> but would not pass on a previous stable point release (even worse this
> release can be n3). Say we?re trying to use some function/feature, that has
> just landed.
>
> Those are my initial ideas about this, have give it a bit more time, to
> think more carefully.
>
> BTW, I can fetch the numbers on how many times murano-dashboard gate was
> broken by changes in horizon, during M and N cycles, if you?re interested.
> Also for murano-dashboard we run our integration selenium tests as a
> 3d-party CI, so technically we?re not blocked by the job not working, in
> case we need to land some security patch. =)
>
> --?
> Kirill Zaitsev
> Murano Project Tech Lead
> Software Engineer at
> Mirantis, Inc
>
> On 20 juillet 2016 at 17:10:46, Rob Cresswell (
> robert.cresswell at outlook.com) wrote:
>
> Yes, it would mean changing your requirements after a release. So, for
> example you might run two gate tests:
>
> - A voting Horizon-stable/milestone test, (or both)
> - A non-voting Horizon-master test
>
> That gives you a lot of control over making your tests passing (multiple
> patches to make the Horizon-master test pass, or all in one patch set
> alongside the horizon-milestone test bump), rather than random failures
> each week. You'd still be able to track the failures as they come in, but
> they won't break your gate each time.
>
> I don't think where horizon (the library) lives would change how you
> version against it. We don't currently have any plans to separate the two;
> while we realise its a desirable change, weighing the work and risk
> involved in the split architecture vs the end result, we've chosen to work
> on other higher priority items for now (performance, filtering
> improvements, angular work etc.)
>
> Rob
>
>
>
> On 20 July 2016 at 13:38, Hayes, Graham <graham.hayes at hpe.com> wrote:
> On 20/07/2016 10:16, Rob Cresswell wrote:
> > Hey all,
> >
> > So we've had a few issues with plugin stability recently, and its
> > apparent that many plugins are building off Horizon master as a
> > dependency. I would really advise against this. A more manageable
> > development process may be to:
> >
> > - Base stable plugins against a stable release of Horizon
> > - Base WIP versions/new plugins off the last Horizon milestone, b2 in
> > this case, and then bump the version and capture issues within the same
> > patch. This should prevent random breakages, and should allow you to
> > just look at the release notes for that milestone.
>
> So this would mean changing tox.ini or requirements files after each
> horizon release?
>
> This dovetails nicely with the other thread about how we should be doing
> cross project interactions.
>
> What would be best, would be having horizon released as a separate
> library on pypi like the clients and oslo libs.
>
> Then openstack-dashboard, and all the plugins could rely on the same
> base library, without hacks like:
>
> ? ?deps =
> ? ? ?-r{toxinidir}/requirements.txt
> ? ? ?-r{toxinidir}/test-requirements.txt
> ? ? ?http://tarballs.openstack.org/horizon/horizon-master.tar.gz
>
> in tox.ini or
>
> ? ?# Testing Requirements
> ? ?http://tarballs.openstack.org/horizon/horizon-master.tar.gz#egg=horizon
>
> in (test-)requirements.txt
>
> Is that on roadmap?
>
> > On the Horizon side, we've moved our FF a week earlier, so I think that
> > week combined with the usual RC period should be enough time to fix
> > bugs. We'll aim to make sure our release notes are complete with regards
> > to breaking issues for plugins, and deprecate appropriately.
> >
> > Rob
>
>
> __________________________________________________________________________
> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/07fbcda5/attachment-0001.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 836 bytes
> Desc: Message signed with OpenPGP using AMPGpg
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/07fbcda5/attachment-0001.pgp
> >
>
> ------------------------------
>
> Message: 18
> Date: Wed, 20 Jul 2016 16:30:09 +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] [Glare][Heat][TripleO] Heat artifact type
> Message-ID:
> <1A3C52DFCD06494D8528644858247BF01B9A6BC2 at EX10MBOX03.pnnl.gov>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I have a preference towards option 2 as well. I usually use templates with
> all the logic in it, and an environment file with just the specific
> parameters defined for launching an instance of the template so I can
> repeatedly deploy/delete/redeploy it.
>
> I've got a good template set I think that would be awesome to see in a
> glare artefact.
>
> Could this template set be wrapped up:
> https://github.com/EMSL-MSC/heat-templates/tree/master/cfn/lib
>
> And the main entrypoint template is:
>
> https://github.com/EMSL-MSC/heat-templates/blob/master/cfn/lib/SimpleServer.yaml
>
> Documentation on how to use it is here:
>
> https://github.com/EMSL-MSC/heat-templates/blob/master/cfn/lib/SimpleServer.txt
>
> With it implemented with Option 2, the user can just copy the two example
> environments at the bottom of the docs there, tweak it slightly and launch
> some fairly advanced servers.
>
> Thanks,
> Kevin
> ________________________________
> From: Mikhail Fedosin [mfedosin at mirantis.com]
> Sent: Wednesday, July 20, 2016 6:58 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Glare][Heat][TripleO] Heat artifact type
>
>
>
> On Wed, Jul 20, 2016 at 5:12 AM, Qiming Teng <tengqim at linux.vnet.ibm.com
> <mailto:tengqim at linux.vnet.ibm.com>> wrote:
> On Tue, Jul 19, 2016 at 06:44:06PM +0300, Oleksii Chuprykov wrote:
> > Hello!
> >
> > Today it was announced that Glare is ready for public review
> > http://lists.openstack.org/pipermail/openstack-dev/2016-July/099553.html
> So
> > we are ready to start working on integration Heat with Glare and
> > implementing a POC. After discussions with Glare team we see two design
> > options:
> >
> > 1) Create one artifact type that will contain template, nested templates
> > and environments.
> > Pros: It is easy to maintain integrity. Since artifact is immutable, we
> can
> > guarantee the consistency and prevent from accidentally removing of
> > dependent environment.
> > Cons: If we need to add new environments to use them with template, we
> need
> > to create new artifact.
> >
> > 2) Create 2 artifact types: environment and template.
> > Pros: It is easy to add new environments. You just need to create new
> > dependency from template artifact to environment one.
> > Cons: Some environment can be (mistakenly) removed, and template that
> have
> > dependencies on it will be in inconsistent state.
>
> Option 2 looks more flexible to me. I'm not sure we are encouraging
> users to introduce or rely on a hard dependency from a template to an
> environment file. With that, it is still good to know whether glare
> supports the concept of 'reference' where a referenced artifact cannot
> be deleted.
>
> Hey!
>
> Indeed, option 2 is more flexible, but in this case users have to manually
> control dependencies, which is may be hard sometimes. Also, initially Glare
> won't support 'hard' dependencies, this feature will be added in next
> version, because it requires additional discussions. For this reason I
> recommend option 1 and let Glare control template consistency for you, it
> won't allow users to break anything.
>
> Best,
> Mike
>
>
> - Qiming
>
> > So we want to hear your opinions and suggestions on the matter. Thanks in
> > advance!
> >
> > Best regards,
> > Oleksii Chuprykov
>
>
> __________________________________________________________________________
> 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/20160720/aa8965fb/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 19
> Date: Wed, 20 Jul 2016 16:36:14 +0000
> From: "Hayes, Graham" <graham.hayes at hpe.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [horizon] Plugin stability, failing tests
> etc.
> Message-ID:
> <
> CS1PR84MB021589920974E4C50CCA0CBB90080 at CS1PR84MB0215.NAMPRD84.PROD.OUTLOOK.COM
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> On 20/07/2016 15:13, Rob Cresswell wrote:
> > Yes, it would mean changing your requirements after a release. So, for
> > example you might run two gate tests:
> >
> > - A voting Horizon-stable/milestone test, (or both)
> > - A non-voting Horizon-master test
> >
> > That gives you a lot of control over making your tests passing (multiple
> > patches to make the Horizon-master test pass, or all in one patch set
> > alongside the horizon-milestone test bump), rather than random failures
> > each week. You'd still be able to track the failures as they come in,
> > but they won't break your gate each time.
>
> I don't want control, I want to consume a library in a standard way -
> the way we consume libraries from the rest of openstack.
>
> > I don't think where horizon (the library) lives would change how you
> > version against it. We don't currently have any plans to separate the
> > two; while we realise its a desirable change, weighing the work and risk
> > involved in the split architecture vs the end result, we've chosen to
> > work on other higher priority items for now (performance, filtering
> > improvements, angular work etc.)
>
> Well, if would stop us having a reference to git branch in our
> requirements, and allow to use the standard global requirements
> process to manage the dependency.
>
> It also means that as a plugin I know that the released version of
> my plugin has been tested in my gate with the exact version of the
> code that the horizon team release.
>
> We can still do multiple patches to fix any changes in the horizon
> library, and in the tip of the chain update the version in requirements.
>
> The risk has just been moved to the plugins, which is not ideal.
>
> It also makes downstream consumption *a lot* easier.
>
> >
> >
> > On 20 July 2016 at 13:38, Hayes, Graham <graham.hayes at hpe.com
> > <mailto:graham.hayes at hpe.com>> wrote:
> >
> > On 20/07/2016 10:16, Rob Cresswell wrote:
> > > Hey all,
> > >
> > > So we've had a few issues with plugin stability recently, and its
> > > apparent that many plugins are building off Horizon master as a
> > > dependency. I would really advise against this. A more manageable
> > > development process may be to:
> > >
> > > - Base stable plugins against a stable release of Horizon
> > > - Base WIP versions/new plugins off the last Horizon milestone, b2
> in
> > > this case, and then bump the version and capture issues within the
> same
> > > patch. This should prevent random breakages, and should allow you
> to
> > > just look at the release notes for that milestone.
> >
> > So this would mean changing tox.ini or requirements files after each
> > horizon release?
> >
> > This dovetails nicely with the other thread about how we should be
> doing
> > cross project interactions.
> >
> > What would be best, would be having horizon released as a separate
> > library on pypi like the clients and oslo libs.
> >
> > Then openstack-dashboard, and all the plugins could rely on the same
> > base library, without hacks like:
> >
> > deps =
> > -r{toxinidir}/requirements.txt
> > -r{toxinidir}/test-requirements.txt
> > http://tarballs.openstack.org/horizon/horizon-master.tar.gz
> >
> > in tox.ini or
> >
> > # Testing Requirements
> >
> >
> http://tarballs.openstack.org/horizon/horizon-master.tar.gz#egg=horizon
> >
> > in (test-)requirements.txt
> >
> > Is that on roadmap?
> >
> > > On the Horizon side, we've moved our FF a week earlier, so I think
> that
> > > week combined with the usual RC period should be enough time to fix
> > > bugs. We'll aim to make sure our release notes are complete with
> regards
> > > to breaking issues for plugins, and deprecate appropriately.
> > >
> > > Rob
> >
> >
> >
> __________________________________________________________________________
> > 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
> >
> >
>
>
>
>
> ------------------------------
>
> Message: 20
> Date: Wed, 20 Jul 2016 18:39:34 +0200
> From: Alan Pevec <apevec at redhat.com>
> To: Sagi Shnaidman <sshnaidm at redhat.com>
> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [TripleO] Delorean fail blocks CI for
> stable branches
> Message-ID:
> <CABYd8ScS7xrtXkTRGL35CRtOevjgy3L8C=
> W1Q7zOhr1zGtH1ug at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> >> ^ ... --local here keeps local checkout untouched, so you end up with
> >> default rpm-master in distro git checkout.
> >> If you remove --local it will reset local checkouts to the branches
> >> specified in projects.ini
> >>
> > Alan,
> > I don't want to reset local checkouts and reset branches - I need to
> build
> > with these checkout, it's all CI is for.
>
> DLRN finds matching packaging branch only when you let it reset git
> checkouts.
> For tripleo-ci use-case we would need to add a new option to keep
> source repo as-is and reset packaging checkout only, in the meantime
> as a quickfix in tripleo.sh you could patch dlrn and set local=True in
> [2]
>
> Alan
>
>
> [1]
> https://github.com/openstack-packages/DLRN/blob/master/dlrn/shell.py#L522-L536
>
> [2]
> https://github.com/openstack-packages/DLRN/blob/master/dlrn/drivers/rdoinfo.py#L83-L84
>
>
>
> ------------------------------
>
> Message: 21
> Date: Wed, 20 Jul 2016 18:50:57 +0200
> From: Alan Pevec <apevec at redhat.com>
> To: Alan Pevec <alan.pevec at redhat.com>
> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [TripleO] Delorean fail blocks CI for
> stable branches
> Message-ID:
> <
> CABYd8Se-jmf8wG7HEB-jczeAhFx241LDqTsTqEGwrrt5diOzSQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> > as a quickfix in tripleo.sh you could patch dlrn and set local=True in
>
> correction, patch local=False there while running dlrn command with
> --local to keep source checkout as-is
>
>
>
> ------------------------------
>
> Message: 22
> Date: Thu, 21 Jul 2016 00:51:59 +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>
> Subject: Re: [openstack-dev] OpenStack Kolla - External Ceph
> Message-ID:
> <
> CAATxhGfZ3bm1dfOXvQpLZcx-jTQ-vLROUm9fcVBJGwFq+thmaw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Jul 6, 2016 at 1:47 AM, Steven Dake (stdake) <stdake at cisco.com>
> wrote:
> >
> > At this point, I feel we are going a direction in which we try to wrap
> > everything anybody could possibly want to configure with Kolla by making
> > extensive use of global.yml. We would have to introduce flags indicating
> a
> > couple of different scenarios:
> >
> > 1. Deploy Ceph (already there: enable_ceph="yes")
> > 2. Use Ceph with Glance (enable_ceph_glance="yes")
> > 3. Use Ceph with Cinder (enable_ceph_cinder="yes")
> > 4. Use Ceph with Nova (enable_ceph_nova="yes")
> >
> >
> > I disagree. If ceph is enabled, then ceph should be used, if ceph is not
> > enabled, then ceph shouldn't be used. That implies all of OpenStack
> either
> > uses Ceph or not. So we really just need enable_ceph.
>
>
> why we need separate configuration for ceph? I think if ceph is
> enable, all the service should use ceph, too.
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
>
>
> ------------------------------
>
> Message: 23
> Date: Wed, 20 Jul 2016 09:57:27 -0700
> From: James Bottomley <James.Bottomley at HansenPartnership.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>, Clint Byrum <clint at fewbar.com
> >
> Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins
> for all)
> Message-ID: <1469033847.2424.66.camel at HansenPartnership.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 2016-07-20 at 16:08 +0000, Fox, Kevin M wrote:
> > +1 to the finding of a middle ground.
>
> Thanks ... I have actually been an enterprise architect (I just keep
> very quiet about it when talking Open Source).
>
> > The problem I've seen with your suggested OpenSource solution is the
> > current social monetary system of OpenStack makes it extremely
> > difficult.
> >
> > Each project currently prints its own currency. Reviews. It takes
> > quite a few Reviews (time/effort) on a project to gain enough
> > currency that you get payed attention to. And, one project doesn't
> > honor another projects currency.
>
> OK, I accept your analogy, even though I would view currency as the
> will to create and push patches.
>
> The problem you describe: getting the recipients to listen and accept
> your patches, is also a common one. The first essential is simple
> minimal patches because they're hard to reject.
>
> Once you've overcome the reject barrier, there's the indifference one
> (no-one says no, but no-one says yes).
>
> Overcoming indifference involves partly knowing who to bother and when
> (In openstack, it's quite easy since you know who the core reviewers
> are) and also building a consensus for the patch; usually this involves
> finding other people who need the feature and getting them to pipe up
> (if you can't find other projects, then you can get potential users to
> do this) even better if they help you write the patches. Ideally, you
> build your consensus before you actually push the patch set. Sometimes
> building consensus involves looking beyond your particular need to a
> bigger one that would satisfy you but also pulls other people in.
>
> > When these sorts of major cross project things need to be done
> > though, you need to have folks with capital in many different
> > projects and its very difficult to amass that much.
> >
> > There is no OpenStack level currency (other then being elected as a
> > TC member) that gets one project to stop and take the time to
> > carefully consider what someone is saying when bringing up cross
> > project issues.
> >
> > Without some shared currency, then the problem becomes, the person
> > invested in getting a solution, can propose and prototype and
> > implement the feature all they want (often several times), but it
> > never actually is accepted into the projects because a project:
> > a) doesn't take the time to really understand the problem, feeling
> > its trivial and just not accepting any reviews
> > b) doesn't take the time to really understand the problem, so
> > minimize it in their mind to a 'you should just use existing thing
> > X...' or a heavy handily propose alternate solutions that really
> > aren't solutions.
> > c) they decide its better handled by another project and stall/block
> > reviews, trying to push the implementation to go elsewhere. When
> > multiple projects decide this, the ball just keeps getting bounced
> > around without any solution for years.
> >
> > The status quo is not working here. The current governance structure
> > doesn't support progress.
>
> What you'll find you've described above is a process that doesn't
> support drive by coders at all and, by extension therefore, doesn't
> welcome newcomers, which is a big problem, but one I thought OpenStack
> was tackling?
>
> The bounce problem is annoying but not insuperable. It mostly occurs
> where there's overlap. Often the best method for coping is to field
> the bounce: produce the patch for the other project. If it's smaller
> and neater, perhaps the bounce was correct. If it's bigger and uglier,
> get the other project to say so and you now have a solid reason to go
> back and say "we tried what you suggested and here's why it didn't
> work". Morally, you're now on higher ground because incorrect
> technical advice is a personal failure for whoever bounced you (make
> sure to capitalise on it if they try another bounce).
>
> James
>
>
>
>
> ------------------------------
>
> Message: 24
> Date: Wed, 20 Jul 2016 17:12:30 +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] OpenStack Kolla - External Ceph
> Message-ID:
> <1A3C52DFCD06494D8528644858247BF01B9A6CC7 at EX10MBOX03.pnnl.gov>
> Content-Type: text/plain; charset="us-ascii"
>
> We use ceph with cinder and glance. I don't see a reason not to.
>
> We do not set nova to use it for anything but cinder volumes though.
>
> The reason being, if you set it up that way, your users have no way of
> opting out of the potential performance hit if using no local storage for
> non pets.
>
> If you leave it nova local, you can always still get ceph remote storage
> for the whole vm by requesting the root disk be volume backed.
>
> We also already have a ceph deployment managed without kolla, and that's
> unlikely to change.
>
> So, for our site, our settings would probably be:
> 1. Deploy Ceph (enable_ceph="no")
> 2. Use Ceph with Glance (enable_ceph_glance="yes")
> 3. Use Ceph with Cinder (enable_ceph_cinder="yes")
> 4. Use Ceph with Nova (enable_ceph_nova="no")
>
> Thanks,
> Kevin
> ________________________________________
> From: Jeffrey Zhang [zhang.lei.fly at gmail.com]
> Sent: Wednesday, July 20, 2016 9:51 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] OpenStack Kolla - External Ceph
>
> On Wed, Jul 6, 2016 at 1:47 AM, Steven Dake (stdake) <stdake at cisco.com>
> wrote:
> >
> > At this point, I feel we are going a direction in which we try to wrap
> > everything anybody could possibly want to configure with Kolla by making
> > extensive use of global.yml. We would have to introduce flags indicating
> a
> > couple of different scenarios:
> >
> > 1. Deploy Ceph (already there: enable_ceph="yes")
> > 2. Use Ceph with Glance (enable_ceph_glance="yes")
> > 3. Use Ceph with Cinder (enable_ceph_cinder="yes")
> > 4. Use Ceph with Nova (enable_ceph_nova="yes")
> >
> >
> > I disagree. If ceph is enabled, then ceph should be used, if ceph is not
> > enabled, then ceph shouldn't be used. That implies all of OpenStack
> either
> > uses Ceph or not. So we really just need enable_ceph.
>
>
> why we need separate configuration for ceph? I think if ceph is
> enable, all the service should use ceph, too.
>
> --
> 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: 25
> Date: Wed, 20 Jul 2016 17:21:31 +0000
> From: Rob Cresswell <robert.cresswell at outlook.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [horizon] Plugin stability, failing tests
> etc.
> Message-ID:
> <
> AM3PR06MB0936D02113CFEF76C538C37088080 at AM3PR06MB0936.eurprd06.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> Kirill: The failures are just as visible, since the cores still control
> merging anyway. The only difference is that if it takes a few days to fix
> something in upstream Horizon, you needn't block your own content in the
> meantime. Later in the release cycle (around N-3, for example) cores could
> just not merge failing tests. Regardless, this is just a recommendation,
> and if you're comfortable adjusting to issues as they come through, then
> thats fine to base off master.
>
> Graham: The "risk" I refer to is in that in any project architecture
> rewrite you can make mistakes and break functionality. So that risk only
> arises from a rewrite.
>
> "It also means that as a plugin I know that the released version of my
> plugin has been tested in my gate with the exact version of the code that
> the horizon team release." - I don't understand this part. If we release a
> horizon lib, we'd still being doing milestone releases to PyPI. So again,
> whether you consume that as a tarball or a PyPI package makes little
> difference to the day to day testing of your plugin. Its the same code.
>
> Ideally - yes, we'd probably split horizon as a separate library, but
> thats something to discuss at the summit and judge demand, because most
> discussions thus far have concluded that its a lower priority issue than
> others.
>
> Rob
>
>
>
> On 20 July 2016 at 17:36, Hayes, Graham <graham.hayes at hpe.com<mailto:
> graham.hayes at hpe.com>> wrote:
> On 20/07/2016 15:13, Rob Cresswell wrote:
> > Yes, it would mean changing your requirements after a release. So, for
> > example you might run two gate tests:
> >
> > - A voting Horizon-stable/milestone test, (or both)
> > - A non-voting Horizon-master test
> >
> > That gives you a lot of control over making your tests passing (multiple
> > patches to make the Horizon-master test pass, or all in one patch set
> > alongside the horizon-milestone test bump), rather than random failures
> > each week. You'd still be able to track the failures as they come in,
> > but they won't break your gate each time.
>
> I don't want control, I want to consume a library in a standard way -
> the way we consume libraries from the rest of openstack.
>
> > I don't think where horizon (the library) lives would change how you
> > version against it. We don't currently have any plans to separate the
> > two; while we realise its a desirable change, weighing the work and risk
> > involved in the split architecture vs the end result, we've chosen to
> > work on other higher priority items for now (performance, filtering
> > improvements, angular work etc.)
>
> Well, if would stop us having a reference to git branch in our
> requirements, and allow to use the standard global requirements
> process to manage the dependency.
>
> It also means that as a plugin I know that the released version of
> my plugin has been tested in my gate with the exact version of the
> code that the horizon team release.
>
> We can still do multiple patches to fix any changes in the horizon
> library, and in the tip of the chain update the version in requirements.
>
> The risk has just been moved to the plugins, which is not ideal.
>
> It also makes downstream consumption *a lot* easier.
>
> >
> >
> > On 20 July 2016 at 13:38, Hayes, Graham <graham.hayes at hpe.com<mailto:
> graham.hayes at hpe.com>
> > <mailto:graham.hayes at hpe.com<mailto:graham.hayes at hpe.com>>> wrote:
> >
> > On 20/07/2016 10:16, Rob Cresswell wrote:
> > > Hey all,
> > >
> > > So we've had a few issues with plugin stability recently, and its
> > > apparent that many plugins are building off Horizon master as a
> > > dependency. I would really advise against this. A more manageable
> > > development process may be to:
> > >
> > > - Base stable plugins against a stable release of Horizon
> > > - Base WIP versions/new plugins off the last Horizon milestone, b2
> in
> > > this case, and then bump the version and capture issues within the
> same
> > > patch. This should prevent random breakages, and should allow you
> to
> > > just look at the release notes for that milestone.
> >
> > So this would mean changing tox.ini or requirements files after each
> > horizon release?
> >
> > This dovetails nicely with the other thread about how we should be
> doing
> > cross project interactions.
> >
> > What would be best, would be having horizon released as a separate
> > library on pypi like the clients and oslo libs.
> >
> > Then openstack-dashboard, and all the plugins could rely on the same
> > base library, without hacks like:
> >
> > deps =
> > -r{toxinidir}/requirements.txt
> > -r{toxinidir}/test-requirements.txt
> > http://tarballs.openstack.org/horizon/horizon-master.tar.gz
> >
> > in tox.ini or
> >
> > # Testing Requirements
> >
> >
> http://tarballs.openstack.org/horizon/horizon-master.tar.gz#egg=horizon
> >
> > in (test-)requirements.txt
> >
> > Is that on roadmap?
> >
> > > On the Horizon side, we've moved our FF a week earlier, so I think
> that
> > > week combined with the usual RC period should be enough time to fix
> > > bugs. We'll aim to make sure our release notes are complete with
> regards
> > > to breaking issues for plugins, and deprecate appropriately.
> > >
> > > Rob
> >
> >
> >
> __________________________________________________________________________
> > 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://OpenStack-dev-request@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://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/20160720/433e2b02/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 26
> Date: Wed, 20 Jul 2016 13:29:02 -0400
> From: Rob Crittenden <rcritten at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>, "Wenzhi Yu (yuywz)"
> <wenzhi_yu at 163.com>
> Subject: Re: [openstack-dev] [devstack] How to enable SSL in devStack?
> Message-ID: <578FB4DE.8080500 at redhat.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Rob Crittenden wrote:
> > Andrey Pavlov wrote:
> >> Hi,
> >>
> >> When I ran devstack with SSL I found a bug and tried to fix it -
> >> https://review.openstack.org/#/c/242812/
> >> But no one agree with me.
> >> Try to apply this patch - it may help.
> >> Also there is a chance that new bugs present in devstack that
> >> prevented to install it with SSL.
> >
> > Seeing how some other things in your local.conf might help but when I
> > tried to reproduce it I got the same error and it failed because Apache
> > didn't have an SSL listener on 443.
> >
> > I'm not sure I'd recommend direct SSL in any case. I'd recommend the
> > tls-proxy service instead. Note that I'm pretty sure it has the same
> > problem: it hasn't been updated to handle port 443 for Keystone.
> >
> > I'm working on switching from stud to mod_proxy if you want to take a
> > look and this problem is fixed there,
> https://review.openstack.org/301172
> >
> > I'll see about adding a SSL listener to Keystone for the USE_SSL case in
> > the next few days.
> >
> > And yeah, it's a moving target. I have an experimental gate test for
> > tlsproxy but it has to be requested explicitly. My plan is to enable it
> > as non-voting once the mod_proxy changes land so it will at least be
> > more obvious when things break (or maybe we can making it voting).
>
> Fixing Keystone is easy. An Apache VirtualHost for 443 needs to be added.
>
> But I found another, deeper problem: cinder won't listen on SSL. When
> they switched to using oslo_service for WSGI they completely removed the
> ability to use SSL. See bug https://bugs.launchpad.net/cinder/+bug/1590901
>
> rob
>
>
>
> ------------------------------
>
> Message: 27
> Date: Wed, 20 Jul 2016 10:37:13 -0700
> From: Clint Byrum <clint at fewbar.com>
> To: "\"OpenStack Development Mailing List (not for usage questions)\""
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins
> for all)
> Message-ID: <1469035947-sup-1293 at fewbar.com>
> Content-Type: text/plain; charset=UTF-8
>
> Excerpts from James Bottomley's message of 2016-07-20 08:31:34 -0700:
> > So this is where the Open Source method takes over. Change is produced
> > by those people who most care about it because they're invested. To
> > take your Cinder example, you're unlikely to find them within Cinder
> > because any project has inertia that resists change. It takes the
> > energy of the outside group X to force the change to Y, but this means
> > that X often gets to propose, develop and even code Y. Essentially
> > they become drive by coders for Cinder. This is where Open Source
> > differs from Enterprise because you have the code and the access, you
> > can do this. However, you have to remember the inertia problem and
> > build what you're trying to do as incrementally as possible: the larger
> > the change, the bigger the resistance to it. It's also a good test of
> > the value of the change: if group X can't really be bothered to code it
> > (and Cinder doesn't want it) then perhaps there's not really enough
> > value in it anyway and it shouldn't happen.
> >
>
> Thanks so much for stating this James. I couldn't agree more. A group
> that can actually _accomplish_ change, and not just suggest it, is
> exactly what we're working to start with the architecture WG. There are
> plenty of people with the will to change, and I feel strongly that if
> those people are given a structure and support, then they'll find the
> time and space to complete these objectives.
>
> I just want to make one nuance point about Cinder changes: the recent
> DLM work, done outside any architecture working group, did actually come
> from both inside and outside Cinder. The Cinder team realized something
> was happening that would perhaps affect everyone, and raised it to the
> cross-project level, which helped external individuals get involved. So
> these initiatives can come from either direction. The key is that enough
> momentum builds up to counter the natural inertia that you mentioned in
> your message.
>
>
>
> ------------------------------
>
> Message: 28
> Date: Wed, 20 Jul 2016 20:49:47 +0300
> From: Sagi Shnaidman <sshnaidm at redhat.com>
> To: Alan Pevec <alan.pevec at redhat.com>
> Cc: James Slagle <jslagle at redhat.com>, "OpenStack Development Mailing
> List \(not for usage questions\)" <
> openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [TripleO] Delorean fail blocks CI for
> stable branches
> Message-ID:
> <CAGHQP9yJQ4sRbpq=XEAmzfixsmOm27FA=
> a__ROboTLDbY_yJZg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> How then it worked before? Can you show me the patch that broke this
> functionality in delorean? It should be about 15 Jul when jobs started to
> fail.
> How then master branch works? It also runs on patched repo and succeeds.
>
> I don't think we can use this workaround, each time this source file will
> change - all our jobs will fail again? It's not even a workaround.
> Please let's stop discussing and let's solve it finally, it blocks our CI
> for stable patches.
> I'd expect for a little bit more involvement in this issue and suggest you
> or anybody who understand well delorean code and specs will try to solve it
> when I provide him a whole TripleO CI dev environment with walking through
> every CI step and any other info I can provide. Let's just sit and solve
> it, otherwise we'll never get it working.
>
> Thanks
>
>
> On Wed, Jul 20, 2016 at 7:50 PM, Alan Pevec <apevec at redhat.com> wrote:
>
> > > as a quickfix in tripleo.sh you could patch dlrn and set local=True in
> >
> > correction, patch local=False there while running dlrn command with
> > --local to keep source checkout as-is
> >
>
>
>
> --
> Best regards
> Sagi Shnaidman
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/be70d6f1/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 29
> Date: Wed, 20 Jul 2016 11:08:43 -0700
> From: Jay Pipes <jaypipes at gmail.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags -
> Manage Capabilities with ResourceProvider
> Message-ID: <00dc5392-3edc-5174-91ed-c9d048fa8036 at gmail.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 07/18/2016 01:45 PM, Matt Riedemann wrote:
> > On 7/15/2016 8:06 PM, Alex Xu wrote:
> >>
> >> Actually I still think aggregates isn't good for Manage Caps, just as I
> >> said in previous reply about Aggregates. One of reason is just same with
> >> #2 you said :) And It's totally not managable. User is even no way to
> >> query a specific host in which host-aggregate. And there isn't a
> >> interface to query what metadata was related to the host by
> >> host-aggregate. I prefer just keep the Aggregate as tool to group the
> >> hosts. But yes, user still can use host-aggregate to manage host with
> >> old way, let's user decide what is more convenient.
> >
> > +1 to Alex's point. I just read through this thread and had the same
> > thought. If the point is to reduce complexity in the system and surface
> > capabilities to the end user, let's do that with resource provider tags,
> > not a mix of host aggregate metadata and resource provider tags so that
> > an operator has to set both, but also know in what situations he/she has
> > to set it and where.
>
> Yeah, having the resource provider be tagged with capabilities versus
> having to manage aggregate tags may make some of the qualitative
> matching queries easier to grok. The query performance won't necessarily
> be any better, but they will likely be easier to read...
>
> > I'm hoping Jay or someone channeling Jay can hold my hand and walk me
> > safely through the evil forest that is image properties / flavor extra
> > specs / scheduler hints / host aggregates / resource providers / and the
> > plethora of scheduler filters that use them to build a concrete
> > picture/story tying this all together. I'm thinking like use cases, what
> > does the operator need to do
>
> Are you asking how things are *currently* done in Nova? If so, I'll need
> to find some alcohol.
>
> If you are asking about how we'd *like* all of the qualitative things to
> be requested and queried in the new placement API, then less alcohol is
> required.
>
> The schema I'm thinking about on the placement engine side looks like this:
>
> CREATE TABLE tags (
> id INT NOT NULL,
> name VARCHAR(200) NOT NULL,
> PRIMARY KEY (id),
> UNIQUE INDEX (name)
> );
>
> CREATE TABLE resource_provider_tags (
> resource_provider_id INT NOT NULL
> tag_id INT NOT NULL,
> PRIMARY KEY (resource_provider_id, tag_id),
> INDEX (tag_id)
> );
>
> On the Nova side, we need a mechanism of associating a set of
> capabilities that may either be required or preferred. The thing that we
> currently use for associating requested things in Nova is the flavor, so
> we'd need to define a mapping in Nova for the tags a flavor would
> require or prefer.
>
> CREATE TABLE flavor_tags (
> flavor_id INT NOT NULL,
> tag_name VARCHAR(200) NOT NULL,
> is_required INT NOT NULL
> );
>
> We would need to have a call in the placement REST API to find the
> resource providers that matched a particular set of required or
> preferred capability tags. Such a call might look like the following:
>
> GET /resource_providers
> {
> "resources": {
> "VCPU": 2,
> "MEMORY_MB": 2048,
> "DISK_GB": 100
> },
> "requires": [
> "storage:ssd",
> "compute:hw:x86:avx2",
> ],
> "prefers": [
> "compute:virt:accelerated_whizzybang"
> ]
> }
>
> Disregard the quantitative side of the above request right now. We could
> answer the qualitative side of the equation with the following SQL query
> in the placement engine:
>
> SELECT rp.uuid
> FROM resource_providers AS rp, tags AS t1, tags AS t2, tags AS t3
> INNER JOIN resource_provider_tags AS rpt1
> ON rp.id = rpt1.resource_provider_id
> AND rpt1.tag_id = t1.id
> INNER JOIN resource_provider_tags AS rpt2
> AND rpt1.resource_provider_id = rpt2.resource_provider_id
> AND rpt2.tag_id = t2.id
> LEFT JOIN resource_provider_tags AS rpt3
> ON rp.id = rpt3.resource_provider_id
> AND rpt3.tag_id = t3.id
> GROUP BY rp.uuid
> ORDER BY COUNT(COALESCE(rpt3.resource_provider_id, 0)) DESC
> WHERE t1.name = 'storage:ssd'
> AND t2.name = 'compute:hw:x86:avx2'
> AND t3.name IN ('compute:virt:accelerated_whizzybang')
>
> The above returns all resource providers having the 'storage:ssd' and
> 'compute:hw:x86:avx2' tags and returns resource providers *first* that
> have the 'compute:virt:accelerated_whizzybang' tag.
>
> >, what does the end user of the cloud need
> > to do, etc. I think if we're going to do resource providers tags for
> > capabilities we also need to think about what we're replacing. Maybe
> > that's just host aggregate metadata, but what's the deprecation plan for
> > that?
>
> Good question, as usual. My expectation would be that in Ocata, when we
> start adding the qualitative aspects to the placement REST API, we would
> introduce documentation that operators could use to translate common use
> cases that they were using flavor extra_specs and aggregate metadata for
> in the pre-placement world to the resource provider tags setup that
> would replace that functonality in the placement API world. Unlike most
> of the quantitative side of things, there really isn't a good way to
> "autoheal" or "autosetup" these things.
>
> > There is a ton to talk about here, so I'll leave that for the midcycle.
> > But let's think about what, if anything, needs to land in Newton to
> > enable us working on this in Ocata - but our priority for the midcycle
> > is really going to be focused on what things we need to get done yet in
> > Newton based on what we said we'd do in Austin.
> >
> > Also, a final nit - can we please be specific about roles in this thread
> > and any specs? I see 'user' thrown around a lot, but there are different
> > kinds of users. Only admins can see host aggregates and their metadata.
> > And when we're talking about how these tags will be used, let's be clear
> > about who the actors are - admins or cloud users. It helps avoid some
> > confusion.
>
> Correct. ONLY administrators can set, delete and associate tags with
> resource providers. End users only see a flavor name IMHO. It would be
> up to the deployer to document for end users whether and what
> capabilities a particular flavor provides...
>
> Best,
> -jay
>
>
>
> ------------------------------
>
> Message: 30
> Date: Wed, 20 Jul 2016 11:15:44 -0700
> From: Jay Pipes <jaypipes at gmail.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags -
> Manage Capabilities with ResourceProvider
> Message-ID: <77e8e16b-4e8f-87b7-aa53-4d047ad7ade3 at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 07/13/2016 01:37 PM, Ed Leafe wrote:
> > On Jul 11, 2016, at 6:08 AM, Alex Xu <soulxu at gmail.com> wrote:
> >
> >> For example, the capabilities can be defined as:
> >>
> >> COMPUTE_HW_CAP_CPU_AVX
> >> COMPUTE_HW_CAP_CPU_SSE
> >> ....
> >> COMPUTE_HV_CAP_LIVE_MIGRATION
> >> COMPUTE_HV_CAP_LIVE_SNAPSHOT
> >> ....
> >>
> >> ( The COMPUTE means this is coming from Nova. HW means this is hardware
> related Capabilities. HV means this is
> >> capabilities of Hypervisor. But the catalog of Capabilities can be
> discussed separated. This propose focus on the
> >> ResourceTags. We also have another idea about not using 'PREFIX' to
> manage the Tags. We can add attributes to the
> >> Tags. Then we have more control on the Tags. This will describe
> separately in the bottom. )
> >
> > I was ready to start ranting about using horribly mangled names to
> represent data, and then saw your comment about attributes for tags. Yes, a
> thousand times yes to attributes! There can be several standards, such as
> ?compute? or ?networking? that we use for some basic cross-cloud
> compatibility, but making them flexible is a must for adoption.
>
> I disagree :) Adoption -- at least interoperable cloud adoption -- of
> this functionality will likely be hindered by super-flexible description
> of capabilities. I think having a set of "standard" capabilities that
> can be counted on to be cross-OpenStack-cloud compatible and a set of
> "dynamic" capabilities that are custom to a deployment would be a good
> thing to do.
>
> Best,
> -jay
>
> > I can update the qualitative request spec to add ResourceProviderTags as
> a possible implementation.
>
>
>
> ------------------------------
>
> Message: 31
> Date: Wed, 20 Jul 2016 18:18:42 +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>, Clint Byrum <clint at fewbar.com
> >
> Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins
> for all)
> Message-ID:
> <1A3C52DFCD06494D8528644858247BF01B9A6DA7 at EX10MBOX03.pnnl.gov>
> Content-Type: text/plain; charset="us-ascii"
>
> I wish it was so simple. Its not.
>
> There is a good coding practice:
> "The code is done, not when there is nothing more to add, but nothing more
> to remove"
>
> Some of the more mature projects are in this mode of thinking now. (which
> is mostly good, really). They don't want to add features unless they see it
> as a benefit to their users. This is the problem, there is a disconnect
> between the view of Project X's users, and greater view of OpenStack Users.
>
> Even accepting the smallest of patches to work towards the goal is
> unacceptable to projects if they believe it is not a helpful feature to
> their perceived user base, or helpful enough to them to justify adding more
> code to their project. Or the feeling that "just push it to a new project
> or a different one is better". This fractured view of OpenStack users at
> the project level is preventing progress on OpenStack as a whole.
>
> Only an overarching Architectural group with some power to define what a
> user is, or the TC can address those sorts of issues.
>
> Thanks,
> Kevin
> ________________________________________
> From: James Bottomley [James.Bottomley at HansenPartnership.com]
> Sent: Wednesday, July 20, 2016 9:57 AM
> To: OpenStack Development Mailing List (not for usage questions); Clint
> Byrum
> Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for
> all)
>
> On Wed, 2016-07-20 at 16:08 +0000, Fox, Kevin M wrote:
> > +1 to the finding of a middle ground.
>
> Thanks ... I have actually been an enterprise architect (I just keep
> very quiet about it when talking Open Source).
>
> > The problem I've seen with your suggested OpenSource solution is the
> > current social monetary system of OpenStack makes it extremely
> > difficult.
> >
> > Each project currently prints its own currency. Reviews. It takes
> > quite a few Reviews (time/effort) on a project to gain enough
> > currency that you get payed attention to. And, one project doesn't
> > honor another projects currency.
>
> OK, I accept your analogy, even though I would view currency as the
> will to create and push patches.
>
> The problem you describe: getting the recipients to listen and accept
> your patches, is also a common one. The first essential is simple
> minimal patches because they're hard to reject.
>
> Once you've overcome the reject barrier, there's the indifference one
> (no-one says no, but no-one says yes).
>
> Overcoming indifference involves partly knowing who to bother and when
> (In openstack, it's quite easy since you know who the core reviewers
> are) and also building a consensus for the patch; usually this involves
> finding other people who need the feature and getting them to pipe up
> (if you can't find other projects, then you can get potential users to
> do this) even better if they help you write the patches. Ideally, you
> build your consensus before you actually push the patch set. Sometimes
> building consensus involves looking beyond your particular need to a
> bigger one that would satisfy you but also pulls other people in.
>
> > When these sorts of major cross project things need to be done
> > though, you need to have folks with capital in many different
> > projects and its very difficult to amass that much.
> >
> > There is no OpenStack level currency (other then being elected as a
> > TC member) that gets one project to stop and take the time to
> > carefully consider what someone is saying when bringing up cross
> > project issues.
> >
> > Without some shared currency, then the problem becomes, the person
> > invested in getting a solution, can propose and prototype and
> > implement the feature all they want (often several times), but it
> > never actually is accepted into the projects because a project:
> > a) doesn't take the time to really understand the problem, feeling
> > its trivial and just not accepting any reviews
> > b) doesn't take the time to really understand the problem, so
> > minimize it in their mind to a 'you should just use existing thing
> > X...' or a heavy handily propose alternate solutions that really
> > aren't solutions.
> > c) they decide its better handled by another project and stall/block
> > reviews, trying to push the implementation to go elsewhere. When
> > multiple projects decide this, the ball just keeps getting bounced
> > around without any solution for years.
> >
> > The status quo is not working here. The current governance structure
> > doesn't support progress.
>
> What you'll find you've described above is a process that doesn't
> support drive by coders at all and, by extension therefore, doesn't
> welcome newcomers, which is a big problem, but one I thought OpenStack
> was tackling?
>
> The bounce problem is annoying but not insuperable. It mostly occurs
> where there's overlap. Often the best method for coping is to field
> the bounce: produce the patch for the other project. If it's smaller
> and neater, perhaps the bounce was correct. If it's bigger and uglier,
> get the other project to say so and you now have a solid reason to go
> back and say "we tried what you suggested and here's why it didn't
> work". Morally, you're now on higher ground because incorrect
> technical advice is a personal failure for whoever bounced you (make
> sure to capitalise on it if they try another bounce).
>
> James
>
>
> __________________________________________________________________________
> 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: 32
> Date: Wed, 20 Jul 2016 21:24:53 +0300
> From: Duncan Thomas <duncan.thomas at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins
> for all)
> Message-ID:
> <CAOyZ2aH=
> fbAh+ohbpYfYLnJnLbR0_MgbhX7YjSfkr1+iWUbHmw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 20 July 2016 at 19:57, James Bottomley <
> James.Bottomley at hansenpartnership.com> wrote:
>
> >
> > OK, I accept your analogy, even though I would view currency as the
> > will to create and push patches.
> >
> > The problem you describe: getting the recipients to listen and accept
> > your patches, is also a common one. The first essential is simple
> > minimal patches because they're hard to reject.
> >
> > Once you've overcome the reject barrier, there's the indifference one
> > (no-one says no, but no-one says yes).
> >
> > [snip]
>
> The trouble with drive-by architecture patches (or large feature patches of
> any kind) is that it is often better *not* to merge them if you don't think
> the contributor is going to stick around for a while. This changes are
> usually intrusive, and have repercussions that take time to discover. It's
> often difficult to keep a change clean when the original author isn't
> around to review the follow-on work.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/7e9c1bfd/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 33
> Date: Wed, 20 Jul 2016 11:39:23 -0700
> From: Billy Olsen <billy.olsen at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [charms] Project mascot
> Message-ID:
> <CA+4oKthjupHFYf1iato_Zess+u=
> kQumSCRZhFNz5iuWw67ok9w at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> I like the idea of the Kraken...
>
> though I think I like the giant squid over an octopus, but either one
> is in the same vein :-)
>
> On Mon, Jul 18, 2016 at 1:27 AM, James Page <james.page at ubuntu.com> wrote:
> > Hi All
> >
> > As an approved project, we need to provide some ideas for a project
> mascot
> > for the Charms project (see [0]).
> >
> > Some suggestions as discussed on IRC:
> >
> > 1) cobra ('[snake] charming openstack') - which aligns with the Juju
> logo a
> > little.
> > 2) kraken ('many armed animal managing openstack') - but I think that
> falls
> > into mythical creatures so its probably excluded so maybe octopus
> instead?
> >
> > It would be nice to have one or two more ideas - any suggestions?
> >
> > Cheers
> >
> > James
> >
> > [0] http://www.openstack.org/project-mascots
> >
> >
> __________________________________________________________________________
> > 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: 34
> Date: Wed, 20 Jul 2016 18:43:55 +0000
> From: "Mooney, Sean K" <sean.k.mooney at intel.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags -
> Manage Capabilities with ResourceProvider
> Message-ID:
> <
> 4B1BB321037C0849AAE171801564DFA65F3335CA at IRSMSX107.ger.corp.intel.com>
>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> > -----Original Message-----
> > From: Jay Pipes [mailto:jaypipes at gmail.com]
> > Sent: Wednesday, July 20, 2016 7:16 PM
> > To: openstack-dev at lists.openstack.org
> > Subject: Re: [openstack-dev] [Nova] [RFC] ResourceProviderTags - Manage
> > Capabilities with ResourceProvider
> >
> > On 07/13/2016 01:37 PM, Ed Leafe wrote:
> > > On Jul 11, 2016, at 6:08 AM, Alex Xu <soulxu at gmail.com> wrote:
> > >
> > >> For example, the capabilities can be defined as:
> > >>
> > >> COMPUTE_HW_CAP_CPU_AVX
> > >> COMPUTE_HW_CAP_CPU_SSE
> > >> ....
> > >> COMPUTE_HV_CAP_LIVE_MIGRATION
> > >> COMPUTE_HV_CAP_LIVE_SNAPSHOT
> > >> ....
> > >>
> > >> ( The COMPUTE means this is coming from Nova. HW means this is
> > >> hardware related Capabilities. HV means this is capabilities of
> > >> Hypervisor. But the catalog of Capabilities can be discussed
> > >> separated. This propose focus on the ResourceTags. We also have
> > >> another idea about not using 'PREFIX' to manage the Tags. We can add
> > >> attributes to the Tags. Then we have more control on the Tags. This
> > >> will describe separately in the bottom. )
> > >
> > > I was ready to start ranting about using horribly mangled names to
> > represent data, and then saw your comment about attributes for tags.
> > Yes, a thousand times yes to attributes! There can be several
> > standards, such as ?compute? or ?networking? that we use for some basic
> > cross-cloud compatibility, but making them flexible is a must for
> > adoption.
> >
> > I disagree :) Adoption -- at least interoperable cloud adoption -- of
> > this functionality will likely be hindered by super-flexible
> > description of capabilities. I think having a set of "standard"
> > capabilities that can be counted on to be cross-OpenStack-cloud
> > compatible and a set of "dynamic" capabilities that are custom to a
> > deployment would be a good thing to do.
>
> [Mooney, Sean K]
> I know there is a bad memories when I metion CIM (
> http://www.dmtf.org/standards/cim)
> for many on the nova team but if we are to use standard names we should
> probably
> actually assess are there existing standads that we could adopt instead of
> defining
> our own standard names in nova for the resources.
> For example
> http://schemas.dmtf.org/wbem/cim-html/2/CIM_ProcessorAllocationSettingData.html
> Define the name for different instcution set extentions for example avx is
> DMTF:x86:AVX.
> Some work has been done in glance to allow importing cim metadata from ovf
> files also
>
> https://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cim-namespace-metadata-definitions.html
>
> while I don?t think using the full cim information model is useful in this
> case using the name would be
> from an inter-operability point of view as we not only would have standard
> names in openstack but those names
> would conform to an existing standard.
>
> We could still allow custom attribute but is see value in standardizing
> what can be standardized.
>
>
> >
> > Best,
> > -jay
> >
> > > I can update the qualitative request spec to add ResourceProviderTags
> > as a possible implementation.
> >
> > _______________________________________________________________________
> > ___
> > 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: 35
> Date: Wed, 20 Jul 2016 19:01:06 +0000
> From: Amrith Kumar <amrith at tesora.com>
> To: "heidijoy at openstack.org" <heidijoy at openstack.org>
> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] Mascot/logo for your project
> Message-ID:
> <
> CO2PR17MB0011B89DCABCD8C561183275A0080 at CO2PR17MB0011.namprd17.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> Heidi,
>
> The Trove team came up with several logo options. The result of a vote was
> decisive:
>
>
> 1. Stingray [1]
>
> 2. A Clam with a Pearl in it. [2]
>
> I have heard of no one else wanting to use the Stingray so I would like to
> request that the foundation consider that our preference.
>
> Among the options suggested was ?Salmonella?. One person (nameless)
> explained it to me as ?A small female fish?. The community will be happy to
> know that in the voting, Salmonella received zero votes. If any other team
> would like to take the idea of salmonella after reading this email, I?d
> request that they please credit the Trove team for this suggestion ? We
> promise that we won?t use that logo and there will be no conflict. Here?s a
> picture of ?salmonella? [3].
>
> Other options which did not garner enough support included a whale, a
> koala bear, and a sea dragon.
>
> Thanks,
>
> -amrith
>
> [1] http://cdn.xl.thumbs.canstockphoto.com/canstock26887885.jpg
> [2]
> http://image.shutterstock.com/z/stock-photo-an-open-sea-shell-with-a-pearl-inside-52231675.jpg
> [3] https://c2.staticflickr.com/8/7032/6400406229_f99d5e268e_b.jpg
>
>
>
>
> From: Heidi Joy Tretheway [mailto:heidijoy at openstack.org]
> Sent: Monday, July 11, 2016 11:00 AM
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] Mascot/logo for your project
>
> The Foundation would like to help promote OpenStack projects in the big
> tent with branding and marketing services. The idea is to create a family
> of logos for OpenStack projects that are unique, yet immediately
> identifiable as part of OpenStack. We?ll be using these logos to promote
> your project on the OpenStack website, at the Summit and in marketing
> materials.
>
>
> We?re asking project teams to choose a mascot to represent as their logo.
> Your team can select your own mascot, and then we?ll have an illustrator
> create the logo for you (and we also plan to print some special collateral
> for your team in Barcelona).
>
>
> If your team already has a logo based on a mascot from nature, you?ll have
> first priority to keep that mascot, and the illustrator will restyle it to
> be consistent with the other projects. If you have a logo that doesn?t have
> a mascot from nature, we encourage your team to choose a mascot.
>
>
> Here?s an FAQ and examples of what the logos can look like:
> http://www.openstack.org/project-mascots
> We?ve also recorded a quick video with an overview of the project:
> https://youtu.be/LOdsuNr2T-o
>
>
> You can get in touch with your PTL to participate in the logo choice
> discussion. If you have more questions, I?m happy to help. :-)
>
>
> Cheers,
> Heidi Joy
>
> ______
> Heidi Joy Tretheway
> Senior Marketing Manager, OpenStack Foundation
> 503 816 9769 | skype: heidi.tretheway
>
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160720/299b7b6f/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 36
> Date: Wed, 20 Jul 2016 19:03:02 +0000
> From: Amrith Kumar <amrith at tesora.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [trove] no weekly meeting next week
> Message-ID:
> <
> CO2PR17MB001125161A4E066C6ABF341BA0080 at CO2PR17MB0011.namprd17.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> We won't have our weekly meeting next week as we are going to be meeting
> anyway for our virtual mid-cycle.
>
> Thanks,
>
> -amrith
>
>
>
> ------------------------------
>
> Message: 37
> Date: Wed, 20 Jul 2016 12:22:56 -0700
> From: Joshua Harlow <harlowja at fastmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins
> for all)
> Message-ID: <578FCF90.7080402 at fastmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Duncan Thomas wrote:
> >
> >
> > On 20 July 2016 at 19:57, James Bottomley
> > <James.Bottomley at hansenpartnership.com
> > <mailto:James.Bottomley at hansenpartnership.com>> wrote:
> >
> >
> > OK, I accept your analogy, even though I would view currency as the
> > will to create and push patches.
> >
> > The problem you describe: getting the recipients to listen and accept
> > your patches, is also a common one. The first essential is simple
> > minimal patches because they're hard to reject.
> >
> > Once you've overcome the reject barrier, there's the indifference one
> > (no-one says no, but no-one says yes).
> >
> > [snip]
> >
> > The trouble with drive-by architecture patches (or large feature patches
> > of any kind) is that it is often better *not* to merge them if you don't
> > think the contributor is going to stick around for a while. This
> > changes are usually intrusive, and have repercussions that take time to
> > discover. It's often difficult to keep a change clean when the original
> > author isn't around to review the follow-on work.
>
> Agreed, and knowing where yahoo and HP(e) are at right now (with regards
> to openstack and ...) these kind of things are a little more prevalent
> (with regards to quota, tasks...) now-a-days (for better or worse); not
> how I want it to be but it's reality.
>
> Which I guess is why I'd be nice to have cross-project architecture
> 'standardization' (? for lack of better word) with a more long term
> strategic vision (vs localized tactical visions). Such things are
> obviously not hard to get going (and are equally hard to sustain).
>
> >
> >
> __________________________________________________________________________
> > 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-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 51, Issue 42
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160721/ac1d7fe8/attachment.html>
More information about the OpenStack-dev
mailing list
