Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Luigi Toscano]

- Original Message -
> Excerpts from Shamail Tahir's message of 2017-02-27 00:44:44 -0500:
> > Hi Clint,
> > 
> > On Mon, Feb 27, 2017 at 12:25 AM, Clint Byrum  wrote:
> > 
> > > Excerpts from Matt Riedemann's message of 2017-02-26 19:48:50 -0600:
> > > > On 2/26/2017 6:52 PM, Clint Byrum wrote:
> > > > > During some productive discussions in the Stewardship Working Group
> > > > > PTG
> > > > > room, the subject of the mailing list came up. The usual questions
> > > > > around whether or not we should have per-project lists came up and
> > > > > the
> > > > > reasons we don't were re-affirmed. To recap those reasons:
> > > > >
> > > > >   * Cross posting is the pits
> > > > >   * People don't always know at the beginning of a thread that a
> > > > > discussion will need to go wider, leading to silos and confusion.
> > > > >
> > > > > So we turned to ways to help reduce peoples' load while reading
> > > > > e-mail,
> > > > > since many (most?) tend to opt out of reading openstack-dev.
> > > > >
> > > > > There are a number of ways that we can help, including teaching
> > > > > people
> > > > > to have more efficient workflows and use specific mail reading tools
> > > > > (don't worry, we're not adding an NNTP gateway.. yet). But one that
> > > > > received positive feedback from the room was to have moderated
> > > > > business-only mailing lists for each project.
> > > > >
> > > > > Basically, there are things that we _do_ know will not go wider when
> > > > > the thread begins. Just running through the threads on the February
> > > > > thread index, there are a few obvious classes:
> > > > >
> > > > >   * Mascots
> > > > >   * Social meetups
> > > > >   * Meeting logistics
> > > > >   * Core team membership
> > > > >
> > >
> > I'm curious as to how much of the traffic (such as the examples given)
> > generates message fatigue on new users but I do appreciate that we are
> > trying to find solutions to make it easier to enter into the mailing lists
> > around OpenStack without having to resort to digests.
> > 
> 
> I think it's worth analyzing it, if somebody has time. I do not. My wild
> ass guess is between 1 and 5 percent of all messages, but probably more
> like 5-10 percent of threads, as a lot of them are the shorter, less
> interesting threads.
> 
> These seem like small numbers, but cognitive load is not linear and the
> number of threads people end up reading varies whether or not they use
> tags.

I share the feeling too that those messages are the minority of the total 
amount of real discussions, so moving them away won't address the problem and 
lead to more complication to the rest of the world.

> 
> > > > There are likely others. The idea is that these messages would go into
> > > > a
> > > > > ${project}-busin...@lists.openstack.org. Said list would be moderated
> > > by
> > > > > a team of the PTL's choosing, and we would admonish moderators to
> > > reject
> > > > > soundly any threads not obviously single project business related.
> > >
> > In this approach, we could send messages that fall within the ${
> > project}-busin...@lists.openstack.org to the dev ML as well.  This would
> > allow people who want only the ${project}-business news to get the content
> > without having to get all messages from the dev ML but at the same time
> > allow threads to be available to both subscribers (dev and
> > ${project}-business}.
> > 
> > I hope we still advocate for subscribing to the openstack-dev mailing list
> > even if a contributor is only starting with a single project (and not
> > interested in cross-project things) because it allows for people to see
> > conversations they might have expertise in or find a new project they want
> > to contribute to based on learning something new about it.
> > 
> 
> Wow, I must have failed in my wording ,sorry about that, because you
> got it 100% backwards. The idea is that everyone stays in openstack-dev
> for _all_ discussions (single-project as well). Only the most mundane
> but necessary emails go on per-project "business lists". So there would
> be zero point in ever subscribing to the business lists without also
> subscribing to openstack-dev, and likewise, republishing business lists
> to openstack-dev would defeat the entire point.

But why not educate people about the *topic* filtering that you can enable on 
mailman directly?
You don't need filters on your client, just go to your mailman page and select 
the topics.

Ciao
-- 
Luigi

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

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Clint Byrum]

Excerpts from Luigi Toscano's message of 2017-02-27 03:02:45 -0500:
> 
> - Original Message -
> > Excerpts from Shamail Tahir's message of 2017-02-27 00:44:44 -0500:
> > > Hi Clint,
> > > 
> > > On Mon, Feb 27, 2017 at 12:25 AM, Clint Byrum  wrote:
> > > 
> > > > Excerpts from Matt Riedemann's message of 2017-02-26 19:48:50 -0600:
> > > > > On 2/26/2017 6:52 PM, Clint Byrum wrote:
> > > > > > During some productive discussions in the Stewardship Working Group
> > > > > > PTG
> > > > > > room, the subject of the mailing list came up. The usual questions
> > > > > > around whether or not we should have per-project lists came up and
> > > > > > the
> > > > > > reasons we don't were re-affirmed. To recap those reasons:
> > > > > >
> > > > > >   * Cross posting is the pits
> > > > > >   * People don't always know at the beginning of a thread that a
> > > > > > discussion will need to go wider, leading to silos and 
> > > > > > confusion.
> > > > > >
> > > > > > So we turned to ways to help reduce peoples' load while reading
> > > > > > e-mail,
> > > > > > since many (most?) tend to opt out of reading openstack-dev.
> > > > > >
> > > > > > There are a number of ways that we can help, including teaching
> > > > > > people
> > > > > > to have more efficient workflows and use specific mail reading tools
> > > > > > (don't worry, we're not adding an NNTP gateway.. yet). But one that
> > > > > > received positive feedback from the room was to have moderated
> > > > > > business-only mailing lists for each project.
> > > > > >
> > > > > > Basically, there are things that we _do_ know will not go wider when
> > > > > > the thread begins. Just running through the threads on the February
> > > > > > thread index, there are a few obvious classes:
> > > > > >
> > > > > >   * Mascots
> > > > > >   * Social meetups
> > > > > >   * Meeting logistics
> > > > > >   * Core team membership
> > > > > >
> > > >
> > > I'm curious as to how much of the traffic (such as the examples given)
> > > generates message fatigue on new users but I do appreciate that we are
> > > trying to find solutions to make it easier to enter into the mailing lists
> > > around OpenStack without having to resort to digests.
> > > 
> > 
> > I think it's worth analyzing it, if somebody has time. I do not. My wild
> > ass guess is between 1 and 5 percent of all messages, but probably more
> > like 5-10 percent of threads, as a lot of them are the shorter, less
> > interesting threads.
> > 
> > These seem like small numbers, but cognitive load is not linear and the
> > number of threads people end up reading varies whether or not they use
> > tags.
> 
> I share the feeling too that those messages are the minority of the total 
> amount of real discussions, so moving them away won't address the problem and 
> lead to more complication to the rest of the world.
> 

Not every solution is a force multiplier. Some things are just fine
tuning. And again, cognitive load is not linear. If you are in a single
project silo, sure, these are easy to tune out. If you are trying to
work cross-project, you have to spend more time on each thread, even if
it is obvious.

> > 
> > > > > There are likely others. The idea is that these messages would go into
> > > > > a
> > > > > > ${project}-busin...@lists.openstack.org. Said list would be 
> > > > > > moderated
> > > > by
> > > > > > a team of the PTL's choosing, and we would admonish moderators to
> > > > reject
> > > > > > soundly any threads not obviously single project business related.
> > > >
> > > In this approach, we could send messages that fall within the ${
> > > project}-busin...@lists.openstack.org to the dev ML as well.  This would
> > > allow people who want only the ${project}-business news to get the content
> > > without having to get all messages from the dev ML but at the same time
> > > allow threads to be available to both subscribers (dev and
> > > ${project}-business}.
> > > 
> > > I hope we still advocate for subscribing to the openstack-dev mailing list
> > > even if a contributor is only starting with a single project (and not
> > > interested in cross-project things) because it allows for people to see
> > > conversations they might have expertise in or find a new project they want
> > > to contribute to based on learning something new about it.
> > > 
> > 
> > Wow, I must have failed in my wording ,sorry about that, because you
> > got it 100% backwards. The idea is that everyone stays in openstack-dev
> > for _all_ discussions (single-project as well). Only the most mundane
> > but necessary emails go on per-project "business lists". So there would
> > be zero point in ever subscribing to the business lists without also
> > subscribing to openstack-dev, and likewise, republishing business lists
> > to openstack-dev would defeat the entire point.
> 
> But why not educate people about the *topic* filtering that you can enable on 
> mailman directly?
> You don't need filters on your clien

Re: [openstack-dev] [ceilometer][gnocchi] How to push compute node metrics to gnocchi?

[Pradeep Singh]

Thanks for the reply.
Is there any documentation available for helping me to add the fields in
gnocchi_resources.yaml.

Thanks,
Pradeep Singh

On Sat, Feb 25, 2017 at 9:17 PM, Julien Danjou  wrote:

> On Sat, Feb 25 2017, Pradeep Singh wrote:
>
> > I installed devstack and enabled compute node's cpu utilization
> collection
> > in nova.conf, but seeing below error in notification agent's log.
> >
> > 2017-02-25 08:40:15.515 22662 WARNING ceilometer.dispatcher.gnocchi [-]
> > metric compute.node.cpu.frequency is not handled by Gnocchi
> > 2017-02-25 08:40:15.530 22662 WARNING ceilometer.dispatcher.gnocchi [-]
> > metric compute.node.cpu.idle.percent is not handled by Gnocchi
> > 2017-02-25 08:40:15.545 22662 WARNING ceilometer.dispatcher.gnocchi [-]
> > metric compute.node.cpu.idle.time is not handled by Gnocchi
> > 2017-02-25 08:40:15.559 22662 WARNING ceilometer.dispatcher.gnocchi [-]
> > metric compute.node.cpu.iowait.percent is not handled by Gnocchi
> > 2017-02-25 08:40:15.574 22662 WARNING ceilometer.dispatcher.gnocchi [-]
> > metric compute.node.cpu.iowait.time is not handled by Gnocchi
> > 2017-02-25 08:40:15.589 22662 WARNING ceilometer.dispatcher.gnocchi [-]
> > metric compute.node.cpu.kernel.percent is not handled by Gnocchi
> > 2017-02-25 08:40:15.604 22662 WARNING ceilometer.dispatcher.gnocchi [-]
> > metric compute.node.cpu.kernel.time is not handled by Gnocchi
> > 2017-02-25 08:40:15.620 22662 WARNING ceilometer.dispatcher.gnocchi [-]
> > metric compute.node.cpu.percent is not handled by Gnocchi
> > 2017-02-25 08:40:15.636 22662 WARNING ceilometer.dispatcher.gnocchi [-]
> > metric compute.node.cpu.user.percent is not handled by Gnocchi
> > 2017-02-25 08:40:15.653 22662 WARNING ceilometer.dispatcher.gnocchi [-]
> > metric compute.node.cpu.user.time is not handled by Gnocchi
> >
> > Could you please suggest what configuration i am missing.
>
> None. It looks like these metrics are not listed in
> ceilometer/dispatcher/data/gnocchi_resources.yaml so they are not
> supported by Gnocchi. It looks like this file should be modified this
> metrics to be able to handle them.
>
> Feel free to send a patch.
>
> --
> Julien Danjou
> # Free Software hacker
> # https://julien.danjou.info
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kuryr] Weekly IRC meeting today cancelled

[Antoni Segura Puimedon]

Hello Kuryrs,

Due to preparations for this week's VTG, today's meeting is cancelled.


Looking forward to see you all tomorrow!

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

Re: [openstack-dev] [Fuel] Nominating Alexander Kislitsky for fuel-web-core

[Ihor Kalnytskyi]

I'm pleased to welcome Alexander to the fuel-web core team!

https://review.openstack.org/#/admin/groups/664,members

On Wed, Feb 22, 2017 at 10:40 AM, Fedor Zhadaev  wrote:
> +1
>
> On Wed, Feb 22, 2017 at 12:36 AM Булат Гайфуллин 
> wrote:
>>
>> +1
>>
>> 2017-02-21 17:01 GMT+03:00 Alexey Shtokolov :
>>>
>>> Hey fellow fuelers,
>>>
>>> I'd like to nominate Alexander Kislitsky to the fuel-web-core team.
>>> He's doing thorough review [1], participate in feature developments
>>> (e.g. Config-DB enhancements, network-manager performance
>>> improvements) and made an outstanding contribution bug-fixing.
>>>
>>> Core reviewers, please reply back with +1/-1.
>>>
>>> Thanks,
>>> Ihor
>>>
>>> [1] http://stackalytics.com/?release=ocata&module=fuel-web
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> Fedor Zhadaev
> email: fzhad...@mirantis.com
> skype: zhadaevfm
> IRC: fzhadaev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements] Managing project requirements

[Andreas Scheuring]

Thanks all for your feedback. Seeing things much clearer now.

One last thing: How is the requirements bot being triggered?

- For OpenStack libraries by the jenkins job that handles the tag (if
the metadata is provided)?
- for external libraries? Is the a cronjob every 2 weeks or so? Or is it
even daily except during the requirements freeze?

Thanks!


-- 
-
Andreas 
IRC: andreas_s



On Fr, 2017-02-24 at 11:22 -0500, Tony Breeds wrote:
> On Fri, Feb 24, 2017 at 02:09:33PM +0100, Andreas Scheuring wrote:
> > Hi, I have a couple of questions in regards of how updates of
> > requirements are handled and what happens if I release a new version of
> > a library. I read along the README [1], but a few points are still
> > unclear to me.
> > 
> > I have the following projects:
> > 
> > * os-dpm [4]
> >   * is a openstack library that gets release when required
> >   * release is done manually (creating a tag and pushing it to gerrit)
> >   * listed in global requirements & upper constraints
> > * zhmcclient [6]
> >   * An "external" library that gets released to pypi
> >   * listed in global requirements & upper constraints
> > * nova-dpm [2] & networking-dpm [3]
> >   * are the main projects and therefore not listed in the openstack
> > requirements
> >   * both specify the os-dpm and zhmcclient in their requirements.txt
> >   * both are accepted in the projects.txt to allow the automated sync of
> > global requirements
> > 
> > 
> > Now the scenarios are
> > 
> > A new version of the external library 'zhmcclient' gets released
> > 
> > 
> > What to do in order to get this reflected in upper constraints? At first
> > I was pushing manual updates to requirements txt, but the latest version
> > was pushed in by the OpenStack proposal bot around 10 days after the
> > release [4]. What's the right approach here?
> > 
> > How can I ensure that I have to approve a new version for my projects,
> > before it gets applied there? (Once it is in upper constraints, it is
> > used in my project as well automatically). If I specify an upper
> > constraint in my requirements.txt file, then the requirements job
> > complains as the requirement does not exactly match the requirementused
> > in global requirements...
> 
> So if you find that a new version of zhmcclient doesn't work for you the 2
> options available to you are:
> 1) Fix you project to tolerate the new (and old) version
> 2) Ban (via !=) in openstack/requirements:global-requirements.txt, and revert
>the relevant parts of the upper-constraints.txt change, which will then
>propagate to your project once it merges (via the proposal-bot)
> 
> but fundamentally it boils down to we'll accept new versions into
> upper-constraints.txt and if it breaks we'll back out/correct it.
> 
> If this proves to be overly problematic for you we can discuss ways for you to
> more actively engage with requirements management to ensure you can approve
> things before that land but that's atypical
> 
> > A new version of the openstack library 'os-dpm' gets released
> > -
> > 
> > As this is an OpenStack project - I think the flow is slightly
> > different: If a new release gets tagged with the corresponding metadata,
> > a patch to upper constraints is submitted automatically. (I still need
> > to figure out how that metdata should look like...)
> 
> Doug's already answer this better than I could.
> 
> > But the same question like above, can I control the upper constraints in
> > my project?
> 
> You've opted into having your requirements managed by the requirements team.
> So the way to set bans or (if really needed) caps is as I outlined above via
> changes to global-requirements.txt.
> 
> The management of *constraints* is global and not per-project.
> 
> Yours Tony.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA][blazar][ceilometer][congress][intel-nfv-ci-tests][ironic][manila][networking-bgpvpn][networking-fortinet][networking-sfc][neutron][neutron-fwaas][neutron-lbaas][nova-lxd][octavia]

[Andrea Frittoli]

Hello folks,

TL;DR: if today you import manager,py from tempest.scenario please maintain
a copy of [0] in tree until further notice.

Full message:
--

One of the priorities for the QA team in the Pike cycle is to refactor
scenario tests to a sane code base [1].

As they are now, changes to scenario tests are difficult to develop and
review, and failures in those tests are hard to debug, which is in many
directions far away from where we need to be.

The issue we face is that, even though tempest.scenario.manager is not
advertised as a stable interface in Tempest, many project use it today for
convenience in writing their own tests. We don't know about dependencies
outside of the OpenStack ecosystem, but we want to try to make this
refactor a smooth experience for our uses in OpenStack, and avoid painful
gate breakages as much as possible.

The process we're proposing is as follows:
- hold a copy of [0] in tree - in most cases you won't even have to change
your imports as a lot of projects use tempest/scenario in their code base.
You may decide to include the bare minimum you need from that module
instead of all of it. It's a bit more work to make the patch, but less
un-used code lying around afterwards.
- the QA team will refactor scenario tests, and make more interfaces stable
(test.py, credential providers). We won't advertise every single change in
this process, only when we start and once we're done.
- you may decide to discard your local copy of manager.py and consume
Tempest stable interfaces directly. We will help with any question you may
have on the process and on Tempest interfaces.

Repositories affected by the refactor are (based on [2]):

blazar,ceilometer,congress,intel-nfv-ci-tests,ironic,manila,networking-bgpvpn,networking-fortinet,networking-sfc,neutron-fwaas,neutron-lbaas,nova-lxd,octavia,sahara-tests,tap-as-a-service,tempest-horizon,vmware-nsx,watcher

If we don't hear from a team at all in the next two weeks, we will assume
that the corresponding Tempest plugin / bunch of tests is not in use
anymore, and ignore it. If you use tempest.scenario.manager.py today and
your repo is not on the list, please let us know!

I'm happy to propose an initial patch for any team that may require it -
just ping me on IRC (andreaf).
I won't have the bandwidth myself to babysit each patch through review and
gate though.

Thank you for your cooperation and patience!

Andrea

[0]
http://git.openstack.org/cgit/openstack/tempest/tree/tempest/scenario/manager.py

[1] https://etherpad.openstack.org/p/pike-qa-priorities
[2]
https://github.com/andreafrittoli/tempest_stable_interfaces/blob/master/data/get_deps.sh
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] no upgrades meeting today

[Ihar Hrachyshka]

Hi,

Sorry for short notice but I figured some of us just met on PTG and where
still traveling back in last several days and would appreciate getting the
hour back to settle pending post PTG items.

This week I will work with PTG participants on producing a detailed report
on the event where it touched our topic. We will share the report with the
team in due course.

We will have the next meeting in a week.

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

Re: [openstack-dev] [Fuel] Nominating Alexander Kislitsky for fuel-web-core

[Alexander Kislitsky]

Thank you!

On Mon, Feb 27, 2017 at 1:29 PM, Ihor Kalnytskyi 
wrote:

> I'm pleased to welcome Alexander to the fuel-web core team!
>
> https://review.openstack.org/#/admin/groups/664,members
>
> On Wed, Feb 22, 2017 at 10:40 AM, Fedor Zhadaev 
> wrote:
> > +1
> >
> > On Wed, Feb 22, 2017 at 12:36 AM Булат Гайфуллин 
> > wrote:
> >>
> >> +1
> >>
> >> 2017-02-21 17:01 GMT+03:00 Alexey Shtokolov :
> >>>
> >>> Hey fellow fuelers,
> >>>
> >>> I'd like to nominate Alexander Kislitsky to the fuel-web-core team.
> >>> He's doing thorough review [1], participate in feature developments
> >>> (e.g. Config-DB enhancements, network-manager performance
> >>> improvements) and made an outstanding contribution bug-fixing.
> >>>
> >>> Core reviewers, please reply back with +1/-1.
> >>>
> >>> Thanks,
> >>> Ihor
> >>>
> >>> [1] http://stackalytics.com/?release=ocata&module=fuel-web
> >>>
> >>>
> >>> 
> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> openstack-dev-requ...@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-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > --
> > Fedor Zhadaev
> > email: fzhad...@mirantis.com
> > skype: zhadaevfm
> > IRC: fzhadaev
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA] Pike PTG Summary

