settingsLogin | Registersettings

[openstack-dev] help

0 votes

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

Send OpenStack-dev mailing list submissions to
openstack-dev@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@lists.openstack.org

You can reach the person managing the list at
openstack-dev-owner@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)

    1. Re: FFE Request for completion of data driven assignment
      testing in Keystone (David Stanek)
    2. Re: [neutron] pushing changes through the gate (Armando M.)
    3. Re: FFE Request for completion of data driven assignment
      testing in Keystone (Morgan Fainberg)
    4. Re: Scheduler hints, API and Objects (Ken'ichi Ohmichi)
    5. [kolla][doc] Kolla documentation now live on
      docs.openstack.org! (Steven Dake (stdake))
    6. Re: FFE Request for completion of data driven assignment
      testing in Keystone (Morgan Fainberg)
    7. Re: [Openstack-operators] [Neutron] Allowing DNS suffix to be
      set per subnet (at least per tenant) (Daniel Comnea)
    8. What's Up, Doc? 4 September, 2015 (Lana Brindley)
    9. Re: [infra][third-party][CI] Third-party oses in
      devstack-gate (Evgeny Antyshev)
    10. Re: [Openstack-operators] [Neutron] Allowing DNS suffix to be
      set per subnet (at least per tenant) (Ihar Hrachyshka)
    11. Re: [Openstack] [ANN] OpenStack Kilo on Ubuntu fully
      automated with Ansible! Ready for NFV L2 Bridges via Heat!
      (Jose Manuel Ferrer Mosteiro)
    12. Re: FFE Request for completion of data driven assignment
      testing in Keystone (Thierry Carrez)
    13. Re: [infra][third-party][CI] Third-party oses in
      devstack-gate (Daniel Mellado)
    14. [murano] [dashboard] Remove the owner filter from "Package
      Definitions" page (Dmitro Dovbii)
    15. Re: [sahara] Request for Feature Freeze Exception
      (Sergey Reshetnyak)
    16. [sahara] FFE request for heat wait condition support
      (Sergey Reshetnyak)
    17. Re: Scheduler hints, API and Objects (Ken'ichi Ohmichi)
    18. Re: Scheduler hints, API and Objects (Alex Xu)
    19. Re: [murano] [dashboard] Remove the owner filter from
      "Package Definitions" page (Alexander Tivelkov)
    20. [all] Mitaka Design Summit - Proposed slot allocation
      (Thierry Carrez)
    21. Re: Scheduler hints, API and Objects (Ken'ichi Ohmichi)
    22. Re: [sahara] FFE request for heat wait condition support
      (Vitaly Gridnev)
    23. Re: Scheduler hints, API and Objects (Sylvain Bauza)
    24. Re: [openstack-announce] [release][nova] python-novaclient
      release 2.28.0 (liberty) (Sean Dague)
    25. Re: [openstack-announce] [release][nova] python-novaclient
      release 2.28.0 (liberty) (Sean Dague)
    26. Re: [all] Mitaka Design Summit - Proposed slot allocation
      (Flavio Percoco)
    27. Re: [murano] [dashboard] Remove the owner filter from
      "Package Definitions" page (Ekaterina Chernova)
    28. 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@debian.org
To: Diana Whitten hurgleburgler@gmail.com
Cc: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [horizon] Concern about
XStatic-bootswatch imports from fonts.googleapis.com
Message-ID: 55E8C462.5050804@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

  1. 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@pnnl.gov
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org, Kevin Benton <
blak111@gmail.com>
Cc: PAUL CARVER pc2929@att.com
Subject: Re: [openstack-dev] cloud-init IPv6 support
Message-ID:
1A3C52DFCD06494D8528644858247BF01A2F0CB6@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@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@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@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@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@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@gmail.com
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [horizon] Concern about XStatic-bootswatch
imports from fonts.googleapis.com
Message-ID:
<
CABswzdHTq_WqX6XmfMpdDrt0pDa2DZS3spw0O26rErtE7h9emg@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@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

  1. 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@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Heat] convergence rally test results (so
far)
Message-ID:
<
CAA16xcx7R0eNatKKrq1rxLX7OGL37acKRFis5S1Pmt8-ZJq+dg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Fri, Sep 4, 2015 at 12:48 AM Zane Bitter zbitter@redhat.com wrote:

On 03/09/15 02:56, Angus Salkeld wrote:

On Thu, Sep 3, 2015 at 3:53 AM Zane Bitter <zbitter@redhat.com
zbitter@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@mirantis.com <mailto:asalkeld@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 numengineworkers,
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 numresourceactions to
(numengineworkers*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
checkresource
"/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
resourceobjects.Resource.getobj(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 * concurrenttasksper_worker
product.

cheers,
Zane.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20150904/10ac4234/attachment-0001.html
>


Message: 5
Date: Thu, 3 Sep 2015 17:18:15 -0700
From: Jim Rollenhagen jim@jimrollenhagen.com
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Ironic] Liberty release plans
Message-ID: 20150904001815.GA21846@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@jimrollenhagen.com
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Ironic] Introducing ironic-lib 0.1.0
Message-ID: 20150904002400.GB21846@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@lab.ntt.co.jp
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] pushing changes through the
gate
Message-ID: AB2E7CE7-ECCC-49D9-AB20-46135559D3DE@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 -backlog directory during the RC window
and move all specs which didn?t make the 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@gmail.com wrote:

On 2 September 2015 at 09:40, Armando M. <armamig@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@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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [magnum]keystone version
Message-ID:
<CAH5-jC8FQ9C7ADVygXXVRyKMt867iBFsjimKp26db6=
pFO27-g@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@nakato.io
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Cross Project] [Neutron] [Nova] Tox.ini
changes for Constraints testing
Message-ID: <1721376.LIrBB9dSzH@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@dstanek.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@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@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Thu, Sep 3, 2015 at 3:44 PM Henry Nash henryn@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 listroleassignment 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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] pushing changes through the
gate
Message-ID:
<
CAK+RQea9d57qka7st1zWHMzGF4qoWWB3MWrhQZThEn0LBFEEtg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On 3 September 2015 at 17:55, Hirofumi Ichihara <
ichihara.hirofumi@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 -backlog directory during the RC window
and move all specs which didn?t make the 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@gmail.com wrote:

