date:20161124

On Fri, Nov 25, 2016 at 4:36 PM, Takashi Yamamoto  wrote:
> On Fri, Nov 25, 2016 at 4:28 PM, Andreas Jaeger  wrote:
>> On 11/25/2016 05:26 AM, Takashi Yamamoto wrote:
>>> networking-midonet doesn't have stable/newton branch yet.
>>> newton jobs failures are false alarms.
>>
>> Then let's remove these jobs,
>
> sure. i'll submit project-config change.

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

>
>>
>> Andreas
>> --
>>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>>HRB 21284 (AG Nürnberg)
>> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>>
>>
>> __
>> 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] [neutron][networking-midonet] Fwd: [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

On Fri, Nov 25, 2016 at 4:28 PM, Andreas Jaeger  wrote:
> On 11/25/2016 05:26 AM, Takashi Yamamoto wrote:
>> networking-midonet doesn't have stable/newton branch yet.
>> newton jobs failures are false alarms.
>
> Then let's remove these jobs,

sure. i'll submit project-config change.

>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> 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] [neutron][networking-midonet] Fwd: [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

2016-11-24 Thread Andreas Jaeger

On 11/25/2016 05:26 AM, Takashi Yamamoto wrote:
> networking-midonet doesn't have stable/newton branch yet.
> newton jobs failures are false alarms.

Then let's remove these jobs,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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

[openstack-dev] [Horizon] End of week wrap-up

2016-11-24 Thread Richard Jones

Hi folks,

This was a bit of a slow-ish week given the number of folks away for
Thanksgiving. We had low-turnout Horizon meeting and cancelled the
Horizon/Keystone cross-project meeting. In the team meeting[1] we
covered:

- The patch priority review list, which looks a lot like last week :-(
- We agreed that we should try not to release xstatic libraries in
release week given compatibility issues.
- We discussed the automatic inclusion of xstatic packages in Horizon,
and upon reflection it's been decided it's a bad idea and we should
stick with an explicit whitelist which should be made easier to extend
if necessary.
- We punted on the question of the Zaqar push-based communication via
websocket patch that's been in play for a very long time. We'll
discuss it again next week when more folks are around.
- Pokemon, and how Thai needs to hand in his Gamer Card.

It really would be super awesome if folks could help us get through
those priority patches[2] so we can turn our focus to the angular work
for O-2! I'll start including the angular panels to be reviewed in
that list next week.

Some of us spent a lot of the week looking to further harden our
master and stable branches against library releases and this resulted
in a few changes, some of which are still up for review. We know some
of y'all have run into issues installing e.g. Mitaka or Newton and
have hit incompatibilities so if you do please hit us up in the
#openstack-horizon IRC channel, or on email, and we'll help you out.

The most important thing to remember is: use upper-constraints:

pip install -c
http://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt?h=stable/
.

Richard

[1]
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-11-16-20.00.html
[2] https://review.openstack.org/#/q/starredby:r1chardj0n3s%20AND%20status:open

__
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] stable/newton 'broken'

Armando, have a happy holiday!

From: "Armando M." 
Reply-To: OpenStack List 
Date: Thursday, November 24, 2016 at 11:09 PM
To: OpenStack List 
Subject: Re: [openstack-dev] [neutron] stable/newton 'broken'

On 24 November 2016 at 11:12, Gary Kotton 
> wrote:
The breakage is due to the fact that the projects do not have stable/newton 
branches cut.
This is something that I would have expected the neutron team to take care of 
as long as it was under the stadium/tent or whatever we want to call it.

Before [1] and [2] you were pulling from master all the time. You are in charge 
of your own project, so you are solely at fault of the issue you're complaining 
about.

[1] https://review.openstack.org/#/c/400462/
[2] https://review.openstack.org/#/c/402070/

The fact that the l2gw was removed may have been an indication that it should 
not have been there. But we have a clear responsibility to the community about 
this. Was there are mail indicating that it is excluded from the stadium/tent. 
I do not recall. I just woke up one morning discovering that you did that. 
There was not much discussion there.

LOL, you genuinely made me laugh. If you don't stay plugged, whose fault is 
that again? The discussion for the governance update did not happen overnight.

It is really unclear how the patches that you added below would have solved the 
problem.
We have made sure that the vmware-nsx code is back up and running. I just hope 
that others are unaffected by this.

My patch specifically would have not solved the problem you claim it's caused 
by the recent neutron master changes. I am just highlighting that prior to that 
you were always pulling from master. With my change you could simply set 
BRANCH=stable/newton in [3] in the appropriate branch and you'd be good to go.

[3] https://review.openstack.org/#/c/400462/1/tools/tox_install_project.sh@22

What I would like to see happen:

1.   L2gw gets a stable branch. At the moment the l2gw release team is non 
existent so community please advise how we can add cores
You can get hold of people [1] and ask them to make you join the team.

[1] https://review.openstack.org/#/admin/groups/532,members

2.   Tap-as-a-service is added to the stadium and tent.
 How is this relevant to this discussion?

A luta continua

From: "Armando M." >
Reply-To: OpenStack List 
>
Date: Thursday, November 24, 2016 at 7:03 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [neutron] stable/newton 'broken'

On 24 November 2016 at 02:38, Thierry Carrez 
> wrote:
Gary Kotton wrote:
> Please see - 
> http://logs.openstack.org/82/401882/1/check/gate-vmware-nsx-python27-db-ubuntu-xenial/1ac0686/console.html#_2016-11-24_06_58_38_520273
> Here we are pulling trunk as there is no stable version to use

Is neutron stable/newton really broken (like your subject seems to
indicate) ? Or only vmware-nsx stable/newton ? Since networking-l2gw and
tap-as-a-service are unofficial projects we can't guarantee that they
will create branches that match the official stable ones, so we should
try to avoid depending on them if possible...

This happens because the referenced projects have no newton branch and the 
consuming project's stable newton was pulling from the master branch (and [1] 
is the hack referenced below). The right fix would be to backport [2], create 
the stable branches of the projects to which vmware-nsx depends on and set the 
branch appropriately. This is what the neutron team does for the projects we 
look after.

This breakage was waiting to happen, and it just did.

[1] 
https://github.com/openstack/vmware-nsx/commit/9a455781e4db9fc360c3264b72c381c91dfa6a15
[2] 
https://github.com/openstack/vmware-nsx/commit/a951f5f9299ffdce268c54dc427a71706b8e41da

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

Re: [openstack-dev] [neutron][networking-odl] Fwd: [Openstack-stable-maint] Stable check of openstack/networking-odl failed

2016-11-24 Thread Rui Zang


Thanks for the notification. We are looking into it.


On 11/25/2016 8:09 AM, Ihar Hrachyshka wrote:

Hi,

Seems like newton branch of networking-odl is pulling neutron from
master. Whoever is responsible for the subproject, please fix.


Begin forwarded message:

*From: *"A mailing list for the OpenStack Stable Branch test reports."
>
*Subject: **[Openstack-stable-maint] Stable check of
openstack/networking-odl failed*
*Date: *24 November 2016 at 07:08:48 GMT+1
*To: *openstack-stable-ma...@lists.openstack.org

*Reply-To: *openstack-dev@lists.openstack.org


Build failed.

- periodic-networking-odl-docs-liberty
http://logs.openstack.org/periodic-stable/periodic-networking-odl-docs-liberty/5b534fb/
: SUCCESS in 2m 30s
- periodic-networking-odl-python27-liberty
http://logs.openstack.org/periodic-stable/periodic-networking-odl-python27-liberty/ef641c1/
: SUCCESS in 2m 57s
- periodic-networking-odl-docs-mitaka
http://logs.openstack.org/periodic-stable/periodic-networking-odl-docs-mitaka/9bcf6ec/
: SUCCESS in 2m 37s
- periodic-networking-odl-python27-mitaka
http://logs.openstack.org/periodic-stable/periodic-networking-odl-python27-mitaka/ebb71f0/
: SUCCESS in 4m 04s
- periodic-networking-odl-docs-newton
http://logs.openstack.org/periodic-stable/periodic-networking-odl-docs-newton/b79be05/
: SUCCESS in 2m 21s
- periodic-networking-odl-python27-newton
http://logs.openstack.org/periodic-stable/periodic-networking-odl-python27-newton/18e0a8d/
: FAILURE in 2m 53s

___
Openstack-stable-maint mailing list
openstack-stable-ma...@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint




__
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] [neutron] stable/newton 'broken'

2016-11-24 Thread reedip banerjee

I agree to tap-as-a-service being tech-preview for this release to get over
this issue , if it is still relevant.


On Fri, Nov 25, 2016 at 2:39 AM, Armando M.  wrote:

>
>
> On 24 November 2016 at 11:12, Gary Kotton  wrote:
>
>> The breakage is due to the fact that the projects do not have
>> stable/newton branches cut.
>>
> This is something that I would have expected the neutron team to take care
>> of as long as it was under the stadium/tent or whatever we want to call it.
>>
>
> Before [1] and [2] you were pulling from master all the time. You are in
> charge of your own project, so you are solely at fault of the issue you're
> complaining about.
>
> [1] https://review.openstack.org/#/c/400462/
> [2] https://review.openstack.org/#/c/402070/
>
>
>> The fact that the l2gw was removed may have been an indication that it
>> should not have been there. But we have a clear responsibility to the
>> community about this. Was there are mail indicating that it is excluded
>> from the stadium/tent. I do not recall. I just woke up one morning
>> discovering that you did that. There was not much discussion there.
>>
>
> LOL, you genuinely made me laugh. If you don't stay plugged, whose fault
> is that again? The discussion for the governance update did not happen
> overnight.
>
>
>>
> It is really unclear how the patches that you added below would have
>> solved the problem.
>>
>> We have made sure that the vmware-nsx code is back up and running. I just
>> hope that others are unaffected by this.
>>
>
> My patch specifically would have not solved the problem you claim it's
> caused by the recent neutron master changes. I am just highlighting that
> prior to that you were always pulling from master. With my change you could
> simply set BRANCH=stable/newton in [3] in the appropriate branch and you'd
> be good to go.
>
> [3] https://review.openstack.org/#/c/400462/1/tools/tox_install_
> project.sh@22
>
> What I would like to see happen:
>>
>> 1.   L2gw gets a stable branch. At the moment the l2gw release team
>> is non existent so community please advise how we can add cores
>>
> You can get hold of people [1] and ask them to make you join the team.
>
> [1] https://review.openstack.org/#/admin/groups/532,members
>
>> 2.   Tap-as-a-service is added to the stadium and tent.
>>
>  How is this relevant to this discussion?
>
>
>>
>> A luta continua
>>
>>
>>
>> *From: *"Armando M." 
>> *Reply-To: *OpenStack List 
>> *Date: *Thursday, November 24, 2016 at 7:03 PM
>> *To: *OpenStack List 
>> *Subject: *Re: [openstack-dev] [neutron] stable/newton 'broken'
>>
>>
>>
>>
>>
>>
>>
>> On 24 November 2016 at 02:38, Thierry Carrez 
>> wrote:
>>
>> Gary Kotton wrote:
>> > Please see - http://logs.openstack.org/82/4
>> 01882/1/check/gate-vmware-nsx-python27-db-ubuntu-xenial/1ac0
>> 686/console.html#_2016-11-24_06_58_38_520273
>> > Here we are pulling trunk as there is no stable version to use
>>
>> Is neutron stable/newton really broken (like your subject seems to
>> indicate) ? Or only vmware-nsx stable/newton ? Since networking-l2gw and
>> tap-as-a-service are unofficial projects we can't guarantee that they
>> will create branches that match the official stable ones, so we should
>> try to avoid depending on them if possible...
>>
>>
>>
>> This happens because the referenced projects have no newton branch and
>> the consuming project's stable newton was pulling from the master branch
>> (and [1] is the hack referenced below). The right fix would be to backport
>> [2], create the stable branches of the projects to which vmware-nsx depends
>> on and set the branch appropriately. This is what the neutron team does for
>> the projects we look after.
>>
>>
>>
>> This breakage was waiting to happen, and it just did.
>>
>>
>>
>> [1] https://github.com/openstack/vmware-nsx/commit/9a455781e
>> 4db9fc360c3264b72c381c91dfa6a15
>> 
>>
>> [2] https://github.com/openstack/vmware-nsx/commit/a951f5f92
>> 99ffdce268c54dc427a71706b8e41da
>> 
>>
>>
>>
>>
>> --
>> Thierry Carrez (ttx)
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:

Re: [openstack-dev] [neutron][networking-midonet] Fwd: [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

hi,

networking-midonet doesn't have stable/newton branch yet.
newton jobs failures are false alarms.

branching has been delayed because development of some futures
planned for newton has not been completed yet.

the plan is to revert ocata-specific changes after branching newton.

On Fri, Nov 25, 2016 at 9:14 AM, Ihar Hrachyshka  wrote:
> Hi,
>
> could anyone from the midonet subproject take ownership of repo stable
> branches? Newton branch is broken for weeks with no apparent actions from
> the core team side.
>
> Begin forwarded message:
>
> From: "A mailing list for the OpenStack Stable Branch test reports."
> 
> Subject: [Openstack-stable-maint] Stable check of
> openstack/networking-midonet failed
> Date: 24 November 2016 at 07:11:42 GMT+1
> To: openstack-stable-ma...@lists.openstack.org
> Reply-To: openstack-dev@lists.openstack.org
>
> Build failed.
>
> - periodic-networking-midonet-docs-liberty
> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-docs-liberty/b912665/
> : SUCCESS in 4m 58s
> - periodic-networking-midonet-python27-liberty
> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-python27-liberty/978a77c/
> : SUCCESS in 9m 57s
> - periodic-networking-midonet-docs-mitaka
> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-docs-mitaka/e4e139e/
> : SUCCESS in 2m 19s
> - periodic-networking-midonet-python27-mitaka
> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-python27-mitaka/d61abf6/
> : SUCCESS in 7m 06s
> - periodic-networking-midonet-docs-newton
> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-docs-newton/55ae3d1/
> : SUCCESS in 2m 34s
> - periodic-networking-midonet-python27-newton
> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-python27-newton/db864e6/
> : FAILURE in 3m 57s
>
> ___
> Openstack-stable-maint mailing list
> openstack-stable-ma...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
>
>

__
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] [daisycloud-core] Agenda for IRC meeting 0800UTC Nov. 25 2016

2016-11-24 Thread hu . zhijiang

1) Roll Call
2) OPNFV: CI Progress
3) OPNFV: Escalator Support
4) nominate Ya to be daisycloud-core core reviewer.
5) Newton

B.R.,
Zhijiang



__
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] 答复: RE: RE: [vitrage] about aodh alarm notification

2016-11-24 Thread dong . wenjuan

EmThe solution goes back to my first question.
Snapshot service calls get_all, and caches all the alarms.
But listener service can't get the cache because there are two services 
and can't share the cache.


BR,
dwj







"Weyl, Alexey (Nokia - IL)"  
2016-11-24 23:50

收件人
"dong.wenj...@zte.com.cn" 
抄送
"Hefetz, Idan (Nokia - IL)" , "Afek, Ifat (Nokia - 
IL)" , "openstack-dev@lists.openstack.org" 
, "zhang.yuj...@zte.com.cn" 

主题
RE: RE: [openstack-dev] [vitrage] about aodh alarm notification






