Open Stack

On 4 September 2015 at 08:00, <openstack-dev-request at lists.openstack.org>
wrote:

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