On 2 September 2015 at 09:40, Armando M. armamig@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@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@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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@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@gmail.com
Content-Type: text/plain; charset="us-ascii"

On Sep 3, 2015, at 19:28, David Stanek dstanek@dstanek.com wrote:

On Thu, Sep 3, 2015 at 3:44 PM Henry Nash henryn@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 listroleassignment 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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Scheduler hints, API and Objects
Message-ID:
<CAA393vixHPJ=Ay=
79JepDeMA+e+z8x_3FQcnT+8NcQCrvMtYFQ@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@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@cisco.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [kolla][doc] Kolla documentation now live on
docs.openstack.org!
Message-ID: D20E5BEE.11D6D%stdake@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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@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@gmail.com
Content-Type: text/plain; charset="us-ascii"

On Sep 3, 2015, at 19:48, Morgan Fainberg morgan.fainberg@gmail.com
wrote:

On Sep 3, 2015, at 19:28, David Stanek dstanek@dstanek.com wrote:

On Thu, Sep 3, 2015 at 3:44 PM Henry Nash henryn@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 listroleassignment 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@gmail.com
To: Kevin Benton blak111@gmail.com
Cc: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org,
"openstack-operators@lists.openstack.org"
openstack-operators@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@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@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/

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@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@wormley.com
wrote:

As far as I am aware it is not presently built-in to Openstack. You'll
need to add a dnsmasqconfigfile 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@maishsk.commaishsk@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@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@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

--
Kevin Benton


OpenStack-operators mailing list
OpenStack-operators@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@lanabrindley.com
To: "openstack-docs@lists.openstack.org"
openstack-docs@lists.openstack.org, OpenStack Development
Mailing
List openstack-dev@lists.openstack.org,
"openstack-i18n@lists.openstack.org"
openstack-i18n@lists.openstack.org
Subject: [openstack-dev] What's Up, Doc? 4 September, 2015
Message-ID: 55E93945.4040107@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@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@virtuozzo.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [infra][third-party][CI] Third-party oses
in devstack-gate
Message-ID: 55E93621.5050909@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 DEVSTACKLOCALCONFIG
(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 isfedora() as it is not officially
supported upstream,
but we can introduce the variable DEVSTACK
GATEISFEDORA 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@redhat.com
To: Daniel Comnea comnea.dani@gmail.com
Cc: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org,
"openstack-operators@lists.openstack.org"
openstack-operators@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@redhat.com
Content-Type: text/plain; charset="us-ascii"

On 04 Sep 2015, at 08:14, Daniel Comnea comnea.dani@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@gmail.com
To: Sabrina Bajorat sabrina.bajorat@gmail.com
Cc: OpenStack Development Mailing List
openstack-dev@lists.openstack.org, openstack@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@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@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!

Powered by Sandvine! ;-)