It seems that you will need to have a cache for that issue.
Due to the fact that AODH alarms aren’t deleted, and stay alive (in AODH) 
when their state is changed to ok (but in this case aren’t supposed to 
appear in Vitrage), and then when the state is changed back to error (‘
alarm’) they are supposed to appear in Vitrage with all the data, the 
most simple way to do that (without touching the core processor and 
architecture) is by saving those alarms of AODH in cache in the AODH 
driver, update its data every change that arrive to the driver, and then 
when a notification arrives and if the state that arrived is different 
than OK and the state that was in the cache is OK then send an event with 
all the data updated in the cache to the queue, otherwise send only the 
data received from the oslo bus to the queue (don’t forget of course to 
update the cache each time an event received, and each time we call the 
get_all of aodh (every snapshot_interval time) we can update the data in 
the cache as well.
 
Alexey
 
From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
Sent: Thursday, November 24, 2016 11:24 AM
To: Weyl, Alexey (Nokia - IL)
Cc: Hefetz, Idan (Nokia - IL); Afek, Ifat (Nokia - IL); 
openstack-dev@lists.openstack.org; zhang.yuj...@zte.com.cn
Subject: 答复: RE: [openstack-dev] [vitrage] about aodh alarm notification
 

Hi Weyl Alexey, 

Another question: 
If we received the alarm.creation notification with the 'ok' state, we 
filter it and don't create vertex in the Graph. 
The next received the alarm state_change notification, all the other alarm 
details are missing in the vertex. 
How can I handle this? Thanks~ 


BR, 
dwj






"Weyl, Alexey (Nokia - IL)"  
2016-11-24 16:25 


收件人
"dong.wenj...@zte.com.cn" , "Afek, Ifat (Nokia - 
IL)" , "Hefetz, Idan (Nokia - IL)" <
idan.hef...@nokia.com>, "zhang.yuj...@zte.com.cn"  
抄送
"openstack-dev@lists.openstack.org"  
主题
RE: [openstack-dev] [vitrage] about aodh alarm notification
 








Hi Dong,

Good question, I will explain how you can handle this problem in Vitrage.

You don't need the cache mechanism here, it is much more simplier.

When you get a new alarm with get_all or by notification of 
'alarm.creation' you will create the alarm with its correct data \ 
properties.
Then when you receive a notification of 'alarm.rule_change', 
'alarm.state_transition', 'alarm.deletion' all you need to do is only to 
update the correct property that has changed in the aodh vertex.
Thus, When you create the Vertex in the transformer, you know the aodh 
uuid so you know the vitrage_id, and you can pass only the properties that 
you have received and want to update (and not all the properties that 
there in the aodh vertex). All the other properties that you haven't 
received that haven't changed you can pass them as None and they won't be 
changed in the graph.

Hope this explains everything.
If you have other questions, you are more than welcome to ask.

Best Regrads,
Alexey


From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
Sent: Thursday, November 24, 2016 9:39 AM
To: Afek, Ifat (Nokia - IL); Weyl, Alexey (Nokia - IL); Hefetz, Idan 
(Nokia - IL); zhang.yuj...@zte.com.cn
Cc: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [vitrage] about aodh alarm notification


Hi Vitrages, 

Currently there are four aodh alarm notifications we need to handle: 
'alarm.creation', 'alarm.rule_change', 'alarm.state_transition', 
'alarm.deletion' 

Only the alarm.creation notification carries the alarm detail info. 
So we need to cache the alarm info. 
When we receive other notifications, we can fill all fields from the 
cache. 

But if the alarm creates before vitrage servies startup, we can't get the 
alarm.creation notification. 
So we need to get_all when vitrage services startup. 
As `SnapshotsService` will get all alarms info when it startup. 
But `SnapshotsService` and `ListenerService` are two services, 
they can't share the cache data unless they communicate with each other. 
This wil be a big change. 

Are there any other better solutions? I need some help, thanks :) 

BR, 
dwj

__

[openstack-dev] [neutron][networking-midonet] Fwd: [Openstack-stable-maint] Stable check of openstack/networking-midonet failed

Hi,

could anyone from the midonet subproject take ownership of repo stable 
branches? Newton branch is broken for weeks with no apparent actions from the 
core team side.

> Begin forwarded message:
> 
> From: "A mailing list for the OpenStack Stable Branch test reports." 
> 
> Subject: [Openstack-stable-maint] Stable check of 
> openstack/networking-midonet failed
> Date: 24 November 2016 at 07:11:42 GMT+1
> To: openstack-stable-ma...@lists.openstack.org
> Reply-To: openstack-dev@lists.openstack.org
> 
> Build failed.
> 
> - periodic-networking-midonet-docs-liberty 
> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-docs-liberty/b912665/
>  : SUCCESS in 4m 58s
> - periodic-networking-midonet-python27-liberty 
> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-python27-liberty/978a77c/
>  : SUCCESS in 9m 57s
> - periodic-networking-midonet-docs-mitaka 
> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-docs-mitaka/e4e139e/
>  : SUCCESS in 2m 19s
> - periodic-networking-midonet-python27-mitaka 
> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-python27-mitaka/d61abf6/
>  : SUCCESS in 7m 06s
> - periodic-networking-midonet-docs-newton 
> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-docs-newton/55ae3d1/
>  : SUCCESS in 2m 34s
> - periodic-networking-midonet-python27-newton 
> http://logs.openstack.org/periodic-stable/periodic-networking-midonet-python27-newton/db864e6/
>  : FAILURE in 3m 57s
> 
> ___
> Openstack-stable-maint mailing list
> openstack-stable-ma...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint

__
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][networking-odl] Fwd: [Openstack-stable-maint] Stable check of openstack/networking-odl failed

Hi,

Seems like newton branch of networking-odl is pulling neutron from master. 
Whoever is responsible for the subproject, please fix.

> Begin forwarded message:
> 
> From: "A mailing list for the OpenStack Stable Branch test reports." 
> 
> Subject: [Openstack-stable-maint] Stable check of openstack/networking-odl 
> failed
> Date: 24 November 2016 at 07:08:48 GMT+1
> To: openstack-stable-ma...@lists.openstack.org
> Reply-To: openstack-dev@lists.openstack.org
> 
> Build failed.
> 
> - periodic-networking-odl-docs-liberty 
> http://logs.openstack.org/periodic-stable/periodic-networking-odl-docs-liberty/5b534fb/
>  : SUCCESS in 2m 30s
> - periodic-networking-odl-python27-liberty 
> http://logs.openstack.org/periodic-stable/periodic-networking-odl-python27-liberty/ef641c1/
>  : SUCCESS in 2m 57s
> - periodic-networking-odl-docs-mitaka 
> http://logs.openstack.org/periodic-stable/periodic-networking-odl-docs-mitaka/9bcf6ec/
>  : SUCCESS in 2m 37s
> - periodic-networking-odl-python27-mitaka 
> http://logs.openstack.org/periodic-stable/periodic-networking-odl-python27-mitaka/ebb71f0/
>  : SUCCESS in 4m 04s
> - periodic-networking-odl-docs-newton 
> http://logs.openstack.org/periodic-stable/periodic-networking-odl-docs-newton/b79be05/
>  : SUCCESS in 2m 21s
> - periodic-networking-odl-python27-newton 
> http://logs.openstack.org/periodic-stable/periodic-networking-odl-python27-newton/18e0a8d/
>  : FAILURE in 2m 53s
> 
> ___
> Openstack-stable-maint mailing list
> openstack-stable-ma...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint

__
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] stable/newton 'broken'

On 24 November 2016 at 11:12, Gary Kotton  wrote:

> The breakage is due to the fact that the projects do not have
> stable/newton branches cut.
>
This is something that I would have expected the neutron team to take care
> of as long as it was under the stadium/tent or whatever we want to call it.
>

Before [1] and [2] you were pulling from master all the time. You are in
charge of your own project, so you are solely at fault of the issue you're
complaining about.

[1] https://review.openstack.org/#/c/400462/
[2] https://review.openstack.org/#/c/402070/


> The fact that the l2gw was removed may have been an indication that it
> should not have been there. But we have a clear responsibility to the
> community about this. Was there are mail indicating that it is excluded
> from the stadium/tent. I do not recall. I just woke up one morning
> discovering that you did that. There was not much discussion there.
>

LOL, you genuinely made me laugh. If you don't stay plugged, whose fault is
that again? The discussion for the governance update did not happen
overnight.


>
It is really unclear how the patches that you added below would have solved
> the problem.
>
> We have made sure that the vmware-nsx code is back up and running. I just
> hope that others are unaffected by this.
>

My patch specifically would have not solved the problem you claim it's
caused by the recent neutron master changes. I am just highlighting that
prior to that you were always pulling from master. With my change you could
simply set BRANCH=stable/newton in [3] in the appropriate branch and you'd
be good to go.

[3]
https://review.openstack.org/#/c/400462/1/tools/tox_install_project.sh@22

What I would like to see happen:
>
> 1.   L2gw gets a stable branch. At the moment the l2gw release team
> is non existent so community please advise how we can add cores
>
You can get hold of people [1] and ask them to make you join the team.

[1] https://review.openstack.org/#/admin/groups/532,members

> 2.   Tap-as-a-service is added to the stadium and tent.
>
 How is this relevant to this discussion?


>
> A luta continua
>
>
>
> *From: *"Armando M." 
> *Reply-To: *OpenStack List 
> *Date: *Thursday, November 24, 2016 at 7:03 PM
> *To: *OpenStack List 
> *Subject: *Re: [openstack-dev] [neutron] stable/newton 'broken'
>
>
>
>
>
>
>
> On 24 November 2016 at 02:38, Thierry Carrez 
> wrote:
>
> Gary Kotton wrote:
> > Please see - http://logs.openstack.org/82/401882/1/check/gate-vmware-
> nsx-python27-db-ubuntu-xenial/1ac0686/console.html#_2016-11-
> 24_06_58_38_520273
> > Here we are pulling trunk as there is no stable version to use
>
> Is neutron stable/newton really broken (like your subject seems to
> indicate) ? Or only vmware-nsx stable/newton ? Since networking-l2gw and
> tap-as-a-service are unofficial projects we can't guarantee that they
> will create branches that match the official stable ones, so we should
> try to avoid depending on them if possible...
>
>
>
> This happens because the referenced projects have no newton branch and the
> consuming project's stable newton was pulling from the master branch (and
> [1] is the hack referenced below). The right fix would be to backport [2],
> create the stable branches of the projects to which vmware-nsx depends on
> and set the branch appropriately. This is what the neutron team does for
> the projects we look after.
>
>
>
> This breakage was waiting to happen, and it just did.
>
>
>
> [1] https://github.com/openstack/vmware-nsx/commit/
> 9a455781e4db9fc360c3264b72c381c91dfa6a15
> 
>
> [2] https://github.com/openstack/vmware-nsx/commit/
> a951f5f9299ffdce268c54dc427a71706b8e41da
> 
>
>
>
>
> --
> Thierry Carrez (ttx)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>

Re: [openstack-dev] [keystone][ceilometer] 'ceilometer -d meter-list' hangs in "Making authentication request to keystone"

2016-11-24 Thread Srikanth Vavilapalli

Hi

We have root caused the issue. It is due to longer MTU setting in the VMs and 
because VxLAN tunneling is used for VM to VM communication on different compute 
nodes, the encapsulated packets are going beyond MTUs in the underlying network 
and getting fragmented and causing the connection issues. So I have set the MTU 
in the VMs to 1400 and the TCP MSS getting adjusted accordingly and now 
communication is working between VM1 & VM2. 

Thanks
Srikanth

-Original Message-
From: Srikanth Vavilapalli [mailto:srikanth.vavilapa...@ericsson.com] 
Sent: Wednesday, November 23, 2016 9:54 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [keystone][ceilometer] 'ceilometer -d meter-list' 
hangs in "Making authentication request to keystone"

We have ensured that the both UDP and TCP communication is good between VM1 and 
VM2. Also if you see ceilometer debug output in my initial e-mail, the first 
keystone REST (curl -g -i -X GET http://mysite-ceilometer-6:5000/v2.0) from VM2 
to VM1 was successful, it hanged only at the second keystone REST (POST 
http://mysite-ceilometer-6:5000/v2.0/tokens). So communication seems like not a 
problem here.

ubuntu@mysite-ceilometer-7:~$ ping 10.0.4.4 PING 10.0.4.4 (10.0.4.4) 56(84) 
bytes of data.
64 bytes from 10.0.4.4: icmp_seq=1 ttl=64 time=3.51 ms
64 bytes from 10.0.4.4: icmp_seq=2 ttl=64 time=2.03 ms
64 bytes from 10.0.4.4: icmp_seq=3 ttl=64 time=1.37 ms ^C
--- 10.0.4.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt 
min/avg/max/mdev = 1.372/2.307/3.511/0.893 ms

ubuntu@mysite-ceilometer-6:~$ nc -l 1048 Hello How is the connection?
Good

ubuntu@mysite-ceilometer-7:~$ nc 10.0.4.4 1048 Hello How is the connection?
Good

-Original Message-
From: gordon chung [mailto:g...@live.ca]
Sent: Wednesday, November 23, 2016 8:22 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [keystone][ceilometer] 'ceilometer -d meter-list' 
hangs in "Making authentication request to keystone"

On 23/11/16 09:16 PM, Srikanth Vavilapalli wrote:
> Yes, I agree, this issue is not related to ceilometer. We have verified that 
> none of the keystone commands (keystone endpoint-list, keystone catalog, 
> keystone user-list) are working in that VM2, they all stuck in getting the 
> token-get operation (/v2.0/tokens).
>
> If I had to suspect the keystone server setup in my VM1, then the keystone 
> client on VM3 also wouldn't work. So seems something else is going wrong 
> here. The keystone debugs logs also not helping much here...

you could try seeing if you can access vm1 from vm2. i imagine you have some 
networking issues.

>
> On the last part, could you plz point us to any existing wiki pages that 
> describe to migrate away from ceilometer-api? Thanks for ur help...

we have a guide on how to switch to Gnocchi[1]. we don't currently have a guide 
to switch to anything else but you can always just use either udp or http 
publishers and push to your required target... that our just push to 
oslo.messaging topic and have your service consume from it.

[1]
http://docs.openstack.org/developer/ceilometer/install/dbreco.html#moving-from-ceilometer-to-gnocchi

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

Re: [openstack-dev] [Congress] Magnum_driver

2016-11-24 Thread Ruben

Hi Tim,
I solved the problem with:

tox --recreate -e py27

Now I no have the error on the import. The unit test still has some errors, but 
I don't know why..

Anyway, I've this error when I try to add the magnum_driver: 

2016-11-24 20:56:27.191 INFO congress.datasources.datasource_driver [-] 
magnum:: polling
2016-11-24 20:56:27.192 DEBUG congress.datasources.datasource_driver [-] update 
table clusters. from (pid=18720) update_from_datasource 
/opt/stack/congress/congress/datasources/datasource_driver.py:1370
2016-11-24 20:56:27.427 DEBUG congress.datasources.magnum_driver [-] CLUSTERS: 
{'clusters': [http://10.0.2.15:9511/v1/clusters/1634beb9-25de-4cdd-bafa-67537069f0cc', 
u'rel': u'self'}, {u'href': 
u'http://10.0.2.15:9511/clusters/1634beb9-25de-4cdd-bafa-67537069f0cc', u'rel': 
u'bookmark'}], u'stack_id': u'17f1248d-286a-4fd4-9639-af5773670f03', 
u'master_count': 1, u'keypair': u'testkey', u'node_count': 1, 
u'create_timeout': 60, u'name': u'k8s-cluster'}>]} from (pid=18720) 
_translate_clusters 
/opt/stack/congress/congress/datasources/magnum_driver.py:165
2016-11-24 20:56:27.435 ERROR congress.datasources.datasource_driver [-] 
Datasource driver raised exception
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver Traceback 
(most recent call last):
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver   File 
"/opt/stack/congress/congress/datasources/datasource_driver.py", line 1384, in 
poll
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver 
self.update_from_datasource()  # sets self.state
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver   File 
"/opt/stack/congress/congress/datasources/datasource_driver.py", line 1371, in 
update_from_datasource
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver 
self.update_methods[registered_table]()
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver   File 
"/opt/stack/congress/congress/datasources/magnum_driver.py", line 150, in 

2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver 
{'clusters': self.magnum.clusters.list()})
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver   File 
"/opt/stack/congress/congress/datasources/datasource_utils.py", line 57, in 
inner
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver result 
= f(self, raw_data, *args, **kw)
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver   File 
"/opt/stack/congress/congress/datasources/magnum_driver.py", line 167, in 
_translate_clusters
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver 
obj['clusters'], MagnumDriver.clusters_translator)
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver   File 
"/opt/stack/congress/congress/datasources/datasource_driver.py", line 1048, in 
convert_objs
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver rows, 
_ = DataSourceDriver.convert_obj(o, translator)
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver   File 
"/opt/stack/congress/congress/datasources/datasource_driver.py", line 1021, in 
convert_obj
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver 
parent_row_dict)
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver   File 
"/opt/stack/congress/congress/datasources/datasource_driver.py", line 994, in 
_populate_translator_data_hdict
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver return 
cls._populate_hdict(translator, obj, parent_row_dict)
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver   File 
"/opt/stack/congress/congress/datasources/datasource_driver.py", line 924, in 
_populate_hdict
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver 
cls._get_value(obj, field, selector), extract_fn)
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver   File 
"/opt/stack/congress/congress/datasources/datasource_driver.py", line 693, in 
_get_value
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver if 
field in o:
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver TypeError: 
argument of type 'Cluster' is not iterable
2016-11-24 20:56:27.435 TRACE congress.datasources.datasource_driver 
2016-11-24 20:56:27.435 INFO congress.datasources.datasource_driver [-] 
magnum:: finished polling


