[openstack-dev] [meghdwar] use case for meghdwar API and Wednesday meeting

[prakash RAMCHANDRAN]

Hi all   
 You can edit the etherpad if you want to update agenda...or reply be email on 
item1-4 below.
https://etherpad.openstack.org/p/meghdwar

Would like to meet for discussions for BOF and agenda as we can not wait for 
2nd Wednesday, so lets meet Wednesday 
from 7-8am PDT (Wed 14:00-15:00 UTC)irc Channel : #openstack-meghdwar
Follow up on same points with updates  from last meeting.
1 Megdwar Gateway API discussions based on use case
Focus is what APIs needed for minimum use case of two cloudlets on two edges 
running 1 app each and how to move one of the apps from source edge gateway to 
destination edge gateway on compute nodes through those gateways.
APIs - requiredMeghdwar service process will have configuration file for each 
cloudlet at the Edge gateway.Dump (take Snapshot), Create , Read, List, Write, 
Start, Stop - Cloudlets
Reviewed other Catalog modules (application-catalog-ui, murano, murano-agent to 
be tested) on Rackspace
2. What other modules are needed in OpenStack 'meghdwar' Catalog Refer Murano 
(May be we use it) - Our Catalog can be for ASP, CSP,NSP and integrated through 
ESP.

To discuss Binder option for two cloudlets. as for two cloudlets with one app 
in 1 above.   c. Cloudlet Gateway Management  (Gateway Service Management) 
   d. python  Cloudlet  / MEC Gateway Management  4. How do we go about 
priority 
Consider two cloudlet Binders and see if we can use LXD and LXC ;live migration 
as 1st API implementation for Meghdwar.LXD 2.0: Live migration [9/12] | 
Stéphane Graber's website

ThanksPrakash__
OpenStack Development Mailing 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] inspecting external openstack environment

[Yujun Zhang]

I see. I'll draft a blueprint after essential study on this requirement.

And thank you for the information on add-new-datasource document.
--
Yujun

On Wed, Sep 7, 2016 at 1:31 PM Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:

> Hi Yujun,
>
> I don’t think we have a support for different versions of openstack at the
> same time at the moment.
>
> We have thought of such a requirement yet, but I think it can be done.
>
> If you can, please add a blueprint with all the details for such a feature.
>
> In addition, we now have a documentation for how to add a new datasource:
>
>
> https://github.com/openstack/vitrage/blob/master/doc/source/add-new-datasource.rst
>
>
>
> Alexey
>
>
>
>
>
> *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> *Sent:* Wednesday, September 07, 2016 6:08 AM
>
>
> *To:* OpenStack Development Mailing List (not for usage questions)
>
> *Subject:* Re: [openstack-dev] [vitrage] inspecting external openstack
> environment
>
>
>
> One additional question about openstack datasource.
>
>
>
> Is it possible to connect *multiple* openstack data sources, furthermore,
> different version of openstack (liberty, newton), at the same time?
>
>
>
> To monitor existing systems, this might be a common requirement.
>
> On Thu, Sep 1, 2016 at 5:16 PM Yujun Zhang 
> wrote:
>
> Thanks for explanation. I'll give it a try.
>
>
>
> Answer to BTW, it is Liberty on Ubuntu 14.04 deployed by Fuel 8.0.
>
> --
>
> Yujun
>
>
>
> On Wed, Aug 31, 2016 at 2:42 PM Afek, Ifat (Nokia - IL) <
> ifat.a...@nokia.com> wrote:
>
> Hi Yujun,
>
>
>
> Using Vitrage for an external openstack environment should be possible,
> but it has never been tested.
>
>
>
> There are some issues to consider:
>
>- You should set the ip of the keystone in vitrage.conf, and make sure
>you can access it
>- You will need to install, together with Vitrage, many dependent
>openstack libraries
>- In order to access Vitrage API, you will either need to install
>keystone on Vitrage environment, or to configure an endpoint for Vitrage in
>the existing openstack
>- For notifications, you need to connect Vitrage to the oslo bus of
>the existing openstack
>
> BTW, what is the version of this openstack environment?
>
>
>
> Best Regards,
>
> Ifat.
>
>
>
> *From: *Yujun Zhang
> *Reply-To: *"OpenStack Development Mailing List (not for usage questions)"
> *Date: *Tuesday, 30 August 2016 at 10:06
> *To: *"OpenStack Development Mailing List (not for usage questions)"
> *Subject: *[openstack-dev] [vitrage] inspecting external openstack
> environment
>
>
>
> My purpose is to inspect an **existing** openstack environment with
> vitrage.
>
>
>
> Do I have to install vitrage on the target environment or it can be done
> by proper configuration?
>
>
>
> --
>
> Yujun
>
> __
> OpenStack Development Mailing 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] inspecting external openstack environment

[Weyl, Alexey (Nokia - IL)]

Hi Yujun,

I don’t think we have a support for different versions of openstack at the same 
time at the moment.

We have thought of such a requirement yet, but I think it can be done.

If you can, please add a blueprint with all the details for such a feature.

In addition, we now have a documentation for how to add a new datasource:
https://github.com/openstack/vitrage/blob/master/doc/source/add-new-datasource.rst

Alexey


From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
Sent: Wednesday, September 07, 2016 6:08 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [vitrage] inspecting external openstack environment

One additional question about openstack datasource.

Is it possible to connect multiple openstack data sources, furthermore, 
different version of openstack (liberty, newton), at the same time?

To monitor existing systems, this might be a common requirement.
On Thu, Sep 1, 2016 at 5:16 PM Yujun Zhang 
> wrote:
Thanks for explanation. I'll give it a try.

Answer to BTW, it is Liberty on Ubuntu 14.04 deployed by Fuel 8.0.
--
Yujun

On Wed, Aug 31, 2016 at 2:42 PM Afek, Ifat (Nokia - IL) 
> wrote:
Hi Yujun,

Using Vitrage for an external openstack environment should be possible, but it 
has never been tested.

There are some issues to consider:

  *   You should set the ip of the keystone in vitrage.conf, and make sure you 
can access it
  *   You will need to install, together with Vitrage, many dependent openstack 
libraries
  *   In order to access Vitrage API, you will either need to install keystone 
on Vitrage environment, or to configure an endpoint for Vitrage in the existing 
openstack
  *   For notifications, you need to connect Vitrage to the oslo bus of the 
existing openstack
BTW, what is the version of this openstack environment?

Best Regards,
Ifat.

From: Yujun Zhang
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Tuesday, 30 August 2016 at 10:06
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: [openstack-dev] [vitrage] inspecting external openstack environment

My purpose is to inspect an **existing** openstack environment with vitrage.

Do I have to install vitrage on the target environment or it can be done by 
proper configuration?

--
Yujun
__
OpenStack Development Mailing 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] inspecting external openstack environment

[Yujun Zhang]

One additional question about openstack datasource.

Is it possible to connect *multiple* openstack data sources, furthermore,
different version of openstack (liberty, newton), at the same time?

To monitor existing systems, this might be a common requirement.

On Thu, Sep 1, 2016 at 5:16 PM Yujun Zhang  wrote:

> Thanks for explanation. I'll give it a try.
>
> Answer to BTW, it is Liberty on Ubuntu 14.04 deployed by Fuel 8.0.
> --
> Yujun
>
> On Wed, Aug 31, 2016 at 2:42 PM Afek, Ifat (Nokia - IL) <
> ifat.a...@nokia.com> wrote:
>
>> Hi Yujun,
>>
>> Using Vitrage for an external openstack environment should be possible,
>> but it has never been tested.
>>
>> There are some issues to consider:
>>
>>- You should set the ip of the keystone in vitrage.conf, and make
>>sure you can access it
>>- You will need to install, together with Vitrage, many dependent
>>openstack libraries
>>- In order to access Vitrage API, you will either need to install
>>keystone on Vitrage environment, or to configure an endpoint for Vitrage 
>> in
>>the existing openstack
>>- For notifications, you need to connect Vitrage to the oslo bus of
>>the existing openstack
>>
>> BTW, what is the version of this openstack environment?
>>
>> Best Regards,
>> Ifat.
>>
>> From: Yujun Zhang
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> Date: Tuesday, 30 August 2016 at 10:06
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> Subject: [openstack-dev] [vitrage] inspecting external openstack
>> environment
>>
>> My purpose is to inspect an **existing** openstack environment with
>> vitrage.
>>
>> Do I have to install vitrage on the target environment or it can be done
>> by proper configuration?
>>
>> --
>> Yujun
>>
>> __
>> OpenStack Development Mailing 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] [release] proposing adding Tony Breeds to "Release Managers" team

[Rochelle Grober]

I have no vote, but my nonvote is a hearty +1 
Tony is amazing.

--Rocky

-Original Message-
From: Amrith Kumar [mailto:amr...@tesora.com] 
Sent: Tuesday, September 06, 2016 10:56 AM
To: d...@doughellmann.com
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [release] proposing adding Tony Breeds to "Release 
Managers" team

Doug,

This is a great addition; Tony's reviews are very helpful, he asks great 
questions and provides insightful feedback. And when you are in a bind, he has 
great suggestions.

+1

Thanks,

-amrith

> -Original Message-
> From: Doug Hellmann [mailto:]
> Sent: Tuesday, September 06, 2016 11:36 AM
> To: openstack-dev 
> Subject: [openstack-dev] [release] proposing adding Tony Breeds to
> "Release Managers" team
> 
> Team,
> 
> I would like to add Tony Breeds to the "Release Managers" team in
> gerrit. This would give him +2 permissions on openstack-infra/release-
> tools
> and on openstack/releases. I feel his reviews on both of those repos
> have already demonstrated a good attention to detail, especially
> of the release schedule and processes.
> 
> Please respond below with +1 or -1.
> 
> Thanks,
> Doug
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

__
OpenStack Development Mailing 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] Fw: [steth] Questions to the project Steth

[hanchao]

An explicit tag would be helpful to catch the eyes of the team. :)


Br,
Chao


-原始邮件-
发件人: "Li Hao" 
发送时间: 2016年9月6日 星期二
收件人: "openstack-dev@lists.openstack.org" 
抄送:
主题: [openstack-dev] 转发: A mail from BJUT student


As a rookie of Openstack and i want to ask you guys a few questions about your 
project Steth so that I can understand more clearly.


1.What's the function limitation of the current version of Steth ?


2.According to the Steth introduction files,Steth just applying to ML2, I can 
not understand that.Why?


3.What's function will your team add to the future version of Steth? 


4.Except for installing the client agent in the target VM, Is there has the 
none-injection solution for the network diagnosis?


It's my first time to send an email to developer,I sincerely hope you can read 
my email and answer my questions. I will be very thanks for that. That means a 
lot to me.


Yours sincerely 




__
OpenStack Development Mailing 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] Make "RedHat RDO CI" vote on tripleo-quickstart changes?

[Emilien Macchi]

On Tue, Sep 6, 2016 at 6:16 AM, Attila Darazs  wrote:
> I think Third party gating is solid enough to make it vote, not just post
> results.
>
> Currently we have a gate job breaking and I almost submitted something
> without everything passing. Would be useful to make it blocking.
>
> Is there any reason not to do this?
>

I don't have a "yes" or a "no" but I have some thoughts here.
My wish is that we would engage more efforts in upstream CI to get
tripleo jobs more stable, reliable and voting.
Some recent efforts have started and we keep making progress; more
folks are engaged in upstream CI and I'm very positive that things
will get better.

I just find it odd that some third party CI would vote while some of
our upstream jobs using TripleO cloud and Nodepool would not be
voting.

Don't consider it as a "no", but just some feedback I would like to share here.

My 2 cents,
-- 
Emilien Macchi

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

Re: [openstack-dev] [tricircle]

[joehuang]

Welcome persisyemcelzy!

From: persistencelzy [persistence...@163.com]
Sent: 06 September 2016 19:22
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [tricircle]

Hello。












__
OpenStack Development Mailing 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] [tricircle]

[joehuang]

Welcome, seems lots of contributors are joining the mail-list and landing in 
tricircle after the message sent in the irc.


From: liukun [kk_li...@163.com]
Sent: 06 September 2016 19:43
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [tricircle]

Tricircle,I am coming!




__
OpenStack Development Mailing 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] [tricircle]

[joehuang]

Welcome yuquanle,  new contributor!

From: yuquanle [yuqua...@126.com]
Sent: 06 September 2016 19:36
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [tricircle]

hello！








__
OpenStack Development Mailing 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] [gnocchi] Support for other drivers - influxdb

[Sam Morrison]

> On 6 Sep 2016, at 11:14 PM, Maxime Belanger  wrote:
> 
> Hey Sam,
> 
> Are the driver you are implementing stores the index in Gnocchi index or 
> directly in influx?
> In other words, are you fully using influx under gnochi API?

Hi Max,

The index lives in gnocchi index much like the other drivers, all that is 
stored in influx db is the samples (time, metric_id, value)

Sam


> Max
> From: Sam Morrison 
> Sent: September 5, 2016 9:24:21 PM
> To: Julien Danjou
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [gnocchi] Support for other drivers - influxdb
>  
> Hi Julien,
> 
> > On 5 Sep 2016, at 5:36 PM, Julien Danjou  wrote:
> > 
> > On Mon, Sep 05 2016, Sam Morrison wrote:
> > 
> > Hi Sam,
> > 
> >> The issue I’m having are with the tests. Because the continuous queries are
> >> asynchronous and there is no current way in influxdb to force them to run 
> >> I get
> >> tests failing due to
> >> them not having run yet.
> >> 
> >> I’m not sure how to get around this issue, apart from the tests failing
> >> everything is working quite well. I’m going to start some load testing 
> >> soon to
> >> see what it’s like when pushing in a lot of metrics.
> > 
> > Does it break the REST API, or only some storage tests?
> 
> REST API is fine, in fact it fixes some tests that influx was failing on.
> 
> > If it's just some storage test, you can change the tests so they are
> > retrying until the operation are done. Either in the test, or via a
> > special flag in the driver – we used to have that in the first version
> > of the driver.
> 
> OK good idea, I’ll work on that.
> 
> 
> >> Wondering if there would be time to talk about this in Barcelona.
> > 
> > Sure.
> 
> Cheers,
> Sam
> 
> 
> > 
> > -- 
> > Julien Danjou
> > -- Free Software hacker
> > -- https://julien.danjou.info 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> __
> OpenStack Development Mailing 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] [release] proposing adding Tony Breeds to "Release Managers" team

[Emilien Macchi]

My vote doesn't count but I still have feedback to share.

As a PTL I have to release multiple projects and Tony was always very
helpful and responsive in the reviews.
I would be super happy to have him part of release managers team.

On Tue, Sep 6, 2016 at 2:17 PM, Jeremy Stanley  wrote:
> On 2016-09-06 14:05:19 -0400 (-0400), Doug Hellmann wrote:
>> Excerpts from Jeremy Stanley's message of 2016-09-06 17:53:57 +:
>> > On 2016-09-06 11:36:01 -0400 (-0400), Doug Hellmann wrote:
>> > > I would like to add Tony Breeds to the "Release Managers" team in
>> > > gerrit. This would give him +2 permissions on 
>> > > openstack-infra/release-tools
>> > > and on openstack/releases. I feel his reviews on both of those repos
>> > > have already demonstrated a good attention to detail, especially
>> > > of the release schedule and processes.
>> > [...]
>> >
>> > Sounds great to me. As PTL over the openstack-infra/release-tools
>> > repo, I don't object.
>>
>> Turf war! [1]
>>
>> Seriously, though, the infra team does play a big role in helping with
>> that repo, so I'm glad to have everyone's input on it.
>>
>> Doug
>>
>> [1] 
>> http://governance.openstack.org/reference/projects/release-management.html#release-tools
>
> Oh--indeed! I missed that it was the only project in the
> openstack-infra namespace belonging to an official team other than
> Infra.
>
> In that case, as an interested (transitive) core reviewer on that
> repo, I heartily agree. ;)
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi

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

Re: [openstack-dev] [nova] Bug team meeting

[Augustina Ragwitz]

I should add that I also expressed interest in taking over the Bug Czar
role. I've been actively involved with the bugs team since Markus
revived it earlier this year. I've run meetings when he was unavailable
and also provided assistance to new folks. How is it normally handled if
more than one person is interested in taking on a subteam "czar" type of
role? Should we co-czar?

-- 
Augustina Ragwitz
Señora Software Engineer
---
Ask me about contributing to OpenStack Nova!
https://wiki.openstack.org/wiki/Nova/Mentoring
---
email: aragwitz+n...@pobox.com
irc: auggy

__
OpenStack Development Mailing 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] [ironic] Driver removal policies - should we make it softer?

[Jim Rollenhagen]

On Tue, Sep 6, 2016 at 4:24 PM, Jim Rollenhagen  wrote:
> On Mon, Aug 29, 2016 at 5:03 AM, Lucas Alvares Gomes
>  wrote:
>> Hi,
>>
>> I overall agree with the proposed plan. I like the idea of having a
>> "supported" flag (or another name as per Kurt's email) that makes it
>> easy mark a driver as "unsupported" indicating it might be removed
>> soon.
>>
>> About point #3 I'm indifferent, it's a common approach in the project
>> to log a warning + release notes to mark something as deprecated and I
>> don't see the real benefit of having an extra Boolean flag to be able
>> to enable certain drivers, it just sounds like an extra pain. If a
>> driver is deprecated in the previous cycle and that
>> "enable_unsupported_drivers" is set to False (the default) after the
>> upgrading the Ironic services the conductor will fail to start and
>> operators will most likely just set it to True straight away. It's not
>> that trivial to replace the deprecated driver on all nodes that are
>> using it (specially if they are active) and IMO, only having the
>> warning message (and release notes) is enough and give people enough
>> time to replace the drivers when possible.
>
> Apologies for taking so long to respond to this thread again.
>
> Sounds like we have rough consensus, with some people expressing
> dislike for #3. Thinking about it more, I actually quite agree, we don't
> need that.
>
> I'll put up patches to make these changes today/tomorrow and we can follow
> up the discussion in Gerrit. Thanks all for chiming in. :)

FYI, the first patch is here: https://review.openstack.org/#/c/366399/

I'll be adding subsequent patches to mark drivers as unsupported, let's
first agree on the framework.

// jim

