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