Any suggestions to solve it?
I've add the code to review.

Ruben

- Original Message -
From: "Ruben" 
To: "Tim Hinrichs" 
Cc: openstack-dev@lists.openstack.org, "timothy l hinrichs" 

Sent: Thursday, November 24, 2016 12:44:38 AM
Subject: Re: [Congress] Magnum_driver

Hi Tim,
I already have 'pyhton-magnumclient' in the requirements.txt file, but I still 
have the error.

This is the /opt/stack/congress/requirements.txt file:

"# The order of packages is

Re: [openstack-dev] [neutron] stable/newton 'broken'

Sukdev has updated the group ☺
Happy holidays

From: Gary Kotton 
Reply-To: OpenStack List 
Date: Thursday, November 24, 2016 at 9:12 PM
To: OpenStack List 
Subject: Re: [openstack-dev] [neutron] stable/newton 'broken'

The breakage is due to the fact that the projects do not have stable/newton 
branches cut. This is something that I would have expected the neutron team to 
take care of as long as it was under the stadium/tent or whatever we want to 
call it. The fact that the l2gw was removed may have been an indication that it 
should not have been there. But we have a clear responsibility to the community 
about this. Was there are mail indicating that it is excluded from the 
stadium/tent. I do not recall. I just woke up one morning discovering that you 
did that. There was not much discussion there.
It is really unclear how the patches that you added below would have solved the 
problem.
We have made sure that the vmware-nsx code is back up and running. I just hope 
that others are unaffected by this.
What I would like to see happen:

1.  L2gw gets a stable branch. At the moment the l2gw release team is non 
existent so community please advise how we can add cores

2.  Tap-as-a-service is added to the stadium and tent.

A luta continua

From: "Armando M." 
Reply-To: OpenStack List 
Date: Thursday, November 24, 2016 at 7:03 PM
To: OpenStack List 
Subject: Re: [openstack-dev] [neutron] stable/newton 'broken'

On 24 November 2016 at 02:38, Thierry Carrez 
> wrote:
Gary Kotton wrote:
> Please see - 
> http://logs.openstack.org/82/401882/1/check/gate-vmware-nsx-python27-db-ubuntu-xenial/1ac0686/console.html#_2016-11-24_06_58_38_520273
> Here we are pulling trunk as there is no stable version to use

Is neutron stable/newton really broken (like your subject seems to
indicate) ? Or only vmware-nsx stable/newton ? Since networking-l2gw and
tap-as-a-service are unofficial projects we can't guarantee that they
will create branches that match the official stable ones, so we should
try to avoid depending on them if possible...

This happens because the referenced projects have no newton branch and the 
consuming project's stable newton was pulling from the master branch (and [1] 
is the hack referenced below). The right fix would be to backport [2], create 
the stable branches of the projects to which vmware-nsx depends on and set the 
branch appropriately. This is what the neutron team does for the projects we 
look after.

This breakage was waiting to happen, and it just did.

[1] 
https://github.com/openstack/vmware-nsx/commit/9a455781e4db9fc360c3264b72c381c91dfa6a15
[2] 
https://github.com/openstack/vmware-nsx/commit/a951f5f9299ffdce268c54dc427a71706b8e41da

--
Thierry Carrez (ttx)

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

__
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] stable/newton 'broken'

The breakage is due to the fact that the projects do not have stable/newton 
branches cut. This is something that I would have expected the neutron team to 
take care of as long as it was under the stadium/tent or whatever we want to 
call it. The fact that the l2gw was removed may have been an indication that it 
should not have been there. But we have a clear responsibility to the community 
about this. Was there are mail indicating that it is excluded from the 
stadium/tent. I do not recall. I just woke up one morning discovering that you 
did that. There was not much discussion there.
It is really unclear how the patches that you added below would have solved the 
problem.
We have made sure that the vmware-nsx code is back up and running. I just hope 
that others are unaffected by this.
What I would like to see happen:

1.   L2gw gets a stable branch. At the moment the l2gw release team is non 
existent so community please advise how we can add cores

2.   Tap-as-a-service is added to the stadium and tent.

A luta continua

From: "Armando M." 
Reply-To: OpenStack List 
Date: Thursday, November 24, 2016 at 7:03 PM
To: OpenStack List 
Subject: Re: [openstack-dev] [neutron] stable/newton 'broken'

On 24 November 2016 at 02:38, Thierry Carrez 
> wrote:
Gary Kotton wrote:
> Please see - 
> http://logs.openstack.org/82/401882/1/check/gate-vmware-nsx-python27-db-ubuntu-xenial/1ac0686/console.html#_2016-11-24_06_58_38_520273
> Here we are pulling trunk as there is no stable version to use

Is neutron stable/newton really broken (like your subject seems to
indicate) ? Or only vmware-nsx stable/newton ? Since networking-l2gw and
tap-as-a-service are unofficial projects we can't guarantee that they
will create branches that match the official stable ones, so we should
try to avoid depending on them if possible...

This happens because the referenced projects have no newton branch and the 
consuming project's stable newton was pulling from the master branch (and [1] 
is the hack referenced below). The right fix would be to backport [2], create 
the stable branches of the projects to which vmware-nsx depends on and set the 
branch appropriately. This is what the neutron team does for the projects we 
look after.

This breakage was waiting to happen, and it just did.

[1] 
https://github.com/openstack/vmware-nsx/commit/9a455781e4db9fc360c3264b72c381c91dfa6a15
[2] 
https://github.com/openstack/vmware-nsx/commit/a951f5f9299ffdce268c54dc427a71706b8e41da

--
Thierry Carrez (ttx)

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

__
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] neutron-lib impact

On 24 November 2016 at 10:16, Neil Jerram  wrote:

> To be clear, when I said 'catching such issues', what I meant was:
> 'letting me know promptly that I now need to update networking-calico'.
>

We're asking folks to take a number of steps to properly communicate
potential issues such as those happened during the past 24 hours:

   - Mark a change's commit message with 'NeutronLibImpact' so that it can
   be caught with gerrit filters [1,2]. This helps folks to check for imminent
   potential impact or past impact that one has to catch up to. We have a
   weekly team meeting discussion about such issues to raise visibility.
   - further raise awareness in ML threads, in case offline discussion is
   required.

Monitoring the usual channels (team meeting logs and ML threads) should
give ample notice to folks and instructions on how to react.

Cheers,
Armando

[1]
https://review.openstack.org/#/q/status:open+message:%22NeutronLibImpact%22
[2]
https://review.openstack.org/#/q/status:merged+message:%22NeutronLibImpact%22


> I absolutely did not mean any kind of delaying or blocking a neutron or
> neutron-lib change.
>
> Thanks,
>  Neil
>
>
>
> On Thu, Nov 24, 2016 at 5:43 PM Kevin Benton  wrote:
>
>> Yeah, in this case I don't think it would have helped because it was
>> removing several things from neutron simultaneously. The only thing that
>> would have stopped that would have been jobs from all sub projects voting
>> on each neutron change.
>>
>> On Nov 24, 2016 10:02, "Armando M."  wrote:
>>
>>
>>
>> On 24 November 2016 at 05:27, Neil Jerram  wrote:
>>
>> But I think a periodic check for a Neutron/neutron-lib-using project
>> (such as networking-calico) would still be a decent way of catching such
>> issues, wouldn't it?
>>
>>
>> It depends, and it would. There are many factors at play, as Kevin
>> pointed out.
>>
>>
>>
>>
>> On Thu, Nov 24, 2016 at 12:58 AM Kevin Benton  wrote:
>>
>> The issue we had is different than breaking changes in neutron-lib. The
>> issue we are running into now is bumps in the road when we are removing
>> deprecated things from Neutron that other projects are still using even
>> though they should be using the neutron-lib version instead.
>>
>> On Wed, Nov 23, 2016 at 5:42 PM, Joshua Harlow 
>> wrote:
>>
>> A suggestion would also to setup something like the following:
>>
>> https://wiki.openstack.org/wiki/Oslo#Periodic
>>
>> Get the users of neutron lib being tested against the latest neutron lib
>> (at least nightly) and seeing if they will be borked by a new neutron lib
>> merge...
>>
>> http://status.openstack.org/openstack-health/#/?groupKey=
>> build_name=hour=-with-oslo
>>
>> Overall be careful with the APIs u expose and plan out how u will shift
>> users from the old API to the new API (without destroying the world during
>> that transition).
>>
>> My 3 cents :-P
>>
>> -Josh
>>
>>
>> Boden Russell wrote:
>>
>> I would encourage anyone working on neutron-lib related changes to have
>> a peek at the recently renovated contributing doc [1] if you haven't
>> already.
>>
>> In particular the 'Phase 4: Consume' section [2] provides some tips on
>> how we see this workflow playing out.
>>
>> Thanks
>>
>> [1]
>> https://github.com/openstack/neutron-lib/blob/master/doc/
>> source/contributing.rst
>> [2]
>> https://github.com/openstack/neutron-lib/blob/master/doc/
>> source/contributing.rst#phase-4-consume
>>
>>
>> On 11/23/16 12:39 PM, Armando M. wrote:
>>
>> Hi neutrinos,
>>
>> In the last few hours a couple of changes landed [1,2] that caused a bit
>> of a jam in the neutron subproject gates, as they overlapped with
>> another change [3] having impact on the subprojects.
>>
>> This is why it is important to communicate during team meetings and/or
>> ML that patches with potential impact are in flight in our review
>> pipeline, so that we do our best to coordinate the merge process without
>> shooting ourselves in the foot.
>>
>> To bring this back to sanity, I issued a temporary revert [4], so that
>> [5] can land undisturbed. After that, a double revert will be applied,
>> once subprojects have had the opportunity to deal with the aftermath of
>> the other breaking change [1,2] (e.g. [6,7]).
>>
>>  From now on, I'd strongly encourage people proposing/reviewing patches
>> with potential impact (any impact) to err on the side of caution, and
>> take the advised steps to ensure such situations don't happen in the
>> future.
>>
>> Thanks,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/397704/
>> [2] https://review.openstack.org/#/c/397037/
>> [3] https://review.openstack.org/#/c/386845/
>> [4] https://review.openstack.org/#/c/401377/
>> [5] https://review.openstack.org/#/q/topic:plugin-directory+status:open
>> [6] https://review.openstack.org/#/c/401263/
>> [7] https://review.openstack.org/#/c/401355/
>>
>>
>>

Re: [openstack-dev] [neutron] neutron-lib impact

2016-11-24 Thread Neil Jerram

To be clear, when I said 'catching such issues', what I meant was: 'letting
me know promptly that I now need to update networking-calico'.

I absolutely did not mean any kind of delaying or blocking a neutron or
neutron-lib change.

Thanks,
 Neil


On Thu, Nov 24, 2016 at 5:43 PM Kevin Benton  wrote:

> Yeah, in this case I don't think it would have helped because it was
> removing several things from neutron simultaneously. The only thing that
> would have stopped that would have been jobs from all sub projects voting
> on each neutron change.
>
> On Nov 24, 2016 10:02, "Armando M."  wrote:
>
>
>
> On 24 November 2016 at 05:27, Neil Jerram  wrote:
>
> But I think a periodic check for a Neutron/neutron-lib-using project (such
> as networking-calico) would still be a decent way of catching such issues,
> wouldn't it?
>
>
> It depends, and it would. There are many factors at play, as Kevin pointed
> out.
>
>
>
>
> On Thu, Nov 24, 2016 at 12:58 AM Kevin Benton  wrote:
>
> The issue we had is different than breaking changes in neutron-lib. The
> issue we are running into now is bumps in the road when we are removing
> deprecated things from Neutron that other projects are still using even
> though they should be using the neutron-lib version instead.
>
> On Wed, Nov 23, 2016 at 5:42 PM, Joshua Harlow 
> wrote:
>
> A suggestion would also to setup something like the following:
>
> https://wiki.openstack.org/wiki/Oslo#Periodic
>
> Get the users of neutron lib being tested against the latest neutron lib
> (at least nightly) and seeing if they will be borked by a new neutron lib
> merge...
>
>
> http://status.openstack.org/openstack-health/#/?groupKey=build_name=hour=-with-oslo
>
> Overall be careful with the APIs u expose and plan out how u will shift
> users from the old API to the new API (without destroying the world during
> that transition).
>
> My 3 cents :-P
>
> -Josh
>
>
> Boden Russell wrote:
>
> I would encourage anyone working on neutron-lib related changes to have
> a peek at the recently renovated contributing doc [1] if you haven't
> already.
>
> In particular the 'Phase 4: Consume' section [2] provides some tips on
> how we see this workflow playing out.
>
> Thanks
>
> [1]
>
> https://github.com/openstack/neutron-lib/blob/master/doc/source/contributing.rst
> [2]
>
> https://github.com/openstack/neutron-lib/blob/master/doc/source/contributing.rst#phase-4-consume
>
>
> On 11/23/16 12:39 PM, Armando M. wrote:
>
> Hi neutrinos,
>
> In the last few hours a couple of changes landed [1,2] that caused a bit
> of a jam in the neutron subproject gates, as they overlapped with
> another change [3] having impact on the subprojects.
>
> This is why it is important to communicate during team meetings and/or
> ML that patches with potential impact are in flight in our review
> pipeline, so that we do our best to coordinate the merge process without
> shooting ourselves in the foot.
>
> To bring this back to sanity, I issued a temporary revert [4], so that
> [5] can land undisturbed. After that, a double revert will be applied,
> once subprojects have had the opportunity to deal with the aftermath of
> the other breaking change [1,2] (e.g. [6,7]).
>
>  From now on, I'd strongly encourage people proposing/reviewing patches
> with potential impact (any impact) to err on the side of caution, and
> take the advised steps to ensure such situations don't happen in the
> future.
>
> Thanks,
> Armando
>
> [1] https://review.openstack.org/#/c/397704/
> [2] https://review.openstack.org/#/c/397037/
> [3] https://review.openstack.org/#/c/386845/
> [4] https://review.openstack.org/#/c/401377/
> [5] https://review.openstack.org/#/q/topic:plugin-directory+status:open
> [6] https://review.openstack.org/#/c/401263/
> [7] https://review.openstack.org/#/c/401355/
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>

Re: [openstack-dev] [neutron] neutron-lib impact

On 24 November 2016 at 09:41, Kevin Benton  wrote:

> Yeah, in this case I don't think it would have helped because it was
> removing several things from neutron simultaneously. The only thing that
> would have stopped that would have been jobs from all sub projects voting
> on each neutron change.
>

Right, and that's never gonna happen otherwise we might as well put all the
code back into one tree.