[Andrea Frittoli]

Hi everyone,

thanks to everyone who joined the QA track, hands-on session and
discussions at the first PTG in Atlanta.
I think it was a very productive week, it was great to meet so many of you
in person.
We also received a lot of feedback from the community [0].

The list of sessions is available at [1].
The list of priorities for the QA team during the Pike cycle is available
at [2].

Below a summary of the areas we will be working on during Pike.
This is not an exhaustive list of all the topics we discussed at the PTG,
see the session etherpads [1] for more.

Andrea

Tempest Stable Interfaces


Credential providers are widely used in Tempest plugins [3], so they're top
of the list in migrating to stable interfaces.
Tempest test base class is used by more than 45 different repos [3], so
after as little as possible rework we will declare that class "as-is" a
stable interface for plugins.
Other items planned to stable interfaces are: swift service client, waiters
and potentially scenario helper methods.

Tempest Plugins
=

We discussed about Tempest plugins and the proposed goal [4] to maintain
them in branchless repos.
We clarified the implications of hosting the plugin in a branched repo / in
the project repo [5].

Documentation


One recurring items in the feedback was documentation. We will be working
on generating documentation from all Tempest stable interfaces, and to add
examples in there. We will enrich the documentation about writing plugins
and contributing tests as well.

Scenario Tests
===

Scenario tests have a long due refactor to be done, so we'll work on it
during Pike.
We will be trying to make the process as smooth as possible for teams that
depend on scenario test base classes today.

Policy Testing - Patrole
=

During the Ocata cycle we introduced a new QA framework - Patrole [6] - for
policy testing.
It's already discovered some inconsistencies in error codes, which is good
news.
We have a lot of work planned on Patrole for the Pike cycle:
- setup CI gates
- make Patrole portable - similar to Tempest - so that it may be used to
test existing deployments (public / private clouds)
- define Patrole interfaces for plugins

Schema Validation
==

We plan to extend schema validation in Tempest to the six projects hosted
there.
Plugins are encouraged to implement schema validation for the service they
represent as well. No additional plugin interfaces are required for this.

Microversion Testing


We will stick to the current plan of updating micro version schemas in
Tempest only when needed.
However we will monitor drift between implemented versions and tested ones,
and we will make sure we fill the gap at least at the end of each cycle.

Grenade and Upgrade Testing
===

The current implementation of upgrade testing in Grenade provides a great
service in our gates.
However it is not meant to fit more complex testing scenarios such as
rolling upgrade, zero-downtime testing, validation using custom topologies
and cross project upgrade dependencies.
We will investigate synergies with other projects to deploy topologies
which are interesting for rolling upgrades, as well as for orchestrating
the upgrade process itself, while keeping the existing upgrade test
strategy available and stable via Grenade.

HA / Destructive Testing
==

Interest on automated HA / Destructive testing has revived - see the email
thread [7].
Starting with a third party CI service may be a good approach to asses the
potential of this for upstream testing.

[0] https://etherpad.openstack.org/p/qa-ptg-pike-community-input
[1] https://etherpad.openstack.org/p/qa-ptg-pike
[2] https://etherpad.openstack.org/p/pike-qa-priorities
[3] http://imgur.com/KDFeAf6
[4] https://review.openstack.org/#/c/369749/
[5] https://etherpad.openstack.org/p/qa-ptg-pike-tempest-plugins
[6] https://github.com/openstack/patrole
[7]
http://lists.openstack.org/pipermail/openstack-dev/2017-February/112848.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tricircle]reschedule the weekly meeting

[joehuang]

Hello,

Currently the Tricircle weekly meeting is held regularly at UTC 13:00~14:00 
every Wednesday, it's not convenient for contributors from USA.

The available time slots could be found at
https://docs.google.com/spreadsheets/d/1lQHKCQa4wQmnWpTMB3DLltY81kIChZumHLHzoMNF07c/edit#gid=0

Other contributors are mostly from East Asia, the time zone is around 
UTC+8/UTC+9.

Please propose some your preferred time slots, and then let's have a poll for 
the new weekly meeting time.

Best Regards
Chaoyi Huang (joehuang)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] [nova] keystonauth catalog work arounds hiding transition issues

[Sean Dague]

We recently implemented a Nova feature around validating that project_id
for quotas we real in keystone. After that merged, trippleo builds
started to fail because their undercloud did not specify the 'identity'
service as the unversioned endpoint.

https://github.com/openstack/nova/blob/8b498ce199ac4acd94eb33a7f47c05ee0c743c34/nova/api/openstack/identity.py#L34-L36
- (code merged in Nova).

After some debug, it was clear that '/v2.0/v3/projects/...' was what was
being called. And after lots of conferring in the Keystone room, we
definitely made sure that the code in question was correct. The thing I
wanted to do was make the failure more clear.

The suggestion was made to use the following code approach:

https://review.openstack.org/#/c/438049/6/nova/api/openstack/identity.py

resp = sess.get('/projects/%s' % project_id,
endpoint_filter={
'service_type': 'identity',
'version': (3, 0)
},
raise_exc=False)


However, I tested that manually with an identity =>
http:///v2.0 endpoint, and it passes. Which confused me.

Until I found this -
https://github.com/openstack/keystoneauth/blob/3364703d3b0e529f7c1b7d1d8ea81726c4f5f121/keystoneauth1/discover.py#L313

keystonauth is specifically coding around the keystone transition from a
versioned /v2.0 endpoint to an unversioned one.


While that is good for the python ecosystem using it, it's actually
*quite* bad for the rest of our ecosystem (direct REST, java, ruby, go,
js, php), because it means that all other facilities need the same work
around. I actually wonder if this is one of the in the field reasons for
why the transition from v2 -> v3 is going slow. That's actually going to
potentially break a lot of software.

It feels like this whole discovery version hack bit should be removed -
https://review.openstack.org/#/c/438483/. It also feels like a migration
path for non python software in changing the catalog entries needs to be
figured out as well.

I think on the Nova side we need to go back to looking for bogus
endpoint because we don't want issues like this hidden from us.

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [murano]

[MONTEIRO, FELIPE C]

Hi everyone,

Currently two of our gates are breaking and so everything is blocked until we 
resolve the issues with them.

I have introduced to patches for Murano [0] and Murano Dashboard [1]. Please 
review these patches so that we can unblock all other patches that are 
currently failing because of the recent changes and bugs mentioned in the 
commit messages for these patches.

[0] https://review.openstack.org/#/c/437687/
[1] https://review.openstack.org/#/c/437671/

Thank You,
Felipe Monteiro

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

[openstack-dev] [packaging] Openstack packaged on Gentoo

[Matthew Thode]

After a short delay for reasons Openstack is now up to date on Gentoo.
Just `emerge =sys-cluster/openstack-meta-2017.1.` with your desired
use flags to pull in the head of the services stable branches and their
dependencies.

-- 
Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Matt Riedemann]

On 2/26/2017 11:25 PM, Clint Byrum wrote:


You have taken the folder approach, and that is a bit less complicated
to set up than sup+offlineimap, but still does require that you know
how to filter by tag. It also means that you are experiencing one of
the problems with cross posting whenever anybody adds a tag, as in
that setup each message is duplicated into each folder, or you have a
'first match' sieve and then tag order becomes significant. Either way,
you have to flip back and forth to read a thread. Or maybe somebody has
an answer? Nobody in the room at the SWG session had one.



I don't have the problem you're describing here. I've got a gmail 
account but I use Thunderbird for my mail client since filtering and 
foldering the dev ML in gmail is a nightmare, at least since I was 
already used to Thunderbird for another IMAP account already.


So yeah I've got lots of folders, and filters, but have sorted my 
filters such that the projects I care about the most get priority. So if 
there is a thread with several project tags on it, like the one you did 
for the nova-compute API session at the PTG, that still all just goes 
into my nova folder since that's priority #1 in my sort list in Thunderbird.


Over the years I tried to keep up with new folders for new 
tags/projects, but with the big tent that got impossible, so now I 
basically filter into folders the projects I really care about being on 
top of, and then the rest just goes into my default "openstack-dev" 
folder. If I find that I'm constantly missing something with a given 
tag, then I start filtering that into a new folder that's prioritized 
higher.


--

Thanks,

Matt Riedemann

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

Re: [openstack-dev] [packaging] Openstack packaged on Gentoo

[Nicolas Bock]

On Mon, Feb 27, 2017 at 08:44:30AM -0600, Matthew Thode wrote:

After a short delay for reasons Openstack is now up to date on Gentoo.
Just `emerge =sys-cluster/openstack-meta-2017.1.` with your desired
use flags to pull in the head of the services stable branches and their
dependencies.


Thanks!


--
Matthew Thode (prometheanfire)



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

Re: [openstack-dev] [keystone] [nova] keystonauth catalog work arounds hiding transition issues

[Sean Dague]

On 02/27/2017 10:22 AM, Morgan Fainberg wrote:

> I agree we should kill the discovery hack, however that is a break in
> the keystoneauth contract. Simply put, we cannot. Keystoneauth is one of
> the few things (similar to how shade works) where behavior, exposed
> elements, etc are considered a strict contract that will not change. If
> we could have avoided stevedore and PBR we would have.
> 
> The best we can provide is a way to build the instances from
> keystoneauth that does not include that hack.
> 
> The short is, we can't remove it. Similar to how we cannot change the
> raise of exceptions for non-200 responses (the behavior is already encoded).

Ok, I'm going to go back to not using the version= parameter then.
Because it's not actually doing the right thing.

I also am a bit concerned that basically through some client changes
that people didn't understand, we've missed a break in the upstream
transition that will impact real clouds. :(

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [horizon] PTG Summary

[Rob Cresswell]

Hi everyone!

Quick summary of the PTG for those who missed it. Here's the etherpad, with 
notes inline: https://etherpad.openstack.org/p/horizon-ptg-pike

We spent the first morning discussing plugins, with several plugin devs 
dropping in to discuss their issues. Several issues were mentioned that Horizon 
needs to improve upon to help the plugins:

- Functional testing for JS
- Extensible quotas
- Use [horizon-plugin] mailer tag to keep people up to date

Further specifics can be found in the etherpad notes.

The afternoon and following morning were spent analysing specific blueprints, 
and then doing a general blueprint review. This has resulted in a really 
refined blueprint list: https://blueprints.launchpad.net/horizon, which we'll 
be using in place of a priorities etherpad this cycle. That's right, tracking 
tools actually being used for tracking. Huzzah!

If there are any disagreements on blueprints, or you feel I have closed 
something unfairly, please get in touch on IRC (robcresswell) or email me.

Two other cross project sessions are also linked in the etherpad; one with 
keystone and another with i18n. These were really helpful in understanding how 
Horizon can work better with these projects. Please review the etherpads to see 
what work needs to be done.

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

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Sylvain Bauza]

Le 27/02/2017 15:50, Matt Riedemann a écrit :
> On 2/26/2017 11:25 PM, Clint Byrum wrote:
>>
>> You have taken the folder approach, and that is a bit less complicated
>> to set up than sup+offlineimap, but still does require that you know
>> how to filter by tag. It also means that you are experiencing one of
>> the problems with cross posting whenever anybody adds a tag, as in
>> that setup each message is duplicated into each folder, or you have a
>> 'first match' sieve and then tag order becomes significant. Either way,
>> you have to flip back and forth to read a thread. Or maybe somebody has
>> an answer? Nobody in the room at the SWG session had one.
>>
> 
> I don't have the problem you're describing here. I've got a gmail
> account but I use Thunderbird for my mail client since filtering and
> foldering the dev ML in gmail is a nightmare, at least since I was
> already used to Thunderbird for another IMAP account already.
> 
> So yeah I've got lots of folders, and filters, but have sorted my
> filters such that the projects I care about the most get priority. So if
> there is a thread with several project tags on it, like the one you did
> for the nova-compute API session at the PTG, that still all just goes
> into my nova folder since that's priority #1 in my sort list in
> Thunderbird.
> 
> Over the years I tried to keep up with new folders for new
> tags/projects, but with the big tent that got impossible, so now I
> basically filter into folders the projects I really care about being on
> top of, and then the rest just goes into my default "openstack-dev"
> folder. If I find that I'm constantly missing something with a given
> tag, then I start filtering that into a new folder that's prioritized
> higher.
> 

FWIW, I use my internal mail server for tagging the emails having a
X-Topics value for the ones I want (eg. tagging "nova" for an email
having X-Topics: nova, or tagging "cross" for an email having X-Topics:
release).

Then, I'm adding the same tag in Thunderbird (each one having different
color) and magically, the list is having many colors ! \o/


Honestly, I don't understand why we should silo all our conversations
because X or Y. Once, I was also a newcomer, and the ML was already
difficult to follow. Sure, but then I used filters and wow, magically,
it worked for me !

-Sylvain
(and please, *do not* Slack)

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

Re: [openstack-dev] [nova] Device tagging: rebuild config drive upon instance reboot to refresh metadata on it

[Artom Lifshitz]

>  - virtio-vsock - think of this as UNIX domain sockets between the host and
>guest.  This is to deal with the valid use case of people wanting to use
>a network protocol, but not wanting an real NIC exposed to the guest/host
>for security concerns. As such I think it'd be useful to run the metadata
>service over virtio-vsock as an option. It'd likely address at lesat some
>people's security concerns wrt metadata service. It would also fix the
>ability to use the metadat service in IPv6-only environments, as we would
>not be using IP at all :-)

Is this currently exposed by libvirt? I had a look at [1] and couldn't
find any mention of 'vsock' or anything that resembles what you've
described.

[1] https://libvirt.org/formatdomain.html

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

Re: [openstack-dev] [keystone] [nova] keystonauth catalog work arounds hiding transition issues

[Morgan Fainberg]

On Mon, Feb 27, 2017 at 5:56 AM, Sean Dague  wrote:

> We recently implemented a Nova feature around validating that project_id
> for quotas we real in keystone. After that merged, trippleo builds
> started to fail because their undercloud did not specify the 'identity'
> service as the unversioned endpoint.
>
> https://github.com/openstack/nova/blob/8b498ce199ac4acd94eb33a7f47c05
> ee0c743c34/nova/api/openstack/identity.py#L34-L36
> - (code merged in Nova).
>
> After some debug, it was clear that '/v2.0/v3/projects/...' was what was
> being called. And after lots of conferring in the Keystone room, we
> definitely made sure that the code in question was correct. The thing I
> wanted to do was make the failure more clear.
>
> The suggestion was made to use the following code approach:
>
> https://review.openstack.org/#/c/438049/6/nova/api/openstack/identity.py
>
> resp = sess.get('/projects/%s' % project_id,
> endpoint_filter={
> 'service_type': 'identity',
> 'version': (3, 0)
> },
> raise_exc=False)
>
>
> However, I tested that manually with an identity =>
> http:///v2.0 endpoint, and it passes. Which confused me.
>
> Until I found this -
> https://github.com/openstack/keystoneauth/blob/
> 3364703d3b0e529f7c1b7d1d8ea81726c4f5f121/keystoneauth1/discover.py#L313
>
> keystonauth is specifically coding around the keystone transition from a
> versioned /v2.0 endpoint to an unversioned one.
>
>
> While that is good for the python ecosystem using it, it's actually
> *quite* bad for the rest of our ecosystem (direct REST, java, ruby, go,
> js, php), because it means that all other facilities need the same work
> around. I actually wonder if this is one of the in the field reasons for
> why the transition from v2 -> v3 is going slow. That's actually going to
> potentially break a lot of software.
>
> It feels like this whole discovery version hack bit should be removed -
> https://review.openstack.org/#/c/438483/. It also feels like a migration
> path for non python software in changing the catalog entries needs to be
> figured out as well.
>
> I think on the Nova side we need to go back to looking for bogus
> endpoint because we don't want issues like this hidden from us.
>
>
I agree we should kill the discovery hack, however that is a break in the
keystoneauth contract. Simply put, we cannot. Keystoneauth is one of the
few things (similar to how shade works) where behavior, exposed elements,
etc are considered a strict contract that will not change. If we could have
avoided stevedore and PBR we would have.

The best we can provide is a way to build the instances from keystoneauth
that does not include that hack.

The short is, we can't remove it. Similar to how we cannot change the raise
of exceptions for non-200 responses (the behavior is already encoded).

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

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Dean Troyer]

On Mon, Feb 27, 2017 at 3:31 AM, Clint Byrum  wrote:
> This is not for users who only want to see some projects. That is a well
> understood space and the mailman filtering does handle it. This is for
> those who want to monitor the overall health of the community, address
> issues with cross-project specs, or participate in so many projects it
> makes little sense to spend time filtering.

Monday morning and the caffiene is just beginning to reach my brain,
but this seems counter-intuitive to me.  I consider myself someone who
_does_ want to keep in touch with the majority of the community, and
breaking things into N additional mailing lists makes that harder, not
easier.  I _do_ include core team updates, mascots, social meetings in
that set of things to pay a little attention to here, especially
around summit/PTG/Forum/etc times.

I've seen a couple of descriptions of who this proposal is not
intended to address, who exactly is expected to benefit from more
mailing lists?

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [nova] Device tagging: rebuild config drive upon instance reboot to refresh metadata on it

[Daniel P. Berrange]

On Mon, Feb 27, 2017 at 10:30:33AM -0500, Artom Lifshitz wrote:
> >  - virtio-vsock - think of this as UNIX domain sockets between the host and
> >guest.  This is to deal with the valid use case of people wanting to use
> >a network protocol, but not wanting an real NIC exposed to the guest/host
> >for security concerns. As such I think it'd be useful to run the metadata
> >service over virtio-vsock as an option. It'd likely address at lesat some
> >people's security concerns wrt metadata service. It would also fix the
> >ability to use the metadat service in IPv6-only environments, as we would
> >not be using IP at all :-)
> 
> Is this currently exposed by libvirt? I had a look at [1] and couldn't
> find any mention of 'vsock' or anything that resembles what you've
> described.

Not yet. The basic QEMU feature merged in 2.8.0, but we're still wiring
up varous bits of userspace. eg selinux-policy, libvirt, nfs server, and
so on to understand vsock

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

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

Re: [openstack-dev] [keystone] [nova] keystonauth catalog work arounds hiding transition issues

[Morgan Fainberg]

On Mon, Feb 27, 2017 at 7:26 AM, Sean Dague  wrote:

> On 02/27/2017 10:22 AM, Morgan Fainberg wrote:
> 
> > I agree we should kill the discovery hack, however that is a break in
> > the keystoneauth contract. Simply put, we cannot. Keystoneauth is one of
> > the few things (similar to how shade works) where behavior, exposed
> > elements, etc are considered a strict contract that will not change. If
> > we could have avoided stevedore and PBR we would have.
> >
> > The best we can provide is a way to build the instances from
> > keystoneauth that does not include that hack.
> >
> > The short is, we can't remove it. Similar to how we cannot change the
> > raise of exceptions for non-200 responses (the behavior is already
> encoded).
>
> Ok, I'm going to go back to not using the version= parameter then.
> Because it's not actually doing the right thing.
>
> I also am a bit concerned that basically through some client changes
> that people didn't understand, we've missed a break in the upstream
> transition that will impact real clouds. :(
>
>
We can make an adapter that does what you want (requests adapters are
cool). I was just chatting with Monty about this, and we can help you out
on this front.

The adapter should make things a lot easier once the lifting is done.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements] Managing project requirements

[Jeremy Stanley]

On 2017-02-27 11:42:22 +0100 (+0100), Andreas Scheuring wrote:
> Thanks all for your feedback. Seeing things much clearer now.
> 
> One last thing: How is the requirements bot being triggered?
> 
> - For OpenStack libraries by the jenkins job that handles the tag
> (if the metadata is provided)?

Yes, new releases through our CI of libraries we maintain directly
propose updates for their particular entries into the constraints
list if they have any (which is presently sometimes painful due to
merge-conflict between one another and so discussion is underway as
to how to potentially batch or stack them).

