Re: [openstack-dev] [all] [tc] Policy Goal Queens-2 Update

[hie...@vn.fujitsu.com]

FYI, I have updated the topic for Heat's works [1]. And finally no more 
projects in 'Not Started' list. :-)

[1]. 
https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:policy-and-docs-in-code

Regards,
Hieu

> -Original Message-
> From: Lance Bragstad [mailto:lbrags...@gmail.com]
> Sent: Friday, December 01, 2017 12:01 PM
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> Subject: Re: [openstack-dev] [all] [tc] Policy Goal Queens-2 Update
> 
> 
> 
> On 11/30/2017 07:00 PM, hie...@vn.fujitsu.com wrote:
> > Lance,
> >
> >>> For the Swift project, I don't see oslo.policy in requirements.txt
> >>> for now, then not sure they need to implement policy in code and the
> >>> we got the same
> >> thing with Solum.
> >> So does that mean these can be removed as well? I'm wondering if
> >> there is an official process here, or just a simple sign-off from a 
> >> project maintainer?
> > Swift did not use oslo.policy and use their own mechanism instead, so I 
> > guess we
> can remove Swift along with remaining networking-* plugins as well.
> >
> > BTW, ceilometer had already deprecated and removed ceilometer API from
> > Q, thus we can also remove ceilometer from the list too. [1]
> >
> > I have created PR regarding all above changes in [2].
> Merged. Thanks for looking into this. New results should be available in the 
> burndown
> chart.
> > Thanks,
> > Hieu.
> >
> > [1].
> > https://github.com/openstack/ceilometer/commit/d881dd52289d453b9f9d94c
> > 7c32c0672a70a8064 [2].
> > https://github.com/lbragstad/openstack-doc-migration-burndown/pull/1
> >
> >
> >> -Original Message-
> >> From: Lance Bragstad [mailto:lbrags...@gmail.com]
> >> Sent: Thursday, November 30, 2017 10:41 PM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> 
> >> Subject: Re: [openstack-dev] [all] [tc] Policy Goal Queens-2 Update
> >>
> >>
> >>
> >> On 11/29/2017 09:13 PM, da...@vn.fujitsu.com wrote:
> >>> Hi all,
> >>>
> >>> I just want to share some related things to anyone are interested in.
> >>>
> >>> For the Neutron projects, I have discussed with them[1] but it is
> >>> not really started, they want to consider more about all of
> >>> networking projects before and I'm still waiting for the feedback to
> >>> define the right way to
> >> implement policy-in-code for networking projects.
> >>> For the other extensions of Neutron, we got some
> >>> recommendations[2][3] that we no need to implement policy-in-code
> >>> into those projects because we already register policy in Neutron,
> >>> so I think we can remove neutron-
> >> fwaas, neutron-dynamic-routing, neutron-lib or even other networking
> >> plugins out of "Not Started" list.
> >> Awesome, thanks for the update! I've gone ahead and removed these
> >> from the burndown chart [0]. Let me know if there are any others that
> >> fall into this category and I'll get things updated in the tracking tool.
> >>
> >> [0]
> >> https://github.com/lbragstad/openstack-doc-migration-
> >> burndown/commit/f34c2f56692230f104354240bf0e4378dc0fea82
> >>> For the Swift project, I don't see oslo.policy in requirements.txt
> >>> for now, then not sure they need to implement policy in code and the
> >>> we got the same
> >> thing with Solum.
> >> So does that mean these can be removed as well? I'm wondering if
> >> there is an official process here, or just a simple sign-off from a 
> >> project maintainer?
> >>> [1]
> >>> http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23opens
> >>> ta
> >>> ck-neutron.2017-10-31.log.html [2]
> >>> http://eavesdrop.openstack.org/irclogs/%23openstack-lbaas/%23opensta
> >>> ck
> >>> -lbaas.2017-10-06.log.html#t2017-10-06T02:50:10
> >>> [3] https://review.openstack.org/#/c/509389/
> >>>
> >>> Dai
> >>>
> >>>
> >>
> ___
> >> ___
> >>>  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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [tripleo] rename ovb jobs?

[Juan Antonio Osorio]

On Thu, Nov 30, 2017 at 9:11 PM, Emilien Macchi  wrote:

> A few months ago, we renamed ovb-updates to be
> tripleo-ci-centos-7-ovb-1ctlr_1comp_1ceph-featureset024.
> The name is much longer but it describes better what it's doing.
> We know it's a job with one controller, one compute and one storage
> node, deploying the quickstart featureset n°24.
>
> For consistency, I propose that we rename all OVB jobs this way.
> For example, tripleo-ci-centos-7-ovb-ha-oooq would become
> tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001
> etc.
>
Sounds reasonable. That would make it easier for me to check what's
actually in the featureset, as opposed to having to ask folks every time.

>
> Any thoughts / feedback before we proceed?
> Before someone asks, I'm not in favor of renaming the multinode
> scenarios now, because they became quite familiar now, and it would
> confuse people to rename the jobs.
>
> Thanks,
> --
> 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
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@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] [tc] Policy Goal Queens-2 Update

[Lance Bragstad]

On 11/30/2017 07:00 PM, hie...@vn.fujitsu.com wrote:
> Lance,
>
>>> For the Swift project, I don't see oslo.policy in requirements.txt for
>>> now, then not sure they need to implement policy in code and the we got the 
>>> same
>> thing with Solum.
>> So does that mean these can be removed as well? I'm wondering if there is an 
>> official
>> process here, or just a simple sign-off from a project maintainer?
> Swift did not use oslo.policy and use their own mechanism instead, so I guess 
> we can remove Swift along with remaining networking-* plugins as well.
>
> BTW, ceilometer had already deprecated and removed ceilometer API from Q, 
> thus we can also remove ceilometer from the list too. [1]
>
> I have created PR regarding all above changes in [2].
Merged. Thanks for looking into this. New results should be available in
the burndown chart.
> Thanks,
> Hieu.
>
> [1]. 
> https://github.com/openstack/ceilometer/commit/d881dd52289d453b9f9d94c7c32c0672a70a8064
> [2]. https://github.com/lbragstad/openstack-doc-migration-burndown/pull/1
>
>
>> -Original Message-
>> From: Lance Bragstad [mailto:lbrags...@gmail.com]
>> Sent: Thursday, November 30, 2017 10:41 PM
>> To: OpenStack Development Mailing List (not for usage questions) > d...@lists.openstack.org>
>> Subject: Re: [openstack-dev] [all] [tc] Policy Goal Queens-2 Update
>>
>>
>>
>> On 11/29/2017 09:13 PM, da...@vn.fujitsu.com wrote:
>>> Hi all,
>>>
>>> I just want to share some related things to anyone are interested in.
>>>
>>> For the Neutron projects, I have discussed with them[1] but it is not
>>> really started, they want to consider more about all of networking
>>> projects before and I'm still waiting for the feedback to define the right 
>>> way to
>> implement policy-in-code for networking projects.
>>> For the other extensions of Neutron, we got some recommendations[2][3]
>>> that we no need to implement policy-in-code into those projects
>>> because we already register policy in Neutron, so I think we can remove 
>>> neutron-
>> fwaas, neutron-dynamic-routing, neutron-lib or even other networking plugins 
>> out of
>> "Not Started" list.
>> Awesome, thanks for the update! I've gone ahead and removed these from the
>> burndown chart [0]. Let me know if there are any others that fall into this 
>> category and
>> I'll get things updated in the tracking tool.
>>
>> [0]
>> https://github.com/lbragstad/openstack-doc-migration-
>> burndown/commit/f34c2f56692230f104354240bf0e4378dc0fea82
>>> For the Swift project, I don't see oslo.policy in requirements.txt for
>>> now, then not sure they need to implement policy in code and the we got the 
>>> same
>> thing with Solum.
>> So does that mean these can be removed as well? I'm wondering if there is an 
>> official
>> process here, or just a simple sign-off from a project maintainer?
>>> [1]
>>> http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23opensta
>>> ck-neutron.2017-10-31.log.html [2]
>>> http://eavesdrop.openstack.org/irclogs/%23openstack-lbaas/%23openstack
>>> -lbaas.2017-10-06.log.html#t2017-10-06T02:50:10
>>> [3] https://review.openstack.org/#/c/509389/
>>>
>>> Dai
>>>
>>>
>> ___
>> ___
>>>  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][api] POST /api-sig/news

[Gilles Dubreuil]

Hi Chris,

Thank you for those precious details.

I just added https://review.openstack.org/#/c/524467/ to augment the 
existing guidelines [2] and to get started with the API Schema 
(consumption) topic.


It would be great if that topic could be added to the agenda, can you 
please help?


Cheers,
Gilles


On 01/12/17 04:17, Chris Dent wrote:


Greetings OpenStack community,

With this week, the API-SIG had its first real meeting since before 
the summit in Sydney. Travel and US holidays have meant not enough 
people were around to make a meeting worth having.


This week there were. First order of business was to officially make 
Dmitry Tantsur "core". In the context of the API-SIG that means he has 
the power to freeze and merge guidelines, run the meetings, and write 
this newsletter. For many months he's been providing excellent reviews 
on the guidelines that the SIG produces, and excellent and regular 
input in the discussions we have during the meetings. Welcome Dmitry!


This week's excellent discussion [5] was centered around effective 
ways of dealing with versions in client code. One of the things that 
was remarkable about the conversation is that many things that a few 
years ago were often subject to debate are now fairly commonly 
accepted as good behavior: service discovery, version discovery, 
microversions, microversioning per-request (rather than per-session). 
As the SIG expands into working with SDK developers, being able to 
talk about and demonstrate these behaviors as "normal" will be very 
useful.


There has not, of late, been much progress on new (or improved) 
guidelines, but there are plenty of opportunities. Those of us who are 
regulars are full of good intentions but in recent months have had too 
many other obligations. If you are interested in helping out there are 
three entry points:


* The list of bugs [6] indicates several missing or incomplete 
guidelines.
* The existing guidelines [2] always need refreshing to account for 
changes over time. If you find something that's not quite right, 
submit a patch [7] to fix it.
* Have you done something for which you think guidance would have made 
things easier but couldn't find any? Submit a patch and help others [7].


# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and 
service discovery

  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet 
ready for review)

  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs 
that you are developing or changing, please address your concerns in 
an email to the OpenStack developer mailing list[1] with the tag 
"[api]" in the subject. In your email, you should include any relevant 
reviews, links, and comments to help guide the discussion of the 
specific challenge you are facing.


To learn more about the API SIG mission and the work we do, see our 
wiki page [4] and guidelines [2].


Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] 
https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z

[4] https://wiki.openstack.org/wiki/API_SIG
[5] 
http://eavesdrop.openstack.org/meetings/api_sig/2017/api_sig.2017-11-30-16.01.log.html#l-71

[6] https://bugs.launchpad.net/openstack-api-wg
[7] https://git.openstack.org/cgit/openstack/api-wg

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg



__
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


--
Gilles Dubreuil
Senior Software Engineer, Openstack DFG Integration
Mobile: +61 400 894 219
Email: gil...@redhat.com
GitHub/IRC: gildub


__
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] [tc] Policy Goal Queens-2 Update

[hie...@vn.fujitsu.com]

Lance,

> > For the Swift project, I don't see oslo.policy in requirements.txt for
> > now, then not sure they need to implement policy in code and the we got the 
> > same
> thing with Solum.
> So does that mean these can be removed as well? I'm wondering if there is an 
> official
> process here, or just a simple sign-off from a project maintainer?

Swift did not use oslo.policy and use their own mechanism instead, so I guess 
we can remove Swift along with remaining networking-* plugins as well.

BTW, ceilometer had already deprecated and removed ceilometer API from Q, thus 
we can also remove ceilometer from the list too. [1]

I have created PR regarding all above changes in [2].

Thanks,
Hieu.

[1]. 
https://github.com/openstack/ceilometer/commit/d881dd52289d453b9f9d94c7c32c0672a70a8064
[2]. https://github.com/lbragstad/openstack-doc-migration-burndown/pull/1


