Re: [openstack-dev] [kolla] [cinder] [ironic] [tripleo] PTG cross-platform meetup possibility

[Emilien Macchi]

On Fri, Sep 8, 2017 at 7:04 PM, Michał Jastrzębski  wrote:
> I know about wed meeting. This is when we wanted to discuss kolla-k8s and
> tripleo shared resources,  whatever they might be.  I assumed Mon meeting is
> different?

So Monday is cross deployment projects collaboration meeting and
Wednesday is whatever TripleO / Kolla collab related things.
Does it make sense?
-- 
Emilien Macchi

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

Re: [openstack-dev] [devstack] SUSE jobs started failing on peakmem_tracker

[Dirk Müller]

Hi David,

Thanks for looking into this. I do watch devstack changes every once in a
while but couldn't catch this one  in time. The missing pmap -XX flag
problem has been there forever but it used to be non fatal. Now it is,
which is in principle a good change.

I will make sure that it passes again on SUSE shortly.

Greetings,
Dirk

I was trying to make sure the existing openSUSE jobs passed on Zuul v3
but even the regular v2 jobs are hitting a bug I filed here [1].
As far as I know, these jobs were passing until recently.



This is preventing us from sanity checking that everything works out
of the box for the suse devstack job for the v3 migration.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] - transitioning PTL role to Miguel Lavalle

[Kevin Benton]

Hi everyone,

Due to a change in my role at my employer, I no longer have time to be the
PTL of Neutron. Effective immediately, I will be transitioning the PTL role
to Miguel Lavalle.

Miguel is an excellent leader in the community and has experience reviewing
patches as a core, reviewing feature requests and specs as a driver,
implementing cross-project features, handling docs, and on-boarding new
contributors.

We will make the switch official next week at the PTG with the appropriate
patches to the governance repo.

If anyone has any concerns with this transition plan, please reach out to
me, Thierry, or Doug Hellmann.

Cheers,
Kevin Benton
__
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] [cinder] [ironic] [tripleo] PTG cross-platform meetup possibility

[Richard Wellum]

No I think it's the same thing, couple of us just didn't know it had been
scheduled for Wednesday. Sorry for confusion.

4pm Monday can still be used for cinder, ironic and kolla cross platform,
and we can use the room I've booked.

Cheers,

Rich

On Fri, Sep 8, 2017, 10:04 PM Michał Jastrzębski  wrote:

> Hey,
>
> I know about wed meeting. This is when we wanted to discuss kolla-k8s and
> tripleo shared resources,  whatever they might be.  I assumed Mon meeting
> is different?
>
> On Sep 8, 2017 6:22 PM, "Richard Wellum"  wrote:
>
>> Emilien,
>>
>> Can you please update this on the schedule if it's not already? The link
>> to the spreadsheet is in this thread.
>>
>> Michal didn't seem to know about this Wednesday meeting because he
>> replied to my email for Monday, with a confirmation, But maybe I'm missing
>> something. And we, kolla, all thought it was Monday, although we searched
>> for the conversation today and couldn't find anything. So not sure everyone
>> is synched up. Could just be me; it's been a long week.
>>
>> Cheers,
>>
>> Rich
>>
>> On Fri, Sep 8, 2017, 5:15 PM Vikram Hosakote (vhosakot) <
>> vhosa...@cisco.com> wrote:
>>
>>> Cool, we’ll hold the room reservation in Durango on Monday 2-4 pm for
>>> the cross-project
>>>
>>> meeting with the deployment tool groups (Kolla, Ansible, TripleO, Chef,
>>> Puppet, Helm,
>>>
>>> etc).
>>>
>>>
>>>
>>> Regards,
>>>
>>> Vikram Hosakote
>>>
>>> IRC:  vhosakot
>>>
>>>
>>>
>>> *From: *Emilien Macchi 
>>> *Reply-To: *"OpenStack Development Mailing List (not for usage
>>> questions)" 
>>> *Date: *Friday, September 8, 2017 at 4:04 PM
>>> *To: *"OpenStack Development Mailing List (not for usage questions)" <
>>> openstack-dev@lists.openstack.org>
>>> *Subject: *Re: [openstack-dev] [kolla] [cinder] [ironic] [tripleo] PTG
>>> cross-platform meetup possibility
>>>
>>>
>>>
>>> On Fri, Sep 8, 2017 at 12:49 PM, Richard Wellum 
>>> wrote:
>>>
>>> Triple-O team - can you please confirm the Monday slot, 2-4pm still works
>>>
>>> for you?
>>>
>>>
>>>
>>> TripleO / Kolla interactions were scheduled on Wednesday morning in
>>>
>>> the TripleO room but I'm fine if you want to move it (just let us
>>>
>>> know).
>>>
>>> On Monday afternoon, Deployment tools group (Kolla, Ansible, TripleO,
>>>
>>> Chef, Puppet, Helm, etc) was supposed to meet in the Packaging room
>>>
>>> and collaborate.
>>>
>>>
>>>
>>> All of this was scheduled a few days / weeks ago but we're happy to
>>>
>>> re-visit it. Please let us know though because it will confuse people
>>>
>>> otherwise.
>>>
>>>
>>>
>>> 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 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] [cinder] [ironic] [tripleo] PTG cross-platform meetup possibility

[Michał Jastrzębski]

Hey,

I know about wed meeting. This is when we wanted to discuss kolla-k8s and
tripleo shared resources,  whatever they might be.  I assumed Mon meeting
is different?

On Sep 8, 2017 6:22 PM, "Richard Wellum"  wrote:

> Emilien,
>
> Can you please update this on the schedule if it's not already? The link
> to the spreadsheet is in this thread.
>
> Michal didn't seem to know about this Wednesday meeting because he replied
> to my email for Monday, with a confirmation, But maybe I'm missing
> something. And we, kolla, all thought it was Monday, although we searched
> for the conversation today and couldn't find anything. So not sure everyone
> is synched up. Could just be me; it's been a long week.
>
> Cheers,
>
> Rich
>
> On Fri, Sep 8, 2017, 5:15 PM Vikram Hosakote (vhosakot) <
> vhosa...@cisco.com> wrote:
>
>> Cool, we’ll hold the room reservation in Durango on Monday 2-4 pm for the
>> cross-project
>>
>> meeting with the deployment tool groups (Kolla, Ansible, TripleO, Chef,
>> Puppet, Helm,
>>
>> etc).
>>
>>
>>
>> Regards,
>>
>> Vikram Hosakote
>>
>> IRC:  vhosakot
>>
>>
>>
>> *From: *Emilien Macchi 
>> *Reply-To: *"OpenStack Development Mailing List (not for usage
>> questions)" 
>> *Date: *Friday, September 8, 2017 at 4:04 PM
>> *To: *"OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> *Subject: *Re: [openstack-dev] [kolla] [cinder] [ironic] [tripleo] PTG
>> cross-platform meetup possibility
>>
>>
>>
>> On Fri, Sep 8, 2017 at 12:49 PM, Richard Wellum 
>> wrote:
>>
>> Triple-O team - can you please confirm the Monday slot, 2-4pm still works
>>
>> for you?
>>
>>
>>
>> TripleO / Kolla interactions were scheduled on Wednesday morning in
>>
>> the TripleO room but I'm fine if you want to move it (just let us
>>
>> know).
>>
>> On Monday afternoon, Deployment tools group (Kolla, Ansible, TripleO,
>>
>> Chef, Puppet, Helm, etc) was supposed to meet in the Packaging room
>>
>> and collaborate.
>>
>>
>>
>> All of this was scheduled a few days / weeks ago but we're happy to
>>
>> re-visit it. Please let us know though because it will confuse people
>>
>> otherwise.
>>
>>
>>
>> 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 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] [cinder] [ironic] [tripleo] PTG cross-platform meetup possibility

[Richard Wellum]

Emilien,

Can you please update this on the schedule if it's not already? The link to
the spreadsheet is in this thread.

Michal didn't seem to know about this Wednesday meeting because he replied
to my email for Monday, with a confirmation, But maybe I'm missing
something. And we, kolla, all thought it was Monday, although we searched
for the conversation today and couldn't find anything. So not sure everyone
is synched up. Could just be me; it's been a long week.

Cheers,

Rich

On Fri, Sep 8, 2017, 5:15 PM Vikram Hosakote (vhosakot) 
wrote:

> Cool, we’ll hold the room reservation in Durango on Monday 2-4 pm for the
> cross-project
>
> meeting with the deployment tool groups (Kolla, Ansible, TripleO, Chef,
> Puppet, Helm,
>
> etc).
>
>
>
> Regards,
>
> Vikram Hosakote
>
> IRC:  vhosakot
>
>
>
> *From: *Emilien Macchi 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Friday, September 8, 2017 at 4:04 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [kolla] [cinder] [ironic] [tripleo] PTG
> cross-platform meetup possibility
>
>
>
> On Fri, Sep 8, 2017 at 12:49 PM, Richard Wellum 
> wrote:
>
> Triple-O team - can you please confirm the Monday slot, 2-4pm still works
>
> for you?
>
>
>
> TripleO / Kolla interactions were scheduled on Wednesday morning in
>
> the TripleO room but I'm fine if you want to move it (just let us
>
> know).
>
> On Monday afternoon, Deployment tools group (Kolla, Ansible, TripleO,
>
> Chef, Puppet, Helm, etc) was supposed to meet in the Packaging room
>
> and collaborate.
>
>
>
> All of this was scheduled a few days / weeks ago but we're happy to
>
> re-visit it. Please let us know though because it will confuse people
>
> otherwise.
>
>
>
> 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 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] [devstack] SUSE jobs started failing on peakmem_tracker

[David Moreau Simard]

Hi,

I was trying to make sure the existing openSUSE jobs passed on Zuul v3
but even the regular v2 jobs are hitting a bug I filed here [1].
As far as I know, these jobs were passing until recently.

This is preventing us from sanity checking that everything works out
of the box for the suse devstack job for the v3 migration.
I've disabled this service through localconf in the v3 job for the
time being [2] to test further.

[1]: https://bugs.launchpad.net/devstack/+bug/1716066
[2]: https://review.openstack.org/#/c/502147/

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]

__
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] [cinder] [ironic] [tripleo] PTG cross-platform meetup possibility

[Vikram Hosakote (vhosakot)]

Cool, we’ll hold the room reservation in Durango on Monday 2-4 pm for the 
cross-project
meeting with the deployment tool groups (Kolla, Ansible, TripleO, Chef, Puppet, 
Helm,
etc).

Regards,
Vikram Hosakote
IRC:  vhosakot

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

Date: Friday, September 8, 2017 at 4:04 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla] [cinder] [ironic] [tripleo] PTG 
cross-platform meetup possibility

On Fri, Sep 8, 2017 at 12:49 PM, Richard Wellum 
> wrote:
Triple-O team - can you please confirm the Monday slot, 2-4pm still works
for you?