> - for external libraries? Is the a cronjob every 2 weeks or so? Or
> is it even daily except during the requirements freeze?

General constraints updates are proposed daily to catch entries
corresponding to libraries released outside of our CI. If a branch
is frozen pending release, those proposals usually won't be merged
unless there's a very good reason to do so.

Separate from constraints, any time a change merges to the global
requirements list a job is immediately triggered to propose
corresponding updates to individual requirements.txt,
test-requirements.txt and setup.py files for any participating repos
which require them.

You may also want to give
https://docs.openstack.org/developer/requirements/ a quick read as
it goes into greater detail on many of these topics.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [keystone] [nova] keystonauth catalog work arounds hiding transition issues

[Monty Taylor]

On 02/27/2017 09:36 AM, Morgan Fainberg wrote:
> 
> 
> On Mon, Feb 27, 2017 at 7:26 AM, Sean Dague  > wrote:
> 
> On 02/27/2017 10:22 AM, Morgan Fainberg wrote:
> 
> > I agree we should kill the discovery hack, however that is a break in
> > the keystoneauth contract. Simply put, we cannot. Keystoneauth is one of
> > the few things (similar to how shade works) where behavior, exposed
> > elements, etc are considered a strict contract that will not change. If
> > we could have avoided stevedore and PBR we would have.
> >
> > The best we can provide is a way to build the instances from
> > keystoneauth that does not include that hack.
> >
> > The short is, we can't remove it. Similar to how we cannot change the
> > raise of exceptions for non-200 responses (the behavior is already 
> encoded).
> 
> Ok, I'm going to go back to not using the version= parameter then.
> Because it's not actually doing the right thing.
> 
> I also am a bit concerned that basically through some client changes
> that people didn't understand, we've missed a break in the upstream
> transition that will impact real clouds. :(
> 
> 
> We can make an adapter that does what you want (requests adapters are
> cool). I was just chatting with Monty about this, and we can help you
> out on this front.
> 
> The adapter should make things a lot easier once the lifting is done. 

Yah. Consider me to be on this. Looking at the code you've got to make
intra-openstack rest calls makes me want to poke out my own eyeballs. It
does _not_ have to be this hard or this brittle.

It'll likely take a few days and a thing or two to unwind.


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

Re: [openstack-dev] [keystone] [nova] keystonauth catalog work arounds hiding transition issues

[Sean Dague]

On 02/27/2017 10:49 AM, Monty Taylor wrote:
> On 02/27/2017 09:36 AM, Morgan Fainberg wrote:
>>
>>
>> On Mon, Feb 27, 2017 at 7:26 AM, Sean Dague > > wrote:
>>
>> On 02/27/2017 10:22 AM, Morgan Fainberg wrote:
>> 
>> > I agree we should kill the discovery hack, however that is a break in
>> > the keystoneauth contract. Simply put, we cannot. Keystoneauth is one 
>> of
>> > the few things (similar to how shade works) where behavior, exposed
>> > elements, etc are considered a strict contract that will not change. If
>> > we could have avoided stevedore and PBR we would have.
>> >
>> > The best we can provide is a way to build the instances from
>> > keystoneauth that does not include that hack.
>> >
>> > The short is, we can't remove it. Similar to how we cannot change the
>> > raise of exceptions for non-200 responses (the behavior is already 
>> encoded).
>>
>> Ok, I'm going to go back to not using the version= parameter then.
>> Because it's not actually doing the right thing.
>>
>> I also am a bit concerned that basically through some client changes
>> that people didn't understand, we've missed a break in the upstream
>> transition that will impact real clouds. :(
>>
>>
>> We can make an adapter that does what you want (requests adapters are
>> cool). I was just chatting with Monty about this, and we can help you
>> out on this front.
>>
>> The adapter should make things a lot easier once the lifting is done. 
> 
> Yah. Consider me to be on this. Looking at the code you've got to make
> intra-openstack rest calls makes me want to poke out my own eyeballs. It
> does _not_ have to be this hard or this brittle.
> 
> It'll likely take a few days and a thing or two to unwind.

I'm definitely happy if there are better ways to do it.

But, I'm also concerned about the bigger picture. I thought keystoneauth
was giving a pretty low level REST interface, which is good, because it
means we can use and think about the services as they are documented in
the api-ref.

However, when there is magic applied it means that stops being true. And
now folks think the APIs work like the magic works, not realizing it's
all client side magic, and when they try to do this in node next month,
it will all fall apart.

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [tc][swg] Summary - Atlanta PTG Stewardship Working Group Session

[Colette Alexander]

Hi everyone!

I thought I'd send a summary of the Stewardship Working Group activities
from our time at the PTG this past week to the list to add voices to our
discussions, and start the work of organizing our work for the next cycle.

The SWG had a room to ourselves for all of Monday, which was the same day
that many other cross-project sessions had to get their work done. Because
we knew the vibe would be more of a drop-in and check-things-out in between
other sessions, we prepared for collecting feedback with a bunch of
question prompts, and post-its and sharpies available for anyone who
dropped in to reply to questions quickly, and stick around and discuss if
they wanted.

The questions:
1. What do you love?
2. What should we fix?
3. What bothers you?
4. Questions?

For most of the morning we had quite a few people sticking around to talk
about subjects in the community and problems they wanted to see addressed.
That conversation also generated a lot of post-its on the "wall of
questions" as it progressed. The end result we ended up affinity mapping
towards the end of the afternoon, and then I ended up transcribing that
fully at the bottom of our session's etherpad as best as I could.[0] I
cross-mapped some things if they seemed to align with things in other
areas, and I'll continue to do that between now and the next SWG meeting.

Based on previous discussions with the group, it's highly likely that most
or all of these items will end up forming the SWG's work backlog in the
next 3-6 months.

I'd like to extend a special thanks to everyone who dropped in and gave
feedback, and especially to those who came by late in the afternoon to help
with affinity mapping everything.

If you attended part of the session, I'd love to hear your feedback here,
and see you in the #openstack-swg channel and at the next SWG meeting, on
March 2nd at 1400 UTC. I know we have some folks interested who live on the
west coast of the US, so one of our agenda items this week will be to
discuss moving the meeting a little to accommodate that time zone.

If you couldn't attend the PTG, but are interested in contributing feedback
here (or in-channel, or at the meeting) we definitely need you! Let us know
what you think the SWG and TC can do to help improve OpenStack!

Sincerely,

colette/gothicmindfood

[0] https://etherpad.openstack.org/p/AtlantaPTG-SWG
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [deployment][TripleO][kolla][ansible][fuel] Next steps for cross project collaboration

[Steven Hardy]

Hi all,

Over the recent PTG, and previously at the design summit in Barcelona,
we've had some productive cross-project discussions amongst the various
deployment teams.

It's clear that we share many common problems, such as patterns for major
version upgrades (even if the workflow isn't identical we've all duplicated
effort e.g around basic nova upgrade workflow recently), container images
and other common building blocks for configuration management.

Here's a non-exhaustive list of sessions where we had some good
cross-project discussion, and agreed a number of common problems where
collaboration may be possible:

https://etherpad.openstack.org/p/ansible-config-mgt

https://etherpad.openstack.org/p/tripleo-kolla-kubernetes

https://etherpad.openstack.org/p/kolla-pike-ptg-images

https://etherpad.openstack.org/p/fuel-ocata-fuel-tripleo-integration

If there is interest in continuing the discussions on a more regular basis,
I'd like to propose we start a cross-project working group:

https://wiki.openstack.org/wiki/Category:Working_Groups

If I go ahead and do this is "deployment" a sufficiently project-neutral
term to proceed with?

I'd suggest we start with an informal WG, which it seems just requires an
update to the wiki, e.g no need for any formal project team at this point?

Likewise I know some folks have expressed an interest in an IRC channel
(openstack-deployment?), I'm happy to start with the ML but open to IRC
also if someone is willing to set up the channel.

Perhaps we can start by using the tag "deployment" in all cross-project ML
traffic, then potentially discuss IRC (or even regular meetings) if it
becomes apparrent these would add value beyond ML discussion?

Please follow up here if anyone has other/better ideas on how to facilitate
ongoing cross-team discussion and I'll do my best to help move things
forward.

Thanks!

Steve

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

Re: [openstack-dev] [deployment][TripleO][kolla][ansible][fuel] Next steps for cross project collaboration

[Emilien Macchi]

On Mon, Feb 27, 2017 at 11:02 AM, Steven Hardy  wrote:
> Hi all,
>
> Over the recent PTG, and previously at the design summit in Barcelona,
> we've had some productive cross-project discussions amongst the various
> deployment teams.
>
> It's clear that we share many common problems, such as patterns for major
> version upgrades (even if the workflow isn't identical we've all duplicated
> effort e.g around basic nova upgrade workflow recently), container images
> and other common building blocks for configuration management.
>
> Here's a non-exhaustive list of sessions where we had some good
> cross-project discussion, and agreed a number of common problems where
> collaboration may be possible:
>
> https://etherpad.openstack.org/p/ansible-config-mgt

first action: EmilienM + bnemec to write a spec in oslo.config that
aims to generate a file (YAML or JSON) with all parameters.

> https://etherpad.openstack.org/p/tripleo-kolla-kubernetes
>
> https://etherpad.openstack.org/p/kolla-pike-ptg-images
>
> https://etherpad.openstack.org/p/fuel-ocata-fuel-tripleo-integration
>
> If there is interest in continuing the discussions on a more regular basis,
> I'd like to propose we start a cross-project working group:
>
> https://wiki.openstack.org/wiki/Category:Working_Groups
>
> If I go ahead and do this is "deployment" a sufficiently project-neutral
> term to proceed with?

Yes, +1 for Deployment WG. It's pretty clear that we saw more interest
than before at the last PTG in Atlanta. It's time to do concrete
things :-)

> I'd suggest we start with an informal WG, which it seems just requires an
> update to the wiki, e.g no need for any formal project team at this point?
>
> Likewise I know some folks have expressed an interest in an IRC channel
> (openstack-deployment?), I'm happy to start with the ML but open to IRC
> also if someone is willing to set up the channel.

+1 for IRC channel.

> Perhaps we can start by using the tag "deployment" in all cross-project ML
> traffic, then potentially discuss IRC (or even regular meetings) if it
> becomes apparrent these would add value beyond ML discussion?

+1 too.

> Please follow up here if anyone has other/better ideas on how to facilitate
> ongoing cross-team discussion and I'll do my best to help move things
> forward.

Thanks for kicking it off!

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



-- 
Emilien Macchi

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

Re: [openstack-dev] [deployment][TripleO][kolla][ansible][fuel] Next steps for cross project collaboration

[Steven Dake]

comments inline.

On Mon, Feb 27, 2017 at 9:02 AM, Steven Hardy  wrote:

> Hi all,
>
> Over the recent PTG, and previously at the design summit in Barcelona,
> we've had some productive cross-project discussions amongst the various
> deployment teams.
>
> It's clear that we share many common problems, such as patterns for major
> version upgrades (even if the workflow isn't identical we've all duplicated
> effort e.g around basic nova upgrade workflow recently), container images
> and other common building blocks for configuration management.
>
> Here's a non-exhaustive list of sessions where we had some good
> cross-project discussion, and agreed a number of common problems where
> collaboration may be possible:
>
> https://etherpad.openstack.org/p/ansible-config-mgt
>
> https://etherpad.openstack.org/p/tripleo-kolla-kubernetes
>
> https://etherpad.openstack.org/p/kolla-pike-ptg-images
>
> https://etherpad.openstack.org/p/fuel-ocata-fuel-tripleo-integration
>
> If there is interest in continuing the discussions on a more regular basis,
> I'd like to propose we start a cross-project working group:
>
> https://wiki.openstack.org/wiki/Category:Working_Groups
>
> If I go ahead and do this is "deployment" a sufficiently project-neutral
> term to proceed with?
>
>
WFM.  Anything longer such as "openstack-deployment-tools" doesn't show up
very well in IRC clients.  Forgive the bikeshedding;
"openstack-deploy-tools" is very project-neutral and shows up well in IRC
clients.


> I'd suggest we start with an informal WG, which it seems just requires an
> update to the wiki, e.g no need for any formal project team at this point?
>
>
WFM.  Since we aren't really a project team but a collection of projects
working together, I don't think we need further formalization.


> Likewise I know some folks have expressed an interest in an IRC channel
> (openstack-deployment?), I'm happy to start with the ML but open to IRC
> also if someone is willing to set up the channel.
>
>
+1 - I think an IRC channel would be the best way for real time
communication.


> Perhaps we can start by using the tag "deployment" in all cross-project ML
> traffic, then potentially discuss IRC (or even regular meetings) if it
> becomes apparrent these would add value beyond ML discussion?
>
>
[deploy-tools] may be better unless that breaks people's email clients.

I am out of bandwidth personally for meetings, although others may be
interested in a meeting.  I'm not sure what value a regular meeting would
have and would need a chair, which may result in an inability to obtain
neutral ground.

IMO IRC and ML would be sufficient for this CP effort, however others may
have different viewpoints.


> Please follow up here if anyone has other/better ideas on how to facilitate
> ongoing cross-team discussion and I'll do my best to help move things
> forward.
>
>
Sounds good to me.  Waiting 3 months to see everyone face to face to
discuss cross-project deployment tool collaboration doesn't seem ideal.


> Thanks!
>
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [deployment][TripleO][kolla][ansible][fuel][openstack-ansible] Next steps for cross project collaboration

[Steven Hardy]

Adding openstack-ansible to the subject tags (apologies, sdake pointed out
I got that wrong in the initial mail, here's the top of this thread):

http://lists.openstack.org/pipermail/openstack-dev/2017-February/112960.html

On Mon, Feb 27, 2017 at 04:02:54PM +, Steven Hardy wrote:
> Hi all,
> 
> Over the recent PTG, and previously at the design summit in Barcelona,
> we've had some productive cross-project discussions amongst the various
> deployment teams.
> 
> It's clear that we share many common problems, such as patterns for major
> version upgrades (even if the workflow isn't identical we've all duplicated
> effort e.g around basic nova upgrade workflow recently), container images
> and other common building blocks for configuration management.
> 
> Here's a non-exhaustive list of sessions where we had some good
> cross-project discussion, and agreed a number of common problems where
> collaboration may be possible:
> 
> https://etherpad.openstack.org/p/ansible-config-mgt
> 
> https://etherpad.openstack.org/p/tripleo-kolla-kubernetes
> 
> https://etherpad.openstack.org/p/kolla-pike-ptg-images
> 
> https://etherpad.openstack.org/p/fuel-ocata-fuel-tripleo-integration
> 
> If there is interest in continuing the discussions on a more regular basis,
> I'd like to propose we start a cross-project working group:
> 
> https://wiki.openstack.org/wiki/Category:Working_Groups
> 
> If I go ahead and do this is "deployment" a sufficiently project-neutral
> term to proceed with?
> 
> I'd suggest we start with an informal WG, which it seems just requires an
> update to the wiki, e.g no need for any formal project team at this point?
> 
> Likewise I know some folks have expressed an interest in an IRC channel
> (openstack-deployment?), I'm happy to start with the ML but open to IRC
> also if someone is willing to set up the channel.
> 
> Perhaps we can start by using the tag "deployment" in all cross-project ML
> traffic, then potentially discuss IRC (or even regular meetings) if it
> becomes apparrent these would add value beyond ML discussion?
> 
> Please follow up here if anyone has other/better ideas on how to facilitate
> ongoing cross-team discussion and I'll do my best to help move things
> forward.
> 
> Thanks!
> 
> Steve
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Steve Hardy
Red Hat Engineering, Cloud

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

[openstack-dev] [oslo][all] Oslo weekly meeting time poll request

[ChangBo Guo]

We discussed the Oslo weekly time during the PTG, current time slot UTC
16:00 is not good for folks from Asian, so wonder if we can try to figure
out another time candidate, please  vote on
https://framadate.org/9Q15UYR19fzdqhol  and add comments if all of
candidates don't work well for you .

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

Re: [openstack-dev] [deployment][TripleO][kolla][ansible][fuel] Next steps for cross project collaboration

[Steven Hardy]

On Mon, Feb 27, 2017 at 09:25:46AM -0700, Steven Dake wrote:
>comments inline.
>On Mon, Feb 27, 2017 at 9:02 AM, Steven Hardy  wrote:
> 
>  Hi all,
> 
>  Over the recent PTG, and previously at the design summit in Barcelona,
>  we've had some productive cross-project discussions amongst the various
>  deployment teams.
> 
>  It's clear that we share many common problems, such as patterns for
>  major
>  version upgrades (even if the workflow isn't identical we've all
>  duplicated
>  effort e.g around basic nova upgrade workflow recently), container
>  images
>  and other common building blocks for configuration management.
> 
>  Here's a non-exhaustive list of sessions where we had some good
>  cross-project discussion, and agreed a number of common problems where
>  collaboration may be possible:
> 
>  https://etherpad.openstack.org/p/ansible-config-mgt
> 
>  https://etherpad.openstack.org/p/tripleo-kolla-kubernetes
> 
>  https://etherpad.openstack.org/p/kolla-pike-ptg-images
> 
>  https://etherpad.openstack.org/p/fuel-ocata-fuel-tripleo-integration
> 
>  If there is interest in continuing the discussions on a more regular
>  basis,
>  I'd like to propose we start a cross-project working group:
> 
>  https://wiki.openstack.org/wiki/Category:Working_Groups
> 
>  If I go ahead and do this is "deployment" a sufficiently project-neutral
>  term to proceed with?
> 
>WFM.  Anything longer such as "openstack-deployment-tools" doesn't show
>up very well in IRC clients.  Forgive the bikeshedding;
>"openstack-deploy-tools" is very project-neutral and shows up well in IRC
>clients.
> 
> 
>  I'd suggest we start with an informal WG, which it seems just requires
>  an
>  update to the wiki, e.g no need for any formal project team at this
>  point?
> 
>WFM.  Since we aren't really a project team but a collection of projects
>working together, I don't think we need further formalization.
> 
> 
>  Likewise I know some folks have expressed an interest in an IRC channel
>  (openstack-deployment?), I'm happy to start with the ML but open to IRC
>  also if someone is willing to set up the channel.
> 
>+1 - I think an IRC channel would be the best way for real time
>communication.
> 
> 
>  Perhaps we can start by using the tag "deployment" in all cross-project
>  ML
>  traffic, then potentially discuss IRC (or even regular meetings) if it
>  becomes apparrent these would add value beyond ML discussion?
> 
>[deploy-tools] may be better unless that breaks people's email clients.
>I am out of bandwidth personally for meetings, although others may be
>interested in a meeting.  I'm not sure what value a regular meeting would
>have and would need a chair, which may result in an inability to obtain
>neutral ground.
>IMO IRC and ML would be sufficient for this CP effort, however others may
>have different viewpoints.

No strong opinion, but FWIW I chose "deployment" because I'd like to see
collaboration not only around tools, but also around experiences and
abstract workflow (e.g we could have all shared experiences around, say,
nova upgrades without necessarily focussing on any one tool).

"deployment" seems like a catch-all and it uses less characters in the
subject line ;)  But I'm happy to go with the consensus here.

I agree ML/IRC should be sufficient, at least in the first instance.

Thanks!

Steve

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

Re: [openstack-dev] [deployment][TripleO][kolla][ansible][fuel] Next steps for cross project collaboration

[Steven Dake]

On Mon, Feb 27, 2017 at 9:36 AM, Steven Hardy  wrote:

> On Mon, Feb 27, 2017 at 09:25:46AM -0700, Steven Dake wrote:
> >comments inline.
> >On Mon, Feb 27, 2017 at 9:02 AM, Steven Hardy 
> wrote:
> >
> >  Hi all,
> >
> >  Over the recent PTG, and previously at the design summit in
> Barcelona,
> >  we've had some productive cross-project discussions amongst the
> various
> >  deployment teams.
> >
> >  It's clear that we share many common problems, such as patterns for
> >  major
> >  version upgrades (even if the workflow isn't identical we've all
> >  duplicated
> >  effort e.g around basic nova upgrade workflow recently), container
> >  images
> >  and other common building blocks for configuration management.
> >
> >  Here's a non-exhaustive list of sessions where we had some good
> >  cross-project discussion, and agreed a number of common problems
> where
> >  collaboration may be possible:
> >
> >  https://etherpad.openstack.org/p/ansible-config-mgt
> >
> >  https://etherpad.openstack.org/p/tripleo-kolla-kubernetes
> >
> >  https://etherpad.openstack.org/p/kolla-pike-ptg-images
> >
> >  https://etherpad.openstack.org/p/fuel-ocata-fuel-tripleo-
> integration
> >
> >  If there is interest in continuing the discussions on a more regular
> >  basis,
> >  I'd like to propose we start a cross-project working group:
> >
> >  https://wiki.openstack.org/wiki/Category:Working_Groups
> >
> >  If I go ahead and do this is "deployment" a sufficiently
> project-neutral
> >  term to proceed with?
> >
> >WFM.  Anything longer such as "openstack-deployment-tools" doesn't
> show
> >up very well in IRC clients.  Forgive the bikeshedding;
> >"openstack-deploy-tools" is very project-neutral and shows up well in
> IRC
> >clients.
> >Â
> >
> >  I'd suggest we start with an informal WG, which it seems just
> requires
> >  an
> >  update to the wiki, e.g no need for any formal project team at this
> >  point?
> >
> >WFM.  Since we aren't really a project team but a collection of
> projects
> >working together, I don't think we need further formalization.
> >Â
> >
> >  Likewise I know some folks have expressed an interest in an IRC
> channel
> >  (openstack-deployment?), I'm happy to start with the ML but open to
> IRC
> >  also if someone is willing to set up the channel.
> >
> >+1 - I think an IRC channel would be the best way for real time
> >communication.
> >Â
> >
> >  Perhaps we can start by using the tag "deployment" in all
> cross-project
> >  ML
> >  traffic, then potentially discuss IRC (or even regular meetings) if
> it
> >  becomes apparrent these would add value beyond ML discussion?
> >
> >[deploy-tools] may be better unless that breaks people's email
> clients.
> >I am out of bandwidth personally for meetings, although others may be
> >interested in a meeting.  I'm not sure what value a regular meeting
> would
> >have and would need a chair, which may result in an inability to
> obtain
> >neutral ground.
> >IMO IRC and ML would be sufficient for this CP effort, however others
> may
> >have different viewpoints.
>
> No strong opinion, but FWIW I chose "deployment" because I'd like to see
> collaboration not only around tools, but also around experiences and
> abstract workflow (e.g we could have all shared experiences around, say,
> nova upgrades without necessarily focussing on any one tool).
>
> "deployment" seems like a catch-all and it uses less characters in the
> subject line ;)  But I'm happy to go with the consensus here.
>
> I agree ML/IRC should be sufficient, at least in the first instance.
>
> Steve,

