<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 4 September 2015 at 08:00, <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] Concern about XStatic-bootswatch imports from<br>
<a href="http://fonts.googleapis.com" rel="noreferrer" target="_blank">fonts.googleapis.com</a> (Thomas Goirand)<br>
2. Re: cloud-init IPv6 support (Fox, Kevin M)<br>
3. [horizon] Concern about XStatic-bootswatch imports from<br>
<a href="http://fonts.googleapis.com" rel="noreferrer" target="_blank">fonts.googleapis.com</a> (Diana Whitten)<br>
4. Re: [Heat] convergence rally test results (so far) (Angus Salkeld)<br>
5. [Ironic] Liberty release plans (Jim Rollenhagen)<br>
6. [Ironic] Introducing ironic-lib 0.1.0 (Jim Rollenhagen)<br>
7. Re: [neutron] pushing changes through the gate (Hirofumi Ichihara)<br>
8. [magnum]keystone version (??)<br>
9. [Cross Project] [Neutron] [Nova] Tox.ini changes for<br>
Constraints testing (Sachi King)<br>
10. Re: FFE Request for completion of data driven assignment<br>
testing in Keystone (David Stanek)<br>
11. Re: [neutron] pushing changes through the gate (Armando M.)<br>
12. Re: FFE Request for completion of data driven assignment<br>
testing in Keystone (Morgan Fainberg)<br>
13. Re: Scheduler hints, API and Objects (Ken'ichi Ohmichi)<br>
14. [kolla][doc] Kolla documentation now live on<br>
<a href="http://docs.openstack.org" rel="noreferrer" target="_blank">docs.openstack.org</a>! (Steven Dake (stdake))<br>
15. Re: FFE Request for completion of data driven assignment<br>
testing in Keystone (Morgan Fainberg)<br>
16. Re: [Openstack-operators] [Neutron] Allowing DNS suffix to be<br>
set per subnet (at least per tenant) (Daniel Comnea)<br>
17. What's Up, Doc? 4 September, 2015 (Lana Brindley)<br>
18. Re: [infra][third-party][CI] Third-party oses in<br>
devstack-gate (Evgeny Antyshev)<br>
19. Re: [Openstack-operators] [Neutron] Allowing DNS suffix to be<br>
set per subnet (at least per tenant) (Ihar Hrachyshka)<br>
20. Re: [Openstack] [ANN] OpenStack Kilo on Ubuntu fully<br>
automated with Ansible! Ready for NFV L2 Bridges via Heat!<br>
(Jose Manuel Ferrer Mosteiro)<br>
21. Re: FFE Request for completion of data driven assignment<br>
testing in Keystone (Thierry Carrez)<br>
22. Re: [infra][third-party][CI] Third-party oses in<br>
devstack-gate (Daniel Mellado)<br>
23. [murano] [dashboard] Remove the owner filter from "Package<br>
Definitions" page (Dmitro Dovbii)<br>
24. Re: [sahara] Request for Feature Freeze Exception<br>
(Sergey Reshetnyak)<br>
25. [sahara] FFE request for heat wait condition support<br>
(Sergey Reshetnyak)<br>
26. Re: Scheduler hints, API and Objects (Ken'ichi Ohmichi)<br>
27. Re: Scheduler hints, API and Objects (Alex Xu)<br>
28. Re: [murano] [dashboard] Remove the owner filter from<br>
"Package Definitions" page (Alexander Tivelkov)<br>
29. [all] Mitaka Design Summit - Proposed slot allocation<br>
(Thierry Carrez)<br>
30. Re: Scheduler hints, API and Objects (Ken'ichi Ohmichi)<br>
31. Re: [sahara] FFE request for heat wait condition support<br>
(Vitaly Gridnev)<br>
32. Re: Scheduler hints, API and Objects (Sylvain Bauza)<br>
33. Re: [openstack-announce] [release][nova] python-novaclient<br>
release 2.28.0 (liberty) (Sean Dague)<br>
34. Re: [openstack-announce] [release][nova] python-novaclient<br>
release 2.28.0 (liberty) (Sean Dague)<br>
35. Re: [all] Mitaka Design Summit - Proposed slot allocation<br>
(Flavio Percoco)<br>
36. Re: [murano] [dashboard] Remove the owner filter from<br>
"Package Definitions" page (Ekaterina Chernova)<br>
37. Re: [all] Mitaka Design Summit - Proposed slot allocation<br>
(Dmitry Tantsur)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 04 Sep 2015 00:06:26 +0200<br>
From: Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a>><br>
To: Diana Whitten <<a href="mailto:hurgleburgler@gmail.com">hurgleburgler@gmail.com</a>><br>
Cc: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [horizon] Concern about<br>
XStatic-bootswatch imports from <a href="http://fonts.googleapis.com" rel="noreferrer" target="_blank">fonts.googleapis.com</a><br>
Message-ID: <<a href="mailto:55E8C462.5050804@debian.org">55E8C462.5050804@debian.org</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On 09/03/2015 07:58 PM, Diana Whitten wrote:<br>
> Thomas,<br>
><br>
> Sorry for the slow response, since I wasn't on the right mailing list yet.<br>
><br>
> 1. I'm trying to figure out the best way possible to address this<br>
> security breach. I think that the best way to fix this is to augment<br>
> Bootswatch to only use the URL through a parameter, that can be easily<br>
> configured. I have an Issue open on their code right now for this very<br>
> feature.<br>
><br>
> Until then, I think that we can easily address the issue from the point<br>
> of view of Horizon, such that we:<br>
> 1. Remove all instances of '<a href="http://fonts.googleapis.com" rel="noreferrer" target="_blank">fonts.googleapis.com</a><br>
> <<a href="http://fonts.googleapis.com" rel="noreferrer" target="_blank">http://fonts.googleapis.com</a>>' from the SCSS during the preprocessor<br>
> step. Therefore, no outside URLs that point to this location EVER get hit<br>
> *or*<br>
> 2. Until the issue that I created on Bootswatch can be addressed, we<br>
> can include that file that is making the call in the tree and remove the<br>
> @import entirely.<br>
> *or*<br>
> 3. Until the issue that I created on Bootswatch can be addressed, we<br>
> can include the two files that we need from bootswatch 'paper' entirely,<br>
> and remove Bootswatch as a requirement until we can get an updated package<br>
><br>
> 2. Its not getting used at all ... anyways. I packaged up the font and<br>
> make it also available via xstatic. I realized there was some questions<br>
> about where the versioning came from, but it looks like you might have<br>
> been looking at the wrong github repo:<br>
> <a href="https://github.com/Templarian/MaterialDesign-Webfont/releases" rel="noreferrer" target="_blank">https://github.com/Templarian/MaterialDesign-Webfont/releases</a><br>
><br>
> You can absolutely patch out the fonts. The result will not be ugly;<br>
> each font should fall back to a nice system font. But, we are only<br>
> using the 'Paper' theme out of Bootswatch right now and therefore only<br>
> packaged up the specific font required for it.<br>
><br>
> Ping me on IRC @hurgleburgler<br>
><br>
> - Diana<br>
<br>
Diana,<br>
<br>
Thanks a lot for all of these answers. It's really helping!<br>
<br>
So if I understand well, xstatic-bootswatch is an already stripped down<br>
version of the upstream bootswatch. But Horizon only use a single theme<br>
out of the 16 available in the XStatic package. Then why aren't we using<br>
an xstatic package which would include only the paper theme? Or is there<br>
something that I didn't understand?<br>
<br>
Removing the <a href="http://fonts.googleapis.com" rel="noreferrer" target="_blank">fonts.googleapis.com</a> at runtime by Horizon isn't an option<br>
for distributions, as we don't want to ship a .css file including such<br>
an import anyway. So definitively, I'd be patching out the @import away.<br>
But will there be a mechanism to load the Roboto font, packaged as<br>
xstatic, then? Falling back to a system font could have surprising results.<br>
<br>
This was for the bootswatch issue. Now, about the mdi, which IMO isn't<br>
as much as a problem.<br>
<br>
The Git repository at:<br>
<a href="https://github.com/Templarian/MaterialDesign-Webfont/releases" rel="noreferrer" target="_blank">https://github.com/Templarian/MaterialDesign-Webfont/releases</a><br>
<br>
I wonder how it was created. Apparently, the font is made up of images<br>
that are coming from this repository:<br>
<a href="https://github.com/google/material-design-icons" rel="noreferrer" target="_blank">https://github.com/google/material-design-icons</a><br>
<br>
the question is then, how has this font been made? Was it done "by hand"<br>
by an artist? Or was there some kind of scripting involved? If it is the<br>
later, then I'd like to build the font out of the original sources if<br>
possible. If I can't find how it was done, then I'll probably end up<br>
just packaging the font as-is, but I'd very much prefer to understand<br>
what has been done.<br>
<br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 3 Sep 2015 23:03:48 +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>>, Kevin Benton <<a href="mailto:blak111@gmail.com">blak111@gmail.com</a>><br>
Cc: PAUL CARVER <<a href="mailto:pc2929@att.com">pc2929@att.com</a>><br>
Subject: Re: [openstack-dev] cloud-init IPv6 support<br>
Message-ID:<br>
<<a href="mailto:1A3C52DFCD06494D8528644858247BF01A2F0CB6@EX10MBOX03.pnnl.gov">1A3C52DFCD06494D8528644858247BF01A2F0CB6@EX10MBOX03.pnnl.gov</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
So if we define the well known address and cloud-init adopts it, then Amazon should be inclined to adopt it too. :)<br>
<br>
Why always chase Amazon?<br>
<br>
Thanks,<br>
Kevin<br>
________________________________________<br>
From: Steve Gordon [<a href="mailto:sgordon@redhat.com">sgordon@redhat.com</a>]<br>
Sent: Thursday, September 03, 2015 11:06 AM<br>
To: Kevin Benton<br>
Cc: OpenStack Development Mailing List (not for usage questions); PAUL CARVER<br>
Subject: Re: [openstack-dev] [Neutron] cloud-init IPv6 support<br>
<br>
----- Original Message -----<br>
> From: "Kevin Benton" <<a href="mailto:blak111@gmail.com">blak111@gmail.com</a>><br>
><br>
> When we discussed this before on the neutron channel, I thought it was<br>
> because cloud-init doesn't support IPv6. We had wasted quite a bit of time<br>
> talking about adding support to our metadata service because I was under<br>
> the impression that cloud-init already did support IPv6.<br>
><br>
> IIRC, the argument against adding IPv6 support to cloud-init was that it<br>
> might be incompatible with how AWS chooses to implement IPv6 metadata, so<br>
> AWS would require a fork or other incompatible alternative to cloud-init in<br>
> all of their images.<br>
><br>
> Is that right?<br>
<br>
That's certainly my understanding of the status quo, I was enquiring primarily to check it was still accurate.<br>
<br>
-Steve<br>
<br>
> On Thu, Sep 3, 2015 at 7:30 AM, Sean M. Collins <<a href="mailto:sean@coreitpro.com">sean@coreitpro.com</a>> wrote:<br>
><br>
> > It's not a case of cloud-init supporting IPv6 - The Amazon EC2 metadata<br>
> > API defines transport level details about the API - and currently only<br>
> > defines a well known IPv4 link local address to connect to. No well known<br>
> > link local IPv6 address has been defined.<br>
> ><br>
> > I usually recommend config-drive for IPv6 enabled clouds due to this.<br>
> > --<br>
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.<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>
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: 3<br>
Date: Thu, 3 Sep 2015 16:11:48 -0700<br>
From: Diana Whitten <<a href="mailto:hurgleburgler@gmail.com">hurgleburgler@gmail.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [horizon] Concern about XStatic-bootswatch<br>
imports from <a href="http://fonts.googleapis.com" rel="noreferrer" target="_blank">fonts.googleapis.com</a><br>
Message-ID:<br>
<<a href="mailto:CABswzdHTq_WqX6XmfMpdDrt0pDa2DZS3spw0O26rErtE7h9emg@mail.gmail.com">CABswzdHTq_WqX6XmfMpdDrt0pDa2DZS3spw0O26rErtE7h9emg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Thomas,<br>
<br>
Lots of movement on this today. I was able to get Bootswatch to roll a new<br>
package to accommodate our need to not pull in the URL by default any<br>
longer. This is now a configurable value that can be set by a variable.<br>
The variable's default value is still the google URL, but Horizon will<br>
reset that when we pull it it.<br>
<br>
The bootswatch package isn't a stripped down version of upstream<br>
bootswatch, but it was created from the already existing bower package for<br>
Bootswatch. It is easier to maintain parity with the bower package, than<br>
trying to pull apart very specific themes out of it. Also, some upcoming<br>
features plan to take advantage of some of the other themes as well.<br>
<br>
As for the MDI package, there are services out there that can convert the<br>
raw SVG that is available directly from google (<br>
<a href="https://github.com/google/material-design-icons" rel="noreferrer" target="_blank">https://github.com/google/material-design-icons</a>) into a variety of Web Font<br>
Formats, BUT ... this is a not a direct mapping of Google's Material Design<br>
Icons. The Templarian repo is actually a bigger set of icons, it includes<br>
Google's Icons, but also a number of Community supports and contributed<br>
(under the same license) icons. See the full set here:<br>
<a href="https://materialdesignicons.com/" rel="noreferrer" target="_blank">https://materialdesignicons.com/</a>. Templarian maintains the SVGs of these<br>
at <a href="https://github.com/Templarian/MaterialDesign" rel="noreferrer" target="_blank">https://github.com/Templarian/MaterialDesign</a>, however, they also<br>
maintain the Bower package (that the xstatic inherits from) at<br>
<a href="https://github.com/Templarian/MaterialDesign-Webfont" rel="noreferrer" target="_blank">https://github.com/Templarian/MaterialDesign-Webfont</a>.<br>
<br>
Best,<br>
Diana<br>
<br>
<br>
<br>
On Thu, Sep 3, 2015 at 3:06 PM, Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a>> wrote:<br>
<br>
> On 09/03/2015 07:58 PM, Diana Whitten wrote:<br>
> > Thomas,<br>
> ><br>
> > Sorry for the slow response, since I wasn't on the right mailing list<br>
> yet.<br>
> ><br>
> > 1. I'm trying to figure out the best way possible to address this<br>
> > security breach. I think that the best way to fix this is to augment<br>
> > Bootswatch to only use the URL through a parameter, that can be easily<br>
> > configured. I have an Issue open on their code right now for this very<br>
> > feature.<br>
> ><br>
> > Until then, I think that we can easily address the issue from the point<br>
> > of view of Horizon, such that we:<br>
> > 1. Remove all instances of '<a href="http://fonts.googleapis.com" rel="noreferrer" target="_blank">fonts.googleapis.com</a><br>
> > <<a href="http://fonts.googleapis.com" rel="noreferrer" target="_blank">http://fonts.googleapis.com</a>>' from the SCSS during the preprocessor<br>
> > step. Therefore, no outside URLs that point to this location EVER get hit<br>
> > *or*<br>
> > 2. Until the issue that I created on Bootswatch can be addressed, we<br>
> > can include that file that is making the call in the tree and remove the<br>
> > @import entirely.<br>
> > *or*<br>
> > 3. Until the issue that I created on Bootswatch can be addressed, we<br>
> > can include the two files that we need from bootswatch 'paper' entirely,<br>
> > and remove Bootswatch as a requirement until we can get an updated<br>
> package<br>
> ><br>
> > 2. Its not getting used at all ... anyways. I packaged up the font and<br>
> > make it also available via xstatic. I realized there was some questions<br>
> > about where the versioning came from, but it looks like you might have<br>
> > been looking at the wrong github repo:<br>
> > <a href="https://github.com/Templarian/MaterialDesign-Webfont/releases" rel="noreferrer" target="_blank">https://github.com/Templarian/MaterialDesign-Webfont/releases</a><br>
> ><br>
> > You can absolutely patch out the fonts. The result will not be ugly;<br>
> > each font should fall back to a nice system font. But, we are only<br>
> > using the 'Paper' theme out of Bootswatch right now and therefore only<br>
> > packaged up the specific font required for it.<br>
> ><br>
> > Ping me on IRC @hurgleburgler<br>
> ><br>
> > - Diana<br>
><br>
> Diana,<br>
><br>
> Thanks a lot for all of these answers. It's really helping!<br>
><br>
> So if I understand well, xstatic-bootswatch is an already stripped down<br>
> version of the upstream bootswatch. But Horizon only use a single theme<br>
> out of the 16 available in the XStatic package. Then why aren't we using<br>
> an xstatic package which would include only the paper theme? Or is there<br>
> something that I didn't understand?<br>
><br>
> Removing the <a href="http://fonts.googleapis.com" rel="noreferrer" target="_blank">fonts.googleapis.com</a> at runtime by Horizon isn't an option<br>
> for distributions, as we don't want to ship a .css file including such<br>
> an import anyway. So definitively, I'd be patching out the @import away.<br>
> But will there be a mechanism to load the Roboto font, packaged as<br>
> xstatic, then? Falling back to a system font could have surprising results.<br>
><br>
> This was for the bootswatch issue. Now, about the mdi, which IMO isn't<br>
> as much as a problem.<br>
><br>
> The Git repository at:<br>
> <a href="https://github.com/Templarian/MaterialDesign-Webfont/releases" rel="noreferrer" target="_blank">https://github.com/Templarian/MaterialDesign-Webfont/releases</a><br>
><br>
> I wonder how it was created. Apparently, the font is made up of images<br>
> that are coming from this repository:<br>
> <a href="https://github.com/google/material-design-icons" rel="noreferrer" target="_blank">https://github.com/google/material-design-icons</a><br>
><br>
> the question is then, how has this font been made? Was it done "by hand"<br>
> by an artist? Or was there some kind of scripting involved? If it is the<br>
> later, then I'd like to build the font out of the original sources if<br>
> possible. If I can't find how it was done, then I'll probably end up<br>
> just packaging the font as-is, but I'd very much prefer to understand<br>
> what has been done.<br>
><br>
> Cheers,<br>
><br>
> Thomas Goirand (zigo)<br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150903/1be665a8/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150903/1be665a8/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Fri, 04 Sep 2015 00:17:20 +0000<br>
From: Angus Salkeld <<a href="mailto:asalkeld@mirantis.com">asalkeld@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] [Heat] convergence rally test results (so<br>
far)<br>
Message-ID:<br>
<<a href="mailto:CAA16xcx7R0eNatKKrq1rxLX7OGL37acKRFis5S1Pmt8-ZJq%2Bdg@mail.gmail.com">CAA16xcx7R0eNatKKrq1rxLX7OGL37acKRFis5S1Pmt8-ZJq+dg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Fri, Sep 4, 2015 at 12:48 AM Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>> wrote:<br>
<br>
> On 03/09/15 02:56, Angus Salkeld wrote:<br>
> > On Thu, Sep 3, 2015 at 3:53 AM Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a><br>
> > <mailto:<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>>> wrote:<br>
> ><br>
> > On 02/09/15 04:55, Steven Hardy wrote:<br>
> > > On Wed, Sep 02, 2015 at 04:33:36PM +1200, Robert Collins wrote:<br>
> > >> On 2 September 2015 at 11:53, Angus Salkeld<br>
> > <<a href="mailto:asalkeld@mirantis.com">asalkeld@mirantis.com</a> <mailto:<a href="mailto:asalkeld@mirantis.com">asalkeld@mirantis.com</a>>> wrote:<br>
> > >><br>
> > >>> 1. limit the number of resource actions in parallel (maybe base<br>
> > on the<br>
> > >>> number of cores)<br>
> > >><br>
> > >> I'm having trouble mapping that back to 'and heat-engine is<br>
> > running on<br>
> > >> 3 separate servers'.<br>
> > ><br>
> > > I think Angus was responding to my test feedback, which was a<br>
> > different<br>
> > > setup, one 4-core laptop running heat-engine with 4 worker<br>
> processes.<br>
> > ><br>
> > > In that environment, the level of additional concurrency becomes<br>
> > a problem<br>
> > > because all heat workers become so busy that creating a large<br>
> stack<br>
> > > DoSes the Heat services, and in my case also the DB.<br>
> > ><br>
> > > If we had a configurable option, similar to num_engine_workers,<br>
> which<br>
> > > enabled control of the number of resource actions in parallel, I<br>
> > probably<br>
> > > could have controlled that explosion in activity to a more<br>
> > managable series<br>
> > > of tasks, e.g I'd set num_resource_actions to<br>
> > (num_engine_workers*2) or<br>
> > > something.<br>
> ><br>
> > I think that's actually the opposite of what we need.<br>
> ><br>
> > The resource actions are just sent to the worker queue to get<br>
> processed<br>
> > whenever. One day we will get to the point where we are overflowing<br>
> the<br>
> > queue, but I guarantee that we are nowhere near that day. If we are<br>
> > DoSing ourselves, it can only be because we're pulling *everything*<br>
> off<br>
> > the queue and starting it in separate greenthreads.<br>
> ><br>
> ><br>
> > worker does not use a greenthread per job like service.py does.<br>
> > This issue is if you have actions that are fast you can hit the db hard.<br>
> ><br>
> > QueuePool limit of size 5 overflow 10 reached, connection timed out,<br>
> > timeout 30<br>
> ><br>
> > It seems like it's not very hard to hit this limit. It comes from simply<br>
> > loading<br>
> > the resource in the worker:<br>
> > "/home/angus/work/heat/heat/engine/worker.py", line 276, in<br>
> check_resource<br>
> > "/home/angus/work/heat/heat/engine/worker.py", line 145, in<br>
> _load_resource<br>
> > "/home/angus/work/heat/heat/engine/resource.py", line 290, in load<br>
> > resource_objects.Resource.get_obj(context, resource_id)<br>
><br>
> This is probably me being naive, but that sounds strange. I would have<br>
> thought that there is no way to exhaust the connection pool by doing<br>
> lots of actions in rapid succession. I'd have guessed that the only way<br>
> to exhaust a connection pool would be to have lots of connections open<br>
> simultaneously. That suggests to me that either we are failing to<br>
> expeditiously close connections and return them to the pool, or that we<br>
> are - explicitly or implicitly - processing a bunch of messages in<br>
> parallel.<br>
><br>
<br>
I suspect we are leaking sessions, I have updated this bug to make sure we<br>
focus on figuring out the root cause of this before jumping to conclusions:<br>
<a href="https://bugs.launchpad.net/heat/+bug/1491185" rel="noreferrer" target="_blank">https://bugs.launchpad.net/heat/+bug/1491185</a><br>
<br>
-A<br>
<br>
<br>
><br>
> > In an ideal world, we might only ever pull one task off that queue<br>
> at a<br>
> > time. Any time the task is sleeping, we would use for processing<br>
> stuff<br>
> > off the engine queue (which needs a quick response, since it is<br>
> serving<br>
> > the ReST API). The trouble is that you need a *huge* number of<br>
> > heat-engines to handle stuff in parallel. In the reductio-ad-absurdum<br>
> > case of a single engine only processing a single task at a time,<br>
> we're<br>
> > back to creating resources serially. So we probably want a higher<br>
> number<br>
> > than 1. (Phase 2 of convergence will make tasks much smaller, and may<br>
> > even get us down to the point where we can pull only a single task<br>
> at a<br>
> > time.)<br>
> ><br>
> > However, the fewer engines you have, the more greenthreads we'll<br>
> have to<br>
> > allow to get some semblance of parallelism. To the extent that more<br>
> > cores means more engines (which assumes all running on one box, but<br>
> > still), the number of cores is negatively correlated with the number<br>
> of<br>
> > tasks that we want to allow.<br>
> ><br>
> > Note that all of the greenthreads run in a single CPU thread, so<br>
> having<br>
> > more cores doesn't help us at all with processing more stuff in<br>
> > parallel.<br>
> ><br>
> ><br>
> > Except, as I said above, we are not creating greenthreads in worker.<br>
><br>
> Well, maybe we'll need to in order to make things still work sanely with<br>
> a low number of engines :) (Should be pretty easy to do with a semaphore.)<br>
><br>
> I think what y'all are suggesting is limiting the number of jobs that go<br>
> into the queue... that's quite wrong IMO. Apart from the fact it's<br>
> impossible (resources put jobs into the queue entirely independently,<br>
> and have no knowledge of the global state required to throttle inputs),<br>
> we shouldn't implement an in-memory queue with long-running tasks<br>
> containing state that can be lost if the process dies - the whole point<br>
> of convergence is we have... a message queue for that. We need to limit<br>
> the rate that stuff comes *out* of the queue. And, again, since we have<br>
> no knowledge of global state, we can only control the rate at which an<br>
> individual worker processes tasks. The way to avoid killing the DB is to<br>
> out a constant ceiling on the workers * concurrent_tasks_per_worker<br>
> product.<br>
><br>
> cheers,<br>
> Zane.<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/20150904/10ac4234/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/10ac4234/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Thu, 3 Sep 2015 17:18:15 -0700<br>
From: Jim Rollenhagen <<a href="mailto:jim@jimrollenhagen.com">jim@jimrollenhagen.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [Ironic] Liberty release plans<br>
Message-ID: <<a href="mailto:20150904001815.GA21846@jimrollenhagen.com">20150904001815.GA21846@jimrollenhagen.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Hi all,<br>
<br>
I wanted to lay down my thoughts on the rest of the cycle here.<br>
<br>
As you may know, we recently released Ironic 4.0.0. We've also released<br>
python-ironicclient 0.8.0 and ironic-lib 0.1.0 this week. Yay!<br>
<br>
I'd like to do two more server releases this cycle.<br>
<br>
* 4.1.0 - minor release to clean up some bugs on 4.0.0. The last<br>
patch[0] I wanted in this is in the gate right now. I'd like to<br>
release this on Tuesday, September 8.<br>
<br>
* 4.2.0 - this will become the stable/liberty branch. I'd like to<br>
release this in coordination with the rest of OpenStack's RC releases,<br>
and backport bug fixes as necessary, releasing 4.2.x for those.<br>
<br>
I've made lists of features and bugs we want to land in 4.2.0 on our<br>
whiteboard[1]. Let's try to prioritize code and review for those as much<br>
as possible.<br>
<br>
I'd like to try to release 4.2.0 on Thursday, September 24. As such, I'd<br>
like reviewers to respect a soft code freeze beginning on Thursday,<br>
September 17. I don't want to say "don't merge features", but please<br>
don't merge anything risky after that date.<br>
<br>
As always, questions/comments/concerns welcome.<br>
<br>
// jim<br>
<br>
[0] <a href="https://review.openstack.org/#/c/219398/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/219398/</a><br>
[1] <a href="https://etherpad.openstack.org/p/IronicWhiteBoard" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/IronicWhiteBoard</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Thu, 3 Sep 2015 17:24:00 -0700<br>
From: Jim Rollenhagen <<a href="mailto:jim@jimrollenhagen.com">jim@jimrollenhagen.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [Ironic] Introducing ironic-lib 0.1.0<br>
Message-ID: <<a href="mailto:20150904002400.GB21846@jimrollenhagen.com">20150904002400.GB21846@jimrollenhagen.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Hi all,<br>
<br>
I'm proud to announce the initial release of ironic-lib! This library<br>
was built to share code between various Ironic projects. The initial<br>
release contains an up-to-date copy of Ironic's disk partitioning code,<br>
to be shared between Ironic and ironic-python-agent.<br>
<br>
At the beginning of the Mitaka cycle, we'll begin to refactor Ironic to<br>
use this code, and also start using it in IPA to be able to deploy<br>
partition images, support ephemeral volumes, etc., without relying on<br>
iSCSI.<br>
<br>
PyPI: <a href="https://pypi.python.org/pypi/ironic-lib" rel="noreferrer" target="_blank">https://pypi.python.org/pypi/ironic-lib</a><br>
Git: <a href="http://git.openstack.org/cgit/openstack/ironic-lib/" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/ironic-lib/</a><br>
Launchpad: <a href="https://launchpad.net/ironic-lib" rel="noreferrer" target="_blank">https://launchpad.net/ironic-lib</a><br>
global-requirements patch: <a href="https://review.openstack.org/#/c/219011/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/219011/</a><br>
<br>
As always, questions/comments/concerns welcome. :)<br>
<br>
// jim<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Fri, 4 Sep 2015 09:55:40 +0900<br>
From: Hirofumi Ichihara <<a href="mailto:ichihara.hirofumi@lab.ntt.co.jp">ichihara.hirofumi@lab.ntt.co.jp</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] [neutron] pushing changes through the<br>
gate<br>
Message-ID: <<a href="mailto:AB2E7CE7-ECCC-49D9-AB20-46135559D3DE@lab.ntt.co.jp">AB2E7CE7-ECCC-49D9-AB20-46135559D3DE@lab.ntt.co.jp</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Good work and thank you for your help with my patch.<br>
<br>
Anyway, I don?t know when does bp owner have to merge the code by.<br>
I can see the following sentence in bp rule[1]<br>
?The PTL will create a <release>-backlog directory during the RC window and move all specs which didn?t make the <release> there.?<br>
Did we have to merge the implementation by L-3? Or can we merge it in RC-1?<br>
<br>
[1]: <a href="http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-bp-and-spec-notes" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-bp-and-spec-notes</a><br>
<br>
Thanks,<br>
Hirofumi<br>
<br>
> On 2015/09/04, at 7:00, Armando M. <<a href="mailto:armamig@gmail.com">armamig@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On 2 September 2015 at 09:40, Armando M. <<a href="mailto:armamig@gmail.com">armamig@gmail.com</a> <mailto:<a href="mailto:armamig@gmail.com">armamig@gmail.com</a>>> wrote:<br>
> Hi,<br>
><br>
> By now you may have seen that I have taken out your change from the gate and given it a -2: don't despair! I am only doing it to give priority to the stuff that needs to merge in order to get [1] into a much better shape.<br>
><br>
> If you have an important fix, please target it for RC1 or talk to me or Doug (or Kyle when he's back from his time off), before putting it in the gate queue. If everyone is not conscious of the other, we'll only end up stepping on each other, and nothing moves forward.<br>
><br>
> Let's give priority to gate stabilization fixes, and targeted stuff.<br>
><br>
> Happy merging...not!<br>
><br>
> Many thanks,<br>
> Armando<br>
><br>
> [1] <a href="https://launchpad.net/neutron/+milestone/liberty-3" rel="noreferrer" target="_blank">https://launchpad.net/neutron/+milestone/liberty-3</a> <<a href="https://launchpad.net/neutron/+milestone/liberty-3" rel="noreferrer" target="_blank">https://launchpad.net/neutron/+milestone/liberty-3</a>><br>
> [2] <a href="https://launchpad.net/neutron/+milestone/liberty-rc1" rel="noreferrer" target="_blank">https://launchpad.net/neutron/+milestone/liberty-rc1</a> <<a href="https://launchpad.net/neutron/+milestone/liberty-rc1" rel="noreferrer" target="_blank">https://launchpad.net/neutron/+milestone/liberty-rc1</a>><br>
><br>
> Download files for the milestone are available in [1]. We still have a lot to do as there are outstanding bugs and blueprints that will have to be merged in the RC time windows.<br>
><br>
> Please be conscious of what you approve. Give priority to:<br>
><br>
> - Targeted bugs and blueprints in [2];<br>
> - Gate stability fixes or patches that aim at helping troubleshooting;<br>
><br>
> In these busy times, please refrain from proposing/merging:<br>
><br>
> - Silly rebase generators (e.g. spelling mistakes);<br>
> - Cosmetic changes (e.g. minor doc strings/comment improvements);<br>
> - Refactoring required while dealing with the above;<br>
> - A dozen of patches stacked on top of each other;<br>
><br>
> Every rule has its own exception, so don't take this literally.<br>
><br>
> If you are unsure, please reach out to me, Kyle or your Lieutenant and we'll target stuff that is worth targeting.<br>
><br>
> As for the rest, I am gonna be merciless and -2 anything than I can find, in order to keep our gate lean and sane :)<br>
><br>
> Thanks and happy hacking.<br>
><br>
> A.<br>
><br>
> [1] <a href="https://launchpad.net/neutron/+milestone/liberty-3" rel="noreferrer" target="_blank">https://launchpad.net/neutron/+milestone/liberty-3</a> <<a href="https://launchpad.net/neutron/+milestone/liberty-3" rel="noreferrer" target="_blank">https://launchpad.net/neutron/+milestone/liberty-3</a>><br>
> [2] <a href="https://launchpad.net/neutron/+milestone/liberty-rc1" rel="noreferrer" target="_blank">https://launchpad.net/neutron/+milestone/liberty-rc1</a> <<a href="https://launchpad.net/neutron/+milestone/liberty-rc1" rel="noreferrer" target="_blank">https://launchpad.net/neutron/+milestone/liberty-rc1</a>><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>>?subject:unsubscribe<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> <<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/20150904/f3e022b3/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/f3e022b3/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Fri, 4 Sep 2015 09:43:49 +0800<br>
From: ?? <<a href="mailto:wanghua.humble@gmail.com">wanghua.humble@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: [openstack-dev] [magnum]keystone version<br>
Message-ID:<br>
<CAH5-jC8FQ9C7ADVygXXVRyKMt867iBFsjimKp26db6=<a href="mailto:pFO27-g@mail.gmail.com">pFO27-g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi all,<br>
<br>
Now the keystoneclient in magnum only support keystone v3. Is is necessary<br>
to support keystone v2? Keystone v2 don't support trust.<br>
<br>
Regards,<br>
Wanghua<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/cfb1e890/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/cfb1e890/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Fri, 04 Sep 2015 12:16:00 +1000<br>
From: Sachi King <<a href="mailto:nakato@nakato.io">nakato@nakato.io</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [Cross Project] [Neutron] [Nova] Tox.ini<br>
changes for Constraints testing<br>
Message-ID: <1721376.LIrBB9dSzH@youmu><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Hi,<br>
<br>
I'm working on setting up both Nova and Neutron with constrained unit tests.<br>
More details about this can be found in the changes can be found in it's<br>
blueprint [0].<br>
<br>
An example issue this will prevent is Neutron's recent gate breakage caused<br>
by a new netaddr version. [1]<br>
<br>
Now that the base changes have landed in project-config the next step is to<br>
modify tox.ini to run an alterniate install command when called with the<br>
'constraints' factor.<br>
<br>
Nova: <a href="https://review.openstack.org/205931/" rel="noreferrer" target="_blank">https://review.openstack.org/205931/</a><br>
Neutron: <a href="https://review.openstack.org/219134/" rel="noreferrer" target="_blank">https://review.openstack.org/219134/</a><br>
<br>
This change is a no-op for current gate jobs and developer workflows, only<br>
adding the functionality required for the new constraints jobs and manual<br>
execution of the constrained tests when desired.<br>
<br>
Once these have been added we can then proceed adding the py27 and 34 jobs,<br>
which will be non-voting at this point.<br>
<br>
Nova: <a href="https://review.openstack.org/219582/" rel="noreferrer" target="_blank">https://review.openstack.org/219582/</a><br>
Neutron: <a href="https://review.openstack.org/219610/" rel="noreferrer" target="_blank">https://review.openstack.org/219610/</a><br>
<br>
[0] <a href="http://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html</a><br>
[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-August/073239.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-August/073239.html</a><br>
<br>
If there are any other projects interested in being an early adopter of<br>
constrained unit tests, please let me know.<br>
<br>
Cheers,<br>
Sachi<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Fri, 04 Sep 2015 02:28:09 +0000<br>
From: David Stanek <<a href="mailto:dstanek@dstanek.com">dstanek@dstanek.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] FFE Request for completion of data driven<br>
assignment testing in Keystone<br>
Message-ID:<br>
<CAO69Nd=<a href="mailto:i84FrR1f%2B0xHqb1S1jHytNFcbL%2B3%2By%2BYjpDEcDQVimA@mail.gmail.com">i84FrR1f+0xHqb1S1jHytNFcbL+3+y+YjpDEcDQVimA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Thu, Sep 3, 2015 at 3:44 PM Henry Nash <<a href="mailto:henryn@linux.vnet.ibm.com">henryn@linux.vnet.ibm.com</a>> wrote:<br>
<br>
><br>
> I would like to request an FFE for the remaining two patches that are<br>
> already in review (<a href="https://review.openstack.org/#/c/153897/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/153897/</a> and<br>
> <a href="https://review.openstack.org/#/c/154485/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/154485/</a>). These contain only test code<br>
> and no functional changes, and increase our test coverage - as well as<br>
> enable other items to be re-use the list_role_assignment backend method.<br>
><br>
<br>
Do we need a FFE for changes to tests?<br>
<br>
-- David<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/c592cdd5/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/c592cdd5/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Thu, 3 Sep 2015 19:36:51 -0700<br>
From: "Armando M." <<a href="mailto:armamig@gmail.com">armamig@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] [neutron] pushing changes through the<br>
gate<br>
Message-ID:<br>
<<a href="mailto:CAK%2BRQea9d57qka7st1zWHMzGF4qoWWB3MWrhQZThEn0LBFEEtg@mail.gmail.com">CAK+RQea9d57qka7st1zWHMzGF4qoWWB3MWrhQZThEn0LBFEEtg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On 3 September 2015 at 17:55, Hirofumi Ichihara <<br>
<a href="mailto:ichihara.hirofumi@lab.ntt.co.jp">ichihara.hirofumi@lab.ntt.co.jp</a>> wrote:<br>
<br>
> Good work and thank you for your help with my patch.<br>
><br>
> Anyway, I don?t know when does bp owner have to merge the code by.<br>
> I can see the following sentence in bp rule[1]<br>
> ?The PTL will create a <release>-backlog directory during the RC window<br>
> and move all specs which didn?t make the <release> there.?<br>
> Did we have to merge the implementation by L-3? Or can we merge it in RC-1?<br>
><br>
> [1]:<br>
> <a href="http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-bp-and-spec-notes" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-bp-and-spec-notes</a><br>
><br>
><br>
It depends on the extent of the changes remaining to merge. There is no<br>
hard and fast rule, because every blueprint is different: the code can be<br>
complex and pervasive, or simple and isolated. In the former even a small<br>
patch may be deferred, in the latter even a dozen patches could be merged<br>
during RC. Some other blueprints are best completed during feature freeze,<br>
because of the rebase risk they cause...<br>
<br>
Bottom line: never leave it to last minute!<br>
<br>
<br>
> Thanks,<br>
> Hirofumi<br>
><br>
> On 2015/09/04, at 7:00, Armando M. <<a href="mailto:armamig@gmail.com">armamig@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On 2 September 2015 at 09:40, Armando M. <<a href="mailto:armamig@gmail.com">armamig@gmail.com</a>> wrote:<br>
><br>
>> Hi,<br>
>><br>
>> By now you may have seen that I have taken out your change from the gate<br>
>> and given it a -2: don't despair! I am only doing it to give priority to<br>
>> the stuff that needs to merge in order to get [1] into a much better shape.<br>
>><br>
>> If you have an important fix, please target it for RC1 or talk to me or<br>
>> Doug (or Kyle when he's back from his time off), before putting it in the<br>
>> gate queue. If everyone is not conscious of the other, we'll only end up<br>
>> stepping on each other, and nothing moves forward.<br>
>><br>
>> Let's give priority to gate stabilization fixes, and targeted stuff.<br>
>><br>
>> Happy merging...not!<br>
>><br>
>> Many thanks,<br>
>> Armando<br>
>><br>
>> [1] <a href="https://launchpad.net/neutron/+milestone/liberty-3" rel="noreferrer" target="_blank">https://launchpad.net/neutron/+milestone/liberty-3</a><br>
>> [2] <a href="https://launchpad.net/neutron/+milestone/liberty-rc1" rel="noreferrer" target="_blank">https://launchpad.net/neutron/+milestone/liberty-rc1</a><br>
>><br>
><br>
> Download files for the milestone are available in [1]. We still have a lot<br>
> to do as there are outstanding bugs and blueprints that will have to be<br>
> merged in the RC time windows.<br>
><br>
> Please be conscious of what you approve. Give priority to:<br>
><br>
> - Targeted bugs and blueprints in [2];<br>
> - Gate stability fixes or patches that aim at helping troubleshooting;<br>
><br>
> In these busy times, please refrain from proposing/merging:<br>
><br>
> - Silly rebase generators (e.g. spelling mistakes);<br>
> - Cosmetic changes (e.g. minor doc strings/comment improvements);<br>
> - Refactoring required while dealing with the above;<br>
> - A dozen of patches stacked on top of each other;<br>
><br>
> Every rule has its own exception, so don't take this literally.<br>
><br>
> If you are unsure, please reach out to me, Kyle or your Lieutenant and<br>
> we'll target stuff that is worth targeting.<br>
><br>
> As for the rest, I am gonna be merciless and -2 anything than I can find,<br>
> in order to keep our gate lean and sane :)<br>
><br>
> Thanks and happy hacking.<br>
><br>
> A.<br>
><br>
> [1] <a href="https://launchpad.net/neutron/+milestone/liberty-3" rel="noreferrer" target="_blank">https://launchpad.net/neutron/+milestone/liberty-3</a><br>
> [2] <a href="https://launchpad.net/neutron/+milestone/liberty-rc1" rel="noreferrer" target="_blank">https://launchpad.net/neutron/+milestone/liberty-rc1</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>
> 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/20150903/05913eda/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150903/05913eda/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Thu, 3 Sep 2015 19:48:17 -0700<br>
From: Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com">morgan.fainberg@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] FFE Request for completion of data driven<br>
assignment testing in Keystone<br>
Message-ID: <<a href="mailto:88142A7C-67DF-440F-A3B7-02966AAE6A9E@gmail.com">88142A7C-67DF-440F-A3B7-02966AAE6A9E@gmail.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
<br>
<br>
<br>
> On Sep 3, 2015, at 19:28, David Stanek <<a href="mailto:dstanek@dstanek.com">dstanek@dstanek.com</a>> wrote:<br>
><br>
><br>
>> On Thu, Sep 3, 2015 at 3:44 PM Henry Nash <<a href="mailto:henryn@linux.vnet.ibm.com">henryn@linux.vnet.ibm.com</a>> wrote:<br>
>><br>
>> I would like to request an FFE for the remaining two patches that are already in review (<a href="https://review.openstack.org/#/c/153897/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/153897/</a> and <a href="https://review.openstack.org/#/c/154485/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/154485/</a>). These contain only test code and no functional changes, and increase our test coverage - as well as enable other items to be re-use the list_role_assignment backend method.<br>
><br>
> Do we need a FFE for changes to tests?<br>
><br>
<br>
I would say "no".<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150903/6af2e685/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150903/6af2e685/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 13<br>
Date: Fri, 4 Sep 2015 12:14:07 +0900<br>
From: "Ken'ichi Ohmichi" <<a href="mailto:ken1ohmichi@gmail.com">ken1ohmichi@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] Scheduler hints, API and Objects<br>
Message-ID:<br>
<CAA393vixHPJ=Ay=<a href="mailto:79JepDeMA%2Be%2Bz8x_3FQcnT%2B8NcQCrvMtYFQ@mail.gmail.com">79JepDeMA+e+z8x_3FQcnT+8NcQCrvMtYFQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hi Andrew,<br>
<br>
Sorry for this late response, I missed it.<br>
<br>
2015-06-25 23:22 GMT+09:00 Andrew Laski <<a href="mailto:andrew@lascii.com">andrew@lascii.com</a>>:<br>
> I have been growing concerned recently with some attempts to formalize<br>
> scheduler hints, both with API validation and Nova objects defining them,<br>
> and want to air those concerns and see if others agree or can help me see<br>
> why I shouldn't worry.<br>
><br>
> Starting with the API I think the strict input validation that's being done,<br>
> as seen in<br>
> <a href="http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da</a>,<br>
> is unnecessary, and potentially problematic.<br>
><br>
> One problem is that it doesn't indicate anything useful for a client. The<br>
> schema indicates that there are hints available but can make no claim about<br>
> whether or not they're actually enabled. So while a microversion bump would<br>
> typically indicate a new feature available to an end user, in the case of a<br>
> new scheduler hint a microversion bump really indicates nothing at all. It<br>
> does ensure that if a scheduler hint is used that it's spelled properly and<br>
> the data type passed is correct, but that's primarily useful because there<br>
> is no feedback mechanism to indicate an invalid or unused scheduler hint. I<br>
> think the API schema is a poor proxy for that deficiency.<br>
><br>
> Since the exposure of a hint means nothing as far as its usefulness, I don't<br>
> think we should be codifying them as part of our API schema at this time.<br>
> At some point I imagine we'll evolve a more useful API for passing<br>
> information to the scheduler as part of a request, and when that happens I<br>
> don't think needing to support a myriad of meaningless hints in older API<br>
> versions is going to be desirable.<br>
><br>
> Finally, at this time I'm not sure we should take the stance that only<br>
> in-tree scheduler hints are supported. While I completely agree with the<br>
> desire to expose things in cross-cloud ways as we've done and are looking to<br>
> do with flavor and image properties I think scheduling is an area where we<br>
> want to allow some flexibility for deployers to write and expose scheduling<br>
> capabilities that meet their specific needs. Over time I hope we will get<br>
> to a place where some standardization can happen, but I don't think locking<br>
> in the current scheduling hints is the way forward for that. I would love<br>
> to hear from multi-cloud users here and get some input on whether that's<br>
> crazy and they are expecting benefits from validation on the current<br>
> scheduler hints.<br>
><br>
> Now, objects. As part of the work to formalize the request spec sent to the<br>
> scheduler there's an effort to make a scheduler hints object. This<br>
> formalizes them in the same way as the API with no benefit that I can see.<br>
> I won't duplicate my arguments above, but I feel the same way about the<br>
> objects as I do with the API. I don't think needing to update and object<br>
> version every time a new hint is added is useful at this time, nor do I<br>
> think we should lock in the current in-tree hints.<br>
><br>
> In the end this boils down to my concern that the scheduling hints api is a<br>
> really horrible user experience and I don't want it to be solidified in the<br>
> API or objects yet. I think we should re-examine how they're handled before<br>
> that happens.<br>
<br>
Now we are discussing this on <a href="https://review.openstack.org/#/c/217727/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/217727/</a><br>
for allowing out-of-tree scheduler-hints.<br>
When we wrote API schema for scheduler-hints, it was difficult to know<br>
what are available API parameters for scheduler-hints.<br>
Current API schema exposes them and I guess that is useful for API users also.<br>
<br>
One idea is that: How about auto-extending scheduler-hint API schema<br>
based on loaded schedulers?<br>
Now API schemas of "create/update/resize/rebuild a server" APIs are<br>
auto-extended based on loaded extensions by using stevedore<br>
library[1].<br>
I guess we can apply the same way for scheduler-hints also in long-term.<br>
Each scheduler needs to implement a method which returns available API<br>
parameter formats and nova-api tries to get them then extends<br>
scheduler-hints API schema with them.<br>
That means out-of-tree schedulers also will be available if they<br>
implement the method.<br>
# In short-term, I can see "blocking additionalProperties" validation<br>
disabled by the way.<br>
<br>
Thanks<br>
Ken Ohmichi<br>
<br>
---<br>
[1]: <a href="https://github.com/openstack/nova/blob/master/doc/source/api_plugins.rst#json-schema" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/master/doc/source/api_plugins.rst#json-schema</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Fri, 4 Sep 2015 03:20:16 +0000<br>
From: "Steven Dake (stdake)" <<a href="mailto:stdake@cisco.com">stdake@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] [kolla][doc] Kolla documentation now live on<br>
<a href="http://docs.openstack.org" rel="noreferrer" target="_blank">docs.openstack.org</a>!<br>
Message-ID: <<a href="mailto:D20E5BEE.11D6D%25stdake@cisco.com">D20E5BEE.11D6D%stdake@cisco.com</a>><br>
Content-Type: text/plain; charset="windows-1252"<br>
<br>
Hi folks,<br>
<br>
Kolla documentation is now published live to <a href="http://docs.openstack.org" rel="noreferrer" target="_blank">docs.openstack.org</a>. Our documentation still needs significant attention to be really high quality, but what we have is a start. Every code change results in new published documentation.<br>
<br>
I?d like to invite folks interested in getting involved in Kolla development to take a look at improving the documentation. One of the major components of any good open source project is fantastic documentation, and the more contribution we receive the better. As further encouragement to improving documentation no specific bugs or blueprints need be filed to make documentation changes. Our community decided on this exception early on to facilitate the enhancement of the documentation. The broader community looks forward to any contributions you can make!<br>
<br>
The documentation is located here:<br>
<br>
<a href="http://docs.openstack.org/developer/kolla" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/kolla</a><br>
<br>
Thanks,<br>
-steve<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/87d9cdd7/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/87d9cdd7/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 15<br>
Date: Thu, 3 Sep 2015 21:23:20 -0700<br>
From: Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com">morgan.fainberg@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] FFE Request for completion of data driven<br>
assignment testing in Keystone<br>
Message-ID: <<a href="mailto:E409D08D-203E-494A-9584-925740B121DE@gmail.com">E409D08D-203E-494A-9584-925740B121DE@gmail.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
<br>
<br>
> On Sep 3, 2015, at 19:48, Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com">morgan.fainberg@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
><br>
>> On Sep 3, 2015, at 19:28, David Stanek <<a href="mailto:dstanek@dstanek.com">dstanek@dstanek.com</a>> wrote:<br>
>><br>
>><br>
>>> On Thu, Sep 3, 2015 at 3:44 PM Henry Nash <<a href="mailto:henryn@linux.vnet.ibm.com">henryn@linux.vnet.ibm.com</a>> wrote:<br>
>>><br>
>>> I would like to request an FFE for the remaining two patches that are already in review (<a href="https://review.openstack.org/#/c/153897/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/153897/</a> and <a href="https://review.openstack.org/#/c/154485/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/154485/</a>). These contain only test code and no functional changes, and increase our test coverage - as well as enable other items to be re-use the list_role_assignment backend method.<br>
>><br>
>> Do we need a FFE for changes to tests?<br>
><br>
> I would say "no".<br>
<br>
To clarify "no" a FFE is not needed here. Not "no" to the additional testing.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150903/fd68da5f/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150903/fd68da5f/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 16<br>
Date: Fri, 4 Sep 2015 09:14:31 +0300<br>
From: Daniel Comnea <<a href="mailto:comnea.dani@gmail.com">comnea.dani@gmail.com</a>><br>
To: Kevin Benton <<a href="mailto:blak111@gmail.com">blak111@gmail.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>
"<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>"<br>
<<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Openstack-operators] [Neutron] Allowing<br>
DNS suffix to be set per subnet (at least per tenant)<br>
Message-ID:<br>
<<a href="mailto:CAOBAnZNj52t1-iKXqMPs6EBrw4SkL%2BOWrogMVb7ML_zyoRNiLA@mail.gmail.com">CAOBAnZNj52t1-iKXqMPs6EBrw4SkL+OWrogMVb7ML_zyoRNiLA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Kevin,<br>
<br>
am i right in saying that the merge above was packaged into Liberty ?<br>
<br>
Any chance to be ported to Juno?<br>
<br>
<br>
Cheers,<br>
Dani<br>
<br>
<br>
<br>
On Fri, Sep 4, 2015 at 12:21 AM, Kevin Benton <<a href="mailto:blak111@gmail.com">blak111@gmail.com</a>> wrote:<br>
<br>
> Support for that blueprint already merged[1] so it's a little late to<br>
> change it to per-subnet. If that is too fine-grained for your use-case, I<br>
> would file an RFE bug[2] to allow it to be set at the subnet level.<br>
><br>
><br>
> 1. <a href="https://review.openstack.org/#/c/200952/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/200952/</a><br>
> 2.<br>
> <a href="http://docs.openstack.org/developer/neutron/policies/blueprints.html#rfe-submission-guidelines" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/neutron/policies/blueprints.html#rfe-submission-guidelines</a><br>
><br>
> On Thu, Sep 3, 2015 at 1:07 PM, Maish Saidel-Keesing <<a href="mailto:maishsk@maishsk.com">maishsk@maishsk.com</a>><br>
> wrote:<br>
><br>
>> On 09/03/15 20:51, Gal Sagie wrote:<br>
>><br>
>> I am not sure if this address what you need specifically, but it would be<br>
>> worth checking these<br>
>> two approved liberty specs:<br>
>><br>
>> 1)<br>
>> <a href="https://github.com/openstack/neutron-specs/blob/master/specs/liberty/internal-dns-resolution.rst" rel="noreferrer" target="_blank">https://github.com/openstack/neutron-specs/blob/master/specs/liberty/internal-dns-resolution.rst</a><br>
>> 2)<br>
>> <a href="https://github.com/openstack/neutron-specs/blob/master/specs/liberty/external-dns-resolution.rst" rel="noreferrer" target="_blank">https://github.com/openstack/neutron-specs/blob/master/specs/liberty/external-dns-resolution.rst</a><br>
>><br>
>> Thanks Gal,<br>
>><br>
>> So I see that from the bp [1] the fqdn will be configurable for each and<br>
>> every port ?<br>
>><br>
>> I think that this does open up a number of interesting possibilities, but<br>
>> I would also think that it would be sufficient to do this on a subnet level?<br>
>><br>
>> We do already have the option of setting nameservers per subnet - I<br>
>> assume the data model is already implemented - which is interesting -<br>
>> because I don't see that as part of the information that is sent by dnsmasq<br>
>> so it must be coming from neutron somewhere.<br>
>><br>
>> The domain suffix - definitely is handled by dnsmasq.<br>
>><br>
>><br>
>><br>
>> On Thu, Sep 3, 2015 at 8:37 PM, Steve Wormley <<a href="mailto:openstack@wormley.com">openstack@wormley.com</a>><br>
>> wrote:<br>
>><br>
>>> As far as I am aware it is not presently built-in to Openstack. You'll<br>
>>> need to add a dnsmasq_config_file option to your dhcp agent configurations<br>
>>> and then populate the file with:<br>
>>> domain=DOMAIN_NAME,CIDR for each network<br>
>>> i.e.<br>
>>> domain=<a href="http://example.com" rel="noreferrer" target="_blank">example.com</a>,<a href="http://10.11.22.0/24" rel="noreferrer" target="_blank">10.11.22.0/24</a><br>
>>> ...<br>
>>><br>
>>> -Steve<br>
>>><br>
>>><br>
>>> On Thu, Sep 3, 2015 at 1:04 AM, Maish Saidel-Keesing <<br>
>>> <<a href="mailto:maishsk@maishsk.com">maishsk@maishsk.com</a>><a href="mailto:maishsk@maishsk.com">maishsk@maishsk.com</a>> wrote:<br>
>>><br>
>>>> Hello all (cross-posting to openstack-operators as well)<br>
>>>><br>
>>>> Today the setting of the dns suffix that is provided to the instance is<br>
>>>> passed through dhcp_agent.<br>
>>>><br>
>>>> There is the option of setting different DNS servers per subnet (and<br>
>>>> and therefore tenant) but the domain suffix is something that stays the<br>
>>>> same throughout the whole system is the domain suffix.<br>
>>>><br>
>>>> I see that this is not a current neutron feature.<br>
>>>><br>
>>>> Is this on the roadmap? Are there ways to achieve this today? If so I<br>
>>>> would be very interested in hearing how.<br>
>>>><br>
>>>> Thanks<br>
>>>> --<br>
>>>> Best Regards,<br>
>>>> Maish Saidel-Keesing<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://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:<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://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>
>> Best Regards ,<br>
>><br>
>> The G.<br>
>><br>
>><br>
>> --<br>
>> Best Regards,<br>
>> Maish Saidel-Keesing<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-operators mailing list<br>
>> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
>><br>
>><br>
><br>
><br>
> --<br>
> Kevin Benton<br>
><br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/21eab95b/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/21eab95b/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 17<br>
Date: Fri, 4 Sep 2015 16:25:09 +1000<br>
From: Lana Brindley <<a href="mailto:openstack@lanabrindley.com">openstack@lanabrindley.com</a>><br>
To: "<a href="mailto:openstack-docs@lists.openstack.org">openstack-docs@lists.openstack.org</a>"<br>
<<a href="mailto:openstack-docs@lists.openstack.org">openstack-docs@lists.openstack.org</a>>, OpenStack Development Mailing<br>
List <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>,<br>
"<a href="mailto:openstack-i18n@lists.openstack.org">openstack-i18n@lists.openstack.org</a>"<br>
<<a href="mailto:openstack-i18n@lists.openstack.org">openstack-i18n@lists.openstack.org</a>><br>
Subject: [openstack-dev] What's Up, Doc? 4 September, 2015<br>
Message-ID: <<a href="mailto:55E93945.4040107@lanabrindley.com">55E93945.4040107@lanabrindley.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Hi everyone,<br>
<br>
This has been a fairly busy week, with Summit preparations beginning,<br>
more newly migrated RST books going live, and testing starting on the<br>
Install Guide. I've been spending time on sorting out the Liberty<br>
blueprints still outstanding, and also working on some old bugs.<br>
<br>
== Progress towards Liberty ==<br>
<br>
40 days to go!<br>
<br>
* RST conversion:<br>
** Is now completed! Well done and a huge thank you to everyone who<br>
converted pages, approved reviews, and participated in publishing the<br>
new guides. This was a truly phenomenal effort :)<br>
<br>
* User Guides information architecture overhaul<br>
** Some user analysis has begun, and we have a new blueprint:<br>
<a href="https://blueprints.launchpad.net/openstack-manuals/+spec/user-guides-reo" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/openstack-manuals/+spec/user-guides-reo</a><br>
rganised<br>
<br>
* Greater focus on helping out devs with docs in their repo<br>
** A certain amount of progress has been made here, and some wrinkles<br>
sorted out which will improve this process for the future.<br>
<br>
* Improve how we communicate with and support our corporate contributors<br>
** If you currently work on documentation for a company that would like<br>
to improve their upstream commits for documentation, please contact me!<br>
<br>
* Improve communication with Docs Liaisons<br>
** I'm very pleased to see liaisons getting more involved in our bugs<br>
and reviews. Keep up the good work!<br>
<br>
* Clearing out old bugs<br>
** The last lot of old bugs are still languishing. I'm assuming you all<br>
hate them so very much that I've decided to give you three more to pick<br>
from. Have at it!<br>
<br>
== Countdown to Summit ==<br>
<br>
With the Liberty release less than two months away, that means it's<br>
nearly Summit time again: <a href="https://www.openstack.org/summit/tokyo-2015/" rel="noreferrer" target="_blank">https://www.openstack.org/summit/tokyo-2015/</a><br>
<br>
The schedule has now been released, congratulations to everyone who had<br>
a talk accepted this time around:<br>
<a href="https://www.openstack.org/summit/tokyo-2015/schedule/" rel="noreferrer" target="_blank">https://www.openstack.org/summit/tokyo-2015/schedule/</a><br>
<br>
All ATCs should have received their pass by now, so now is the time to<br>
be booking your travel and accommodation:<br>
<a href="https://www.openstack.org/summit/tokyo-2015/tokyo-and-travel/" rel="noreferrer" target="_blank">https://www.openstack.org/summit/tokyo-2015/tokyo-and-travel/</a><br>
<br>
== Conventions ==<br>
<br>
A new governance patch has landed which changes the way we capitalise<br>
service names (I know almost exactly 50% of you will be happy about<br>
this!):<br>
<a href="https://wiki.openstack.org/wiki/Documentation/Conventions#Service_and_pr" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Documentation/Conventions#Service_and_pr</a><br>
oject_names<br>
Please be aware of this when editing files, and remember that the<br>
'source of truth' for these things is the projects.yaml file:<br>
<a href="http://git.openstack.org/cgit/openstack/governance/tree/reference/projec" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/governance/tree/reference/projec</a><br>
ts.yaml<br>
<br>
== Docs Tools ==<br>
<br>
openstack-doc-tools 0.30.0 and openstackdocstheme 1.2.1 have been<br>
released. openstack-doc-tools allows translation of the Install Guide.<br>
openstackdocstheme contains fixes for the inclusion of metatags, removes<br>
unused images and javascript files, and fixes the "Docs Home" link.<br>
<br>
== Doc team meeting ==<br>
<br>
The APAC meeting was not held this week. The minutes from the previous<br>
US meeting are here:<br>
<a href="https://wiki.openstack.org/wiki/Documentation/MeetingLogs#2015-08-26" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Documentation/MeetingLogs#2015-08-26</a><br>
<br>
The next meetings are:<br>
US: Wednesday 9 September, 14:00:00 UTC<br>
APAC: Wednesday 16 September, 00:30:00 UTC<br>
<br>
Please go ahead and add any agenda items to the meeting page here:<br>
<a href="https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_</a><br>
meeting<br>
<br>
== Spotlight bugs for this week ==<br>
<br>
Let's give these three a little love:<br>
<br>
<a href="https://bugs.launchpad.net/openstack-manuals/+bug/1280092" rel="noreferrer" target="_blank">https://bugs.launchpad.net/openstack-manuals/+bug/1280092</a> end user guide<br>
lacks doc on admin password injection<br>
<br>
<a href="https://bugs.launchpad.net/openstack-manuals/+bug/1282765" rel="noreferrer" target="_blank">https://bugs.launchpad.net/openstack-manuals/+bug/1282765</a> Chapter 6.<br>
Block Storage in OpenStack Cloud Administrator Guide<br>
<br>
<a href="https://bugs.launchpad.net/openstack-manuals/+bug/1284215" rel="noreferrer" target="_blank">https://bugs.launchpad.net/openstack-manuals/+bug/1284215</a> Driver for IBM<br>
SONAS and Storwize V7000 Unified<br>
<br>
- --<br>
<br>
Remember, if you have content you would like to add to this newsletter,<br>
or you would like to be added to the distribution list, please email me<br>
directly at <a href="mailto:openstack@lanabrindley.com">openstack@lanabrindley.com</a>, or visit:<br>
<a href="https://wiki.openstack.org/w/index.php?title=Documentation/WhatsUpDoc" rel="noreferrer" target="_blank">https://wiki.openstack.org/w/index.php?title=Documentation/WhatsUpDoc</a><br>
<br>
Keep on doc'ing!<br>
<br>
Lana<br>
<br>
- --<br>
Lana Brindley<br>
Technical Writer<br>
Rackspace Cloud Builders Australia<br>
<a href="http://lanabrindley.com" rel="noreferrer" target="_blank">http://lanabrindley.com</a><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.22 (GNU/Linux)<br>
<br>
iQEcBAEBAgAGBQJV6TlFAAoJELppzVb4+KUy/zkIAKYKbKdw78Nv8dpB8d9Rj4qh<br>
+JTK2rTlz/Up5F10OzIoJoNMIvySeKH+jHV1CP0qL9KigYaepkEeMn8RnNSayYww<br>
cgSmk/8gpzGTTd17JK0Rrn+RjOb3XMYeNH2d4OkvIQPGBAYsnerODrvEK3GG7YHO<br>
oo5xYSkLdYH54qnXhhvNZxjxDclT1P5QgpUP6M6KcB3bcKt4niHGLHnBHFoqvlMR<br>
gJA1BtKR6CackhZbkJpPFCpEHimm4xdWwF+q7xRezy599MbkkPAIxR/oMuEkqU2H<br>
zj+tm9sHDxOoH2j4Hfkbw7xxF+/NjvGtm41JCPsUVBxuAocaBbJ1kZRbbRzrafI=<br>
=2TAI<br>
-----END PGP SIGNATURE-----<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 18<br>
Date: Fri, 4 Sep 2015 10:11:45 +0400<br>
From: Evgeny Antyshev <<a href="mailto:eantyshev@virtuozzo.com">eantyshev@virtuozzo.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] [infra][third-party][CI] Third-party oses<br>
in devstack-gate<br>
Message-ID: <<a href="mailto:55E93621.5050909@virtuozzo.com">55E93621.5050909@virtuozzo.com</a>><br>
Content-Type: text/plain; charset="windows-1252"; format=flowed<br>
<br>
On 01.09.2015 12:28, Evgeny Antyshev wrote:<br>
> Hello!<br>
><br>
> This letter I address to those third-party CI maintainers who needs to<br>
> amend<br>
> the upstream devstack-gate to satisfy their environment.<br>
><br>
> Some folks that I know use inline patching at job level,<br>
> some make private forks of devstack-gate (I even saw one on github).<br>
> There have been a few improvements to devstack-gate, which made it<br>
> easier to use it<br>
> downstream, f.e. introducing DEVSTACK_LOCAL_CONFIG<br>
> (<a href="https://review.openstack.org/145321" rel="noreferrer" target="_blank">https://review.openstack.org/145321</a>)<br>
><br>
> We particularly need it to recognize our rhel-based distribution as a<br>
> Fedora OS.<br>
> We cannot define it explicitly in is_fedora() as it is not officially<br>
> supported upstream,<br>
> but we can introduce the variable DEVSTACK_GATE_IS_FEDORA which makes<br>
> is_fedora() agnostic to distributions and to succeed if run on an<br>
> undefined OS.<br>
><br>
> Here is the change: <a href="https://review.openstack.org/215029" rel="noreferrer" target="_blank">https://review.openstack.org/215029</a><br>
> I welcome everyone interested in the matter<br>
> to tell us if we do it right or not, and to review the change.<br>
><br>
Prepending with [infra] tag to draw more attention<br>
<br>
--<br>
Best regards,<br>
Evgeny Antyshev.<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 19<br>
Date: Fri, 4 Sep 2015 09:26:23 +0200<br>
From: Ihar Hrachyshka <<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a>><br>
To: Daniel Comnea <<a href="mailto:comnea.dani@gmail.com">comnea.dani@gmail.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>
"<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>"<br>
<<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Openstack-operators] [Neutron] Allowing<br>
DNS suffix to be set per subnet (at least per tenant)<br>
Message-ID: <<a href="mailto:32F63AEB-460C-46FB-8F30-517C2AEA1563@redhat.com">32F63AEB-460C-46FB-8F30-517C2AEA1563@redhat.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
> On 04 Sep 2015, at 08:14, Daniel Comnea <<a href="mailto:comnea.dani@gmail.com">comnea.dani@gmail.com</a>> wrote:<br>
><br>
> Kevin,<br>
><br>
> am i right in saying that the merge above was packaged into Liberty ?<br>
><br>
> Any chance to be ported to Juno?<br>
><br>
<br>
There is no chance a new feature will be backported to any stable branch, even Kilo. At least in upstream.<br>
<br>
Ihar<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 455 bytes<br>
Desc: Message signed with OpenPGP using GPGMail<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/5267415e/attachment-0001.pgp" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/5267415e/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 20<br>
Date: Fri, 04 Sep 2015 09:58:11 +0200<br>
From: Jose Manuel Ferrer Mosteiro<br>
<<a href="mailto:jmferrer.paradigmatecnologico@gmail.com">jmferrer.paradigmatecnologico@gmail.com</a>><br>
To: Sabrina Bajorat <<a href="mailto:sabrina.bajorat@gmail.com">sabrina.bajorat@gmail.com</a>><br>
Cc: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>, <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [Openstack] [ANN] OpenStack Kilo on<br>
Ubuntu fully automated with Ansible! Ready for NFV L2 Bridges via<br>
Heat!<br>
Message-ID: <<a href="mailto:b671b11c2e3440458f33159aa4f3f191@fermosit.es">b671b11c2e3440458f33159aa4f3f191@fermosit.es</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
<br>
<br>
Hi<br>
<br>
It is a pre pre pre pre pre pre pre alpha version that just installs the<br>
juno ubuntu guide until dashboard included. Block Storage Service is<br>
very important but does not work now.<br>
<br>
vCenter will be always the operating system that makes my life easyer.<br>
Today is Ubuntu.<br>
<br>
The hypervisor is also Ubuntu but it will be Ubuntu, CentOs and Debian.<br>
<br>
I will announce the project when the project is more advanced.<br>
<br>
Thanks<br>
<br>
On 2015-08-31 15:08, Sabrina Bajorat wrote:<br>
<br>
> That is great !!! Can it be use with Debian 7 too?<br>
><br>
> Thanks<br>
><br>
> On Mon, Aug 31, 2015 at 2:54 PM, Jose Manuel Ferrer Mosteiro <<a href="mailto:jmferrer.paradigmatecnologico@gmail.com">jmferrer.paradigmatecnologico@gmail.com</a>> wrote:<br>
><br>
> Nice job. I am doing a vmware vcenter like in <a href="https://github.com/elmanytas/ansible-openstack-vcenter" rel="noreferrer" target="_blank">https://github.com/elmanytas/ansible-openstack-vcenter</a> [1] and I solved the problem of duplicate endpoints in line 106 of <a href="https://github.com/elmanytas/ansible-openstack-vcenter/blob/master/etc_ansible/roles/keystone/tasks/main.yml" rel="noreferrer" target="_blank">https://github.com/elmanytas/ansible-openstack-vcenter/blob/master/etc_ansible/roles/keystone/tasks/main.yml</a> [2] . This makes playbooks idempotents.<br>
><br>
> Maybe you could be interested.<br>
><br>
> On 2015-08-26 00:30, Martinx - ????? wrote:<br>
> Hello Stackers!<br>
><br>
> I'm proud to announce an Ansible Playbook to deploy OpenStack on Ubuntu!<br>
><br>
> Check it out!<br>
><br>
> * <a href="https://github.com/sandvine/os-ansible-deployment-lite" rel="noreferrer" target="_blank">https://github.com/sandvine/os-ansible-deployment-lite</a> [3]<br>
><br>
> Powered by Sandvine! ;-)<br>
><br>
> Basically, this is the automation of what we have documented here:<br>
><br>
> * <a href="http://docs.openstack.org/kilo/install-guide/install/apt/content/" rel="noreferrer" target="_blank">http://docs.openstack.org/kilo/install-guide/install/apt/content/</a> [4]<br>
><br>
> Instructions:<br>
><br>
> 1- Install Ubuntu 14.04, fully upgraded (with<br>
> "linux-generic-lts-vivid" installed), plus "/etc/hostname" and<br>
> "/etc/hosts" configured according.<br>
><br>
> 2- Deploy OpenStack with 1 command:<br>
><br>
> * Open vSwtich (default):<br>
><br>
> bash <(curl -s<br>
> <a href="https://raw.githubusercontent.com/sandvine/os-ansible-deployment-lite/kilo/misc/os-install.sh" rel="noreferrer" target="_blank">https://raw.githubusercontent.com/sandvine/os-ansible-deployment-lite/kilo/misc/os-install.sh</a> [5])<br>
><br>
> * Linux Bridges (alternative):<br>
><br>
> bash <(curl -s<br>
> <a href="https://raw.githubusercontent.com/sandvine/os-ansible-deployment-lite/kilo/misc/os-install-lbr.sh" rel="noreferrer" target="_blank">https://raw.githubusercontent.com/sandvine/os-ansible-deployment-lite/kilo/misc/os-install-lbr.sh</a> [6])<br>
><br>
> 3- Launch a NFV L2 Stack:<br>
><br>
> heat stack-create demo -f<br>
> ~/os-ansible-deployment-lite/misc/os-heat-templates/nfv-l2-bridge-basic-stack-ubuntu-little.yaml<br>
><br>
> IMPORTANT NOTES:<br>
><br>
> Only runs the "step 2" on top of a fresh installed Ubuntu 14.04! Can<br>
> be a Server or Desktop but, fresh installed. Do not pre-install MySQL,<br>
> RabbitMQ, Keystone, etc... Let Ansible to its magic!<br>
><br>
> Also, make sure you can use "sudo" without password.<br>
><br>
> Some features of our Ansible Playbook:<br>
><br>
> 1- Deploys OpenStack with one single command, in one physical box<br>
> (all-in-one), helper script (./os-deploy.sh) available;<br>
><br>
> 2- Supports NFV instances that can act as a L2 Bridge between two<br>
> VXLAN Networks;<br>
><br>
> 3- Plenty of Heat Templates;<br>
><br>
> 4- 100% Ubuntu based;<br>
><br>
> 5- Very simple setup (simpler topology; dummy interfaces for both<br>
> "br-ex" and "vxlan"; no containers for each service (yet));<br>
><br>
> 6- Ubuntu PPA available, with a few OpenStack patches backported from<br>
> Liberty, to Kilo (to add "port_security_enabled" Heat support);<br>
><br>
> <a href="https://launchpad.net/~sandvine/+archive/ubuntu/cloud-archive-kilo/" rel="noreferrer" target="_blank">https://launchpad.net/~sandvine/+archive/ubuntu/cloud-archive-kilo/</a> [7]<br>
><br>
> 7- Only requires one physical ethernet card;<br>
><br>
> 8- Both "Linux Bridges" and "Open vSwitch" deployments are supported;<br>
><br>
> 9- Planning to add DPDK support;<br>
><br>
> 10- Multi-node support under development;<br>
><br>
> 11- IPv6 support comming...<br>
><br>
> * Notes about Vagrant support:<br>
><br>
> Under development (it doesn't work yet).<br>
><br>
> There is a preliminary Vagrant support (there is still a bug on MySQL<br>
> startup, pull requests are welcome).<br>
><br>
> Just "git clone" our Ansible playbooks and run "vagrant up" (or<br>
> ./os-deploy-vagrant.sh to auto-config your Ansible vars / files for<br>
> you).<br>
><br>
> We tried it only with Mac / VirtualBox but, it does not support<br>
> VT-in-VT (nested virtualization), so, we're looking for KVM / Libvirt<br>
> on Ubuntu Desktop instead. But it would be nice to, at least, launch<br>
> OpenStack in a VirtualBox on you Mac... =)<br>
><br>
> Hope you guys enjoy it!<br>
><br>
> Cheers!<br>
> Thiago<br>
><br>
> _______________________________________________<br>
> Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a> [8]<br>
> Post to : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
> Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a> [8]<br>
><br>
> _______________________________________________<br>
> Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a> [8]<br>
> Post to : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
> Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a> [8]<br>
<br>
<br>
Links:<br>
------<br>
[1] <a href="https://github.com/elmanytas/ansible-openstack-vcenter" rel="noreferrer" target="_blank">https://github.com/elmanytas/ansible-openstack-vcenter</a><br>
[2]<br>
<a href="https://github.com/elmanytas/ansible-openstack-vcenter/blob/master/etc_ansible/roles/keystone/tasks/main.yml" rel="noreferrer" target="_blank">https://github.com/elmanytas/ansible-openstack-vcenter/blob/master/etc_ansible/roles/keystone/tasks/main.yml</a><br>
[3] <a href="https://github.com/sandvine/os-ansible-deployment-lite" rel="noreferrer" target="_blank">https://github.com/sandvine/os-ansible-deployment-lite</a><br>
[4] <a href="http://docs.openstack.org/kilo/install-guide/install/apt/content/" rel="noreferrer" target="_blank">http://docs.openstack.org/kilo/install-guide/install/apt/content/</a><br>
[5]<br>
<a href="https://raw.githubusercontent.com/sandvine/os-ansible-deployment-lite/kilo/misc/os-install.sh" rel="noreferrer" target="_blank">https://raw.githubusercontent.com/sandvine/os-ansible-deployment-lite/kilo/misc/os-install.sh</a><br>
[6]<br>
<a href="https://raw.githubusercontent.com/sandvine/os-ansible-deployment-lite/kilo/misc/os-install-lbr.sh" rel="noreferrer" target="_blank">https://raw.githubusercontent.com/sandvine/os-ansible-deployment-lite/kilo/misc/os-install-lbr.sh</a><br>
[7] <a href="https://launchpad.net/~sandvine/+archive/ubuntu/cloud-archive-kilo/" rel="noreferrer" target="_blank">https://launchpad.net/~sandvine/+archive/ubuntu/cloud-archive-kilo/</a><br>
[8] <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/792ad425/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/792ad425/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 21<br>
Date: Fri, 4 Sep 2015 10:17:29 +0200<br>
From: Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] FFE Request for completion of data driven<br>
assignment testing in Keystone<br>
Message-ID: <<a href="mailto:55E95399.1070903@openstack.org">55E95399.1070903@openstack.org</a>><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
Morgan Fainberg wrote:<br>
><br>
>> I would like to request an FFE for the remaining two patches that<br>
>> are already in review<br>
>> (<a href="https://review.openstack.org/#/c/153897/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/153897/</a> and <a href="https://review.openstack.org/#/c/154485/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/154485/</a>).<br>
>> These contain only test code and no functional changes, and<br>
>> increase our test coverage - as well as enable other items to be<br>
>> re-use the list_role_assignment backend method.<br>
>><br>
>> Do we need a FFE for changes to tests?<br>
>><br>
><br>
> I would say "no".<br>
<br>
Right. Extra tests (or extra docs for that matter) don't count as a<br>
"feature" for the freeze. In particular it doesn't change the behavior<br>
of the software or invalidate testing that may have been conducted.<br>
<br>
--<br>
Thierry Carrez (ttx)<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 22<br>
Date: Fri, 4 Sep 2015 10:42:57 +0200<br>
From: Daniel Mellado <<a href="mailto:daniel.mellado.es@ieee.org">daniel.mellado.es@ieee.org</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [infra][third-party][CI] Third-party oses<br>
in devstack-gate<br>
Message-ID: <<a href="mailto:55E95991.4050105@ieee.org">55E95991.4050105@ieee.org</a>><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
El 04/09/15 a las 08:11, Evgeny Antyshev escribi?:<br>
> On 01.09.2015 12:28, Evgeny Antyshev wrote:<br>
>> Hello!<br>
>><br>
>> This letter I address to those third-party CI maintainers who needs<br>
>> to amend<br>
>> the upstream devstack-gate to satisfy their environment.<br>
>><br>
>> Some folks that I know use inline patching at job level,<br>
>> some make private forks of devstack-gate (I even saw one on github).<br>
>> There have been a few improvements to devstack-gate, which made it<br>
>> easier to use it<br>
>> downstream, f.e. introducing DEVSTACK_LOCAL_CONFIG<br>
>> (<a href="https://review.openstack.org/145321" rel="noreferrer" target="_blank">https://review.openstack.org/145321</a>)<br>
>><br>
>> We particularly need it to recognize our rhel-based distribution as a<br>
>> Fedora OS.<br>
>> We cannot define it explicitly in is_fedora() as it is not officially<br>
>> supported upstream,<br>
>> but we can introduce the variable DEVSTACK_GATE_IS_FEDORA which makes<br>
>> is_fedora() agnostic to distributions and to succeed if run on an<br>
>> undefined OS.<br>
>><br>
>> Here is the change: <a href="https://review.openstack.org/215029" rel="noreferrer" target="_blank">https://review.openstack.org/215029</a><br>
>> I welcome everyone interested in the matter<br>
>> to tell us if we do it right or not, and to review the change.<br>
>><br>
> Prepending with [infra] tag to draw more attention<br>
><br>
Personally I think that would be great, as it would greatly help finding<br>
Fedora-ish issues with devstack, which are now only being raised by<br>
developers due to the lack of a gate.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 23<br>
Date: Fri, 4 Sep 2015 12:36:56 +0300<br>
From: Dmitro Dovbii <<a href="mailto:ddovbii@mirantis.com">ddovbii@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: [openstack-dev] [murano] [dashboard] Remove the owner filter<br>
from "Package Definitions" page<br>
Message-ID:<br>
<<a href="mailto:CAKSp79y8cCU7z0S-Pzgy2k1TNJZZMsyVYXk-bEtSj6ByoB4JZQ@mail.gmail.com">CAKSp79y8cCU7z0S-Pzgy2k1TNJZZMsyVYXk-bEtSj6ByoB4JZQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi folks!<br>
<br>
I want suggest you to delete owner filter (3 tabs) from Package Definition<br>
page. Previously this filter was available for all users and we agreed that<br>
it is useless. Now it is available only for admin but I think this fact<br>
still doesn't improve the UX. Moreover, this filter prevents the<br>
implementation of the search by name, because the work of the two filters<br>
can be inconsistent.<br>
So, please express your opinion on this issue. If you agree, I will remove<br>
this filter ASAP.<br>
<br>
Best regards,<br>
Dmytro Dovbii<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/c9546f3a/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/c9546f3a/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 24<br>
Date: Fri, 4 Sep 2015 12:40:55 +0300<br>
From: Sergey Reshetnyak <<a href="mailto:sreshetniak@mirantis.com">sreshetniak@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] [sahara] Request for Feature Freeze<br>
Exception<br>
Message-ID:<br>
<<a href="mailto:CAOB5mPxaTM5QKm410c2956QMfnsaz9QqT7XreMyxPmdrK1E0Og@mail.gmail.com">CAOB5mPxaTM5QKm410c2956QMfnsaz9QqT7XreMyxPmdrK1E0Og@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
+1 from me.<br>
<br>
Thanks,<br>
Sergey R.<br>
<br>
2015-09-03 23:27 GMT+03:00 Ethan Gafford <<a href="mailto:egafford@redhat.com">egafford@redhat.com</a>>:<br>
<br>
> Agreed. We've talked about this for a while, and it's very low risk.<br>
><br>
> Thanks,<br>
> Ethan<br>
><br>
> ----- Original Message -----<br>
> From: "michael mccune" <<a href="mailto:msm@redhat.com">msm@redhat.com</a>><br>
> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
> Sent: Thursday, September 3, 2015 3:53:41 PM<br>
> Subject: Re: [openstack-dev] [sahara] Request for Feature Freeze Exception<br>
><br>
> On 09/03/2015 02:49 PM, Vitaly Gridnev wrote:<br>
> > Hey folks!<br>
> ><br>
> > I would like to propose to add to list of FFE's following blueprint:<br>
> > <a href="https://blueprints.launchpad.net/sahara/+spec/drop-hadoop-1" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/sahara/+spec/drop-hadoop-1</a><br>
> ><br>
> > Reasoning of that is following:<br>
> ><br>
> > 1. HDP 1.3.2 and Vanilla 1.2.1 are not gated for a whole release<br>
> > cycle, so it can be reason of several bugs in these versions;<br>
> > 2. Minimal risk of removal: it doesn't touch versions that we already<br>
> > have.<br>
> > 3. All required changes was already uploaded to the review:<br>
> ><br>
> <a href="https://review.openstack.org/#/q/status:open+project:openstack/sahara+branch:master+topic:bp/drop-hadoop-1,n,z" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/status:open+project:openstack/sahara+branch:master+topic:bp/drop-hadoop-1,n,z</a><br>
><br>
> this sounds reasonable to me<br>
><br>
> mike<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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/5c660e15/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/5c660e15/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 25<br>
Date: Fri, 4 Sep 2015 12:54:18 +0300<br>
From: Sergey Reshetnyak <<a href="mailto:sreshetniak@mirantis.com">sreshetniak@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: [openstack-dev] [sahara] FFE request for heat wait condition<br>
support<br>
Message-ID:<br>
<<a href="mailto:CAOB5mPwf6avCZD4Q6U4xh-g4f553eMzCTh1kfiX4bVY8x59i5A@mail.gmail.com">CAOB5mPwf6avCZD4Q6U4xh-g4f553eMzCTh1kfiX4bVY8x59i5A@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
I would like to request FFE for wait condition support for Heat engine.<br>
Wait condition reports signal about booting instance.<br>
<br>
Blueprint:<br>
<a href="https://blueprints.launchpad.net/sahara/+spec/sahara-heat-wait-conditions" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/sahara/+spec/sahara-heat-wait-conditions</a><br>
<br>
Spec:<br>
<a href="https://github.com/openstack/sahara-specs/blob/master/specs/liberty/sahara-heat-wait-conditions.rst" rel="noreferrer" target="_blank">https://github.com/openstack/sahara-specs/blob/master/specs/liberty/sahara-heat-wait-conditions.rst</a><br>
<br>
Patch:<br>
<a href="https://review.openstack.org/#/c/169338/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/169338/</a><br>
<br>
Thanks,<br>
Sergey Reshetnyak<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/6e8d42e5/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/6e8d42e5/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 26<br>
Date: Fri, 4 Sep 2015 18:54:49 +0900<br>
From: "Ken'ichi Ohmichi" <<a href="mailto:ken1ohmichi@gmail.com">ken1ohmichi@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] Scheduler hints, API and Objects<br>
Message-ID:<br>
<CAA393vhyeMYeA=6MK9+0LtReud67+OMBu=<a href="mailto:KcaOzvM_pzL4Ea%2Bg@mail.gmail.com">KcaOzvM_pzL4Ea+g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
2015-09-04 12:14 GMT+09:00 Ken'ichi Ohmichi <<a href="mailto:ken1ohmichi@gmail.com">ken1ohmichi@gmail.com</a>>:<br>
> Hi Andrew,<br>
><br>
> Sorry for this late response, I missed it.<br>
><br>
> 2015-06-25 23:22 GMT+09:00 Andrew Laski <<a href="mailto:andrew@lascii.com">andrew@lascii.com</a>>:<br>
>> I have been growing concerned recently with some attempts to formalize<br>
>> scheduler hints, both with API validation and Nova objects defining them,<br>
>> and want to air those concerns and see if others agree or can help me see<br>
>> why I shouldn't worry.<br>
>><br>
>> Starting with the API I think the strict input validation that's being done,<br>
>> as seen in<br>
>> <a href="http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da</a>,<br>
>> is unnecessary, and potentially problematic.<br>
>><br>
>> One problem is that it doesn't indicate anything useful for a client. The<br>
>> schema indicates that there are hints available but can make no claim about<br>
>> whether or not they're actually enabled. So while a microversion bump would<br>
>> typically indicate a new feature available to an end user, in the case of a<br>
>> new scheduler hint a microversion bump really indicates nothing at all. It<br>
>> does ensure that if a scheduler hint is used that it's spelled properly and<br>
>> the data type passed is correct, but that's primarily useful because there<br>
>> is no feedback mechanism to indicate an invalid or unused scheduler hint. I<br>
>> think the API schema is a poor proxy for that deficiency.<br>
>><br>
>> Since the exposure of a hint means nothing as far as its usefulness, I don't<br>
>> think we should be codifying them as part of our API schema at this time.<br>
>> At some point I imagine we'll evolve a more useful API for passing<br>
>> information to the scheduler as part of a request, and when that happens I<br>
>> don't think needing to support a myriad of meaningless hints in older API<br>
>> versions is going to be desirable.<br>
>><br>
>> Finally, at this time I'm not sure we should take the stance that only<br>
>> in-tree scheduler hints are supported. While I completely agree with the<br>
>> desire to expose things in cross-cloud ways as we've done and are looking to<br>
>> do with flavor and image properties I think scheduling is an area where we<br>
>> want to allow some flexibility for deployers to write and expose scheduling<br>
>> capabilities that meet their specific needs. Over time I hope we will get<br>
>> to a place where some standardization can happen, but I don't think locking<br>
>> in the current scheduling hints is the way forward for that. I would love<br>
>> to hear from multi-cloud users here and get some input on whether that's<br>
>> crazy and they are expecting benefits from validation on the current<br>
>> scheduler hints.<br>
>><br>
>> Now, objects. As part of the work to formalize the request spec sent to the<br>
>> scheduler there's an effort to make a scheduler hints object. This<br>
>> formalizes them in the same way as the API with no benefit that I can see.<br>
>> I won't duplicate my arguments above, but I feel the same way about the<br>
>> objects as I do with the API. I don't think needing to update and object<br>
>> version every time a new hint is added is useful at this time, nor do I<br>
>> think we should lock in the current in-tree hints.<br>
>><br>
>> In the end this boils down to my concern that the scheduling hints api is a<br>
>> really horrible user experience and I don't want it to be solidified in the<br>
>> API or objects yet. I think we should re-examine how they're handled before<br>
>> that happens.<br>
><br>
> Now we are discussing this on <a href="https://review.openstack.org/#/c/217727/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/217727/</a><br>
> for allowing out-of-tree scheduler-hints.<br>
> When we wrote API schema for scheduler-hints, it was difficult to know<br>
> what are available API parameters for scheduler-hints.<br>
> Current API schema exposes them and I guess that is useful for API users also.<br>
><br>
> One idea is that: How about auto-extending scheduler-hint API schema<br>
> based on loaded schedulers?<br>
> Now API schemas of "create/update/resize/rebuild a server" APIs are<br>
> auto-extended based on loaded extensions by using stevedore<br>
> library[1].<br>
> I guess we can apply the same way for scheduler-hints also in long-term.<br>
> Each scheduler needs to implement a method which returns available API<br>
> parameter formats and nova-api tries to get them then extends<br>
> scheduler-hints API schema with them.<br>
> That means out-of-tree schedulers also will be available if they<br>
> implement the method.<br>
> # In short-term, I can see "blocking additionalProperties" validation<br>
> disabled by the way.<br>
<br>
<a href="https://review.openstack.org/#/c/220440" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/220440</a> is a prototype for the above idea.<br>
<br>
Thanks<br>
Ken Ohmichi<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 27<br>
Date: Fri, 4 Sep 2015 18:03:57 +0800<br>
From: Alex Xu <<a href="mailto:soulxu@gmail.com">soulxu@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] Scheduler hints, API and Objects<br>
Message-ID:<br>
<CAH7mGauOgfvVkfW2OYPm7D=<a href="mailto:7zgXhRHpx4a7_jZMyBtND3iirGQ@mail.gmail.com">7zgXhRHpx4a7_jZMyBtND3iirGQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
2015-09-04 11:14 GMT+08:00 Ken'ichi Ohmichi <<a href="mailto:ken1ohmichi@gmail.com">ken1ohmichi@gmail.com</a>>:<br>
<br>
> Hi Andrew,<br>
><br>
> Sorry for this late response, I missed it.<br>
><br>
> 2015-06-25 23:22 GMT+09:00 Andrew Laski <<a href="mailto:andrew@lascii.com">andrew@lascii.com</a>>:<br>
> > I have been growing concerned recently with some attempts to formalize<br>
> > scheduler hints, both with API validation and Nova objects defining them,<br>
> > and want to air those concerns and see if others agree or can help me see<br>
> > why I shouldn't worry.<br>
> ><br>
> > Starting with the API I think the strict input validation that's being<br>
> done,<br>
> > as seen in<br>
> ><br>
> <a href="http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da</a><br>
> ,<br>
> > is unnecessary, and potentially problematic.<br>
> ><br>
> > One problem is that it doesn't indicate anything useful for a client.<br>
> The<br>
> > schema indicates that there are hints available but can make no claim<br>
> about<br>
> > whether or not they're actually enabled. So while a microversion bump<br>
> would<br>
> > typically indicate a new feature available to an end user, in the case<br>
> of a<br>
> > new scheduler hint a microversion bump really indicates nothing at all.<br>
> It<br>
> > does ensure that if a scheduler hint is used that it's spelled properly<br>
> and<br>
> > the data type passed is correct, but that's primarily useful because<br>
> there<br>
> > is no feedback mechanism to indicate an invalid or unused scheduler<br>
> hint. I<br>
> > think the API schema is a poor proxy for that deficiency.<br>
> ><br>
> > Since the exposure of a hint means nothing as far as its usefulness, I<br>
> don't<br>
> > think we should be codifying them as part of our API schema at this time.<br>
> > At some point I imagine we'll evolve a more useful API for passing<br>
> > information to the scheduler as part of a request, and when that happens<br>
> I<br>
> > don't think needing to support a myriad of meaningless hints in older API<br>
> > versions is going to be desirable.<br>
> ><br>
> > Finally, at this time I'm not sure we should take the stance that only<br>
> > in-tree scheduler hints are supported. While I completely agree with the<br>
> > desire to expose things in cross-cloud ways as we've done and are<br>
> looking to<br>
> > do with flavor and image properties I think scheduling is an area where<br>
> we<br>
> > want to allow some flexibility for deployers to write and expose<br>
> scheduling<br>
> > capabilities that meet their specific needs. Over time I hope we will<br>
> get<br>
> > to a place where some standardization can happen, but I don't think<br>
> locking<br>
> > in the current scheduling hints is the way forward for that. I would<br>
> love<br>
> > to hear from multi-cloud users here and get some input on whether that's<br>
> > crazy and they are expecting benefits from validation on the current<br>
> > scheduler hints.<br>
> ><br>
> > Now, objects. As part of the work to formalize the request spec sent to<br>
> the<br>
> > scheduler there's an effort to make a scheduler hints object. This<br>
> > formalizes them in the same way as the API with no benefit that I can<br>
> see.<br>
> > I won't duplicate my arguments above, but I feel the same way about the<br>
> > objects as I do with the API. I don't think needing to update and object<br>
> > version every time a new hint is added is useful at this time, nor do I<br>
> > think we should lock in the current in-tree hints.<br>
> ><br>
> > In the end this boils down to my concern that the scheduling hints api<br>
> is a<br>
> > really horrible user experience and I don't want it to be solidified in<br>
> the<br>
> > API or objects yet. I think we should re-examine how they're handled<br>
> before<br>
> > that happens.<br>
><br>
> Now we are discussing this on <a href="https://review.openstack.org/#/c/217727/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/217727/</a><br>
> for allowing out-of-tree scheduler-hints.<br>
> When we wrote API schema for scheduler-hints, it was difficult to know<br>
> what are available API parameters for scheduler-hints.<br>
> Current API schema exposes them and I guess that is useful for API users<br>
> also.<br>
><br>
> One idea is that: How about auto-extending scheduler-hint API schema<br>
> based on loaded schedulers?<br>
> Now API schemas of "create/update/resize/rebuild a server" APIs are<br>
> auto-extended based on loaded extensions by using stevedore<br>
> library[1].<br>
><br>
<br>
Em....we will deprecate the extension from our API. this sounds like add<br>
more extension mechanism.<br>
<br>
<br>
> I guess we can apply the same way for scheduler-hints also in long-term.<br>
> Each scheduler needs to implement a method which returns available API<br>
> parameter formats and nova-api tries to get them then extends<br>
> scheduler-hints API schema with them.<br>
> That means out-of-tree schedulers also will be available if they<br>
> implement the method.<br>
> # In short-term, I can see "blocking additionalProperties" validation<br>
> disabled by the way.<br>
><br>
> Thanks<br>
> Ken Ohmichi<br>
><br>
> ---<br>
> [1]:<br>
> <a href="https://github.com/openstack/nova/blob/master/doc/source/api_plugins.rst#json-schema" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/master/doc/source/api_plugins.rst#json-schema</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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/d10cb2fb/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/d10cb2fb/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 28<br>
Date: Fri, 4 Sep 2015 13:06:57 +0300<br>
From: Alexander Tivelkov <<a href="mailto:ativelkov@mirantis.com">ativelkov@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] [murano] [dashboard] Remove the owner<br>
filter from "Package Definitions" page<br>
Message-ID:<br>
<CAM6FM9S47YmJsTYGVNoPc7L2JGjBpCB+-s-HTd=<a href="mailto:d%2BHK939GEEg@mail.gmail.com">d+HK939GEEg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
?+1 on this.<br>
<br>
Filtering by ownership makes sense only on Catalog view (i.e. on the page<br>
of usable apps) ?but not on the admin-like console like the list of package<br>
definitions.<br>
<br>
--<br>
Regards,<br>
Alexander Tivelkov<br>
<br>
On Fri, Sep 4, 2015 at 12:36 PM, Dmitro Dovbii <<a href="mailto:ddovbii@mirantis.com">ddovbii@mirantis.com</a>> wrote:<br>
<br>
> Hi folks!<br>
><br>
> I want suggest you to delete owner filter (3 tabs) from Package Definition<br>
> page. Previously this filter was available for all users and we agreed that<br>
> it is useless. Now it is available only for admin but I think this fact<br>
> still doesn't improve the UX. Moreover, this filter prevents the<br>
> implementation of the search by name, because the work of the two filters<br>
> can be inconsistent.<br>
> So, please express your opinion on this issue. If you agree, I will remove<br>
> this filter ASAP.<br>
><br>
> Best regards,<br>
> Dmytro Dovbii<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/20150904/904f4318/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/904f4318/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 29<br>
Date: Fri, 4 Sep 2015 12:14:06 +0200<br>
From: Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [all] Mitaka Design Summit - Proposed slot<br>
allocation<br>
Message-ID: <<a href="mailto:55E96EEE.4070306@openstack.org">55E96EEE.4070306@openstack.org</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Hi PTLs,<br>
<br>
Here is the proposed slot allocation for every "big tent" project team<br>
at the Mitaka Design Summit in Tokyo. This is based on the requests the<br>
liberty PTLs have made, space availability and project activity &<br>
collaboration needs.<br>
<br>
We have a lot less space (and time slots) in Tokyo compared to<br>
Vancouver, so we were unable to give every team what they wanted. In<br>
particular, there were far more workroom requests than we have<br>
available, so we had to cut down on those quite heavily. Please note<br>
that we'll have a large lunch room with roundtables inside the Design<br>
Summit space that can easily be abused (outside of lunch) as space for<br>
extra discussions.<br>
<br>
Here is the allocation:<br>
<br>
| fb: fishbowl 40-min slots<br>
| wr: workroom 40-min slots<br>
| cm: Friday contributors meetup<br>
| | day: full day, morn: only morning, aft: only afternoon<br>
<br>
Neutron: 12fb, cm:day<br>
Nova: 14fb, cm:day<br>
Cinder: 5fb, 4wr, cm:day<br>
Horizon: 2fb, 7wr, cm:day<br>
Heat: 4fb, 8wr, cm:morn<br>
Keystone: 7fb, 3wr, cm:day<br>
Ironic: 4fb, 4wr, cm:morn<br>
Oslo: 3fb, 5wr<br>
Rally: 1fb, 2wr<br>
Kolla: 3fb, 5wr, cm:aft<br>
Ceilometer: 2fb, 7wr, cm:morn<br>
TripleO: 2fb, 1wr, cm:full<br>
Sahara: 2fb, 5wr, cm:aft<br>
Murano: 2wr, cm:full<br>
Glance: 3fb, 5wr, cm:full<br>
Manila: 2fb, 4wr, cm:morn<br>
Magnum: 5fb, 5wr, cm:full<br>
Swift: 2fb, 12wr, cm:full<br>
Trove: 2fb, 4wr, cm:aft<br>
Barbican: 2fb, 6wr, cm:aft<br>
Designate: 1fb, 4wr, cm:aft<br>
OpenStackClient: 1fb, 1wr, cm:morn<br>
Mistral: 1fb, 3wr<br>
Zaqar: 1fb, 3wr<br>
Congress: 3wr<br>
Cue: 1fb, 1wr<br>
Solum: 1fb<br>
Searchlight: 1fb, 1wr<br>
MagnetoDB: won't be present<br>
<br>
Infrastructure: 3fb, 4wr (shared meetup with Ironic and QA)<br>
PuppetOpenStack: 2fb, 3wr<br>
Documentation: 2fb, 4wr, cm:morn<br>
Quality Assurance: 4fb, 4wr, cm:full<br>
OpenStackAnsible: 2fb, 1wr, cm:aft<br>
Release management: 1fb, 1wr (shared meetup with QA)<br>
Security: 2fb, 2wr<br>
ChefOpenstack: will camp in the lunch room all week<br>
App catalog: 1fb, 1wr<br>
I18n: cm:morn<br>
OpenStack UX: 2wr<br>
Packaging-deb: 2wr<br>
Refstack: 2wr<br>
RpmPackaging: 1fb, 1wr<br>
<br>
We'll start working on laying out those sessions over the available<br>
rooms and time slots. If you have constraints (I already know<br>
searchlight wants to avoid conflicts with Horizon, Kolla with Magnum,<br>
Manila with Cinder, Solum with Magnum...) please let me know, we'll do<br>
our best to limit them.<br>
<br>
--<br>
Thierry Carrez (ttx)<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 30<br>
Date: Fri, 04 Sep 2015 10:18:43 +0000<br>
From: "Ken'ichi Ohmichi" <<a href="mailto:ken1ohmichi@gmail.com">ken1ohmichi@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] Scheduler hints, API and Objects<br>
Message-ID:<br>
<<a href="mailto:CAA393vhfetUH3PkJHkpcP9sf8vjzS%2BTm-Fcp7O_D6mo3Q_S-xA@mail.gmail.com">CAA393vhfetUH3PkJHkpcP9sf8vjzS+Tm-Fcp7O_D6mo3Q_S-xA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Alex,<br>
<br>
Thanks for your comment.<br>
IMO, this idea is different from the extension we will remove.<br>
That is modularity for the maintenance burden.<br>
By this idea, we can put the corresponding schema in each filter.<br>
<br>
2015?9?4?(?) 19:04 Alex Xu <<a href="mailto:soulxu@gmail.com">soulxu@gmail.com</a>>:<br>
<br>
> 2015-09-04 11:14 GMT+08:00 Ken'ichi Ohmichi <<a href="mailto:ken1ohmichi@gmail.com">ken1ohmichi@gmail.com</a>>:<br>
><br>
>> Hi Andrew,<br>
>><br>
>> Sorry for this late response, I missed it.<br>
>><br>
>> 2015-06-25 23:22 GMT+09:00 Andrew Laski <<a href="mailto:andrew@lascii.com">andrew@lascii.com</a>>:<br>
>> > I have been growing concerned recently with some attempts to formalize<br>
>> > scheduler hints, both with API validation and Nova objects defining<br>
>> them,<br>
>> > and want to air those concerns and see if others agree or can help me<br>
>> see<br>
>> > why I shouldn't worry.<br>
>> ><br>
>> > Starting with the API I think the strict input validation that's being<br>
>> done,<br>
>> > as seen in<br>
>> ><br>
>> <a href="http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da</a><br>
>> ,<br>
>> > is unnecessary, and potentially problematic.<br>
>> ><br>
>> > One problem is that it doesn't indicate anything useful for a client.<br>
>> The<br>
>> > schema indicates that there are hints available but can make no claim<br>
>> about<br>
>> > whether or not they're actually enabled. So while a microversion bump<br>
>> would<br>
>> > typically indicate a new feature available to an end user, in the case<br>
>> of a<br>
>> > new scheduler hint a microversion bump really indicates nothing at<br>
>> all. It<br>
>> > does ensure that if a scheduler hint is used that it's spelled properly<br>
>> and<br>
>> > the data type passed is correct, but that's primarily useful because<br>
>> there<br>
>> > is no feedback mechanism to indicate an invalid or unused scheduler<br>
>> hint. I<br>
>> > think the API schema is a poor proxy for that deficiency.<br>
>> ><br>
>> > Since the exposure of a hint means nothing as far as its usefulness, I<br>
>> don't<br>
>> > think we should be codifying them as part of our API schema at this<br>
>> time.<br>
>> > At some point I imagine we'll evolve a more useful API for passing<br>
>> > information to the scheduler as part of a request, and when that<br>
>> happens I<br>
>> > don't think needing to support a myriad of meaningless hints in older<br>
>> API<br>
>> > versions is going to be desirable.<br>
>> ><br>
>> > Finally, at this time I'm not sure we should take the stance that only<br>
>> > in-tree scheduler hints are supported. While I completely agree with<br>
>> the<br>
>> > desire to expose things in cross-cloud ways as we've done and are<br>
>> looking to<br>
>> > do with flavor and image properties I think scheduling is an area where<br>
>> we<br>
>> > want to allow some flexibility for deployers to write and expose<br>
>> scheduling<br>
>> > capabilities that meet their specific needs. Over time I hope we will<br>
>> get<br>
>> > to a place where some standardization can happen, but I don't think<br>
>> locking<br>
>> > in the current scheduling hints is the way forward for that. I would<br>
>> love<br>
>> > to hear from multi-cloud users here and get some input on whether that's<br>
>> > crazy and they are expecting benefits from validation on the current<br>
>> > scheduler hints.<br>
>> ><br>
>> > Now, objects. As part of the work to formalize the request spec sent<br>
>> to the<br>
>> > scheduler there's an effort to make a scheduler hints object. This<br>
>> > formalizes them in the same way as the API with no benefit that I can<br>
>> see.<br>
>> > I won't duplicate my arguments above, but I feel the same way about the<br>
>> > objects as I do with the API. I don't think needing to update and<br>
>> object<br>
>> > version every time a new hint is added is useful at this time, nor do I<br>
>> > think we should lock in the current in-tree hints.<br>
>> ><br>
>> > In the end this boils down to my concern that the scheduling hints api<br>
>> is a<br>
>> > really horrible user experience and I don't want it to be solidified in<br>
>> the<br>
>> > API or objects yet. I think we should re-examine how they're handled<br>
>> before<br>
>> > that happens.<br>
>><br>
>> Now we are discussing this on <a href="https://review.openstack.org/#/c/217727/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/217727/</a><br>
>> for allowing out-of-tree scheduler-hints.<br>
>> When we wrote API schema for scheduler-hints, it was difficult to know<br>
>> what are available API parameters for scheduler-hints.<br>
>> Current API schema exposes them and I guess that is useful for API users<br>
>> also.<br>
>><br>
>> One idea is that: How about auto-extending scheduler-hint API schema<br>
>> based on loaded schedulers?<br>
>> Now API schemas of "create/update/resize/rebuild a server" APIs are<br>
>> auto-extended based on loaded extensions by using stevedore<br>
>> library[1].<br>
>><br>
><br>
> Em....we will deprecate the extension from our API. this sounds like add<br>
> more extension mechanism.<br>
><br>
><br>
>> I guess we can apply the same way for scheduler-hints also in long-term.<br>
>> Each scheduler needs to implement a method which returns available API<br>
>> parameter formats and nova-api tries to get them then extends<br>
>> scheduler-hints API schema with them.<br>
>> That means out-of-tree schedulers also will be available if they<br>
>> implement the method.<br>
>> # In short-term, I can see "blocking additionalProperties" validation<br>
>> disabled by the way.<br>
>><br>
>> Thanks<br>
>> Ken Ohmichi<br>
>><br>
>> ---<br>
>> [1]:<br>
>> <a href="https://github.com/openstack/nova/blob/master/doc/source/api_plugins.rst#json-schema" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/master/doc/source/api_plugins.rst#json-schema</a><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://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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/34f28fe5/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/34f28fe5/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 31<br>
Date: Fri, 4 Sep 2015 13:37:25 +0300<br>
From: Vitaly Gridnev <<a href="mailto:vgridnev@mirantis.com">vgridnev@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] [sahara] FFE request for heat wait<br>
condition support<br>
Message-ID:<br>
<<a href="mailto:CA%2BO3VAhA2Xi_hKCaCB2PoWr8jUM0bQhwnSUAGx2gOGB0ksii6w@mail.gmail.com">CA+O3VAhA2Xi_hKCaCB2PoWr8jUM0bQhwnSUAGx2gOGB0ksii6w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
+1 for FFE, because of<br>
<br>
1. Low risk of issues, fully covered with current scenario tests;<br>
2. Implementation already on review<br>
<br>
On Fri, Sep 4, 2015 at 12:54 PM, Sergey Reshetnyak <<a href="mailto:sreshetniak@mirantis.com">sreshetniak@mirantis.com</a><br>
> wrote:<br>
<br>
> Hi,<br>
><br>
> I would like to request FFE for wait condition support for Heat engine.<br>
> Wait condition reports signal about booting instance.<br>
><br>
> Blueprint:<br>
> <a href="https://blueprints.launchpad.net/sahara/+spec/sahara-heat-wait-conditions" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/sahara/+spec/sahara-heat-wait-conditions</a><br>
><br>
> Spec:<br>
><br>
> <a href="https://github.com/openstack/sahara-specs/blob/master/specs/liberty/sahara-heat-wait-conditions.rst" rel="noreferrer" target="_blank">https://github.com/openstack/sahara-specs/blob/master/specs/liberty/sahara-heat-wait-conditions.rst</a><br>
><br>
> Patch:<br>
> <a href="https://review.openstack.org/#/c/169338/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/169338/</a><br>
><br>
> Thanks,<br>
> Sergey Reshetnyak<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>
Best Regards,<br>
Vitaly Gridnev<br>
Mirantis, Inc<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/92bbca9d/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/92bbca9d/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 32<br>
Date: Fri, 04 Sep 2015 12:56:51 +0200<br>
From: Sylvain Bauza <<a href="mailto:sbauza@redhat.com">sbauza@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>><br>
Subject: Re: [openstack-dev] Scheduler hints, API and Objects<br>
Message-ID: <<a href="mailto:55E978F3.2070804@redhat.com">55E978F3.2070804@redhat.com</a>><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
<br>
<br>
Le 04/09/2015 12:18, Ken'ichi Ohmichi a ?crit :<br>
><br>
> Hi Alex,<br>
><br>
> Thanks for your comment.<br>
> IMO, this idea is different from the extension we will remove.<br>
> That is modularity for the maintenance burden.<br>
> By this idea, we can put the corresponding schema in each filter.<br>
><br>
><br>
<br>
While I think it could be a nice move to have stevedore-loaded filters<br>
for the FilterScheduler due to many reasons, I actually wouldn't want to<br>
delay more than needed the compatibility change for the API validation<br>
relaxing the scheduler hints.<br>
<br>
In order to have a smooth transition, I'd rather just provide a change<br>
for using stevedore with the filters and weighters (even if the<br>
weighters are not using the API), and then once implemented, then do the<br>
necessary change on the API level like the one you proposed.<br>
<br>
In the meantime, IMHO we should accept rather sooner than later (meaning<br>
for Liberty) <a href="https://review.openstack.org/#/c/217727/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/217727/</a><br>
<br>
Thanks for that good idea, I like it,<br>
<br>
-Sylvain<br>
<br>
<br>
> 2015?9?4?(?) 19:04 Alex Xu <<a href="mailto:soulxu@gmail.com">soulxu@gmail.com</a><br>
> <mailto:<a href="mailto:soulxu@gmail.com">soulxu@gmail.com</a>>>:<br>
><br>
> 2015-09-04 11:14 GMT+08:00 Ken'ichi Ohmichi <<a href="mailto:ken1ohmichi@gmail.com">ken1ohmichi@gmail.com</a><br>
> <mailto:<a href="mailto:ken1ohmichi@gmail.com">ken1ohmichi@gmail.com</a>>>:<br>
><br>
> Hi Andrew,<br>
><br>
> Sorry for this late response, I missed it.<br>
><br>
> 2015-06-25 23:22 GMT+09:00 Andrew Laski <<a href="mailto:andrew@lascii.com">andrew@lascii.com</a><br>
> <mailto:<a href="mailto:andrew@lascii.com">andrew@lascii.com</a>>>:<br>
> > I have been growing concerned recently with some attempts to<br>
> formalize<br>
> > scheduler hints, both with API validation and Nova objects<br>
> defining them,<br>
> > and want to air those concerns and see if others agree or<br>
> can help me see<br>
> > why I shouldn't worry.<br>
> ><br>
> > Starting with the API I think the strict input validation<br>
> that's being done,<br>
> > as seen in<br>
> ><br>
> <a href="http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da</a>,<br>
> > is unnecessary, and potentially problematic.<br>
> ><br>
> > One problem is that it doesn't indicate anything useful for<br>
> a client. The<br>
> > schema indicates that there are hints available but can make<br>
> no claim about<br>
> > whether or not they're actually enabled. So while a<br>
> microversion bump would<br>
> > typically indicate a new feature available to an end user,<br>
> in the case of a<br>
> > new scheduler hint a microversion bump really indicates<br>
> nothing at all. It<br>
> > does ensure that if a scheduler hint is used that it's<br>
> spelled properly and<br>
> > the data type passed is correct, but that's primarily useful<br>
> because there<br>
> > is no feedback mechanism to indicate an invalid or unused<br>
> scheduler hint. I<br>
> > think the API schema is a poor proxy for that deficiency.<br>
> ><br>
> > Since the exposure of a hint means nothing as far as its<br>
> usefulness, I don't<br>
> > think we should be codifying them as part of our API schema<br>
> at this time.<br>
> > At some point I imagine we'll evolve a more useful API for<br>
> passing<br>
> > information to the scheduler as part of a request, and when<br>
> that happens I<br>
> > don't think needing to support a myriad of meaningless hints<br>
> in older API<br>
> > versions is going to be desirable.<br>
> ><br>
> > Finally, at this time I'm not sure we should take the stance<br>
> that only<br>
> > in-tree scheduler hints are supported. While I completely<br>
> agree with the<br>
> > desire to expose things in cross-cloud ways as we've done<br>
> and are looking to<br>
> > do with flavor and image properties I think scheduling is an<br>
> area where we<br>
> > want to allow some flexibility for deployers to write and<br>
> expose scheduling<br>
> > capabilities that meet their specific needs. Over time I<br>
> hope we will get<br>
> > to a place where some standardization can happen, but I<br>
> don't think locking<br>
> > in the current scheduling hints is the way forward for<br>
> that. I would love<br>
> > to hear from multi-cloud users here and get some input on<br>
> whether that's<br>
> > crazy and they are expecting benefits from validation on the<br>
> current<br>
> > scheduler hints.<br>
> ><br>
> > Now, objects. As part of the work to formalize the request<br>
> spec sent to the<br>
> > scheduler there's an effort to make a scheduler hints<br>
> object. This<br>
> > formalizes them in the same way as the API with no benefit<br>
> that I can see.<br>
> > I won't duplicate my arguments above, but I feel the same<br>
> way about the<br>
> > objects as I do with the API. I don't think needing to<br>
> update and object<br>
> > version every time a new hint is added is useful at this<br>
> time, nor do I<br>
> > think we should lock in the current in-tree hints.<br>
> ><br>
> > In the end this boils down to my concern that the scheduling<br>
> hints api is a<br>
> > really horrible user experience and I don't want it to be<br>
> solidified in the<br>
> > API or objects yet. I think we should re-examine how<br>
> they're handled before<br>
> > that happens.<br>
><br>
> Now we are discussing this on<br>
> <a href="https://review.openstack.org/#/c/217727/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/217727/</a><br>
> for allowing out-of-tree scheduler-hints.<br>
> When we wrote API schema for scheduler-hints, it was difficult<br>
> to know<br>
> what are available API parameters for scheduler-hints.<br>
> Current API schema exposes them and I guess that is useful for<br>
> API users also.<br>
><br>
> One idea is that: How about auto-extending scheduler-hint API<br>
> schema<br>
> based on loaded schedulers?<br>
> Now API schemas of "create/update/resize/rebuild a server"<br>
> APIs are<br>
> auto-extended based on loaded extensions by using stevedore<br>
> library[1].<br>
><br>
><br>
> Em....we will deprecate the extension from our API. this sounds<br>
> like add more extension mechanism.<br>
><br>
> I guess we can apply the same way for scheduler-hints also in<br>
> long-term.<br>
> Each scheduler needs to implement a method which returns<br>
> available API<br>
> parameter formats and nova-api tries to get them then extends<br>
> scheduler-hints API schema with them.<br>
> That means out-of-tree schedulers also will be available if they<br>
> implement the method.<br>
> # In short-term, I can see "blocking additionalProperties"<br>
> validation<br>
> disabled by the way.<br>
><br>
> Thanks<br>
> Ken Ohmichi<br>
><br>
> ---<br>
> [1]:<br>
> <a href="https://github.com/openstack/nova/blob/master/doc/source/api_plugins.rst#json-schema" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/master/doc/source/api_plugins.rst#json-schema</a><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>
> 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>
> 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/20150904/ba8e2d21/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/ba8e2d21/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 33<br>
Date: Fri, 4 Sep 2015 07:15:01 -0400<br>
From: Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [openstack-announce] [release][nova]<br>
python-novaclient release 2.28.0 (liberty)<br>
Message-ID: <<a href="mailto:55E97D35.9020507@dague.net">55E97D35.9020507@dague.net</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On 09/02/2015 05:48 PM, Matt Riedemann wrote:<br>
><br>
><br>
> On 9/2/2015 3:40 PM, Jeremy Stanley wrote:<br>
>> On 2015-09-02 10:55:56 -0400 (-0400), <a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a> wrote:<br>
>>> We are thrilled to announce the release of:<br>
>>><br>
>>> python-novaclient 2.27.0: Client library for OpenStack Compute API<br>
>> [...]<br>
>><br>
>> Just as a heads up, there's some indication that this release is<br>
>> currently broken by many popular service providers (behavior ranging<br>
>> from 401 unauthorized errors to hanging indefinitely due, it seems,<br>
>> to filtering or not supporting version detection in various ways).<br>
>><br>
>> <a href="https://launchpad.net/bugs/1491579" rel="noreferrer" target="_blank">https://launchpad.net/bugs/1491579</a><br>
>><br>
><br>
> And:<br>
><br>
> <a href="https://bugs.launchpad.net/python-novaclient/+bug/1491325" rel="noreferrer" target="_blank">https://bugs.launchpad.net/python-novaclient/+bug/1491325</a><br>
><br>
> We have a fix for ^ and I plan on putting in the request for 2.27.1<br>
> tonight once the fix is merged. That should unblock manila.<br>
><br>
> For the version discovery bug, we plan on talking about that in the nova<br>
> meeting tomorrow.<br>
<br>
The issues exposed in novaclient version detection working correctly<br>
against various clouds has now be fixed in 2.28.0 - the bug<br>
<a href="https://bugs.launchpad.net/python-novaclient/+bug/1491579" rel="noreferrer" target="_blank">https://bugs.launchpad.net/python-novaclient/+bug/1491579</a> has been<br>
updated to hopefully contain all the relevant details of the issue.<br>
<br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 34<br>
Date: Fri, 4 Sep 2015 07:29:45 -0400<br>
From: Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [openstack-announce] [release][nova]<br>
python-novaclient release 2.28.0 (liberty)<br>
Message-ID: <<a href="mailto:55E980A9.9020101@dague.net">55E980A9.9020101@dague.net</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On 09/04/2015 07:15 AM, Sean Dague wrote:<br>
> On 09/02/2015 05:48 PM, Matt Riedemann wrote:<br>
>><br>
>><br>
>> On 9/2/2015 3:40 PM, Jeremy Stanley wrote:<br>
>>> On 2015-09-02 10:55:56 -0400 (-0400), <a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a> wrote:<br>
>>>> We are thrilled to announce the release of:<br>
>>>><br>
>>>> python-novaclient 2.27.0: Client library for OpenStack Compute API<br>
>>> [...]<br>
>>><br>
>>> Just as a heads up, there's some indication that this release is<br>
>>> currently broken by many popular service providers (behavior ranging<br>
>>> from 401 unauthorized errors to hanging indefinitely due, it seems,<br>
>>> to filtering or not supporting version detection in various ways).<br>
>>><br>
>>> <a href="https://launchpad.net/bugs/1491579" rel="noreferrer" target="_blank">https://launchpad.net/bugs/1491579</a><br>
>>><br>
>><br>
>> And:<br>
>><br>
>> <a href="https://bugs.launchpad.net/python-novaclient/+bug/1491325" rel="noreferrer" target="_blank">https://bugs.launchpad.net/python-novaclient/+bug/1491325</a><br>
>><br>
>> We have a fix for ^ and I plan on putting in the request for 2.27.1<br>
>> tonight once the fix is merged. That should unblock manila.<br>
>><br>
>> For the version discovery bug, we plan on talking about that in the nova<br>
>> meeting tomorrow.<br>
><br>
> The issues exposed in novaclient version detection working correctly<br>
> against various clouds has now be fixed in 2.28.0 - the bug<br>
> <a href="https://bugs.launchpad.net/python-novaclient/+bug/1491579" rel="noreferrer" target="_blank">https://bugs.launchpad.net/python-novaclient/+bug/1491579</a> has been<br>
> updated to hopefully contain all the relevant details of the issue.<br>
<br>
It also looks like a big reason that this unexpected behavior in the<br>
field existed was because configuring SSL termination correctly (so that<br>
link following in the rest documents work) requires setting a ton of<br>
additional and divergent configuration options in various services.<br>
Thanks for folks looking into the issue in the bug and helping explain<br>
the behavior we saw.<br>
<br>
We're not yet testing for that in Tempest, so people are probably not<br>
realizing that their API environments are a bit janky.<br>
<br>
Honestly, the fact that deployers are required to do this is crazy. The<br>
service catalog already has this information, and the services should be<br>
reflecting this back. However people spent a lot of time working around<br>
the service catalog here probably because they didn't understand it, and<br>
creating a configuration hairball in the process.<br>
<br>
This I think raises the importance of really getting the Service Catalog<br>
into shape in this next cycle so that we can get ahead of issues like<br>
this one in the future, and actually ensure that out of the box cloud<br>
installs work in situations like this.<br>
<br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 35<br>
Date: Fri, 4 Sep 2015 13:37:05 +0200<br>
From: Flavio Percoco <<a href="mailto:flavio@redhat.com">flavio@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>><br>
Subject: Re: [openstack-dev] [all] Mitaka Design Summit - Proposed<br>
slot allocation<br>
Message-ID: <<a href="mailto:20150904113705.GH30997@redhat.com">20150904113705.GH30997@redhat.com</a>><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
On 04/09/15 12:14 +0200, Thierry Carrez wrote:<br>
>Hi PTLs,<br>
><br>
>Here is the proposed slot allocation for every "big tent" project team<br>
>at the Mitaka Design Summit in Tokyo. This is based on the requests the<br>
>liberty PTLs have made, space availability and project activity &<br>
>collaboration needs.<br>
><br>
>We have a lot less space (and time slots) in Tokyo compared to<br>
>Vancouver, so we were unable to give every team what they wanted. In<br>
>particular, there were far more workroom requests than we have<br>
>available, so we had to cut down on those quite heavily. Please note<br>
>that we'll have a large lunch room with roundtables inside the Design<br>
>Summit space that can easily be abused (outside of lunch) as space for<br>
>extra discussions.<br>
><br>
>Here is the allocation:<br>
><br>
>| fb: fishbowl 40-min slots<br>
>| wr: workroom 40-min slots<br>
>| cm: Friday contributors meetup<br>
>| | day: full day, morn: only morning, aft: only afternoon<br>
><br>
>Neutron: 12fb, cm:day<br>
>Nova: 14fb, cm:day<br>
>Cinder: 5fb, 4wr, cm:day<br>
>Horizon: 2fb, 7wr, cm:day<br>
>Heat: 4fb, 8wr, cm:morn<br>
>Keystone: 7fb, 3wr, cm:day<br>
>Ironic: 4fb, 4wr, cm:morn<br>
>Oslo: 3fb, 5wr<br>
>Rally: 1fb, 2wr<br>
>Kolla: 3fb, 5wr, cm:aft<br>
>Ceilometer: 2fb, 7wr, cm:morn<br>
>TripleO: 2fb, 1wr, cm:full<br>
>Sahara: 2fb, 5wr, cm:aft<br>
>Murano: 2wr, cm:full<br>
>Glance: 3fb, 5wr, cm:full<br>
>Manila: 2fb, 4wr, cm:morn<br>
>Magnum: 5fb, 5wr, cm:full<br>
>Swift: 2fb, 12wr, cm:full<br>
>Trove: 2fb, 4wr, cm:aft<br>
>Barbican: 2fb, 6wr, cm:aft<br>
>Designate: 1fb, 4wr, cm:aft<br>
>OpenStackClient: 1fb, 1wr, cm:morn<br>
>Mistral: 1fb, 3wr<br>
>Zaqar: 1fb, 3wr<br>
>Congress: 3wr<br>
>Cue: 1fb, 1wr<br>
>Solum: 1fb<br>
>Searchlight: 1fb, 1wr<br>
>MagnetoDB: won't be present<br>
><br>
>Infrastructure: 3fb, 4wr (shared meetup with Ironic and QA)<br>
>PuppetOpenStack: 2fb, 3wr<br>
>Documentation: 2fb, 4wr, cm:morn<br>
>Quality Assurance: 4fb, 4wr, cm:full<br>
>OpenStackAnsible: 2fb, 1wr, cm:aft<br>
>Release management: 1fb, 1wr (shared meetup with QA)<br>
>Security: 2fb, 2wr<br>
>ChefOpenstack: will camp in the lunch room all week<br>
>App catalog: 1fb, 1wr<br>
>I18n: cm:morn<br>
>OpenStack UX: 2wr<br>
>Packaging-deb: 2wr<br>
>Refstack: 2wr<br>
>RpmPackaging: 1fb, 1wr<br>
><br>
>We'll start working on laying out those sessions over the available<br>
>rooms and time slots. If you have constraints (I already know<br>
>searchlight wants to avoid conflicts with Horizon, Kolla with Magnum,<br>
>Manila with Cinder, Solum with Magnum...) please let me know, we'll do<br>
>our best to limit them.<br>
<br>
>From a very selfish POV, I'd like to avoid conflicts between Glance<br>
and Zaqar.<br>
<br>
>From a community POV, It'd be cool if we could avoid conflicts between<br>
Zaqar and Sahara (at least in 1wr slot) since we'd like to dedicate 1<br>
to Sahara.<br>
<br>
Cheers,<br>
Flavio<br>
<br>
--<br>
@flaper87<br>
Flavio Percoco<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: not available<br>
Type: application/pgp-signature<br>
Size: 819 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/e7b9b548/attachment-0001.pgp" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/e7b9b548/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 36<br>
Date: Fri, 4 Sep 2015 14:48:53 +0300<br>
From: Ekaterina Chernova <<a href="mailto:efedorova@mirantis.com">efedorova@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] [murano] [dashboard] Remove the owner<br>
filter from "Package Definitions" page<br>
Message-ID:<br>
<<a href="mailto:CAOFFu8Zo5SRVPUytGk7kj4UgNN5KJ5m39d9NeJpKoB427FbzfA@mail.gmail.com">CAOFFu8Zo5SRVPUytGk7kj4UgNN5KJ5m39d9NeJpKoB427FbzfA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Agreed.<br>
<br>
Currently, pagination is broken on "Package definitions" page now, so<br>
removing that filter<br>
will fix it back. Also, 'Other' tab looks unhelpful, admin should indicate<br>
to witch tenant this package belongs to.<br>
This improvement will be added later.<br>
<br>
Regards,<br>
Kate.<br>
<br>
On Fri, Sep 4, 2015 at 1:06 PM, Alexander Tivelkov <<a href="mailto:ativelkov@mirantis.com">ativelkov@mirantis.com</a>><br>
wrote:<br>
<br>
> ?+1 on this.<br>
><br>
> Filtering by ownership makes sense only on Catalog view (i.e. on the page<br>
> of usable apps) ?but not on the admin-like console like the list of package<br>
> definitions.<br>
><br>
> --<br>
> Regards,<br>
> Alexander Tivelkov<br>
><br>
> On Fri, Sep 4, 2015 at 12:36 PM, Dmitro Dovbii <<a href="mailto:ddovbii@mirantis.com">ddovbii@mirantis.com</a>><br>
> wrote:<br>
><br>
>> Hi folks!<br>
>><br>
>> I want suggest you to delete owner filter (3 tabs) from Package<br>
>> Definition page. Previously this filter was available for all users and we<br>
>> agreed that it is useless. Now it is available only for admin but I think<br>
>> this fact still doesn't improve the UX. Moreover, this filter prevents the<br>
>> implementation of the search by name, because the work of the two filters<br>
>> can be inconsistent.<br>
>> So, please express your opinion on this issue. If you agree, I will<br>
>> remove this filter ASAP.<br>
>><br>
>> Best regards,<br>
>> Dmytro Dovbii<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://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>
> 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/20150904/4a269156/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/4a269156/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 37<br>
Date: Fri, 4 Sep 2015 13:52:41 +0200<br>
From: Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com">dtantsur@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [all] Mitaka Design Summit - Proposed<br>
slot allocation<br>
Message-ID: <<a href="mailto:55E98609.4060708@redhat.com">55E98609.4060708@redhat.com</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
On 09/04/2015 12:14 PM, Thierry Carrez wrote:<br>
> Hi PTLs,<br>
><br>
> Here is the proposed slot allocation for every "big tent" project team<br>
> at the Mitaka Design Summit in Tokyo. This is based on the requests the<br>
> liberty PTLs have made, space availability and project activity &<br>
> collaboration needs.<br>
><br>
> We have a lot less space (and time slots) in Tokyo compared to<br>
> Vancouver, so we were unable to give every team what they wanted. In<br>
> particular, there were far more workroom requests than we have<br>
> available, so we had to cut down on those quite heavily. Please note<br>
> that we'll have a large lunch room with roundtables inside the Design<br>
> Summit space that can easily be abused (outside of lunch) as space for<br>
> extra discussions.<br>
><br>
> Here is the allocation:<br>
><br>
> | fb: fishbowl 40-min slots<br>
> | wr: workroom 40-min slots<br>
> | cm: Friday contributors meetup<br>
> | | day: full day, morn: only morning, aft: only afternoon<br>
><br>
> Neutron: 12fb, cm:day<br>
> Nova: 14fb, cm:day<br>
> Cinder: 5fb, 4wr, cm:day<br>
> Horizon: 2fb, 7wr, cm:day<br>
> Heat: 4fb, 8wr, cm:morn<br>
> Keystone: 7fb, 3wr, cm:day<br>
> Ironic: 4fb, 4wr, cm:morn<br>
> Oslo: 3fb, 5wr<br>
> Rally: 1fb, 2wr<br>
> Kolla: 3fb, 5wr, cm:aft<br>
> Ceilometer: 2fb, 7wr, cm:morn<br>
> TripleO: 2fb, 1wr, cm:full<br>
> Sahara: 2fb, 5wr, cm:aft<br>
> Murano: 2wr, cm:full<br>
> Glance: 3fb, 5wr, cm:full<br>
> Manila: 2fb, 4wr, cm:morn<br>
> Magnum: 5fb, 5wr, cm:full<br>
> Swift: 2fb, 12wr, cm:full<br>
> Trove: 2fb, 4wr, cm:aft<br>
> Barbican: 2fb, 6wr, cm:aft<br>
> Designate: 1fb, 4wr, cm:aft<br>
> OpenStackClient: 1fb, 1wr, cm:morn<br>
> Mistral: 1fb, 3wr<br>
> Zaqar: 1fb, 3wr<br>
> Congress: 3wr<br>
> Cue: 1fb, 1wr<br>
> Solum: 1fb<br>
> Searchlight: 1fb, 1wr<br>
> MagnetoDB: won't be present<br>
><br>
> Infrastructure: 3fb, 4wr (shared meetup with Ironic and QA)<br>
> PuppetOpenStack: 2fb, 3wr<br>
> Documentation: 2fb, 4wr, cm:morn<br>
> Quality Assurance: 4fb, 4wr, cm:full<br>
> OpenStackAnsible: 2fb, 1wr, cm:aft<br>
> Release management: 1fb, 1wr (shared meetup with QA)<br>
> Security: 2fb, 2wr<br>
> ChefOpenstack: will camp in the lunch room all week<br>
> App catalog: 1fb, 1wr<br>
> I18n: cm:morn<br>
> OpenStack UX: 2wr<br>
> Packaging-deb: 2wr<br>
> Refstack: 2wr<br>
> RpmPackaging: 1fb, 1wr<br>
><br>
> We'll start working on laying out those sessions over the available<br>
> rooms and time slots. If you have constraints (I already know<br>
> searchlight wants to avoid conflicts with Horizon, Kolla with Magnum,<br>
> Manila with Cinder, Solum with Magnum...) please let me know, we'll do<br>
> our best to limit them.<br>
><br>
<br>
Would be cool to avoid conflicts between Ironic and TripleO.<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 41, Issue 9<br>
********************************************<br>
</blockquote></div><br></div></div>