>
> On Nov 24, 2016 10:02, "Armando M."  wrote:
>
>>
>>
>> On 24 November 2016 at 05:27, Neil Jerram  wrote:
>>
>>> But I think a periodic check for a Neutron/neutron-lib-using project
>>> (such as networking-calico) would still be a decent way of catching such
>>> issues, wouldn't it?
>>>
>>
>> It depends, and it would. There are many factors at play, as Kevin
>> pointed out.
>>
>>
>>>
>>>
>>> On Thu, Nov 24, 2016 at 12:58 AM Kevin Benton  wrote:
>>>
 The issue we had is different than breaking changes in neutron-lib. The
 issue we are running into now is bumps in the road when we are removing
 deprecated things from Neutron that other projects are still using even
 though they should be using the neutron-lib version instead.

 On Wed, Nov 23, 2016 at 5:42 PM, Joshua Harlow 
 wrote:

 A suggestion would also to setup something like the following:

 https://wiki.openstack.org/wiki/Oslo#Periodic

 Get the users of neutron lib being tested against the latest neutron
 lib (at least nightly) and seeing if they will be borked by a new neutron
 lib merge...

 http://status.openstack.org/openstack-health/#/?groupKey=bui
 ld_name=hour=-with-oslo

 Overall be careful with the APIs u expose and plan out how u will shift
 users from the old API to the new API (without destroying the world during
 that transition).

 My 3 cents :-P

 -Josh

 Boden Russell wrote:

 I would encourage anyone working on neutron-lib related changes to have
 a peek at the recently renovated contributing doc [1] if you haven't
 already.

 In particular the 'Phase 4: Consume' section [2] provides some tips on
 how we see this workflow playing out.

 Thanks

 [1]
 https://github.com/openstack/neutron-lib/blob/master/doc/sou
 rce/contributing.rst
 [2]
 https://github.com/openstack/neutron-lib/blob/master/doc/sou
 rce/contributing.rst#phase-4-consume

 On 11/23/16 12:39 PM, Armando M. wrote:

 Hi neutrinos,

 In the last few hours a couple of changes landed [1,2] that caused a bit
 of a jam in the neutron subproject gates, as they overlapped with
 another change [3] having impact on the subprojects.

 This is why it is important to communicate during team meetings and/or
 ML that patches with potential impact are in flight in our review
 pipeline, so that we do our best to coordinate the merge process without
 shooting ourselves in the foot.

 To bring this back to sanity, I issued a temporary revert [4], so that
 [5] can land undisturbed. After that, a double revert will be applied,
 once subprojects have had the opportunity to deal with the aftermath of
 the other breaking change [1,2] (e.g. [6,7]).

  From now on, I'd strongly encourage people proposing/reviewing patches
 with potential impact (any impact) to err on the side of caution, and
 take the advised steps to ensure such situations don't happen in the
 future.

 Thanks,
 Armando

 [1] https://review.openstack.org/#/c/397704/
 [2] https://review.openstack.org/#/c/397037/
 [3] https://review.openstack.org/#/c/386845/
 [4] https://review.openstack.org/#/c/401377/
 [5] https://review.openstack.org/#/q/topic:plugin-directory+status:open
 [6] https://review.openstack.org/#/c/401263/
 [7] https://review.openstack.org/#/c/401355/

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

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

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

Re: [openstack-dev] [neutron] neutron-lib impact

2016-11-24 Thread Kevin Benton

Yeah, in this case I don't think it would have helped because it was
removing several things from neutron simultaneously. The only thing that
would have stopped that would have been jobs from all sub projects voting
on each neutron change.

On Nov 24, 2016 10:02, "Armando M."  wrote:

>
>
> On 24 November 2016 at 05:27, Neil Jerram  wrote:
>
>> But I think a periodic check for a Neutron/neutron-lib-using project
>> (such as networking-calico) would still be a decent way of catching such
>> issues, wouldn't it?
>>
>
> It depends, and it would. There are many factors at play, as Kevin pointed
> out.
>
>
>>
>>
>> On Thu, Nov 24, 2016 at 12:58 AM Kevin Benton  wrote:
>>
>>> The issue we had is different than breaking changes in neutron-lib. The
>>> issue we are running into now is bumps in the road when we are removing
>>> deprecated things from Neutron that other projects are still using even
>>> though they should be using the neutron-lib version instead.
>>>
>>> On Wed, Nov 23, 2016 at 5:42 PM, Joshua Harlow 
>>> wrote:
>>>
>>> A suggestion would also to setup something like the following:
>>>
>>> https://wiki.openstack.org/wiki/Oslo#Periodic
>>>
>>> Get the users of neutron lib being tested against the latest neutron lib
>>> (at least nightly) and seeing if they will be borked by a new neutron lib
>>> merge...
>>>
>>> http://status.openstack.org/openstack-health/#/?groupKey=bui
>>> ld_name=hour=-with-oslo
>>>
>>> Overall be careful with the APIs u expose and plan out how u will shift
>>> users from the old API to the new API (without destroying the world during
>>> that transition).
>>>
>>> My 3 cents :-P
>>>
>>> -Josh
>>>
>>>
>>> Boden Russell wrote:
>>>
>>> I would encourage anyone working on neutron-lib related changes to have
>>> a peek at the recently renovated contributing doc [1] if you haven't
>>> already.
>>>
>>> In particular the 'Phase 4: Consume' section [2] provides some tips on
>>> how we see this workflow playing out.
>>>
>>> Thanks
>>>
>>> [1]
>>> https://github.com/openstack/neutron-lib/blob/master/doc/sou
>>> rce/contributing.rst
>>> [2]
>>> https://github.com/openstack/neutron-lib/blob/master/doc/sou
>>> rce/contributing.rst#phase-4-consume
>>>
>>>
>>> On 11/23/16 12:39 PM, Armando M. wrote:
>>>
>>> Hi neutrinos,
>>>
>>> In the last few hours a couple of changes landed [1,2] that caused a bit
>>> of a jam in the neutron subproject gates, as they overlapped with
>>> another change [3] having impact on the subprojects.
>>>
>>> This is why it is important to communicate during team meetings and/or
>>> ML that patches with potential impact are in flight in our review
>>> pipeline, so that we do our best to coordinate the merge process without
>>> shooting ourselves in the foot.
>>>
>>> To bring this back to sanity, I issued a temporary revert [4], so that
>>> [5] can land undisturbed. After that, a double revert will be applied,
>>> once subprojects have had the opportunity to deal with the aftermath of
>>> the other breaking change [1,2] (e.g. [6,7]).
>>>
>>>  From now on, I'd strongly encourage people proposing/reviewing patches
>>> with potential impact (any impact) to err on the side of caution, and
>>> take the advised steps to ensure such situations don't happen in the
>>> future.
>>>
>>> Thanks,
>>> Armando
>>>
>>> [1] https://review.openstack.org/#/c/397704/
>>> [2] https://review.openstack.org/#/c/397037/
>>> [3] https://review.openstack.org/#/c/386845/
>>> [4] https://review.openstack.org/#/c/401377/
>>> [5] https://review.openstack.org/#/q/topic:plugin-directory+status:open
>>> [6] https://review.openstack.org/#/c/401263/
>>> [7] https://review.openstack.org/#/c/401355/
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>

Re: [openstack-dev] [neutron] stable/newton 'broken'

On 24 November 2016 at 02:38, Thierry Carrez  wrote:

> Gary Kotton wrote:
> > Please see - http://logs.openstack.org/82/401882/1/check/gate-vmware-
> nsx-python27-db-ubuntu-xenial/1ac0686/console.html#_2016-11-
> 24_06_58_38_520273
> > Here we are pulling trunk as there is no stable version to use
>
> Is neutron stable/newton really broken (like your subject seems to
> indicate) ? Or only vmware-nsx stable/newton ? Since networking-l2gw and
> tap-as-a-service are unofficial projects we can't guarantee that they
> will create branches that match the official stable ones, so we should
> try to avoid depending on them if possible...
>

This happens because the referenced projects have no newton branch and the
consuming project's stable newton was pulling from the master branch (and
[1] is the hack referenced below). The right fix would be to backport [2],
create the stable branches of the projects to which vmware-nsx depends on
and set the branch appropriately. This is what the neutron team does for
the projects we look after.

This breakage was waiting to happen, and it just did.

[1]
https://github.com/openstack/vmware-nsx/commit/9a455781e4db9fc360c3264b72c381c91dfa6a15
[2]
https://github.com/openstack/vmware-nsx/commit/a951f5f9299ffdce268c54dc427a71706b8e41da


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

On 24 November 2016 at 05:27, Neil Jerram  wrote:

> But I think a periodic check for a Neutron/neutron-lib-using project (such
> as networking-calico) would still be a decent way of catching such issues,
> wouldn't it?
>

It depends, and it would. There are many factors at play, as Kevin pointed
out.


>
>
> On Thu, Nov 24, 2016 at 12:58 AM Kevin Benton  wrote:
>
>> The issue we had is different than breaking changes in neutron-lib. The
>> issue we are running into now is bumps in the road when we are removing
>> deprecated things from Neutron that other projects are still using even
>> though they should be using the neutron-lib version instead.
>>
>> On Wed, Nov 23, 2016 at 5:42 PM, Joshua Harlow 
>> wrote:
>>
>> A suggestion would also to setup something like the following:
>>
>> https://wiki.openstack.org/wiki/Oslo#Periodic
>>
>> Get the users of neutron lib being tested against the latest neutron lib
>> (at least nightly) and seeing if they will be borked by a new neutron lib
>> merge...
>>
>> http://status.openstack.org/openstack-health/#/?groupKey=
>> build_name=hour=-with-oslo
>>
>> Overall be careful with the APIs u expose and plan out how u will shift
>> users from the old API to the new API (without destroying the world during
>> that transition).
>>
>> My 3 cents :-P
>>
>> -Josh
>>
>>
>> Boden Russell wrote:
>>
>> I would encourage anyone working on neutron-lib related changes to have
>> a peek at the recently renovated contributing doc [1] if you haven't
>> already.
>>
>> In particular the 'Phase 4: Consume' section [2] provides some tips on
>> how we see this workflow playing out.
>>
>> Thanks
>>
>> [1]
>> https://github.com/openstack/neutron-lib/blob/master/doc/
>> source/contributing.rst
>> [2]
>> https://github.com/openstack/neutron-lib/blob/master/doc/
>> source/contributing.rst#phase-4-consume
>>
>>
>> On 11/23/16 12:39 PM, Armando M. wrote:
>>
>> Hi neutrinos,
>>
>> In the last few hours a couple of changes landed [1,2] that caused a bit
>> of a jam in the neutron subproject gates, as they overlapped with
>> another change [3] having impact on the subprojects.
>>
>> This is why it is important to communicate during team meetings and/or
>> ML that patches with potential impact are in flight in our review
>> pipeline, so that we do our best to coordinate the merge process without
>> shooting ourselves in the foot.
>>
>> To bring this back to sanity, I issued a temporary revert [4], so that
>> [5] can land undisturbed. After that, a double revert will be applied,
>> once subprojects have had the opportunity to deal with the aftermath of
>> the other breaking change [1,2] (e.g. [6,7]).
>>
>>  From now on, I'd strongly encourage people proposing/reviewing patches
>> with potential impact (any impact) to err on the side of caution, and
>> take the advised steps to ensure such situations don't happen in the
>> future.
>>
>> Thanks,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/397704/
>> [2] https://review.openstack.org/#/c/397037/
>> [3] https://review.openstack.org/#/c/386845/
>> [4] https://review.openstack.org/#/c/401377/
>> [5] https://review.openstack.org/#/q/topic:plugin-directory+status:open
>> [6] https://review.openstack.org/#/c/401263/
>> [7] https://review.openstack.org/#/c/401355/
>>
>>
>> 
>> __
>> 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] [tripleo] CI scenarios design - how to add more services

2016-11-24 Thread Emilien Macchi

On Thu, Nov 24, 2016 at 11:08 AM, Juan Antonio Osorio
 wrote:
> I don't have a strong opinion about any option, as long as we have something
> in place I'm happy.
>
> But regarding option 1.A: what would be done for newton once these templates
> are moved to t-h-t. Would they be backported? What about mitaka?

Newton: yes: we'll have to backport
https://review.openstack.org/#/c/402119/ and that's it!
Mitaka: we never supported and ran scenarios, so no problem here.

I started a first iteration:
https://review.openstack.org/#/q/topic:tripleo-ci/scenarios

Feel free to review and give any feedback.
Thanks,

>
> On 24 Nov 2016 17:55, "Carlos Camacho Gonzalez"  wrote:
>>
>> I think would be cool to go with option, +1 to 1.A
>>
>> IMHO,
>> - Easier to read.
>> - Easier to maintain.
>> - We don't make backports, instead we guarantee backwards compatibility.
>> - We'll re-use experience from Puppet OpenStack CI.
>>
>> On Wed, Nov 23, 2016 at 10:13 PM, Giulio Fidente 
>> wrote:
>> > hi Emilien,
>> >
>> > thanks for putting some thought into this. We have a similar problem to
>> > test
>> > RGW which was only added in Newton.
>> >
>> >
>> > On 11/23/2016 03:02 AM, Emilien Macchi wrote:
>> >>
>> >> == Context
>> >>
>> >> In Newton we added new multinode jobs called "scenarios".
>> >> The challenged we tried to solve was "how to test the maximum of
>> >> services without overloading the nodes that run tests".
>> >>
>> >> Each scenarios deploys a set of services, which allows us to
>> >> horizontally scale the number of scenarios to increase the service
>> >> testing coverage.
>> >> See the result here:
>> >> https://github.com/openstack-infra/tripleo-ci#service-testing-matrix
>> >>
>> >> To implement this model, we took example of Puppet OpenStack CI:
>> >> https://github.com/openstack/puppet-openstack-integration#description
>> >> We even tried to keep consistent the services/scenarios relations, so
>> >> it's consistent and easier to maintain.
>> >>
>> >> Everything was fine until we had to add new services during Ocata
>> >> cycles.
>> >> Because tripleo-ci repository is not branched, adding Barbican service
>> >> in the TripleO environment for scenario002 would break Newton CI jobs.
>> >> During my vacations, the team created a new scenario, scenario004,
>> >> that deploys Barbican and that is only run for Ocata jobs.
>> >> I don't think we should proceed this way, and let me explain why.
>> >>
>> >> == Problem
>> >>
>> >> How to scale the number of services that we test without increasing
>> >> the number of scenarios and therefore the complexity of maintaining
>> >> them on long-term.
>> >>
>> >>
>> >> == Solutions
>> >>
>> >> The list is not exhaustive, feel free to add more.
>> >>
>> >> 1) Re-use experience from Puppet OpenStack CI and have environments
>> >> that are in a branched repository.
>> >> environments.
>> >> In Puppet OpenStack CI, the repository that deploys environments
>> >> (puppet-openstack-integration) is branched. So if puppet-barbican is
>> >> ready to be tested in Ocata, we'll patch
>> >> puppet-openstack-integration/master to start testing it and it won't
>> >> break stable jobs.
>> >> Like this, we were successfully able to maintain a fair number of
>> >> scenarios and keep our coverage increasing over each cycle.
>> >>
>> >> I see 2 sub-options here:
>> >>
>> >> a) Move CI environments and pingtest into
>> >> tripleo-heat-templates/environments/ci/(scenarios|pingtest). This repo
>> >> is branched and we could add a README to explain these files are used
>> >> in CI and we don't guarantee they would work outside TripleO CI tools.
>> >> b) Branch tripleo-ci repository. Personally I don't like this solution
>> >> because a lot of patches in this repo are not related to OpenStack
>> >> versions, which means we would need to backport most of the things
>> >> from master.
>> >
>> >
>> > I'd +1 this idea. It sounds like we could make the scenarios generic
>> > enough
>> > to be usable also outside CI? Maybe they can serve as samples?
>> > --
>> > Giulio Fidente
>> > GPG KEY: 08D733BA
>> >
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>

Re: [openstack-dev] [heat][sahara][magnum][tripleo] Scaling nested stack validation

2016-11-24 Thread Thomas Herve