TripleO / Kolla interactions were scheduled on Wednesday morning in
the TripleO room but I'm fine if you want to move it (just let us
know).
On Monday afternoon, Deployment tools group (Kolla, Ansible, TripleO,
Chef, Puppet, Helm, etc) was supposed to meet in the Packaging room
and collaborate.

All of this was scheduled a few days / weeks ago but we're happy to
re-visit it. Please let us know though because it will confuse people
otherwise.

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 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] fluentd integration cleanup

[Lars Kellogg-Stedman]

[tl;dr] shardy, these are the fluentd changes we discussed.

The original fluentd integration in tripleo landed just before before
service_config_settings, so it used some janky changes in
common/services.yaml in order to aggregate configuration information from
other services in the service chain.

With the availability of service_config_settings this is no longer
necessary.  I've started the work to clean up the fluentd integration to
use the new mechanism.

The work is being tracked in https://bugs.launchpad.net/tripleo/+bug/1715187
and you can find all the changes at
https://review.openstack.org/#/q/topic:bug/1715187. There are changes to
tripleo-heat-templates and to puppet-tripleo.

Everything is currently marked [WIP]. While the changes Work For Me, I know
that there is ongoing work to support the Pike release and these changes in
particular will conflict with some work that jbadiapa is doing for
containerized fluentd in Pike.  I'd like to make sure that Pike has settled
before landing these.

-- 
Lars Kellogg-Stedman 
__
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] removing screen from devstack - RSN

[Eric Fried]

Oh, are we talking about the logs produced by CI jobs?  I thought we
were talking about on your local devstack itself.  Because there, I
don't think you shouldn't be seeing log files like this anymore.
Logging is done via systemd and can be viewed via journalctl [1].

The exceptions are things that run under apache, like horizon, keystone,
and placement - their log files can be found wherever apache is set up
to send 'em.  E.g. [2].

As far as the names go, I *think* we've done away with 'q' as the
neutron prefixy thing at this point.  On my (pike-ish) setup, the
devstack neutron API service is quite appropriately called
devstack@neutron-api.service.

[1] https://docs.openstack.org/devstack/latest/systemd#querying-logs
[2] http://paste.openstack.org/raw/620754/


On 09/08/2017 03:49 PM, Sean Dague wrote:
> I would love to. Those were mostly left because devstack-gate (and
> related tooling like elasticsearch) is not branch aware, so things get
> ugly on the conditionals for changing expected output files.
> 
> That might be a good popup infra topic at PTG.
> 
> On 09/08/2017 04:17 PM, John Villalovos wrote:
>> Does this mean we can now get more user friendly names for the log files?
>>
>> Currently I see names like:
>> screen-dstat.txt.gz
>> screen-etcd.txt.gz 
>> screen-g-api.txt.gz
>> screen-g-reg.txt.gz
>> screen-ir-api.txt.gz   
>> screen-ir-cond.txt.gz  
>> screen-keystone.txt.gz 
>> screen-n-api-meta.txt.gz   
>> screen-n-api.txt.gz
>> screen-n-cauth.txt.gz  
>> screen-n-cond.txt.gz   
>> screen-n-cpu.txt.gz
>> screen-n-novnc.txt.gz  
>> screen-n-sch.txt.gz
>> screen-peakmem_tracker.txt.gz  
>> screen-placement-api.txt.gz
>> screen-q-agt.txt.gz
>> screen-q-dhcp.txt.gz   
>> screen-q-l3.txt.gz 
>> screen-q-meta.txt.gz   
>> screen-q-metering.txt.gz   
>> screen-q-svc.txt.gz
>> screen-s-account.txt.gz
>> screen-s-container.txt.gz  
>> screen-s-object.txt.gz 
>> screen-s-proxy.txt.gz  
>>
>> People new to OpenStack don't really know that 'q' means neutron.
>>
>>
>>
>> On Thu, Sep 7, 2017 at 5:45 AM, Sean Dague > > wrote:
>>
>> On 08/31/2017 06:27 AM, Sean Dague wrote:
>> > The work that started last cycle to make devstack only have a single
>> > execution mode, that was the same between automated QA and local, is
>> > nearing it's completion.
>> >
>> > https://review.openstack.org/#/c/499186/
>>  is the patch that will remove
>> > screen from devstack (which was only left as a fall back for things 
>> like
>> > grenade during Pike). Tests are currently passing on all the gating 
>> jobs
>> > for it. And experimental looks mostly useful.
>> >
>> > The intent is to merge this in about a week (right before PTG). So, if
>> > you have a complicated devstack plugin you think might be affected by
>> > this (and were previously making jobs pretend to be grenade to keep
>> > screen running), now is the time to run tests against this patch and 
>> see
>> > where things stand.
>>
>> This patch is in the gate and now merging, and with it devstack now has
>> a single run mode, using systemd units, which is the same between test
>> and development.
>>
>> Thanks to everyone helping with the transition!
>>
>> -Sean
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>>
>>
>>
>>
>> __
>> OpenStack 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] removing screen from devstack - RSN

[Sean Dague]

I would love to. Those were mostly left because devstack-gate (and
related tooling like elasticsearch) is not branch aware, so things get
ugly on the conditionals for changing expected output files.

That might be a good popup infra topic at PTG.

On 09/08/2017 04:17 PM, John Villalovos wrote:
> Does this mean we can now get more user friendly names for the log files?
> 
> Currently I see names like:
> screen-dstat.txt.gz
> screen-etcd.txt.gz 
> screen-g-api.txt.gz
> screen-g-reg.txt.gz
> screen-ir-api.txt.gz   
> screen-ir-cond.txt.gz  
> screen-keystone.txt.gz 
> screen-n-api-meta.txt.gz   
> screen-n-api.txt.gz
> screen-n-cauth.txt.gz  
> screen-n-cond.txt.gz   
> screen-n-cpu.txt.gz
> screen-n-novnc.txt.gz  
> screen-n-sch.txt.gz
> screen-peakmem_tracker.txt.gz  
> screen-placement-api.txt.gz
> screen-q-agt.txt.gz
> screen-q-dhcp.txt.gz   
> screen-q-l3.txt.gz 
> screen-q-meta.txt.gz   
> screen-q-metering.txt.gz   
> screen-q-svc.txt.gz
> screen-s-account.txt.gz
> screen-s-container.txt.gz  
> screen-s-object.txt.gz 
> screen-s-proxy.txt.gz  
> 
> People new to OpenStack don't really know that 'q' means neutron.
> 
> 
> 
> On Thu, Sep 7, 2017 at 5:45 AM, Sean Dague  > wrote:
> 
> On 08/31/2017 06:27 AM, Sean Dague wrote:
> > The work that started last cycle to make devstack only have a single
> > execution mode, that was the same between automated QA and local, is
> > nearing it's completion.
> >
> > https://review.openstack.org/#/c/499186/
>  is the patch that will remove
> > screen from devstack (which was only left as a fall back for things like
> > grenade during Pike). Tests are currently passing on all the gating jobs
> > for it. And experimental looks mostly useful.
> >
> > The intent is to merge this in about a week (right before PTG). So, if
> > you have a complicated devstack plugin you think might be affected by
> > this (and were previously making jobs pretend to be grenade to keep
> > screen running), now is the time to run tests against this patch and see
> > where things stand.
> 
> This patch is in the gate and now merging, and with it devstack now has
> a single run mode, using systemd units, which is the same between test
> and development.
> 
> Thanks to everyone helping with the transition!
> 
> -Sean
> 
> --
> Sean Dague
> http://dague.net
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> 
> __
> OpenStack 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
> 


-- 
Sean Dague
http://dague.net

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

[openstack-dev] [cinder] Denver Team Dinner Planned ...

[Jay Bryant]

Team,

I have found a place that I hope we will all enjoy for dinner. The 
general consensus was to do Thursday night with a few exceptions.  So, I 
went with the majority and made reservations for Thursday night at 7 
pm.  Here are the details:


 * */Location:  Casey's Bistro and Pub - 7301 East 29th Avenue Denver,
   CO 80238 -- 720-974-7350/*

 * */Website: /**/http://coloradopubco.com/stapleton-caseys//*

The place is .9 miles from the convention center.  So, it should be 
walkable.


If you are planning to come but haven't yet put your name on the list in 
the etherpad [1] please do so by Wednesday so I can make sure we have an 
accurate number for the reservation.


Look forward to seeing you all next week!

Jay

[1] https://etherpad.openstack.org/p/cinder-ptg-queens


__
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] removing screen from devstack - RSN

[John Villalovos]

Does this mean we can now get more user friendly names for the log files?

Currently I see names like:
screen-dstat.txt.gz
screen-etcd.txt.gz
screen-g-api.txt.gz
screen-g-reg.txt.gz
screen-ir-api.txt.gz
screen-ir-cond.txt.gz
screen-keystone.txt.gz
screen-n-api-meta.txt.gz
screen-n-api.txt.gz
screen-n-cauth.txt.gz
screen-n-cond.txt.gz
screen-n-cpu.txt.gz
screen-n-novnc.txt.gz
screen-n-sch.txt.gz
screen-peakmem_tracker.txt.gz
screen-placement-api.txt.gz
screen-q-agt.txt.gz
screen-q-dhcp.txt.gz
screen-q-l3.txt.gz
screen-q-meta.txt.gz
screen-q-metering.txt.gz
screen-q-svc.txt.gz
screen-s-account.txt.gz
screen-s-container.txt.gz
screen-s-object.txt.gz
screen-s-proxy.txt.gz

People new to OpenStack don't really know that 'q' means neutron.



On Thu, Sep 7, 2017 at 5:45 AM, Sean Dague  wrote:

> On 08/31/2017 06:27 AM, Sean Dague wrote:
> > The work that started last cycle to make devstack only have a single
> > execution mode, that was the same between automated QA and local, is
> > nearing it's completion.
> >
> > https://review.openstack.org/#/c/499186/ is the patch that will remove
> > screen from devstack (which was only left as a fall back for things like
> > grenade during Pike). Tests are currently passing on all the gating jobs
> > for it. And experimental looks mostly useful.
> >
> > The intent is to merge this in about a week (right before PTG). So, if
> > you have a complicated devstack plugin you think might be affected by
> > this (and were previously making jobs pretend to be grenade to keep
> > screen running), now is the time to run tests against this patch and see
> > where things stand.
>
> This patch is in the gate and now merging, and with it devstack now has
> a single run mode, using systemd units, which is the same between test
> and development.
>
> Thanks to everyone helping with the transition!
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack 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] [cinder] [ironic] [tripleo] PTG cross-platform meetup possibility

[Emilien Macchi]

On Fri, Sep 8, 2017 at 12:49 PM, Richard Wellum  wrote:
> Triple-O team - can you please confirm the Monday slot, 2-4pm still works
> for you?