> -Original Message-
> From: Lance Bragstad [mailto:lbrags...@gmail.com]
> Sent: Thursday, November 30, 2017 10:41 PM
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> Subject: Re: [openstack-dev] [all] [tc] Policy Goal Queens-2 Update
> 
> 
> 
> On 11/29/2017 09:13 PM, da...@vn.fujitsu.com wrote:
> > Hi all,
> >
> > I just want to share some related things to anyone are interested in.
> >
> > For the Neutron projects, I have discussed with them[1] but it is not
> > really started, they want to consider more about all of networking
> > projects before and I'm still waiting for the feedback to define the right 
> > way to
> implement policy-in-code for networking projects.
> >
> > For the other extensions of Neutron, we got some recommendations[2][3]
> > that we no need to implement policy-in-code into those projects
> > because we already register policy in Neutron, so I think we can remove 
> > neutron-
> fwaas, neutron-dynamic-routing, neutron-lib or even other networking plugins 
> out of
> "Not Started" list.
> Awesome, thanks for the update! I've gone ahead and removed these from the
> burndown chart [0]. Let me know if there are any others that fall into this 
> category and
> I'll get things updated in the tracking tool.
> 
> [0]
> https://github.com/lbragstad/openstack-doc-migration-
> burndown/commit/f34c2f56692230f104354240bf0e4378dc0fea82
> >
> > For the Swift project, I don't see oslo.policy in requirements.txt for
> > now, then not sure they need to implement policy in code and the we got the 
> > same
> thing with Solum.
> So does that mean these can be removed as well? I'm wondering if there is an 
> official
> process here, or just a simple sign-off from a project maintainer?
> >
> > [1]
> > http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23opensta
> > ck-neutron.2017-10-31.log.html [2]
> > http://eavesdrop.openstack.org/irclogs/%23openstack-lbaas/%23openstack
> > -lbaas.2017-10-06.log.html#t2017-10-06T02:50:10
> > [3] https://review.openstack.org/#/c/509389/
> >
> > Dai
> >
> >
> ___
> ___
> >  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] [E] Re: nova diagnostics in client library/SDK

[Gilles Dubreuil]

On 01/12/17 03:47, Monty Taylor wrote:

On 11/29/2017 12:49 PM, Gordon, Kent S wrote:


On Tue, Nov 28, 2017 at 2:15 PM, Monty Taylor > wrote:


    On 11/03/2017 11:31 AM, Gordon, Kent S wrote:

    Do any of the python client libraries implement the nova
    diagnostics API?

https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openstack.org_wiki_Nova-5FVM-5FDiagnostics=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=Xkn6r0Olgrmyl97VKakpX0o-JiB_old4u22bFbcLdRo=p2ULfonZvWd4C82lmFExdHuyh-NeUTzyu-q5M0kTDNg=RI4HTKLenL00VdvmCqFfjr5IMJV4HfWW_UkH1R1BWSU=



    Not to my knowledge, no. However, adding support for it should be
    easy enough to accomplish and would be a welcome addition.

    This is the API you're talking about?

https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.openstack.org_api-2Dref_compute_-23servers-2Ddiagnostics-2Dservers-2Ddiagnostics=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=Xkn6r0Olgrmyl97VKakpX0o-JiB_old4u22bFbcLdRo=p2ULfonZvWd4C82lmFExdHuyh-NeUTzyu-q5M0kTDNg=2GH64mANdI_uV67Gt2YvoBJlR7uHHl17EB-URrOMN-E=


yes

    If you feel like hacking on it, a patch to
    openstack/python-openstacksdk would be the best way to go.

    However, this is microversion-protected, and this would be the first
    such feature in the SDK. So if diving that far down the rabbithole
    sounds like too much, either bug me until I get around to it - or do
    as much of it as makes sense (like adding a Resource class based on
    openstack.resource2) but ignore the microversion bit and I can help
    finish it off.


It has been a while since I did a lot of development.  Let me see how 
far I can get.


No worries - I can also just knock it out for you ... mostly wanted to 
be welcoming in case you *wanted* to add it. (it's no fun if I swoop 
in and steal people's hacking projects)





Well Misty does:

htps://github.com/flystack/misty/blob/master/lib/misty/openstack/nova/nova_v2_1.rb#L58

Meanwhile I've never tested that part so any feedback more than welcome 
and I'll be happy to promptly help if there are any issues.


Cheers,
Gilles

PS: This is exactly why wee need to get more attention on the `API 
Schema` because of the *desperate* need for more APIs automation!



__ 


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


--
Gilles Dubreuil
Senior Software Engineer, Openstack DFG Integration
Mobile: +61 400 894 219
Email: gil...@redhat.com
GitHub/IRC: gildub



__
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] [sahara] [api] [sdks] [keystone] Sahara APIv2: service discovery

[Monty Taylor]

On 11/30/2017 03:07 PM, Jeremy Freudberg wrote:

Hi all,

In the Sahara world, we are getting ready to expose our experimental
v2 API to real users and not just curious devs. Therefore we need to
start thinking about service/version discovery of this new API.


\o/


Earlier this year, the service types authority was created, and one of
the things it asserted was that different service types for each API
version (like Cinder and Mistral did) is bad.

So, it would entail that we should not adopt the `data-processingv2`
service type.


Yes. Please don't... the service-types data has made its way into many 
places now.



Unfortunately it's not so easy because Sahara API v1 relies on project
ID in the URL, and therefore is expected to be registered with the
project ID template in the Keystone service catalog. But API v2 does
not accept project ID in the URL.

We don't want to break existing clients' ability to discover and use
Sahara among all clouds. So if we changed the expectation of the
endpoint for the current `dataprocessing` service type to never
contain project ID, some clients might get spooked. (Correct me if I'm
wrong)


WELL - there's totally a way to do this that works, although it's gonna 
be somewhat annoying.


First and most importantly you need to update python-saharaclient to 
make sure it can handle it an unversioned endpoint in the catalog (by 
doing discovery) - and that if it finds an unversioned endpoint in the 
catalog it knows to prepend project-id to the urls is sends. The 
easiest/best way to do this it to make sure it's delegating version 
discovery to keystoneauth ... I will be more than happy to help you get 
that updated.


Then, for now, recommend that *new* deployments put the unversioned 
endpoint into their catalog, but that existing deployments keep the v1 
endpoint in the catalog even if they upgrade sahara to a version that 
has v2 as well. (The full description of version discovery describes how 
to get to a newer version even if an older version is in the catalog, so 
people can opt-in to v2 if it's there with no trouble)


That gets us to a state where:

- existing deployments with users using v1 are not broken
- existing deployments that upgrade can have user's opt-in to v2 easily
- new deployments will have both v1 and v2 - but users who want to use 
v1 will have to do so with a client that understands actually doing 
discovery


Then let it sit that way for a while, and we can work to make sure that 
other clients with sahara support are also up to date with version 
discovery.


There will eventually come a point where a deployer will decide they 
want to change their catalog from /v1/{project_id} to / ... but by then 
we should have all the clients able to understand discovery fully.



So, we either need to break the rules and create the
`data-processingv2` type anyway, or we can create a new type just
called, for example, `bigdata` which going forward can be used to
discover either v1 or v2 without any interop concerns.


I think renaming to bigdata is less terrible than data-processing2 ... 
but let's see if we can't get things to work the other day first - 
there's a lot of churn otherwise.



This is not an aspect of OpenStack I know a lot about, so any guidance
is appreciated. Once we figure out a way forward I will make sure
patches get proposed to the service types authority repo.


Almost nobody does. :) But we can totally figure this one out.

Monty

__
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 diagnostics in client library/SDK

[Matt Riedemann]

On 11/28/2017 2:15 PM, Monty Taylor wrote:

On 11/03/2017 11:31 AM, Gordon, Kent S wrote:

Do any of the python client libraries implement the nova diagnostics API?

https://wiki.openstack.org/wiki/Nova_VM_Diagnostics


Not to my knowledge, no. However, adding support for it should be easy 
enough to accomplish and would be a welcome addition.


This is the API you're talking about?

https://developer.openstack.org/api-ref/compute/#servers-diagnostics-servers-diagnostics 



If you feel like hacking on it, a patch to openstack/python-openstacksdk 
would be the best way to go.


However, this is microversion-protected, and this would be the first 
such feature in the SDK. So if diving that far down the rabbithole 
sounds like too much, either bug me until I get around to it - or do as 
much of it as makes sense (like adding a Resource class based on 
openstack.resource2) but ignore the microversion bit and I can help 
finish it off.


Monty

__
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


Well, novaclient does:

https://github.com/openstack/python-novaclient/blob/f7c991703517b6fd6a42f732fc602badb0caebb8/novaclient/v2/servers.py#L1260

--

Thanks,

Matt

__
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] [OpenStack-Dev] [Nova][Neutron][Horizon][Cinder][Keystone][Glance][Ironic][Swift] Fault Classification Input Request

[Nematollah Bidokhti]

Hi,

Our [Fault-Genes WG] has been working on defining the fault classifications for 
key OpenStack projects in an effort to support OpenStack fault management & 
self-healing.
We have been using machine learning (unsupervised data) as a method to look 
into all bugs and issues submitted by the community and it has been very 
challenging to define the classification completely by the machine.
We have decided to go with supervised data set. In order to do this, we need to 
come up with our training data.

We need your help to generate the training data set. Basically, we only need 2 
or 3 unique fault classifications with a short description and the associated 
mitigations from each member who is familiar with OpenStack design & operation. 
This way we can build a focused library of faults & mitigations for each 
project.
Once this data is accumulated, we will develop our own specific algorithms that 
can be applied to all future OpenStack issues.
Thanks in advance for your support.
 No.

Project

Fault Classification

Description

Root Cause

Mitigation

1











2











3












Below are examples of what a couple of developers in Neutron have provided. I 
am sure there are other types of fault classifications in Neurton that have not 
been captured in this table.


Fault Classification


Root Cause


Mitigation


Network Connectivity Issues


Virtual interface in the VM admin down


Un-shut the virtual interface


Virtual interface does not have IP address via DHCP


Depends on lower level root cause


Virtual network does not have interface to the router


Add virtual network as one of the router interfaces


vNIC port of VM not active (stuck in build)


Depends on lower level root cause


Security group lock in traffic


Fix the security group to allow relevant traffic


Unable to Add Port to Bridge


Libvirtd in Apparmor is blocking


allow Libvirtd profile in Appamor


No Valid Host Found/insufficient hypervisor resources


Compute nodes do not have sufficient resources


free up required compute storage and memory resources on compute node


No Resource


Configuration issues


Change config setting


Authentication/permissions error


Configuration error such as port # or Password


Make sure end points are properly configured


Gateway access not reachable


Use custom keep-alive health-check


Design issue of OpenStack Network node


Out of band health checking mechanism


Security Group Mis-configuration


The security group


Change security rules/Programming the security group


DNS Attack


Implement CERT alerts updates


Network design issue


Network storm


Reduce L2 broadcast domain

Nemat



__
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] [Neutron] Propose Slawek Kaplonski for Neutron core

[Hirofumi Ichihara]

+1

2017-11-30 4:21 GMT+09:00 Miguel Lavalle :

> Hi Neutron Team,
>
> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. Slawek
> has been an active contributor to the project since the Mitaka cycle. He
> has been instrumental in the development of the QoS capabilities in
> Neutron, becoming the lead of the sub-team focused on that set of features.
> More recently, he has collaborated in the implementation of OVO and is an
> active participant in the CI sub-team. His number of code reviews during
> the Queens cycle is on par with the leading core members of the team:
> http://stackalytics.com/?module=neutron
>
> In my opinion, his efforts are highly valuable to the team and we will be
> very lucky to have him as a fully voting core.
>
> I will keep this nomination open for a week as customary,
>
> Thank you,
>
> Miguel
>
> __
> 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] [charms] 17.11 OpenStack Charms release

[David Ames]

Announcing the 17.11 release of the OpenStack Charms.

In addition to 125 bug fixes across the charms, the release includes
official support for Gnocchi and support for QoS. Several charms have
made the migration to python3 only run-time.

For full details of the release, please refer to the release notes:

  https://docs.openstack.org/charm-guide/latest/1711.html