Basically, this is the automation of what we have documented here:

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 "portsecurityenabled" 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@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@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@openstack.org
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] FFE Request for completion of data driven
assignment testing in Keystone
Message-ID: 55E95399.1070903@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 listroleassignment 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@ieee.org
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [infra][third-party][CI] Third-party oses
in devstack-gate
Message-ID: 55E95991.4050105@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 DEVSTACKLOCALCONFIG
(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 isfedora() as it is not officially
supported upstream,
but we can introduce the variable DEVSTACK
GATEISFEDORA 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@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [murano] [dashboard] Remove the owner filter
from "Package Definitions" page
Message-ID:
<
CAKSp79y8cCU7z0S-Pzgy2k1TNJZZMsyVYXk-bEtSj6ByoB4JZQ@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@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [sahara] Request for Feature Freeze
Exception
Message-ID:
<
CAOB5mPxaTM5QKm410c2956QMfnsaz9QqT7XreMyxPmdrK1E0Og@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@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@redhat.com
To: openstack-dev@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@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@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@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [sahara] FFE request for heat wait condition
support
Message-ID:
<
CAOB5mPwf6avCZD4Q6U4xh-g4f553eMzCTh1kfiX4bVY8x59i5A@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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Scheduler hints, API and Objects
Message-ID:
<CAA393vhyeMYeA=6MK9+0LtReud67+OMBu=
KcaOzvM_pzL4Ea+g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

2015-09-04 12:14 GMT+09:00 Ken'ichi Ohmichi ken1ohmichi@gmail.com:

Hi Andrew,

Sorry for this late response, I missed it.

2015-06-25 23:22 GMT+09:00 Andrew Laski andrew@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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Scheduler hints, API and Objects
Message-ID:
<CAH7mGauOgfvVkfW2OYPm7D=
7zgXhRHpx4a7_jZMyBtND3iirGQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

2015-09-04 11:14 GMT+08:00 Ken'ichi Ohmichi ken1ohmichi@gmail.com:

Hi Andrew,

Sorry for this late response, I missed it.

2015-06-25 23:22 GMT+09:00 Andrew Laski andrew@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@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@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [murano] [dashboard] Remove the owner
filter from "Package Definitions" page
Message-ID:
<CAM6FM9S47YmJsTYGVNoPc7L2JGjBpCB+-s-HTd=
d+HK939GEEg@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@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@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@openstack.org
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [all] Mitaka Design Summit - Proposed slot
allocation
Message-ID: 55E96EEE.4070306@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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Scheduler hints, API and Objects
Message-ID:
<
CAA393vhfetUH3PkJHkpcP9sf8vjzS+Tm-Fcp7OD6mo3QS-xA@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@gmail.com:

2015-09-04 11:14 GMT+08:00 Ken'ichi Ohmichi ken1ohmichi@gmail.com:

Hi Andrew,

Sorry for this late response, I missed it.

2015-06-25 23:22 GMT+09:00 Andrew Laski andrew@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@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@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@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [sahara] FFE request for heat wait
condition support
Message-ID:
<
CA+O3VAhA2Xi_hKCaCB2PoWr8jUM0bQhwnSUAGx2gOGB0ksii6w@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@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@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@redhat.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Scheduler hints, API and Objects
Message-ID: 55E978F3.2070804@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@gmail.com
soulxu@gmail.com>:

2015-09-04 11:14 GMT+08:00 Ken'ichi Ohmichi <ken1ohmichi@gmail.com
<mailto:ken1ohmichi@gmail.com>>:

    Hi Andrew,

    Sorry for this late response, I missed it.

    2015-06-25 23:22 GMT+09:00 Andrew Laski <andrew@lascii.com
    <mailto:andrew@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@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@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@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@dague.net
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [openstack-announce] [release][nova]
python-novaclient release 2.28.0 (liberty)
Message-ID: 55E97D35.9020507@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@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@dague.net
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [openstack-announce] [release][nova]
python-novaclient release 2.28.0 (liberty)
Message-ID: 55E980A9.9020101@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@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@redhat.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] Mitaka Design Summit - Proposed
slot allocation
Message-ID: 20150904113705.GH30997@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@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [murano] [dashboard] Remove the owner
filter from "Package Definitions" page
Message-ID:
<
CAOFFu8Zo5SRVPUytGk7kj4UgNN5KJ5m39d9NeJpKoB427FbzfA@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@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@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@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@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@redhat.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] Mitaka Design Summit - Proposed
slot allocation
Message-ID: 55E98609.4060708@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

End of OpenStack-dev Digest, Vol 41, Issue 9



OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Sep 4, 2015 in openstack-dev by Swapnil_Tamse (120 points)  
...