TripleO / Kolla interactions were scheduled on Wednesday morning in
the TripleO room but I'm fine if you want to move it (just let us
know).
On Monday afternoon, Deployment tools group (Kolla, Ansible, TripleO,
Chef, Puppet, Helm, etc) was supposed to meet in the Packaging room
and collaborate.

All of this was scheduled a few days / weeks ago but we're happy to
re-visit it. Please let us know though because it will confuse people
otherwise.

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

Re: [openstack-dev] [kolla] [cinder] [ironic] [tripleo] PTG cross-platform meetup possibility

[Richard Wellum]

No problem Michal.

Triple-O team - can you please confirm the Monday slot, 2-4pm still works
for you?

Thanks,

||Rich

On Fri, Sep 8, 2017 at 3:31 PM Michał Jastrzębski  wrote:

> Awesome!
>
> Thanks Rich and see you all in Denver!
>
> On 8 September 2017 at 12:19, Richard Wellum  wrote:
> > Room booked: 'Durango', 2-4pm for Kolla+Triple-O and 4-6 for
> > Kolla+Ironic+Cinder.
> >
> > Please see: https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms
> -
> > for more details.
> >
> > Thanks,
> >
> > ||Rich
> >
> >
> > On Thu, Sep 7, 2017 at 11:09 AM Vikram Hosakote (vhosakot)
> >  wrote:
> >>
> >> Sending the confirmed cross-project meets with the kolla community:
> >>
> >>
> >>
> >> Monday with Triple-O at 2 pm
> >>
> >> Monday with Cinder and Ironic at 4 pm
> >>
> >>
> >>
> >> Regards,
> >>
> >> Vikram Hosakote
> >>
> >> IRC:  vhosakot
> >>
> >>
> >>
> >> From: Jay S Bryant 
> >> Reply-To: "jsbry...@electronicjungle.net" <
> jsbry...@electronicjungle.net>,
> >> "OpenStack Development Mailing List (not for usage questions)"
> >> 
> >> Date: Thursday, August 31, 2017 at 1:43 PM
> >> To: "openstack-dev@lists.openstack.org"
> >> 
> >> Subject: Re: [openstack-dev] [kolla] [cinder] [ironic] PTG
> cross-platform
> >> meetup possibility
> >>
> >>
> >>
> >> Rich,
> >>
> >> I can make Monday at 4 pm work.  Conflicts with some Docs discussions
> but
> >> I can step out for a bit.
> >>
> >> Thanks!
> >>
> >> Jay
> >>
> >>
> >>
> >>
> >>
> >> On 8/31/2017 8:25 AM, Richard Wellum wrote:
> >>
> >> Hi,
> >>
> >>
> >>
> >> How does Monday at 4pm sound? Kolla already has a cross-platform
> >> discussion with Triple-O at 2pm, so this would dovetail nicely.
> >>
> >>
> >>
> >> Thanks,
> >>
> >>
> >> ||Rich
> >>
> >>
> >>
> >> On Wed, Aug 30, 2017 at 2:48 PM Ivan Kolodyazhny 
> wrote:
> >>
> >> Hi team,
> >>
> >>
> >>
> >> I'm interested in cinder containerization too. It would be great if we
> can
> >> schedule our meetup after 3pm or even 4pm, It will increase my chances
> to
> >> attend it.
> >>
> >>
> >>
> >> Thanks in advance.
> >>
> >>
> >> Regards,
> >> Ivan Kolodyazhny,
> >> http://blog.e0ne.info/
> >>
> >>
> >>
> >> On Wed, Aug 30, 2017 at 4:23 PM, Dmitry Tantsur 
> >> wrote:
> >>
> >> Hi!
> >>
> >> I'm all for it. Monday sounds okay to me, though I'll have to manage
> some
> >> conflicts, of course.
> >>
> >>
> >>
> >> On 08/29/2017 05:56 PM, Richard Wellum wrote:
> >>
> >> Hi Folks,
> >>
> >> Would there be some interest from Cinder and Ironic (and others of
> course)
> >> team members to have a quick session at the PTG with the Kolla team on
> the
> >> latest developments in Kolla (like the new kolla-ansible devmode for
> >> example)?
> >>
> >> Also it would give the Kolla team an opportunity to hear about your
> teams
> >> interest and experiences in containerization and what you need from
> Kolla
> >> going forward.
> >>
> >> I'm thinking an hour or two on Monday afternoon, the first day of the
> PTG?
> >>
> >> Thanks,
> >>
> >> ||Rich
> >>
> >>
> __
> >> 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:
> 

Re: [openstack-dev] [kolla] [cinder] [ironic] PTG cross-platform meetup possibility

[Michał Jastrzębski]

Awesome!

Thanks Rich and see you all in Denver!

On 8 September 2017 at 12:19, Richard Wellum  wrote:
> Room booked: 'Durango', 2-4pm for Kolla+Triple-O and 4-6 for
> Kolla+Ironic+Cinder.
>
> Please see: https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms -
> for more details.
>
> Thanks,
>
> ||Rich
>
>
> On Thu, Sep 7, 2017 at 11:09 AM Vikram Hosakote (vhosakot)
>  wrote:
>>
>> Sending the confirmed cross-project meets with the kolla community:
>>
>>
>>
>> Monday with Triple-O at 2 pm
>>
>> Monday with Cinder and Ironic at 4 pm
>>
>>
>>
>> Regards,
>>
>> Vikram Hosakote
>>
>> IRC:  vhosakot
>>
>>
>>
>> From: Jay S Bryant 
>> Reply-To: "jsbry...@electronicjungle.net" ,
>> "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Thursday, August 31, 2017 at 1:43 PM
>> To: "openstack-dev@lists.openstack.org"
>> 
>> Subject: Re: [openstack-dev] [kolla] [cinder] [ironic] PTG cross-platform
>> meetup possibility
>>
>>
>>
>> Rich,
>>
>> I can make Monday at 4 pm work.  Conflicts with some Docs discussions but
>> I can step out for a bit.
>>
>> Thanks!
>>
>> Jay
>>
>>
>>
>>
>>
>> On 8/31/2017 8:25 AM, Richard Wellum wrote:
>>
>> Hi,
>>
>>
>>
>> How does Monday at 4pm sound? Kolla already has a cross-platform
>> discussion with Triple-O at 2pm, so this would dovetail nicely.
>>
>>
>>
>> Thanks,
>>
>>
>> ||Rich
>>
>>
>>
>> On Wed, Aug 30, 2017 at 2:48 PM Ivan Kolodyazhny  wrote:
>>
>> Hi team,
>>
>>
>>
>> I'm interested in cinder containerization too. It would be great if we can
>> schedule our meetup after 3pm or even 4pm, It will increase my chances to
>> attend it.
>>
>>
>>
>> Thanks in advance.
>>
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>>
>>
>> On Wed, Aug 30, 2017 at 4:23 PM, Dmitry Tantsur 
>> wrote:
>>
>> Hi!
>>
>> I'm all for it. Monday sounds okay to me, though I'll have to manage some
>> conflicts, of course.
>>
>>
>>
>> On 08/29/2017 05:56 PM, Richard Wellum wrote:
>>
>> Hi Folks,
>>
>> Would there be some interest from Cinder and Ironic (and others of course)
>> team members to have a quick session at the PTG with the Kolla team on the
>> latest developments in Kolla (like the new kolla-ansible devmode for
>> example)?
>>
>> Also it would give the Kolla team an opportunity to hear about your teams
>> interest and experiences in containerization and what you need from Kolla
>> going forward.
>>
>> I'm thinking an hour or two on Monday afternoon, the first day of the PTG?
>>
>> Thanks,
>>
>> ||Rich
>>
>> __
>> 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
>

__
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] [cinder] [ironic] PTG cross-platform meetup possibility

[Richard Wellum]

Room booked: 'Durango', 2-4pm for Kolla+Triple-O and 4-6 for
Kolla+Ironic+Cinder.

Please see: https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms -
for more details.

Thanks,

||Rich

On Thu, Sep 7, 2017 at 11:09 AM Vikram Hosakote (vhosakot) <
vhosa...@cisco.com> wrote:

> Sending the confirmed cross-project meets with the kolla community:
>
>
>
> Monday with Triple-O at 2 pm
>
> Monday with Cinder and Ironic at 4 pm
>
>
>
> Regards,
>
> Vikram Hosakote
>
> IRC:  vhosakot
>
>
>
> *From: *Jay S Bryant 
> *Reply-To: *"jsbry...@electronicjungle.net" ,
> "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Date: *Thursday, August 31, 2017 at 1:43 PM
> *To: *"openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [kolla] [cinder] [ironic] PTG
> cross-platform meetup possibility
>
>
>
> Rich,
>
> I can make Monday at 4 pm work.  Conflicts with some Docs discussions but
> I can step out for a bit.
>
> Thanks!
>
> Jay
>
>
>
>
>
> On 8/31/2017 8:25 AM, Richard Wellum wrote:
>
> Hi,
>
>
>
> How does Monday at 4pm sound? Kolla already has a cross-platform
> discussion with Triple-O at 2pm, so this would dovetail nicely.
>
>
>
> Thanks,
>
>
> ||Rich
>
>
>
> On Wed, Aug 30, 2017 at 2:48 PM Ivan Kolodyazhny  wrote:
>
> Hi team,
>
>
>
> I'm interested in cinder containerization too. It would be great if we can
> schedule our meetup after 3pm or even 4pm, It will increase my chances to
> attend it.
>
>
>
> Thanks in advance.
>
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
>
>
> On Wed, Aug 30, 2017 at 4:23 PM, Dmitry Tantsur 
> wrote:
>
> Hi!
>
> I'm all for it. Monday sounds okay to me, though I'll have to manage some
> conflicts, of course.
>
>
>
> On 08/29/2017 05:56 PM, Richard Wellum wrote:
>
> Hi Folks,
>
> Would there be some interest from Cinder and Ironic (and others of course)
> team members to have a quick session at the PTG with the Kolla team on the
> latest developments in Kolla (like the new kolla-ansible devmode for
> example)?
>
> Also it would give the Kolla team an opportunity to hear about your teams
> interest and experiences in containerization and what you need from Kolla
> going forward.
>
> I'm thinking an hour or two on Monday afternoon, the first day of the PTG?
>
> Thanks,
>
> ||Rich
>
> __
> 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] [neutron] PTG cross-platform meetup possibility

[Richard Wellum]

Hi,

I have booked the room 'Vail', Tuesday from 2pm for these discussions.
Please see: https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms for
more details.

Thanks,

||Rich

On Thu, Sep 7, 2017 at 12:15 PM  wrote:

> Vikram Hosakote (vhosakot), 2017-09-07 15:38:
> > Would there be any interest in meeting with the Kolla team at the PTG
> > to discuss neutron’s
> > integration with containers and Kubernetes especially about the new
> > networking
> > technologies like VPP, fd.io, OpenDaylight, OVS-DPDK, OVN, service
> > chaining (SFC), etc?
> >
> > If yes, would Tuesday 2 pm work?  I’m thinking about an hour or two
> > for the session.
>
> If this happens I'm interested to follow.
>
> -Thomas
>
>
>
> _
>
> 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
>
__
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] [PTG][QA] QA PT Agenda & Schedule