Thanks go to the following contributors for this release:

 Alex Kavanagh
 Andrew McLeod
 Aydin Doyak
 Billy Olsen
 Chris MacNaughton
 Corey Bryant
 David Ames
 Dmitrii Shcherbakov
 Edward Hope-Morley
 Evgeny Kremenetsky
 Felipe Reyes
 Frode Nordahl
 Fulvio Galeazzi
 Haw Loeung
 Hua Zhang
 James Page
 Jorge Niedbalski
 Liam Young
 Marian Gasparovic
 Michael Skalka
 Nobuto Murata
 Pete Vander Giessen
 Ryan Beisner
 Seyeong Kim
 Shane Peters
 Tytus Kurek
 Xav Paice
 viswesuwara nathan
 zhangyangyang

__
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] [Neutron] Propose Slawek Kaplonski for Neutron core

[Akihiro Motoki]

+1 from me!

2017-11-30 4:21 GMT+09:00 Miguel Lavalle :
> Hi Neutron Team,
>
> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. Slawek
> has been an active contributor to the project since the Mitaka cycle. He has
> been instrumental in the development of the QoS capabilities in Neutron,
> becoming the lead of the sub-team focused on that set of features. More
> recently, he has collaborated in the implementation of OVO and is an active
> participant in the CI sub-team. His number of code reviews during the Queens
> cycle is on par with the leading core members of the team:
> http://stackalytics.com/?module=neutron
>
> In my opinion, his efforts are highly valuable to the team and we will be
> very lucky to have him as a fully voting core.
>
> I will keep this nomination open for a week as customary,
>
> Thank you,
>
> Miguel
>
> __
> 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] [tripleo] containerized undercloud update

[Wesley Hayutin]

Greetings,

Just wanted to share some progress with the containerized undercloud work.
Ian pushed some of the patches along and we now have a successful
undercloud install with containers.

The initial undercloud install works [1]
The idempotency check failed where we reinstall the undercloud [2]

Question: Do we expect the reinstallation to work at this point? Should the
check be turned off?

I will try it w/o the idempotency check, I suspect I will run into errors
in a full run with an overcloud deployment.  I ran into issues weeks ago.
I suspect if we do hit something it will be CI related as Dan Price has
been deploying the overcloud for a while now.  Dan I may need to review
your latest doit.sh scripts to check for diffs in the CI.

Thanks


[1]
http://logs.openstack.org/18/518118/6/check/tripleo-ci-centos-7-undercloud-oooq/73115d6/logs/undercloud/home/zuul/undercloud_install.log.txt.gz
[2]
http://logs.openstack.org/18/518118/6/check/tripleo-ci-centos-7-undercloud-oooq/73115d6/logs/undercloud/home/zuul/undercloud_reinstall.log.txt.gz#_2017-11-30_19_51_26
__
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] [sahara] [api] [sdks] [keystone] Sahara APIv2: service discovery

[Jeremy Freudberg]

Hi all,

In the Sahara world, we are getting ready to expose our experimental
v2 API to real users and not just curious devs. Therefore we need to
start thinking about service/version discovery of this new API.

Earlier this year, the service types authority was created, and one of
the things it asserted was that different service types for each API
version (like Cinder and Mistral did) is bad.

So, it would entail that we should not adopt the `data-processingv2`
service type.

Unfortunately it's not so easy because Sahara API v1 relies on project
ID in the URL, and therefore is expected to be registered with the
project ID template in the Keystone service catalog. But API v2 does
not accept project ID in the URL.

We don't want to break existing clients' ability to discover and use
Sahara among all clouds. So if we changed the expectation of the
endpoint for the current `dataprocessing` service type to never
contain project ID, some clients might get spooked. (Correct me if I'm
wrong)

So, we either need to break the rules and create the
`data-processingv2` type anyway, or we can create a new type just
called, for example, `bigdata` which going forward can be used to
discover either v1 or v2 without any interop concerns.

This is not an aspect of OpenStack I know a lot about, so any guidance
is appreciated. Once we figure out a way forward I will make sure
patches get proposed to the service types authority repo.

Best,
Jeremy

__
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] Dublin PTG format

[Frank Kloeker]

Am 2017-11-27 11:58, schrieb Thierry Carrez:
[...]

We have two options in how we do the split for predetermined topics. We
used to split the week between Mon-Tue (themes) and Wed-Fri (teams). 
The

general idea there was to allow some people only interested in a team
meeting to only attend the second part of the week. However most people
attend all 5 days, and during event feedback some people suggested that
"themes" should be in the mornings and "teams" in the afternoons (and
all Friday).

What would be your preference ? The Mon-Tue/Wed-Fri split means less
room changes, which make it easier on the events team. So all else 
being

equal we'd rather keep it the way it is, but I'm open to changing it if
attendees think it's a good idea.

If you have any other suggestion (that we could implement in the 3
months we have between now and the event) please let me know :)


Hi Thierry,

I'd like the idea about themes and teams. Themes bring the opportunity 
to learn work methods and learn ways of working together, across 
OpenStack project teams and new people who are interested. There are so 
many things to learn from the OpenStack community like documentation, 
code review, code testing, automation, project work. This is the chance 
to prove the 4 O's and to give a platform for it.
Call it Summit 2.0. For 2 days, people who are not members of any 
project team but who are interested in their work or in the workings of 
the OpenStack community.
The other 3 days are really for project team work. I think 2 days would 
be also enough plus 1 day cross-project team work.
I'm not sure if I explained that correctly. I learned so much about 
working methods in the community. I think there may be more people 
proving it and maybe new enthusiastically people are joining in.


These are my thoughts about themes and teams :)

kind regards

Frank (@eumel8)

__
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] rename ovb jobs?

[Emilien Macchi]

A few months ago, we renamed ovb-updates to be
tripleo-ci-centos-7-ovb-1ctlr_1comp_1ceph-featureset024.
The name is much longer but it describes better what it's doing.
We know it's a job with one controller, one compute and one storage
node, deploying the quickstart featureset n°24.

For consistency, I propose that we rename all OVB jobs this way.
For example, tripleo-ci-centos-7-ovb-ha-oooq would become
tripleo-ci-centos-7-ovb-3ctlr_1comp-featureset001
etc.

Any thoughts / feedback before we proceed?
Before someone asks, I'm not in favor of renaming the multinode
scenarios now, because they became quite familiar now, and it would
confuse people to rename the jobs.

Thanks,
-- 
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

[openstack-dev] [docs] Closing down openstack-d...@lists.openstack.org

[Petr Kovar]

Hi all,

As previously announced, I'm sending a final notice that we are closing
down openstack-d...@lists.openstack.org.

Please use openstack-dev@lists.openstack.org with the [docs] tag in
subject for documentation-related discussions.

No new subscriptions or postings will be allowed for
openstack-d...@lists.openstack.org but we plan to retain the list archives
for historical reference.

Thanks,
pk

__
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] [Kolla][Kubernetes][Doomed] So close but yet so far

[Scott, Justin A]

Hi Michael,

If you inspect the nova-api-create-cell- pod manifest you might see that there 
is a missing port for keystone-internal URL. You can add ‘port: 5000’ under 
keystone section in cloud.yaml before installing. Hope that helps!

Thanks,

Justin

From: Michael Still 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, November 30, 2017 at 2:36 AM
To: OpenStack Development Mailing List 
Subject: [openstack-dev] [Kolla][Kubernetes][Doomed] So close but yet so far

Hi,

I'm out of my depth a little here. I've done the following:

 - installed kubernetes
 - followed the deploy guide for kolla-kubernetes [1]
 - except where I didn't because I had to fix it [2]

I can download an openrc and even send a "nova boot" that looks like it works. 
However, I have this container in the list:

kolla nova-api-create-cell-947hc0/1   Init:2/3   0  
24m   10.1.0.195  lab8
Which means that the instance doesn't actually start:

$ openstack server show demo1 --format shell
os_dcf_diskconfig="MANUAL"
os_ext_az_availability_zone=""
os_ext_srv_attr_host="None"
os_ext_srv_attr_hypervisor_hostname="None"
os_ext_srv_attr_instance_name=""
os_ext_sts_power_state="NOSTATE"
os_ext_sts_task_state="scheduling"
os_ext_sts_vm_state="building"
os_srv_usg_launched_at="None"
os_srv_usg_terminated_at="None"
accessipv4=""
accessipv6=""
addresses=""
config_drive=""
created="2017-11-30T10:24:19Z"
flavor="m1.tiny (1)"
hostid=""
id="a531bedc-fc2a-4d59-8643-18e1b83943fe"
image="cirros (04053309-9a5c-4f25-8dda-2ff898f5a400)"
key_name="mykey"
name="demo1"
progress="0"
project_id="d0a64448a0d940b48c579f8fbb774827"
properties=""
status="BUILD"
updated="2017-11-30T10:34:45Z"
user_id="420105e944c64b918185cdc22f55fdfc"
volumes_attached=""

Where it sits forever, presumably waiting for someone to notice the request.

I'm a but stumped as to how to debug further. Could I have a hint please?

Thanks,
Michael

1: https://docs.openstack.org/kolla-kubernetes/latest/deployment-guide.html
2: https://review.openstack.org/#/c/524125/
__
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] [cinder] nova cannot create instance snapshot after ocata upgrade

[Matt Riedemann]

On 11/30/2017 9:30 AM, Kim-Norman Sahm wrote:

after upgrade openstack newton -> ocata i cannot create snapshots of my
instances.

if i try to create a snapshot of a instance horizon get this error:
"Error: Unable to create snapshot."
create a snapshot of a cinder volume  via openstackcli is working.

nova.log