>
> // jim
>
>>
>> Cheers,
>> Lucas
>>
>> On Tue, Aug 23, 2016 at 3:55 PM, Vladyslav Drok  wrote:
>>>
>>> On Mon, Aug 22, 2016 at 9:48 PM, Loo, Ruby  wrote:

 Hi,



 I admit, I didn't read the entire thread [0], but did read the summary
 [1]. I like this, except that I'm not sure about #3. What's the rationale 
 of
 adding a new config option 'enable_unsupported_drivers' that defaults to
 False. Versus not having it, and "just" logging a warning if they are
 loading an unsupported (in-tree) driver?



 If I understand this...



 If we have 'enable_unsupported_drivers': since it defaults to False, the
 conductor will fail on startup, if an unsupported driver is in the
 enabled_drivers config. (The conductor will emit a warning in the logs, or
 maybe it won't?) The operator (if they haven't changed it), will now change
 it to True if they want to use any unsupported drivers. The conductor will
 start up and emit a warning in the logs.



 If we don't have an enable_unsupported_drivers config, will the conductor
 start up and emit a warning in the logs?
>>>
>>>
>>> We have not added any deprecation warnings to drivers. I think that just
>>> gives a bit more time to switch to other drivers and it will make the
>>> removal more visible, as the current spec states: "Third party driver teams
>>> that do not implement a reliable reporting CI test system by the N release
>>> feature freeze (see Deliverable milestones above) will be removed from the
>>> ironic source tree.", IIUC meaning that conductor will fail startup not
>>> being able to find the removed code.
>>>



 I was also wondering, where is the value for the 'supported' flag for each
 driver going to be kept? Hard-coded in the driver code?
>>>
>>>
>>> Yep, seems like it.
>>>



 --ruby





 On 2016-08-19, 10:15 AM, "Jim Rollenhagen"  wrote:



 Hi Ironickers,



 There was a big thread here[0] about Cinder, driver removal, and standard

 deprecation policy. If you haven't read through it yet, please do before

 continuing here. :)



 The outcome of that thread is summarized well here.[1]



 I know that I previously had a different opinion on this, but I think we

 should go roughly the same route, for the sake of the users.



 1) A ``supported`` flag for each driver that is True if and only if the
 driver

is tested in infra or third-party CI (and meets our third party CI

requirements).

 2) If the supported flag is False for a driver, deprecation is implied
 (and

a warning is emitted at load time). A driver may be removed per
 standard

deprecation policies, with turning the supported flag False to start
 the

clock.

 3) Add a ``enable_unsupported_drivers`` config option that allows enabling

drivers marked supported=False. If a driver is in enabled_drivers, has

Re: [openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

[Matt Riedemann]

On 9/6/2016 2:48 PM, Martin Millnert wrote:

Hi,

  Goal:

I'd like to replicate the industry standard of providing a on-by-
default (UI) option to auto-assign a floating IP to a newly launched
instance. It must be toggleable however (to follow industry standard).


Floating IPs aren't required in OpenStack deployments, and anyone 
running with cells v1 (Rackspace, GoDaddy, NeCTAR, CERN) doesn't use or 
support them, at least without patching Nova. So I'm not sure what 
'industry standard' is being referred to here.




With openstackclient I'm hoping the feature could be added through e.g
"--auto-assign-floating-ip", where it is unspecified where the stateful
glue logic actually resides.


  Scenario:

We use Horizon as UI and OpenContrail as VPC provider, where our
virtual networks by default really are private networks, e.g. following
actual industry standard VPC behaviour.

Our users are today required to themselves perform the Assign Floating
IP operation [1] operation before their instance has achieved what 98%
of users desire. So this is both unexpected for users and likewise far
from industry standard (defaults should make a happy user).


  Problem:

Recognizing that deployments are different, and this probably won't
satisfy 100% of deployments architecture, there is furthermore the
unfortunate situation of:
 - nova: we're not adding anything


Correct, nova provides the APIs to do this already, something sitting on 
top just needs to use them to orchestrate your use case.



 - horizon: UI's not a brain

I'm aware of the "--get-me-a-network" effort which is admirable. I
haven't been on top of its progress, but from what I understand today
it hasn't seen the light of day yet. Any update aligned with my goal
would be helpful.


The get-me-a-network work is complete with the 2.37 API microversion in 
Nova and the 6.0.0 python-novaclient release. You can test it out today. 
However, it does not allocate and auto-assign a floating IP.




So how can one solve an OpenStack cross-project problem like this,
possibly without having to implement an artificial superintelligence
first?


Orchestrate on top of Nova's APIs, either in your own CLI, or UI, or 
maybe even Heat would support this.




For any operators around who've dealt with this, and possibly run a
proprietary UI: Have you perchance added an ... "instance launch
orchestrator" that takes arguments to this dear instance orchestration
platform, seeing that Nova in fact *isn't* an "instance launch
orchestrator" (at least not moddable)?

We're at the point where we want this so much that we'll do it regardless of 
upstream, but I can't for the life of me think that we're alone with the use 
case.

Regards,
Martin Millnert
[1] http://developer.openstack.org/api-ref/networking/v2/index.html?exp
anded=create-floating-ip-detail

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




--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [nova] Bug team meeting

[Augustina Ragwitz]

Hi Timofei,

Based on your post, it sounds like you plan to take over the bug team
meetings? Maybe with Markus stepping down, this could be a good
opportunity to reconsider our meeting schedule. Our meetings are
generally not well attended and I'm not sure if a weekly meeting is
necessary.

Also, the 0800 UTC meeting you mention being cancelled for Sept 13 was
moved to that time from 1000 UTC due to low attendance. Has attendance
improved since that meeting was moved? I don't normally attend it
because it's the middle of the night for me :)

I'm in US Pacific time and it would be very convenient for me to run the
1800 UTC meeting if that's an issue. Alternatively, we could propose a
new time and just have one meeting every other week.

-- 
Augustina Ragwitz
Señora Software Engineer
---
Ask me about contributing to OpenStack Nova!
https://wiki.openstack.org/wiki/Nova/Mentoring
---
email: aragwitz+n...@pobox.com
irc: auggy

__
OpenStack Development Mailing 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] [ironic] Driver removal policies - should we make it softer?

[Jim Rollenhagen]

On Mon, Aug 29, 2016 at 5:03 AM, Lucas Alvares Gomes
 wrote:
> Hi,
>
> I overall agree with the proposed plan. I like the idea of having a
> "supported" flag (or another name as per Kurt's email) that makes it
> easy mark a driver as "unsupported" indicating it might be removed
> soon.
>
> About point #3 I'm indifferent, it's a common approach in the project
> to log a warning + release notes to mark something as deprecated and I
> don't see the real benefit of having an extra Boolean flag to be able
> to enable certain drivers, it just sounds like an extra pain. If a
> driver is deprecated in the previous cycle and that
> "enable_unsupported_drivers" is set to False (the default) after the
> upgrading the Ironic services the conductor will fail to start and
> operators will most likely just set it to True straight away. It's not
> that trivial to replace the deprecated driver on all nodes that are
> using it (specially if they are active) and IMO, only having the
> warning message (and release notes) is enough and give people enough
> time to replace the drivers when possible.

Apologies for taking so long to respond to this thread again.

Sounds like we have rough consensus, with some people expressing
dislike for #3. Thinking about it more, I actually quite agree, we don't
need that.

I'll put up patches to make these changes today/tomorrow and we can follow
up the discussion in Gerrit. Thanks all for chiming in. :)

// jim

>
> Cheers,
> Lucas
>
> On Tue, Aug 23, 2016 at 3:55 PM, Vladyslav Drok  wrote:
>>
>> On Mon, Aug 22, 2016 at 9:48 PM, Loo, Ruby  wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> I admit, I didn't read the entire thread [0], but did read the summary
>>> [1]. I like this, except that I'm not sure about #3. What's the rationale of
>>> adding a new config option 'enable_unsupported_drivers' that defaults to
>>> False. Versus not having it, and "just" logging a warning if they are
>>> loading an unsupported (in-tree) driver?
>>>
>>>
>>>
>>> If I understand this...
>>>
>>>
>>>
>>> If we have 'enable_unsupported_drivers': since it defaults to False, the
>>> conductor will fail on startup, if an unsupported driver is in the
>>> enabled_drivers config. (The conductor will emit a warning in the logs, or
>>> maybe it won't?) The operator (if they haven't changed it), will now change
>>> it to True if they want to use any unsupported drivers. The conductor will
>>> start up and emit a warning in the logs.
>>>
>>>
>>>
>>> If we don't have an enable_unsupported_drivers config, will the conductor
>>> start up and emit a warning in the logs?
>>
>>
>> We have not added any deprecation warnings to drivers. I think that just
>> gives a bit more time to switch to other drivers and it will make the
>> removal more visible, as the current spec states: "Third party driver teams
>> that do not implement a reliable reporting CI test system by the N release
>> feature freeze (see Deliverable milestones above) will be removed from the
>> ironic source tree.", IIUC meaning that conductor will fail startup not
>> being able to find the removed code.
>>
>>>
>>>
>>>
>>> I was also wondering, where is the value for the 'supported' flag for each
>>> driver going to be kept? Hard-coded in the driver code?
>>
>>
>> Yep, seems like it.
>>
>>>
>>>
>>>
>>> --ruby
>>>
>>>
>>>
>>>
>>>
>>> On 2016-08-19, 10:15 AM, "Jim Rollenhagen"  wrote:
>>>
>>>
>>>
>>> Hi Ironickers,
>>>
>>>
>>>
>>> There was a big thread here[0] about Cinder, driver removal, and standard
>>>
>>> deprecation policy. If you haven't read through it yet, please do before
>>>
>>> continuing here. :)
>>>
>>>
>>>
>>> The outcome of that thread is summarized well here.[1]
>>>
>>>
>>>
>>> I know that I previously had a different opinion on this, but I think we
>>>
>>> should go roughly the same route, for the sake of the users.
>>>
>>>
>>>
>>> 1) A ``supported`` flag for each driver that is True if and only if the
>>> driver
>>>
>>>is tested in infra or third-party CI (and meets our third party CI
>>>
>>>requirements).
>>>
>>> 2) If the supported flag is False for a driver, deprecation is implied
>>> (and
>>>
>>>a warning is emitted at load time). A driver may be removed per
>>> standard
>>>
>>>deprecation policies, with turning the supported flag False to start
>>> the
>>>
>>>clock.
>>>
>>> 3) Add a ``enable_unsupported_drivers`` config option that allows enabling
>>>
>>>drivers marked supported=False. If a driver is in enabled_drivers, has
>>>
>>>supported=False, and enable_unsupported_drivers=False, ironic-conductor
>>>
>>>will fail to start. Setting enable_unsupported_drivers=True will allow
>>>
>>>ironic-conductor to start with warnings emitted.
>>>
>>>
>>>
>>> It is important to note that (3) does still technically break the standard
>>>
>>> deprecation policy (old config may not work with new version of ironic).
>>>
>>> However, this is a much 

[openstack-dev] [Horizon][OSC][Nova][Neutron] Launch instance with Floating IP

[Martin Millnert]

Hi,

  Goal:

I'd like to replicate the industry standard of providing a on-by-
default (UI) option to auto-assign a floating IP to a newly launched
instance. It must be toggleable however (to follow industry standard).

With openstackclient I'm hoping the feature could be added through e.g
"--auto-assign-floating-ip", where it is unspecified where the stateful
glue logic actually resides. 


  Scenario:

We use Horizon as UI and OpenContrail as VPC provider, where our
virtual networks by default really are private networks, e.g. following
actual industry standard VPC behaviour.

Our users are today required to themselves perform the Assign Floating
IP operation [1] operation before their instance has achieved what 98%
of users desire. So this is both unexpected for users and likewise far
from industry standard (defaults should make a happy user).


  Problem:

Recognizing that deployments are different, and this probably won't
satisfy 100% of deployments architecture, there is furthermore the
unfortunate situation of:
 - nova: we're not adding anything
 - horizon: UI's not a brain

I'm aware of the "--get-me-a-network" effort which is admirable. I
haven't been on top of its progress, but from what I understand today
it hasn't seen the light of day yet. Any update aligned with my goal
would be helpful.

So how can one solve an OpenStack cross-project problem like this,
possibly without having to implement an artificial superintelligence
first?

For any operators around who've dealt with this, and possibly run a
proprietary UI: Have you perchance added an ... "instance launch
orchestrator" that takes arguments to this dear instance orchestration
platform, seeing that Nova in fact *isn't* an "instance launch
orchestrator" (at least not moddable)?

We're at the point where we want this so much that we'll do it regardless of 
upstream, but I can't for the life of me think that we're alone with the use 
case.

Regards,
Martin Millnert
[1] http://developer.openstack.org/api-ref/networking/v2/index.html?exp
anded=create-floating-ip-detail

__
OpenStack Development Mailing 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] Bug team meeting

[Timofei Durakov]

Hello everyone,

Bug team meeting on Sept. 13 is canceled. So the next time it will be Sept.
20 18:00 UTC.
By that time I'll update agenda [1], everyone is welcome to do the same.

Timofey

[1] - https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kuryr] Kuryr-Kubernetes devstack proposal for testing

[Antoni Segura Puimedon]

Hi Kuryrs!

Yesterday in the meeting we discussed about the need to design a way for the
functional testing to happen for the Kuryr-Kubernetes integration. I studied
the possibilities today and came up with the following proposal (After the
proposal I'll put more detailed explanations).

Prerequisites
=
Usual services:
* Neutron and its agents (LBaaSv2 included)
* Keystone

Devstack plugin
===

* Installs Docker just like kuryr-libnetwork's plugin
* Installs Docker compose
* Pulls gcr.io/google_containers/hyperkube-amd64:v1.3.6
* Pulls quay.io/coreos/etcd:v3.0.7
* Runs in --net=host:
  * coreos/etcd
  * google_containers/hyperkube /setup-files.sh
  * google_containers/hyperkube /hyperkube apiserver
  * google_containers/hyperkube /hyperkube controller-manager
  * google_containers/hyperkube /hyperkube scheduler
  * google_containers/hyperkube /hyperkube kubelet with the Kuryr CNI driver
mounted as a volume
* Starts the Kuryr Watcher pointing to the apiserver as a devstack service

After the steps above, we can use a python kubernetes client to run the tests.

apiserver
-
This is what the Kuryr watcher connects to. Example parameters for running the
hyperkube container::

--service-cluster-ip-range=10.0.0.1/24 \
--insecure-bind-address=0.0.0.0 \
--insecure-port=8080 \
--etcd-servers=http://${LOCAL_IP}:2379 \

--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota
\
--client-ca-file=/srv/kubernetes/ca.crt \
--basic-auth-file=/srv/kubernetes/basic_auth.csv \
--min-request-timeout=300 \
--tls-cert-file=/srv/kubernetes/server.cert \
--tls-private-key-file=/srv/kubernetes/server.key \
--token-auth-file=/srv/kubernetes/known_tokens.csv \
--allow-privileged=true \
--v=2 \
--logtostderr=true

controller-manager
--
It will be running the plugin for LoadBalancer service type in the future.
Example parameters for running the hyperkube container::

--master=127.0.0.1:8080 \
--service-account-private-key-file=/srv/kubernetes/server.key \
--root-ca-file=/srv/kubernetes/ca.crt \
--min-resync-period=3m \
--v=2 \
--logtostderr=true

scheduler
-
To do the hard job of scheduling to the only kubelet. Example parameters for
running the hyperkube container::

  --master=127.0.0.1:8080 \
  --service-account-private-key-file=/srv/kubernetes/server.key \
  --root-ca-file=/srv/kubernetes/ca.crt \
  --min-resync-period=3m \
  --v=2 \
  --logtostderr=true

Kubelet
---
It needs to run in privileged mode and with the following volumes::

--volume=/:/rootfs:ro \
--volume=/sys:/sys:ro \
--volume=/var/lib/docker/:/var/lib/docker:rw \
--volume=/var/lib/kubelet/:/var/lib/kubelet:rw \
--volume=/var/run:/var/run:rw \
--volume=/var/log/kuryr:/var/log/kuryr \
--net=host \
--privileged=true \
--pid=host

It also needs the CNI driver, which should be mounted as a volume from the
current /opt/stack/kuryr-kubernetes source. However, the container is not
likely to have Python, so I propose to build a CNI binary with python-install
and mount just the binary.

The example parameters to run it would be::
--allow-privileged=true \  # this we can probably omit for tests
--api-servers="http://127.0.0.1:8080; \
--v=2 \
--address='0.0.0.0' \
--enable-server \
--containerized \
--network-plugin=cni

Why Hyperkube and compose instead of minikube?
==

Hyperkube provides us with more flexibility to run the building blocks that we
need for the integration, like not running kube-proxy. It also can run easily
without modification in the OpenStack CI jenkins worker with little resources.

Minikube spawns a Virtual Machine using Docker Machine. This means that it
would need more resources and make its Keystone/Neutron usage more complicated.
It could prossibly be hacked to use the Docker Machine generic SSH driver and
point it to the same machine, but I find it going to too much trouble compared
to the simplicity of the solution above.


Why Hyperkube and compose instead of just running kubernetes from src
=
Kubernetes building would take a high amount of resources ~8GiB and more time
than pulling the hyperkube containers. However, this is a decision that we may
want to revisit once we start contributing the kuryr cloud provider to
Kubernetes (for the loadbalancer service type).

---
---
---

Please, all Kuryrs, feel welcome to dispute the proposal and claims above and
to propose alternatives. After a bit of discussion we can propose a blueprint
and start implementing.


Regards,

Toni

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

Re: [openstack-dev] [oslo] [telemetry] Oslo.db 4.13.1 broke Gnocchi

[Joshua Harlow]

Tony Breeds wrote:

On Fri, Sep 02, 2016 at 12:29:04PM -0400, Mike Bayer wrote:

is the failure here something that comes up in gnocchi's test suite?

Could there be some way that oslo libraries run the test suites of all
consuming projects before a patch and/or a release?  (apologies if we
already do this).


There are a couple of ways to do this.

Build an integration style job or enhance the cross-project gateing stuff we
use in requirements.  Either is doable the challenge will be deciding which
projects to use/balancing gate resources.

If you look at the repos managed my the requirements team[1] there are 40
users of oslo.db[2].  If you look at all the repos listed in [3] That number 
grows
to 66.  Clearly gating on all of them isn't viable.

Ther are lots of ways to do this better, especially in a one of in-formal
fashion.  I wonder if it's worth trting to define a really easy way for
everyone.


Ya, also the fact that we have the following to:

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

We catch some of these issues via that but some still get through 
(because as u said 66+ projects and periodically running them is 
non-trivial of a problem).


I'd be more than open to new ideas and new solutions here though, 
because it helps the quality of everything improve if we have those (and 
also makes it so people don't yell 'u broke me' at the oslo folks, ha).




Tony.
[1] http://git.openstack.org/cgit/openstack/requirements/tree/projects.txt
[2] This list doen't include gnocchi
[3] 
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml


__
OpenStack Development Mailing 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] [new][oslo] oslo.db 4.13.2 release (newton)

[no-reply]

We are excited to announce the release of:

oslo.db 4.13.2: Oslo Database library

This release is part of the newton stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslo.db

With package available at:

https://pypi.python.org/pypi/oslo.db

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.db

For more details, please see below.

Changes in oslo.db 4.13.1..4.13.2
-

bf3b21f utils: fix get_unique_keys() when model has no table attached to it
067fc46 Update .gitreview for stable/newton


Diffstat (except docs and test files)
-

.gitreview |  1 +
oslo_db/sqlalchemy/utils.py| 31 -
3 files changed, 61 insertions(+), 12 deletions(-)




__
OpenStack Development Mailing 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] [release] proposing adding Tony Breeds to "Release Managers" team