[Andrea Frittoli]

Dear all,

attached the agenda / schedule [0][1] for the work of the QA team in Denver.

If there is a session you would like to join but you're not able to because
of a conflict, please do let me know, I'll do my best to accommodate
everyone needs.

The actual schedule will be defined in real time via the PTG bot so keep an
eye on it for the latest  news about what's going on in the QA room;
however we'll try to stick as much as possible to the proposed schedule.

See you in Denver and on IRC

Andrea Frittoli (andreaf)

[0] https://ethercalc.openstack.org/Queens-PTG-QA-Planning
[1] https://etherpad.openstack.org/p/qa-queens-ptg
__
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 Developer Mailing List Digest Sept 2-8

[Kendall Nelson]

Hello All!

HTML Version:
https://www.openstack.org/blog/2017/09/openstack-developer-mailing-list-digest-september-2-8/

Successbot Says!

   -

   fungi: Octavia has migrated from Launchpad to StoryBoard [1]
   -

   sc’ : OpenStack is now on the Chef Supermarket!
   https://supermarket.chef.io/users/openstack [2]


Summaries:

   -

   Notifications Update Week 36 [3]


Updates:

   -

   Summit Free Passes [4]
   -

  People that have attended the Atlanta PTG or will attend the Denver
  PTG will receive 100% discount passes for the Sydney Summit
  -

  They must be used by October 27th
  -

   Early Bird Deadline for Summit Passes is September 8th [5]
   -

  Expires at 6:59 UTC
  -

  Discount Saves you 50%
  -

   Libraries Published to pypi with YYY.X.Z versions [6]
   -

  Moving forward with deleting the libraries from Pypi
  -

  Removing these libraries:
  -

 python-congressclient 2015.1.0
 -

 python-congressclient 2015.1.0rc1
 -

 python-designateclient 2013.1.a8.g3a2a320
 -

 networking-hyperv 2015.1.0
 -

  Still waiting on approval from PTL’s about the others
  -

 mistral-extra
 -

 networking-odl
 -

 murano-dashboard
 -

 networking-midonet
 -

 sahara-image-elements
 -

 freezer-api
 -

 murano-agent
 -

 mistral-dashboard
 -

 Sahara-dashboard
 -

   Unified Limits work stalled [7]
   -

  Need for new leadership
  -

  Keystone merged a spec [8]
  -

   Should we continue providing FQDN’s for instance hostnames?[9]
   -

  Nova network has deprecated the option that the domain in the FQDN is
  based on
  -

  Working on getting the domain info from Neutron instead of Nova, but
  this may not be the right direction
  -

  Do we want to use a FQDN as the hostnames inside the guest?
  -

 The Infra servers are built with the FQDN as the instance name
 itself
 -

   Cinder V1 API Removal[10]
   -

  Patch here[11]
  -

   Removing Screen from Devstack- RSN
   -

  It’s been merged
  -

  A few people are upset that they don’t have screen for debugging
  anymore
  -

  Systemd docs are being updated to include pdb path so as to be able
  to debug in a similar way to how people used screen [12] [13] [14]


PTG Planning

   -

   Video Interviews [15]


-Kendall (diablo_rojo)

[1]
http://eavesdrop.openstack.org/irclogs/%23storyboard/%23storyboard.2017-09-06.log.html#t2017-09-06T22:03:06

[2]
http://eavesdrop.openstack.org/irclogs/%23openstack-chef/%23openstack-chef.2017-09-08.log.html#t2017-09-08T13:48:14

[3]
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121769.html

[4]
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121843.html
#Free

[5]
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121847.html

[6]
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121705.html
#

[7]
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121944.html

[8]
https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/unified-limits.html

[9]
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121762.html

[10]
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121956.html

[11] https://review.openstack.org/#/c/499342/

[12] https://review.openstack.org/#/c/501834
/

[13] https://pypi.python.org/pypi/remote-pdb

[14] https://review.openstack.org/#/c/501870/

[15]
http://lists.openstack.org/pipermail/openstack-dev/2017-September/121901.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [sahara] [ptg] Sahara dinner in Denver

[Evgeny Sikachov]

Yes, it’s really cool

On Sep 8, 2017, 9:04 PM +0400, Telles Nobrega , wrote:
> That is a great idea Jeremy. Thanks for putting it together.
> > On Fri, 8 Sep 2017 at 13:46 Jeremy Freudberg  
> > wrote:
> > > Hey all,
> > >
> > > Sahara team: I will attempt to organize a team dinner in Denver. Not
> > > sure when (Tuesday, Wednesday, Thursday night) or where (the immediate
> > > area is notoriously spread-out and not pedestrian-friendly) but please
> > > let me know if you have any thoughts. You can let me know on
> > > email/IRC/etherpad.
> > >
> > > Others: Being an active contributor to Sahara is not a requirement for
> > > having dinner with the Sahara team! If you're interested in joining
> > > us, please let us know on email/IRC/etherpad.
> > >
> > > Best,
> > > Jeremy
> --
> TELLES NOBREGA
> SOFTWARE ENGINEER
> Red Hat I
> tenob...@redhat.com
> TRIED. TESTED. TRUSTED.
__
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] [ptg] Sahara dinner in Denver

[Telles Nobrega]

That is a great idea Jeremy. Thanks for putting it together.
On Fri, 8 Sep 2017 at 13:46 Jeremy Freudberg 
wrote:

> Hey all,
>
> Sahara team: I will attempt to organize a team dinner in Denver. Not
> sure when (Tuesday, Wednesday, Thursday night) or where (the immediate
> area is notoriously spread-out and not pedestrian-friendly) but please
> let me know if you have any thoughts. You can let me know on
> email/IRC/etherpad.
>
> Others: Being an active contributor to Sahara is not a requirement for
> having dinner with the Sahara team! If you're interested in joining
> us, please let us know on email/IRC/etherpad.
>
> Best,
> Jeremy
>
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat I 

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
__
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] [ptg] Sahara dinner in Denver

[Jeremy Freudberg]

Hey all,

Sahara team: I will attempt to organize a team dinner in Denver. Not
sure when (Tuesday, Wednesday, Thursday night) or where (the immediate
area is notoriously spread-out and not pedestrian-friendly) but please
let me know if you have any thoughts. You can let me know on
email/IRC/etherpad.

Others: Being an active contributor to Sahara is not a requirement for
having dinner with the Sahara team! If you're interested in joining
us, please let us know on email/IRC/etherpad.

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

[openstack-dev] Reminder: Early Bird Deadline - OpenStack Summit Sydney

[Erin Disney]

Hi everyone,
 
Friendly reminder that TODAY, September 8, at 11:59pm Pacific Time (September 9 
at 6:59 UTC) is the deadline to purchase passes for the OpenStack Summit in 
Sydney at the early bird price, which saves you 50% off full price passes.
 
Register NOW  before the 
prices increase! 

Cheers, 
Erin

Erin Disney
OpenStack Marketing
e...@openstack.org 
__
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] [octavia][l7policy] Is redirect to pool supported?

[Michael Johnson]

Yes, you can redirect to a pool.  Multiple pools can be created under
the load balancer object and then referenced from the L7 Policy.

This example shows a load balancer with a redirect to pool L7 policy:
https://docs.openstack.org/octavia/latest/user/guides/l7-cookbook.html#send-requests-starting-with-js-or-images-to-static-pool
Note that the first step in the example is to create the pool on the
load balancer.

Michael (johnsom)

On Fri, Sep 8, 2017 at 12:09 AM,   wrote:
> Sorry, I forgot the link to this documentation:
> https://docs.openstack.org/octavia/latest/user/guides/l7-cookbook.html
>
>
>
> From: mihaela.ba...@orange.com [mailto:mihaela.ba...@orange.com]
> Sent: Friday, September 08, 2017 10:07 AM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [octavia][l7policy] Is redirect to pool supported?
>
>
>
> Hello,
>
>
>
> Is redirect_to_pool policy currently supported with Octavia? Since a
> listener can only have one pool (the default pool) I cannot see how this can
> be configured. However, this documentation details a lot of scenarios. I am
> testing Octavia Ocata version.
>
>
>
> Thank you,
>
> Mihaela Balas
>
> _
>
>
>
> 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.
>
> _
>
> 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
>

__
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] [all] [glance] Glance at the Denver PTG

[Brian Rosmaita]

The Glance design discussions on Wednesday and Thursday will roughly
adhere to the schedule on this etherpad:
https://etherpad.openstack.org/p/glance-queens-ptg

There's a place on the etherpad for Monday and Tuesday events; any
other teams having discussions that would benefit from having a Glance
representative there, feel free to put info on the etherpad.

The etherpad linked to above has links to etherpads for each session.
If you cannot attend the PTG but are interested in a session, please
put questions/comments on the appropriate etherpad.  We won't be
livecasting the sessions, but we will have IRC open to
#openstack-glance and #openstack-ptg, and we'll be taking live notes
on each session's etherpad.

Finally, we're aiming to have a Glance team dinner at 18:30 Denver
time on Tuesday (location TBA; will be posted on the etherpad linked
to above).  If you're interested in attending, please put your
name/irc nick on the etherpad so we can get a count.  Having
contributed to the Pike release of Glance is *not* a requirement for
having dinner with the Glance team! If you're interested in Glance, or
just want to meet the culprits responsible, feel free to join us.

Looking forward to a productive PTG!

brian

__
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][oslo.db] db retry madness

[Michael Bayer]

On Fri, Sep 8, 2017 at 8:53 AM, Kevin Benton  wrote:
> Thanks for asking this. It's good to get this documented on the mailing list
> since most of it is spread across bug reports and commits over the last
> couple of years.
>
>>1. since the retry_if_session_inactive decorator assumes functions that
>> receive a "context", what does it mean that networking_odl uses functions
>> that receive a "session" and not a "context" ?   Should networking_odl be
>> modified such that it accepts the same "context" that Neutron passes around?
>>
>>2. Alternatively, should the retry_if_session_inactive decorator be
>> modified (or a new decorator added) that provides the identical behavior for
>> functions that receive a "session" argument rather than a "context" argument
>> ?  (or should this be done anyway even if networking_odl's pattern is
>> legacy?)
>
> So it really depends on how those particular functions are being called. For
> example, it seems like this function in the review is always going to be
> called within an active session:
> https://review.openstack.org/#/c/500584/3/networking_odl/db/db.py@113  If
> that's the case then the decorator is never going to trigger a retry since
> is_active will be True.

>
> Since the goal of that patch is to deal with deadlocks, the retry can't
> happen down at that level, it will need to be somewhere further up the call
> stack since the deadlock will put the session in a rollback state.