2017-11-30 15:19:57.875 93 DEBUG cinderclient.v3.client [req-5820c19b-
fb11-43a2-8513-0782540b3d32 c756af2957c4447eafc4cef39cdb79e5
469dc3d300df4d41aaea00db572043ae - default default] REQ: curl -g -i -X
GET https://cinder:8776/v3/469dc3d300df4d41aaea00db572043ae/volumes/c67
b5cf3-0beb-4efa-9177-d2b6498185fb -H "X-Service-Token:
{SHA1}29a46cd87988e2bb905dbd3e796401aa23dff1a5" -H "User-Agent: python-
cinderclient" -H "Accept: application/json" -H "X-Auth-Token:
{SHA1}524061f0ab91e64ed6241e437792346f90df856e" _http_log_request
/usr/lib/python2.7/dist-packages/keystoneauth1/session.py:347
2017-11-30 15:19:57.890 92 INFO nova.osapi_compute.wsgi.server [req-
d83d5b73-fd24-406c-ad6b-feed6a40bfae c756af2957c4447eafc4cef39cdb79e5
469dc3d300df4d41aaea00db572043ae - default default] 10.78.21.2 "GET
/v2.1/flavors/203/os-extra_specs HTTP/1.1" status: 200 len: 448 time:
0.0326798
2017-11-30 15:19:58.148 93 DEBUG cinderclient.v3.client [req-5820c19b-
fb11-43a2-8513-0782540b3d32 c756af2957c4447eafc4cef39cdb79e5
469dc3d300df4d41aaea00db572043ae - default default] RESP: [401] Date:
Thu, 30 Nov 2017 15:19:57 GMT Server: Apache/2.4.18 (Ubuntu) x-
openstack-request-id: req-22378faa-880b-4a80-a83e-41936741839e WWW-
Authenticate: Keystone uri='https://keystone:5000/' Content-Length: 114
Content-Type: application/json
RESP BODY: {"error": {"message": "The request you have made requires
authentication.", "code": 401, "title": "Unauthorized"}}
  _http_log_response /usr/lib/python2.7/dist-
packages/keystoneauth1/session.py:395
2017-11-30 15:19:58.149 93 DEBUG cinderclient.v3.client [req-5820c19b-
fb11-43a2-8513-0782540b3d32 c756af2957c4447eafc4cef39cdb79e5
469dc3d300df4d41aaea00db572043ae - default default] GET call to
cinderv3 for https://cinder:8776/v3/469dc3d300df4d41aaea00db572043ae/vo
lumes/c67b5cf3-0beb-4efa-9177-d2b6498185fb used request id req-
22378faa-880b-4a80-a83e-41936741839e request /usr/lib/python2.7/dist-
packages/keystoneauth1/session.py:640
2017-11-30 15:19:58.157 93 DEBUG cinderclient.v3.client [req-5820c19b-
fb11-43a2-8513-0782540b3d32 c756af2957c4447eafc4cef39cdb79e5
469dc3d300df4d41aaea00db572043ae - default default] RESP: [401] Date:
Thu, 30 Nov 2017 15:19:58 GMT Server: Apache/2.4.18 (Ubuntu) x-
openstack-request-id: req-02ebac9f-794a-46f4-85b2-0e429a1785cf WWW-
Authenticate: Keystone uri='https://keystone:5000/' Content-Length: 114
Content-Type: application/json
RESP BODY: {"error": {"message": "The request you have made requires
authentication.", "code": 401, "title": "Unauthorized"}}
  _http_log_response /usr/lib/python2.7/dist-
packages/keystoneauth1/session.py:395
2017-11-30 15:19:58.158 93 ERROR nova.api.openstack.extensions [req-
5820c19b-fb11-43a2-8513-0782540b3d32 c756af2957c4447eafc4cef39cdb79e5
469dc3d300df4d41aaea00db572043ae - default default] Unexpected
exception in API method
2017-11-30 15:19:58.158 93 ERROR nova.api.openstack.extensions
Traceback (most recent call last):
2017-11-30 15:19:58.158 93 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/dist-packages/nova/api/openstack/extensions.py",
line 338, in wrapped
2017-11-30 15:19:58.158 93 ERROR
nova.api.openstack.extensions return f(*args, **kwargs)
2017-11-30 15:19:58.158 93 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/dist-packages/nova/api/openstack/common.py", line
359, in inner
2017-11-30 15:19:58.158 93 ERROR
nova.api.openstack.extensions return f(*args, **kwargs)
2017-11-30 15:19:58.158 93 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py",
line 108, in wrapper
2017-11-30 15:19:58.158 93 ERROR
nova.api.openstack.extensions return func(*args, **kwargs)
2017-11-30 15:19:58.158 93 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py",
line 108, in wrapper
2017-11-30 15:19:58.158 93 ERROR
nova.api.openstack.extensions return func(*args, **kwargs)
2017-11-30 15:19:58.158 93 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/dist-
packages/nova/api/openstack/compute/servers.py", line 1095, in
_action_create_image
2017-11-30 15:19:58.158 93 ERROR
nova.api.openstack.extensions metadata)
2017-11-30 15:19:58.158 93 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 151, in
inner
2017-11-30 15:19:58.158 93 ERROR
nova.api.openstack.extensions return f(self, context, instance,
*args, **kw)
2017-11-30 15:19:58.158 93 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 2909, in
snapshot_volume_backed
2017-11-30 15:19:58.158 93 

[openstack-dev] [all][api] POST /api-sig/news

[Chris Dent]

Greetings OpenStack community,

With this week, the API-SIG had its first real meeting since before the summit 
in Sydney. Travel and US holidays have meant not enough people were around to 
make a meeting worth having.

This week there were. First order of business was to officially make Dmitry Tantsur 
"core". In the context of the API-SIG that means he has the power to freeze and 
merge guidelines, run the meetings, and write this newsletter. For many months he's been 
providing excellent reviews on the guidelines that the SIG produces, and excellent and 
regular input in the discussions we have during the meetings. Welcome Dmitry!

This week's excellent discussion [5] was centered around effective ways of dealing with 
versions in client code. One of the things that was remarkable about the conversation is 
that many things that a few years ago were often subject to debate are now fairly 
commonly accepted as good behavior: service discovery, version discovery, microversions, 
microversioning per-request (rather than per-session). As the SIG expands into working 
with SDK developers, being able to talk about and demonstrate these behaviors as 
"normal" will be very useful.

There has not, of late, been much progress on new (or improved) guidelines, but 
there are plenty of opportunities. Those of us who are regulars are full of 
good intentions but in recent months have had too many other obligations. If 
you are interested in helping out there are three entry points:

* The list of bugs [6] indicates several missing or incomplete guidelines.
* The existing guidelines [2] always need refreshing to account for changes 
over time. If you find something that's not quite right, submit a patch [7] to 
fix it.
* Have you done something for which you think guidance would have made things 
easier but couldn't find any? Submit a patch and help others [7].

# Newly Published Guidelines

None this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week

# Guidelines Currently Under Review [3]

* A (shrinking) suite of several documents about doing version and service 
discovery
  Start at https://review.openstack.org/#/c/459405/

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API SIG about APIs that you are 
developing or changing, please address your concerns in an email to the OpenStack 
developer mailing list[1] with the tag "[api]" in the subject. In your email, 
you should include any relevant reviews, links, and comments to help guide the discussion 
of the specific challenge you are facing.

To learn more about the API SIG mission and the work we do, see our wiki page 
[4] and guidelines [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://wiki.openstack.org/wiki/API_SIG
[5] 
http://eavesdrop.openstack.org/meetings/api_sig/2017/api_sig.2017-11-30-16.01.log.html#l-71
[6] https://bugs.launchpad.net/openstack-api-wg
[7] https://git.openstack.org/cgit/openstack/api-wg

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-SIG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_sig/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg

--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
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] [patrole] Question regarding Patrole API coverage

[MONTEIRO, FELIPE C]

> -Original Message-
> From: Graham Hayes [mailto:g...@ham.ie]
> Sent: Wednesday, November 29, 2017 10:20 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [qa] [patrole] Question regarding Patrole API
> coverage
> 
> 
> 
> On 29/11/17 15:11, Andrea Frittoli wrote:
> >
> >
> > On Wed, Nov 29, 2017 at 2:28 PM Peng Liu  > > wrote:
> >
> > Hi Team,
> >
> > Hi Peng
> >
> >
> > I have a question regarding to the API coverage of Patrole.
> > Currently, Patrole as a Tempest plugin heavily relys on the Tempest
> > code. However, Tempest only contains the API tests for the most
> > common APIs of the most common projects(Nova, Neutron, Cinder,
> > Glance, Swift, Keystone).
> >
> > So I want to know if it is possible to extend Patrole to:
> > 1) test the APIs of the common projects which was not yet covered in
> > Tempest.
> >
> > 2) test projects which was not covered in Tempest?
> >
> >
> > You can use the Patrole framework to test services not covered by
> > Tempest by taking advantage of Tempest plugin mechanism.
> > Patrole itself is a Tempest plugin. If you install the plugin of a
> > service that includes a service client, you should be able to use it to
> > write Patrole tests for that service.
> > I believe this has not been done yet by any project though, so there may
> > be a few technical bits to be sorted out.
> 
> There has been a start with Designate + Neutron [1], it is just underway
> now though.
> 
> It could cause an issue as all of a sudden the internals of a project's
> plugin may need to be a stable interface, which may not be something
> they expect.

Patrole doesn't change its internals overnight, so to speak. We also use 
deprecation notes and typically wait one release cycle before removing the 
feature, communicated again with a release note. That being said, Patrole's 
framework does change more often than Tempest's and will continue to do so for 
some time yet. So any reliance on Patrole will require maintenance. This is why 
Patrole uses 0.x.0 release versioning right now. 

> 1 - https://review.openstack.org/#/c/520237/
> 
> > I don't think Patrole itself will have to be extended, however Patrole
> > does not yet include stable APIs.
> > If you're going to use Patrole APIs in your project you need to be aware
> > that there may be backward incompatible changes happening without a
> > deprecation period.

The other thing to keep in mind is to ensure that the clients that are being 
used are Tempest-based. I've seen a few Tempest plugins using 
python--client integrations which is problematic, because Patrole 
expects Tempest-based exceptions to be raised.

> >
> > There are several options on where to host such tests: in a dedicated
> > plugin, in the Tempest plugin for the service or in Patrole itself.
> > The latter would probably suffer from the same scalability issues that
> > lead us to create the plugin mechanism to begin with.

There was discussion long ago about a `patrole.lib` that could be its own 
package, but anything like that will not materialize until Patrole is stable, 
pending discussion of course.

> >
> > Andrea Frittoli (andreaf)
> >
> >
> >
> > Thanks,
> > --
> > Peng Liu
> >

Thanks,

Felipe
__
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] [tripleo] Updates on the TripleO on Kubernetes work

[Flavio Percoco]

On 30/11/17 10:23 -0500, Dan Prince wrote:

On Fri, Nov 17, 2017 at 4:43 AM, Steven Hardy  wrote:



In the ansible/kubernetes model, it could work like:

1. Ansible role makes k8s API call creating pod with multiple containers
2. Pod starts temporary container that runs puppet, config files
written out to shared volume
3. Service container starts, config consumed from shared volume
4. Optionally run temporary bootstrapping container inside pod

This sort of pattern is documented here:

https://kubernetes.io/docs/tasks/access-application-cluster/communicate-
containers-same-pod-shared-volume/




Regarding the use of the shared volume I agree this is a nice iteration. We
considered using it within Pike as well but due to the Hybrid nature of the
deployment, and the desire to have config files easily debug friendly on
the host itself we ended up not going there.

In Queens however we are aiming for more or less full containerization so
we could consider the merits of this approach again. Just pointing out that
I don't think Kubernetes is a requirement in order to be able to proceed
with some of this improvement.


Agreed! The sooner we can move things out of "host paths" the better! Kubernetes
is not a requirement for these improvements but, I would say they are a
requirement for a k8s based deployment.

That is to say, a k8s based deployment should not depend on hostpaths :)

Flavio


--
@flaper87
Flavio Percoco


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

[openstack-dev] [tripleo] Updates from the ansible-role-k8s-* front

[Flavio Percoco]

Hey folks,

Some updates from the work on ansible-role-k8s-*

I've got the CI jobs working and running tempest. Well, to be honest, the
kubernetes one does, whereas the openshift one seems to be failing right now.
But, this is good anyways.

It is not running the full tempest suite but the tests for the specific role.
This is not meant to be an integration job but a functional one. We'll
eventually add integration jobs.

In addition, I've created a little script for those who want to play with the
ansible-role-k8s-* repos. You can start from a vanilla CentOS box and run this
script (sudo required). Ok, I lied, you need to have a Kubernetes cluster
somewhere and, as of now, it expects it to be on localhost. If it is not, feel
free to modify the script and change the `coe_host` in the playbook.

Here's a link to the script: 
https://gist.github.com/flaper87/f69a5dcc7b6ab0fdc290fa01eb8e7bdb
And an asciicinema recording of the script running: 
https://asciinema.org/a/150376

The requirements are small and it doesn't take too long to run. Eventually, all
the cleanup operations should go into the deprovision tasks file. Working on 
that!

Cheers,
Flavio

--
@flaper87
Flavio Percoco


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] [Neutron] Propose Slawek Kaplonski for Neutron core

[Brian Haley]

+1 from me!

On 11/29/2017 02:21 PM, Miguel Lavalle wrote:

Hi Neutron Team,

I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. 
Slawek has been an active contributor to the project since the Mitaka 
cycle. He has been instrumental in the development of the QoS 
capabilities in Neutron, becoming the lead of the sub-team focused on 
that set of features. More recently, he has collaborated in the 
implementation of OVO and is an active participant in the CI sub-team. 
His number of code reviews during the Queens cycle is on par with the 
leading core members of the team: http://stackalytics.com/?module=neutron


In my opinion, his efforts are highly valuable to the team and we will 
be very lucky to have him as a fully voting core.


I will keep this nomination open for a week as customary,

Thank you,

Miguel


__
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] [E] Re: nova diagnostics in client library/SDK

[Monty Taylor]

On 11/29/2017 12:49 PM, Gordon, Kent S wrote:


On Tue, Nov 28, 2017 at 2:15 PM, Monty Taylor > wrote:


On 11/03/2017 11:31 AM, Gordon, Kent S wrote:

Do any of the python client libraries implement the nova
diagnostics API?


https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openstack.org_wiki_Nova-5FVM-5FDiagnostics=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=Xkn6r0Olgrmyl97VKakpX0o-JiB_old4u22bFbcLdRo=p2ULfonZvWd4C82lmFExdHuyh-NeUTzyu-q5M0kTDNg=RI4HTKLenL00VdvmCqFfjr5IMJV4HfWW_UkH1R1BWSU=




Not to my knowledge, no. However, adding support for it should be
easy enough to accomplish and would be a welcome addition.

This is the API you're talking about?