On Wed, Nov 23, 2016 at 11:58 PM, Zane Bitter  wrote:
> We discussed $SUBJECT at the summit as one of the main performance problems
> that people are running into when trying to create very large autoscaling
> groups, as projects like Sahara, Magnum, TripleO, OpenShift are wont to do.
> Of course, as we all know, validation happens synchronously, so it's prone
> to causing RPC timeouts that mean a hard failure of the parent stack.
>
> First the good news - I just committed this patch:
>
> https://review.openstack.org/#/c/400961/
>
> which should mean from now on that resources with identical definitions will
> not all be validated, and instead we'll just validate one representative
> one. In theory this should mean that autoscaling groups should now validate
> in constant rather than linear time. If anyone from one of the affected
> projects is able to confirm this, then I'd be happy to backport the patch to
> stable/newton. It really is very simple.
>
> The bad news here is for users of ResourceGroups with %index% substitution
> (*cough*TripleO*cough*) - this makes each resource definition unique, so it
> won't benefit from this fix. (Adding this to my mental list of reasons why
> index substitution is bad.)
>
>
> I also investigated another issue, which is that since the fix for
> https://bugs.launchpad.net/heat/+bug/1388140 landed (in Kilo) I believe we
> are validating nested stacks multiple times (specifically, m times, where m
> is the stack's depth in the tree):
>
>   root childgrandchild
>
>   create
>-> validate --> validate --> validate
>-> Resource.create ===> create
> -> validate --> validate
> -> Resource.create ===> create
>  -> validate
>
> The only good news here is that ResourceGroup is smart enough to make sure
> that it generates a nested stack with at most 1 resource to validate when
> validate() is called. (However, when the nested stack is created, and thus
> validated, it is of course full-sized.) Autoscaling groups make no such
> allowances, but the patch above should actually have the same effect. (We
> can't get rid of the special case for ResourceGroup though, because of index
> substitution.)
>
> An obvious fix would be to disable validation - or, more specifically,
> validation of _resources_ - on create/update for stacks that have a non-null
> owner_id (i.e. nested stacks), so that we had something like:
>
>   root childgrandchild
>
>   create
>-> validate --> validate --> validate
>-> Resource.create ===> create
> -> Resource.create ===> create
>
> That would eliminate the duplication/triplication/multiplication of
> validation. It would also mean that we'd cut out the expensive part of
> ResourceGroup validation with index substitution, leaving only the cheap
> part.
>
> One downside is that in the ResourceGroup/index substitution case we'd be
> creating resources whose definitions hadn't _ever_ been validated. I _think_
> that's safe, in the sense that you'd just hear about errors later, as
> opposed to everything falling over in a heap, but it's difficult to be
> certain. Hearing about problems late is also not ideal (since it may cause
> otherwise-healthy siblings to be cancelled), but I would guess that heavy
> users like TripleO developers would say that it's worth the tradeoff.
>
> However, one other thing about this bothers me. The part of validation that
> we're keeping:
>
>-> validate --> validate --> validate
>
> involves loading all of the nested stacks in memory at once (i.e. the thing
> we were not supposed to be doing any more in Kilo, in favour of farming
> nested stacks out over RPC.) As we discovered when we found out we were
> doing the same thing with outputs[1], this is a bit like hanging out a giant
> "Kick Me" sign for the OOM Killer.
>
> That's mitigated quite a lot by my patch though... we'll load the whole
> autoscaling group stack in memory, but if its members are themselves nested
> stacks we'll load only one of them. So the scaling tendencies will hopefully
> be dominated by the complexity of your templates more than than the size of
> your deployment. ResourceGroup is in a better position, because its nested
> stack will actually have only one member, so the size shouldn't affect
> memory consumption at all during validation.
>
> Some options:
> 1) Chalk it up to an acceptable tradeoff
> 2) Add a single-member special case for autoscaling group validation
> 3) Farm out the nested validation over RPC
> 4) Both (2) & (3)
> 5) Some totally different arrangement of how nested stacks are validated

I think I'd like to see what difference 3 makes. Maybe then also do 2.
Again, we really need to have some reproducible big template that

Re: [openstack-dev] [neutron] stable/newton 'broken'

I have worked around the issue by pegging the l2gw and tap-aas to specific
commits.
This is a hack at the moment and will update as soon as the branches are cut.

Thanks and happy holidays

On 11/24/16, 4:11 PM, "Gary Kotton" wrote:

On 11/24/16, 12:38 PM, "Thierry Carrez" wrote:

Gary Kotton wrote:
> Please see -
http://logs.openstack.org/82/401882/1/check/gate-vmware-nsx-python27-db-ubuntu-xenial/1ac0686/console.html#_2016-11-24_06_58_38_520273
> Here we are pulling trunk as there is no stable version to use

Is neutron stable/newton really broken (like your subject seems to
indicate) ? Or only vmware-nsx stable/newton ? Since networking-l2gw and
tap-as-a-service are unofficial projects we can't guarantee that they
will create branches that match the official stable ones, so we should
try to avoid depending on them if possible...

[Gary] I Know that the vmware_nsx and midonet are broken. Until a few weeks
ago the l2gw project was part of the big tent/stadium and it was removed. That
was in trunk, but until then we had an obligation to have this working in
stable/newton.
In order for us to be able to work with and consume community feature we
need to have links to this project. So at the moment we are between a rock and
a hard place.

I think that the tap-as-a-service is creating a tech preview branch. Which
will solve the issues

For L2GW the community has people using this stuff in production … So we
just need to make sure that they do not upgrade to newton.

--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [tripleo] CI scenarios design - how to add more services

2016-11-24 Thread Juan Antonio Osorio

I don't have a strong opinion about any option, as long as we have
something in place I'm happy.

But regarding option 1.A: what would be done for newton once these
templates are moved to t-h-t. Would they be backported? What about mitaka?

On 24 Nov 2016 17:55, "Carlos Camacho Gonzalez"  wrote:

> I think would be cool to go with option, +1 to 1.A
>
> IMHO,
> - Easier to read.
> - Easier to maintain.
> - We don't make backports, instead we guarantee backwards compatibility.
> - We'll re-use experience from Puppet OpenStack CI.
>
> On Wed, Nov 23, 2016 at 10:13 PM, Giulio Fidente 
> wrote:
> > hi Emilien,
> >
> > thanks for putting some thought into this. We have a similar problem to
> test
> > RGW which was only added in Newton.
> >
> >
> > On 11/23/2016 03:02 AM, Emilien Macchi wrote:
> >>
> >> == Context
> >>
> >> In Newton we added new multinode jobs called "scenarios".
> >> The challenged we tried to solve was "how to test the maximum of
> >> services without overloading the nodes that run tests".
> >>
> >> Each scenarios deploys a set of services, which allows us to
> >> horizontally scale the number of scenarios to increase the service
> >> testing coverage.
> >> See the result here:
> >> https://github.com/openstack-infra/tripleo-ci#service-testing-matrix
> >>
> >> To implement this model, we took example of Puppet OpenStack CI:
> >> https://github.com/openstack/puppet-openstack-integration#description
> >> We even tried to keep consistent the services/scenarios relations, so
> >> it's consistent and easier to maintain.
> >>
> >> Everything was fine until we had to add new services during Ocata
> cycles.
> >> Because tripleo-ci repository is not branched, adding Barbican service
> >> in the TripleO environment for scenario002 would break Newton CI jobs.
> >> During my vacations, the team created a new scenario, scenario004,
> >> that deploys Barbican and that is only run for Ocata jobs.
> >> I don't think we should proceed this way, and let me explain why.
> >>
> >> == Problem
> >>
> >> How to scale the number of services that we test without increasing
> >> the number of scenarios and therefore the complexity of maintaining
> >> them on long-term.
> >>
> >>
> >> == Solutions
> >>
> >> The list is not exhaustive, feel free to add more.
> >>
> >> 1) Re-use experience from Puppet OpenStack CI and have environments
> >> that are in a branched repository.
> >> environments.
> >> In Puppet OpenStack CI, the repository that deploys environments
> >> (puppet-openstack-integration) is branched. So if puppet-barbican is
> >> ready to be tested in Ocata, we'll patch
> >> puppet-openstack-integration/master to start testing it and it won't
> >> break stable jobs.
> >> Like this, we were successfully able to maintain a fair number of
> >> scenarios and keep our coverage increasing over each cycle.
> >>
> >> I see 2 sub-options here:
> >>
> >> a) Move CI environments and pingtest into
> >> tripleo-heat-templates/environments/ci/(scenarios|pingtest). This repo
> >> is branched and we could add a README to explain these files are used
> >> in CI and we don't guarantee they would work outside TripleO CI tools.
> >> b) Branch tripleo-ci repository. Personally I don't like this solution
> >> because a lot of patches in this repo are not related to OpenStack
> >> versions, which means we would need to backport most of the things
> >> from master.
> >
> >
> > I'd +1 this idea. It sounds like we could make the scenarios generic
> enough
> > to be usable also outside CI? Maybe they can serve as samples?
> > --
> > Giulio Fidente
> > GPG KEY: 08D733BA
> >
> >
> > 
> __
> > 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] [Performance][shaker]

2016-11-24 Thread Matthieu Simonin

Hi Ilya, 

Thanks for your answer, let me know your findings.
In any case I'll be glad to help if needed.

Matt

ps : I just realized that I missed a proper subjet to the thread :(.
If this thread continue it's maybe better to change that.

- Mail original -
> De: "Ilya Shakhat" 
> À: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Envoyé: Jeudi 24 Novembre 2016 13:03:33
> Objet: Re: [openstack-dev] [Performance][shaker]
> 
> Hi Matt,
> 
> Out of the box Shaker doesn't support such topology.
> It shouldn't be hard to implement though. Let me check what needs to be
> done.
> 
> Thanks,
> Ilya
> 
> 2016-11-24 13:49 GMT+03:00 Matthieu Simonin :
> 
> > Hello,
> >
> > I'm looking to shaker capabilities and I'm wondering if this kind
> > of accomodation (see attachment also) can be achieved
> >
> > Ascii (flat) version :
> >
> > CN1 (2n VMs) <- n flows -> CN2 (2n VMs)
> > CN1 (2n VMs) <- n flows -> CN3 (2n VMs)
> > CN2 (2n VMs) <- n flows -> CN3 (2n VMs)
> >
> > In this situation concurrency could be mapped to the number of
> > simultaneous flows in use per link.
> >
> > Best,
> >
> > 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 Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

Re: [openstack-dev] [tripleo] CI scenarios design - how to add more services

2016-11-24 Thread Carlos Camacho Gonzalez

I think would be cool to go with option, +1 to 1.A

IMHO,
- Easier to read.
- Easier to maintain.
- We don't make backports, instead we guarantee backwards compatibility.
- We'll re-use experience from Puppet OpenStack CI.

On Wed, Nov 23, 2016 at 10:13 PM, Giulio Fidente  wrote:
> hi Emilien,
>
> thanks for putting some thought into this. We have a similar problem to test
> RGW which was only added in Newton.
>
>
> On 11/23/2016 03:02 AM, Emilien Macchi wrote:
>>
>> == Context
>>
>> In Newton we added new multinode jobs called "scenarios".
>> The challenged we tried to solve was "how to test the maximum of
>> services without overloading the nodes that run tests".
>>
>> Each scenarios deploys a set of services, which allows us to
>> horizontally scale the number of scenarios to increase the service
>> testing coverage.
>> See the result here:
>> https://github.com/openstack-infra/tripleo-ci#service-testing-matrix
>>
>> To implement this model, we took example of Puppet OpenStack CI:
>> https://github.com/openstack/puppet-openstack-integration#description
>> We even tried to keep consistent the services/scenarios relations, so
>> it's consistent and easier to maintain.
>>
>> Everything was fine until we had to add new services during Ocata cycles.
>> Because tripleo-ci repository is not branched, adding Barbican service
>> in the TripleO environment for scenario002 would break Newton CI jobs.
>> During my vacations, the team created a new scenario, scenario004,
>> that deploys Barbican and that is only run for Ocata jobs.
>> I don't think we should proceed this way, and let me explain why.
>>
>> == Problem
>>
>> How to scale the number of services that we test without increasing
>> the number of scenarios and therefore the complexity of maintaining
>> them on long-term.
>>
>>
>> == Solutions
>>
>> The list is not exhaustive, feel free to add more.
>>
>> 1) Re-use experience from Puppet OpenStack CI and have environments
>> that are in a branched repository.
>> environments.
>> In Puppet OpenStack CI, the repository that deploys environments
>> (puppet-openstack-integration) is branched. So if puppet-barbican is
>> ready to be tested in Ocata, we'll patch
>> puppet-openstack-integration/master to start testing it and it won't
>> break stable jobs.
>> Like this, we were successfully able to maintain a fair number of
>> scenarios and keep our coverage increasing over each cycle.
>>
>> I see 2 sub-options here:
>>
>> a) Move CI environments and pingtest into
>> tripleo-heat-templates/environments/ci/(scenarios|pingtest). This repo
>> is branched and we could add a README to explain these files are used
>> in CI and we don't guarantee they would work outside TripleO CI tools.
>> b) Branch tripleo-ci repository. Personally I don't like this solution
>> because a lot of patches in this repo are not related to OpenStack
>> versions, which means we would need to backport most of the things
>> from master.
>
>
> I'd +1 this idea. It sounds like we could make the scenarios generic enough
> to be usable also outside CI? Maybe they can serve as samples?
> --
> Giulio Fidente
> GPG KEY: 08D733BA
>
>
> __
> 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] [vitrage] about aodh alarm notification

2016-11-24 Thread Weyl, Alexey (Nokia - IL)

It seems that you will need to have a cache for that issue.
Due to the fact that AODH alarms aren’t deleted, and stay alive (in AODH) when 
their state is changed to ok (but in this case aren’t supposed to appear in 
Vitrage), and then when the state is changed back to error (‘alarm’) they are 
supposed to appear in Vitrage with all the data, the most simple way to do that 
(without touching the core processor and architecture) is by saving those 
alarms of AODH in cache in the AODH driver, update its data every change that 
arrive to the driver, and then when a notification arrives and if the state 
that arrived is different than OK and the state that was in the cache is OK 
then send an event with all the data updated in the cache to the queue, 
otherwise send only the data received from the oslo bus to the queue (don’t 
forget of course to update the cache each time an event received, and each time 
we call the get_all of aodh (every snapshot_interval time) we can update the 
data in the cache as well.

Alexey

From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn]
Sent: Thursday, November 24, 2016 11:24 AM
To: Weyl, Alexey (Nokia - IL)
Cc: Hefetz, Idan (Nokia - IL); Afek, Ifat (Nokia - IL); 
openstack-dev@lists.openstack.org; zhang.yuj...@zte.com.cn
Subject: 答复: RE: [openstack-dev] [vitrage] about aodh alarm notification


Hi Weyl Alexey,

Another question:
If we received the alarm.creation notification with the 'ok' state, we filter 
it and don't create vertex in the Graph.
The next received the alarm state_change notification, all the other alarm 
details are missing in the vertex.
How can I handle this? Thanks~


BR,
dwj





"Weyl, Alexey (Nokia - IL)" 
>

2016-11-24 16:25

收件人

"dong.wenj...@zte.com.cn" 
>, "Afek, Ifat (Nokia - 
IL)" >, "Hefetz, Idan (Nokia - 
IL)" >, 
"zhang.yuj...@zte.com.cn" 
>

抄送

"openstack-dev@lists.openstack.org" 
>

主题

RE: [openstack-dev] [vitrage] about aodh alarm notification







Hi Dong,

Good question, I will explain how you can handle this problem in Vitrage.

You don't need the cache mechanism here, it is much more simplier.

When you get a new alarm with get_all or by notification of 'alarm.creation' 
you will create the alarm with its correct data \ properties.
Then when you receive a notification of 'alarm.rule_change', 
'alarm.state_transition', 'alarm.deletion' all you need to do is only to update 
the correct property that has changed in the aodh vertex.
Thus, When you create the Vertex in the transformer, you know the aodh uuid so 
you know the vitrage_id, and you can pass only the properties that you have 
received and want to update (and not all the properties that there in the aodh 
vertex). All the other properties that you haven't received that haven't 
changed you can pass them as None and they won't be changed in the graph.

Hope this explains everything.
If you have other questions, you are more than welcome to ask.

Best Regrads,
Alexey


From: dong.wenj...@zte.com.cn 
[mailto:dong.wenj...@zte.com.cn]
Sent: Thursday, November 24, 2016 9:39 AM
To: Afek, Ifat (Nokia - IL); Weyl, Alexey (Nokia - IL); Hefetz, Idan (Nokia - 
IL); zhang.yuj...@zte.com.cn
Cc: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [vitrage] about aodh alarm notification


Hi Vitrages,

Currently there are four aodh alarm notifications we need to handle:
'alarm.creation', 'alarm.rule_change', 'alarm.state_transition', 
'alarm.deletion'

Only the alarm.creation notification carries the alarm detail info.
So we need to cache the alarm info.
When we receive other notifications, we can fill all fields from the cache.

But if the alarm creates before vitrage servies startup, we can't get the 
alarm.creation notification.
So we need to get_all when vitrage services startup.
As `SnapshotsService` will get all alarms info when it startup.
But `SnapshotsService` and `ListenerService` are two services,
they can't share the cache data unless they communicate with each other.
This wil be a big change.

Are there any other better solutions? I need some help, thanks :)