OK when I was talking to Michel about this, I first mentioned that to
get retry within this in-a-transaction block would require adding a
savepoint to the mix, but he seemed to indicate that the method can
also run by itself, but since there's no session.begin() there then
that matches with my initial impression that the retry has to be at
the level which the transaction starts, and that's not here.



>
> For the functions being called outside of an active session, they should
> switch to accepting a context to handle the enginefacade switch.
>
>>  3a.  Is this a temporary measure to work around legacy patterns?
>
> Yes. When that went in we had very little adoption of the enginefacade. Even
> now we haven't fully completed the transition so checking for is_active
> covers the old code paths.


OK, so this is where they are still calling session.begin()
themselves.Are all these session.begin() calls in projects under
the "openstack" umbrella so I can use codesearch ?



>
> As we continue migrating to the enginefacade, the cases where you can get a
> reference to a session that actually has 'is_active==False' are going to
> keep dwindling. Once we complete the switch and remove the legacy session
> constructor, the decorator will just be adjusted to check if there is a
> session attached to the context to determine if retries are safe since
> is_active will always be True.

neat

>
>> 3b.  If 3a., is the pattern in use by networking_odl, receiving a
>> "session" and not "context", the specific legacy pattern in question?
>
> If those functions are called outside of an active session, then yes. Based
> on the session.begin() call without substransactions=True, I'm guessing
> that's the case for at least some of them:
> https://review.openstack.org/#/c/500584/3/networking_odl/db/db.py@85

Is there guidance written down somewhere I can point plugin teams towards ?


>
>>3c.  if 3a and 3b, are we expecting all the various plugins to start using
>> "context" at some point ?  (and when they come to me with breakage, I can
>> push them in that direction?)
>
> Yeah, for any functions that expect to start their own transaction they
> should altered to accept contexts and use the reader/writer context
> managers. If it's a function that is called from within an ongoing
> transaction, it can obviously still accept a session argument but the
> 'retry_if_session_inactive' decorator would obviously be irrelevant in that
> scenario since the session would always be active.
>
>> 4a.  Is it strictly that simple mutable lists and dicts of simple types
>> (ints, strings, etc.) are preserved across retries, assuming the receiving
>> functions might be modifying them?
>
> Yes, this was to deal with functions that would mutate collections passed
> in. In particular, we have functions that alter the parsed API request as
> they process them. If they hit a deadlock on commit and we retry at that
> point the API request would be mangled without the copy. (e.g.
> https://bugs.launchpad.net/neutron/+bug/1584920)
>
>>4b. Does this deepcopy() approach have any support for functions that are
>> being passed not just simple structures but ORM-mapped objects?   Was this
>> use case considered?
>
> No, it doesn't support ORM objects. Given that the target use case of the
> retry decorator was for functions not in an ongoing session, we didn't have
> a pattern to support in the main tree where an ORM object would be passed as
> an argument to the function that needed to be protected.

right, 

Re: [openstack-dev] [panko][ceilometer][keystone] Support X-Is-Admin-Project

[Innus, Martins]

Gord,

Thanks for the reply.

On Sep 7, 2017, at 4:15 PM, gordon chung > 
wrote:



On 2017-09-07 02:15 PM, Innus, Martins wrote:
The fix seems to be something like the attached patch and setting the 
appropriate configs in keystone.conf.


One curious thing is that with the default keystone config, requests from all 
projects have "X-Is-Admin-Project: True”

If I set admin_project_domain_name and admin_project_name , only then do the 
non admin projects have the header set to False.

apologies, do you have more details on what 'X-Is-Admin-Project' is? i'm
not familiar with this header.


As far as I can tell its meant for designating an overall cloud admin account. 
Reference to creation of the keystone config options:

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

Where the HEAT team seems to have used it for the same purpose, but by making 
changes in the policy.json:

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

But in my limited understating of how Panko works, using the header seems to be 
the easiest way to get this functionality:

https://github.com/openstack/keystonemiddleware/commit/0562670d4e56c257aec8db5a2bb651b5e59fddb2


currently, the behaviour is that:
- a member of a project can only see its own events
- an admin of a project can see all the events of a project (and any
events without any project associated with it)

if this is the way of denoting a user is a 'super-admin' that has access
to all events, i'm ok with it.


Yeah, thats what I’m going for, but as I said, I’ve barely stared to scratch 
the surface of OpenStack, so there way be a better way of doing this.

Thanks

Martins

__
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] [notification] cleaning up networking related notifications

[Matt Riedemann]

On 9/8/2017 5:52 AM, Balazs Gibizer wrote:
The addFixedIp REST API was deprecated in Pike [1] (in microversion 
2.44). As a result the legacy create_ip.start and create_ip.end 
notifications will not be emitted after microversion 2.44. We had a 
TODO[2] to transform this notification to the versioned format but now 
that seems a bit pointless. Also I've just found out that the existing 
POST os-interface REST API call does not emit any notification.


I think it would make sense not to transform the legacy notification in 
a deprecated code path but instead emit a new instance.interface_attach 
and instance.interface_detach notifications from the POST os-interface 
REST API code path, preferably from compute.manager.attach_interface().

Do you agree?


Yeah this makes sense to not transform the legacy deprecated paths but 
add something for attach/detach.




We also have TODOs about transforming floating_ip related 
notifications[2], e.g. network.floating_ip.allocate emitted from [3]. As 
far as I understand these notifications are only emitted from an already 
deprecated code path. Is it OK to remove them from our TODO list?


Yeah these are all deprecated so we don't need to transform them.

The allocate and deallocate floating IP paths are deprecated after 2.35:

https://github.com/openstack/nova/blob/fbe6f77bc1cb41f5d6cfc24ece54d3413f997aab/nova/api/openstack/compute/floating_ips.py#L142

https://github.com/openstack/nova/blob/fbe6f77bc1cb41f5d6cfc24ece54d3413f997aab/nova/api/openstack/compute/floating_ips.py#L173

And associate/disassociate are deprecated after 2.43:

https://github.com/openstack/nova/blob/fbe6f77bc1cb41f5d6cfc24ece54d3413f997aab/nova/api/openstack/compute/floating_ips.py#L213

https://github.com/openstack/nova/blob/fbe6f77bc1cb41f5d6cfc24ece54d3413f997aab/nova/api/openstack/compute/floating_ips.py#L294

--

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] [swift] radosgw multi tenancy support with newton

[Kim-Norman Sahm]

Hi,

does swift (radosgw on ceph jewel) multi tenancy working with openstack newton?
http://docs.ceph.com/docs/jewel/radosgw/keystone/

I've tried to integrate ceph-radosgw as swift service in openstack newton with 
keystone v3 and the authentication is working but all buckets are created in 
the same ceph-tenant (namespace).
if user A is creating a bucket "test" its all fine.
if user B is creating a bucket "test" swift get an error: bucket already exists.

Does anybody know the problem?

regards Kim


Kim-Norman Sahm
Cloud & Infrastructure(OCI)

noris network AG
Thomas-Mann-Straße 16-20
90471 Nürnberg
Deutschland

Tel +49 911 9352 1433
Fax +49 911 9352 100

kim-norman.s...@noris.de

https://www.noris.de - Mehr Leistung als Standard
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689










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

Re: [openstack-dev] [all] [oslo] schedule for Denver PTG is ready !

[Lance Bragstad]

The schedules for keystone shifted a bit yesterday to accommodate some
of the developments with the Baremetal/VM SIG schedule [0], making
Monday pretty chaotic. Would it be possible to move the scope-in-policy
and policy-deprecation sessions to Tuesday instead? I should be able to
shuffle things around in the morning, pending the Application
Credentials discussion.


[0] https://etherpad.openstack.org/p/queens-PTG-vmbm

On 09/05/2017 09:15 PM, Lance Bragstad wrote:
> Thanks! That should work. We have a couple things set up with the
> baremetal/VM SIG [0] during that time, but I don't think there is a
> set schedule for that SIG anyway. We should be able to go through some
> of those topics on Tuesday if we don't get to them on Monday.
>
> [0] https://etherpad.openstack.org/p/keystone-queens-ptg
>
> On Tue, Sep 5, 2017 at 7:25 AM, ChangBo Guo  > wrote:
>
> Lance,  I just update the schedule in [1] and add your new
> proposal topic in the schedule, kindly let me know when you're
> available, then we can rearrange your topics if you still have
> conflicts :-)
>
> [1] https://etherpad.openstack.org/p/oslo-ptg-queens
> 
>
> 2017-09-02 6:16 GMT+08:00 Lance Bragstad  >:
>
> Thanks for the schedule! I should be somewhat available Monday
> afternoon for the policy deprecation discussion. The only
> conflict that might come up for me is with the Baremetal/VM
> group [0]. Keystone has a few topics to iron out there, but
> I'm not exactly sure when that group plans to talk about those
> things. Also, I proposed another oslo spec detailing some
> additional policy work [1]. Let me know if you have thoughts,
> or would like to discuss it in Denver.
>
> [0] https://etherpad.openstack.org/p/keystone-queens-ptg
> 
> [1] https://review.openstack.org/#/c/500207/
> 
>
>
> On 08/28/2017 09:44 PM, ChangBo Guo wrote:
>> sure, will adjust the schedule
>>
>> 2017-08-29 2:24 GMT+08:00 Doug Hellmann
>> >:
>>
>> Excerpts from ChangBo Guo's message of 2017-08-28
>> 23:14:05 +0800:
>> > Please check  for the draft in [1], we can adjust if you have 
>> conflicts
>> > with other discussions.
>> >
>> > We have specific cross projects coding event  in the
>> Tuesday afternoon, for
>> > more details please
>> > check [2] and [3],  please join us if you're free from
>> 1:00 PM to 3: PM on
>> > Tuesday.
>> >
>> > [1] https://etherpad.openstack.org/p/oslo-ptg-queens
>> 
>> > [2]
>> >
>> 
>> http://lists.openstack.org/pipermail/openstack-dev/2017-August/121345.html
>> 
>> 
>> > [3] https://etherpad.openstack.org/p/oslo-queens-tasks
>> 
>> >
>>
>> I think we can drop the discussion of retiring oslosphinx
>> from the
>> schedule. We had no objections, and the way forward is
>> clear (see the
>> other thread [4] for details).
>>
>> Doug
>>
>> [4]
>> 
>> http://lists.openstack.org/pipermail/openstack-dev/2017-August/121564.html
>> 
>> 
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>>
>>
>>
>>
>> -- 
>> ChangBo Guo(gcb)
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 

[openstack-dev] [glance] priorities for the coming week (09/08-09/14)

[Brian Rosmaita]

Hello Glancers,

1. No meeting on Sept 14 due to PTG.

2. The PTG schedule for Glance is available.  There are etherpads
associated with each session.  If you cannot attend the PTG but are
interested in a session, please put questions/comments on the
appropriate etherpad.  We won't be livecasting the sessions, but we
will have IRC open to  #openstack-glance and #openstack-ptg, and we'll
be taking notes on the session etherpad
- https://etherpad.openstack.org/p/glance-queens-ptg