https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.openstack.org_api-2Dref_compute_-23servers-2Ddiagnostics-2Dservers-2Ddiagnostics=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=Xkn6r0Olgrmyl97VKakpX0o-JiB_old4u22bFbcLdRo=p2ULfonZvWd4C82lmFExdHuyh-NeUTzyu-q5M0kTDNg=2GH64mANdI_uV67Gt2YvoBJlR7uHHl17EB-URrOMN-E=



yes

If you feel like hacking on it, a patch to
openstack/python-openstacksdk would be the best way to go.

However, this is microversion-protected, and this would be the first
such feature in the SDK. So if diving that far down the rabbithole
sounds like too much, either bug me until I get around to it - or do
as much of it as makes sense (like adding a Resource class based on
openstack.resource2) but ignore the microversion bit and I can help
finish it off.


It has been a while since I did a lot of development.  Let me see how 
far I can get.


No worries - I can also just knock it out for you ... mostly wanted to 
be welcoming in case you *wanted* to add it. (it's no fun if I swoop in 
and steal people's hacking projects)



__
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] [python-openstacksdk][shade] New cores proposed for shade/sdk

[Dean Troyer]

On Thu, Nov 30, 2017 at 8:00 AM, Monty Taylor  wrote:
> So let's add them to the core team, yeah?

+1

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] [Neutron] Propose Slawek Kaplonski for Neutron core

[thomas.morin]

+1 !

-Thomas


Miguel Lavalle, 2017-11-29 13:21:
> Hi Neutron Team,
> 
> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core.
> Slawek has been an active contributor to the project since the Mitaka
> cycle. He has been instrumental in the development of the QoS
> capabilities in Neutron, becoming the lead of the sub-team focused on
> that set of features. More recently, he has collaborated in the
> implementation of OVO and is an active participant in the CI sub-
> team. His number of code reviews during the Queens cycle is on par
> with the leading core members of the team: http://stackalytics.com/?m
> odule=neutron
> 
> In my opinion, his efforts are highly valuable to the team and we
> will be very lucky to have him as a fully voting core.
> 
> I will keep this nomination open for a week as customary,
> 
> Thank you,
> 
> Miguel
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


__
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] [tc] Policy Goal Queens-2 Update

[Lance Bragstad]

On 11/29/2017 09:13 PM, da...@vn.fujitsu.com wrote:
> Hi all,
>
> I just want to share some related things to anyone are interested in.
>
> For the Neutron projects, I have discussed with them[1] but it is not really 
> started,
> they want to consider more about all of networking projects before and I'm 
> still waiting for the feedback to
> define the right way to implement policy-in-code for networking projects.
>
> For the other extensions of Neutron, we got some recommendations[2][3] that 
> we no need to implement
> policy-in-code into those projects because we already register policy in 
> Neutron, so I think we can remove
> neutron-fwaas, neutron-dynamic-routing, neutron-lib or even other networking 
> plugins out of "Not Started" list.
Awesome, thanks for the update! I've gone ahead and removed these from
the burndown chart [0]. Let me know if there are any others that fall
into this category and I'll get things updated in the tracking tool.

[0]
https://github.com/lbragstad/openstack-doc-migration-burndown/commit/f34c2f56692230f104354240bf0e4378dc0fea82
>
> For the Swift project, I don't see oslo.policy in requirements.txt for now,
> then not sure they need to implement policy in code and the we got the same 
> thing with Solum.
So does that mean these can be removed as well? I'm wondering if there
is an official process here, or just a simple sign-off from a project
maintainer?
>
> [1] 
> http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2017-10-31.log.html
> [2] 
> http://eavesdrop.openstack.org/irclogs/%23openstack-lbaas/%23openstack-lbaas.2017-10-06.log.html#t2017-10-06T02:50:10
> [3] https://review.openstack.org/#/c/509389/
>
> Dai
>
> __
> 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




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] [TripleO] Proposing Ronelle Landy for Tripleo-Quickstart/Extras/CI core

[Dan Prince]

+1

On Wed, Nov 29, 2017 at 2:34 PM, John Trowbridge  wrote:

> I would like to propose Ronelle be given +2 for the above repos. She has
> been a solid contributor to tripleo-quickstart and extras almost since the
> beginning. She has solid review numbers, but more importantly has always
> done quality reviews. She also has been working in the very intense rover
> role on the CI squad in the past CI sprint, and has done very well in that
> role.
>
> __
> 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] [tripleo] Updates on the TripleO on Kubernetes work

[Dan Prince]

On Thu, Nov 16, 2017 at 11:56 AM, James Slagle 
wrote:
>
>
> When we consume these ansible-role-k8s-* roles from t-h-t, I think
> that should be a stepping stone towards migrating away from having to
> use Heat to deploy and configure those services. We know that these
> new ansible roles will be deployable standalone, and the interface to
> do that should be typical ansible best practices (role defaults, vars,
> etc).
>
> We can offer a mechanism such that one can migrate from a
> tripleo-heat-templates/docker/services/database/mysql.yaml deployed
> mariadb to one deployed via
> ansible-role-k8s-mariadb. The config-download mechanism could be
> updated to generate or pull from Heat the necessary ansible vars files
> for configuring the roles. We should make sure that the integration
> with tripleo-heat-templates results in the same inputs/outputs that
> someone would consume if using the roles standalone. Future iterations
> would then not have to require Heat for that service at all, unless
> the operator wanted to continue to configure the service via Heat
> parameters/environments.
>
> What I'm trying to propose is a path towards deprecating the Heat
> parameter/environment driven and hieradata driven approach to
> configuring the services. The ansible-role-k8s-* roles should offer a
> new interface, so I don't think we have to remain tied to Heat
> forever, so we should consider what we want the long term goal to be
> in an ideal world, and take some iterative steps to get there.
>

I like the idea of a leaner set of deployment tooling very much. I think we
are to the point where we need to consider "clean rooming" some things.

That said in moving towards a new interface like you talk about I think we
do have to have feature parity with things like composability and parameter
validation. Otherwise we are going to break things we currently rely on in
our high level (Mistral) deployment workflow. Specifically, I've yet to see
something that would give us the nested parameter validations we leverage
from Heat.

Dan
__
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] [nova] [cinder] nova cannot create instance snapshot after ocata upgrade

[Kim-Norman Sahm]

after upgrade openstack newton -> ocata i cannot create snapshots of my
instances.

if i try to create a snapshot of a instance horizon get this error:
"Error: Unable to create snapshot."
create a snapshot of a cinder volume  via openstackcli is working. 

nova.log

2017-11-30 15:19:57.875 93 DEBUG cinderclient.v3.client [req-5820c19b-
fb11-43a2-8513-0782540b3d32 c756af2957c4447eafc4cef39cdb79e5
469dc3d300df4d41aaea00db572043ae - default default] REQ: curl -g -i -X
GET https://cinder:8776/v3/469dc3d300df4d41aaea00db572043ae/volumes/c67
b5cf3-0beb-4efa-9177-d2b6498185fb -H "X-Service-Token:
{SHA1}29a46cd87988e2bb905dbd3e796401aa23dff1a5" -H "User-Agent: python-
cinderclient" -H "Accept: application/json" -H "X-Auth-Token:
{SHA1}524061f0ab91e64ed6241e437792346f90df856e" _http_log_request
/usr/lib/python2.7/dist-packages/keystoneauth1/session.py:347
2017-11-30 15:19:57.890 92 INFO nova.osapi_compute.wsgi.server [req-
d83d5b73-fd24-406c-ad6b-feed6a40bfae c756af2957c4447eafc4cef39cdb79e5
469dc3d300df4d41aaea00db572043ae - default default] 10.78.21.2 "GET
/v2.1/flavors/203/os-extra_specs HTTP/1.1" status: 200 len: 448 time:
0.0326798
2017-11-30 15:19:58.148 93 DEBUG cinderclient.v3.client [req-5820c19b-
fb11-43a2-8513-0782540b3d32 c756af2957c4447eafc4cef39cdb79e5
469dc3d300df4d41aaea00db572043ae - default default] RESP: [401] Date:
Thu, 30 Nov 2017 15:19:57 GMT Server: Apache/2.4.18 (Ubuntu) x-
openstack-request-id: req-22378faa-880b-4a80-a83e-41936741839e WWW-
Authenticate: Keystone uri='https://keystone:5000/' Content-Length: 114
Content-Type: application/json
RESP BODY: {"error": {"message": "The request you have made requires
authentication.", "code": 401, "title": "Unauthorized"}}
 _http_log_response /usr/lib/python2.7/dist-
packages/keystoneauth1/session.py:395
2017-11-30 15:19:58.149 93 DEBUG cinderclient.v3.client [req-5820c19b-
fb11-43a2-8513-0782540b3d32 c756af2957c4447eafc4cef39cdb79e5
469dc3d300df4d41aaea00db572043ae - default default] GET call to
cinderv3 for https://cinder:8776/v3/469dc3d300df4d41aaea00db572043ae/vo
lumes/c67b5cf3-0beb-4efa-9177-d2b6498185fb used request id req-
22378faa-880b-4a80-a83e-41936741839e request /usr/lib/python2.7/dist-
packages/keystoneauth1/session.py:640
2017-11-30 15:19:58.157 93 DEBUG cinderclient.v3.client [req-5820c19b-
fb11-43a2-8513-0782540b3d32 c756af2957c4447eafc4cef39cdb79e5
469dc3d300df4d41aaea00db572043ae - default default] RESP: [401] Date:
Thu, 30 Nov 2017 15:19:58 GMT Server: Apache/2.4.18 (Ubuntu) x-
openstack-request-id: req-02ebac9f-794a-46f4-85b2-0e429a1785cf WWW-
Authenticate: Keystone uri='https://keystone:5000/' Content-Length: 114
Content-Type: application/json
RESP BODY: {"error": {"message": "The request you have made requires
authentication.", "code": 401, "title": "Unauthorized"}}
 _http_log_response /usr/lib/python2.7/dist-
packages/keystoneauth1/session.py:395
2017-11-30 15:19:58.158 93 ERROR nova.api.openstack.extensions [req-
5820c19b-fb11-43a2-8513-0782540b3d32 c756af2957c4447eafc4cef39cdb79e5
469dc3d300df4d41aaea00db572043ae - default default] Unexpected
exception in API method
2017-11-30 15:19:58.158 93 ERROR nova.api.openstack.extensions
Traceback (most recent call last):
2017-11-30 15:19:58.158 93 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/dist-packages/nova/api/openstack/extensions.py",
line 338, in wrapped
2017-11-30 15:19:58.158 93 ERROR
nova.api.openstack.extensions return f(*args, **kwargs)
2017-11-30 15:19:58.158 93 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/dist-packages/nova/api/openstack/common.py", line
359, in inner
2017-11-30 15:19:58.158 93 ERROR
nova.api.openstack.extensions return f(*args, **kwargs)
2017-11-30 15:19:58.158 93 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py",
line 108, in wrapper
2017-11-30 15:19:58.158 93 ERROR
nova.api.openstack.extensions return func(*args, **kwargs)
2017-11-30 15:19:58.158 93 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py",
line 108, in wrapper
2017-11-30 15:19:58.158 93 ERROR
nova.api.openstack.extensions return func(*args, **kwargs)
2017-11-30 15:19:58.158 93 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/dist-
packages/nova/api/openstack/compute/servers.py", line 1095, in
_action_create_image
2017-11-30 15:19:58.158 93 ERROR
nova.api.openstack.extensions metadata)
2017-11-30 15:19:58.158 93 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 151, in
inner
2017-11-30 15:19:58.158 93 ERROR
nova.api.openstack.extensions return f(self, context, instance,
*args, **kw)
2017-11-30 15:19:58.158 93 ERROR nova.api.openstack.extensions   File
"/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 2909, in
snapshot_volume_backed
2017-11-30 15:19:58.158 93 ERROR
nova.api.openstack.extensions volume = 

Re: [openstack-dev] [tripleo] Updates on the TripleO on Kubernetes work

[Dan Prince]

On Fri, Nov 17, 2017 at 4:43 AM, Steven Hardy  wrote:
>
>
> In the ansible/kubernetes model, it could work like:
>
> 1. Ansible role makes k8s API call creating pod with multiple containers
> 2. Pod starts temporary container that runs puppet, config files
> written out to shared volume
> 3. Service container starts, config consumed from shared volume
> 4. Optionally run temporary bootstrapping container inside pod
>
> This sort of pattern is documented here:
>
> https://kubernetes.io/docs/tasks/access-application-cluster/communicate-
> containers-same-pod-shared-volume/
>
>
>
Regarding the use of the shared volume I agree this is a nice iteration. We
considered using it within Pike as well but due to the Hybrid nature of the
deployment, and the desire to have config files easily debug friendly on
the host itself we ended up not going there.

In Queens however we are aiming for more or less full containerization so
we could consider the merits of this approach again. Just pointing out that
I don't think Kubernetes is a requirement in order to be able to proceed
with some of this improvement.

Dan
__
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] [cyborg]Queens Sprint meeting

[Zhipeng Huang]

Hi Team,

Please find the ZOOM links at https://trello.com/c/MhhxydAT for our next
sprint in about 11 hours.

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] [TripleO] Proposing Ronelle Landy for Tripleo-Quickstart/Extras/CI core

[Steven Hardy]

+1

On Thu, Nov 30, 2017 at 3:56 PM, Attila Darazs  wrote:
> On 11/29/2017 08:34 PM, John Trowbridge wrote:
>>
>> I would like to propose Ronelle be given +2 for the above repos. She has
>> been a solid contributor to tripleo-quickstart and extras almost since the
>> beginning. She has solid review numbers, but more importantly has always
>> done quality reviews. She also has been working in the very intense rover
>> role on the CI squad in the past CI sprint, and has done very well in that
>> role.
>
>
> +1, yep!
>
>
> __
> 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] [python-openstacksdk][shade] New cores proposed for shade/sdk