openstack-deployment makes sense to me given the above.  The only downside
I see is there is a bit of overlap with #openstack-operators given the
objectives you stated.  I think that is a solvable problem.

I've registered #openstack-deployment and #openstack-deploy-tools
properly.  If the OpenStack deployment project members wish to proceed, I
will commit to doing the legwork of setting up the bots/etc on the final
name we come up with even if it isn't one of the above two :)

Regards
-steve

Thanks!
>
> Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [docs] Docs PTG summary

[Alexandra Settle]

Hi everyone,

The OpenStack manuals project had a really productive week at the first PTG in 
Atlanta, collaborating with the I18n team on the Monday and Tuesday for the 
horizontal sessions.

We were able to have several key leaders in the room, including previous 
documentation PTL, Anne Gentle and I18n PTL, Ian Choi to help drive a lot of 
the sessions. Although we had a small localized attendance, we were visited by 
several members of different projects such as Neutron and Security, each 
interested in helping contribute to the documentation project. We also had a 
successful first attempt at incorporating remote attendees for a few different 
sessions.

Following the PTG, the documentation team will be having a renewed focus on the 
Administration, Networking, High Availability (HA) and the Architecture Guides. 
These guides in particular have been items of technical debt for some time. The 
team at the PTG was able to collaborate and work on plans to best deal with any 
and all concerns. You can see all our comments, and sessions here: 
https://etherpad.openstack.org/p/docs-i18n-ptg-pike

Things to look out for during Pike:


1.   HA Guide

· Specialty team lead Ianeta Hutchinson and SME Adam Spiers played a 
big hand in planning the future of the guide. One of the major concerns was 
ensuring the guide was written and delivered to an appropriate audience. After 
collaborating during the session, and later in a cross-project working session. 
The team was able to smash out some new deliverables.

· You can see the comments, and the ToC planning in the HA etherpad: 
https://etherpad.openstack.org/p/HA_Guide

· The team will be using SMEs like Adam to help craft the guide, with 
further assistance from the OSIC team.

2.   Administration Guide

· The topic of a project-specific admin guide has come up previously, 
but this time with more gusto. As a result of the discussions in the PTG 
sessions, Ildiko Vancsa and specialty team lead Joseph Robinson will be working 
together over the course of the Pike release to fashion a specification.

· https://etherpad.openstack.org/p/docs-i18n-ptg-pike-repos

3.   Networking Guide

· Specialty team lead John Davidge will be working closely with the 
neutron team to work on a better information delivery method using the 
DocImpact tag. He will also be working on reorganizing the guide, and working 
with the HA team to avoid duplication of content.

· https://etherpad.openstack.org/p/networking-guide-improvements

4.   Security Guide

· The security guide team and the documentation team got together to 
work on the future of the Sec guide. Due to limited resources, there has been a 
pause in necessary updates. The security team working with OSIC have 
volunteered their team to employ a tactical effort to deliver 10 non-wishlist 
bugs.

· Further planning is underway regarding the audience, services, and 
pre-existing content.

· You can find more information here: 
https://etherpad.openstack.org/p/docs-i18n-ptg-pike (line 202)

5.   Architecture and Operations Guide(s)

· The draft guide that Ben Silverman and specialty team lead Darren 
Chan have been working on tirelessly for the last few cycles is coming out of 
the darkness and being published. Hopefully this will generate more interest in 
the guide (help!). The team will be working on improving the visibility of 
issues overall, and creating an architecture template use case template to 
provide guidance for contributors.

· The Ops Guide team will also be focusing on a single source of truth 
for Networking content, and discussing best course of action for the Upgrade 
notes.

· For more information: 
https://etherpad.openstack.org/p/docs-i18n-ptg-pike (line 271)

6.   Reno release notes

· Adam Spiers is working alongside Doug Hellmann to enable reno release 
notes for the Pike release. https://docs.openstack.org/developer/reno/

· Adam already has a preliminary patch up: 
https://review.openstack.org/#/c/437611/ keep your eyes open for more!

7.   Archiving of documentation

· Specialty team lead Brian Moss will be working with the tools team 
and Lana Brindley to implement the plan for archiving as detailed here: 
https://review.openstack.org/#/c/426047/

· The docs team will be working with the I18n team to find a use case 
that suits both scenarios.

· More information and notes: 
https://etherpad.openstack.org/p/docs-i18n-ptg-pike (line 104)

8.   Website theme

· The docs team will be working on unifying the themes used 
(oslo.sphinx and openstackdocstheme). Specialty team lead Kato Tomoyuki will be 
working alongside Anne Gentle to write a specification for the new integration.

We also had a few new contributors that was really great to see. Thanks to 
everyone that came along to the documentation session locally or r

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Thierry Carrez]

Dean Troyer wrote:
> On Mon, Feb 27, 2017 at 3:31 AM, Clint Byrum  wrote:
>> This is not for users who only want to see some projects. That is a well
>> understood space and the mailman filtering does handle it. This is for
>> those who want to monitor the overall health of the community, address
>> issues with cross-project specs, or participate in so many projects it
>> makes little sense to spend time filtering.
> 
> Monday morning and the caffiene is just beginning to reach my brain,
> but this seems counter-intuitive to me.  I consider myself someone who
> _does_ want to keep in touch with the majority of the community, and
> breaking things into N additional mailing lists makes that harder, not
> easier.  I _do_ include core team updates, mascots, social meetings in
> that set of things to pay a little attention to here, especially
> around summit/PTG/Forum/etc times.
> 
> I've seen a couple of descriptions of who this proposal is not
> intended to address, who exactly is expected to benefit from more
> mailing lists?

I'm not (yet) convinced that getting rid of 10% of ML messages (the ones
that would go to the -business lists) is worth the hassle of setting up
50 new lists, have people subscribe to them, and have overworked PTL
moderate them...

Also from my experience moderating such a -business list (the
openstack-tc list) I can say that it takes significant effort to avoid
having general-interest discussions there (or to close them when they
start from an innocent thread). Over those 50+ -business mailing-lists
I'm pretty sure a few would diverge and use the convenience of isolated
discussions without "outsiders" potentially chiming in. And they would
be pretty hard to detect...

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [nova] Device tagging: rebuild config drive upon instance reboot to refresh metadata on it

[Joshua Harlow]

Not afaik, first time I've heard about this type of device/data.

Tim Bell wrote:

Is there cloud-init support for this mode or do we still need to mount as a 
config drive?

Tim

On 20.02.17, 17:50, "Jeremy Stanley"  wrote:

 On 2017-02-20 15:46:43 + (+), Daniel P. Berrange wrote:
 >  The data is exposed either as a block device or as a character device
 >  in Linux - which one depends on how the NVDIMM is configured. Once
 >  opening the right device you can simply mmap() the FD and read the
 >  data. So exposing it as a file under sysfs doesn't really buy you
 >  anything better.

 Oh! Fair enough, if you can already access it as a character device
 then I agree that solves the use cases I was considering.
 --
 Jeremy Stanley

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Ian Cordasco]

-Original Message-
From: Thierry Carrez 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: February 27, 2017 at 11:19:25
To: openstack-dev@lists.openstack.org 
Subject:  Re: [openstack-dev] [all][swg] per-project "Business only"
moderated mailing lists

> Dean Troyer wrote:
> > On Mon, Feb 27, 2017 at 3:31 AM, Clint Byrum wrote:
> >> This is not for users who only want to see some projects. That is a well
> >> understood space and the mailman filtering does handle it. This is for
> >> those who want to monitor the overall health of the community, address
> >> issues with cross-project specs, or participate in so many projects it
> >> makes little sense to spend time filtering.
> >
> > Monday morning and the caffiene is just beginning to reach my brain,
> > but this seems counter-intuitive to me. I consider myself someone who
> > _does_ want to keep in touch with the majority of the community, and
> > breaking things into N additional mailing lists makes that harder, not
> > easier. I _do_ include core team updates, mascots, social meetings in
> > that set of things to pay a little attention to here, especially
> > around summit/PTG/Forum/etc times.
> >
> > I've seen a couple of descriptions of who this proposal is not
> > intended to address, who exactly is expected to benefit from more
> > mailing lists?
>
> I'm not (yet) convinced that getting rid of 10% of ML messages (the ones
> that would go to the -business lists) is worth the hassle of setting up
> 50 new lists, have people subscribe to them, and have overworked PTL
> moderate them...
>
> Also from my experience moderating such a -business list (the
> openstack-tc list) I can say that it takes significant effort to avoid
> having general-interest discussions there (or to close them when they
> start from an innocent thread). Over those 50+ -business mailing-lists
> I'm pretty sure a few would diverge and use the convenience of isolated
> discussions without "outsiders" potentially chiming in. And they would
> be pretty hard to detect...

I agree and would like to point out that it will likely confuse
newcomers. Where would they send their message to about whatever
feature their management is pressuring them to develop? Most likely
they'll try openstack-{project} first and then the PTL + their team
will have to read through it and guide the person to the openstack-dev
list. Core project teams already occasionally bicker over changes
being approved that one half wouldn't have approved. This will
introduce yet another place for subjective reasoning between trusted
members of the community.

I'm not sure there's a great deal of value in those lists considering
the likely costs.

--
Ian Cordasco

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

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Morgan Fainberg]

On Mon, Feb 27, 2017 at 9:18 AM, Thierry Carrez 
wrote:

> Dean Troyer wrote:
> > On Mon, Feb 27, 2017 at 3:31 AM, Clint Byrum  wrote:
> >> This is not for users who only want to see some projects. That is a well
> >> understood space and the mailman filtering does handle it. This is for
> >> those who want to monitor the overall health of the community, address
> >> issues with cross-project specs, or participate in so many projects it
> >> makes little sense to spend time filtering.
> >
> > Monday morning and the caffiene is just beginning to reach my brain,
> > but this seems counter-intuitive to me.  I consider myself someone who
> > _does_ want to keep in touch with the majority of the community, and
> > breaking things into N additional mailing lists makes that harder, not
> > easier.  I _do_ include core team updates, mascots, social meetings in
> > that set of things to pay a little attention to here, especially
> > around summit/PTG/Forum/etc times.
> >
> > I've seen a couple of descriptions of who this proposal is not
> > intended to address, who exactly is expected to benefit from more
> > mailing lists?
>
> I'm not (yet) convinced that getting rid of 10% of ML messages (the ones
> that would go to the -business lists) is worth the hassle of setting up
> 50 new lists, have people subscribe to them, and have overworked PTL
> moderate them...
>
> Also from my experience moderating such a -business list (the
> openstack-tc list) I can say that it takes significant effort to avoid
> having general-interest discussions there (or to close them when they
> start from an innocent thread). Over those 50+ -business mailing-lists
> I'm pretty sure a few would diverge and use the convenience of isolated
> discussions without "outsiders" potentially chiming in. And they would
> be pretty hard to detect...
>
>
FWIW, If I was a PTL and had a list like that to moderate on top of all the
other things, I'd just send a message that the list was going to be turned
off effectively (no messages being passed through).

Moderated lists are important for some tasks. This really doesn't seem like
a good use of someone's time. I agree with Thierry, this seems like a lot
of hassle for a very small benefit.

With all that said, I am not a PTL and would not be moderating these new
lists.

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

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Clint Byrum]

Excerpts from Dean Troyer's message of 2017-02-27 09:32:09 -0600:
> On Mon, Feb 27, 2017 at 3:31 AM, Clint Byrum  wrote:
> > This is not for users who only want to see some projects. That is a well
> > understood space and the mailman filtering does handle it. This is for
> > those who want to monitor the overall health of the community, address
> > issues with cross-project specs, or participate in so many projects it
> > makes little sense to spend time filtering.
> 
> Monday morning and the caffiene is just beginning to reach my brain,
> but this seems counter-intuitive to me.  I consider myself someone who
> _does_ want to keep in touch with the majority of the community, and
> breaking things into N additional mailing lists makes that harder, not
> easier.  I _do_ include core team updates, mascots, social meetings in
> that set of things to pay a little attention to here, especially
> around summit/PTG/Forum/etc times.
> 
> I've seen a couple of descriptions of who this proposal is not
> intended to address, who exactly is expected to benefit from more
> mailing lists?
> 

Thanks for your reply. The proposed change is meant to benefit
readers of openstack-dev who do not have access to, or ability with,
sup/procmail/sieve/IMAP/etc., but do want to be able to be able to keep
up with the general flow of discussion in openstack-dev. We had a room
full of 10 or so cross-project minded folks, and only 3 of us felt that
we could keep up with the discussion threads that we even care about, much
less those that we might care about, but don't have time to even evaluate.

The idea would simply be that those directly involved in a team wouldn't
mind subscribing to a few more ML's to get relevant information about
the day to day workings of a team, but that for most people openstack-dev
would be sufficient.

The response to the suggestion tells me that we don't have agreement that
there is a problem. Perhaps those of us in the SWG room at the time were
simply falling victim to a small sample size and anecdotal data.

So, I'll ask more generally: do you believe that the single openstack-dev
mailing list is working fine and we should change nothing? If not, what
problems has it created for you? 

Let's refrain from making suggestions about solutions until we've agreed
on any problems (or the lack thereof, hopefully?)

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

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Shamail]

> On Feb 27, 2017, at 12:35 PM, Clint Byrum  wrote:
> 
> Excerpts from Dean Troyer's message of 2017-02-27 09:32:09 -0600:
>>> On Mon, Feb 27, 2017 at 3:31 AM, Clint Byrum  wrote:
>>> This is not for users who only want to see some projects. That is a well
>>> understood space and the mailman filtering does handle it. This is for
>>> those who want to monitor the overall health of the community, address
>>> issues with cross-project specs, or participate in so many projects it
>>> makes little sense to spend time filtering.
>> 
>> Monday morning and the caffiene is just beginning to reach my brain,
>> but this seems counter-intuitive to me.  I consider myself someone who
>> _does_ want to keep in touch with the majority of the community, and
>> breaking things into N additional mailing lists makes that harder, not
>> easier.  I _do_ include core team updates, mascots, social meetings in
>> that set of things to pay a little attention to here, especially
>> around summit/PTG/Forum/etc times.
>> 
>> I've seen a couple of descriptions of who this proposal is not
>> intended to address, who exactly is expected to benefit from more
>> mailing lists?
>> 
> 
> Thanks for your reply. The proposed change is meant to benefit
> readers of openstack-dev who do not have access to, or ability with,
> sup/procmail/sieve/IMAP/etc., but do want to be able to be able to keep
> up with the general flow of discussion in openstack-dev. We had a room
> full of 10 or so cross-project minded folks, and only 3 of us felt that
> we could keep up with the discussion threads that we even care about, much
> less those that we might care about, but don't have time to even evaluate.
> 
> The idea would simply be that those directly involved in a team wouldn't
> mind subscribing to a few more ML's to get relevant information about
> the day to day workings of a team, but that for most people openstack-dev
> would be sufficient.
> 
> The response to the suggestion tells me that we don't have agreement that
> there is a problem. Perhaps those of us in the SWG room at the time were
> simply falling victim to a small sample size and anecdotal data.
> 
> So, I'll ask more generally: do you believe that the single openstack-dev
> mailing list is working fine and we should change nothing? If not, what
> problems has it created for you? 

The single openstack-dev list works fine for me.  I am not using anything to 
filter either beyond what my default mail clients offer.  

Could we modify the question slightly to also ask how people are dealing with 
reading through the single list?  That might help us write a page that 
newcomers could read to get tips on how to best handle the mailing list traffic 
(which seems to be the origin of the proposed change).
> 
> Let's refrain from making suggestions about solutions until we've agreed
> on any problems (or the lack thereof, hopefully?)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Matthew Treinish]

On Mon, Feb 27, 2017 at 06:18:10PM +0100, Thierry Carrez wrote:
> > Dean Troyer wrote:
> >> On Mon, Feb 27, 2017 at 3:31 AM, Clint Byrum  wrote:
> >> This is not for users who only want to see some projects. That is a well
> >> understood space and the mailman filtering does handle it. This is for
> >> those who want to monitor the overall health of the community, address
> >> issues with cross-project specs, or participate in so many projects it
> >> makes little sense to spend time filtering.
> > 
> > Monday morning and the caffiene is just beginning to reach my brain,
> > but this seems counter-intuitive to me.  I consider myself someone who
> > _does_ want to keep in touch with the majority of the community, and
> > breaking things into N additional mailing lists makes that harder, not
> > easier.  I _do_ include core team updates, mascots, social meetings in
> > that set of things to pay a little attention to here, especially
> > around summit/PTG/Forum/etc times.

+1, I'm also someone who also tries to keep an eye on a lot of projects and
cross project work and will find this a lot more difficult.

> > 
> > I've seen a couple of descriptions of who this proposal is not
> > intended to address, who exactly is expected to benefit from more
> > mailing lists?
> 
> I'm not (yet) convinced that getting rid of 10% of ML messages (the ones
> that would go to the -business lists) is worth the hassle of setting up
> 50 new lists, have people subscribe to them, and have overworked PTL
> moderate them...