[Jeremy Stanley]

On 2016-09-06 14:05:19 -0400 (-0400), Doug Hellmann wrote:
> Excerpts from Jeremy Stanley's message of 2016-09-06 17:53:57 +:
> > On 2016-09-06 11:36:01 -0400 (-0400), Doug Hellmann wrote:
> > > I would like to add Tony Breeds to the "Release Managers" team in
> > > gerrit. This would give him +2 permissions on 
> > > openstack-infra/release-tools
> > > and on openstack/releases. I feel his reviews on both of those repos
> > > have already demonstrated a good attention to detail, especially
> > > of the release schedule and processes.
> > [...]
> > 
> > Sounds great to me. As PTL over the openstack-infra/release-tools
> > repo, I don't object.
> 
> Turf war! [1]
> 
> Seriously, though, the infra team does play a big role in helping with
> that repo, so I'm glad to have everyone's input on it.
> 
> Doug
> 
> [1] 
> http://governance.openstack.org/reference/projects/release-management.html#release-tools

Oh--indeed! I missed that it was the only project in the
openstack-infra namespace belonging to an official team other than
Infra.

In that case, as an interested (transitive) core reviewer on that
repo, I heartily agree. ;)
-- 
Jeremy Stanley

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

Re: [openstack-dev] [release] proposing adding Tony Breeds to "Release Managers" team

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2016-09-06 17:53:57 +:
> On 2016-09-06 11:36:01 -0400 (-0400), Doug Hellmann wrote:
> > I would like to add Tony Breeds to the "Release Managers" team in
> > gerrit. This would give him +2 permissions on openstack-infra/release-tools
> > and on openstack/releases. I feel his reviews on both of those repos
> > have already demonstrated a good attention to detail, especially
> > of the release schedule and processes.
> [...]
> 
> Sounds great to me. As PTL over the openstack-infra/release-tools
> repo, I don't object.

Turf war! [1]

Seriously, though, the infra team does play a big role in helping with
that repo, so I'm glad to have everyone's input on it.

Doug

[1] 
http://governance.openstack.org/reference/projects/release-management.html#release-tools

__
OpenStack Development Mailing 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] resignation from bug czar role

[Augustina Ragwitz]

It's been great working with you and you've done such a great job with
the bugs team!

I'd be more than happy to pick up the Bug Czar role and continue with
the great work you started.

-- 
Augustina Ragwitz
Señora Software Engineer
---
Ask me about contributing to OpenStack Nova!
https://wiki.openstack.org/wiki/Nova/Mentoring
---
email: aragwitz+n...@pobox.com
irc: auggy

__
OpenStack Development Mailing 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] [release] proposing adding Tony Breeds to "Release Managers" team

[Amrith Kumar]

Doug,

This is a great addition; Tony's reviews are very helpful, he asks great 
questions and provides insightful feedback. And when you are in a bind, he has 
great suggestions.

+1

Thanks,

-amrith

> -Original Message-
> From: Doug Hellmann [mailto:]
> Sent: Tuesday, September 06, 2016 11:36 AM
> To: openstack-dev 
> Subject: [openstack-dev] [release] proposing adding Tony Breeds to
> "Release Managers" team
> 
> Team,
> 
> I would like to add Tony Breeds to the "Release Managers" team in
> gerrit. This would give him +2 permissions on openstack-infra/release-
> tools
> and on openstack/releases. I feel his reviews on both of those repos
> have already demonstrated a good attention to detail, especially
> of the release schedule and processes.
> 
> Please respond below with +1 or -1.
> 
> Thanks,
> Doug
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [release] proposing adding Tony Breeds to "Release Managers" team

[Jeremy Stanley]

On 2016-09-06 11:36:01 -0400 (-0400), Doug Hellmann wrote:
> I would like to add Tony Breeds to the "Release Managers" team in
> gerrit. This would give him +2 permissions on openstack-infra/release-tools
> and on openstack/releases. I feel his reviews on both of those repos
> have already demonstrated a good attention to detail, especially
> of the release schedule and processes.
[...]

Sounds great to me. As PTL over the openstack-infra/release-tools
repo, I don't object.
-- 
Jeremy Stanley

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

[openstack-dev] [tripleo] TripleO-UI status for TripleO RC1

[Jiri Tomasek]

Hey all,

here is a summary of TripleO-UI related TripleO RC1 work:

Tripleo-common patches required by TripleO-UI:

- roles listing: https://review.openstack.org/#/c/330283/
- validations run_groups workflow fix: 
https://review.openstack.org/#/c/366055/
- Include environments which aren't specified in capabilities-map in 
capabilities output: https://review.openstack.org/#/c/355598/
- wire in jinja templating: https://review.openstack.org/#/c/362465/ + 
any other custom roles patches or patches which clean up the parameters 
defined in overcloud.yaml

- set deployment parameters  https://review.openstack.org/365625

Tripleo-heat-templates patches required by TripleO-UI:

- capabilities map update: https://review.openstack.org/#/c/364842/

Instack-undercloud patches required by TripleO-UI:

- enable_ui patch:  https://review.openstack.org/#/c/344140/ (+ any 
dependent puppet-* patches) - this needs to get tested and verified that 
all requirements specified in 
https://blueprints.launchpad.net/tripleo-ui/+spec/instack-undercloud-ui-config 
are fulfilled


Mistral patches required by TripleO-UI:

- make execution output optionally part of executions listing: 
https://review.openstack.org/#/c/364446/ (MERGED, mistral package with 
this patch needs to be installed with TripleO RC1



TripleO RC1 TripleO-UI work is tracked at TripleO-UI launchpad marked as 
RC1 series https://blueprints.launchpad.net/tripleo-ui/rc1 . We're in 
good progress so far considering that the work on those items started on 
Thursday last week.
Patches waiting for review are available here: 
https://review.openstack.org/#/q/project:openstack/tripleo-ui


We'd need to get back end dependencies merged as soon as possible, so 
the work which depends on those can be implemented in relatively stable 
environment.



Thanks

-- Jirka


__
OpenStack Development Mailing 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] [api][doc][neutron] what releases should API reference support?

[Sean Dague]

On 09/06/2016 11:42 AM, Ihar Hrachyshka wrote:
> Jeremy Stanley  wrote:
> 
>> On 2016-09-06 15:36:42 +0200 (+0200), Andreas Jaeger wrote:
>>> On 2016-09-06 15:30, Ihar Hrachyshka wrote:
 Andreas Jaeger  wrote:

> On 2016-09-06 15:02, Ihar Hrachyshka wrote:
>> [...]
>> Since neutron-lib is branched on stable/* boundary, I feel that it
>> would
>> be fine to keep one-to-one relationship between neutron and
>> neutron-lib
>> api-ref branches.
>
> We only publish the api-ref documents from master,

 Is it a hard requirement from infra, or just the current state of
 affairs? If the latter, we could revisit the approach. If the
 former, of
 course we will accommodate.
>>>
>>> It's the current state of affair - and how api-ref was designed AFAIK:
>>> To have one tree,
>>
>> The argument for this stems from the fact that it's documenting an
>> API, not the software providing that API. While Neutron has releases
>> and stable branches, your API _doesn't_ (I hope!).
>>
>> If I, as an end user/application author want to use your API, it's
>> entirely unlikely I'll even know what version of Neutron any random
>> provider is running. Likewise, my application/library need not
>> figure out what release of Neutron is in use to be able to interact
>> with its API, it should only need to know the reported API version.
>> The most complete picture of the Neutron API will, in theory, be
>> reflected in the API documentation in the master branch (and for
>> given objects/methods/parameters should mention the earliest _API_
>> version where they appear).
> 
> The particular case under discussion is that in Newton, Neutron removed
> LBaaS v1 API (it was deprecated for quite some time). Users are able to
> detect the presence (or absence) of the API as before, by checking if
> corresponding API extension alias is in the list of active API
> extensions as returned by /extensions neutron API. Now, in Newton, the
> extension is *always* disabled, because there is no way to enable it
> (the code is gone). In Mitaka and Liberty though, it depends on whether
> the lbaasv1 service plugin is enabled in particular setup.
> 
> There are two related but separate questions here:
> - is there time when we can drop API from api-ref when it’s removed in
> code?
> - if so, when is it: right when the API is dropped, or when all branches
> supporting it are gone? or should we document the non-existing API
> indefinitely?

The solution we've been using in Nova is "fix it in english". We move
deprecated stuff towards the end of the document, mark it deprecated,
and add explanatory language around the API about it.
http://developer.openstack.org/api-ref/compute/#ping-instances-os-fping-deprecated
is maybe a reasonable example.

The important thing is that if you have multiple versions of your API
reference document, no one will know if they are on the right one. If
you have one version, and explain "this has been removed, might not be
in your installation, you can find out if it's available with X Y Z".
Then all consumers have the same view of the world, will know they are
on the one true document.

When do delete is tricky. There are public clouds running Kilo right
now. So 4 cycles at least if you don't want to strand users.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [ironic] API v.next meeting cancelled

[Jim Rollenhagen]

On Tue, Sep 6, 2016 at 1:23 PM, Jim Rollenhagen  wrote:
> We're cancelling the next two meetings as well, for the same reason.
>
> We'll meet again on September 27.

I'm bad at counting, apparently, the next meeting will be September 20.

// jim

>
> On Tue, Aug 30, 2016 at 1:32 PM, Jim Rollenhagen  
> wrote:
>> Sorry for the late notice, but we decided we'd rather keep working on
>> Newton things this week instead of having this meeting, so it's
>> cancelled for today.
>>
>> // jim

__
OpenStack Development Mailing 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] [ironic] API v.next meeting cancelled

[Jim Rollenhagen]

We're cancelling the next two meetings as well, for the same reason.

We'll meet again on September 27.

// jim


On Tue, Aug 30, 2016 at 1:32 PM, Jim Rollenhagen  
wrote:
> Sorry for the late notice, but we decided we'd rather keep working on
> Newton things this week instead of having this meeting, so it's
> cancelled for today.
>
> // jim

__
OpenStack Development Mailing 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][taas] On TaaS not capturing some packets between two VMs on the same host

[Anil Rao]

Hi Takashi,

Yes, this update was for bug 1529595.

Thanks,
Anil

-Original Message-
From: Takashi Yamamoto [mailto:yamam...@midokura.com] 
Sent: Monday, September 05, 2016 11:29 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][taas] On TaaS not capturing some packets 
between two VMs on the same host

hi,

On Sat, Sep 3, 2016 at 7:32 AM, Anil Rao  wrote:
> Hello,
>
> Here is an update on the issue of not being able to capture packets 
> flowing between two VMs on the same host.

it it about bug 1529595 ?
https://bugs.launchpad.net/tap-as-a-service/+bug/1529595

>
> Isolating the problem:
>
> It has been confirmed that the TaaS OVS driver cannot capture packets 
> ingressing (flowing into) a VM’s vNIC under the following conditions:
>
> - The sender port and the receiver port (which is being monitored) 
> reside on the same host.
>
> - The sender port and the receiver port are attached to the same 
> (virtual) network.
>
> We do not have a problem in the above situation for traffic egressing 
> (flowing out) of the VM’s vNIC. We also do not have a problem if the 
> sender port and receiver port are on different hosts, or if the sender 
> and receiver ports belong to different (virtual) networks.
>
> Trafffic Capture Technique:
>
> The implementation uses the following methods to capture packets 
> flowing into and out of a VM’s vNIC.
>
> Egress Side (flowing out of the vNIC):
>
> The ‘in_port=’ check is used to identify packets coming 
> in from the port associated with the VM’s vNIC. This allows us to 
> capture all packets flowing out of the vNIC under question. No problems here.
>
> Ingress Side (flowing into the vNIC):
>
> The ‘dl_vlan=, dl_dst=’ check is used 
> to identify packets destined for the port associated with the VM’s vNIC.
>
> The VLAN tag check was put in place because Neutron port MAC addresses 
> are required to be unique only within a (virtual) network. Now each 
> instance port in br-int gets tagged with a VLAN id that is the same 
> for all ports on that host, which are associated with a particular 
> (virtual) network. Ports belonging to different (virtual) networks 
> therefore get tagged with different VLAN ids.
>
> The combination of “VLAN tag + destination MAC address” was felt to be 
> a sufficient check to ensure that we are truly dealing with traffic 
> heading out of the port being monitored.
>
> Root Cause of the problem:
>
> The br-int bridge operates using the legacy (or normal) mode of operation.
> We have observed that under these circumstances, OVS does not add VLAN 
> tags to packets, as long as they are flowing within the bridge. 
> Packets escaping from br-int into br-tun (via the patch ports), 
> however, get tagged as expected when they arrive in br-tun.
>
> Due to this behavior, our ingress side flow (described above) fails to 
> capture packets flowing into a VM’s vNIC, when it is originating from 
> another port on the same host and on the same virtual network.
>
> Possible Solutions:

i think the it can be fixed by having rules to "tag" packets explicitly.
ie. match on inport and record the logical network in openflow metadata.
(or ovs registers, which is basically the same thing) as it's planned to be 
done for ovs-agent extensions:
https://review.openstack.org/#/c/320439/

>
> OVS documentation (refer: Open vSwitch FAQ) seems to recommend not 
> using the normal operating mode, but handling VLANs explicitly, if 
> flows related to VLAN ids are going to be used.  As mentioned above, 
> to ensure that we correctly handle the Neutron requirement that port 
> MAC addresses are unique only within a virtual network, we need to add 
> VLAN related checks to the TaaS flows. However, br-int today relies on 
> the normal operation mode for most of its work.
>
> This has left us now in a quandary situation. Here is a proposal to 
> move us
> forward:
>
> 1.   As a temporary fix, we can convert the TaaS ingress side flow in
> br-int from
>
> dl_vlan=, dl_dst=
>
> to
>
> dl_dst=
>
> This will obviously mean that we no longer support the notion that 
> Neutron port MAC addresses are unique only within a virtual network. 
> However, given that the probability of two port MAC addresses on a 
> host being the same is low, this should suffice for the short term.

i agree this is the easiest workaround.

>
> [We will also disable the flows used to capture broadcast/multicast 
> traffic flowing into a VM’s vNIC]
>
> 2.   Implement VLAN handling explicitly in br-int and thereby move away
> from the normal operating mode. This will be a core Neutron change and 
> not limited to just TaaS. However, I have the feeling that there will 
> be other projects (outside of TaaS) that will sooner or later have a 
> need to detect traffic flowing into a vNIC and they will also run into 
> the same issue we are presently facing.

i'm all for moving away from port based "internal" 

Re: [openstack-dev] [api][doc][neutron] what releases should API reference support?

[Jeremy Stanley]

On 2016-09-06 17:42:03 +0200 (+0200), Ihar Hrachyshka wrote:
[...]
> There are two related but separate questions here:
> - is there time when we can drop API from api-ref when it’s removed in code?
> - if so, when is it: right when the API is dropped, or when all branches
> supporting it are gone? or should we document the non-existing API
> indefinitely?

Agreed, this is where opinions are going to start coming into play
because there's a trade-off in trying to maintain documentation for
dead-end features indefinitely. Ideally you'd keep it documented
until such time as you feel there's not enough people likely to
still be relying on the documentation for that feature in the wild
(once major service providers and distributions are no longer
supporting it). That could be a long time though, and there are no
easy answers... it's a matter of your documentation authors weighing
cost and benefit to pick an appropriate time for the project and its
downstream consumers.

Though hopefully once you do drop it, there's not much burden to
indefinitely maintaining a note in the documentation acknowledging
that it used to exist (perhaps mentioning the location in revision
control from where the old documentation source could be exhumed)?
-- 
Jeremy Stanley

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

[openstack-dev] [neutron] not passing objects into registered extensions

[Ihar Hrachyshka]

Hi,

we have this latent bug where we pass objects for subnetpools into  
extension functions. (That was a mistake made when switching to using  
objects in base db plugin for the resource.) Now, we want to revert to  
passing db models as we did before, so that our plugin api is consistent  
and reflects what we had before.


The patch that would achieve that is at:  
https://review.openstack.org/#/c/348279/


The patch is still a slight WIP, and also has concerns from @zzzeek around  
using populate_existing, same concerns as found in Kevin’s patch at:  
https://review.openstack.org/#/c/364301/


While we are still shaping the patches, it would be wise to land some of  
dependencies that are just cosmetic changes to objects API and test  
framework. Specifically, we’ll need:


https://review.openstack.org/#/c/348271/
https://review.openstack.org/#/c/366052/

Those pass CI right now, and would be actually valuable irrelevant to the  
result of the discussion with @zzzeek.


Thanks for reviews,
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] [release] proposing adding Tony Breeds to "Release Managers" team

[Nikhil Komawar]

+1. def.


I have always found his reviews quite detailed and constructive.


On 9/6/16 11:36 AM, Doug Hellmann wrote:
> Team,
>
> I would like to add Tony Breeds to the "Release Managers" team in
> gerrit. This would give him +2 permissions on openstack-infra/release-tools
> and on openstack/releases. I feel his reviews on both of those repos
> have already demonstrated a good attention to detail, especially
> of the release schedule and processes.
>
> Please respond below with +1 or -1.
>
> Thanks,
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing 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]Table renames in the contract phase in db upgrade breaks rolling upgrade from Mitaka to Newton

[Ihar Hrachyshka]

Gyorgy Szombathelyi  wrote:





-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]

Gyorgy Szombathelyi  wrote:


Hi!

Maybe I'm overseeing something, but I'm wondering if table renames
breaks rolling upgrades.


Yes, they would. Do you suggest that we allowed such a migration anywhere
in Newton?

Well, if you don't count the contract phase, then of course not.


E.g. if I'm upgrading neutron server instances one-by-one, and doing a
db expand during the process, the old neutron-server instances will
continue to work. However, without the new renamed tables, the new
instances won't work.  Just would be good to know:


With the current approach to neutron-server upgrades that neutron team
supports, we don’t allow new neutron-servers running while contract phase
is not applied yet. The process is documented at:

http://docs.openstack.org/developer/neutron/devref/upgrade.html#server
-upgrade

Ah, OK, then I misunderstood it.


- In this form, why the expand phase is useful? The expanded database
won't work with a new server instance, and it is not required for the
older ones.


It contains operations that are safe to execute while old neutron-server
instances are running. After expansion happens, you must shutdown all
neutron-servers, then apply contract phase, then start your new neutron-
servers. This is the only scenario currently supported.
Ok, understand. However I don't think there's a big difference in  
execution time
between a contract or an just upgrade head, so for not too big  
installations,
the two-phase upgrade can be skipped safely, I think.  There'll be not  
much more

downtime.


The split is a foundational work for the next step of forbidding any data  
migration in contraction phase, and postponing schema contraction to later  
when it’s safe to execute it (+2 releases from the time of the  
corresponding expansion schema change). I agree that the way it’s  
implemented just now is not saving much time, and does not provide you with  
no downtime. We are looking into this direction though, so stay tuned.





- Actually what would be the workflow for a downtime-less upgrade?
From Liberty to Mitaka it worked fairly good, even without using
expand-contract.


Depending on what you mean by asking for downtime-less. If it’s data plane
wise, current agents should be able to work and upgrade without disrupting
any data flows. If you suggest that neutron API should be available at all
times, then this scenario is just not supported at this moment.

While your mileage may vary, I really doubt you could safely upgrade L->M
without API downtime. You are either lucky, or you just haven’t noticed
some failures. The way we currently handle database access does not
accommodate for no-downtime upgrade process for api endpoints. We are
looking into implementing some form of it in Ocata, but only time will  
tell if

we succeed to deliver. Until then, you can’t avoid API downtime.


Since the old instances could work more or less with the new SQL schema  
(at least
I didn't notice any immediate failures, and looking at the Mitaka  
contract code, it

is not so intrusive), it was fairly good with this process:
- remove one neutron-server from the LB
- upgrade it
- upgrade the schema
- put it back to the LB
- remove the other neutron-servers from the LB
- upgrade them
- put back them to the LB


Then you were lucky. :)



From Mitaka to Newton, the new instance immediately fails because of the  
renaming
ml2_dvr_port_bindings and ml2_network_segments tables, and the old  
instances

also fail if they started after the renames (contract).
But if it is designed this way, I should accept it then.


Yeah, it was never meant to work. If it worked for your isolated case, it’s  
pure luck. You should have bought a lottery ticket!


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]Table renames in the contract phase in db upgrade breaks rolling upgrade from Mitaka to Newton

[Gyorgy Szombathelyi]

> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> 
> Gyorgy Szombathelyi  wrote:
> 
> > Hi!
> >
> > Maybe I'm overseeing something, but I'm wondering if table renames
> > breaks rolling upgrades.
> 
> Yes, they would. Do you suggest that we allowed such a migration anywhere
> in Newton?
> 
Well, if you don't count the contract phase, then of course not.

> > E.g. if I'm upgrading neutron server instances one-by-one, and doing a
> > db expand during the process, the old neutron-server instances will
> > continue to work. However, without the new renamed tables, the new
> > instances won't work.  Just would be good to know:
> 
> With the current approach to neutron-server upgrades that neutron team
> supports, we don’t allow new neutron-servers running while contract phase
> is not applied yet. The process is documented at:
> 
> http://docs.openstack.org/developer/neutron/devref/upgrade.html#server
> -upgrade
> 
Ah, OK, then I misunderstood it.

> > - In this form, why the expand phase is useful? The expanded database
> > won't work with a new server instance, and it is not required for the
> > older ones.
> 
> It contains operations that are safe to execute while old neutron-server
> instances are running. After expansion happens, you must shutdown all
> neutron-servers, then apply contract phase, then start your new neutron-
> servers. This is the only scenario currently supported.
> 
Ok, understand. However I don't think there's a big difference in execution time
between a contract or an just upgrade head, so for not too big installations,
the two-phase upgrade can be skipped safely, I think.  There'll be not much more
downtime.

> > - Actually what would be the workflow for a downtime-less upgrade?
> > From Liberty to Mitaka it worked fairly good, even without using
> > expand-contract.
> 
> Depending on what you mean by asking for downtime-less. If it’s data plane
> wise, current agents should be able to work and upgrade without disrupting
> any data flows. If you suggest that neutron API should be available at all
> times, then this scenario is just not supported at this moment.
> 
> While your mileage may vary, I really doubt you could safely upgrade L->M
> without API downtime. You are either lucky, or you just haven’t noticed
> some failures. The way we currently handle database access does not
> accommodate for no-downtime upgrade process for api endpoints. We are
> looking into implementing some form of it in Ocata, but only time will tell if
> we succeed to deliver. Until then, you can’t avoid API downtime.

Since the old instances could work more or less with the new SQL schema (at 
least
I didn't notice any immediate failures, and looking at the Mitaka contract 
code, it
is not so intrusive), it was fairly good with this process:
- remove one neutron-server from the LB
- upgrade it
- upgrade the schema
- put it back to the LB
- remove the other neutron-servers from the LB
- upgrade them
- put back them to the LB

From Mitaka to Newton, the new instance immediately fails because of the 
renaming 
ml2_dvr_port_bindings and ml2_network_segments tables, and the old instances
also fail if they started after the renames (contract).
But if it is designed this way, I should accept it then.

> 
> Ihar
> 
Br,
György
__
OpenStack Development Mailing 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] [api][doc][neutron] what releases should API reference support?

[Anne Gentle]

On Tue, Sep 6, 2016 at 10:44 AM, Ihar Hrachyshka 
wrote:

> Alexander  wrote:
>
> FYI,
>>
>> A similar discussion was held for an api-ref change in Glance:
>> https://review.openstack.org/#/c/356693/
>>
>
> Thanks for the link, it led me to this discussion:
> http://lists.openstack.org/pipermail/openstack-dev/2016-August/101501.html
>
> From the looks of it, seems like the result of the discussion is glance
> folks tagging new API with micro-versions. In Neutron, we don’t have
> micro-versioning, though we have /extensions API that would allow to detect
> if a particular API is available. In particular case of dropping lbaasv1,
> it would mean we keep reference for the API for some time while stating
> it’s never available in Newton+?


Glance does not have microversioning either.

Yes, you need to keep the API reference for quite a long time (years). In
one page, note that the API version for the service is not available for
deployment in Newton+.

Anne


>
>
> Ihar
>



-- 
Anne Gentle
www.justwriteclick.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] [release] proposing adding Tony Breeds to "Release Managers" team

[Thierry Carrez]

Davanum Srinivas wrote:
> +1 Welcome Tony!

+1
Hopefully we won't break him by stretching him even more :)

-- 
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] [api][doc][neutron] what releases should API reference support?

[Ihar Hrachyshka]

Alexander  wrote:


FYI,

A similar discussion was held for an api-ref change in Glance:
https://review.openstack.org/#/c/356693/


Thanks for the link, it led me to this discussion:
http://lists.openstack.org/pipermail/openstack-dev/2016-August/101501.html

From the looks of it, seems like the result of the discussion is glance  
folks tagging new API with micro-versions. In Neutron, we don’t have  
micro-versioning, though we have /extensions API that would allow to detect  
if a particular API is available. In particular case of dropping lbaasv1,  
it would mean we keep reference for the API for some time while stating  
it’s never available in Newton+?


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] [oslo] [telemetry] Oslo.db 4.13.1 broke Gnocchi

[Joshua Harlow]

Thanks Ihar for taking the lead on this while everyone in the US was 
(mostly) on vacation, much appreciated :)


Ihar Hrachyshka wrote:

Ihar Hrachyshka  wrote:


Julien Danjou  wrote:


On Fri, Sep 02 2016, Mike Bayer wrote:


I've augmented it with mapper-level SQLAlchemy API use.


Awesome, thanks. :)

And "augmented" makes it sounds so futurist, whoohhh. :)


Ouch, sorry for that bug in my patch. :-|

Now that the fix landed master, we can proceed with stable/newton
backport: https://review.openstack.org/#/c/365227/ Once it lands, we
can request a new Newton release.

I also requested a block for oslo.db 4.13.1 in openstack/requirements:
https://review.openstack.org/#/c/365565/

Ihar


Backport landed. Requested a new oslo.db release for newton:
https://review.openstack.org/#/c/366160/

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] [api][doc][neutron] what releases should API reference support?

[Ihar Hrachyshka]

Jeremy Stanley  wrote:


On 2016-09-06 15:36:42 +0200 (+0200), Andreas Jaeger wrote:

On 2016-09-06 15:30, Ihar Hrachyshka wrote:

Andreas Jaeger  wrote:


On 2016-09-06 15:02, Ihar Hrachyshka wrote:

[...]
Since neutron-lib is branched on stable/* boundary, I feel that it  
would

be fine to keep one-to-one relationship between neutron and neutron-lib
api-ref branches.


We only publish the api-ref documents from master,


Is it a hard requirement from infra, or just the current state of
affairs? If the latter, we could revisit the approach. If the former, of
course we will accommodate.


It's the current state of affair - and how api-ref was designed AFAIK:
To have one tree,


The argument for this stems from the fact that it's documenting an
API, not the software providing that API. While Neutron has releases
and stable branches, your API _doesn't_ (I hope!).

If I, as an end user/application author want to use your API, it's
entirely unlikely I'll even know what version of Neutron any random
provider is running. Likewise, my application/library need not
figure out what release of Neutron is in use to be able to interact
with its API, it should only need to know the reported API version.
The most complete picture of the Neutron API will, in theory, be
reflected in the API documentation in the master branch (and for
given objects/methods/parameters should mention the earliest _API_
version where they appear).


The particular case under discussion is that in Newton, Neutron removed  
LBaaS v1 API (it was deprecated for quite some time). Users are able to  
detect the presence (or absence) of the API as before, by checking if  
corresponding API extension alias is in the list of active API extensions  
as returned by /extensions neutron API. Now, in Newton, the extension is  
*always* disabled, because there is no way to enable it (the code is gone).  
In Mitaka and Liberty though, it depends on whether the lbaasv1 service  
plugin is enabled in particular setup.


There are two related but separate questions here:
- is there time when we can drop API from api-ref when it’s removed in code?
- if so, when is it: right when the API is dropped, or when all branches  
supporting it are gone? or should we document the non-existing API  
indefinitely?


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] [release] proposing adding Tony Breeds to "Release Managers" team

[Davanum Srinivas]

+1 Welcome Tony!

-- Dims

On Tue, Sep 6, 2016 at 11:36 AM, Doug Hellmann  wrote:
> Team,
>
> I would like to add Tony Breeds to the "Release Managers" team in
> gerrit. This would give him +2 permissions on openstack-infra/release-tools
> and on openstack/releases. I feel his reviews on both of those repos
> have already demonstrated a good attention to detail, especially
> of the release schedule and processes.
>
> Please respond below with +1 or -1.
>
> Thanks,
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: https://twitter.com/dims

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

[openstack-dev] [release] proposing adding Tony Breeds to "Release Managers" team

[Doug Hellmann]

Team,

I would like to add Tony Breeds to the "Release Managers" team in
gerrit. This would give him +2 permissions on openstack-infra/release-tools
and on openstack/releases. I feel his reviews on both of those repos
have already demonstrated a good attention to detail, especially
of the release schedule and processes.

Please respond below with +1 or -1.

Thanks,
Doug

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

Re: [openstack-dev] [api][doc][neutron] what releases should API reference support?

[Jeremy Stanley]

On 2016-09-06 15:36:42 +0200 (+0200), Andreas Jaeger wrote:
> On 2016-09-06 15:30, Ihar Hrachyshka wrote:
> > Andreas Jaeger  wrote:
> > 
> >> On 2016-09-06 15:02, Ihar Hrachyshka wrote:
> >>> [...]
> >>> Since neutron-lib is branched on stable/* boundary, I feel that it would
> >>> be fine to keep one-to-one relationship between neutron and neutron-lib
> >>> api-ref branches.
> >>
> >> We only publish the api-ref documents from master,
> > 
> > Is it a hard requirement from infra, or just the current state of
> > affairs? If the latter, we could revisit the approach. If the former, of
> > course we will accommodate.
> 
> It's the current state of affair - and how api-ref was designed AFAIK:
> To have one tree,

The argument for this stems from the fact that it's documenting an
API, not the software providing that API. While Neutron has releases
and stable branches, your API _doesn't_ (I hope!).

If I, as an end user/application author want to use your API, it's
entirely unlikely I'll even know what version of Neutron any random
provider is running. Likewise, my application/library need not
figure out what release of Neutron is in use to be able to interact
with its API, it should only need to know the reported API version.
The most complete picture of the Neutron API will, in theory, be
reflected in the API documentation in the master branch (and for
given objects/methods/parameters should mention the earliest _API_
version where they appear).
-- 
Jeremy Stanley

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

[openstack-dev] [cinder] moving driver to open source

[Alon Marx]

I want to share our plans to open the IBM Storage driver source code. 
Historically we started our way in cinder way back (in Essex if I'm not 
mistaken) with just a small piece of code in the community while keeping 
most of the driver code closed. Since then the code has grown, but we kept 
with the same format. We would like now to open the driver source code, 
while keeping the connectivity to the storage as closed source. 
I believe that there are other cinder drivers that have some stuff in 
proprietary libraries. I want to propose and formalize the principles to 
where we draw the line (this has also been discussed in 
https://review.openstack.org/#/c/341780/) on what's acceptable by the 
community.
Based on previous discussion I understand that the rule of thumb is "as 
long as the majority of the driver logic is in the public driver" the 
community would be fine with that. Is this acceptable to the community?

Regards,
Alon
 
  






__
OpenStack Development Mailing 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] [api][doc][neutron] what releases should API reference support?

[Bashmakov, Alexander]

FYI,

A similar discussion was held for an api-ref change in Glance:
https://review.openstack.org/#/c/356693/

On Sep 6, 2016, at 6:39 AM, Andreas Jaeger 
> wrote:

On 2016-09-06 15:30, Ihar Hrachyshka wrote:
Andreas Jaeger > wrote:

On 2016-09-06 15:02, Ihar Hrachyshka wrote:
[...]
Since neutron-lib is branched on stable/* boundary, I feel that it would
be fine to keep one-to-one relationship between neutron and neutron-lib
api-ref branches.

We only publish the api-ref documents from master,

Is it a hard requirement from infra, or just the current state of
affairs? If the latter, we could revisit the approach. If the former, of
course we will accommodate.

It's the current state of affair - and how api-ref was designed AFAIK:
To have one tree,

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

[openstack-dev] [new][horizon] XStatic-smart-table 1.4.13.2 release

[no-reply]

We are jubilant to announce the release of:

XStatic-smart-table 1.4.13.2: smart-table 1.4.13 (XStatic packaging
standard)

With package available at:

https://pypi.python.org/pypi/XStatic-smart-table

For more details, please see below.

Changes in XStatic-smart-table 1.4.13.1..1.4.13.2
-

3989e1f Update using xstatic-release 1.2.1
f1e9270 Fix description metadata


Diffstat (except docs and test files)
-

setup.cfg   |  2 +-
setup.py| 24 
xstatic/pkg/angular_smart_table/__init__.py |  2 +-
3 files changed, 18 insertions(+), 10 deletions(-)




__
OpenStack Development Mailing 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]Table renames in the contract phase in db upgrade breaks rolling upgrade from Mitaka to Newton

[Gyorgy Szombathelyi]

Hi!

Maybe I'm overseeing something, but I'm wondering if table renames breaks 
rolling upgrades.
E.g. if I'm upgrading neutron server instances one-by-one, and doing a db 
expand during the process,
the old neutron-server instances will continue to work. However, without the 
new renamed tables, the
new instances won't work.  Just would be good to know:
- In this form, why the expand phase is useful? The expanded database won't 
work with a new server instance, and it is not required for the older ones.
- Actually what would be the workflow for a downtime-less upgrade? From Liberty 
to Mitaka it worked fairly good, even without
using expand-contract.

Br,
György

__
OpenStack Development Mailing 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]Table renames in the contract phase in db upgrade breaks rolling upgrade from Mitaka to Newton

[Ihar Hrachyshka]

Gyorgy Szombathelyi  wrote:


Hi!

Maybe I'm overseeing something, but I'm wondering if table renames breaks  
rolling upgrades.


Yes, they would. Do you suggest that we allowed such a migration anywhere  
in Newton?


E.g. if I'm upgrading neutron server instances one-by-one, and doing a db  
expand during the process,
the old neutron-server instances will continue to work. However, without  
the new renamed tables, the

new instances won't work.  Just would be good to know:


With the current approach to neutron-server upgrades that neutron team  
supports, we don’t allow new neutron-servers running while contract phase  
is not applied yet. The process is documented at:


http://docs.openstack.org/developer/neutron/devref/upgrade.html#server-upgrade

- In this form, why the expand phase is useful? The expanded database  
won't work with a new server instance, and it is not required for the  
older ones.


It contains operations that are safe to execute while old neutron-server  
instances are running. After expansion happens, you must shutdown all  
neutron-servers, then apply contract phase, then start your new  
neutron-servers. This is the only scenario currently supported.


- Actually what would be the workflow for a downtime-less upgrade? From  
Liberty to Mitaka it worked fairly good, even without

using expand-contract.


Depending on what you mean by asking for downtime-less. If it’s data plane  
wise, current agents should be able to work and upgrade without disrupting  
any data flows. If you suggest that neutron API should be available at all  
times, then this scenario is just not supported at this moment.


While your mileage may vary, I really doubt you could safely upgrade L->M  
without API downtime. You are either lucky, or you just haven’t noticed  
some failures. The way we currently handle database access does not  
accommodate for no-downtime upgrade process for api endpoints. We are  
looking into implementing some form of it in Ocata, but only time will tell  
if we succeed to deliver. Until then, you can’t avoid API downtime.


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-dev] [nova] Nova API sub-team meeting

[Alex Xu]

Hi,

We have weekly Nova API meeting tomorrow. The meeting is being held
Wednesday UTC1300 and irc channel is #openstack-meeting-4.

The proposed agenda and meeting details are here:

https://wiki.openstack.org/wiki/Meetings/NovaAPI

Please feel free to add items to the agenda.

Thanks
__
OpenStack Development Mailing 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] [puppet] [plumgrid-puppet] Proposal to create plumgrid-puppet

[Emilien Macchi]

On Tue, Sep 6, 2016 at 10:28 AM, Qasim Sarfraz  wrote:
>
>>
>> It is not clear to me what this module would deploy.
>> Could you give more details here?
>> Would it deploy PLUMgrid IO Visor and dependencies?
>
> It will install PLUMgrid SDN Platform and PLUMgrid IO Visor which are
> dependencies for PLUMgrid Neutron Plugin. All the calls from PLUMgrid
> Neutron Plugin are redirected to our SDN Platform which provide networking
> in an OpenStack cloud. This new module help us integrate better with
> community installers including TripleO, Fuel etc.
>
> Hope it explains.

Yup, got it.
openstack/puppet-midonet does similar tasks to deploy Midonet SDN; you
could maybe follow this path? They aren't in Puppet Openstack forge
but still use OpenStack Infra, sounds like a good deal.
I'm not sure if puppet-plumgrid would be a good candidate to be part
of Puppet OpenStack, for 2 reasons:
- it's not really an OpenStack project, but it wouldn't  be a blocker
- it deploys proprietary software so I don't know how we could test
the module in upstream CI.

Anyway, feedback is welcome on this thing and I'm open to help you to
get a Puppet module in OpenStack.

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



-- 
Emilien Macchi

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

Re: [openstack-dev] [release][diskimage-builder] v2 branch request

[Thierry Carrez]

Ian Wienand wrote:
> diskimage-builder would like to request a feature/v2 branch.
> [...]

Sure thing.
What would you like the branching SHA to be ? Current HEAD ?
We can continue this discussion on #openstack-release.

-- 
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] [puppet] [plumgrid-puppet] Proposal to create plumgrid-puppet

[Qasim Sarfraz]

> It is not clear to me what this module would deploy.
> Could you give more details here?
> Would it deploy PLUMgrid IO Visor and dependencies?
>
It will install PLUMgrid SDN Platform and PLUMgrid IO Visor which are
dependencies for PLUMgrid Neutron Plugin. All the calls from PLUMgrid
Neutron Plugin are redirected to our SDN Platform which provide networking
in an OpenStack cloud. This new module help us integrate better with
community installers including TripleO, Fuel etc.

Hope it explains.

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

[openstack-dev] [release][requirements] late release requests

[Doug Hellmann]

Although we are in a release freeze for libraries, we have several
bug fix release requests. We're evaluating these on a case-by-case
basis, and processing some of them. To make that easier, please
make sure to include information about the critical bugs being fixed
by the proposed release when you submit the patch to openstack/releases.
We're going to ask anyway, so including the information up front will
save everyone time.

Thanks,
Doug

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

Re: [openstack-dev] [Rally] Rename some placeholders in task HTML report

[Roman Vasilets]

Hi,

1) lets call it for the times - Overview
2) Actions statistics - because there is a statistic by actions
3) I suggest to keep it. And add to the docs that we have idle and load
durations. I think people not fully understand those two terms and to
change report is not the best way to improve their knowledges

--Best regards, Roman Vasylets.

On Thu, Sep 1, 2016 at 2:56 PM, Aleksandr Maretskiy  wrote:

> Hi all,
>
> this is about terminology in Rally task HTML report.
>
> Some placeholders sounds not accurate and another even confusing,
> which causes repeated questions and even bug reports like [1].
>
> That is why I would like to discuss renaming here.
>
> Please take a look at attached "demo.png", there are 3 placeholders to
> discuss:
>
> 1) Menu item "Task overview"
>
> Report can be generated for workloads from a single task or from 1000
> tasks,
> however overview table shows workloads data, not task(s).
> So I recommend to rename this placeholder.
>
> Proposals:
>
>  * Overview
>  * Workloads overview
>  * Summary
>  * ... ideas?
>
> 2) Subtitle "Total durations"
>
> "Total" is something complete or summarized, however there is a statistics
> values table under this header. The table is about durations statistics
> (both atomic actions and iterations load durations).
>
> Proposals:
>
>  * Durations
>  * Durations statistics
>  * ... ideas?
>
>
> 3) Action "total" in durations statistics table
>
> That is the most confusing placeholder, because it is easy to suppose
> that this row is for summarized values for each column.
> But this row is actually about iterations "load_duration" values.
>
> Proposals:
>
>  * iteration duration
>  * load duration
>  * load_duration
>  * ... ideas?
>
>
> [1] https://bugs.launchpad.net/rally/+bug/1607804
>
> __
> OpenStack Development Mailing 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] [oslo] [telemetry] Oslo.db 4.13.1 broke Gnocchi

[Ihar Hrachyshka]

Ihar Hrachyshka  wrote:


Julien Danjou  wrote:


On Fri, Sep 02 2016, Mike Bayer wrote:


I've augmented it with mapper-level SQLAlchemy API use.


Awesome, thanks. :)

And "augmented" makes it sounds so futurist, whoohhh. :)


Ouch, sorry for that bug in my patch. :-|

Now that the fix landed master, we can proceed with stable/newton  
backport: https://review.openstack.org/#/c/365227/ Once it lands, we can  
request a new Newton release.


I also requested a block for oslo.db 4.13.1 in openstack/requirements:  
https://review.openstack.org/#/c/365565/


Ihar


Backport landed. Requested a new oslo.db release for newton:  
https://review.openstack.org/#/c/366160/


Ihar


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing 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-ovn] Team Meeting

[Richard Theis]

A formal networking-ovn team meeting has been setup. The first meeting
is this Thursday 18:00 UTC. See [1] for meeting details. See [2] for
meeting agenda.

[1] https://review.openstack.org/#/c/363906/
[2] https://etherpad.openstack.org/p/networking-ovn-meeting__
OpenStack Development Mailing 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] [api][doc][neutron] what releases should API reference support?

[Andreas Jaeger]

On 2016-09-06 15:30, Ihar Hrachyshka wrote:
> Andreas Jaeger  wrote:
> 
>> On 2016-09-06 15:02, Ihar Hrachyshka wrote:
>>> [...]
>>> Since neutron-lib is branched on stable/* boundary, I feel that it would
>>> be fine to keep one-to-one relationship between neutron and neutron-lib
>>> api-ref branches.
>>
>> We only publish the api-ref documents from master,
> 
> Is it a hard requirement from infra, or just the current state of
> affairs? If the latter, we could revisit the approach. If the former, of
> course we will accommodate.

It's the current state of affair - and how api-ref was designed AFAIK:
To have one tree,

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

Re: [openstack-dev] [api][doc][neutron] what releases should API reference support?

[Ihar Hrachyshka]

Andreas Jaeger  wrote:


On 2016-09-06 15:02, Ihar Hrachyshka wrote:

[...]
Since neutron-lib is branched on stable/* boundary, I feel that it would
be fine to keep one-to-one relationship between neutron and neutron-lib
api-ref branches.


We only publish the api-ref documents from master,


Is it a hard requirement from infra, or just the current state of affairs?  
If the latter, we could revisit the approach. If the former, of course we  
will accommodate.


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-dev] [architecture] Architecture WG Meeting time proposed - Thursdays, 1900 UTC [poppy]

[Clint Byrum]

Hi! We still have not landed the arch-wg spec [1] just yet, but there
seems to be broad base consensus. So I believe it is time to start
having regular IRC meetings to keep forward momentum.

I've proposed [2] that we have meetings on Thursdays at 1900 UTC. I
noticed that Poppy was scheduled to meet at that time, but has not held
a meeting since January, so I've proposed that we replace their slot in
#openstack-meeting-alt.

I understand this time might not be perfect for everyone, so _please_
let's get this figured out soon. Weigh in on the review, and if we get
enough -1's, we can do a doodle poll. Thanks everyone!

[1] https://review.openstack.org/335141
[2] https://review.openstack.org/366127

__
OpenStack Development Mailing 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] Seeking Mobile Beta Testers

[Jimmy McArthur]

Hi all -

I've got a handful of volunteers (BCC'd here), which should be plenty 
for round 1. Please expect some further communication with me this 
afternoon with details on how to access the app, what to test, and to 
log in, etc...


Thank you for the assist!
Jimmy McArthur


Major Hayden 
September 6, 2016 at 8:04 AM

I'll gladly help with Android testing on my Moto X.

--
Major Hayden
Jimmy McArthur 
September 2, 2016 at 12:57 PM
We're looking for a handful of community members to test our updated 
OpenStack Summit mobile Apps. If you're interested, shoot me a note, 
along with iOS/Android preference, and we'll get you set up.


Thank you,
Jimmy McArthur



__
OpenStack Development Mailing 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] [api][doc][neutron] what releases should API reference support?

[Andreas Jaeger]

On 2016-09-06 15:02, Ihar Hrachyshka wrote:
> [...]
> Since neutron-lib is branched on stable/* boundary, I feel that it would
> be fine to keep one-to-one relationship between neutron and neutron-lib
> api-ref branches.

We only publish the api-ref documents from master,

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

Re: [openstack-dev] [api][doc][neutron] what releases should API reference support?

[John Davidge]

On 9/6/16, 2:02 PM, "Ihar Hrachyshka"  wrote:

>Akihiro Motoki  wrote:
>
>> What releases should we support in API references?
>> There are several options.
>>
>> 1. The latest stable release + master
>> 2. All supported stable releases + master
>> 3. more older releases too?
>>
>> Option 2 sounds reasonable to me.
>>
>> This question is raised in the neutron api-ref patch [1].
>> This patch drops the API reference of LBaaS v1 which was dropped in
>> Newton release.
>> At least Newton is not released yet, so I think it is better to keep
>> it until Newton is released.
>>
>> I would like to get a community consensus before moving this patch
>>forward.
>>
>> Thanks,
>> Akihiro
>
>Since neutron-lib is branched on stable/* boundary, I feel that it would
>be
>fine to keep one-to-one relationship between neutron and neutron-lib
>api-ref branches.
>
>The only reason why keeping all stable branches described in master would
>
>be ease of maintenance, because you don¹t need to backport any api-ref
>related fixes to previous branches.
>
>So, I would not vote for any of 3 options suggested. Instead, I would
>keep
>master api-ref documenting just the latest (master) neutron API, and keep
>
>stable releases documented in corresponding branches whenever they differ.
>
>Of course it will require to solve an issue of publishing api-ref for
>each
>of supported branches instead of just master.
>
>Ihar

I¹m inclined to agree with Ihar on this. Now that the api ref lives in
neutron-lib I think it makes sense for it to track master. If it lived
elsewhere and wasn¹t so closely coupled with release branches then option
2 would be best, but as Ihar says, the ref for older releases can belong
in the relevant branch.

John



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.

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

Re: [openstack-dev] [api][doc][neutron] what releases should API reference support?

[Akihiro Motoki]

2016-09-06 22:02 GMT+09:00 Ihar Hrachyshka :
> Akihiro Motoki  wrote:
>
>> What releases should we support in API references?
>> There are several options.
>>
>> 1. The latest stable release + master
>> 2. All supported stable releases + master
>> 3. more older releases too?
>>
>> Option 2 sounds reasonable to me.
>>
>> This question is raised in the neutron api-ref patch [1].
>> This patch drops the API reference of LBaaS v1 which was dropped in
>> Newton release.
>> At least Newton is not released yet, so I think it is better to keep
>> it until Newton is released.
>>
>> I would like to get a community consensus before moving this patch
>> forward.
>>
>> Thanks,
>> Akihiro
>
>
> Since neutron-lib is branched on stable/* boundary, I feel that it would be
> fine to keep one-to-one relationship between neutron and neutron-lib api-ref
> branches.
>
> The only reason why keeping all stable branches described in master would be
> ease of maintenance, because you don’t need to backport any api-ref related
> fixes to previous branches.
>
> So, I would not vote for any of 3 options suggested. Instead, I would keep
> master api-ref documenting just the latest (master) neutron API, and keep
> stable releases documented in corresponding branches whenever they differ.
>
> Of course it will require to solve an issue of publishing api-ref for each
> of supported branches instead of just master.
>
> Ihar

Good point.

As you mentioned, the current way of publishing API references is from
the master branch.
So at the moment we need to provide API references for stable releases
in the master branch.

I honestly would like to align the way of publishing Networking API
reference with of other projects.
I'd wait input from the docs team leading this effort.

Thanks,
Akihiro

>
>
> __
> OpenStack Development Mailing 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] [gnocchi] Support for other drivers - influxdb

[Maxime Belanger]

Hey Sam,


Are the driver you are implementing stores the index in Gnocchi index or 
directly in influx?

In other words, are you fully using influx under gnochi API?


Max


From: Sam Morrison 
Sent: September 5, 2016 9:24:21 PM
To: Julien Danjou
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [gnocchi] Support for other drivers - influxdb

Hi Julien,

> On 5 Sep 2016, at 5:36 PM, Julien Danjou  wrote:
>
> On Mon, Sep 05 2016, Sam Morrison wrote:
>
> Hi Sam,
>
>> The issue I’m having are with the tests. Because the continuous queries are
>> asynchronous and there is no current way in influxdb to force them to run I 
>> get
>> tests failing due to
>> them not having run yet.
>>
>> I’m not sure how to get around this issue, apart from the tests failing
>> everything is working quite well. I’m going to start some load testing soon 
>> to
>> see what it’s like when pushing in a lot of metrics.
>
> Does it break the REST API, or only some storage tests?

REST API is fine, in fact it fixes some tests that influx was failing on.

> If it's just some storage test, you can change the tests so they are
> retrying until the operation are done. Either in the test, or via a
> special flag in the driver – we used to have that in the first version
> of the driver.

OK good idea, I’ll work on that.


>> Wondering if there would be time to talk about this in Barcelona.
>
> Sure.

Cheers,
Sam


>
> --
> Julien Danjou
> -- Free Software hacker
> -- https://julien.danjou.info


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

[Doug Hellmann]

Excerpts from joehuang's message of 2016-09-06 02:12:45 +:
> 
> > A full rewrite of the library that doesn't take under consideration the 
> > existing
> > deployed technologies is not going to be of any help, IMHO. The reason being
> > that upgradability would be broken and that's a no-go. I believe Clynt was
> > trying to make the same point when he brought up the choice of backends up.
> 
> +1.
> 
> That's why I proposed to provide plugin mechanism in Nova/Cinder API layer, 
> this layer
> abstract can hide the difference of messaging library, and ensure the

oslo.messaging is the abstraction layer you're looking for. Put the new
features there.

Doug

> existing implementation always work and successfully fallback during upgrade 
> if necessary
> and this way makes the upgrade easier to manage, and a cleaner and more steady
> interface to do improvement step by step.
> 
> Best Regards
> Chaoyi Huang (joehuang)
> 
> 
> From: Flavio Percoco [fla...@redhat.com]
> Sent: 05 September 2016 20:52
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all][massively 
> distributed][architecture]Coordination between actions/WGs
> 
> On 05/09/16 18:55 +0700, Ian Wells wrote:
> >On 5 September 2016 at 17:08, Flavio Percoco  wrote:
> >
> >> We should probably start by asking ourselves who's really being bitten by
> >> the
> >> messaging bus right now? Large (and please, let's not bikeshed on what a
> >> Large
> >> Cloud is) Clouds? Small Clouds? New Clouds? Everyone?
> >> The we can start asking ourselves things like: Would a change of the
> >> API/underlying technology help them? Why? How? What technology exactly and
> >> why?
> >> What technology would make their lives simpler and why?
> >>
> >
> >Well, as far as RabbitMQ goes, then I would certainly say in deployment
> >it's not a pleasant thing to work with.  Even if you consider it good
> >enough day to day (which is debatable) then consider its upgradeability -
> >it's impractical to keep it running as you upgrade it, is my
> >understanding.  It would also seem to be a big factor in our scale
> >limitations - I wonder if we could do without such complexities as cells if
> >we had something a bit more performant (with perhaps a more lax operating
> >model).
> >
> >But this is not about blaming Rabbit for all our problems.  The original
> >statement was that RPC is a bad pattern to use in occasionally unreliable
> >distributed systems, and Rabbit in no ways forces us to use RPC patterns.
> >That we don't see the RPC pattern's problems so clearly is because a fault
> >happening at just the right time in a call sequence to show up the problem
> >rarely happens, and testing such a fault using injection is not practical -
> >but it does happen in reality and things do go weird when it happens.
> >
> >The proposal was to create a better interface in oslo for a comms model
> >(that we could implement - and regardless of how we chose to implement it -
> >and that would encourage people to code for the corner cases) and then
> >encourage people to move across.
> >
> >I'm not saying this research/work is not useful/important (in fact, I've
> >> been
> >> advocating for it for almost 2 years now) but I do want us to be more
> >> careful
> >> and certainly I don't think this change should be anything but transparent
> >> for
> >> every deployment out there.
> >>
> >
> >That is a perfectly reasonable thing to ask.  I presume by transparent you
> >mean that the standard upgrade approaches will work.
> >
> >To answer this topic more directly. As much as being opinionated would help
> >> driving focus and providing a better result here, I believe we are not
> >> there yet
> >> and I also believe a backend agnostic API would be more benefitial to begin
> >> with. We're not going to move 98% of the OpenStack deployments out there
> >> off of
> >> rabbitmq just like that.
> >>
> >
> >Again, this originally wasn't about Rabbit, or having a choice of
> >backends.  One backend would do if that backend were perfect for the job.
> >There are other reasons for doing this that would hopefully make OpenStack
> >more robust.
> 
> I did not mean to say Rabbit is to blame, if anything I meant to say that 
> things
> have gotten better from the Rabbit side. My point is that OPs/Deployments must
> be taken under consideration on this refactor.
> 
> A full rewrite of the library that doesn't take under consideration the 
> existing
> deployed technologies is not going to be of any help, IMHO. The reason being
> that upgradability would be broken and that's a no-go. I believe Clynt was
> trying to make the same point when he brought up the choice of backends up.
> 
> As I mentioned in my previous email, I'm all for having a better messaging API
> that is backend agnostic, even if we end up using a single backend in the Z^2
> release.
> 
> Hope it's clearer now,
> Flavio
> 

Re: [openstack-dev] [api][doc][neutron] what releases should API reference support?

[Ihar Hrachyshka]

Akihiro Motoki  wrote:


What releases should we support in API references?
There are several options.

1. The latest stable release + master
2. All supported stable releases + master
3. more older releases too?

Option 2 sounds reasonable to me.

This question is raised in the neutron api-ref patch [1].
This patch drops the API reference of LBaaS v1 which was dropped in
Newton release.
At least Newton is not released yet, so I think it is better to keep
it until Newton is released.

I would like to get a community consensus before moving this patch forward.

Thanks,
Akihiro


Since neutron-lib is branched on stable/* boundary, I feel that it would be  
fine to keep one-to-one relationship between neutron and neutron-lib  
api-ref branches.


The only reason why keeping all stable branches described in master would  
be ease of maintenance, because you don’t need to backport any api-ref  
related fixes to previous branches.


So, I would not vote for any of 3 options suggested. Instead, I would keep  
master api-ref documenting just the latest (master) neutron API, and keep  
stable releases documented in corresponding branches whenever they differ.


Of course it will require to solve an issue of publishing api-ref for each  
of supported branches instead of just master.


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] [api][doc][neutron] what releases should API reference support?

[Miguel Angel Ajo Pelayo]

Option 2 sounds reasonable to me too. :)

On Tue, Sep 6, 2016 at 2:39 PM, Akihiro Motoki  wrote:
> What releases should we support in API references?
> There are several options.
>
> 1. The latest stable release + master
> 2. All supported stable releases + master
> 3. more older releases too?
>
> Option 2 sounds reasonable to me.
>
> This question is raised in the neutron api-ref patch [1].
> This patch drops the API reference of LBaaS v1 which was dropped in
> Newton release.
> At least Newton is not released yet, so I think it is better to keep
> it until Newton is released.
>
> I would like to get a community consensus before moving this patch forward.
>
> Thanks,
> Akihiro
>
> [1] https://review.openstack.org/#/c/362838/
>
> __
> OpenStack Development Mailing 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] [api][doc][neutron] what releases should API reference support?

[Akihiro Motoki]

What releases should we support in API references?
There are several options.

1. The latest stable release + master
2. All supported stable releases + master
3. more older releases too?

Option 2 sounds reasonable to me.

This question is raised in the neutron api-ref patch [1].
This patch drops the API reference of LBaaS v1 which was dropped in
Newton release.
At least Newton is not released yet, so I think it is better to keep
it until Newton is released.

I would like to get a community consensus before moving this patch forward.

Thanks,
Akihiro

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

__
OpenStack Development Mailing 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] [Fuel] New version of fuel-devops (3.0.2)

[Alexey Stepanov]

Hi all!
We are gong to release fuel-devops framework version 3.0.2.
This thread is in active development.

Changes since 3.0.1:

- Do not print `k e y s` if no environments registered (Bug #1605599) [1]
- Extend _ManageSSH docstring with a note for current directory [2]
- Fix documentation about install fuel-devops 3.0.x with different DB [3]
- Configure 'stp' per l2_network_device (Bug #1608518) [4]
- Create address_pools and network_pools for each OpenStack network (Bug
#1598315) [5]
- Fix unit test for decorators [6]
- Use exit codes enum (standard codes only) [7]
- Add timeout to open_session as made in Paramiko sources [8]
- Open PTY on channel before command execution, if required (Bug #1607402)
[9]
- Rework get_sudo [10]
- Drop deprecated code: QA side has been updated (API changes) [11]
- Allow additional arguments for Subprocess class [12]
- Revert "Temporary compatibility layer for numhosts property support." [13]
- SSHAuth object: copy into SSHClient instance on create [14]
- Make coverage report human-readable (Gates report) [15]
- Implement sftp.stat for file attributes read [16]
- Use 'verbose' and argument in subprocess_runner. Non blocking real-time
display output of command [17]
- Use repr in debug output of SSH and subprocess (fixes sometimes
reproduces UnicodeDecodeErrors) [18]
- Bump fuel-devops master branch version up to 3.0.2 [19]

List of all changes is available on github [20].

[1]
https://github.com/openstack/fuel-devops/commit/41bfaa96526c167d0ae151bba595f3b1fb2f0d80
[2]
https://github.com/openstack/fuel-devops/commit/26f9ab7dbc23fb54d7304bbb3f211f79df7b081c
[3]
https://github.com/openstack/fuel-devops/commit/08d0520f7a3f0a7ddb9405cf416afe25b55ed60b
[4]
https://github.com/openstack/fuel-devops/commit/03d8e6643d3bb7aa72baf7ae81488e33f479b462
[5]
https://github.com/openstack/fuel-devops/commit/088df926390c40230893b9c08e59d78d0e7e2815
[6]
https://github.com/openstack/fuel-devops/commit/3c3b1e988bf8e1b69f890e9569962f93f260d02c
[7]
https://github.com/openstack/fuel-devops/commit/6ea70501911d48d395203944cc5a0b85b393ac8d
[8]
https://github.com/openstack/fuel-devops/commit/944f953caf065fe086aff1bafb5eb285ab92714f
[9]
https://github.com/openstack/fuel-devops/commit/642962f4e124bb491939471e90a1c1b4247d5d9f
[10]
https://github.com/openstack/fuel-devops/commit/4166448427f459dec59c1121e9f3ce49dd7b8317
[11]
https://github.com/openstack/fuel-devops/commit/35cc8ec0d1c8f5ee70a7005951342771b0713a3c
[12]
https://github.com/openstack/fuel-devops/commit/b0c9a7d0f8520518f565a135be5d00d3203da9a7
[13]
https://github.com/openstack/fuel-devops/commit/48fcf848a5e1ebf77fd613f285aae3aa2e76ff93
[14]
https://github.com/openstack/fuel-devops/commit/a34dc163b6e72abf34fe3a0d66280a9938a80850
[15]
https://github.com/openstack/fuel-devops/commit/07a2791259d05d758c4cc995100ed9eeb643018e
[16]
https://github.com/openstack/fuel-devops/commit/56f97c5bf8c63ab586a2149d610ebc341c200734
[17]
https://github.com/openstack/fuel-devops/commit/bb3e7b058668cdc1f8edaf424f891d101a459260
[18]
https://github.com/openstack/fuel-devops/commit/060ab8eaebb3f8faabfbeaf935544f5621fc29ff
[19]
https://github.com/openstack/fuel-devops/commit/5c94ae2886927421d9f59b245b59e557dc2869a7

[20] https://github.com/openstack/fuel-devops/compare/3.0.1...master

-- 
Alexey Stepanov
__
OpenStack Development Mailing 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] resignation from bug czar role

[Sean Dague]

On 09/05/2016 07:19 AM, Markus Zoeller wrote:

> Thanks a lot to the people who helped making Nova a better project by
> doing bug triage! Special thanks to auggy who put a lot(!) of effort
> into that.
> 
> See you (hopefully) in Barcelona!

Thanks you for all your service here. It's been invaluable.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Congress] Enabling Remote Debugging

[Aimee Ukasick]

Thanks all for your feedback.
I'll work on the changes Tues and push to Gerrit as a WIP.
Eric - thanks for pointing out eventlet.monkey_patch(thread=False). I
read about
that last week and will include pertinent info in the patch.

aimee

On Fri, Sep 2, 2016 at 1:34 PM, Tim Hinrichs  wrote:
> I'd be concerned about merging a change to eventlet this late in the cycle.
> Threading problems are notoriously difficult to find during testing.  I'd
> recommend pushing the patch to Gerrit, so that we can all try it out when
> debugging, and we check it in after the Newton release.
>
> Eric, +1 to your general advice.
>
> I wouldn't expect a blueprint or even a bug for a code-change that only
> impacts developers, unless you want to socialize the idea before writing the
> code or the code is substantial.  If writing the code is small and easy, and
> no one will have much to say before seeing that code, I'd just push a patch
> to gerrit and see what people think.
>
> Tim
>
>
> On Fri, Sep 2, 2016 at 2:31 AM Masahito MUROI 
> wrote:
>>
>> Hi Aimee,
>>
>> Thanks let us know.
>>
>> I don't think it has a big impact to the current architecture and
>> user/dev. So it seems to be good to report it as a bug and target the
>> fix to N-release.
>>
>> best regards,
>> Masahito
>>
>> On 2016/09/02 10:10, Eric K wrote:
>> > Hi Aimee,
>> >
>> > Thanks for digging into it!
>> >
>> > Here¹s my understanding of our conventions (and I¹m happy to hear from
>> > others).
>> >
>> > a. If you think it¹s just a straightforward change with zero to minimal
>> > impact on architecture, users, and devs, then it makes sense to file a
>> > bug
>> > or just submit a patch.
>> > b. If you think it warrants deeper discussion in terms of design,
>> > impact,
>> > etc., then the process is to create a spec and associated blueprint. See
>> > this wiki for more details:
>> > https://wiki.openstack.org/wiki/Blueprints#Spec_.2B_Blueprints_lifecycle
>> >
>> > In case (b), the change should target the O-cycle because we¹re past
>> > feature-freeze in N.
>> > In case (a), it may make sense to get it in during the N-cycle if it has
>> > minimal impact and will help us in the N-cycle QA process.
>> >
>> > My guess is we¹re in case (a) because we can make sure changes have no
>> > impact without a special flag. But I¹d also like to understand a little
>> > better the impact of eventlet.monkey_patch(thread=False) as done in the
>> > Keystone patch
>> > (https://review.openstack.org/#/c/18404/3/bin/keystone-all).
>> >
>> > Enjoy the time holidays!
>> >
>> > On 9/1/16, 11:45 AM, "Aimee Ukasick" 
>> > wrote:
>> >
>> >> HI all - I've been trying to configure remote debugging with PyCharm
>> >> and DevStack. It looks like some tiny modifications need to be made to
>> >> the Congress code (3-4 files) to support remote debugging via pydevd.
>> >>
>> >> As far as I can tell, support has been added to Keystone, Glance,
>> >> Nova, and Manilla (and I'm sure others).
>> >>
>> >> Keystone patch: https://review.openstack.org/#/c/18404/3
>> >> Glance patch: https://review.openstack.org/#/c/18748/5
>> >>
>> >> I think it would be very beneficial to support remote debugging, and
>> >> I'm willing to implement the changes needed. Should I create a bug for
>> >> this or draft a blueprint?
>> >>
>> >> I'm out of office 2-5 Sept for the US Labor Day holiday, so I could
>> >> start on this on 6 Sept.
>> >>
>> >> As always, I appreciate all your comments.
>> >>
>> >> Thanks.
>> >>
>> >> aimee
>> >>
>> >> irc:aimeeu
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing 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
>> >
>> >
>>
>>
>> --
>> 室井 雅仁(Masahito MUROI)
>> Software Innovation Center, NTT
>> Tel: +81-422-59-4539
>>
>>
>>
>> __
>> OpenStack Development Mailing 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] [puppet] [plumgrid-puppet] Proposal to create plumgrid-puppet

[Emilien Macchi]

On Tue, Sep 6, 2016 at 5:25 AM, Qasim Sarfraz  wrote:
> Hi,
>
> I wanted to start a thread around the creation of a new puppet module
> (puppet-plumgrid) for PLUMgrid OpenStack Networking Suite installation as
> per [1].
>
> The is required for PLUMgrid Neutron Plugin [2] whose changes are already
> part of puppet neutron [3]. Let me know what do you people think about it?

It is not clear to me what this module would deploy.
Could you give more details here?
Would it deploy PLUMgrid IO Visor and dependencies?

> [1] -
> http://docs.openstack.org/developer/puppet-openstack-guide/new-module.html
> [2] - https://wiki.openstack.org/wiki/PLUMgrid-Neutron
> [3] -
> https://github.com/openstack/puppet-neutron/blob/master/manifests/plugins/plumgrid.pp
>
> --
> Regards,
> Qasim Sarfraz
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Emilien Macchi

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

Re: [openstack-dev] [nova] resignation from bug czar role

[Markus Zoeller]

On 05.09.2016 18:33, Timofei Durakov wrote:
> Hi, folks,
> 
> Thanks, Markus, for doing this job! I'm interested in this activity.
> 
> Timofey

Awesome! Thanks a ton! We can use https://appear.in/os-nova-bugs for a
kickoff. I'll catch up with you in IRC for finding time and date. I'm in
the UTC+1 timezone.

> 
> On Mon, Sep 5, 2016 at 7:20 PM, Sylvain Bauza  wrote:
> 
>>
>>
>> Le 05/09/2016 13:19, Markus Zoeller a écrit :
>>
>>> TL;DR: bug czar role for Nova is vacant from now on
>>>
>>>
>>> After doing bug triage for ~1 year, which was quiet interesting, it's
>>> time for me to move to different topics. My tasks within the company
>>> internal team are shifting too. Unfortunately less Nova for me in the
>>> next (hopefully short) time. That means I'm resigning from the bug czar
>>> role as of now.
>>>
>>>
>>> Observations in this timeframe
>>> --
>>>
>>> * The quality of most of the bug reports could be better. Very often
>>> they are not actionable. A bug report which isn't actionable burns
>>> resources without any benefit. The pattern I've seen is:
>>>  * 1/3 : invalid because they are support requests or a wrong
>>> understanding
>>>  * 1/3 : could be reasonable but essential information is missing
>>>  * 1/3 : sounds reasonable + has a little info, should be looked at
>>>Very few follow this template which is shown when you open a new
>>> report: https://wiki.openstack.org/wiki/Nova/BugsTeam/BugReportTemplate
>>>
>>> * We get ~40 new bug reports per week. With the current number of people
>>> who do bug triage, the number of overall bug reports doesn't decline. I
>>> started collecting data 6 months ago:
>>>
>>> http://45.55.105.55:3000/dashboard/db/openstack-bugs?from=
>>> now-6M=1
>>>
>>> * I wish the cores would engage more in bug triaging. If one core every
>>> other week would do the bug triage for 1 week, a core would have to do
>>> that only once per dev cycle. I'm aware of the review backlog though :/
>>>
>>> * I wish more non-cores would engage more in bug triaging.
>>>
>>> * We don't have contacts for a lot of areas in Nova:
>>>https://wiki.openstack.org/wiki/Nova/BugTriage#Tag_Owner_List
>>>
>>> * Keeping the bug reports in a consistent state is cumbersome:
>>>http://45.55.105.55:8082/bugs-dashboard.html#tabInProgressStale
>>>We could introduce more automation here.
>>>
>>>
>>> Things we should continue
>>> -
>>>
>>> * Bug reports older that the oldest supported stable release should be
>>>expired. Maybe best when the EOL tag gets applied.
>>>
>>> https://github.com/openstack-infra/release-tools/blob/master
>>> /expire_old_bug_reports.py
>>>http://lists.openstack.org/pipermail/openstack-dev/2016-May
>>> /095654.html
>>>
>>> * We never came to a real conclusion how the ops communicated the RFEs
>>> to us. The way of using "wishlist" bug reports wasn't successful IMO.
>>> The last proposal was to use the ops ML to bring an RFE into some
>>> actionable shape and then create a backlog spec out of it.
>>>http://lists.openstack.org/pipermail/openstack-dev/2016-Mar
>>> ch/089365.html
>>>
>>>
>>>
>>> Things we should start
>>> --
>>>
>>> * A cross-project discussion of (easy) ways to collect and send debug
>>> data to upstream OpenStack. Almost no bug report in Nova had the result
>>> of "sosreport" attached although we ask for that in the report template.
>>>
>>>
>>>
>>> Some last words
>>> ---
>>>
>>> * Whoever wants to do the job next, I offer some kind of onboarding.
>>>
>>> * I'll push a change to remove the IRC meetings in the next few days:
>>>http://eavesdrop.openstack.org/#Nova_Bugs_Team_Meeting
>>>
>>> * The tooling I used will still be available at:
>>>https://github.com/markuszoeller/openstack/tree/master/
>>> scripts/launchpad
>>>
>>> * My server which hosts some dashboards will still be available at:
>>>http://45.55.105.55:3000/dashboard/db/openstack-bugs
>>>http://45.55.105.55:8082/bugs-dashboard.html
>>>http://45.55.105.55:8082/bugs-stats.html
>>>
>>> * I did an evaluation of Storyboard in July 2016 and it looks promising.
>>> Give it a shot at: https://storyboard-dev.openstack.org/#!/project/2 If
>>> you don't like something there, push a change, it's Python based.
>>>
>>> * I'll still hang out in the IRC channels, but don't expect much from me.
>>>
>>>
>>> Thanks a lot to the people who helped making Nova a better project by
>>> doing bug triage! Special thanks to auggy who put a lot(!) of effort
>>> into that.
>>>
>>> See you (hopefully) in Barcelona!
>>>
>>
>> As said on IRC, hope we'll still see you around, and see you in Barcelona.
>> You made a great job !
>>
>> -Sylvain
>>
>>
>> --
>>> Regards,
>>> Markus Zoeller (markus_z)
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 

Re: [openstack-dev] [tripleo] FFE request for Ceph RGW integration

[Keith Schincke]

Here are some updates on the mentioned issues:
puppet-ceph not idempotent - Fixed with 363164
Ceph RGW needing a CI test (scenario004) - Passing excepted a Xenial issue
in 339106

The status of the RGW role related patches are:
  289027 Deploying RGW role: being rechecked after a merge conflict within
THT. It is coming up green so far.
  334081 Add RGW role to puppet-tripleo: passes except for one OVB CI test
with a mysql error
  347956 RGW/Keystone V3 to puppet-ceph: There is a fuel issue and I am
trying to understand the logs.

Keith


On Thu, Sep 1, 2016 at 2:48 AM, Giulio Fidente  wrote:

> On 09/01/2016 02:11 AM, Giulio Fidente wrote:
>
>> On 08/30/2016 10:50 PM, Steven Hardy wrote:
>>
>>> On Tue, Aug 30, 2016 at 03:25:30PM -0400, Emilien Macchi wrote:
>>>
 Here's my 2 cents:

 The patch in puppet-ceph has been here for long time now and it still
 doesn't work (recent update of today, puppet-ceph is not idempotent
 when deploying RGW service. It must be fixed in order to get
 successful deployment).
 Puppet CI is still not gating on Ceph RGW (scenario004 still in
 progress and really low progress to make it working recently).

>>>
>>> This does sound concerning, Giulio, can you provide any feedback on work
>>> in-progress or planned to improve this?
>>>
>>
>> we invested quite some time today testing and updating the patches as
>> needed
>>
>> I've a got a successful deployment where by just adding the Member role
>> to my user I could use the regular swiftclient to operate against RadosGW
>>
>
> fwiw, we just amended one of the patches to remove the need for the users
> to have the 'Member' role set
>
> which means that with its latest version it is possible to deploy radosgw
> as a drop-in replacement for swift and use with swiftclient without any
> additional step, by using the ceph-radosgw.yaml enironment at deployment
> time
>
> unfortunately CI is having some unrelated issues so it's hard to get all
> patches to pass but I would encourage people to review and test this as I
> think it is in good shape
>
> --
> Giulio Fidente
> GPG KEY: 08D733BA | IRC: gfidente
>



-- 

Keith Schincke
Senior Software Engineer (RHCA)
Systems Engineering
__
OpenStack Development Mailing 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] next notification subteam meeting

[Balázs Gibizer]

Hi, 

The next notification subteam meeting will be held on 2016.09.06 17:00 UTC [1] 
on #openstack-meeting-4.

Cheers,
Gibi

[1] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20160906T17

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

[openstack-dev] openstack/python-ironicclient

[Galyna Zholtkevych]

Dear all,

Ironic community needs a help to decide on the specification

of the openstack client command that provide the same functionality as

'ironic driver-raid-logical-disk-properties' .

Some propositions violate openstack client conventions for a user.

For now the available propositions are:

* openstack baremetal driver raid-logical-disk-properties show

* openstack baremetal driver show --raid-logical-disk-properties

* openstack baremetal driver raid logical disk properties show

* openstack baremetal driver show raid-logical-disk-properties

* openstack baremetal driver show raid logical-disk-properties


Reference to the appropriate discussion:
https://bugs.launchpad.net/python-ironicclient/+bug/1619052


Hope you to join the discussion in order to make a reasonable decision.

Best regards,

Galyna Zholtkevych
__
OpenStack Development Mailing 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] [tricircle] your proposal for the name of networking and gateway sub-projects

[liukun]

Triangel +1

At 2016-09-06 16:27:22, "joehuang"  wrote:

Hello,


After the discussion in the #openstack-tricircle channel and mail-list, 4 
candidates
available now, please vote the name for the new sub-project for api-gateway
functionality:


1. Triangel, 2 votes
  The Triangel are dolls that bring luck. Found some meaning may not all people 
like it, Zhiyuan proposed another candidate "Trio2o"
2. Tridonut, 0 votes
  Three Donuts. Delicious food, often buy 3 get 1 free.
3. Trifennel, 2 votes
  Three Fennel. Fennel is highly prized for its licorice-like flavor and
  the myriad of health benefits it provides
4. Trio2o, 3 votes
  openstack-to-openstack


Some team members just joined the mail-list, so please continue to vote for the 
api-gateway project name.


Best Regards
Chaoyi Huang(joehuang)


From: joehuang
Sent: 06 September 2016 9:04
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [tricircle] your proposal for the name of 
networking and gateway sub-projects


I also like trio2o, +1 for trio2o.


From: xiulin yin [yinxiuli...@gmail.com]
Sent: 05 September 2016 18:44
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle] your proposal for the name of 
networking and gateway sub-projects


trio2o +1， Accurately express the function of the project.



2016-09-05 17:34 GMT+08:00 Vega Cai :

Oops, sorry for "triangel". Then what about "trio2o", openstack-to-openstack


Zhiyuan 


Yipei Niu 于2016年9月5日周一 上午11:22写道：

Trifennel +1


Best regards,
Yipei
__
OpenStack Development Mailing 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


From: Dongfeng Huang [dfhua...@gmail.com]
Sent: 05 September 2016 20:17
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tricircle]your proposal for the name of 
networking and gateway sub-projects (joehuang)


 Trifennel +1__
OpenStack Development Mailing 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] [tricircle] your proposal for the name of networking and gateway sub-projects

[yuquanle]

+1 for trio2o.

At 2016-09-06 16:27:22, "joehuang"  wrote:

Hello,


After the discussion in the #openstack-tricircle channel and mail-list, 4 
candidates
available now, please vote the name for the new sub-project for api-gateway
functionality:


1. Triangel, 2 votes
  The Triangel are dolls that bring luck. Found some meaning may not all people 
like it, Zhiyuan proposed another candidate "Trio2o"
2. Tridonut, 0 votes
  Three Donuts. Delicious food, often buy 3 get 1 free.
3. Trifennel, 2 votes
  Three Fennel. Fennel is highly prized for its licorice-like flavor and
  the myriad of health benefits it provides
4. Trio2o, 3 votes
  openstack-to-openstack


Some team members just joined the mail-list, so please continue to vote for the 
api-gateway project name.


Best Regards
Chaoyi Huang(joehuang)


From: joehuang
Sent: 06 September 2016 9:04
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [tricircle] your proposal for the name of 
networking and gateway sub-projects


I also like trio2o, +1 for trio2o.


From: xiulin yin [yinxiuli...@gmail.com]
Sent: 05 September 2016 18:44
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle] your proposal for the name of 
networking and gateway sub-projects


trio2o +1， Accurately express the function of the project.



2016-09-05 17:34 GMT+08:00 Vega Cai :

Oops, sorry for "triangel". Then what about "trio2o", openstack-to-openstack


Zhiyuan 


Yipei Niu 于2016年9月5日周一 上午11:22写道：

Trifennel +1


Best regards,
Yipei
__
OpenStack Development Mailing 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


From: Dongfeng Huang [dfhua...@gmail.com]
Sent: 05 September 2016 20:17
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tricircle]your proposal for the name of 
networking and gateway sub-projects (joehuang)


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

[openstack-dev] [tricircle]

[liukun]

Tricircle,I am coming!__
OpenStack Development Mailing 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] Live migration IRC meeting

[Murray, Paul (HP Cloud)]

There will be a live migration sub team meeting today, see:

https://wiki.openstack.org/wiki/Meetings/NovaLiveMigration

Paul

__
OpenStack Development Mailing 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] Fw:Re: [tricircle] your proposal for the name of networking and gateway sub-projects

[persistencelzy]

+1 for trio2o




At 2016-09-06 19:29:54, "hejiawei"  wrote:









 Forwarding messages 
From: "joehuang" 
Date: 2016-09-06 16:27:22
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [tricircle] your proposal for the name of 
networking and gateway sub-projects

Hello,


After the discussion in the #openstack-tricircle channel and mail-list, 4 
candidates
available now, please vote the name for the new sub-project for api-gateway
functionality:


1. Triangel, 2 votes
  The Triangel are dolls that bring luck. Found some meaning may not all people 
like it, Zhiyuan proposed another candidate "Trio2o"
2. Tridonut, 0 votes
  Three Donuts. Delicious food, often buy 3 get 1 free.
3. Trifennel, 2 votes
  Three Fennel. Fennel is highly prized for its licorice-like flavor and
  the myriad of health benefits it provides
4. Trio2o, 3 votes
  openstack-to-openstack


Some team members just joined the mail-list, so please continue to vote for the 
api-gateway project name.


Best Regards
Chaoyi Huang(joehuang)


From: joehuang
Sent: 06 September 2016 9:04
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [tricircle] your proposal for the name of 
networking and gateway sub-projects


I also like trio2o, +1 for trio2o.


From: xiulin yin [yinxiuli...@gmail.com]
Sent: 05 September 2016 18:44
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle] your proposal for the name of 
networking and gateway sub-projects


trio2o +1， Accurately express the function of the project.



2016-09-05 17:34 GMT+08:00 Vega Cai :

Oops, sorry for "triangel". Then what about "trio2o", openstack-to-openstack


Zhiyuan 


Yipei Niu 于2016年9月5日周一 上午11:22写道：

Trifennel +1


Best regards,
Yipei
__
OpenStack Development Mailing 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


From: Dongfeng Huang [dfhua...@gmail.com]
Sent: 05 September 2016 20:17
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tricircle]your proposal for the name of 
networking and gateway sub-projects (joehuang)


 Trifennel +1



【网易自营|30天无忧退货】万人抢购的51米长懒人抹布（4卷装、无需水洗），只要52元！>__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tricircle]

[yuquanle]

hello！




 __
OpenStack Development Mailing 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] using the qemu memory overhead in memory resource tracking or scheduling

[Balázs Gibizer]

> From: Roman Podoliaka [mailto:rpodoly...@mirantis.com]
> Sent: September 06, 2016 11:55
> 
> Looks like we already have something like that in the virt drivers interface:
> 
> https://github.com/openstack/nova/blob/master/nova/virt/driver.py#L205-
> L216
> 
> which is used in the resource tracker.

Thanks for the pointer. I added some constant but nonzero overhead
to the libvirt driver impl but it seems to me that this overhead calculation
happens against the overall memory pool on the compute.
I have 1G pages for instances and I have kept some 4k memory
for the host OS. The qemu memory overhead is allocated from the 4k
memory. If the compute runs out of 4k memory but still have free
1G pages then the claim is successful as overall there is free memory
however qemu or the host OS can fail as there is no free 4k memory.

Cheers,
gibi

> 
> On Tue, Sep 6, 2016 at 10:40 AM, Balázs Gibizer
>  wrote:
> > Hi,
> >
> > In our cloud we use 1G huge pages for the instance memory.
> > We started notice that qemu has a relevant memory overhead
> > per domain (something like 300MB per domain). As we use
> > huge pages for the instance memory nova scheduler makes
> > placement decision based on the available huge pages.
> > However in this situation the available host OS memory also
> > needs to be considered. Reserving host OS memory deployment
> > time is not practical as the needed reservation depends on the
> > number of instances that will be run on that host.
> >
> > Is there any plan in the nova community to use qemu
> > memory overhead in the placement decision in case of huge page
> > backed instance?
> >
> > If there is no plan, do you support the idea adding such feature to nova?
> >
> > Cheers,
> > gibi
> >
> >
> __
> 
> > OpenStack Development Mailing 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] [tricircle]

[persistencelzy]

Hello。




 





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

Re: [openstack-dev] [Fuel] Common fuel-core group for all Fuel projects

[Aleksey Kasatkin]

Hi,

-1 to the proposal. We have the ability (and we use it) to add guys to
several core groups. So, AFAIC, Vladimir's pros point #1 is covered. IMO,
pros point #2 looks questionable and not so important. Cons could be worse
(agree with Lukasz).

Thanks,



Aleksey Kasatkin


On Tue, Sep 6, 2016 at 1:19 PM, Sergii Golovatiuk 
wrote:

> Hi,
>
> Fuel repositories include several languages/technologies (puppet, python,
> ruby, make ...)  Core engineer nominated for achievements in one project
> may have average skills in another language/technology.
>
> So, I give '-1' the suggestion.
>
> However, we may have one group for python project, one group for puppet
> related projects. So we need to identify languages/technologies first, then
> make another proposal.
>
>
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Tue, Sep 6, 2016 at 11:19 AM, Aleksandr Didenko 
> wrote:
>
>> Hi,
>>
>> -1 for the proposal
>>
>> Regards,
>> Alex
>>
>> On Tue, Sep 6, 2016 at 10:42 AM, Alexey Stepanov 
>> wrote:
>>
>>> Guys, I have one serious question: WHO will be global core?
>>> Example:
>>>   I'm core reviewer in 2 repos, but I'm absolutely could not be core
>>> reviewer in puppet!
>>>
>>> On Tue, Sep 6, 2016 at 11:31 AM, Igor Kalnitsky 
>>> wrote:
>>>
 -1 for the proposal. I see no problems to add guys who're familiar
 with various sub-projects to multiple core groups.

 On Tue, Sep 6, 2016 at 10:38 AM, Evgeniy L  wrote:
 > +1 to Lukasz.
 > -1 to the proposal, we had it this way for a quite some time, and it
 was not
 > good for the project (as Lukasz pointed out), why should a person who
 merges
 > the code to the library have an access to merge the code to
 Nailgun/Astute
 > without proper expertise. Those are different areas which require
 different
 > skills.
 >
 > Thanks,
 >
 > On Tue, Sep 6, 2016 at 9:40 AM, Lukasz Oles 
 wrote:
 >>
 >> On Mon, Sep 5, 2016 at 5:39 PM, Andrew Maksimov <
 amaksi...@mirantis.com>
 >> wrote:
 >> > +1
 >> > This is a good proposal, I also think we should have single
 fuel-core
 >> > group
 >> > for all repos. In real life core reviewers won't set +2 or merge to
 >> > repos
 >> > with which they are not familiar with.
 >> Actually one of the reasons why core groups were split was that it
 >> happened a few times :)
 >>
 >> >
 >> > Regards,
 >> > Andrey Maximov
 >> >
 >> > On Mon, Sep 5, 2016 at 2:11 PM, Vladimir Kozhukalov
 >> >  wrote:
 >> >>
 >> >> Dear colleagues,
 >> >>
 >> >> I'd like to suggest to use common fuel-core group for all Fuel
 projects
 >> >> instead of having separate independent 'by-project' core groups
 like
 >> >> 'fuel-astute-core' or 'fuel-agent-core'.
 >> >>
 >> >> Pros:
 >> >> 1) It will be easier to access core members (timezone and holiday
 >> >> tolerance)
 >> >> 2) It will be easier to manage single core group (promote new
 members,
 >> >> remove not active members)
 >> >>
 >> >> Cons:
 >> >> 1) Less of flexibility. Permissions will be the same for all core
 >> >> reviewers in all Fuel projects.
 >> >>
 >> >> What do you think?
 >> >>
 >> >> Vladimir Kozhukalov
 >> >>
 >> >>
 >> >> 
 __
 >> >> OpenStack Development Mailing 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
 >> >
 >>
 >>
 >>
 >> --
 >> Łukasz Oleś
 >>
 >> 
 __
 >> 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] [Fuel] Common fuel-core group for all Fuel projects

[Sergii Golovatiuk]

Hi,

Fuel repositories include several languages/technologies (puppet, python,
ruby, make ...)  Core engineer nominated for achievements in one project
may have average skills in another language/technology.

So, I give '-1' the suggestion.

However, we may have one group for python project, one group for puppet
related projects. So we need to identify languages/technologies first, then
make another proposal.



--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Tue, Sep 6, 2016 at 11:19 AM, Aleksandr Didenko 
wrote:

> Hi,
>
> -1 for the proposal
>
> Regards,
> Alex
>
> On Tue, Sep 6, 2016 at 10:42 AM, Alexey Stepanov 
> wrote:
>
>> Guys, I have one serious question: WHO will be global core?
>> Example:
>>   I'm core reviewer in 2 repos, but I'm absolutely could not be core
>> reviewer in puppet!
>>
>> On Tue, Sep 6, 2016 at 11:31 AM, Igor Kalnitsky 
>> wrote:
>>
>>> -1 for the proposal. I see no problems to add guys who're familiar
>>> with various sub-projects to multiple core groups.
>>>
>>> On Tue, Sep 6, 2016 at 10:38 AM, Evgeniy L  wrote:
>>> > +1 to Lukasz.
>>> > -1 to the proposal, we had it this way for a quite some time, and it
>>> was not
>>> > good for the project (as Lukasz pointed out), why should a person who
>>> merges
>>> > the code to the library have an access to merge the code to
>>> Nailgun/Astute
>>> > without proper expertise. Those are different areas which require
>>> different
>>> > skills.
>>> >
>>> > Thanks,
>>> >
>>> > On Tue, Sep 6, 2016 at 9:40 AM, Lukasz Oles 
>>> wrote:
>>> >>
>>> >> On Mon, Sep 5, 2016 at 5:39 PM, Andrew Maksimov <
>>> amaksi...@mirantis.com>
>>> >> wrote:
>>> >> > +1
>>> >> > This is a good proposal, I also think we should have single
>>> fuel-core
>>> >> > group
>>> >> > for all repos. In real life core reviewers won't set +2 or merge to
>>> >> > repos
>>> >> > with which they are not familiar with.
>>> >> Actually one of the reasons why core groups were split was that it
>>> >> happened a few times :)
>>> >>
>>> >> >
>>> >> > Regards,
>>> >> > Andrey Maximov
>>> >> >
>>> >> > On Mon, Sep 5, 2016 at 2:11 PM, Vladimir Kozhukalov
>>> >> >  wrote:
>>> >> >>
>>> >> >> Dear colleagues,
>>> >> >>
>>> >> >> I'd like to suggest to use common fuel-core group for all Fuel
>>> projects
>>> >> >> instead of having separate independent 'by-project' core groups
>>> like
>>> >> >> 'fuel-astute-core' or 'fuel-agent-core'.
>>> >> >>
>>> >> >> Pros:
>>> >> >> 1) It will be easier to access core members (timezone and holiday
>>> >> >> tolerance)
>>> >> >> 2) It will be easier to manage single core group (promote new
>>> members,
>>> >> >> remove not active members)
>>> >> >>
>>> >> >> Cons:
>>> >> >> 1) Less of flexibility. Permissions will be the same for all core
>>> >> >> reviewers in all Fuel projects.
>>> >> >>
>>> >> >> What do you think?
>>> >> >>
>>> >> >> Vladimir Kozhukalov
>>> >> >>
>>> >> >>
>>> >> >> 
>>> __
>>> >> >> OpenStack Development Mailing 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
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Łukasz Oleś
>>> >>
>>> >> 
>>> __
>>> >> 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
>>>
>>
>>
>>
>> --
>> Alexey Stepanov
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 

[openstack-dev] [TripleO] Make "RedHat RDO CI" vote on tripleo-quickstart changes?

[Attila Darazs]

I think Third party gating is solid enough to make it vote, not just 
post results.


Currently we have a gate job breaking and I almost submitted something 
without everything passing. Would be useful to make it blocking.


Is there any reason not to do this?

Attila

__
OpenStack Development Mailing 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] using the qemu memory overhead in memory resource tracking or scheduling

[Roman Podoliaka]

Looks like we already have something like that in the virt drivers interface:

https://github.com/openstack/nova/blob/master/nova/virt/driver.py#L205-L216

which is used in the resource tracker.

On Tue, Sep 6, 2016 at 10:40 AM, Balázs Gibizer
 wrote:
> Hi,
>
> In our cloud we use 1G huge pages for the instance memory.
> We started notice that qemu has a relevant memory overhead
> per domain (something like 300MB per domain). As we use
> huge pages for the instance memory nova scheduler makes
> placement decision based on the available huge pages.
> However in this situation the available host OS memory also
> needs to be considered. Reserving host OS memory deployment
> time is not practical as the needed reservation depends on the
> number of instances that will be run on that host.
>
> Is there any plan in the nova community to use qemu
> memory overhead in the placement decision in case of huge page
> backed instance?
>
> If there is no plan, do you support the idea adding such feature to nova?
>
> Cheers,
> gibi
>
> __
> OpenStack Development Mailing 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] [Heat] Convergence status

[Thomas Herve]

Hi all,

We're approaching release time, and there are still some concerns
whether or not we can make convergence the default. In particular we
have a somewhat longstanding issue with canceling creation [1]. The
good news is that this is almost fixed [2], and update cancel is
almost there too [3]. We expect to see them merged by RC1 next week,
so please review those if you can.

I also have some confidence overall as projects like Magnum and Sahara
have been running tests with convergence enabled for about 3 months
now, and no particular issues have been reported about it.

That said, if we can't manage to get those in by RC1, we'll have to
revert back to legacy. Those behaviors are too important to release
without them. Hopefully, we'll make it work, and we can focus on
making TripleO using convergence during the next cycle.

Thanks,

-- 
Thomas


[1] https://bugs.launchpad.net/heat/+bug/1592374
[2] https://review.openstack.org/#/c/354000/
[3] https://review.openstack.org/#/c/362346/

__
OpenStack Development Mailing 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] [puppet] [plumgrid-puppet] Proposal to create plumgrid-puppet

[Qasim Sarfraz]

Hi,

I wanted to start a thread around the creation of a new puppet module
(puppet-plumgrid) for PLUMgrid OpenStack Networking Suite installation as
per [1].

The is required for PLUMgrid Neutron Plugin [2] whose changes are already
part of puppet neutron [3]. Let me know what do you people think about it?

[1] - http://docs.openstack.org/developer/puppet-openstack-
guide/new-module.html

[2] - https://wiki.openstack.org/wiki/PLUMgrid-Neutron
[3] -
https://github.com/openstack/puppet-neutron/blob/master/manifests/plugins/plumgrid.pp

-- 
Regards,
Qasim Sarfraz
__
OpenStack Development Mailing 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] [third-party] [puppet] puppet-jenkins doesn't allow to pin version

[Evgeny Antyshev]

Hello!

Last time I created Third-Party CI in new environment, I faced 
difficulties installing Jenkins by puppet-jenkins:


1) It really doesn't allow to pin Jenkins version, due to bug (or lack 
of functionality) in Jenkins infrastructure:

https://issues.jenkins-ci.org/browse/INFRA-92

Therefore, the change at https://review.openstack.org/354086 don't 
actually work.


There are 2 options to workaround this: install Jenkins package from 
*.deb by given link, which involves some possible issues with 
dependancies. Or to make it without Jenkins, using Zuul launcher in 
3rd-party environment, has anybody tried that?


2) 3rd-party CI also needs https://review.openstack.org/334400 (to 
disable security policy preventing custom build parameters). But this 
solution won't be accepted, and there's no other yet.


Does anyone have opinion on this?

Thanks in advance!

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

Re: [openstack-dev] [Fuel] Common fuel-core group for all Fuel projects

[Aleksandr Didenko]

Hi,

-1 for the proposal

Regards,
Alex

On Tue, Sep 6, 2016 at 10:42 AM, Alexey Stepanov 
wrote:

> Guys, I have one serious question: WHO will be global core?
> Example:
>   I'm core reviewer in 2 repos, but I'm absolutely could not be core
> reviewer in puppet!
>
> On Tue, Sep 6, 2016 at 11:31 AM, Igor Kalnitsky 
> wrote:
>
>> -1 for the proposal. I see no problems to add guys who're familiar
>> with various sub-projects to multiple core groups.
>>
>> On Tue, Sep 6, 2016 at 10:38 AM, Evgeniy L  wrote:
>> > +1 to Lukasz.
>> > -1 to the proposal, we had it this way for a quite some time, and it
>> was not
>> > good for the project (as Lukasz pointed out), why should a person who
>> merges
>> > the code to the library have an access to merge the code to
>> Nailgun/Astute
>> > without proper expertise. Those are different areas which require
>> different
>> > skills.
>> >
>> > Thanks,
>> >
>> > On Tue, Sep 6, 2016 at 9:40 AM, Lukasz Oles  wrote:
>> >>
>> >> On Mon, Sep 5, 2016 at 5:39 PM, Andrew Maksimov <
>> amaksi...@mirantis.com>
>> >> wrote:
>> >> > +1
>> >> > This is a good proposal, I also think we should have single fuel-core
>> >> > group
>> >> > for all repos. In real life core reviewers won't set +2 or merge to
>> >> > repos
>> >> > with which they are not familiar with.
>> >> Actually one of the reasons why core groups were split was that it
>> >> happened a few times :)
>> >>
>> >> >
>> >> > Regards,
>> >> > Andrey Maximov
>> >> >
>> >> > On Mon, Sep 5, 2016 at 2:11 PM, Vladimir Kozhukalov
>> >> >  wrote:
>> >> >>
>> >> >> Dear colleagues,
>> >> >>
>> >> >> I'd like to suggest to use common fuel-core group for all Fuel
>> projects
>> >> >> instead of having separate independent 'by-project' core groups like
>> >> >> 'fuel-astute-core' or 'fuel-agent-core'.
>> >> >>
>> >> >> Pros:
>> >> >> 1) It will be easier to access core members (timezone and holiday
>> >> >> tolerance)
>> >> >> 2) It will be easier to manage single core group (promote new
>> members,
>> >> >> remove not active members)
>> >> >>
>> >> >> Cons:
>> >> >> 1) Less of flexibility. Permissions will be the same for all core
>> >> >> reviewers in all Fuel projects.
>> >> >>
>> >> >> What do you think?
>> >> >>
>> >> >> Vladimir Kozhukalov
>> >> >>
>> >> >>
>> >> >> 
>> __
>> >> >> OpenStack Development Mailing 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
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Łukasz Oleś
>> >>
>> >> 
>> __
>> >> 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.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Alexey Stepanov
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] First Project Teams Gathering - Atlanta Feb 20-24, 2017

[Thierry Carrez]

Hi everyone,

As you probably know, the OpenStack Foundation staff has been busy over
the past year reorganizing how our events are laid out. Starting in
2017, the "Design Summit" part of the OpenStack Summit will be
refactored into two separate events: a general "Forum" for
community-wide discussions at the Summit (starting in Boston in May,
2017), and a separate event for upstream project teams (horizontal and
vertical) to get together, called the Project Teams Gathering.

The first Project Teams Gathering will be held in Atlanta, Feb 20-24,
2017. Mark the date ! In an effort to encourage people to engage beyond
their base team, the current plan is to provide space for horizontal
teams and cross-project efforts on Monday-Tuesday, while vertical teams
would get space to meet on Wednesday-Friday. We'll reach out to the
newly-elected PTLs so that they can tell us if they would like to have a
meeting room at the Atlanta PTG for their team to gather in, then we
should be able to open registration in October.

For more information on the event, why we changed things and who should
plan to go there, please see the event page at:

http://www.openstack.org/ptg

Feel free to reach out to me if you have questions. You can also read
the FAQ at:

http://www.openstack.org/ptg/ptgfaq/

As a result of this, Barcelona will be our last old-style Design Summit.
Ocata will be a slightly-shorter development cycle, with Pike
development starting with the PTG in February. The proposed Ocata
release schedule reflects that: https://review.openstack.org/#/c/357214/

Regards,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [nova] Next steps for resource providers work

[Chris Dent]

On Fri, 2 Sep 2016, Dan Smith wrote:


We should try to get this figured out before newton ships if possible. I
don't think I see it locally, but I have a large dev machine, so I'll
have to try to poke it harder.


I'm not clear on where we left this issue with allocation violations
on Friday?

Other things that have happened since Friday morning:

* We realized that the logging wasn't logging all requests correctly
  and was sometimes suggesting a request was a 200 when it was not.
* We decided that it was important when writing inventory for it to
  be able to violate existing allocations, otherwise a reconfigured
  compute node would not be able to manage its inventory and would
  get in a stuck state and the placement service would not have
  correct information.
* We optimized writing allocations so that if an exact allocation is
  already stored, we don't write it, we just return okay. This is
  above beyond the earlier decision to allow allocations to be
  updated.
* We only write inventories when we know they have changed since the
  last time we wrote them.
* We fixed the serialization of the response to a GET
  /resource_providers/{uuid}/inventories. Some refactoring caused
  that to violate the spec.
* That fix allowed the writing of inventories on the resource
  tracker side to be less complex.
* Further adjustments to logging so it is a little more clear what's
  going on (further fixes here required).

All of the above is in the stack starting at

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

That may seem like a lot but I think it reflects that we are
iterating well.

In some testing with devstack yesterday allocations were been
written and destroyed as expected during server create, delete, and
error. Testing Friday was showing that allocations associated with
resizes were working[1], but only because the updates were happening
on the periodic heal job, not in direct response to the resize, so
there was some latency.

Some of the changes above are pragmatic, made in response to the
testing, and may not be aligned with the vision™, so I suspect Dan
and Jay and I will need to get together to figure out what needs to
happen.

There have been several ancillary changes are well, based on bugs
found while doing the above work or validating it:

* Misleading comment in wsgi.py:
  https://review.openstack.org/#/c/365638/
* Remove the script that wsgi.py replaced:
  https://review.openstack.org/#/c/363705/
* Remove another misleading comment:
  https://review.openstack.org/#/c/363039/

And finally there is some pending work that it would be good to get
in now instead of later so that the service is as complete as
possible:

* Clean up json handling
  https://review.openstack.org/#/c/361422/
* Implementation of associating aggregates with resource providers
  https://review.openstack.org/#/c/362863/
* Optional placement database
  https://review.openstack.org/#/c/362766/

The last two were mooted as "punt to Ocata" but I think we should
consider them for now, if possible. The first one is a cleanup.

[1] I used this to do some of my testing:
https://github.com/cdent/placement-exercise

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fw:Re: [tricircle] your proposal for the name of networking and gateway sub-projects

[crh]

trio2o +1




--



Best regards,
Ronghui Cao, Ph.D. Candidate
College of Information Science and Engineering
Hunan University, Changsha 410082, Hunan, China

At 2016-09-06 16:55:12, "hejiawei"  wrote:









 Forwarding messages 
From: "joehuang" 
Date: 2016-09-06 16:27:22
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [tricircle] your proposal for the name of 
networking and gateway sub-projects

Hello,


After the discussion in the #openstack-tricircle channel and mail-list, 4 
candidates
available now, please vote the name for the new sub-project for api-gateway
functionality:


1. Triangel, 2 votes
  The Triangel are dolls that bring luck. Found some meaning may not all people 
like it, Zhiyuan proposed another candidate "Trio2o"
2. Tridonut, 0 votes
  Three Donuts. Delicious food, often buy 3 get 1 free.
3. Trifennel, 2 votes
  Three Fennel. Fennel is highly prized for its licorice-like flavor and
  the myriad of health benefits it provides
4. Trio2o, 3 votes
  openstack-to-openstack


Some team members just joined the mail-list, so please continue to vote for the 
api-gateway project name.


Best Regards
Chaoyi Huang(joehuang)


From: joehuang
Sent: 06 September 2016 9:04
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [tricircle] your proposal for the name of 
networking and gateway sub-projects


I also like trio2o, +1 for trio2o.


From: xiulin yin [yinxiuli...@gmail.com]
Sent: 05 September 2016 18:44
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle] your proposal for the name of 
networking and gateway sub-projects


trio2o +1， Accurately express the function of the project.



2016-09-05 17:34 GMT+08:00 Vega Cai :

Oops, sorry for "triangel". Then what about "trio2o", openstack-to-openstack


Zhiyuan 


Yipei Niu 于2016年9月5日周一 上午11:22写道：

Trifennel +1


Best regards,
Yipei
__
OpenStack Development Mailing 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


From: Dongfeng Huang [dfhua...@gmail.com]
Sent: 05 September 2016 20:17
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tricircle]your proposal for the name of 
networking and gateway sub-projects (joehuang)


 Trifennel +1



【网易自营|30天无忧退货】万人抢购的51米长懒人抹布（4卷装、无需水洗），只要52元！>__
OpenStack Development Mailing 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] [tricircle] your proposal for the name of networking and gateway sub-projects

[hejiawei]

trio2o +1, it's concise






At 2016-09-06 16:27:22, "joehuang"  wrote:

Hello,


After the discussion in the #openstack-tricircle channel and mail-list, 4 
candidates
available now, please vote the name for the new sub-project for api-gateway
functionality:


1. Triangel, 2 votes
  The Triangel are dolls that bring luck. Found some meaning may not all people 
like it, Zhiyuan proposed another candidate "Trio2o"
2. Tridonut, 0 votes
  Three Donuts. Delicious food, often buy 3 get 1 free.
3. Trifennel, 2 votes
  Three Fennel. Fennel is highly prized for its licorice-like flavor and
  the myriad of health benefits it provides
4. Trio2o, 3 votes
  openstack-to-openstack


Some team members just joined the mail-list, so please continue to vote for the 
api-gateway project name.


Best Regards
Chaoyi Huang(joehuang)


From: joehuang
Sent: 06 September 2016 9:04
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [tricircle] your proposal for the name of 
networking and gateway sub-projects


I also like trio2o, +1 for trio2o.


From: xiulin yin [yinxiuli...@gmail.com]
Sent: 05 September 2016 18:44
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tricircle] your proposal for the name of 
networking and gateway sub-projects


trio2o +1， Accurately express the function of the project.



2016-09-05 17:34 GMT+08:00 Vega Cai :

Oops, sorry for "triangel". Then what about "trio2o", openstack-to-openstack


Zhiyuan 


Yipei Niu 于2016年9月5日周一 上午11:22写道：

Trifennel +1


Best regards,
Yipei
__
OpenStack Development Mailing 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


From: Dongfeng Huang [dfhua...@gmail.com]
Sent: 05 September 2016 20:17
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tricircle]your proposal for the name of 
networking and gateway sub-projects (joehuang)


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

Re: [openstack-dev] [Fuel] Common fuel-core group for all Fuel projects

[Alexey Stepanov]

Guys, I have one serious question: WHO will be global core?
Example:
  I'm core reviewer in 2 repos, but I'm absolutely could not be core
reviewer in puppet!

On Tue, Sep 6, 2016 at 11:31 AM, Igor Kalnitsky  wrote:

> -1 for the proposal. I see no problems to add guys who're familiar
> with various sub-projects to multiple core groups.
>
> On Tue, Sep 6, 2016 at 10:38 AM, Evgeniy L  wrote:
> > +1 to Lukasz.
> > -1 to the proposal, we had it this way for a quite some time, and it was
> not
> > good for the project (as Lukasz pointed out), why should a person who
> merges
> > the code to the library have an access to merge the code to
> Nailgun/Astute
> > without proper expertise. Those are different areas which require
> different
> > skills.
> >
> > Thanks,
> >
> > On Tue, Sep 6, 2016 at 9:40 AM, Lukasz Oles  wrote:
> >>
> >> On Mon, Sep 5, 2016 at 5:39 PM, Andrew Maksimov  >
> >> wrote:
> >> > +1
> >> > This is a good proposal, I also think we should have single fuel-core
> >> > group
> >> > for all repos. In real life core reviewers won't set +2 or merge to
> >> > repos
> >> > with which they are not familiar with.
> >> Actually one of the reasons why core groups were split was that it
> >> happened a few times :)
> >>
> >> >
> >> > Regards,
> >> > Andrey Maximov
> >> >
> >> > On Mon, Sep 5, 2016 at 2:11 PM, Vladimir Kozhukalov
> >> >  wrote:
> >> >>
> >> >> Dear colleagues,
> >> >>
> >> >> I'd like to suggest to use common fuel-core group for all Fuel
> projects
> >> >> instead of having separate independent 'by-project' core groups like
> >> >> 'fuel-astute-core' or 'fuel-agent-core'.
> >> >>
> >> >> Pros:
> >> >> 1) It will be easier to access core members (timezone and holiday
> >> >> tolerance)
> >> >> 2) It will be easier to manage single core group (promote new
> members,
> >> >> remove not active members)
> >> >>
> >> >> Cons:
> >> >> 1) Less of flexibility. Permissions will be the same for all core
> >> >> reviewers in all Fuel projects.
> >> >>
> >> >> What do you think?
> >> >>
> >> >> Vladimir Kozhukalov
> >> >>
> >> >>
> >> >> 
> __
> >> >> OpenStack Development Mailing 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
> >> >
> >>
> >>
> >>
> >> --
> >> Łukasz Oleś
> >>
> >> 
> __
> >> OpenStack Development Mailing 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
>



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

Re: [openstack-dev] [Fuel] Common fuel-core group for all Fuel projects

[Igor Kalnitsky]

-1 for the proposal. I see no problems to add guys who're familiar
with various sub-projects to multiple core groups.

On Tue, Sep 6, 2016 at 10:38 AM, Evgeniy L  wrote:
> +1 to Lukasz.
> -1 to the proposal, we had it this way for a quite some time, and it was not
> good for the project (as Lukasz pointed out), why should a person who merges
> the code to the library have an access to merge the code to Nailgun/Astute
> without proper expertise. Those are different areas which require different
> skills.
>
> Thanks,
>
> On Tue, Sep 6, 2016 at 9:40 AM, Lukasz Oles  wrote:
>>
>> On Mon, Sep 5, 2016 at 5:39 PM, Andrew Maksimov 
>> wrote:
>> > +1
>> > This is a good proposal, I also think we should have single fuel-core
>> > group
>> > for all repos. In real life core reviewers won't set +2 or merge to
>> > repos
>> > with which they are not familiar with.
>> Actually one of the reasons why core groups were split was that it
>> happened a few times :)
>>
>> >
>> > Regards,
>> > Andrey Maximov
>> >
>> > On Mon, Sep 5, 2016 at 2:11 PM, Vladimir Kozhukalov
>> >  wrote:
>> >>
>> >> Dear colleagues,
>> >>
>> >> I'd like to suggest to use common fuel-core group for all Fuel projects
>> >> instead of having separate independent 'by-project' core groups like
>> >> 'fuel-astute-core' or 'fuel-agent-core'.
>> >>
>> >> Pros:
>> >> 1) It will be easier to access core members (timezone and holiday
>> >> tolerance)
>> >> 2) It will be easier to manage single core group (promote new members,
>> >> remove not active members)
>> >>
>> >> Cons:
>> >> 1) Less of flexibility. Permissions will be the same for all core
>> >> reviewers in all Fuel projects.
>> >>
>> >> What do you think?
>> >>
>> >> Vladimir Kozhukalov
>> >>
>> >>
>> >> __
>> >> OpenStack Development Mailing 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
>> >
>>
>>
>>
>> --
>> Łukasz Oleś
>>
>> __
>> OpenStack Development Mailing 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