[Monty Taylor]

Hey everybody,

I'd like to propose adding Slawek Kaplonski (slaweq) and Rosario Di 
Somma (rods) to the shade/sdk core team. While they are clearly two 
different humans, I'm going to speak of them collectively since what I 
have to say about each of them is largely the same.


They were both super helpful in getting the REST transition completed 
and both of them have shown both a good understanding of the code - and 
that they know their boundaries. (Knowing when you don't know something 
turns out to be super important)


They both have exhibited an attention to detail, the ability to 
troubleshoot the weird kinds of things that we run in to in shade-land, 
and the ability to safely stage large or ugly changes in digestible chunks.


They have both shown an eagerness to jump in, figure out and handle hard 
issues.


Now that we've finished RESTification it's time to jump straight into 
shade/sdk integration. On the one hand it'll be a repeat of a bunch of 
what we just did - but on the other it's going to be infinitely easier 
because of all of the work slaweq and rods put in over the past year.


So let's add them to the core team, yeah?

Thanks!
Monty

__
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] [TripleO] Proposing Ronelle Landy for Tripleo-Quickstart/Extras/CI core

[Attila Darazs]

On 11/29/2017 08:34 PM, John Trowbridge wrote:
I would like to propose Ronelle be given +2 for the above repos. She has 
been a solid contributor to tripleo-quickstart and extras almost since 
the beginning. She has solid review numbers, but more importantly has 
always done quality reviews. She also has been working in the very 
intense rover role on the CI squad in the past CI sprint, and has done 
very well in that role.


+1, yep!

__
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] [release] Release countdown for week R-12, December 2-8

[Sean McGinnis]

Development Focus
-

The Queens-2 milestone deadline is December 7th. All projects with specific
deadlines should be wrapping them up in time to submit the release request
before the end of day on the 7th.

General Information
---

Membership freeze coincides with milestone 2 [0]. This means projects that have
not done a release yet must do so for the next two milestones to be included in
the Queens release.

[0] https://releases.openstack.org/queens/schedule.html#q-mf

The following libraries have not done a release yet in the queens cycle:

ceilometermiddleware
django_openstack_auth
glance-store
heat-translator
ldappool
mistral-lib
os-client-config
os-vif
osc-lib
pycadf
python-aodhclient
python-barbicanclient
python-ceilometerclient
python-cloudkittyclient
python-congressclient
python-designateclient
python-freezerclient
python-glanceclient
python-ironic-inspector-client
python-karborclient
python-keystoneclient
python-magnumclient
python-mistralclient
python-muranoclient
python-neutronclient
python-novaclient
python-octaviaclient
python-pankoclient
python-searchlightclient
python-senlinclient
python-solumclient
python-swiftclient
python-tackerclient
python-tricircleclient
python-vitrageclient
python-zaqarclient
requestsexceptions
tosca-parser

For library-only projects, please be aware of the membership freeze mentioned
above.

Remember that there are client and non-client library freezes for the release
starting mid-January.

If there are any questions about preparing a release by the 7th, please come
talk to us in #openstack-releases.

Upcoming Deadlines & Dates
--

Queens-2 Milestone: December 7
Final non-client library release deadline: January 18
Final client library release deadline: January 25
Queens-3 Milestone: January 25
Rocky PTG in Dublin: Week of February 26, 2018

-- 
Sean McGinnis (smcginnis)

__
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] [TripleO] Proposing Ronelle Landy for Tripleo-Quickstart/Extras/CI core

[James Slagle]

On Wed, Nov 29, 2017 at 2:34 PM, John Trowbridge  wrote:
> I would like to propose Ronelle be given +2 for the above repos. She has
> been a solid contributor to tripleo-quickstart and extras almost since the
> beginning. She has solid review numbers, but more importantly has always
> done quality reviews. She also has been working in the very intense rover
> role on the CI squad in the past CI sprint, and has done very well in that
> role.

+1


-- 
-- 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] [all] Dublin PTG format

[Dmitry Tantsur]

On 11/27/2017 11:58 AM, Thierry Carrez wrote:

Hi everyone,

We are in the final step in the process of signing the contract with the
PTG venue. We should be able to announce the location this week !

So it's time to start preparing. We'll have 5 days, like in Denver. One
thing we'd like to change for this round is to give a bit more
flexibility in the topics being discussed, especially in the first two days.

In Denver, we selected a number of general "themes" and gave them all a
room for 2 days on Monday-Tuesday. Then all the "teams" that wanted a
project team meeting could get a room for 2 or 3 days on
Wednesday-Friday. That resulted in a bit of flux during the first two
days, with a lot of empty rooms as most of the themes did not really
need 2 days, and a lot of conflicts were present.

For Dublin, the idea would be to still predetermine topics (themes and
teams) and assign them rooms in advance. But we would be able to assign
smaller amounts of time (per half-day) based on the expressed needs.
Beyond those pre-assigned themes/teams we'd add flexibility for other
groups to book the remaining available rooms in 90-min slots on-demand.
A bit like how we did reservable rooms in the past, but more integrated
with the rest of the event. It would all be driven by the PTGbot, which
would show which topic is being discussed in which room, in addition to
the current discussion subject within each topic.

We have two options in how we do the split for predetermined topics. We
used to split the week between Mon-Tue (themes) and Wed-Fri (teams). The
general idea there was to allow some people only interested in a team
meeting to only attend the second part of the week. However most people
attend all 5 days, and during event feedback some people suggested that
"themes" should be in the mornings and "teams" in the afternoons (and
all Friday).


I'm not sure about "most people", I guess you're more informed than me :) I used 
to be on board with "let us make more people attend by stretching the teams 
part" previously. But after seeing actual budget problems, I started to think 
that allowing people to travel only for 3 days is a feature.


Side note: I expect a substantial share of people, especially from Europe, to 
arrive on Monday morning and leave on Friday evening.




What would be your preference ? The Mon-Tue/Wed-Fri split means less
room changes, which make it easier on the events team. So all else being
equal we'd rather keep it the way it is, but I'm open to changing it if
attendees think it's a good idea.


I'm kind of +0 on experimenting with it, taking into account what I mentioned 
above.



If you have any other suggestion (that we could implement in the 3
months we have between now and the event) please let me know :)




__
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] [TripleO] Proposing Ronelle Landy for Tripleo-Quickstart/Extras/CI core

[Arx Cruz]

+1 well deserved!!!

On Thu, Nov 30, 2017 at 11:37 AM, Jiří Stránský  wrote:

> +1
>
>
> On 29.11.2017 20:34, John Trowbridge wrote:
>
>> I would like to propose Ronelle be given +2 for the above repos. She has
>> been a solid contributor to tripleo-quickstart and extras almost since the
>> beginning. She has solid review numbers, but more importantly has always
>> done quality reviews. She also has been working in the very intense rover
>> role on the CI squad in the past CI sprint, and has done very well in that
>> role.
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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] [heat][qa] Split tempest plugin from heat

[Rico Lin]

>
> Does anybody remember what the mechanism for dealing with this that was
agreed at the PTG was?

The etherpad [1] shows actions that we(me and Thomas) agree to do, and
that's all for PTG discussion (the online attendee number is 0 for that
session).
Following with a recap in meeting to share the task and include that
etherpad (which Rabi's agreement on fallow). And with further implement and
research (by Rabi), we face the test separation issue, as we discussed
yesterday, Rabi reaches out for suggestion and opinions,  and I gave mine
with agreeing to move all test to the new repo and giving my +2 review to
those patches.
IMO, that's a question of whether we consider our tests as part of tempest
plugin or we want to consider them as internal Heat CI tests.

Right now what we have is following:
1. A new repo for heat-tempest-plugin with all tests in it.
2. Switch heat's functional and grenade jobs (in master) to use new heat
tempest plugin.
3. a patch to propose to remove integration tests in heat.
4. needs a plan to match branchless for heat-tempest-plugin repo

>
> Basically we need a way to:
>
> * Run a bunch of integration tests in Heat CI jobs
> * against a full OpenStack cloud
> * preferably using tempest as a testrunner, but this is optional
> * without any danger of e.g. breaking tempest test discovery just because
Heat was installed on the same machine as tempest
>
> How do we do it?

We now use tempest for all our integration tests but seems the question now
is how can we let our the CI out of this process, so all developers in heat
will have a better life while users/ops will also have a better life when
testing against their OpenStack environment.

My propose is we separate our tests into two groups:
A group of tests that should only stay in Heat CI jobs, which we still can
use tempest as test runner, but we should mark it(with a description, a
tag, or any way) as for internal CI usage, which will not follow any TC
goals since that's only for heat internal usage.

Another group of tests that make sense for us to expose to users and
operators. These stay in heat tempest plugin which users/ops can use to
test their own environment, and we will meet what the users/ops might
expect when they testing with their own heat environment. Also means we
should keep this repo branchless and fully tested with each branch. So we
stick with that goal. API tests seem to be native in this group, but we
have to keep in mind that it's not covering all cases, so we might need to
consider to add more tests in tempest plugin (in long-term).

In turns of actions:

1. Create a new tempest plugin for internal CI usage (in heat repo) and
mark it as internal(as a declare for we do not consider this as a tempest
plugin for users/ops), so others will know that they should not use it for
any other way(or use at their own risk).
2. Modify the patch which proposes to remove integration tests in heat, and
keeps tests those tests we decided as internal CI tests.
3. Allow heat gate to run tests from both tempest plugin( internal one and
`heat-tempest-plugin`) so we will still run and check both works. Of
course, we can keep the same group of tests on both sides(like a sync job)
but don't see why that's the way we like.

We should have this discussion earlier (when a simple suggestion from any
one of us will do), but since we still under developing cycle that means
it's not too late for anything.
And TBH, as a developer(not a good one but still learning), I see this goal
as pure painful plus useless for developers in heat, but I trust TCs and QA
team when they think this is so important (on how this will help users/ops
when testing their environment) that they decided to make this as a goal
for our community.

I'm fine with whatever the solution we came out from here, and I'm happy to
implement it together, but please keep in mind that we need all to help us
track the progress, so we can have more opinions or suggestions for any
issues we are/will face on these tasks.

Let's do this together and make it right at once!

Would really like to hear more suggestions on how we can deal with this or
how other teams do, so please share with us if you(heat/QA member or not)
see this mail.


[1] https://etherpad.openstack.org/p/heat-queens-ptg-tempest-plugin
__
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] [kolla] Vxlan and OVS issues post deployment.

[Goutham Pratapa]

Hi Eduardo,

No, they were not created by default I had to follow the workaround only
then they are getting created

I'm just bringing to your notice that the issue is still there because they
are not present after the deployment  :)

Now even after the tunnels are created VM's are not getting the IP