3. We have bugs targeted to Q-1, so you can't go wrong this week by
reviewing any patches associated with them:
- https://launchpad.net/glance/+milestone/queens-1
- also https://review.openstack.org/#/c/493654/ and
https://review.openstack.org/#/c/492651/

4. We'll be triaging and prioritizing bugs on Thursday (22:30-23:30
UTC) and having a bugfix session Friday, Sept 15 (15:00-18:00 UTC).
Feel free to join in!

Have a good week, everyone!

brian

__
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][oslo.db] db retry madness

[Kevin Benton]

Thanks for asking this. It's good to get this documented on the mailing
list since most of it is spread across bug reports and commits over the
last couple of years.

>1. since the retry_if_session_inactive decorator assumes functions that
receive a "context", what does it mean that networking_odl uses functions
that receive a "session" and not a "context" ?   Should networking_odl be
modified such that it accepts the same "context" that Neutron passes around?
>
>2. Alternatively, should the retry_if_session_inactive decorator be modified
(or a new decorator added) that provides the identical behavior for
functions that receive a "session" argument rather than a "context"
argument ?  (or should this be done anyway even if networking_odl's pattern
is legacy?)

So it really depends on how those particular functions are being called. For
example, it seems like this function in the review is always going to be
called within an active session:
https://review.openstack.org/#/c/500584/3/networking_odl/db/db.py@113  If
that's the case then the decorator is never going to trigger a retry since
is_active will be True.

Since the goal of that patch is to deal with deadlocks, the retry can't
happen down at that level, it will need to be somewhere further up the call
stack since the deadlock will put the session in a rollback state.

For the functions being called outside of an active session, they should
switch to accepting a context to handle the enginefacade switch.

>  3a.  Is this a temporary measure to work around legacy patterns?

Yes. When that went in we had very little adoption of the enginefacade.
Even now we haven't fully completed the transition so checking for
is_active covers the old code paths.

As we continue migrating to the enginefacade, the cases where you can get a
reference to a session that actually has 'is_active==False' are going to
keep dwindling. Once we complete the switch and remove the legacy session
constructor, the decorator will just be adjusted to check if there is a
session attached to the context to determine if retries are safe since
is_active will always be True.

> 3b.  If 3a., is the pattern in use by networking_odl, receiving a "session"
and not "context", the specific legacy pattern in question?

If those functions are called outside of an active session, then yes. Based
on the session.begin() call without substransactions=True, I'm guessing
that's the case for at least some of them:
https://review.openstack.org/#/c/500584/3/networking_odl/db/db.py@85

>3c.  if 3a and 3b, are we expecting all the various plugins to start using
"context" at some point ?  (and when they come to me with breakage, I can
push them in that direction?)

Yeah, for any functions that expect to start their own transaction they
should altered to accept contexts and use the reader/writer context
managers. If it's a function that is called from within an ongoing
transaction, it can obviously still accept a session argument but the
'retry_if_session_inactive' decorator would obviously be irrelevant in that
scenario since the session would always be active.

> 4a.  Is it strictly that simple mutable lists and dicts of simple types
(ints, strings, etc.) are preserved across retries, assuming the receiving
functions might be modifying them?

Yes, this was to deal with functions that would mutate collections passed
in. In particular, we have functions that alter the parsed API request as
they process them. If they hit a deadlock on commit and we retry at that
point the API request would be mangled without the copy. (e.g.
https://bugs.launchpad.net/neutron/+bug/1584920)

>4b. Does this deepcopy() approach have any support for functions that are
being passed not just simple structures but ORM-mapped objects?   Was this
use case considered?

No, it doesn't support ORM objects. Given that the target use case of the
retry decorator was for functions not in an ongoing session, we didn't have
a pattern to support in the main tree where an ORM object would be passed
as an argument to the function that needed to be protected.

>4c. Does Neutron's model base have any support for deepcopy()?  I notice
that the base classes in model_base do **not** seem to have a __deepcopy__
present.  This would mean that this deepcopy() will definitely break any
ORM mapped objects because you need to use an approach like what Nova uses
for copy(): https://github.com/openstack/nova/blob/master/nova/db/
sqlalchemy/models.py#L46 . This would be why the developer's objects are
all getting kicked
out of the session.   (this is the "is this a bug?" part)

That's definitely why the objects are being kicked out of the session. I'm
not sure if it makes sense to attempt to support copying an ORM object when
the decorator is meant for functions starting a completely new session. If
there is a use case I'm missing that we do want to support, it probably
makes more sense to use a different decorator than to adjust the existing
one.

>4d. How frequent 

Re: [openstack-dev] [openstack-ansible][tempest] "Ensure tempest image" failing

[Markos Chandras]

Hi Lawrence,

On 08/09/17 10:57, Lawrence J. Albinson wrote:
> Dear Colleagues,
> 
> I have just noticed that the short-form tempest run at the end of an
> openstack-ansible installation is failing with the following error:
> [...]
> \"/usr/local/lib/python2.7/dist-packages/shade/openstackcloud.py\", line
> 403, in _get_versioned_client\n    shade_logger=self.log)\n  File
> \"/usr/local/lib/python2.7/dist-packages/shade/_adapter.py\", line 87,
> in __init__\n    super(ShadeAdapter, self).__init__(*args, **kwargs)\n 
> File \"/usr/local/lib/python2.7/dist-packages/positional/__init__.py\",
> line 101, in inner\n    return wrapped(*args, **kwargs)\nTypeError:
> __init__() got an unexpected keyword argument 'min_version'\n",
> "module_stdout": "", "msg": "MODULE FAILURE"}
> 
> The message "got an unexpected keyword argument 'min_version'" seems to
> suggest some recent change to the ansible module os-image. Before I go
> looking too deep though, has anyone else seen this please?
> 
> Kind regards, Lawrence Albinson
> 

Are you on master or stable/pike? It appears that the problem is in the
'shade' package and there have been some changes on that front recently

https://review.openstack.org/#/q/topic:pin_shade

is your branch up to date? If not, could you update it and try again?

-- 
markos

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

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

Re: [openstack-dev] [openstack-ansible][tempest] "Ensure tempest image" failing

[Lawrence J. Albinson]

Just noticed that I left off the OSA version which is 15.1.7.

From: Lawrence J. Albinson
Sent: 08 September 2017 10:57
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [openstack-ansible][tempest] "Ensure tempest image" 
failing

Dear Colleagues,

I have just noticed that the short-form tempest run at the end of an 
openstack-ansible installation is failing with the following error:

TASK [os_tempest : Ensure tempest image] ***
Thursday 07 September 2017  19:29:12 +0100 (0:00:07.251)   0:45:55.029 
FAILED - RETRYING: TASK: os_tempest : Ensure tempest image (5 retries left).
FAILED - RETRYING: TASK: os_tempest : Ensure tempest image (4 retries left).
FAILED - RETRYING: TASK: os_tempest : Ensure tempest image (3 retries left).
FAILED - RETRYING: TASK: os_tempest : Ensure tempest image (2 retries left).
FAILED - RETRYING: TASK: os_tempest : Ensure tempest image (1 retries left).
fatal: [vyainfra1_utility_container-12b6cf07]: FAILED! => {"attempts": 5, 
"changed": false, "failed": true, "module_stderr": "mesg: ttyname failed: 
Inappropriate ioctl for device\nTraceback (most recent call last):\n  File 
\"/tmp/ansible_2l6Fyx/ansible_module_os_image.py\", line 193, in \n
main()\n  File \"/tmp/ansible_2l6Fyx/ansible_module_os_image.py\", line 147, in 
main\nimage = cloud.get_image(name_or_id=module.params['name'])\n  File 
\"/usr/local/lib/python2.7/dist-packages/shade/openstackcloud.py\", line 3074, 
in get_image\nreturn _utils._get_entity(self.search_images, name_or_id, 
filters)\n  File \"/usr/local/lib/python2.7/dist-packages/shade/_utils.py\", 
line 220, in _get_entity\nentities = func(name_or_id, filters, **kwargs)\n  
File \"/usr/local/lib/python2.7/dist-packages/shade/openstackcloud.py\", line 
1550, in search_images\nimages = self.list_images()\n  File 
\"/usr/local/lib/python2.7/dist-packages/shade/openstackcloud.py\", line 2130, 
in list_images\nif self._is_client_version('image', 2):\n  File 
\"/usr/local/lib/python2.7/dist-packages/shade/openstackcloud.py\", line 457, 
in _is_client_version\nclient = getattr(self, client_name)\n  File 
\"/usr/local/lib/python2.7/dist-packages/shade/openstackcloud.py\", line 525, 
in _image_client\n'image', min_version=1, max_version='2.latest')\n  File 
\"/usr/local/lib/python2.7/dist-packages/shade/openstackcloud.py\", line 403, 
in _get_versioned_client\nshade_logger=self.log)\n  File 
\"/usr/local/lib/python2.7/dist-packages/shade/_adapter.py\", line 87, in 
__init__\nsuper(ShadeAdapter, self).__init__(*args, **kwargs)\n  File 
\"/usr/local/lib/python2.7/dist-packages/positional/__init__.py\", line 101, in 
inner\nreturn wrapped(*args, **kwargs)\nTypeError: __init__() got an 
unexpected keyword argument 'min_version'\n", "module_stdout": "", "msg": 
"MODULE FAILURE"}

The message "got an unexpected keyword argument 'min_version'" seems to suggest 
some recent change to the ansible module os-image. Before I go looking too deep 
though, has anyone else seen this please?

Kind regards, Lawrence Albinson