I agree with this. (although TBH I don't think I can be convinced) I
also don't think in practice it will even be close to 10% of the ML traffic
being routed to the per project lists.

> 
> Also from my experience moderating such a -business list (the
> openstack-tc list) I can say that it takes significant effort to avoid
> having general-interest discussions there (or to close them when they
> start from an innocent thread). Over those 50+ -business mailing-lists
> I'm pretty sure a few would diverge and use the convenience of isolated
> discussions without "outsiders" potentially chiming in. And they would
> be pretty hard to detect...
> 

Another similar counter example is the dedicated openstack-qa list, which has
been dead for a long time now. This was something that had similar issues,
although it wasn't a moderated list. What ended up happening was that the
discussions happening there were siloed and no one ever noticed anything being
discussed there. So things had to be cross posted to get any attention.
Discussions also ended up being duplicated between the 2 lists (like ttx said
he ties to avoid via active moderation). Which is why we dissolved the
openstack-qa list and just reintegrated the discussion back into openstack-dev.

-Matt Treinish


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

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Dean Troyer]

On Mon, Feb 27, 2017 at 11:35 AM, Clint Byrum  wrote:
> Thanks for your reply. The proposed change is meant to benefit
> readers of openstack-dev who do not have access to, or ability with,
> sup/procmail/sieve/IMAP/etc., but do want to be able to be able to keep
> up with the general flow of discussion in openstack-dev.

FWIW, I'm using GMail, and nothing else, to achieve acceptable
filtering/sorting _for me_.  But then I am interested in at least
seeing subjects of the wider community go past and not doing sharp
filtering on specific projects.

> The idea would simply be that those directly involved in a team wouldn't
> mind subscribing to a few more ML's to get relevant information about
> the day to day workings of a team, but that for most people openstack-dev
> would be sufficient.

This makes assumptions about who wants to see those messages intended
for the additional lists.

> So, I'll ask more generally: do you believe that the single openstack-dev
> mailing list is working fine and we should change nothing? If not, what
> problems has it created for you?

It is working about as well as can be expected _for me_.  Others have
also shared a similar sentiment, including the tools they use to
achieve that result.  I fully expect that there is a significant
number of people for whom the current situation is not working well
_for them_, and some of those folk were in that room.

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Clint Byrum]

Excerpts from Matthew Treinish's message of 2017-02-27 13:03:56 -0500:
> On Mon, Feb 27, 2017 at 06:18:10PM +0100, Thierry Carrez wrote:
> > > Dean Troyer wrote:
> > >> On Mon, Feb 27, 2017 at 3:31 AM, Clint Byrum  wrote:
> > >> This is not for users who only want to see some projects. That is a well
> > >> understood space and the mailman filtering does handle it. This is for
> > >> those who want to monitor the overall health of the community, address
> > >> issues with cross-project specs, or participate in so many projects it
> > >> makes little sense to spend time filtering.
> > > 
> > > Monday morning and the caffiene is just beginning to reach my brain,
> > > but this seems counter-intuitive to me.  I consider myself someone who
> > > _does_ want to keep in touch with the majority of the community, and
> > > breaking things into N additional mailing lists makes that harder, not
> > > easier.  I _do_ include core team updates, mascots, social meetings in
> > > that set of things to pay a little attention to here, especially
> > > around summit/PTG/Forum/etc times.
> 
> +1, I'm also someone who also tries to keep an eye on a lot of projects and
> cross project work and will find this a lot more difficult.
> 
> > > 
> > > I've seen a couple of descriptions of who this proposal is not
> > > intended to address, who exactly is expected to benefit from more
> > > mailing lists?
> > 
> > I'm not (yet) convinced that getting rid of 10% of ML messages (the ones
> > that would go to the -business lists) is worth the hassle of setting up
> > 50 new lists, have people subscribe to them, and have overworked PTL
> > moderate them...
> 
> I agree with this. (although TBH I don't think I can be convinced) I
> also don't think in practice it will even be close to 10% of the ML traffic
> being routed to the per project lists.
> 

To be clear, I estimate 10% of _threads_, not traffic. Most people can
mentally file a thread away by subject, even if their mail client can't.

> > 
> > Also from my experience moderating such a -business list (the
> > openstack-tc list) I can say that it takes significant effort to avoid
> > having general-interest discussions there (or to close them when they
> > start from an innocent thread). Over those 50+ -business mailing-lists
> > I'm pretty sure a few would diverge and use the convenience of isolated
> > discussions without "outsiders" potentially chiming in. And they would
> > be pretty hard to detect...
> > 
> 
> Another similar counter example is the dedicated openstack-qa list, which has
> been dead for a long time now. This was something that had similar issues,
> although it wasn't a moderated list. What ended up happening was that the
> discussions happening there were siloed and no one ever noticed anything being
> discussed there. So things had to be cross posted to get any attention.
> Discussions also ended up being duplicated between the 2 lists (like ttx said
> he ties to avoid via active moderation). Which is why we dissolved the
> openstack-qa list and just reintegrated the discussion back into 
> openstack-dev.
>

I obviously failed at stating this but I'll say it again: The business
lists would never be for discussions of anything. They're for informing
each other of facts pertaining to your project only.

I'm refraining from thinking up new solutions until we've agreed upon a
set of problems to address. Thanks for responding. :)

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

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Jeremy Stanley]

On 2017-02-27 09:35:21 -0800 (-0800), Clint Byrum wrote:
[...]
> do you believe that the single openstack-dev mailing list is
> working fine and we should change nothing? If not, what problems
> has it created for you?
[...]

Perhaps my case is unusual, but I find the current activity on this
ML to be working rather well for me. In particular the presence of
discussions from a variety of vertical teams (especially new ones)
here makes it more likely that I notice when they start to head off
the rails from established community norms. I don't filter it at all
and do try to skim all the threads unless my workload gets heavier
than expected.

A few "horizontal" teams already have examples of such secondary
mailing lists and I end up subscribing to all of them as well
(Infrastructure obviously, but also Documentation, I18n, Security,
Stable Branch Maintenance...). There used to be more but as time
goes on many have been folded back into the main -dev ML for better
alignment with community-wide discussion. The ones which haven't are
either used solely for automation (reports of failed changes, Cc'd
comments from specific bug tags, et cetera) or are have a high
enough volume of threads which aren't of general interest to the
-dev subscriber base (in Infra's case we field a lot of support
requests for non-OpenStack-specific software, for example).

So yes, "business" lists are in use and seem to be working
effectively in a few situations, but these tend to all be focused on
topics which fall outside of the scope of the main development
mailing list and even then their respective participants and
moderators struggle to figure out which discussions should go where.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [QA]Refactoring Scenarios manager.py

[Ken'ichi Ohmichi]

I see Jordan's opinion here and I also faced this situation before.
I proposed a hacking patch [1] to notify wrong usage of Tempest
methods to projects and I saw some users of these methods didn't know
the definition of stable interfaces of Tempest.
We always face this issue on developments which change *internal*
methods of Tempest.

2017-02-26 10:13 GMT-08:00 Andrea Frittoli :
>
> Scenario tests will go through a significant number of changes as part of
> the refactor and if every change risks to break someone's gate job it won't
> work.
> I propose we proceed as follows:
> - identify projects that import from tempest.scenario
> - send a notification to the ML about the changes that are going to happen
> - help the affected teams to identify a way decouple them from tempest
> scenario code - most likely copy the relevant code in-tree
> - meanwhile continue to work on patches for scenario tests but do not merge
> them yet

Yeah, this approach is very nice to land patches softly.
Users can find solutions if facing this issue on the own gate.

> This process shouldn't take long and be rather straight forward.
>
> I already have some data from codesearch, I will send out the e-mail
> tomorrow.

++, thanks for your leadership.

Thanks
Ken Ohmichi

---

[1]: https://review.openstack.org/#/c/328651

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

[openstack-dev] [neutron] Does your plugin support updating network provider extended attributes?

[Boden Russell]

Today, most, if not all plugins forbid updating network provider
extended attributes. Our docs [1] even say so:

"Most Networking plug-ins and drivers do not support updating any
provider related attributes."

To formalize this we were discussing the possibility of forbidding
updates (PUT) at the API layer [2]. However, such a change begs the
question of backwards compatibility; the motivation for this email.

Question:
Are there any neutron plugins that DO support updating network provider
extended attributes [1]?


Thanks

PS: Just to make sure we cover our bases, I'll send a quick note to the
operator list as well; referring to this one.


[1]
https://developer.openstack.org/api-ref/networking/v2/#provider-extended-attributes
[2] https://review.openstack.org/421961/

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

[openstack-dev] [deployment][kolla][openstack-helm] OpenStack on Helm Workgroup Meeting

[Chris Hoge]

We will be holding an OpenStack on Helm Workgroup meeting on Tuesday,
February 28 at 19:30 UTC/11:30 PT. On the agenda will be the transition
of the meeting from an informal working group to the
kubernetes-sig-openstack efforts, with a proposal to seed the applications
side of the sig-openstack meetings with this collaboration.

Meeting room:
https://deis.zoom.us/zoomconference?m=45b8ceYiN82MrsspfNm4Go91HnZ5jVUj

Agenda:
https://etherpad.openstack.org/p/openstack-helm

Thanks,
Chris

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

Re: [openstack-dev] [deployment][TripleO][kolla][ansible][fuel] Next steps for cross project collaboration

[Chris Hoge]

> 
> On Feb 27, 2017, at 8:02 AM, Steven Hardy  wrote:
> 
> Hi all,
> 
> Over the recent PTG, and previously at the design summit in Barcelona,
> we've had some productive cross-project discussions amongst the various
> deployment teams.
> 
> It's clear that we share many common problems, such as patterns for major
> version upgrades (even if the workflow isn't identical we've all duplicated
> effort e.g around basic nova upgrade workflow recently), container images
> and other common building blocks for configuration management.
> 
> Here's a non-exhaustive list of sessions where we had some good
> cross-project discussion, and agreed a number of common problems where
> collaboration may be possible:
> 
> https://etherpad.openstack.org/p/ansible-config-mgt
> 
> https://etherpad.openstack.org/p/tripleo-kolla-kubernetes
> 
> https://etherpad.openstack.org/p/kolla-pike-ptg-images
> 
> https://etherpad.openstack.org/p/fuel-ocata-fuel-tripleo-integration
> 
> If there is interest in continuing the discussions on a more regular basis,
> I'd like to propose we start a cross-project working group:
> 
> https://wiki.openstack.org/wiki/Category:Working_Groups
> 
> If I go ahead and do this is "deployment" a sufficiently project-neutral
> term to proceed with?
> 
> I'd suggest we start with an informal WG, which it seems just requires an
> update to the wiki, e.g no need for any formal project team at this point?
> 
> Likewise I know some folks have expressed an interest in an IRC channel
> (openstack-deployment?), I'm happy to start with the ML but open to IRC
> also if someone is willing to set up the channel.
> 
> Perhaps we can start by using the tag "deployment" in all cross-project ML
> traffic, then potentially discuss IRC (or even regular meetings) if it
> becomes apparrent these would add value beyond ML discussion?
> 
> Please follow up here if anyone has other/better ideas on how to facilitate
> ongoing cross-team discussion and I'll do my best to help move things
> forward.

This is great. Of note, for the projects using K8S as a deployment
platform, we have efforts to refine the kubernetes-sig-openstack
to have a common location for collaboration with K8s projects. I
just sent an invitation the dev mailing list, but planning starts
tomorrow (Feb 28) as part of the informal OpenStack on Helm
workgroup meeting.

> Thanks!
> 
> Steve
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Sean McGinnis]

On Mon, Feb 27, 2017 at 06:26:48PM +, Jeremy Stanley wrote:
> On 2017-02-27 09:35:21 -0800 (-0800), Clint Byrum wrote:
> [...]
> > do you believe that the single openstack-dev mailing list is
> > working fine and we should change nothing? If not, what problems
> > has it created for you?
> [...]
> 
> Perhaps my case is unusual, but I find the current activity on this
> ML to be working rather well for me. In particular the presence of
> discussions from a variety of vertical teams (especially new ones)
> here makes it more likely that I notice when they start to head off
> the rails from established community norms. I don't filter it at all
> and do try to skim all the threads unless my workload gets heavier
> than expected.
> 

Same for me. I would actually prefer to keep things as they are.

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

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Jeremy Stanley]

On 2017-02-27 12:54:33 -0500 (-0500), Shamail wrote:
[...]
> Could we modify the question slightly to also ask how people are
> dealing with reading through the single list?  That might help us
> write a page that newcomers could read to get tips on how to best
> handle the mailing list traffic (which seems to be the origin of
> the proposed change).
[...]

Many thanks to Joshua Harlow for the breadcrumbs necessary to find
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104453.html
in our archives! ;)
-- 
Jeremy Stanley

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

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Mikhail Medvedev]

On Mon, Feb 27, 2017 at 11:54 AM, Shamail  wrote:
>
>
> The single openstack-dev list works fine for me.  I am not using anything to 
> filter either beyond what my default mail clients offer.
>
> Could we modify the question slightly to also ask how people are dealing with 
> reading through the single list?  That might help us write a page that 
> newcomers could read to get tips on how to best handle the mailing list 
> traffic (which seems to be the origin of the proposed change).
>

+1, collecting workflows people use for dealing with ml would be good.
I am new to such a high-volume list, and I have tried several things.
Now I have a few filters in gmail that mark threads I am not
interested in, but they all still go into my main inbox. I then mute
irrelevant threads. Once you did the first round of mutes, it becomes
easier. I spend 10-20 minutes daily to get through all of the threads.

I see a very marginal benefit in adding more lists.

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

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Doug Hellmann]

Excerpts from Clint Byrum's message of 2017-02-27 09:35:21 -0800:
> Excerpts from Dean Troyer's message of 2017-02-27 09:32:09 -0600:
> > On Mon, Feb 27, 2017 at 3:31 AM, Clint Byrum  wrote:
> > > This is not for users who only want to see some projects. That is a well
> > > understood space and the mailman filtering does handle it. This is for
> > > those who want to monitor the overall health of the community, address
> > > issues with cross-project specs, or participate in so many projects it
> > > makes little sense to spend time filtering.
> > 
> > Monday morning and the caffiene is just beginning to reach my brain,
> > but this seems counter-intuitive to me.  I consider myself someone who
> > _does_ want to keep in touch with the majority of the community, and
> > breaking things into N additional mailing lists makes that harder, not
> > easier.  I _do_ include core team updates, mascots, social meetings in
> > that set of things to pay a little attention to here, especially
> > around summit/PTG/Forum/etc times.
> > 
> > I've seen a couple of descriptions of who this proposal is not
> > intended to address, who exactly is expected to benefit from more
> > mailing lists?
> > 
> 
> Thanks for your reply. The proposed change is meant to benefit
> readers of openstack-dev who do not have access to, or ability with,
> sup/procmail/sieve/IMAP/etc., but do want to be able to be able to keep
> up with the general flow of discussion in openstack-dev. We had a room
> full of 10 or so cross-project minded folks, and only 3 of us felt that
> we could keep up with the discussion threads that we even care about, much
> less those that we might care about, but don't have time to even evaluate.
> 
> The idea would simply be that those directly involved in a team wouldn't
> mind subscribing to a few more ML's to get relevant information about
> the day to day workings of a team, but that for most people openstack-dev
> would be sufficient.
> 
> The response to the suggestion tells me that we don't have agreement that
> there is a problem. Perhaps those of us in the SWG room at the time were
> simply falling victim to a small sample size and anecdotal data.
> 
> So, I'll ask more generally: do you believe that the single openstack-dev
> mailing list is working fine and we should change nothing? If not, what
> problems has it created for you? 

As a person who sends a lot of process-driven email to this list,
it is not working for my needs to communicate with others.

Over the past few cycles when I was the release PTL, I always had
a couple of PTLs say there was too much email on this list for them
to read, and that they had not read my instructions for managing
releases. That resulted in us having to train folks at the last
minute, remind them of deadlines, deal with them missing deadlines,
and otherwise increased the release team's workload.

It is possible the situation will improve now that the automation
work is mostly complete and we expect to see fewer significant
changes in the release workflow. That still leaves quite a few
people regularly surprised by deadlines, though.

Doug

> Let's refrain from making suggestions about solutions until we've agreed
> on any problems (or the lack thereof, hopefully?)
> 

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

Re: [openstack-dev] [horizon] PTG Summary

[Richard Jones]

On 28 February 2017 at 02:28, Rob Cresswell
 wrote:
> Quick summary of the PTG for those who missed it. Here's the etherpad, with
> notes inline: https://etherpad.openstack.org/p/horizon-ptg-pike

Thanks, Rob!


> - Use [horizon-plugin] mailer tag to keep people up to date

Could you expand on this please? Who is using/consuming this, and what
information is desired?


Richard

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

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Clint Byrum]

Excerpts from Doug Hellmann's message of 2017-02-27 15:43:12 -0500:
> Excerpts from Clint Byrum's message of 2017-02-27 09:35:21 -0800:
> > Excerpts from Dean Troyer's message of 2017-02-27 09:32:09 -0600:
> > > On Mon, Feb 27, 2017 at 3:31 AM, Clint Byrum  wrote:
> > > > This is not for users who only want to see some projects. That is a well
> > > > understood space and the mailman filtering does handle it. This is for
> > > > those who want to monitor the overall health of the community, address
> > > > issues with cross-project specs, or participate in so many projects it
> > > > makes little sense to spend time filtering.
> > > 
> > > Monday morning and the caffiene is just beginning to reach my brain,
> > > but this seems counter-intuitive to me.  I consider myself someone who
> > > _does_ want to keep in touch with the majority of the community, and
> > > breaking things into N additional mailing lists makes that harder, not
> > > easier.  I _do_ include core team updates, mascots, social meetings in
> > > that set of things to pay a little attention to here, especially
> > > around summit/PTG/Forum/etc times.
> > > 
> > > I've seen a couple of descriptions of who this proposal is not
> > > intended to address, who exactly is expected to benefit from more
> > > mailing lists?
> > > 
> > 
> > Thanks for your reply. The proposed change is meant to benefit
> > readers of openstack-dev who do not have access to, or ability with,
> > sup/procmail/sieve/IMAP/etc., but do want to be able to be able to keep
> > up with the general flow of discussion in openstack-dev. We had a room
> > full of 10 or so cross-project minded folks, and only 3 of us felt that
> > we could keep up with the discussion threads that we even care about, much
> > less those that we might care about, but don't have time to even evaluate.
> > 
> > The idea would simply be that those directly involved in a team wouldn't
> > mind subscribing to a few more ML's to get relevant information about
> > the day to day workings of a team, but that for most people openstack-dev
> > would be sufficient.
> > 
> > The response to the suggestion tells me that we don't have agreement that
> > there is a problem. Perhaps those of us in the SWG room at the time were
> > simply falling victim to a small sample size and anecdotal data.
> > 
> > So, I'll ask more generally: do you believe that the single openstack-dev
> > mailing list is working fine and we should change nothing? If not, what
> > problems has it created for you? 
> 
> As a person who sends a lot of process-driven email to this list,
> it is not working for my needs to communicate with others.
> 
> Over the past few cycles when I was the release PTL, I always had
> a couple of PTLs say there was too much email on this list for them
> to read, and that they had not read my instructions for managing
> releases. That resulted in us having to train folks at the last
> minute, remind them of deadlines, deal with them missing deadlines,
> and otherwise increased the release team's workload.
> 
> It is possible the situation will improve now that the automation
> work is mostly complete and we expect to see fewer significant
> changes in the release workflow. That still leaves quite a few
> people regularly surprised by deadlines, though.
> 

The problem above is really the krux of it. Whether or not you can keep
up with the mailing list can be an unknown, unknown. Even now, those
who can't actually handle the mailing list traffic are in fact likely
missing this thread about whether or not people can handle the mailing
list traffic (credit fungi for pointing out this irony to me on IRC).

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

[openstack-dev] [neutron] neutron-lib pep8 hacking checks

[Boden Russell]

If your project is or plans to use neutron-lib moving forward, please
read on.

At the PTG we discussed how to roll-out new hacking checks in
neutron-lib. In summary we decided to move forward using a single set of
hacking checks, as proposed by [1] (see 'doc/source/usage.rst' in that
patch for gory details).

The major implication is that sub-projects using neutron-lib's hacking
checks [2] will pick-up new checks as we release them to the lib.

This email serves as a heads-up and friendly reminder on that topic.

Please direct any technical discussion to the patch [1] so we can
capture it along with the implementation.

Thanks