Thanks
Goutham.

On Thu, Nov 30, 2017 at 4:02 PM, Eduardo Gonzalez 
wrote:

> Hi Goutham,
>
> VXLAN tunnels are created between network/compute hosts in expected
> interface (ens3):
>
> df_default="true", in_key=flow, local_ip="192.168.122.215", out_key=flow, 
> remote_ip="192.168.122.177"
>
> Where is exactly failing? Instances not get IP, DHCP does not work, vm-to-vm 
> traffic issues, public traffic issues?
>
> Regards
>
>
> 2017-11-30 11:26 GMT+01:00 Goutham Pratapa :
>
>> Hi Eduardo,
>>
>> I am trying to deploy self-service network topology.
>>
>> I think then I shouldn't be bothered about the `ens8` because I'm not
>> dealing with provider networks
>>
>> and attached are the outputs requested...
>>
>> Ps: Controller and the network node are both same in my setup.
>>
>> Thanks in advance
>>
>> Goutham
>>
>> On Thu, Nov 30, 2017 at 3:33 PM, Eduardo Gonzalez 
>> wrote:
>>
>>> Hi,
>>>
>>> In kolla,VXLAN  tunnels are connfigured in ``tunnel_interface`` variable
>>> which defaults to ``network_interface``, ``neutron_external_interface`` is
>>> used for public floating IPs in neutron.
>>>
>>> Please share your globals.yml, ``ip a`` output in compute/network hosts
>>> and ``ovs-vsctl show`` from openvswitch daemon containers.
>>>
>>> What network topology are you trying to deploy? Self-service, provider
>>> networks, etc?
>>>
>>> Regards
>>>
>>>
>>> 2017-11-30 10:42 GMT+01:00 Jeffrey Zhang :
>>>
 i guess you didn't enabled one of following[0]

   enable_neutron_dvr: yes
   enable_neutron_provider_networks: yes

 I hit this recently. i am thinking we should remove this or make
 enable_neutron_provider_network=yes in default.

 [0] https://github.com/openstack/kolla-ansible/blob/master/a
 nsible/group_vars/all.yml#L607


 On Thu, Nov 30, 2017 at 5:11 PM, Goutham Pratapa <
 pratapagout...@gmail.com> wrote:

> Hi Kolla Team,
>
> I have tried deploying Kolla OpenStack multinode and I am facing this
> issue vxlan_peers_not_created
> 
> in every deployment and I* tried the workaround* i.e restart the
> network  containers to get the vxlan peers
>
> But when I see *ip addr show *in my compute node.
>
> *P.S:* "ens8"  is the interface I specified as
> *neutron_external_interface** in globals.yml*
>
>
> * Globals.yml-*
>
>
>
>
> *# This is the raw interface given to neutron as its external network
> port. Even# though an IP address can exist on this interface, it will be
> unusable in most# configurations. It is recommended this interface not be
> configured with any IP# addresses for that reason.*
>
> *neutron_external_interface: "ens8"*3: ens8:
>  mtu 1500 qdisc pfifo_fast state UP
> group default qlen 1000
> link/ether 52:54:00:54:b3:50 brd ff:ff:ff:ff:ff:ff
> inet 192.168.122.218/24 scope global ens8
>valid_lft forever preferred_lft forever
> inet6 fe80::5054:ff:fe54:b350/64 scope link
>valid_lft forever preferred_lft forever
>
> Which should be something like the below (as per my understanding) for
> the Vms to be up and running.
>
> 3: ens8:  mtu 1500 qdisc pfifo_fast 
> *master
> ovs-system* state UP group default qlen 1000
> link/ether 52:54:00:22:4b:cf brd ff:ff:ff:ff:ff:ff
> inet 192.168.122.165/32 scope global ens8
>valid_lft forever preferred_lft forever
> inet6 fe80::5054:ff:fe22:4bcf/64 scope link
>valid_lft forever preferred_lft forever
>
> Is this a known issue ??
>
> If yes any workaround to solve??
>
> Thanks in advance.
> --
> Thanks!!!
> Goutham Pratapa
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.op
> enstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


 --
 Regards,
 Jeffrey Zhang
 Blog: http://xcodest.me

 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.op
 enstack.org?subject:unsubscribe
 

Re: [openstack-dev] [TripleO] Proposing Ronelle Landy for Tripleo-Quickstart/Extras/CI core

[Jiří Stránský]

+1

On 29.11.2017 20:34, John Trowbridge wrote:

I would like to propose Ronelle be given +2 for the above repos. She has
been a solid contributor to tripleo-quickstart and extras almost since the
beginning. She has solid review numbers, but more importantly has always
done quality reviews. She also has been working in the very intense rover
role on the CI squad in the past CI sprint, and has done very well in that
role.



__
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] [Kolla][Kubernetes][Doomed] So close but yet so far

[Michael Still]

Hi,

I'm out of my depth a little here. I've done the following:

 - installed kubernetes
 - followed the deploy guide for kolla-kubernetes [1]
 - except where I didn't because I had to fix it [2]

I can download an openrc and even send a "nova boot" that looks like it
works. However, I have this container in the list:

kolla nova-api-create-cell-947hc0/1   Init:2/3
0  24m   10.1.0.195  lab8
Which means that the instance doesn't actually start:

$ openstack server show demo1 --format shell
os_dcf_diskconfig="MANUAL"
os_ext_az_availability_zone=""
os_ext_srv_attr_host="None"
os_ext_srv_attr_hypervisor_hostname="None"
os_ext_srv_attr_instance_name=""
os_ext_sts_power_state="NOSTATE"
os_ext_sts_task_state="scheduling"
os_ext_sts_vm_state="building"
os_srv_usg_launched_at="None"
os_srv_usg_terminated_at="None"
accessipv4=""
accessipv6=""
addresses=""
config_drive=""
created="2017-11-30T10:24:19Z"
flavor="m1.tiny (1)"
hostid=""
id="a531bedc-fc2a-4d59-8643-18e1b83943fe"
image="cirros (04053309-9a5c-4f25-8dda-2ff898f5a400)"
key_name="mykey"
name="demo1"
progress="0"
project_id="d0a64448a0d940b48c579f8fbb774827"
properties=""
status="BUILD"
updated="2017-11-30T10:34:45Z"
user_id="420105e944c64b918185cdc22f55fdfc"
volumes_attached=""

Where it sits forever, presumably waiting for someone to notice the request.

I'm a but stumped as to how to debug further. Could I have a hint please?

Thanks,
Michael

1: https://docs.openstack.org/kolla-kubernetes/latest/deployment-guide.html
2: https://review.openstack.org/#/c/524125/
__
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] [Neutron] Propose Slawek Kaplonski for Neutron core

[Jakub Libosvar]

Big +1 for Slawek :)

On 30/11/2017 00:49, Armando M. wrote:
> On 29 November 2017 at 12:27, Korzeniewski, Artur <
> artur.korzeniew...@intel.com> wrote:
> 
>> +1 from me , (even though my vote does not count)
>>
>> I know Slawek since Tokyo summit and I’m impressed of his knowledge and
>> hands-on experience to improve Neutron quality and functionality!
>>
>> It is great to see him joining the core reviewers team!
>>
>> Congrats Sławek!
>>
> 
> Rock On
> 
> 
>>
>>
>> *From:* Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com]
>> *Sent:* Wednesday, November 29, 2017 8:47 PM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> *Subject:* Re: [openstack-dev] [Neutron] Propose Slawek Kaplonski for
>> Neutron core
>>
>>
>>
>> "+1" I know, I'm not active, but I care about neutron, and slaweq is a
>> great contributor.
>>
>>
>>
>> On Nov 29, 2017 8:37 PM, "Ihar Hrachyshka"  wrote:
>>
>> YES, FINALLY.
>>
>> On Wed, Nov 29, 2017 at 11:29 AM, Kevin Benton  wrote:
>>> +1! ... even though I haven't been around. :)
>>>
>>> On Wed, Nov 29, 2017 at 1:21 PM, Miguel Lavalle 
>> wrote:

 Hi Neutron Team,

 I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core.
>> Slawek
 has been an active contributor to the project since the Mitaka cycle.
>> He has
 been instrumental in the development of the QoS capabilities in Neutron,
 becoming the lead of the sub-team focused on that set of features. More
 recently, he has collaborated in the implementation of OVO and is an
>> active
 participant in the CI sub-team. His number of code reviews during the
>> Queens
 cycle is on par with the leading core members of the team:
 http://stackalytics.com/?module=neutron

 In my opinion, his efforts are highly valuable to the team and we will
>> be
 very lucky to have him as a fully voting core.

 I will keep this nomination open for a week as customary,

 Thank you,

 Miguel

 
>> __
 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 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] [kolla] Vxlan and OVS issues post deployment.

[Eduardo Gonzalez]

Hi Goutham,

VXLAN tunnels are created between network/compute hosts in expected
interface (ens3):

df_default="true", in_key=flow, local_ip="192.168.122.215",
out_key=flow, remote_ip="192.168.122.177"

Where is exactly failing? Instances not get IP, DHCP does not work,
vm-to-vm traffic issues, public traffic issues?

Regards


2017-11-30 11:26 GMT+01:00 Goutham Pratapa :

> Hi Eduardo,
>
> I am trying to deploy self-service network topology.
>
> I think then I shouldn't be bothered about the `ens8` because I'm not
> dealing with provider networks
>
> and attached are the outputs requested...
>
> Ps: Controller and the network node are both same in my setup.
>
> Thanks in advance
>
> Goutham
>
> On Thu, Nov 30, 2017 at 3:33 PM, Eduardo Gonzalez 
> wrote:
>
>> Hi,
>>
>> In kolla,VXLAN  tunnels are connfigured in ``tunnel_interface`` variable
>> which defaults to ``network_interface``, ``neutron_external_interface`` is
>> used for public floating IPs in neutron.
>>
>> Please share your globals.yml, ``ip a`` output in compute/network hosts
>> and ``ovs-vsctl show`` from openvswitch daemon containers.
>>
>> What network topology are you trying to deploy? Self-service, provider
>> networks, etc?
>>
>> Regards
>>
>>
>> 2017-11-30 10:42 GMT+01:00 Jeffrey Zhang :
>>
>>> i guess you didn't enabled one of following[0]
>>>
>>>   enable_neutron_dvr: yes
>>>   enable_neutron_provider_networks: yes
>>>
>>> I hit this recently. i am thinking we should remove this or make
>>> enable_neutron_provider_network=yes in default.
>>>
>>> [0] https://github.com/openstack/kolla-ansible/blob/master/a
>>> nsible/group_vars/all.yml#L607
>>>
>>>
>>> On Thu, Nov 30, 2017 at 5:11 PM, Goutham Pratapa <
>>> pratapagout...@gmail.com> wrote:
>>>
 Hi Kolla Team,

 I have tried deploying Kolla OpenStack multinode and I am facing this
 issue vxlan_peers_not_created
 
 in every deployment and I* tried the workaround* i.e restart the
 network  containers to get the vxlan peers

 But when I see *ip addr show *in my compute node.

 *P.S:* "ens8"  is the interface I specified as
 *neutron_external_interface** in globals.yml*


 * Globals.yml-*




 *# This is the raw interface given to neutron as its external network
 port. Even# though an IP address can exist on this interface, it will be
 unusable in most# configurations. It is recommended this interface not be
 configured with any IP# addresses for that reason.*

 *neutron_external_interface: "ens8"*3: ens8:
  mtu 1500 qdisc pfifo_fast state UP
 group default qlen 1000
 link/ether 52:54:00:54:b3:50 brd ff:ff:ff:ff:ff:ff
 inet 192.168.122.218/24 scope global ens8
valid_lft forever preferred_lft forever
 inet6 fe80::5054:ff:fe54:b350/64 scope link
valid_lft forever preferred_lft forever

 Which should be something like the below (as per my understanding) for
 the Vms to be up and running.

 3: ens8:  mtu 1500 qdisc pfifo_fast 
 *master
 ovs-system* state UP group default qlen 1000
 link/ether 52:54:00:22:4b:cf brd ff:ff:ff:ff:ff:ff
 inet 192.168.122.165/32 scope global ens8
valid_lft forever preferred_lft forever
 inet6 fe80::5054:ff:fe22:4bcf/64 scope link