__
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][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

[Mikhail Fedosin]

Hello!

I created an etherpad with the topics I want to discuss:
https://etherpad.openstack.org/p/ptg-glare-etsi

There I want to make a brief overview of glare features, that may be useful
for vnf packages support, and get a list of requirements from ETSI NFV
delegates, they want to see in the catalog of VNF packages.

Best regards,
Mikhail Fedosin

On Tue, Sep 5, 2017 at 6:04 PM, Csatari, Gergely (Nokia - HU/Budapest) <
gergely.csat...@nokia.com> wrote:

> Hi,
>
>
>
> We can try to squeeze it into the schedule. Can you collect your
> discussion topics to an etherpad so we can decide on the timing of the
> timeslot?
>
>
>
> Br,
>
> Gerg0
>
>
>
> *From:* Mikhail Fedosin [mailto:mfedo...@gmail.com]
> *Sent:* Tuesday, September 5, 2017 3:46 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]:
> OpenStack meets ETSI NFV workshop on 12.09.2017
>
>
>
> Yes, It will be even better! I can record a demo and publish it before the
> meeting.
>
>
>
> Could you schedule a short talk about IFA007 during the workshop?
>
>
>
> Best regards,
>
> Mikhail Fedosin
>
>
>
> On Fri, Sep 1, 2017 at 5:30 PM, Csatari, Gergely (Nokia - HU/Budapest) <
> gergely.csat...@nokia.com> wrote:
>
> Hi,
>
>
>
> Thanks for the proposal. The aim of this workshop is to accelerate the
> collaboration between OpenStack and ETSI and not to execute demonstrations.
> However if you have technical questions to IFA about IFA007 then we can add
> that as an agenda point.
>
>
>
> Br,
>
> Gerg0
>
>
>
> *From:* Mikhail Fedosin [mailto:mfedo...@gmail.com]
> *Sent:* Friday, September 1, 2017 1:03 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
>
>
> *Subject:* Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]:
> OpenStack meets ETSI NFV workshop on 12.09.2017
>
>
>
> Hello!
>
>
>
> I would also like to discuss the possibility of using Glare for
> cataloging VNF packages. Generally speaking Glare satisfies all the
> requirements from the standard http://www.etsi.org/
> deliver/etsi_gs/NFV-IFA/001_099/007/02.01.01_60/gs_NFV-IFA007v020101p.pdf
>
> Could we include this topic in the discussions, too?
>
>
>
> I plan to create an artifact type and present a short demo there, about
> how glare can work with the packages. If this topic is interesting, then we
> can discuss it in more detail on Wednesday or Thursday in dedicated Glare
> team room.
>
>
>
> Best regards,
>
> Mikhail Fedosin
>
>
>
> On Mon, Aug 28, 2017 at 5:06 PM, Csatari, Gergely (Nokia - HU/Budapest) <
> gergely.csat...@nokia.com> wrote:
>
> Hi,
>
> Thanks for the clarification.
>
> Our understanding was that with Panko it is possible to subscribe to the
> state of the different resource of the cloud as it is descibed in [1]. This
> is why we mapped the Virtualised [Compute|Network|Storage] Resources
> Capacity Management Interfaces to Panko.
>
> [1]: https://wiki.openstack.org/wiki/Telemetry#Managed
>
> Br,
> Gerg0
>
>
>
> -Original Message-
> From: gordon chung [mailto:g...@live.ca]
> Sent: Monday, August 28, 2017 3:05 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]:
> OpenStack meets ETSI NFV workshop on 12.09.2017
>
>
> > Gaps to be discussed are here:
> > https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-expla
> > ined
>
> i added a note in etherpad but it seems you want Ceilometer (+Gnocchi if
> you need storagE) and not Panko. Panko only handles storage of events (more
> metadata focused data) while Ceilometer handles the actual generation of
> both events and metrics, the latter being the one you want it seems.
> Gnocchi is used for optimised time-series metric storage.
>
> unfortunately, i don't believe anyone from Telemetry teams are attending
> the PTG but we can be reached on ML or #openstack-telemetry.
>
> cheers,
>
> --
> gord
> __
> 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 

Re: [openstack-dev] [tripleo] Facilitating automation testing in TripleO UI

[Jiri Tomasek]

On Fri, Aug 4, 2017 at 9:33 AM, Honza Pokorny  wrote:

> About 10 years ago, we were promised a fully semantic version of HTML.
> No more nested divs to structure your documents.  However, all we got
> was a few generic, and only marginally useful elements like  and
> .
>
> On 2017-08-03 18:59, Ana Krivokapic wrote:
> > Hi TripleO devs,
> >
> > In our effort to make the TripleO UI code friendlier to automation
> > testing[1], there is an open review[2] for which we seem to have some
> > difficulty reaching the consensus on how best to proceed. There is
> already
> > a discussion happening on the review itself, and I'd like to move it
> here,
> > rather than having it in a Gerrit review.
> >
> > The tricky part is around adding HTML element ids to the Nodes page. This
> > page is generated by looping through the list of registered nodes and
> > displaying complete information about each of them. Because of this, many
> > of the elements are repeating on the page (CPU info, BIOS, power state,
> > etc, for each node). We need to figure out how to make these elements
> easy
> > for the automation testing code to access, both in terms of locating a
> > single group within the page, as well as distinguishing the individual
> > elements of a group from each other. There are several approaches that
> > we've come up so far:
> >
> > 1) Add unique IDs to all the elements. Generate unique `id` html
> attributes
> > by including the node UUID in the value of the `id` attribute. Do this
> for
> > both the higher level elements (divs that hold all the information about
> a
> > single node), as well as the lower level (the ones that hold info about
> > BIOS, CPU, etc). The disadvantage of this approach is cluttering the UI
> > codebase with many `id` attributes that would otherwise not be needed.
>
> While this is useful for addressing a particular element, I think it
> would still require quite a bit of parsing.  You'd find yourself writing
> string-splitting code all over the place.  It would make the code harder
> to read without providing much semantic information --- unless of course
> every single element had some kind of ID.



>
> > 2) Add CSS classes instead of IDs. Pros for this approach: no need to
> > generate the clumsy ids containing the node UUID, since the CSS classes
> > don't need to be unique. Cons: we would be adding even more classes to
> HTML
> > elements, many of which are already cluttered with many classes. Also,
> > these classes would not exist anywhere in CSS or serve any other purpose.
>
> I like this option the best.  It seems to be the most natural way of
> adding semantic information to the bare-bones building blocks of the
> web.  Classes are simple strings that add information about the intended
> use of the element.  Using jQuery-like selectors, this can make for some
> easy-to-understand code.  Do you want to grab the power state of the
> currently expanded node in the list?
>
> $('#node-list div.node.expanded').find('.power-state')
>
> By default, Selenium can query the DOM by id, by class name, and by
> xpath.  It can be extended to use pyquery which is the Python
> implementation of the jQuery css selector.  I think many of the
> automation implementation headaches can be solved by using pyquery.
>
> https://blogs.gnome.org/danni/2012/11/19/extending-selenium-with-jquery/


I agree with this solution. Using IDs for unique elements in the page and
classes for elements which are repeating (list items) seems most natural
to me. In combination with pyquery it should be sufficient IMHO.

Also, to make sure that classes won't repeat and it is simple to identify
the desired element, we should use BEM [2] similarly as we do with IDs

Also note that incrementally we are extracting presentational components
into separate building blocks (see [1] for example), which makes the code
much more readable and classnames won't be cluttered any more.
e.g. instead of having code such as
content of item
we'll have
content of the
item
IIUC this is the semanticity Honza is looking for.

[1]
https://github.com/patternfly/patternfly-react/pull/50/files#diff-b2dff316cba6ec51de4d1712eef132d0R76
[2] https://codepen.io/Merri/post/advanced-bem-with-react-components

-- Jirka


>
> Furthermore, I think that classes can be used effectively when
> describing transient state like the expanded/collapsed state of a
> togglable element.  It's easy to implement on the client side, and it
> should be helpful on the automation side.
>
> Relying on patternfly presentational class names won't suffice.



>
> > 3) Add custom HTML attributes. These usually start with the 'data-'
> prefix,
> > and would not need to be unique either. Pros: avoids the problems
> described
> > with both approaches above. Cons: AFAIU, the React framework could have
> > problems with custom attributes (Jirka can probably explain this better).
> > Also, casual readers of the code could be confused about the purpose of
> > 

Re: [openstack-dev] [neutron] out-of-tree l3 service providers

[Kevin Benton]

Please add the requirements underneath the l3 flavors section of the
etherpad so we can come up with a plan during the PTG.

On Thu, Sep 7, 2017 at 11:04 PM, Isaku Yamahata 
wrote:

> On Fri, Sep 08, 2017 at 12:26:56PM +0900,
> Takashi Yamamoto  wrote:
>
> > hi,
> >
> > On Fri, Sep 8, 2017 at 5:52 AM, Isaku Yamahata 
> wrote:
> > > Hi.
> > >
> > > Any update on this? Now L3 service provider got the time slot at the
> PTG.
> > >
> > > Yamamoto, do you have any proposal for the interface?
> >
> > no
> >
> > > Although ODL surely is interested in L3 flavor, the networking-odl
> team hasn't
> > > spec or experimental patch yet unfortunately.
> >
> > can you at least provide your requirements?
>
> Sure.
>
> networking-odl needs PRECOMMIT/AFTER_CREATE/UPDATE/DELETE for
> router/floaringip and PRECOMMIT for disassociate_floatingip.
> The reason why precommit_disassociate_floatingip is needed is that
> right now ODL doesn't support to updating floatingip status by ODL.
> So floatingip status is forcibly set to DOWN by the callback for now.
> (It's in future roadmap)
> networking-odl doesn't need callback for add/remove_router_interface
> because
> only db operation does. ODL identifies router interface by port:owner
> which is
> updated by update_port.
>
> Thanks,
>
> > networking-midonet needs to send the following info to its backend on
> > AFTER_CREATE/AFTER_UPDATE for router, router_interface, and
> > floating_ip.
> > https://github.com/midonet/midonet/blob/fcc127f5c9216b7a563c89d2684461
> 428feb9a67/nsdb/src/main/proto/neutron.proto#L129-L161
> > (some of fields are actually unused right now. eg. tenant_id)
> > on AFTER_DELETE, we only need "id" field of the resource.
> > in feature we want to use PRECOMMIT_xxx events as well. necessary
> > fields are same as AFTER_xxx.
> >
> > > Dragon flow folks seems to have their own spec.
> > >
> > > thanks,
> > >
> > > On Mon, Jul 31, 2017 at 02:10:07PM +0900,
> > > Takashi Yamamoto  wrote:
> > >
> > >> hi,
> > >>
> > >> On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton 
> wrote:
> > >> > If I understand the main issue with using regular callbacks, it's
> mainly
> > >> > just that the flavor assignment itself is in a callback, right?
> > >>
> > >> yes.
> > >>
> > >> >
> > >> > If so, couldn't we solve the problem by just moving flavor
> assignment to an
> > >> > explicit call before emitting the callbacks? Or would that still
> result in
> > >> > other ordering issues?
> > >>
> > >> it would solve the problem for CREATE.
> > >> for UPDATE and DELETE, i'm not sure.
> > >> UPDATE can change the flavor but it's supposed to be a special case
> > >> only for dvr/ha, right?
> > >> AFTER_DELETE might be tricky as we probably need to provide flavor
> > >> info to subscribers.
> > >>
> > >> >
> > >> > On Thu, Jul 13, 2017 at 3:01 AM, Takashi Yamamoto <
> yamam...@midokura.com>
> > >> > wrote:
> > >> >>
> > >> >> hi,
> > >> >>
> > >> >> today i managed to play with l3 flavors.
> > >> >> i wrote a crude patch to implement midonet flavor. [1]
> > >> >>
> > >> >> [1] https://review.openstack.org/#/c/483174/
> > >> >>
> > >> >> a good news is it's somehow working.
> > >> >>
> > >> >> a bad news is it has a lot of issues, as you can see in TODO
> comments
> > >> >> in the patch.
> > >> >> given these issues, now i tend to think it's cleaner to introduce
> > >> >> ml2-like precommit/postcommit driver api (or its equivalent via
> > >> >> callbacks) rather than using these existing notifications.
> > >> >>
> > >> >> how do you think?
> > >> >
> > >> >
> > >>
> > >> 
> __
> > >> 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
> > >
> > > --
> > > Isaku Yamahata 
>
> --
> Isaku Yamahata 
>
__
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] [notification] cleaning up networking related notifications