[1] https://review.openstack.org/421484/
[2]
http://codesearch.openstack.org/?q=local-check-factory%20%3D%20neutron_lib%5C.hacking%5C.checks.factory

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

Re: [openstack-dev] [deployment][TripleO][kolla][ansible][fuel] Next steps for cross project collaboration

[Jesse Pretorius]

Comments in-line

On 2/27/17, 4:02 PM, "Steven Hardy"  wrote:

If I go ahead and do this is "deployment" a sufficiently project-neutral
term to proceed with?

I think so.

I'd suggest we start with an informal WG, which it seems just requires an
update to the wiki, e.g no need for any formal project team at this point?

A WG is what I had in mind.

Likewise I know some folks have expressed an interest in an IRC channel
(openstack-deployment?), I'm happy to start with the ML but open to IRC
also if someone is willing to set up the channel.

Personally I think we should use #openstack-dev instead. It’s the traditional 
place for cross-project communication, is less exclusive and much like this 
mailing list brings more people into the conversation.

Perhaps we can start by using the tag "deployment" in all cross-project ML
traffic, then potentially discuss IRC (or even regular meetings) if it
becomes apparrent these would add value beyond ML discussion?

Sure, I don’t have any strong feelings about the tag. The tag [deployment] 
makes sense to me.



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] this week's priorities and subteam reports

[Loo, Ruby]

Hi,

We are fascinated to present this week's priorities and subteam report for 
Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and 
formatted.

This Week's Priorities (as of the weekly ironic meeting)

1. PTG summary and deciding on Pike priorities
2. update subteam list
3. portgroups and attach/detach tempest tests: 
https://review.openstack.org/382476


Bugs (dtantsur, vdrok)
==
- Stats (diff between 13 Feb 2017 and 27 Feb 2017)
- Ironic: 227 bugs (+7) + 238 wishlist items (+2). 20 new (+3), 189 in progress 
(+8), 0 critical, 24 high (-1) and 29 incomplete
- Inspector: 15 bugs (+1) + 23 wishlist items (+3). 3 new (+1), 13 in progress 
(+1), 0 critical, 1 high and 4 incomplete (-1)
- Nova bugs with Ironic tag: 11. 0 new (-1), 0 critical, 0 high

Portgroups support (sambetts, vdrok)

* trello: https://trello.com/c/KvVjeK5j/29-portgroups-support
- status as of most recent weekly meeting:
- tempest tests https://review.openstack.org/382476 need review

CI refactoring (dtantsur, lucasagomes)
==
* trello: https://trello.com/c/c96zb3dm/32-ci-refactoring
- status as of most recent weekly meeting:
- standalone tests proposed by vsaienk0 
https://review.openstack.org/#/c/423556/

Rolling upgrades and grenade-partial (rloo, jlvillal)
=
* trello: 
https://trello.com/c/GAlhSzLm/2-rolling-upgrades-and-grenade-with-multi-node
- status as of most recent weekly meeting:
- patches need reviews: https://review.openstack.org/#/q/topic:bug/1526283.
- Testing work:
- 27-Feb-2017: Grenade + multi-tenant + multi-node is passing on the 
OSIC cluster :)
- This is of course with a few patches which still need to land.
- There is an issue with the job failing on clusters other than 
OSIC :(

Generic boot-from-volume (TheJulia)
===
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- status as of most recent weekly meeting:
- API side changes for volume connector information has a procedural -2 
until we can begin making use of the data in the conductor, but should stil be 
reviewed
- https://review.openstack.org/#/c/214586/
- This change has been rebased on top of the iPXE template update 
revision to support cinder/iscsi booting.
- Boot from volume/storage cinder interface is up for review
- Julia in process of updating base changes
- Volunteers indicated they would be willing to assist with the 
remaining work. TheJulia will be reaching out to those volunteers during the 
week after the PTG in order to schedule a regular meeting.
- 
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1559691
- Original volume connection information client patches
- These changes should be expected to land once Pike opens.
- 
https://review.openstack.org/#/q/status:open+project:openstack/python-ironicclient+branch:master+topic:bug/1526231

Driver composition (dtantsur, jroll)

* trello: https://trello.com/c/fTya14y6/14-driver-composition
- gerrit topic: https://review.openstack.org/#/q/status:open+topic:bug/1524745
- status as of most recent weekly meeting:
- a job based on the IPMI hardware type is running non-voting
- will probably be rolled into some other job(s) later
- api-ref merged
- next steps (some yet to be written/finished) as of 13 Feb 2017:
- install guide / admin guide docs - TODO
- client changes:
- driver commands update: https://review.openstack.org/419274
- node-update update: https://review.openstack.org/#/c/431542/
- talked at PTG about anything missing, path to getting vendor hw types, 
etc. jroll will update with what is left to do.

Rescue mode (JayF / mariojv)

* trello: https://trello.com/c/PwH1pexJ/23-rescue-mode
- Working in devstack! http://imgur.com/a/dqvE2
- 2/27 status
- need reviews on:
- https://review.openstack.org/#/c/350831/ - API/conductor methods 
(tested working)
- https://review.openstack.org/#/c/353156/ - rescuewait timeout 
periodic task
- https://review.openstack.org/#/c/400437/ - agent driver patch (tested 
working)
- https://review.openstack.org/#/c/408341/ - client support patch 
(tested working)
- https://review.openstack.org/#/c/423521 - IPA support for CoreOS 
Image + DHCP networks (tested working)
- https://review.openstack.org/#/c/419606/ - ironic docs patch - needs 
rebase and updates
- https://review.openstack.org/#/c/431622/ - IPA docs patch - needs 
updates
- Still WIP
- Nova patch: https://review.openstack.org/#/c/416487/

etags in the REST API (gzholtkevych)

[openstack-dev] [nova][keystone] Pike PTG recap - quotas

[Matt Riedemann]

We talked about a few things related to quotas at the PTG, some in 
cross-project sessions earlier in the week and then some on Wednesday 
morning in the Nova room. The full etherpad is here [1].


Counting quotas
---

Melanie hit a problem with the counting quotas work in Ocata with 
respect to how to handle quotas when the cell that an instance is 
running in is down. The proposed solution is to track project/user ID 
information in the "allocations" table in the Placement service so that 
we can get allocation information for quota usage from Placement rather 
than the cell. That should be a relatively simple change to move this 
forward and hopefully get the counting quotas patches merged by p-1 so 
we have plenty of burn-in time for the new quotas code.


Centralizing limits in Keystone
---

This actually came up mostly during the hierarchical quotas discussion 
on Tuesday which was a cross-project session. The etherpad for that is 
here [2]. The idea here is that Keystone already knows about the project 
hierarchy and can be a central location for resource limits so that the 
various projects, like nova and cinder, don't have to have a similar 
data model and API for limits, we can just make that common in Keystone. 
The other projects would still track resource usage and calculate when a 
request is over the limit, but the hope is that the calculation and 
enforcement can be generalized so we don't have to implement the same 
thing in all of the projects for calculating when something is over quota.


There is quite a bit of detail in the nova etherpad [1] about 
overbooking and enforcement modes, which will need to be brought up as 
options in a spec and then projects can sort out what makes the most 
sense (there might be multiple enforcement models available).


We still have to figure out the data migration plan to get limits data 
from each project into Keystone, and what the API in Keystone is going 
to look like, including what this looks like when you have multiple 
compute endpoints in the service catalog, or regions, for example.


Sean Dague was going to start working on the spec for this.

Hierarchical quota support
--

The notes on hierarchical quota support are already in [1] and [2]. We 
agreed to not try and support hierarchical quotas in Nova until we were 
using limits from Keystone so that we can avoid the complexity of both 
systems (limits from Nova and limits from Keystone) in the same API 
code. We also agreed to not block the counting quotas work that melwitt 
is doing since that's already valuable on its own. It's also fair to say 
that hierarchical quota support in Nova is a Queens item at the earliest 
given we have to get limits stored in Keystone in Pike first.


Dealing with the os-qouta-class-sets API


I had a spec [3] proposing to cleanup some issues with the 
os-quota-class-sets API in Nova. We agreed that rather than spend time 
fixing the latent issues in that API, we'd just invest that time in 
storing and getting limits from Keystone, after which we'll revisit 
deprecating the quota classes API in Nova.


[1] https://etherpad.openstack.org/p/nova-ptg-pike-quotas
[2] https://etherpad.openstack.org/p/ptg-hierarchical-quotas
[3] https://review.openstack.org/#/c/411035/

--

Thanks,

Matt Riedemann

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

Re: [openstack-dev] [oslo] PTG summary

[Doug Hellmann]

Excerpts from ChangBo Guo's message of 2017-02-25 00:07:21 +0800:
> Oslo folks,
> 
> This is summary of  oslo PTG schedule during one and half days. You can
> check the details in etherpad link:
> https://etherpad.openstack.org/p/oslo-ptg-pike
> 
> 1. oslo.messaging: consistent names for general driver configuration options
>Some of supported drviers have various option configuration names with
> for common usage, This has led to a plethora of different configuration
> options that complicates the   development of Day 1 deployment and
> configuration tools. We propose that 'scrub' the configuration namespace
> and come up with common generic names that can be shared among the various
> drivers. Note: this is *not* calling for moving these configuration items
> 'up' to the DEFAULT group.  Each driver should be able to have its own
> value for any given configuration setting.  This is necessary for the dual
> backend deployment scenario.
> 
> 2. Messaging Experiences towards hybrid backends
>Share experience and progress towards introducing dual messaging backend
> operation :
> https://docs.google.com/presentation/d/1Y-3gH8rxrU5KagvDQiqpByfvmgM8no-PLn1O0IT5PCs/edit?usp=sharing
> 
> 3.How to make oslo work done in an efficient way
>1)Track bugs & reviews accoding to their priorities
>2)Record general core reviewers' focus to help get help from them.
> https://etherpad.openstack.org/p/oslo-pike-tracking
>3) Don't migrate to StoryBoard until that's a community goal .
> 
> 4.Add a new policy rule to check specific metadata key
>   Decide to change nova codes instead of oslo.policy
> https://etherpad.openstack.org/p/policy_support_for_specific_metadata_keys
> 
> 5. Discuss oslo_messaging.rpc message encryption and security
> Trove implements this function in its code base, wan to code be
> included in oslo.messaging.
> kgiusti - followup with amrith on possible API (message digest)
> 
> 6. Feature updates & collect ideas
>1) Josh propose a new library to handle remote exceptions in an united
> way: http://pypi.python.org/pypi/failure
>Need improve it in code and documentation , test in gate , then adop
> it .
>gcb will talk with Nova PTL if nova want to adopt it.
>   2) new functions from neutron(ihrachys): ability to cancel in
> progress/blocked RPC requests in oslo.messaging
>   ihrachys will file a bug, describe use cases to track this.
> 
> we also did bug smash to reduce bug numbers in rest of time.
> 

A few topics came up outside of the Oslo room, or later in the week.

1. The new Deployment working group is interested in being able to
generate a data file listing all of the configuration options for
a service, to be used to drive a UI for filling in those options.
It isn't clear yet whether this will be a completely new addition
to the config generator in oslo.config, or if the existing generator
can be extended to support a new format (we talked about YAML).

2. We are looking at removing the warnerrors flag from pbr. It is
currently broken, but there is an unreleased patch to fix it.
Releasing that in its current state has a high chance of breaking
doc builds across the community, so I put together a patch to rename
it. Then Stephen pointed out that Sphinx 1.5 includes its own flag,
which can also be set in setup.cfg. We agreed it made more sense
to drop the flag from pbr and use that one, because it would be
backwards-compatible (in the sense that pbr currently doesn't honor
the flag it does claim to understand).  See
https://review.openstack.org/#/c/438510/ for Stephen's patch.

3. I intend to resume the work on making pbr include reno-generated
release notes text files in sdist packages. That will probably have
to wait until after the second milestone, unless someone else is
interested in picking it up.

Doug

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

[openstack-dev] [TripleO] Spinning up multinode environments using Heat

[James Slagle]

I wanted to share some work I've done around setting up multinode environments
and reproducing tripleo-ci jobs on those environments on OpenStack using Heat:

https://github.com/slagle/traas

traas is a set of Heat templates and wrapper scripts arond toci_gate_test.sh
mostly. You can think of traas as taking on the role that is done by nodepool
and devstack-gate in CI, but using Heat instead. I'm not *proposing* replacing
either of those tools in our actual CI jobs. traas could just be used when you
have access to an OpenStack cloud with Heat that you want to use for
TripleO development.

The Heat templates are used to bring up a multinode environment, and then
trigger some SoftwareDeployment resources on the undercloud node to
execute a tripleo-ci job.

The main template is:

https://github.com/slagle/traas/blob/master/templates/traas.yaml

You can see the resources there for an undercloud node and set of overcloud
nodes, etc.

Once the nodes are up, the main script that is triggered is:

https://github.com/slagle/traas/blob/master/scripts/traas.sh

That is a simple wrapper around toci_gate_test.sh. The
$TOCI_JOBTYPE variable (passed in via a Heat parameter) is what drives which job
is executed. So far I've tested with multinode-nonha-oooq and multinode-nonha.
Since it just executes toci_gate_test.sh, what tool tripleo-ci uses for that
jobtype is what tool gets used to execute the job (tripleo-quickstart,
tripleo.sh, etc).

In either case, it executes the ci job end to end and then leaves the
environment up at the end for inspection and/or development.

I should mention that I started with (inspired by) the templates from
openstack-virtual-baremetal:

https://github.com/cybertron/openstack-virtual-baremetal/tree/master/templates

which we are already using in CI to bring up OVB environments. The work in
traas takes that a bit further by adding multinode support and actually
triggering the CI job execution. We can integrate the traas work back into
openstack-virtual-baremetal if folks are open to that route.

Long term, I think it would be cool if we had a scenario where someone could
log in to Horizon, go to the Heat interface and just click a button or 2 to
bring up a TripleO multinode environment (with different pre-canned templates
for different releases, configurations, etc). This ought to be achievable
because the cli to start the traas stack is simply:

openstack stack create traas -t traas/templates/traas.yaml \
-e traas/templates/traas-resource-registry.yaml \
-e traas/templates/env.yaml

Note that I have found several issues/wrinkles with running toci_gate_test.sh
locally on a clean CentOS environment which I've started addressing in this
branch: https://review.openstack.org/#/q/topic:traas

Any feedback is welcome.

-- 
-- James Slagle
--

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

Re: [openstack-dev] [telemetry][heat] Removal of Aodh combination alarms

[Zane Bitter]

On 24/02/17 06:15, Julien Danjou wrote:

Hey,

We're about to remove the code for the deprecated combination alarm.

  https://review.openstack.org/#/c/429405/

I checked and as far as I can tell that should not break Heat gate, but
I'd prefer to be sure. So, Heat developers if you have some code relying
on it, let us know before we press the big +A button.


Looks like it merged and there was no breakage, so that's good.

How should we handle the (hidden) resource type in Heat?

http://git.openstack.org/cgit/openstack/heat/tree/heat/engine/resources/openstack/aodh/alarm.py#n227

Make handle_delete() return without doing anything, and raise an 
exception in all other handle_*() methods?


- ZB

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

[openstack-dev] [tripleo] On the road to Pike

[Emilien Macchi]

Here's a summary of what was said at PTG. Feel free to comment if I
missed something.


# NFV
Driver: skramaja
Summary: Support for OVS 2.6, Multi-queue and Jumbo Frames are already
making good progress. Need to investigate how to make "Role Specific
Parameters" for complex deployments.
Etherpad: https://etherpad.openstack.org/p/tripleo-ptg-nfv-updates
Blueprints:
1. Support for OVS 2.6 features for DPDK - Multi-queue and Jumbo Frames:
https://blueprints.launchpad.net/tripleo/+spec/ovs-2-6-features-dpdk
2. Add OVS 2.6 support in TripleO for DPDK:
https://blueprints.launchpad.net/tripleo/+spec/ovs-2-6-dpdk

# Whole disk images
Driver: yolanda
Summary:  Allow TripleO to use partition / volumes parameters when
building the image with tripleo-common. Also make the security
hardened image to be as flexible as possible. One of our OVB CI jobs
will cover the testing.
Etherpad: https://etherpad.openstack.org/p/TripleO_whole_disk_images
Blueprint: 
https://blueprints.launchpad.net/tripleo/+spec/build-whole-disk-images

# Container roadmap
Driver: flaper87
Summary: Goal is to support all services deployed in containers. Bring
new CI job for undercloud-container. Stabilize ovb-containers CI job.
Investigate Upgrades workflow.
Etherpad: 
https://etherpad.openstack.org/p/tripleo-composable-containers-undercloud
Blueprints:
1. Support for all services in containers:
https://blueprints.launchpad.net/tripleo/+spec/containerize-tripleo
2. Deploy a containerized undercloud:
https://blueprints.launchpad.net/tripleo/+spec/heat-undercloud

# Upgrades roadmap
Driver: shardy
Etherpad: https://etherpad.openstack.org/p/tripleo-ptg-pike-composable-upgrades
Actions:
1. More support for rolling upgrades, moving towards less
control-plane service downtime.
2. Operator driven upgrades, so Ansible playbooks are externally usable.
3. Add upgrade tasks for services introduced in Ocata.
4. Reducing the pain for service specific upgrades in future.
5. Stabilize CI jobs for scenario upgrades jobs. Run pingtest and make
jobs voting.
(please create blueprint)

# Python 3.5
Drivers: EmilienM, apevec
Etherpad: https://etherpad.openstack.org/p/tripleo-ptg-pike-python3
Actions:
1. Improve unit tests coverage in TripleO Python projects.
2. Run unit test coverage job in TripleO CI.
3. Investigate functional testing jobs for python-tripleoclient (using Fedora?).

# Tendrl for External Storage Deployment/Management
Driver: fultonj
Summary: Deploy Ceph using a Mistral workflow (which triggers
alternative Ceph deployment/management tools e.g. ceph-ansible or
Tendrl). CI coverage wanted that will require ceph-ansible + deps
packaging.
Etherpad: https://etherpad.openstack.org/p/tripleo-tendrl-integration
Blueprint: https://blueprints.launchpad.net/tripleo/+spec/tripleo-ceph-ansible
Spec: https://review.openstack.org/#/c/387631/

# Sample Environment Generator
Drivers: bnemec, jtomasek
Summary: Keeping in sync environments parameters with actual
parameters in the services, so sample environments & templates & UI
are synchronized with the same parameters & metadatas.
Etherpad: https://etherpad.openstack.org/p/tripleo-environment-generator
Blueprint: WIP (bnemec)
Actions:
1. Consider using a naming convention to work around the
passed-from-parent problem above? e.g private parameter could be
_ServiceNetMap ?
2. Add THT yaml-validate check that enforces all
non-passed-from-parent parameters are identical e.g same type,
description and constraints as they are global scope and passed via
parameter_defaults
3. Have environment generator update capabilities map as well as
environment files?

# Future of configuration management
Driver: EmilienM
Summary: This cross-deployment-project tried to figure out how to
generate a YAML file that would expose all parameters handled by
OpenStack, using oslo.config to generate it. In the future, this file
could be consumed by OpenStack Ansible, OpenStack Kubernetes, Kolla,
TripleO, etc by a single source of parameters. In the future, we could
think of a unified way to push configuration on containers / nodes
using this file, but for Pike the goal is to generate it and
investigate how we can use it.
Etherpad: https://etherpad.openstack.org/p/ansible-config-mgt
Blueprint / Spec: WIP (EmilienM + bnemec)

# Rework $bootstrap_node for composable roles
Driver: bandini
Summary: $bootstrap_node variable, used to find out the first
controller that is deployed needs to be reworked since the notion of
controller has been lost with the composable roles. Add
_short_service_bootstrap_node support for all services and
also move the db_sync out of the base profiles in puppet-tripleo are
the main actions.
Etherpad: 
https://etherpad.openstack.org/p/tripleo-ptg-pike-bootstrapnode-multinode
Blueprint: WIP (bandini)

# Composable Networking
Driver: shardy
Summary: Enable custom networks vs hard-coded network names. Will
require CI: need at least two jobs with net-iso, one with default
networks and one with custom networks.
Etherpad: 
https://ethe

[openstack-dev] [nova] Pike PTG recap - cells