valid_lft forever preferred_lft forever

 Is this a known issue ??

 If yes any workaround to solve??

 Thanks in advance.
 --
 Thanks!!!
 Goutham Pratapa

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


>>>
>>>
>>> --
>>> Regards,
>>> Jeffrey Zhang
>>> Blog: http://xcodest.me
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Cheers !!!
> Goutham Pratapa
>
> __
> OpenStack Development Mailing List (not for usage 

Re: [openstack-dev] [kolla] Vxlan and OVS issues post deployment.

[Goutham Pratapa]

Hi Eduardo,

I am trying to deploy self-service network topology.

I think then I shouldn't be bothered about the `ens8` because I'm not
dealing with provider networks

and attached are the outputs requested...

Ps: Controller and the network node are both same in my setup.

Thanks in advance

Goutham

On Thu, Nov 30, 2017 at 3:33 PM, Eduardo Gonzalez 
wrote:

> Hi,
>
> In kolla,VXLAN  tunnels are connfigured in ``tunnel_interface`` variable
> which defaults to ``network_interface``, ``neutron_external_interface`` is
> used for public floating IPs in neutron.
>
> Please share your globals.yml, ``ip a`` output in compute/network hosts
> and ``ovs-vsctl show`` from openvswitch daemon containers.
>
> What network topology are you trying to deploy? Self-service, provider
> networks, etc?
>
> Regards
>
>
> 2017-11-30 10:42 GMT+01:00 Jeffrey Zhang :
>
>> i guess you didn't enabled one of following[0]
>>
>>   enable_neutron_dvr: yes
>>   enable_neutron_provider_networks: yes
>>
>> I hit this recently. i am thinking we should remove this or make
>> enable_neutron_provider_network=yes in default.
>>
>> [0] https://github.com/openstack/kolla-ansible/blob/master/
>> ansible/group_vars/all.yml#L607
>>
>>
>> On Thu, Nov 30, 2017 at 5:11 PM, Goutham Pratapa <
>> pratapagout...@gmail.com> wrote:
>>
>>> Hi Kolla Team,
>>>
>>> I have tried deploying Kolla OpenStack multinode and I am facing this
>>> issue vxlan_peers_not_created
>>> 
>>> in every deployment and I* tried the workaround* i.e restart the
>>> network  containers to get the vxlan peers
>>>
>>> But when I see *ip addr show *in my compute node.
>>>
>>> *P.S:* "ens8"  is the interface I specified as
>>> *neutron_external_interface** in globals.yml*
>>>
>>>
>>> * Globals.yml-*
>>>
>>>
>>>
>>>
>>> *# This is the raw interface given to neutron as its external network
>>> port. Even# though an IP address can exist on this interface, it will be
>>> unusable in most# configurations. It is recommended this interface not be
>>> configured with any IP# addresses for that reason.*
>>>
>>> *neutron_external_interface: "ens8"*3: ens8:
>>>  mtu 1500 qdisc pfifo_fast state UP
>>> group default qlen 1000
>>> link/ether 52:54:00:54:b3:50 brd ff:ff:ff:ff:ff:ff
>>> inet 192.168.122.218/24 scope global ens8
>>>valid_lft forever preferred_lft forever
>>> inet6 fe80::5054:ff:fe54:b350/64 scope link
>>>valid_lft forever preferred_lft forever
>>>
>>> Which should be something like the below (as per my understanding) for
>>> the Vms to be up and running.
>>>
>>> 3: ens8:  mtu 1500 qdisc pfifo_fast *master
>>> ovs-system* state UP group default qlen 1000
>>> link/ether 52:54:00:22:4b:cf brd ff:ff:ff:ff:ff:ff
>>> inet 192.168.122.165/32 scope global ens8
>>>valid_lft forever preferred_lft forever
>>> inet6 fe80::5054:ff:fe22:4bcf/64 scope link
>>>valid_lft forever preferred_lft forever
>>>
>>> Is this a known issue ??
>>>
>>> If yes any workaround to solve??
>>>
>>> Thanks in advance.
>>> --
>>> Thanks!!!
>>> Goutham Pratapa
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Regards,
>> Jeffrey Zhang
>> Blog: http://xcodest.me
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


-- 
Cheers !!!
Goutham Pratapa

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: ens3:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether 52:54:00:30:a5:ee brd ff:ff:ff:ff:ff:ff
inet 192.168.122.215/24 brd 192.168.122.255 scope global ens3
   valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe30:a5ee/64 scope link
   valid_lft forever preferred_lft forever
3: ens8: 

Re: [openstack-dev] [kolla] Vxlan and OVS issues post deployment.

[Eduardo Gonzalez]

Hi,

In kolla,VXLAN  tunnels are connfigured in ``tunnel_interface`` variable
which defaults to ``network_interface``, ``neutron_external_interface`` is
used for public floating IPs in neutron.

Please share your globals.yml, ``ip a`` output in compute/network hosts and
``ovs-vsctl show`` from openvswitch daemon containers.

What network topology are you trying to deploy? Self-service, provider
networks, etc?

Regards


2017-11-30 10:42 GMT+01:00 Jeffrey Zhang :

> i guess you didn't enabled one of following[0]
>
>   enable_neutron_dvr: yes
>   enable_neutron_provider_networks: yes
>
> I hit this recently. i am thinking we should remove this or make
> enable_neutron_provider_network=yes in default.
>
> [0] https://github.com/openstack/kolla-ansible/blob/
> master/ansible/group_vars/all.yml#L607
>
>
> On Thu, Nov 30, 2017 at 5:11 PM, Goutham Pratapa  > wrote:
>
>> Hi Kolla Team,
>>
>> I have tried deploying Kolla OpenStack multinode and I am facing this
>> issue vxlan_peers_not_created
>> 
>> in every deployment and I* tried the workaround* i.e restart the
>> network  containers to get the vxlan peers
>>
>> But when I see *ip addr show *in my compute node.
>>
>> *P.S:* "ens8"  is the interface I specified as
>> *neutron_external_interface** in globals.yml*
>>
>>
>> * Globals.yml-*
>>
>>
>>
>>
>> *# This is the raw interface given to neutron as its external network
>> port. Even# though an IP address can exist on this interface, it will be
>> unusable in most# configurations. It is recommended this interface not be
>> configured with any IP# addresses for that reason.*
>>
>> *neutron_external_interface: "ens8"*3: ens8:
>>  mtu 1500 qdisc pfifo_fast state UP
>> group default qlen 1000
>> link/ether 52:54:00:54:b3:50 brd ff:ff:ff:ff:ff:ff
>> inet 192.168.122.218/24 scope global ens8
>>valid_lft forever preferred_lft forever
>> inet6 fe80::5054:ff:fe54:b350/64 scope link
>>valid_lft forever preferred_lft forever
>>
>> Which should be something like the below (as per my understanding) for
>> the Vms to be up and running.
>>
>> 3: ens8:  mtu 1500 qdisc pfifo_fast *master
>> ovs-system* state UP group default qlen 1000
>> link/ether 52:54:00:22:4b:cf brd ff:ff:ff:ff:ff:ff
>> inet 192.168.122.165/32 scope global ens8
>>valid_lft forever preferred_lft forever
>> inet6 fe80::5054:ff:fe22:4bcf/64 scope link
>>valid_lft forever preferred_lft forever
>>
>> Is this a known issue ??
>>
>> If yes any workaround to solve??
>>
>> Thanks in advance.
>> --
>> Thanks!!!
>> Goutham Pratapa
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> 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] [kolla] Vxlan and OVS issues post deployment.

[Jeffrey Zhang]

i guess you didn't enabled one of following[0]

  enable_neutron_dvr: yes
  enable_neutron_provider_networks: yes

I hit this recently. i am thinking we should remove this or make
enable_neutron_provider_network=yes in default.

[0]
https://github.com/openstack/kolla-ansible/blob/master/ansible/group_vars/all.yml#L607


On Thu, Nov 30, 2017 at 5:11 PM, Goutham Pratapa 
wrote:

> Hi Kolla Team,
>
> I have tried deploying Kolla OpenStack multinode and I am facing this
> issue vxlan_peers_not_created
> 
> in every deployment and I* tried the workaround* i.e restart the network
> containers to get the vxlan peers
>
> But when I see *ip addr show *in my compute node.
>
> *P.S:* "ens8"  is the interface I specified as
> *neutron_external_interface** in globals.yml*
>
>
> * Globals.yml-*
>
>
>
>
> *# This is the raw interface given to neutron as its external network
> port. Even# though an IP address can exist on this interface, it will be
> unusable in most# configurations. It is recommended this interface not be
> configured with any IP# addresses for that reason.*
>
> *neutron_external_interface: "ens8"*3: ens8:
>  mtu 1500 qdisc pfifo_fast state UP
> group default qlen 1000
> link/ether 52:54:00:54:b3:50 brd ff:ff:ff:ff:ff:ff
> inet 192.168.122.218/24 scope global ens8
>valid_lft forever preferred_lft forever
> inet6 fe80::5054:ff:fe54:b350/64 scope link
>valid_lft forever preferred_lft forever
>
> Which should be something like the below (as per my understanding) for the
> Vms to be up and running.
>
> 3: ens8:  mtu 1500 qdisc pfifo_fast *master
> ovs-system* state UP group default qlen 1000
> link/ether 52:54:00:22:4b:cf brd ff:ff:ff:ff:ff:ff
> inet 192.168.122.165/32 scope global ens8
>valid_lft forever preferred_lft forever
> inet6 fe80::5054:ff:fe22:4bcf/64 scope link
>valid_lft forever preferred_lft forever
>
> Is this a known issue ??
>
> If yes any workaround to solve??
>
> Thanks in advance.
> --
> Thanks!!!
> Goutham Pratapa
>
> __
> 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,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] [kolla] Vxlan and OVS issues post deployment.

[Goutham Pratapa]

Hi Kolla Team,

I have tried deploying Kolla OpenStack multinode and I am facing this issue
vxlan_peers_not_created

in every deployment and I* tried the workaround* i.e restart the network
containers to get the vxlan peers

But when I see *ip addr show *in my compute node.

*P.S:* "ens8"  is the interface I specified as *neutron_external_interface**
in globals.yml*


* Globals.yml-*




*# This is the raw interface given to neutron as its external network port.
Even# though an IP address can exist on this interface, it will be unusable
in most# configurations. It is recommended this interface not be configured
with any IP# addresses for that reason.*

*neutron_external_interface: "ens8"*3: ens8:
 mtu 1500 qdisc pfifo_fast state UP group
default qlen 1000
link/ether 52:54:00:54:b3:50 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.218/24 scope global ens8
   valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe54:b350/64 scope link
   valid_lft forever preferred_lft forever

Which should be something like the below (as per my understanding) for the
Vms to be up and running.

3: ens8:  mtu 1500 qdisc pfifo_fast *master
ovs-system* state UP group default qlen 1000
link/ether 52:54:00:22:4b:cf brd ff:ff:ff:ff:ff:ff
inet 192.168.122.165/32 scope global ens8
   valid_lft forever preferred_lft forever
inet6 fe80::5054:ff:fe22:4bcf/64 scope link
   valid_lft forever preferred_lft forever

Is this a known issue ??

If yes any workaround to solve??

Thanks in advance.
-- 
Thanks!!!
Goutham Pratapa
__
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] Meeting Thursday Nov 30th at 8:00 UTC

[zhu.fanglei]

As to the scenario refactor, the following patches need review, and in fact I 
am waiting for the second patch to finish, because the change is a little big.


https://review.openstack.org/#/c/519985/ Add extra_msg and server parameter to 
check_vm_connectivity


https://review.openstack.org/#/c/498124/ Use neutron client for floating ips in 
scenarios (">Duc Truong)


I wonder when " style="line-height: 1.5em;">Duc Truong can be free to deal with 
gmann's comments:)







-zhufl



Original Mail



Sender:  ;
To:  ;
Date: 2017/11/30 11:04
Subject: [openstack-dev]  [QA] Meeting Thursday Nov 30th at 8:00 UTC


Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, Nov 30th at 8:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_Nov_30th_2017_.280800_UTC.29

Anyone is welcome to add an item to the agenda.

-gmann

__
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