[Balazs Gibizer]

Hi,

The addFixedIp REST API was deprecated in Pike [1] (in microversion 
2.44). As a result the legacy create_ip.start and create_ip.end 
notifications will not be emitted after microversion 2.44. We had a 
TODO[2] to transform this notification to the versioned format but now 
that seems a bit pointless. Also I've just found out that the existing 
POST os-interface REST API call does not emit any notification.


I think it would make sense not to transform the legacy notification in 
a deprecated code path but instead emit a new instance.interface_attach 
and instance.interface_detach notifications from the POST os-interface 
REST API code path, preferably from compute.manager.attach_interface().

Do you agree?

We also have TODOs about transforming floating_ip related 
notifications[2], e.g. network.floating_ip.allocate emitted from [3]. 
As far as I understand these notifications are only emitted from an 
already deprecated code path. Is it OK to remove them from our TODO 
list?


Cheers,
gibi


[1]https://review.openstack.org/#/c/457181/
[2]https://vntburndown-gibi.rhcloud.com/index.html
[3]https://github.com/openstack/nova/blob/master/nova/network/floating_ips.py#L230


__
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-ansible][tempest] "Ensure tempest image" failing

[Lawrence J. Albinson]

Dear Colleagues,

I have just noticed that the short-form tempest run at the end of an 
openstack-ansible installation is failing with the following error:

TASK [os_tempest : Ensure tempest image] ***
Thursday 07 September 2017  19:29:12 +0100 (0:00:07.251)   0:45:55.029 
FAILED - RETRYING: TASK: os_tempest : Ensure tempest image (5 retries left).
FAILED - RETRYING: TASK: os_tempest : Ensure tempest image (4 retries left).
FAILED - RETRYING: TASK: os_tempest : Ensure tempest image (3 retries left).
FAILED - RETRYING: TASK: os_tempest : Ensure tempest image (2 retries left).
FAILED - RETRYING: TASK: os_tempest : Ensure tempest image (1 retries left).
fatal: [vyainfra1_utility_container-12b6cf07]: FAILED! => {"attempts": 5, 
"changed": false, "failed": true, "module_stderr": "mesg: ttyname failed: 
Inappropriate ioctl for device\nTraceback (most recent call last):\n  File 
\"/tmp/ansible_2l6Fyx/ansible_module_os_image.py\", line 193, in \n
main()\n  File \"/tmp/ansible_2l6Fyx/ansible_module_os_image.py\", line 147, in 
main\nimage = cloud.get_image(name_or_id=module.params['name'])\n  File 
\"/usr/local/lib/python2.7/dist-packages/shade/openstackcloud.py\", line 3074, 
in get_image\nreturn _utils._get_entity(self.search_images, name_or_id, 
filters)\n  File \"/usr/local/lib/python2.7/dist-packages/shade/_utils.py\", 
line 220, in _get_entity\nentities = func(name_or_id, filters, **kwargs)\n  
File \"/usr/local/lib/python2.7/dist-packages/shade/openstackcloud.py\", line 
1550, in search_images\nimages = self.list_images()\n  File 
\"/usr/local/lib/python2.7/dist-packages/shade/openstackcloud.py\", line 2130, 
in list_images\nif self._is_client_version('image', 2):\n  File 
\"/usr/local/lib/python2.7/dist-packages/shade/openstackcloud.py\", line 457, 
in _is_client_version\nclient = getattr(self, client_name)\n  File 
\"/usr/local/lib/python2.7/dist-packages/shade/openstackcloud.py\", line 525, 
in _image_client\n'image', min_version=1, max_version='2.latest')\n  File 
\"/usr/local/lib/python2.7/dist-packages/shade/openstackcloud.py\", line 403, 
in _get_versioned_client\nshade_logger=self.log)\n  File 
\"/usr/local/lib/python2.7/dist-packages/shade/_adapter.py\", line 87, in 
__init__\nsuper(ShadeAdapter, self).__init__(*args, **kwargs)\n  File 
\"/usr/local/lib/python2.7/dist-packages/positional/__init__.py\", line 101, in 
inner\nreturn wrapped(*args, **kwargs)\nTypeError: __init__() got an 
unexpected keyword argument 'min_version'\n", "module_stdout": "", "msg": 
"MODULE FAILURE"}

The message "got an unexpected keyword argument 'min_version'" seems to suggest 
some recent change to the ansible module os-image. Before I go looking too deep 
though, has anyone else seen this please?

Kind regards, Lawrence Albinson

__
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] [ptg][heat] Heat PTG + Virtual meetup Agenda

[Rico Lin]

In case anyone can't find attached ICS file
ICS calendar:
https://drive.google.com/file/d/0B_UWw7JzTsWYZnIwYVpGR0REdms/view?usp=sharing

2017-09-07 18:44 GMT+08:00 Rico Lin :

> Hi heat members
>
> As we're going to have PTG in Denver(and online)
> Here are schedules and Etherpads for it [1].
>
> Encourage all to join us remotely if you can't make it to Denver!, we
> welcome anyone shares their ideas, experiences, efforts, and stories to us
> to help us make our design/implement better.
>
> Attached an ics file, feel free to add it to your calendar
>
> As we discussed in heat meeting, this Heat PTG will be a mixed format,
> Physical PTG room + Virtual Online channel together.
> The virtual link will share in [1], and if anything went wrong(like we
> have to change room URL), we will update to etherpad as well. So keep
> update to date with the etherpad.
>
> Also please notice that we won't host team meeting next week.
>
> [1] https://etherpad.openstack.org/p/heat-queens-ptg
>
> --
> May The Force of OpenStack Be With You,
>
> *Rico Lin*irc: ricolin
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
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] [octavia][l7policy] Is redirect to pool supported?

[mihaela.balas]

Sorry, I forgot the link to this documentation: 
https://docs.openstack.org/octavia/latest/user/guides/l7-cookbook.html

From: mihaela.ba...@orange.com [mailto:mihaela.ba...@orange.com]
Sent: Friday, September 08, 2017 10:07 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [octavia][l7policy] Is redirect to pool supported?

Hello,

Is redirect_to_pool policy currently supported with Octavia? Since a listener 
can only have one pool (the default pool) I cannot see how this can be 
configured. However, this documentation details a lot of scenarios. I am 
testing Octavia Ocata version.

Thank you,
Mihaela Balas

_



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.

_

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

[openstack-dev] [octavia][l7policy] Is redirect to pool supported?

[mihaela.balas]

Hello,

Is redirect_to_pool policy currently supported with Octavia? Since a listener 
can only have one pool (the default pool) I cannot see how this can be 
configured. However, this documentation details a lot of scenarios. I am 
testing Octavia Ocata version.

Thank you,
Mihaela Balas

_

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] [neutron] out-of-tree l3 service providers

[Isaku Yamahata]

On Fri, Sep 08, 2017 at 12:26:56PM +0900,
Takashi Yamamoto  wrote:

> hi,
> 
> On Fri, Sep 8, 2017 at 5:52 AM, Isaku Yamahata  
> wrote:
> > Hi.
> >
> > Any update on this? Now L3 service provider got the time slot at the PTG.
> >
> > Yamamoto, do you have any proposal for the interface?
> 
> no
> 
> > Although ODL surely is interested in L3 flavor, the networking-odl team 
> > hasn't
> > spec or experimental patch yet unfortunately.
> 
> can you at least provide your requirements?

Sure.

networking-odl needs PRECOMMIT/AFTER_CREATE/UPDATE/DELETE for
router/floaringip and PRECOMMIT for disassociate_floatingip.
The reason why precommit_disassociate_floatingip is needed is that
right now ODL doesn't support to updating floatingip status by ODL.
So floatingip status is forcibly set to DOWN by the callback for now.
(It's in future roadmap)
networking-odl doesn't need callback for add/remove_router_interface because
only db operation does. ODL identifies router interface by port:owner which is
updated by update_port.

Thanks,

> networking-midonet needs to send the following info to its backend on
> AFTER_CREATE/AFTER_UPDATE for router, router_interface, and
> floating_ip.
> https://github.com/midonet/midonet/blob/fcc127f5c9216b7a563c89d2684461428feb9a67/nsdb/src/main/proto/neutron.proto#L129-L161
> (some of fields are actually unused right now. eg. tenant_id)
> on AFTER_DELETE, we only need "id" field of the resource.
> in feature we want to use PRECOMMIT_xxx events as well. necessary
> fields are same as AFTER_xxx.
> 
> > Dragon flow folks seems to have their own spec.
> >
> > thanks,
> >
> > On Mon, Jul 31, 2017 at 02:10:07PM +0900,
> > Takashi Yamamoto  wrote:
> >
> >> hi,
> >>
> >> On Mon, Jul 24, 2017 at 8:49 AM, Kevin Benton  wrote:
> >> > If I understand the main issue with using regular callbacks, it's mainly
> >> > just that the flavor assignment itself is in a callback, right?
> >>
> >> yes.
> >>
> >> >
> >> > If so, couldn't we solve the problem by just moving flavor assignment to 
> >> > an
> >> > explicit call before emitting the callbacks? Or would that still result 
> >> > in
> >> > other ordering issues?
> >>
> >> it would solve the problem for CREATE.
> >> for UPDATE and DELETE, i'm not sure.
> >> UPDATE can change the flavor but it's supposed to be a special case
> >> only for dvr/ha, right?
> >> AFTER_DELETE might be tricky as we probably need to provide flavor
> >> info to subscribers.
> >>
> >> >
> >> > On Thu, Jul 13, 2017 at 3:01 AM, Takashi Yamamoto 
> >> > wrote:
> >> >>
> >> >> hi,
> >> >>
> >> >> today i managed to play with l3 flavors.
> >> >> i wrote a crude patch to implement midonet flavor. [1]
> >> >>
> >> >> [1] https://review.openstack.org/#/c/483174/
> >> >>
> >> >> a good news is it's somehow working.
> >> >>
> >> >> a bad news is it has a lot of issues, as you can see in TODO comments
> >> >> in the patch.
> >> >> given these issues, now i tend to think it's cleaner to introduce
> >> >> ml2-like precommit/postcommit driver api (or its equivalent via
> >> >> callbacks) rather than using these existing notifications.
> >> >>
> >> >> how do you think?
> >> >
> >> >
> >>
> >> __
> >> 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
> >
> > --
> > Isaku Yamahata 

-- 
Isaku Yamahata 

__
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