[Matt Riedemann]

We talked about cells on Wednesday morning at the PTG. The full etherpad 
is here [1].


Searchlight integration
---

We talked a bit about what needs to happen for this, and it starts with 
getting the data into searchlight so that it can serve the REST API, 
which is being worked in this blueprint [2]. We want to get that done 
early in Pike.


We plan on making the use of Searchlight configurable in Nova since at 
first you might not even have anything in it, so listing instances 
wouldn't work. We're also going to attempt to merge-sort when listing 
instances across multiple cells but it's going to be a known issue that 
it will be slow.


For testing Nova with Searchlight, we need to start by enabling the 
Searchlight devstack plugin in the nova-next CI job, which I'll work on.


I'm going to talk to Kevin Zheng about seeing if he can spend some time 
on getting Nova to use Searchlight if it's (1) configured for use and 
(2) is available (the endpoint is in the service catalog). Kevin is a 
Searchlight core and familiar with the Nova API code, so he's a good 
candidate for working on this (assuming he's available and willing to 
own it).


Cells-aware gaps in the API
---

Dan Smith has started a blueprint [3] for closing gaps in the API which 
break in a multi-cell deployment. He has a test patch [4] to expose the 
failures and then they can be worked on individually. The pattern of the 
work is in [5]. Help is welcome here, so please attend the weekly cells 
meeting [6] if you want to help out.


Auto-discovery of compute hosts
---

The "discover_hosts_in_cells_interval" config option was introduced in 
Ocata which controls a periodic task in the scheduler to discover new 
unmapped compute hosts but it's not very efficient since it queries all 
cell mappings and then all compute nodes in each cell mapping and checks 
to see if those compute nodes are yet mapped to the cell in the nova_api 
database. Dan Smith has a series of changes [7] which should make that 
discovery process more efficient, it just needs to be cleaned up a bit.


Service arrangement
---

Dan Smith is working on a series of changes in both Nova and devstack 
for testing with multiple cells [8]. The general idea is that there will 
still be two nodes and two nova-compute services. There will be three 
nova-conductor services, one per cell, and then another top-level "super 
conductor" which is there for building instances and sending the server 
create down to one of the cells. All three conductors are going to be 
running in the subnode just to balance the resources a bit otherwise the 
primary node is going to be starved. The multi-cell job won't be running 
migration tests since we don't currently support instance move 
operations between cells. We're going to work a hack into the scheduler 
to restrict a move operation to the same cell the instance is already 
in. This means the live migration job will still be a single-cell setup 
where both nova-computes are in the same cell.


Getting rid of nova-consoleauth
---

There is an unfinished blueprint [9] from Paul Murray which melwitt is 
going to pick up for Pike. The idea is to move the tokens into the 
database so we don't care where the consoleauth service lives and then 
we can also kill the service.


[1] https://etherpad.openstack.org/p/nova-ptg-pike-cells
[2] 
https://blueprints.launchpad.net/nova/+spec/additional-notification-fields-for-searchlight

[3] https://blueprints.launchpad.net/nova/+spec/cells-aware-api
[4] https://review.openstack.org/#/c/433318/
[5] https://review.openstack.org/#/c/433362/
[6] http://eavesdrop.openstack.org/#Nova_Cellsv2_Meeting
[7] https://review.openstack.org/#/c/427901/
[8] https://review.openstack.org/#/c/436094/
[9] https://blueprints.launchpad.net/nova/+spec/convert-consoles-to-objects

--

Thanks,

Matt Riedemann

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

[openstack-dev] [kubernetes][kolla][openstack-helm][magnum] Kubernetes Day at OpenStack Summit NA 2017 announced!

[Ihor Dvoretskyi]

Hello everyone,

On behalf of Kubernetes Community and OpenStack SpeciaI Interest Group [0],
I'm happy to announce Kubernetes Day at OpenStack Summit NA 2017. The event
will be hosted by CNCF as a part of OpenStack’s Open Source Days in Boston
[1].

The CFP process is already open - feel free to submit your talk. More
detailed information about the event you may find at the CNCF's event page
[2].

Special thanks to CNCF, OpenStack Foundation, and individuals who made this
happen.

0. https://github.com/kubernetes/community/blob/
master/sig-openstack/README.md
1. https://www.openstack.org/summit/boston-2017/open-source-days/
2. https://www.cncf.io/event/openstack-north-america-2017
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] So long, farewell, auf wiedersehen

[Carter, Kevin]

It's been great working with you, you've done a lot for our community
and it'll be sad not seeing you around. Congratulations on the new
position and I wish you all the best!

Take care.

--

Kevin Carter
IRC: Cloudnull


On Wed, Feb 22, 2017 at 1:06 PM, Major Hayden  wrote:
> On 02/22/2017 11:48 AM, Truman, Travis wrote:
>> I’ve very much enjoyed being part of the OpenStack community over the past 
>> 14 months. My time in the OpenStack-Ansible community has been one of the 
>> most rewarding experiences of my career. However, my career is changing 
>> directions and I’ll no longer be able to invest the time and energy required 
>> to maintain my involvement in the community.
>
> Thanks for all you've done for the project and for all you've done for the 
> OpenStack-Ansible community members, too.  We wish you the best in your 
> future endeavors! :)
>
> --
> Major Hayden
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] PTG Summary

[Kenji Ishii]

Hi, forks

I'm very very sorry that when I see this page, I'd translated to another 
language with mistake.. 

Can anyone do back to previous one?

---
Kenji Ishii


> -Original Message-
> From: Rob Cresswell [mailto:robert.cressw...@outlook.com]
> Sent: Tuesday, February 28, 2017 12:28 AM
> To: OpenStack Dev Mailer 
> Subject: [openstack-dev] [horizon] PTG Summary
> 
> Hi everyone!
> 
> Quick summary of the PTG for those who missed it. Here's the etherpad,
> with notes inline: https://etherpad.openstack.org/p/horizon-ptg-pike
> 
> We spent the first morning discussing plugins, with several plugin devs
> dropping in to discuss their issues. Several issues were mentioned that
> Horizon needs to improve upon to help the plugins:
> 
> - Functional testing for JS
> - Extensible quotas
> - Use [horizon-plugin] mailer tag to keep people up to date
> 
> Further specifics can be found in the etherpad notes.
> 
> The afternoon and following morning were spent analysing specific
> blueprints, and then doing a general blueprint review. This has resulted
> in a really refined blueprint list:
> https://blueprints.launchpad.net/horizon, which we'll be using in place
> of a priorities etherpad this cycle. That's right, tracking tools actually
> being used for tracking. Huzzah!
> 
> If there are any disagreements on blueprints, or you feel I have closed
> something unfairly, please get in touch on IRC (robcresswell) or email
> me.
> 
> Two other cross project sessions are also linked in the etherpad; one with
> keystone and another with i18n. These were really helpful in understanding
> how Horizon can work better with these projects. Please review the
> etherpads to see what work needs to be done.
> 
> Rob
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] PTG summary

[Ben Nemec]

On 02/27/2017 03:30 PM, Doug Hellmann wrote:

Excerpts from ChangBo Guo's message of 2017-02-25 00:07:21 +0800:

Oslo folks,

This is summary of  oslo PTG schedule during one and half days. You can
check the details in etherpad link:
https://etherpad.openstack.org/p/oslo-ptg-pike

1. oslo.messaging: consistent names for general driver configuration options
   Some of supported drviers have various option configuration names with
for common usage, This has led to a plethora of different configuration
options that complicates the   development of Day 1 deployment and
configuration tools. We propose that 'scrub' the configuration namespace
and come up with common generic names that can be shared among the various
drivers. Note: this is *not* calling for moving these configuration items
'up' to the DEFAULT group.  Each driver should be able to have its own
value for any given configuration setting.  This is necessary for the dual
backend deployment scenario.

2. Messaging Experiences towards hybrid backends
   Share experience and progress towards introducing dual messaging backend
operation :
https://docs.google.com/presentation/d/1Y-3gH8rxrU5KagvDQiqpByfvmgM8no-PLn1O0IT5PCs/edit?usp=sharing

3.How to make oslo work done in an efficient way
   1)Track bugs & reviews accoding to their priorities
   2)Record general core reviewers' focus to help get help from them.
https://etherpad.openstack.org/p/oslo-pike-tracking
   3) Don't migrate to StoryBoard until that's a community goal .

4.Add a new policy rule to check specific metadata key
  Decide to change nova codes instead of oslo.policy
https://etherpad.openstack.org/p/policy_support_for_specific_metadata_keys

5. Discuss oslo_messaging.rpc message encryption and security
Trove implements this function in its code base, wan to code be
included in oslo.messaging.
kgiusti - followup with amrith on possible API (message digest)

6. Feature updates & collect ideas
   1) Josh propose a new library to handle remote exceptions in an united
way: http://pypi.python.org/pypi/failure
   Need improve it in code and documentation , test in gate , then adop
it .
   gcb will talk with Nova PTL if nova want to adopt it.
  2) new functions from neutron(ihrachys): ability to cancel in
progress/blocked RPC requests in oslo.messaging
  ihrachys will file a bug, describe use cases to track this.

we also did bug smash to reduce bug numbers in rest of time.



A few topics came up outside of the Oslo room, or later in the week.

1. The new Deployment working group is interested in being able to
generate a data file listing all of the configuration options for
a service, to be used to drive a UI for filling in those options.
It isn't clear yet whether this will be a completely new addition
to the config generator in oslo.config, or if the existing generator
can be extended to support a new format (we talked about YAML).


Emilien and I are planning to write up a spec with details about what 
we'd like to do and why.




2. We are looking at removing the warnerrors flag from pbr. It is
currently broken, but there is an unreleased patch to fix it.
Releasing that in its current state has a high chance of breaking
doc builds across the community, so I put together a patch to rename
it. Then Stephen pointed out that Sphinx 1.5 includes its own flag,
which can also be set in setup.cfg. We agreed it made more sense
to drop the flag from pbr and use that one, because it would be
backwards-compatible (in the sense that pbr currently doesn't honor
the flag it does claim to understand).  See
https://review.openstack.org/#/c/438510/ for Stephen's patch.


I tried this on tripleo-docs and it seems to be working.  Looks like a 
good way forward to me.




3. I intend to resume the work on making pbr include reno-generated
release notes text files in sdist packages. That will probably have
to wait until after the second milestone, unless someone else is
interested in picking it up.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] PTG Summary

[Kenji Ishii]

Hi forks,

I added the English version which I had at the top of the page without deleting 
current one.
As far as I see, there looks no points missing in former. 
but if anyone know the recent change and find differences, I'd be so happy if 
you reflect that diff.

I'm so sorry and thanks for comments.

Best regards,
---
Kenji Ishii


> -Original Message-
> From: Kenji Ishii [mailto:ken-is...@sx.jp.nec.com]
> Sent: Tuesday, February 28, 2017 8:39 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [horizon] PTG Summary
> 
> Hi, forks
> 
> I'm very very sorry that when I see this page, I'd translated to another
> language with mistake..
> 
> Can anyone do back to previous one?
> 
> ---
> Kenji Ishii
> 
> 
> > -Original Message-
> > From: Rob Cresswell [mailto:robert.cressw...@outlook.com]
> > Sent: Tuesday, February 28, 2017 12:28 AM
> > To: OpenStack Dev Mailer 
> > Subject: [openstack-dev] [horizon] PTG Summary
> >
> > Hi everyone!
> >
> > Quick summary of the PTG for those who missed it. Here's the etherpad,
> > with notes inline: https://etherpad.openstack.org/p/horizon-ptg-pike
> >
> > We spent the first morning discussing plugins, with several plugin
> > devs dropping in to discuss their issues. Several issues were
> > mentioned that Horizon needs to improve upon to help the plugins:
> >
> > - Functional testing for JS
> > - Extensible quotas
> > - Use [horizon-plugin] mailer tag to keep people up to date
> >
> > Further specifics can be found in the etherpad notes.
> >
> > The afternoon and following morning were spent analysing specific
> > blueprints, and then doing a general blueprint review. This has
> > resulted in a really refined blueprint list:
> > https://blueprints.launchpad.net/horizon, which we'll be using in
> > place of a priorities etherpad this cycle. That's right, tracking
> > tools actually being used for tracking. Huzzah!
> >
> > If there are any disagreements on blueprints, or you feel I have
> > closed something unfairly, please get in touch on IRC (robcresswell)
> > or email me.
> >
> > Two other cross project sessions are also linked in the etherpad; one
> > with keystone and another with i18n. These were really helpful in
> > understanding how Horizon can work better with these projects. Please
> > review the etherpads to see what work needs to be done.
> >
> > Rob
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [deployment][TripleO][kolla][ansible][fuel] Next steps for cross project collaboration

[Michał Jastrzębski]

So first, I'd like to say that my poor English skills aren't enough to
emphasize how much I love this idea.
I think instead of adding yet-another-irc-channel how about create
weekly meetings? We can rant in scheduled time and it probably will
get more attention. That, mailing list with dedicated tag and WG would
be great imho. We could get some room in future PTGs too then.

Am I making sense?
Michal

On 27 February 2017 at 13:08, Jesse Pretorius
 wrote:
> Comments in-line
>
> On 2/27/17, 4:02 PM, "Steven Hardy"  wrote:
>
> If I go ahead and do this is "deployment" a sufficiently project-neutral
> term to proceed with?
>
> I think so.
>
> I'd suggest we start with an informal WG, which it seems just requires an
> update to the wiki, e.g no need for any formal project team at this point?
>
> A WG is what I had in mind.
>
> Likewise I know some folks have expressed an interest in an IRC channel
> (openstack-deployment?), I'm happy to start with the ML but open to IRC
> also if someone is willing to set up the channel.
>
> Personally I think we should use #openstack-dev instead. It’s the traditional 
> place for cross-project communication, is less exclusive and much like this 
> mailing list brings more people into the conversation.
>
> Perhaps we can start by using the tag "deployment" in all cross-project ML
> traffic, then potentially discuss IRC (or even regular meetings) if it
> becomes apparrent these would add value beyond ML discussion?
>
> Sure, I don’t have any strong feelings about the tag. The tag [deployment] 
> makes sense to me.
>
>
> 
> Rackspace Limited is a company registered in England & Wales (company 
> registered number 03897010) whose registered office is at 5 Millington Road, 
> Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
> viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
> contain confidential or privileged information intended for the recipient. 
> Any dissemination, distribution or copying of the enclosed material is 
> prohibited. If you receive this transmission in error, please notify us 
> immediately by e-mail at ab...@rackspace.com and delete the original message. 
> Your cooperation is appreciated.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [deployment][TripleO][kolla][ansible][fuel] Next steps for cross project collaboration

[Steven Dake (stdake)]

I think IRC is more effective for real time collaboration then waiting a week 
for a meeting.  We shouldn’t have to rant at all since we are all part of 
OpenStack ☺

Regards
-steve


-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, February 27, 2017 at 5:52 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [deployment][TripleO][kolla][ansible][fuel] Next 
steps for cross project collaboration

So first, I'd like to say that my poor English skills aren't enough to
emphasize how much I love this idea.
I think instead of adding yet-another-irc-channel how about create
weekly meetings? We can rant in scheduled time and it probably will
get more attention. That, mailing list with dedicated tag and WG would
be great imho. We could get some room in future PTGs too then.

Am I making sense?
Michal

On 27 February 2017 at 13:08, Jesse Pretorius
 wrote:
> Comments in-line
>
> On 2/27/17, 4:02 PM, "Steven Hardy"  wrote:
>
> If I go ahead and do this is "deployment" a sufficiently 
project-neutral
> term to proceed with?
>
> I think so.
>
> I'd suggest we start with an informal WG, which it seems just 
requires an
> update to the wiki, e.g no need for any formal project team at this 
point?
>
> A WG is what I had in mind.
>
> Likewise I know some folks have expressed an interest in an IRC 
channel
> (openstack-deployment?), I'm happy to start with the ML but open to 
IRC
> also if someone is willing to set up the channel.
>
> Personally I think we should use #openstack-dev instead. It’s the 
traditional place for cross-project communication, is less exclusive and much 
like this mailing list brings more people into the conversation.
>
> Perhaps we can start by using the tag "deployment" in all 
cross-project ML
> traffic, then potentially discuss IRC (or even regular meetings) if it
> becomes apparrent these would add value beyond ML discussion?
>
> Sure, I don’t have any strong feelings about the tag. The tag 
[deployment] makes sense to me.
>
>
> 
> Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [QA] The end-user test suite for OpenStack clusters

[Sam P]

Hi Dims, Hi gmann,

Thanks guys.
 Slowly recovering from PTG jet lag

OK then.., I will start working on this.
I would also like to coordinate this work with LCOO [1] team,  where
we can get valuable feedback and contributions..
I will give you update on next QA IRC on 0900 UTC meeting, which is
9th of March?
(1700 UTC meeting is difficult for me, however I will definitely be
there if needed)

[1] https://wiki.openstack.org/wiki/LCOO
--- Regards,
Sampath



On Fri, Feb 24, 2017 at 8:57 PM, Ghanshyam Mann  wrote:
> Yea, agree with dims.
>
> Sampath ,
>
> Thanks for taking over this, it is really great help. Please update the
> current spec with approaches you have. Timur help will be great if he show
> up sometime.
>
> Also we will add destructive testing as one of weekly meeting agenda and
> make sure you will get all help & required attention from QA team.
>
> -gmann
>
>
> On Fri, Feb 24, 2017 at 7:26 AM, Davanum Srinivas  wrote:
>>
>> Sampath,
>>
>> I am not sure if you will hear back from Timur soon as he may not be
>> working on this stuff anymore (in Mirantis). So i'd recommend picking
>> up the work if you don't hear from him soon.
>>
>> Thanks,
>> Dims
>>
>> On Thu, Feb 23, 2017 at 3:41 PM, Sam P  wrote:
>> > Hi Timur,
>> >
>> >  The current status of this work is,
>> > 1) The QA user story for destructive testing of OpenStack cloud [1] is
>> > merged .
>> > 2) The spec for a new framework which will focus on HA/failover and
>> > destructive testing  [2] has no update since Nov 30 2016.
>> > 3) The commit for the new repository [3]  has abandoned due to no
>> > update after Nov 29 2016.
>> >
>> > Currently, I am working on 3rd party destructive/HA testing CI for
>> > Masakari[4] and very much interested in this work.
>> > I will keep working on [1] with PWG.
>> > Please let me know your plans for [2], and [3].
>> > If it is difficult for you to continue, I would love to continue your
>> > work on [2], and [3].
>> >
>> > [1] https://review.openstack.org/#/c/396142
>> > [2] https://review.openstack.org/#/c/399618
>> > [3] https://review.openstack.org/#/c/374667
>> > [4] https://wiki.openstack.org/wiki/Masakari
>> > --- Regards,
>> > Sampath
>> >
>> >
>> >
>> > On Mon, Nov 28, 2016 at 6:37 AM, Timur Nurlygayanov
>> >  wrote:
>> >> Hi team,
>> >>
>> >> here is a short update:
>> >>
>> >> 1) The QA user story for destructive testing of OpenStack cloud is on
>> >> review
>> >> [1].
>> >> 2) The spec for a new framework which will focus on HA/failover and
>> >> destructive testing is no review [2].
>> >> 3) The commit for the new repository is on review [3] as well.
>> >>
>> >> [1] https://review.openstack.org/#/c/396142
>> >> [2] https://review.openstack.org/#/c/399618
>> >> [3] https://review.openstack.org/#/c/374667
>> >>
>> >>
>> >> On Fri, Oct 14, 2016 at 3:47 AM, Ghanshyam Mann
>> >>  wrote:
>> >>>
>> >>> I like os-faults library which can provide the abstraction over
>> >>> different
>> >>> destructive actions like reboot/poweroff node etc.
>> >>>
>> >>>
>> >>>
>> >>> But not much clear about Stepler that what all tests it will contain.
>> >>> Tempest do have scenario tests which can hit the production env with
>> >>> significant way of testing scenario.
>> >>>
>> >>> It can cover the end user scenario also which involves the interaction
>> >>> of
>> >>> public OpenStack APIs and always in enhancement state by adding more
>> >>> and
>> >>> more scenario tests.
>> >>>
>> >>>
>> >>>
>> >>> Few query over Stepler as separate project:
>> >>>
>> >>> 1.   Is Stepler will cover only tests which hits the node level
>> >>> action(reboot, HA etc)?
>> >>>
>> >>> 2.   This should not mix the scenario tests which are in Tempest
>> >>> scope
>> >>> because that can make confusion for developers (where to add scenario
>> >>> tests)
>> >>> as well as for tester(from where to run what scenario tests).
>> >>>
>> >>> 3.   How we make sure those tests run fine or at least run while
>> >>> adding.
>> >>>
>> >>> a.   I think devstack enhancement for multi-node etc can do this
>> >>> as
>> >>> mentioned by you also.
>> >>>
>> >>> b.  If so then why not adding those tests in Tempest only using
>> >>> os-faults lib ?
>> >>>
>> >>>
>> >>>
>> >>> Overall I feel os-faults  as lib is really nice idea but tests scope
>> >>> can
>> >>> go in Tempest under HW_scenario  (or something else) till it does not
>> >>> break
>> >>> basic principle of Tempest.
>> >>>
>> >>>
>> >>>
>> >>> Thanks
>> >>>
>> >>> gmann
>> >>>
>> >>>
>> >>>
>> >>> From: Timur Nurlygayanov [mailto:tnurlygaya...@mirantis.com]
>> >>> Sent: 06 October 2016 20:09
>> >>> To: OpenStack Development Mailing List (not for usage questions)
>> >>> 
>> >>> Subject: Re: [openstack-dev] [QA] The end-user test suite for
>> >>> OpenStack
>> >>> clusters
>> >>>
>> >>>
>> >>>
>> >>> Ken, it is a good idea!
>> >>>
>> >>>
>> >>>
>> >>> The plan is to develop os-faults as a library which will be able
>> >>>
>> >>> to manage cluster nodes and OpenStack service