BR,
dwj
__
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][neutron] DHCP agent: advertise SLAAC prefixes Exceptions

This is also a latest dnsmask for uname -a
Linux cloudx-24.rdmz.labs.mlnx 3.10.0-327.el7.x86_64 #1 SMP Thu Oct 29 17:29:29 
EDT 2015 x86_64 x86_64 x86_64 GNU/Linux
bash-4.2$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.2 (Maipo)

#neutron-sanity-check  --config-file /etc/neutron/neutron.conf --config-file 
/etc/neutron/dhcp_agent.ini
Guru meditation now registers SIGUSR1 and SIGUSR2 by default for backward 
compatibility. SIGUSR1 will no longer be registered in a future release, so 
please use SIGUSR2 to generate reports.
2016-11-24 17:17:06.623 17608 INFO neutron.common.config [-] Logging enabled!
2016-11-24 17:17:06.623 17608 INFO neutron.common.config [-] 
/usr/bin/neutron-sanity-check version 10.0.0.0b2.dev118
2016-11-24 17:17:08.479 INFO oslo_rootwrap.client [-] Spawned new rootwrap 
daemon process with pid=17621
2016-11-24 17:17:08.580 INFO neutron.agent.ovsdb.native.vlog [-] 
tcp:127.0.0.1:6640: connecting...
2016-11-24 17:17:08.580 INFO neutron.agent.ovsdb.native.vlog [-] 
tcp:127.0.0.1:6640: connected
2016-11-24 17:17:09.296 ERROR neutron.cmd.sanity_check [-] The installed 
version of dnsmasq is too old. Please update to at least version 2.67.
2016-11-24 17:17:09.298 INFO oslo_rootwrap.client [-] Stopping rootwrap daemon 
process with pid=17621

> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: Thursday, November 24, 2016 4:41 PM
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> Subject: Re: [openstack-dev] [openstack][neutron] DHCP agent: advertise SLAAC
> prefixes Exceptions
> 
> 
> > On 24 Nov 2016, at 15:31, Jens Rosenboom  wrote:
> >
> > 2016-11-24 15:08 GMT+01:00 Lenny Verkhovsky :
> >> Hi,
> >>
> >> The DHCP Agent commit[1] added a lot of exceptions into Mellanox CI
> >
> > What OS is the CI running on? Can you show the output of "dnsmasq
> > --version" and "neutron-sanity-check" on a CI node?
> 
> I think you need to pass --config-file /etc/neutron/neutron.conf --config-file
> /etc/neutron/dhcp_agent.ini to the tool to make it trigger the dnsmasq version
> check you probably expect to fail.
> 
> That said, I believe that check should be removed:
> https://review.openstack.org/#/c/402003/
> 
> Ihar
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
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][neutron] DHCP agent: advertise SLAAC prefixes Exceptions


> On 24 Nov 2016, at 15:31, Jens Rosenboom  wrote:
> 
> 2016-11-24 15:08 GMT+01:00 Lenny Verkhovsky :
>> Hi,
>> 
>> The DHCP Agent commit[1] added a lot of exceptions into Mellanox CI
> 
> What OS is the CI running on? Can you show the output of "dnsmasq
> --version" and "neutron-sanity-check" on a CI node?

I think you need to pass --config-file /etc/neutron/neutron.conf --config-file 
/etc/neutron/dhcp_agent.ini to the tool to make it trigger the dnsmasq version 
check you probably expect to fail.

That said, I believe that check should be removed: 
https://review.openstack.org/#/c/402003/

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

Re: [openstack-dev] [openstack][neutron] DHCP agent: advertise SLAAC prefixes Exceptions

RH7.2

#dnsmasq --version
Dnsmasq version 2.66  Copyright (c) 2000-2013 Simon Kelley
Compile time options: IPv6 GNU-getopt DBus no-i18n IDN DHCP DHCPv6 no-Lua TFTP 
no-conntrack ipset auth
This software comes with ABSOLUTELY NO WARRANTY.
Dnsmasq is free software, and you are welcome to redistribute it
under the terms of the GNU General Public License, version 2 or 3.

#neutron-sanity-check
Guru meditation now registers SIGUSR1 and SIGUSR2 by default for backward 
compatibility. SIGUSR1 will no longer be registered in a future release, so 
please use SIGUSR2 to generate reports.
2016-11-24 16:37:39.512 17367 INFO neutron.common.config [-] Logging enabled!
2016-11-24 16:37:39.513 17367 INFO neutron.common.config [-] 
/usr/bin/neutron-sanity-check version 10.0.0.0b2.dev118


> -Original Message-
> From: Jens Rosenboom [mailto:j.rosenb...@x-ion.de]
> Sent: Thursday, November 24, 2016 4:32 PM
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> Subject: Re: [openstack-dev] [openstack][neutron] DHCP agent: advertise SLAAC
> prefixes Exceptions
> 
> 2016-11-24 15:08 GMT+01:00 Lenny Verkhovsky :
> > Hi,
> >
> > The DHCP Agent commit[1] added a lot of exceptions into Mellanox CI
> 
> What OS is the CI running on? Can you show the output of "dnsmasq --version"
> and "neutron-sanity-check" on a CI node?
> 
> 
> __
> 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] [Rally][all] Gitter as an alternative way for communication

2016-11-24 Thread Luigi Toscano

On Thursday, 24 November 2016 16:20:32 CET Andrey Kurilin wrote:
> Hi folks!
> 
> I'm happy to announce our new chats at gitter.im :
> 
> - https://gitter.im/rally-dev/Lobby  # main chat for regular
> communication
> - https://gitter.im/rally-dev/statuses  # chat for gerrit notifications
> 
> These chats are configured with a simple bot which syncs messages between
> Gitter and IRC, so we do not plan to abandon our #openstack-rally Freenode
> channel and you can choose the best messenger for yourself.
> 
> Long story:
> I had a talk with several guys some time ago and they mentioned that IRC is
> not convenient for them enough, even with modern clients like IRCCloud (it
> is not an advertisement:) ). Also, this topic was raised at Rally work
> session at Barcelona and we discussed it at our weekly meetings too.

Do you know that matrix.org allows you to access all freenode channels? (see 
also the riot.im client)

-- 
Luigi

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

Re: [openstack-dev] [openstack][neutron] DHCP agent: advertise SLAAC prefixes Exceptions

2016-11-24 Thread Jens Rosenboom

2016-11-24 15:08 GMT+01:00 Lenny Verkhovsky :
> Hi,
>
> The DHCP Agent commit[1] added a lot of exceptions into Mellanox CI

What OS is the CI running on? Can you show the output of "dnsmasq
--version" and "neutron-sanity-check" on a CI node?

__
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][neutron] DHCP agent: advertise SLAAC prefixes Exceptions

+1 – we need to figure out if this flag is supported by specific dnsmasq 
versions

On 11/24/16, 4:15 PM, "Ihar Hrachyshka"  wrote:


> On 24 Nov 2016, at 15:08, Lenny Verkhovsky  wrote:
> 
> Hi,
> The DHCP Agent commit[1] added a lot of exceptions into Mellanox CI
>  
>  
> [1] https://review.openstack.org/#/c/393007/

We probably revert the patch: https://review.openstack.org/#/c/401985/

Ihar

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


__
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][neutron] DHCP agent: advertise SLAAC prefixes Exceptions

10x


> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: Thursday, November 24, 2016 4:16 PM
> To: OpenStack Development Mailing List (not for usage questions)  d...@lists.openstack.org>
> Subject: Re: [openstack-dev] [openstack][neutron] DHCP agent: advertise SLAAC
> prefixes Exceptions
> 
> 
> > On 24 Nov 2016, at 15:08, Lenny Verkhovsky  wrote:
> >
> > Hi,
> > The DHCP Agent commit[1] added a lot of exceptions into Mellanox CI
> >
> >
> > [1] https://review.openstack.org/#/c/393007/
> 
> We probably revert the patch: https://review.openstack.org/#/c/401985/
> 
> Ihar
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
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] [Rally][all] Gitter as an alternative way for communication

2016-11-24 Thread Andrey Kurilin

Hi folks!

I'm happy to announce our new chats at gitter.im :

- https://gitter.im/rally-dev/Lobby  # main chat for regular
communication
- https://gitter.im/rally-dev/statuses  # chat for gerrit notifications

These chats are configured with a simple bot which syncs messages between
Gitter and IRC, so we do not plan to abandon our #openstack-rally Freenode
channel and you can choose the best messenger for yourself.

Long story:
I had a talk with several guys some time ago and they mentioned that IRC is
not convenient for them enough, even with modern clients like IRCCloud (it
is not an advertisement:) ). Also, this topic was raised at Rally work
session at Barcelona and we discussed it at our weekly meetings too.

Why Gitter?
Gitter is a free service from GitHub, so you can use you GitHub account for
authentication (everyone has GitHub account) or you can use your twitter
account. It provides convenient chats with avatars, quoting, markdown and
etc. You do not need an invitation for join us - just go to
https://gitter.im/rally-dev/Lobby and push "join room" button.
Also, if you want, you can use Gitter IRC tunnel (actually, you do not need
it, you can continue use #openstack-rally Freenode channel).

Why not slack?
Slack is good enough and it is used by another big community - Kubernetes,
but, imho, it has at least several limitations: you need to be invited for
joining "organization"; the way of switching between organizations are not
good enough.

-- 
Best regards,
Andrey Kurilin.
__
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][neutron] DHCP agent: advertise SLAAC prefixes Exceptions


> On 24 Nov 2016, at 15:08, Lenny Verkhovsky  wrote:
> 
> Hi,
> The DHCP Agent commit[1] added a lot of exceptions into Mellanox CI
>  
>  
> [1] https://review.openstack.org/#/c/393007/

We probably revert the patch: https://review.openstack.org/#/c/401985/

Ihar

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

Re: [openstack-dev] [neutron] stable/newton 'broken'

On 11/24/16, 12:38 PM, "Thierry Carrez" wrote:

[Gary] I Know that the vmware_nsx and midonet are broken. Until a few weeks ago
the l2gw project was part of the big tent/stadium and it was removed. That was
in trunk, but until then we had an obligation to have this working in
stable/newton.
In order for us to be able to work with and consume community feature we need
to have links to this project. So at the moment we are between a rock and a
hard place.

I think that the tap-as-a-service is creating a tech preview branch. Which will
solve the issues

For L2GW the community has people using this stuff in production … So we just
need to make sure that they do not upgrade to newton.

--
Thierry Carrez (ttx)

[openstack-dev] [openstack][neutron] DHCP agent: advertise SLAAC prefixes Exceptions

Hi,
The DHCP Agent commit[1] added a lot of exceptions into Mellanox CI


[1] https://review.openstack.org/#/c/393007/
[2]  
http://13.69.151.247/41/346041/24/check-cinder/Cinder-ISER-ISCSI/ec78a29/logs/q-dhcp.log.gz

[3] 2016-11-23 06:37:49.950 28150 DEBUG neutron.agent.linux.utils 
[req-ec66fd16-7b36-4afe-8969-ca7b931abd82 - -] Running command (rootwrap 
daemon): ['ip', 'netns', 'exec', 'qdhcp-cffeeda9-94b5-41bf-998e-d87c7a3a25a1', 
'dnsmasq', '--no-hosts', '', '--strict-order', '--except-interface=lo', 
'--pid-file=/opt/stack/data/neutron/dhcp/cffeeda9-94b5-41bf-998e-d87c7a3a25a1/pid',
 
'--dhcp-hostsfile=/opt/stack/data/neutron/dhcp/cffeeda9-94b5-41bf-998e-d87c7a3a25a1/host',
 
'--addn-hosts=/opt/stack/data/neutron/dhcp/cffeeda9-94b5-41bf-998e-d87c7a3a25a1/addn_hosts',
 
'--dhcp-optsfile=/opt/stack/data/neutron/dhcp/cffeeda9-94b5-41bf-998e-d87c7a3a25a1/opts',
 
'--dhcp-leasefile=/opt/stack/data/neutron/dhcp/cffeeda9-94b5-41bf-998e-d87c7a3a25a1/leases',
 '--dhcp-match=set:ipxe,175', '--enable-ra', '--ra-param=tapf5c8ccfc-b4,0,0', 
'--bind-interfaces', '--interface=tapf5c8ccfc-b4', 
'--dhcp-range=set:tag0,172.0.0.0,static,86400s', 
'--dhcp-option-force=option:mtu,1500', '--dhcp-lease-max=64', '--conf-file=', 
'--domain=openstacklocal'] execute_rootwrap_daemon 
/opt/stack/neutron/neutron/agent/linux/utils.py:108

2016-11-23 06:37:49.979 28150 ERROR neutron.agent.linux.utils 
[req-ec66fd16-7b36-4afe-8969-ca7b931abd82 - -] Exit code: 1; Stdin: ; Stdout: ; 
Stderr:

dnsmasq: bad command line options: try --help



2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent 
[req-ec66fd16-7b36-4afe-8969-ca7b931abd82 - -] Unable to enable dhcp for 
cffeeda9-94b5-41bf-998e-d87c7a3a25a1.

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent Traceback (most 
recent call last):

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/dhcp/agent.py", line 115, in call_driver

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent 
getattr(driver, action)(**action_kwargs)

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 216, in enable

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent 
self.spawn_process()

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 437, in spawn_process

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent 
self._spawn_or_reload_process(reload_with_HUP=False)

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 451, in 
_spawn_or_reload_process

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent 
pm.enable(reload_cfg=reload_with_HUP)

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/linux/external_process.py", line 94, in enable

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent 
run_as_root=self.run_as_root)

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/linux/ip_lib.py", line 882, in execute

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent 
log_fail_as_error=log_fail_as_error, **kwargs)

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/linux/utils.py", line 147, in execute

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent raise 
ProcessExecutionError(msg, returncode=returncode)

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent 
ProcessExecutionError: Exit code: 1; Stdin: ; Stdout: ; Stderr:

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent dnsmasq: bad 
command line options: try --help

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent

2016-11-23 06:37:49.980 28150 ERROR neutron.agent.dhcp.agent

Please advice
Lenny.
__
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] [telemetry] PostgreSQL gate broken

2016-11-24 Thread Chris Friesen


On 11/24/2016 05:57 AM, Julien Danjou wrote:

Hi,

It seems Nova broke its PostgreSQL support recently, and that impacts
Telemetry as we do gate on PostgreSQL. I opened a bug:

   https://bugs.launchpad.net/nova/+bug/1644513

Could somebody from Nova indicates if this is something you want to fix
quickly or if we should just stop caring about Nova+PostgreSQL in our
integration test gate?


As someone using Nova+PostgreSQL in production, I sure hope that we don't stop 
caring about it!


Chris

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

Re: [openstack-dev] [keystone] Pike PTL

2016-11-24 Thread Juan Antonio Osorio

You were an awesome PTL! thanks for all the work.

BR

On Wed, Nov 23, 2016 at 6:04 PM, Henry Nash  wrote:

> Steve,
>
> It’s been a pleasure working with you as PTL - an excellent tenure. Enjoy
> taking some time back!
>
> Henry
>
> On 21 Nov 2016, at 19:38, Steve Martinelli  wrote:
>
> one of these days i'll learn how to spell :)
>
> On Mon, Nov 21, 2016 at 12:52 PM, Steve Martinelli  > wrote:
>
>> Keystoners,
>>
>> I do not intend to run for the PTL position of the Pike development
>> cycle. I'm sending this out early so I can work with folks interested in
>> the role, If you intend to run for PTL in Pike and are interested in
>> learning the ropes (or just want to hear more about what the role means)
>> then shoot me an email.
>>
>> It's been an unforgettable ride. Being PTL a is very rewarding
>> experience, I encourage anyone interested to put your name forward. I'm
>> not going away from OpenStack, I just think three terms as PTL has been
>> enough. It'll be nice to have my evenings back :)
>>
>> To *all* the keystone contributors (cores and non-cores), thank you for
>> all your time and commitment. More importantly thank you for putting up
>> with my many questions, pings, pokes and -1s. Each of you are amazing and
>> together you make an awesome team. It has been an absolute pleasure to
>> serve as PTL, thank you for letting me do so.
>>
>> stevemar
>>
>>
>> 
>>
>> Thanks for the idea Lana [1]
>> [1] http://lists.openstack.org/pipermail/openstack-docs/2016
>> -November/009357.html
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] neutron-lib impact

2016-11-24 Thread Neil Jerram

But I think a periodic check for a Neutron/neutron-lib-using project (such
as networking-calico) would still be a decent way of catching such issues,
wouldn't it?

On Thu, Nov 24, 2016 at 12:58 AM Kevin Benton  wrote:

> The issue we had is different than breaking changes in neutron-lib. The
> issue we are running into now is bumps in the road when we are removing
> deprecated things from Neutron that other projects are still using even
> though they should be using the neutron-lib version instead.
>
> On Wed, Nov 23, 2016 at 5:42 PM, Joshua Harlow 
> wrote:
>
> A suggestion would also to setup something like the following:
>
> https://wiki.openstack.org/wiki/Oslo#Periodic
>
> Get the users of neutron lib being tested against the latest neutron lib
> (at least nightly) and seeing if they will be borked by a new neutron lib
> merge...
>
>
> http://status.openstack.org/openstack-health/#/?groupKey=build_name=hour=-with-oslo
>
> Overall be careful with the APIs u expose and plan out how u will shift
> users from the old API to the new API (without destroying the world during
> that transition).
>
> My 3 cents :-P
>
> -Josh
>
>
> Boden Russell wrote:
>
> I would encourage anyone working on neutron-lib related changes to have
> a peek at the recently renovated contributing doc [1] if you haven't
> already.
>
> In particular the 'Phase 4: Consume' section [2] provides some tips on
> how we see this workflow playing out.
>
> Thanks
>
> [1]
>
> https://github.com/openstack/neutron-lib/blob/master/doc/source/contributing.rst
> [2]
>
> https://github.com/openstack/neutron-lib/blob/master/doc/source/contributing.rst#phase-4-consume
>
>
> On 11/23/16 12:39 PM, Armando M. wrote:
>
> Hi neutrinos,
>
> In the last few hours a couple of changes landed [1,2] that caused a bit
> of a jam in the neutron subproject gates, as they overlapped with
> another change [3] having impact on the subprojects.
>
> This is why it is important to communicate during team meetings and/or
> ML that patches with potential impact are in flight in our review
> pipeline, so that we do our best to coordinate the merge process without
> shooting ourselves in the foot.
>
> To bring this back to sanity, I issued a temporary revert [4], so that
> [5] can land undisturbed. After that, a double revert will be applied,
> once subprojects have had the opportunity to deal with the aftermath of
> the other breaking change [1,2] (e.g. [6,7]).
>
>  From now on, I'd strongly encourage people proposing/reviewing patches
> with potential impact (any impact) to err on the side of caution, and
> take the advised steps to ensure such situations don't happen in the
> future.
>
> Thanks,
> Armando
>
> [1] https://review.openstack.org/#/c/397704/
> [2] https://review.openstack.org/#/c/397037/
> [3] https://review.openstack.org/#/c/386845/
> [4] https://review.openstack.org/#/c/401377/
> [5] https://review.openstack.org/#/q/topic:plugin-directory+status:open
> [6] https://review.openstack.org/#/c/401263/
> [7] https://review.openstack.org/#/c/401355/
>
>
> __
> 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] [nova] [telemetry] PostgreSQL gate broken

2016-11-24 Thread Sylvain Bauza

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



Le 24/11/2016 11:57, Julien Danjou a écrit :
> Hi,
> 
> It seems Nova broke its PostgreSQL support recently, and that
> impacts Telemetry as we do gate on PostgreSQL. I opened a bug:
> 
> https://bugs.launchpad.net/nova/+bug/1644513
> 
> Could somebody from Nova indicates if this is something you want to
> fix quickly or if we should just stop caring about Nova+PostgreSQL
> in our integration test gate?
> 


Good question. Since today is Thanksgiving for US folks, it could be a
bit more difficult for find the RCA and fix it but we can still try.

For the moment, trying to understand when the regression happened and
with which merged change, so we could see if we could just revert it.

- -Sylvain


> Thanks!
> 
> Cheers,
> 
> 
> 
> __

>
> 
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
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJYNuP7AAoJEO+lyg5yIElq1gAH/103s+0Iuffo+F//68kZy57e
E1ziQpvNvgtuQ+z20jhFnbhv3sWujVcYSjGG61hwVN2sapQS3/d6Q4y5/jYiWpBQ
eZbfA9jjQjq+3BunjwVGq+w6JiT9Wf5wTxKUm2aPbZ4c1nO5HfVjUPcPgXFuq3Ad
fUUZmRXVrbXoUjSkdFeiZZUDP5AQwxFK6zOjlnTw0bPWfaLOu5b9kZ2raG1LJIBY
vWWKFZ8sfQFPUCas71SdMy3kgjN2ExrvWKxrdv7NW5952xX5J+v9VZSgBevoE/YA
b5wxThfBO7bhF3NGb2IPwBBr0I50q7Zy/Y47NR+6tUJVRCgZnnzo1+LAfhkL7t8=
=Ni/b
-END PGP SIGNATURE-

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

Re: [openstack-dev] [keystone] Stepping down from keystone core

2016-11-24 Thread Rodrigo Duarte

Thanks for everything Marek, good times when we debugged federation issues!
:)

On Wed, Nov 23, 2016 at 1:05 PM, Henry Nash  wrote:

> Echoing the comments of others. - thanks for all your hard work and
> expertise.
>
> Henry
>
> On 23 Nov 2016, at 15:05, Lance Bragstad  wrote:
>
> Thanks for all your hard work, Marek. It's been a pleasure working with
> you. Best of luck and hopefully our paths cross in the future!
>
> On Tue, Nov 22, 2016 at 7:57 PM, Steve Martinelli 
> wrote:
>
>> Marek, thanks for everything you've done in Keystone. It was loads of fun
>> to develop some of the early federation work with you back in the Icehouse
>> release! Good luck in whatever the future holds for you!
>>
>> On Tue, Nov 22, 2016 at 5:18 PM, Marek Denis <
>> marek.denis+openst...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Due to my current responsibilities I cannot serve as keystone core
>>> anymore. I also feel I should make some space for others who will surely
>>> bring new quality to the OpenStack Identity Program.
>>>
>>> It's been a great journey, I surely learned a lot and improved both my
>>> technical and soft skills. I can only hope my contributions and reviews
>>> have been useful and made OpenStack a little bit better.
>>>
>>> I wish you all the best in the future.
>>>
>>> With kind regards,
>>> Marek Denis
>>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Security] Weekly meeting canceled due to thanksgiving

2016-11-24 Thread Rob C

All,

I should have sent the notification out earlier however today's weekly IRC
meeting is cancelled as most of our group are american and on vacation
today.

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

Re: [openstack-dev] [all][infra] Proposed changes to unit-test setup

2016-11-24 Thread Coles, Alistair



On 22 November 2016 18:56, John Dickinson wrote:

>
> On 22 Nov 2016, at 10:47, Andreas Jaeger wrote:
> 
> > When we (infra) changed the unit test jobs to not set up databases by
> > default, we created special python-db and tox-db jobs that set up both
> > MySQL and PostgreSQL databases. And that complicated the setup of
> > those projects and lead to problems like setting projects up via
> > bindep for both databases even if one was used.
> >
> > We had last week an IRC discussion [1] and came up with the following
> > approach:
> >
> >   Projects can use a tools/test-setup.sh script that is called from
> >   our unit test (tox, python27, python34, python35) targets. The
> >   script is executed as root and should set up the needed databases -
> >   or whatever is needed. The script needs to reside in the repository -
> >   and thus might need to get backported to older branches.
> >
> >   This setup should be used for any kind of repo specific unit test
> >   setup.
> >
> >   Projects are suggested to add to their developer documents, e.g. the
> >   README or CONTRIBUTING or TESTING file, the usage of
> >   tools/testsetup.sh. Developers should be able to use the script to
> >   set up prerequisites for unit tests locally.
> >
> >   Long term goal is for projects to not use the -db jobs anymore, new
> >   changes for them should not be accepted.
> >
> > This is implemented in project-config [2], an example usage in
> > nodepool [3,4], which leads to a cleanup [5].
> >
> > Further investigation shows that the special searchlight setup can be
> > solved with the same approach (searchlight change [6], project-config
> > [7]). Here it's interesting to note that moving the setup in the
> > repository, found a problem: The repo needs elasticsearch 1 for
> > liberty and 2 for newer branches, this can now be done inside the
> > repository.
> >
> > The xfs TMPDIR setup of swift [2] could been done in general this way
> > as well but that change needs to set TMPDIR for the unittests, passing
> > information from the set up builder to the tox builder. This is
> > currently not possible using only the proposed solution, and so would
> > still require a custom tox job. Alternative, this could be changed
> > with some other way of passing the value of TMPDIR between these
> > different invocations.
> 
> (actually link [10])
> 
> This sounds like a great idea that I would have loved to have in place a few
> weeks ago!
> 
> One question: is there a limit to which tox environments will call this 
> in-repo
> script? Above you list a few, but Swift and other projects have repo-specific
> environments that would need the setup as well. How will that work?
> 

+1 this is a really useful feature.

Further to John's question, would it be possible for the test-setup.sh script 
to be passed the job template name as an arg? That would allow customized setup 
for specific test jobs. Right now I don’t have a specific use case in Swift but 
I'm curious as to whether it is a possibility.

> 
> >
> > Today, a change was proposed [8,9] that would setup docker for kolla
> > and kolla-ansible. I suggest to not merge it and instead use the same
> > approach here.
> >
> > Credits for the proposal go to Jeremy - and this got triggered by
> > comments by Jim. Thanks!
> >
> > Andreas
> >
> > [1]
> > http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack
> > -infra.2016-11-17.log.html#t2016-11-17T15:07:38
> >
> > [2] https://review.openstack.org/399105
> > [3] https://review.openstack.org/399079
> > [4] https://review.openstack.org/399177
> > [5] https://review.openstack.org/399180
> > [6] https://review.openstack.org/399159
> > [7] https://review.openstack.org/399169
> > [8] https://review.openstack.org/400128
> > [9] https://review.openstack.org/400474
> > [10] https://review.openstack.org/394600
> > --
> >  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> >   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> >GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> >HRB 21284 (AG Nürnberg)
> > GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272
> > A126
> >
> >
> 
> __
> >  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] [Performance][shaker]

2016-11-24 Thread Ilya Shakhat

Hi Matt,

Out of the box Shaker doesn't support such topology.
It shouldn't be hard to implement though. Let me check what needs to be
done.

Thanks,
Ilya

2016-11-24 13:49 GMT+03:00 Matthieu Simonin :

> Hello,
>
> I'm looking to shaker capabilities and I'm wondering if this kind
> of accomodation (see attachment also) can be achieved
>
> Ascii (flat) version :
>
> CN1 (2n VMs) <- n flows -> CN2 (2n VMs)
> CN1 (2n VMs) <- n flows -> CN3 (2n VMs)
> CN2 (2n VMs) <- n flows -> CN3 (2n VMs)
>
> In this situation concurrency could be mapped to the number of
> simultaneous flows in use per link.
>
> Best,
>
> 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 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] [telemetry] PostgreSQL gate broken

2016-11-24 Thread Julien Danjou

Hi,

It seems Nova broke its PostgreSQL support recently, and that impacts
Telemetry as we do gate on PostgreSQL. I opened a bug:

  https://bugs.launchpad.net/nova/+bug/1644513

Could somebody from Nova indicates if this is something you want to fix
quickly or if we should just stop caring about Nova+PostgreSQL in our
integration test gate?

Thanks!

Cheers,
-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


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

[openstack-dev] [Performance][shaker]

2016-11-24 Thread Matthieu Simonin

Hello, 

I'm looking to shaker capabilities and I'm wondering if this kind 
of accomodation (see attachment also) can be achieved

Ascii (flat) version : 

CN1 (2n VMs) <- n flows -> CN2 (2n VMs)
CN1 (2n VMs) <- n flows -> CN3 (2n VMs)
CN2 (2n VMs) <- n flows -> CN3 (2n VMs)

In this situation concurrency could be mapped to the number of simultaneous 
flows in use per link.

Best,

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

Re: [openstack-dev] [Nova] Stepping back

2016-11-24 Thread Sylvain Bauza



Le 22/11/2016 17:39, Andrew Laski a écrit :
> I should have sent this weeks ago but I'm a bad person who forgets
> common courtesy. My employment situation has changed in a way that does
> not afford me the necessary time to remain a regular contributor to
> Nova, or the broader OpenStack community. So it is with regret that I
> announce that I will no longer be actively involved in the project.
> 
> Fortunately, for those of you reading this, the Nova community is full
> of wonderful and talented individuals who have picked up the work that
> I'm not able to continue. Primarily this means parts of the cellsv2
> effort, for which I am extremely grateful.
> 
> It has been a true pleasure working with you all these past few years
> and I'm thankful to have had the opportunity. As I've told people many
> times when they ask me what it's like to work on an open source project
> like this: working on proprietary software exposes you to smart people
> but you're limited to the small set of people within an organization,
> working on a project like this exposed me to smart people from many
> companies and many parts of the world. I have learned a lot working with
> you all. Thanks.
> 
> I will continue to lurk in #openstack-nova, and try to stay minimally
> involved as time allows, so feel free to ping me there.
> 


Andrew, you're an excellent contributor and I'm a bit sad to see you
less in Nova. I really liked working with you and I remember all the
help you got to me for knowing better the project.

Hopefully you'll still be in the IRC channel, but I'll really miss
seeing you during our face-to-face meetings.

My thoughts goes for you for your next projects.

-Sylvain


> -Laski
> 
> __
> 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] [neutron] stable/newton 'broken'

2016-11-24 Thread Thierry Carrez

Gary Kotton wrote:
> Please see - 
> http://logs.openstack.org/82/401882/1/check/gate-vmware-nsx-python27-db-ubuntu-xenial/1ac0686/console.html#_2016-11-24_06_58_38_520273
> Here we are pulling trunk as there is no stable version to use

Is neutron stable/newton really broken (like your subject seems to
indicate) ? Or only vmware-nsx stable/newton ? Since networking-l2gw and
tap-as-a-service are unofficial projects we can't guarantee that they
will create branches that match the official stable ones, so we should
try to avoid depending on them if possible...

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [cinder][oslo] ZeroMQ support with multibackend

2016-11-24 Thread Dulko, Michal

Hi,

Cinder is lacking ZeroMQ messaging support in multibackend
configurations. This is due to the fact that we're abusing
``Target.server`` property by appending "@backend" suffix to the
hostname. This works just fine in RabbitMQ, as it routes messages using
queue names, but fails in ZeroMQ when 'server' property stops matching
hostnames.

There is a workaround for this in oslo.messaging [1], but it breaks
multibackend configrations, as backend A on a host can get message
addressed for the backend B on the same host.

We've seen tries [2], [3], [4] to fix it, but these implementations
were based on doing special operations when ZeroMQ is configured. This
invalidates concept of oslo.messaging being an abstraction layer.

My current idea to fix this [5] is to switch whole multibackend message
routing from being based on ``Target.server`` to ``Target.topic``.
Implementation is based on keeping the old RPC server that listens on
"cinder-volume" topic for fanout messages and creating a new RPC server
which listens on "cinder-volume.host@backend" topic and "host" server.
This is fine with rolling upgrades, as '$topic.$server' is how server
queue names are built in oslo.messaging, so we'll still listen on old
queues.

Please note that only the messaging layer is being changed. Internally
volumes will still be seen as existing on "host@backend" servers.

I've added an experimental gate-tempest-dsvm-zeromq-multibackend job,
which passes fine on [5], but fails on master, which proves that the
fix works.

Is anyone seeing dangers in this approach? If not - I'm asking for
reviews on [5].

Thanks,
Michal

[1]
https://github.com/openstack/oslo.messaging/blob/7b5bec3133b6d74c4144fb8a33b9c9d2803e8858/oslo_messaging/_drivers/zmq_driver/zmq_address.py#L36-L39
[2] https://review.openstack.org/#/c/271848/
[3] https://review.openstack.org/#/c/277113/
[4] https://review.openstack.org/#/c/351862
[5] https://review.openstack.org/#/c/398452
__
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] [tap-as-a-service] stable/newton 'broken'

+1