Re: [openstack-dev] [nova] Pike PTG recap - cells

[Zhenyu Zheng]

Matt,

Thanks for the recap, it's a pity I cannot attend PTG due to personal
reason, I will be willing to take the work you mentioned, and will check
the details with you.

And another thing, I don't know whether you guys discussed or not, I saw in
[1] we are talking about adding tags field(and others of cause) to the
instance notification
payload, to be able to send during instance.create and instance.update. The
fact is that currently we cannot add tags during boot, nor we send
notifications when we
add/update/delete tags latter(it is a direct DB change and no
instance.update notification has been sent out), so for tags field, we have
to wait for another instance.update
action to get the latest info. And I have already tried to working on the
boot thing[2] and already planned to work on the tag notification thing[3].

So, are there any plans about those? Maybe it is OK to send out
instance.update notification in tags actions once [1] got merged?

Thanks,

Kevin Zheng

[1] https://blueprints.launchpad.net/nova/+spec/additional-notif
ication-fields-for-searchlight
[2]
https://blueprints.launchpad.net/nova/+spec/support-tag-instance-when-boot
[3] https://blueprints.launchpad.net/nova/+spec/send-tag-notification


On Tue, Feb 28, 2017 at 6:33 AM, Matt Riedemann  wrote:

> We talked about cells on Wednesday morning at the PTG. The full etherpad
> is here [1].
>
> Searchlight integration
> ---
>
> We talked a bit about what needs to happen for this, and it starts with
> getting the data into searchlight so that it can serve the REST API, which
> is being worked in this blueprint [2]. We want to get that done early in
> Pike.
>
> We plan on making the use of Searchlight configurable in Nova since at
> first you might not even have anything in it, so listing instances wouldn't
> work. We're also going to attempt to merge-sort when listing instances
> across multiple cells but it's going to be a known issue that it will be
> slow.
>
> For testing Nova with Searchlight, we need to start by enabling the
> Searchlight devstack plugin in the nova-next CI job, which I'll work on.
>
> I'm going to talk to Kevin Zheng about seeing if he can spend some time on
> getting Nova to use Searchlight if it's (1) configured for use and (2) is
> available (the endpoint is in the service catalog). Kevin is a Searchlight
> core and familiar with the Nova API code, so he's a good candidate for
> working on this (assuming he's available and willing to own it).
>
> Cells-aware gaps in the API
> ---
>
> Dan Smith has started a blueprint [3] for closing gaps in the API which
> break in a multi-cell deployment. He has a test patch [4] to expose the
> failures and then they can be worked on individually. The pattern of the
> work is in [5]. Help is welcome here, so please attend the weekly cells
> meeting [6] if you want to help out.
>
> Auto-discovery of compute hosts
> ---
>
> The "discover_hosts_in_cells_interval" config option was introduced in
> Ocata which controls a periodic task in the scheduler to discover new
> unmapped compute hosts but it's not very efficient since it queries all
> cell mappings and then all compute nodes in each cell mapping and checks to
> see if those compute nodes are yet mapped to the cell in the nova_api
> database. Dan Smith has a series of changes [7] which should make that
> discovery process more efficient, it just needs to be cleaned up a bit.
>
> Service arrangement
> ---
>
> Dan Smith is working on a series of changes in both Nova and devstack for
> testing with multiple cells [8]. The general idea is that there will still
> be two nodes and two nova-compute services. There will be three
> nova-conductor services, one per cell, and then another top-level "super
> conductor" which is there for building instances and sending the server
> create down to one of the cells. All three conductors are going to be
> running in the subnode just to balance the resources a bit otherwise the
> primary node is going to be starved. The multi-cell job won't be running
> migration tests since we don't currently support instance move operations
> between cells. We're going to work a hack into the scheduler to restrict a
> move operation to the same cell the instance is already in. This means the
> live migration job will still be a single-cell setup where both
> nova-computes are in the same cell.
>
> Getting rid of nova-consoleauth
> ---
>
> There is an unfinished blueprint [9] from Paul Murray which melwitt is
> going to pick up for Pike. The idea is to move the tokens into the database
> so we don't care where the consoleauth service lives and then we can also
> kill the service.
>
> [1] https://etherpad.openstack.org/p/nova-ptg-pike-cells
> [2] https://blueprints.launchpad.net/nova/+spec/additional-notif
> ication-fields-for-searchlight
> [3] https://blueprints.launchpad.net/nova/+spec/cells-aware-

Re: [openstack-dev] [ansible]Octavia ansible script

[Santhosh Fernandes]

Thanks Major Hayden,

Hello German,

I don't have access to repo git://
git.openstack.org/openstack/openstack-ansible-os_octavia

Can you provide us access ?

Thanks,
Santhosh






On Tue, Feb 7, 2017 at 7:37 PM, Major Hayden 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 02/07/2017 12:00 AM, Santhosh Fernandes wrote:
> > Can we know the status of octavia ansible script ?
> >
> > Link :- https://blueprints.launchpad.net/~german-eichberger <
> https://blueprints.launchpad.net/%7Egerman-eichberger>
> >
> > Is there any version available for beta testing. Can you provide us
> link? or time line of availability.
>
> Hello Santosh,
>
> Although I drafted the spec[0], German Eichberger has taken over the work
> on the WIP patchset[1].  He would be the best person to discuss timelines
> and remaining work to be done.
>
> [0] http://specs.openstack.org/openstack/openstack-ansible-
> specs/specs/mitaka/lbaasv2.html
> [1] https://review.openstack.org/#/c/417210/
>
> - --
> Major Hayden
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJYmdSOAAoJEHNwUeDBAR+xkh0P/25yqkYIIxPuO/uvV+jNdiny
> NMxNClMfNxpKagCjokJyoMvyVDVX0VR71RloEeigOrTGTP7goAotn99J0pUK+je/
> X7zU7POwqV92mAj/3gU7uWm1792EZNCWNpnd9IQiik9PfEcLPmmW1FZeuxyY/l8K
> ZE3VOAId0lHaZYbHXR9GCLzy5QwwXM1kg1+Ub1ivIbU3Q81Ais3L64KXLth7ahtu
> 5dIaCAKZ6uqOVRe336kI9aYPv5N4Fpwt5OkZUdGf4iNc/fivAjrGxaLt9H0ldZJQ
> lsbOl1wtjlYJwreQWVGaNBEx/F1UZocnnvzUe9vAUIY2leTZ4eQck16fEkbkRe6b
> Zl+o/GVh0mwS+IBjZcilJxQ7PoOX/07Z2wZOHuy8ihUIkM/L2ySP3TBWImv5a5H0
> eQW1uK1B45j68E61oEuyW9DvNCWNTltUwD/FQNk833vFAtv35eqMRF1vhx3pPwmO
> GI1SQC55n0q96DF+5JedkAVy3qXwgt4CQwxvku8meD0hFb7XpWwy5DBd5p4ZbBb4
> XpjlsGkLzBK0uyLPyXaZ0LbFJ3Czp68Gbys09yLxjGI+P+PFWuWGVgoL/+FV9XA2
> H7St0aFZJgM0cLFYYQF1ols48SbPUp3HchexaXgltMfGYy2A3x/nnbEJSPtH7Vp9
> V9TEomffspXHgMQ2U3R5
> =BmgA
> -END PGP SIGNATURE-
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Zun] Choose a project mascot

[Hongbin Lu]

Hi all,

We discussed the mascot choice a few times. At the last team meeting, we 
decided to choose dolphins as the Zun’s mascot. Thanks Pradeep for proposing 
this mascot and thanks all for providing feedback.

Best regards,
Hongbin

From: Pradeep Singh [mailto:ps4openst...@gmail.com]
Sent: February-16-17 10:46 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Zun] Choose a project mascot

I was thinking about falcon(light, powerful and fast), or dolphins or tiger.

On Wed, Feb 15, 2017 at 12:29 AM, Hongbin Lu 
mailto:hongbin...@huawei.com>> wrote:
Hi Zun team,

OpenStack has a mascot program [1]. Basically, if we like, we can choose a 
mascot to represent our team. The process is as following:
* We choose a mascot from the natural world, which can be an animal (i.e. fish, 
bird), natural feature (i.e. waterfall) or other natural element (i.e. flame).
* Once we choose a mascot, I communicate the choice with OpenStack foundation 
staff.
* Someone will work on a draft based on the style of the family of logos.
* The draft will be sent back to us for approval.

The final mascot will be used to present our team. All, any idea for the mascot 
choice?

[1] https://www.openstack.org/project-mascots/

Best regards,
Hongbin

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [nova] keystonauth catalog work arounds hiding transition issues

[Jamie Lennox]

On 27 February 2017 at 08:56, Sean Dague  wrote:

> We recently implemented a Nova feature around validating that project_id
> for quotas we real in keystone. After that merged, trippleo builds
> started to fail because their undercloud did not specify the 'identity'
> service as the unversioned endpoint.
>
> https://github.com/openstack/nova/blob/8b498ce199ac4acd94eb33a7f47c05
> ee0c743c34/nova/api/openstack/identity.py#L34-L36
> - (code merged in Nova).
>
> After some debug, it was clear that '/v2.0/v3/projects/...' was what was
> being called. And after lots of conferring in the Keystone room, we
> definitely made sure that the code in question was correct. The thing I
> wanted to do was make the failure more clear.
>
> The suggestion was made to use the following code approach:
>
> https://review.openstack.org/#/c/438049/6/nova/api/openstack/identity.py
>
> resp = sess.get('/projects/%s' % project_id,
> endpoint_filter={
> 'service_type': 'identity',
> 'version': (3, 0)
> },
> raise_exc=False)
>
>
> However, I tested that manually with an identity =>
> http:///v2.0 endpoint, and it passes. Which confused me.
>
> Until I found this -
> https://github.com/openstack/keystoneauth/blob/
> 3364703d3b0e529f7c1b7d1d8ea81726c4f5f121/keystoneauth1/discover.py#L313
>
> keystonauth is specifically coding around the keystone transition from a
> versioned /v2.0 endpoint to an unversioned one.
>
>
> While that is good for the python ecosystem using it, it's actually
> *quite* bad for the rest of our ecosystem (direct REST, java, ruby, go,
> js, php), because it means that all other facilities need the same work
> around. I actually wonder if this is one of the in the field reasons for
> why the transition from v2 -> v3 is going slow. That's actually going to
> potentially break a lot of software.
>
> It feels like this whole discovery version hack bit should be removed -
> https://review.openstack.org/#/c/438483/. It also feels like a migration
> path for non python software in changing the catalog entries needs to be
> figured out as well.
>
> I think on the Nova side we need to go back to looking for bogus
> endpoint because we don't want issues like this hidden from us.
>
> -Sean


So I would completely agree, I would like to see this behaviour
removed. However
it was done very intentionally - and at the time it was written it was
needed.

This is one of a number of situations where keystoneauth tried its best to
paper over inconsistencies in OpenStack APIs because to various levels of
effectiveness almost all the python clients were doing this. Any whilst we
have slowly pushed the documentation and standard deployment procedures to
unversioned URLs whilst this hack was maintained in keystoneauth we didn't
have to fix it individually for every client.

Where python and keystoneauth are different from every other language is
that the services themselves are written in python and using these
libraries and inter-service communication had to continue to work
throughout the transition. You may remember the fun we had trying to change
to v3 auth and unversioned URLs in devstack? This hack is what made it
possible at all. As you say this is extremely difficult for other
languages, but something there isn't a solution for whilst this transition
is in place.

Anyway a few cycles later we are in a different position and a new service
such as the placement API can decide that it shouldn't work at all if the
catalog isn't configured as OpenStack advises. This is great! We can
effectively force deployments to transition to unversioned URLs. We can't
change the default behaviour in keystoneauth but it should be relatively
easy to give you an adapter that doesn't do this. Probably something like
[1]. I also filed it as a bug, which links to this thread [2], but could
otherwise do with some more detail.

Long story short, sorry but it'll have to be a new flag. Yes, keystoneauth
is supposed to be a low-level request maker, but it is also trying to paper
over a number of historical bad decisions so at the very least the user
experience is correct and we don't have clients re-inventing it themselves.

[1] https://review.openstack.org/#/c/438788/
[2] https://bugs.launchpad.net/keystoneauth/+bug/1668484
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] PTG Summary

[Richard Jones]

On 28 February 2017 at 02:28, Rob Cresswell
 wrote:
> Quick summary of the PTG for those who missed it. Here's the etherpad, with
> notes inline: https://etherpad.openstack.org/p/horizon-ptg-pike

Was there much discussion around project health, and the lack of core
review capacity?


 Richard

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

Re: [openstack-dev] [third-party][ci] Transition your devstack-gate based CI to local.conf

[Nilesh Savant]

Hello Mikhail,



We are operating CI for Veritas HyperScale, Due to this changes our CI started 
failing,



Could you please help us by providing the sample local.conf file as per new 
changes.



It will be great if you can point us to any of the working CI with your changes 
for reference.



Thanks & Regards,

Nilesh Savant

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

[openstack-dev] [murano]An error occured when I executed environment-deploy

[渥美 慶彦]

Hi everyone,

I tried to execute "environment-deploy", but failed.
2017-02-27 15:40:21.066 13046 ERROR murano.common.engine [-]
  keystoneauth1.exceptions.catalog.EndpointNotFound: Endpoint for 
unknown service

(Omitted)

auth_uri is equal to that one in nova.conf.
I refered to
http://egonzalez.org/murano-in-rdo-openstack-manual-installation/
after "Import ApacheHttpServer package".
Do you have information?

My environment:
 CentOS 7
 OpenStack Mitaka(Packstack), including Heat
 Murano[
 openstack-murano-api-2.0.0-2.el7.noarch
 python2-muranoclient-0.8.6-1.el7.noarch
 openstack-murano-common-2.0.0-2.el7.noarch
 openstack-murano-engine-2.0.0-2.el7.noarch
 openstack-murano-doc-2.0.0-2.el7.noarch
 ](yum install)
 Base Murano package:tag2.0.0

Thank you.
--

NTTソフトウェア株式会社
クラウド＆セキュリティ事業部　第一事業ユニット
渥美 慶彦（Atsumi Yoshihiko）
〒220-0012
横浜市西区みなとみらい4-4-5 横浜アイマークプレイス13F
TEL：045-212-7539
FAX：045-212-9800
E-mail：atsumi.yoshih...@po.ntts.co.jp



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

Re: [openstack-dev] [telemetry][heat] Removal of Aodh combination alarms

[Sergey Kraynev]

Zane,
as I understand, all related code was removed. Probably we may to remove
our Hidden resource too.

If we want to have hidden resource, then probably as you mentioned will be
enough to raise Exceptions and execute nothing for handle_delete.

On 28 February 2017 at 01:36, Zane Bitter  wrote:

> On 24/02/17 06:15, Julien Danjou wrote:
>
>> Hey,
>>
>> We're about to remove the code for the deprecated combination alarm.
>>
>>   https://review.openstack.org/#/c/429405/
>>
>> I checked and as far as I can tell that should not break Heat gate, but
>> I'd prefer to be sure. So, Heat developers if you have some code relying
>> on it, let us know before we press the big +A button.
>>
>
> Looks like it merged and there was no breakage, so that's good.
>
> How should we handle the (hidden) resource type in Heat?
>
> http://git.openstack.org/cgit/openstack/heat/tree/heat/engin
> e/resources/openstack/aodh/alarm.py#n227
>
> Make handle_delete() return without doing anything, and raise an exception
> in all other handle_*() methods?
>
> - ZB
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] Problem in visualizing port-mirroring information

[Manik Bindlish]

Hi All,

I am facing an issue in visualizing port-mirroring information.


1.)Created 2 VMs:

VM1:  ubuntu3(10.0.0.3,  floating IP: 192.168.200.252) - Tap service created

VM2:  ubuntu2(10.0.0.12,  floating ip: 192.168.200.250) - Tap flow created

2.)Connected to bridge router: br-ex(192.168.200.11)

3.)Pinging google is possible and can be check from br-ex



Problem: Not able to get the packet info on ubuntu3 where tap service is 
running.

Ports info:
ubuntu@openstack-nti-11:/opt/stack/devstack$ neutron port-show 
19526048-98d9-4e6c-8205-dddfcaf8f2b2
neutron CLI is deprecated and will be removed in the future. Use openstack CLI 
instead.
+---+-+
| Field | Value 
  |
+---+-+
| admin_state_up| True  
  |
| allowed_address_pairs |   
  |
| binding:host_id   | openstack-nti-11  
  |
| binding:profile   | {}
  |
| binding:vif_details   | {"port_filter": true, "ovs_hybrid_plug": true}
  |
| binding:vif_type  | ovs   
  |
| binding:vnic_type | normal
  |
| created_at| 2017-02-22T09:59:51Z  
  |
| description   |   
  |
| device_id | 843fe80f-971a-43e3-986c-31d19bef3898  
  |
| device_owner  | compute:None  
  |
| extra_dhcp_opts   |   
  |
| fixed_ips | {"subnet_id": "398b77d2-49aa-4d29-ac4d-f0fd14943120", 
"ip_address": "10.0.0.3"} |
|   | {"subnet_id": "401e3dde-1504-4620-8bbc-0ad6e54b0570", 
"ip_address": "fdaa:99df:2497:0:f816:3eff:feeb:52f2"} |
| id| 19526048-98d9-4e6c-8205-dddfcaf8f2b2  
  |
| mac_address   | fa:16:3e:eb:52:f2 
  |
| name  |   
  |
| network_id| 7fae0053-aeeb-44ac-9336-41b9cae8a9ba  
  |
| port_security_enabled | True  
  |
| project_id| 9c342a60b7cd4e8cacc8c5f6f92e80e6  
  |
| revision_number   | 10
  |
| security_groups   | 13e4320a-bc74-4303-a55d-67a0f092a066  
  |
| status| ACTIVE
  |
| tags  |   
  |
| tenant_id | 9c342a60b7cd4e8cacc8c5f6f92e80e6  
  |
| updated_at| 2017-02-22T10:00:10Z  
  |
+---+-+


ubuntu@openstack-nti-11:/opt/stack/devstack$ neutron port-show 
dde6689e-4f0f-4fe2-9d28-1182ef03e113
neutron CLI is deprecated and will be removed in the future. Use openstack CLI 
instead.
+---+--