In newton we did integrations in the vmware_nsx repository with this (it’s a 
super useful project and having the ability to do a copy port helps debug and 
triage issues)

Please let us know what you decide

On 11/24/16, 11:43 AM, "Soichi Shigeta"  wrote:


  Hi,

 > taas folks,
 > given increasing demands (networking-midonet also will depend on it)
 > i guess it makes sense to create newton branch.
 > if we don't think it's mature enough, we can call it experimental or
 > tech-preview or whatever.
 > how do you think?

   It sounds nice idea.
   +1 (maybe "tech-preview")

   Regards,
   Soichi

> hi,
>
> On Thu, Nov 24, 2016 at 6:00 PM, Gary Kotton  wrote:
>> Please see - 
http://logs.openstack.org/82/401882/1/check/gate-vmware-nsx-python27-db-ubuntu-xenial/1ac0686/console.html#_2016-11-24_06_58_38_520273
>> Here we are pulling trunk as there is no stable version to use
>
> thank you.
> tap-as-a-service doesn't have any stable branches or releases yet.
>
> taas folks,
> given increasing demands (networking-midonet also will depend on it)
> i guess it makes sense to create newton branch.
> if we don't think it's mature enough, we can call it experimental or
> tech-preview or whatever.
> how do you think?
>
>>
>> On 11/24/16, 10:00 AM, "Takashi Yamamoto"  wrote:
>>
>> can you give me an example of breakage?
>>
>> On Thu, Nov 24, 2016 at 4:19 PM, Gary Kotton  
wrote:
>> > Hi,
>> >
>> > The change https://review.openstack.org/#/c/386845/ that landed 
yesterday
>> > has caused a breakage in stable/newton. This is due to the fact 
that the
>> > following projects do not have stable/newton tags:
>> >
>> > -  
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_tap-2Das-2Da-2Dservice=DgICAg=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=rhTtJFUiMBfCpZ3j8zoxSr5mK0E8RukJ6ajV1ATnO0Y=dXUw9DykF46Tk1oluf1fQMVmbhNKHbwG_scuNyTpXrM=
>> >
>> > -  
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_networking-2Dl2gw=DgICAg=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=rhTtJFUiMBfCpZ3j8zoxSr5mK0E8RukJ6ajV1ATnO0Y=DFa6PGUhmT9xowY1VGPsddAUZYVmZX2YsX9NIHQMpK0=
>> >
>> > Can the relevant release teams of the projects above please create 
the
>> > relevant tags.
>> >
>> > Thanks
>> >
>> > Gary
>> >
>> >
>> > 
__
>> > 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] [neutron] [tap-as-a-service] stable/newton 'broken'

2016-11-24 Thread Soichi Shigeta



 Hi,

> taas folks,
> given increasing demands (networking-midonet also will depend on it)
> i guess it makes sense to create newton branch.
> if we don't think it's mature enough, we can call it experimental or
> tech-preview or whatever.
> how do you think?

  It sounds nice idea.
  +1 (maybe "tech-preview")

  Regards,
  Soichi


hi,

On Thu, Nov 24, 2016 at 6:00 PM, Gary Kotton  wrote:

Please see - 
http://logs.openstack.org/82/401882/1/check/gate-vmware-nsx-python27-db-ubuntu-xenial/1ac0686/console.html#_2016-11-24_06_58_38_520273
Here we are pulling trunk as there is no stable version to use


thank you.
tap-as-a-service doesn't have any stable branches or releases yet.

taas folks,
given increasing demands (networking-midonet also will depend on it)
i guess it makes sense to create newton branch.
if we don't think it's mature enough, we can call it experimental or
tech-preview or whatever.
how do you think?



On 11/24/16, 10:00 AM, "Takashi Yamamoto"  wrote:

can you give me an example of breakage?

On Thu, Nov 24, 2016 at 4:19 PM, Gary Kotton  wrote:
> Hi,
>
> The change https://review.openstack.org/#/c/386845/ that landed yesterday
> has caused a breakage in stable/newton. This is due to the fact that the
> following projects do not have stable/newton tags:
>
> -  
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_tap-2Das-2Da-2Dservice=DgICAg=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=rhTtJFUiMBfCpZ3j8zoxSr5mK0E8RukJ6ajV1ATnO0Y=dXUw9DykF46Tk1oluf1fQMVmbhNKHbwG_scuNyTpXrM=
>
> -  
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_networking-2Dl2gw=DgICAg=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=rhTtJFUiMBfCpZ3j8zoxSr5mK0E8RukJ6ajV1ATnO0Y=DFa6PGUhmT9xowY1VGPsddAUZYVmZX2YsX9NIHQMpK0=
>
> Can the relevant release teams of the projects above please create the
> relevant tags.
>
> Thanks
>
> Gary
>
>
> __
> 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-dev] 答复: RE: [vitrage] about aodh alarm notification

2016-11-24 Thread dong . wenjuan

Hi Weyl Alexey,

Another question:
If we received the alarm.creation notification with the 'ok' state, we 
filter it and don't create vertex in the Graph.
The next received the alarm state_change notification, all the other alarm 
details are missing in the vertex.
How can I handle this? Thanks~


BR,
dwj







"Weyl, Alexey (Nokia - IL)"  
2016-11-24 16:25

收件人
"dong.wenj...@zte.com.cn" , "Afek, Ifat (Nokia - 
IL)" , "Hefetz, Idan (Nokia - IL)" 
, "zhang.yuj...@zte.com.cn" 

抄送
"openstack-dev@lists.openstack.org" 
主题
RE: [openstack-dev] [vitrage] about aodh alarm notification






Hi Dong,

Good question, I will explain how you can handle this problem in Vitrage.

You don't need the cache mechanism here, it is much more simplier.

When you get a new alarm with get_all or by notification of 
'alarm.creation' you will create the alarm with its correct data \ 
properties.
Then when you receive a notification of 'alarm.rule_change', 
'alarm.state_transition', 'alarm.deletion' all you need to do is only to 
update the correct property that has changed in the aodh vertex.
Thus, When you create the Vertex in the transformer, you know the aodh 
uuid so you know the vitrage_id, and you can pass only the properties that 
you have received and want to update (and not all the properties that 
there in the aodh vertex). All the other properties that you haven't 
received that haven't changed you can pass them as None and they won't be 
changed in the graph.

Hope this explains everything.
If you have other questions, you are more than welcome to ask.

Best Regrads,
Alexey


From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
Sent: Thursday, November 24, 2016 9:39 AM
To: Afek, Ifat (Nokia - IL); Weyl, Alexey (Nokia - IL); Hefetz, Idan 
(Nokia - IL); zhang.yuj...@zte.com.cn
Cc: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [vitrage] about aodh alarm notification


Hi Vitrages, 

Currently there are four aodh alarm notifications we need to handle: 
'alarm.creation', 'alarm.rule_change', 'alarm.state_transition', 
'alarm.deletion' 

Only the alarm.creation notification carries the alarm detail info. 
So we need to cache the alarm info. 
When we receive other notifications, we can fill all fields from the 
cache. 

But if the alarm creates before vitrage servies startup, we can't get the 
alarm.creation notification. 
So we need to get_all when vitrage services startup. 
As `SnapshotsService` will get all alarms info when it startup. 
But `SnapshotsService` and `ListenerService` are two services, 
they can't share the cache data unless they communicate with each other. 
This wil be a big change. 

Are there any other better solutions? I need some help, thanks :) 

BR, 
dwj


__
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] [tap-as-a-service] stable/newton 'broken'

hi,

On Thu, Nov 24, 2016 at 6:00 PM, Gary Kotton  wrote:
> Please see - 
> http://logs.openstack.org/82/401882/1/check/gate-vmware-nsx-python27-db-ubuntu-xenial/1ac0686/console.html#_2016-11-24_06_58_38_520273
> Here we are pulling trunk as there is no stable version to use

thank you.
tap-as-a-service doesn't have any stable branches or releases yet.

taas folks,
given increasing demands (networking-midonet also will depend on it)
i guess it makes sense to create newton branch.
if we don't think it's mature enough, we can call it experimental or
tech-preview or whatever.
how do you think?

>
> On 11/24/16, 10:00 AM, "Takashi Yamamoto"  wrote:
>
> can you give me an example of breakage?
>
> On Thu, Nov 24, 2016 at 4:19 PM, Gary Kotton  wrote:
> > Hi,
> >
> > The change https://review.openstack.org/#/c/386845/ that landed 
> yesterday
> > has caused a breakage in stable/newton. This is due to the fact that the
> > following projects do not have stable/newton tags:
> >
> > -  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_tap-2Das-2Da-2Dservice=DgICAg=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=rhTtJFUiMBfCpZ3j8zoxSr5mK0E8RukJ6ajV1ATnO0Y=dXUw9DykF46Tk1oluf1fQMVmbhNKHbwG_scuNyTpXrM=
> >
> > -  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_networking-2Dl2gw=DgICAg=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=rhTtJFUiMBfCpZ3j8zoxSr5mK0E8RukJ6ajV1ATnO0Y=DFa6PGUhmT9xowY1VGPsddAUZYVmZX2YsX9NIHQMpK0=
> >
> > Can the relevant release teams of the projects above please create the
> > relevant tags.
> >
> > Thanks
> >
> > Gary
> >
> >
> > 
> __
> > 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-dev] 答复: RE: [vitrage] about aodh alarm notification

2016-11-24 Thread dong . wenjuan

Hi Weyl, Alexey,

Oh, I made the issue complicated.
Thanks for your explaintion~
I'll try again.
Thank you very much~

BR,
dwj






"Weyl, Alexey (Nokia - IL)"  
2016-11-24 16:25

收件人
"dong.wenj...@zte.com.cn" , "Afek, Ifat (Nokia - 
IL)" , "Hefetz, Idan (Nokia - IL)" 
, "zhang.yuj...@zte.com.cn" 

抄送
"openstack-dev@lists.openstack.org" 
主题
RE: [openstack-dev] [vitrage] about aodh alarm notification






Hi Dong,

Good question, I will explain how you can handle this problem in Vitrage.

You don't need the cache mechanism here, it is much more simplier.

When you get a new alarm with get_all or by notification of 
'alarm.creation' you will create the alarm with its correct data \ 
properties.
Then when you receive a notification of 'alarm.rule_change', 
'alarm.state_transition', 'alarm.deletion' all you need to do is only to 
update the correct property that has changed in the aodh vertex.
Thus, When you create the Vertex in the transformer, you know the aodh 
uuid so you know the vitrage_id, and you can pass only the properties that 
you have received and want to update (and not all the properties that 
there in the aodh vertex). All the other properties that you haven't 
received that haven't changed you can pass them as None and they won't be 
changed in the graph.

Hope this explains everything.
If you have other questions, you are more than welcome to ask.

Best Regrads,
Alexey


From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
Sent: Thursday, November 24, 2016 9:39 AM
To: Afek, Ifat (Nokia - IL); Weyl, Alexey (Nokia - IL); Hefetz, Idan 
(Nokia - IL); zhang.yuj...@zte.com.cn
Cc: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [vitrage] about aodh alarm notification


Hi Vitrages, 

Currently there are four aodh alarm notifications we need to handle: 
'alarm.creation', 'alarm.rule_change', 'alarm.state_transition', 
'alarm.deletion' 

Only the alarm.creation notification carries the alarm detail info. 
So we need to cache the alarm info. 
When we receive other notifications, we can fill all fields from the 
cache. 

But if the alarm creates before vitrage servies startup, we can't get the 
alarm.creation notification. 
So we need to get_all when vitrage services startup. 
As `SnapshotsService` will get all alarms info when it startup. 
But `SnapshotsService` and `ListenerService` are two services, 
they can't share the cache data unless they communicate with each other. 
This wil be a big change. 

Are there any other better solutions? I need some help, thanks :) 

BR, 
dwj


__
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] stable/newton 'broken'

Please see - 
http://logs.openstack.org/82/401882/1/check/gate-vmware-nsx-python27-db-ubuntu-xenial/1ac0686/console.html#_2016-11-24_06_58_38_520273
Here we are pulling trunk as there is no stable version to use

On 11/24/16, 10:00 AM, "Takashi Yamamoto"  wrote:

can you give me an example of breakage?

On Thu, Nov 24, 2016 at 4:19 PM, Gary Kotton  wrote:
> Hi,
>
> The change https://review.openstack.org/#/c/386845/ that landed yesterday
> has caused a breakage in stable/newton. This is due to the fact that the
> following projects do not have stable/newton tags:
>
> -  
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_tap-2Das-2Da-2Dservice=DgICAg=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=rhTtJFUiMBfCpZ3j8zoxSr5mK0E8RukJ6ajV1ATnO0Y=dXUw9DykF46Tk1oluf1fQMVmbhNKHbwG_scuNyTpXrM=
 
>
> -  
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_networking-2Dl2gw=DgICAg=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=rhTtJFUiMBfCpZ3j8zoxSr5mK0E8RukJ6ajV1ATnO0Y=DFa6PGUhmT9xowY1VGPsddAUZYVmZX2YsX9NIHQMpK0=
 
>
> Can the relevant release teams of the projects above please create the
> relevant tags.
>
> Thanks
>
> Gary
>
>
> __
> 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] [vitrage] about aodh alarm notification

2016-11-24 Thread Weyl, Alexey (Nokia - IL)

Hi Dong,

Good question, I will explain how you can handle this problem in Vitrage.

You don't need the cache mechanism here, it is much more simplier.

When you get a new alarm with get_all or by notification of 'alarm.creation' 
you will create the alarm with its correct data \ properties.
Then when you receive a notification of 'alarm.rule_change', 
'alarm.state_transition', 'alarm.deletion' all you need to do is only to update 
the correct property that has changed in the aodh vertex.
Thus, When you create the Vertex in the transformer, you know the aodh uuid so 
you know the vitrage_id, and you can pass only the properties that you have 
received and want to update (and not all the properties that there in the aodh 
vertex). All the other properties that you haven't received that haven't 
changed you can pass them as None and they won't be changed in the graph.

Hope this explains everything.
If you have other questions, you are more than welcome to ask.

Best Regrads,
Alexey


From: dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
Sent: Thursday, November 24, 2016 9:39 AM
To: Afek, Ifat (Nokia - IL); Weyl, Alexey (Nokia - IL); Hefetz, Idan (Nokia - 
IL); zhang.yuj...@zte.com.cn
Cc: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [vitrage] about aodh alarm notification


Hi Vitrages, 

Currently there are four aodh alarm notifications we need to handle: 
'alarm.creation', 'alarm.rule_change', 'alarm.state_transition', 
'alarm.deletion' 

Only the alarm.creation notification carries the alarm detail info. 
So we need to cache the alarm info. 
When we receive other notifications, we can fill all fields from the cache. 

But if the alarm creates before vitrage servies startup, we can't get the 
alarm.creation notification. 
So we need to get_all when vitrage services startup. 
As `SnapshotsService` will get all alarms info when it startup. 
But `SnapshotsService` and `ListenerService` are two services, 
they can't share the cache data unless they communicate with each other. 
This wil be a big change. 

Are there any other better solutions? I need some help, thanks :) 

BR, 
dwj

__
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] Need some suggestion for a patch on liberty branch

2016-11-24 Thread Bruce Tan


Hi all,
I am writing to ask suggestion about how to move one patch [1] forward.

This patch is to fix a problem that tempest configuration on liberty is 
not setting "api_extensions", and any test case that verifies API 
extensions NOT on Liberty will get a FALSE POSITIVE (because we used 
"all" in configuration instead of listing all available extensions 
explicitly), and lead to test failure.

The same issue is also on Mitaka, and the counterpart [2] is merged.
(Maybe I should have reported such issues formally as a bug in the first 
place)


This patch has being waiting for review for more than a month, and 
another patch (adding new test cases to Tempest) depending on it got 
workflow one month ago but had to wait for this one to get merged.


I understand that Liberty is not our priority, and it will be EOL soon. 
So I am not sure if I would continue pursuing the patch getting merged, 
or should I wait until Liberty is EOL so that liberty tests get removed 
from Jenkins?


Thank you in advance.

[1] : https://review.openstack.org/#/c/380066/
[2] : https://review.openstack.org/#/c/386886/

--
Best regards,
Bruce Tan


__
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] stable/newton 'broken'