Re: [openstack-dev] [Cinder][Ceph][Kingbird][Tricircle][Smaug]Build a multisite disaster recovery "stack"

[joehuang]

Hello, Sébastien,

There is OPNFV summit in Berlin Jun 20~23, 2016, as currently Kingbird is still 
a part of OPNFV multisite project, how about to have a design summit there, to 
discuss the features and design needed, and also discuss whether to move 
Kingbird to OpenStack community thread?

http://events.linuxfoundation.org/events/opnfv-summit


Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: joehuang 
Sent: Monday, May 09, 2016 11:20 AM
To: OpenStack Development Mailing List (not for usage questions); Zhipeng 
Huang; Dimitri Mazmanov; 'Ashish Singh'
Cc: opnfv-tech-disc...@lists.opnfv.org
Subject: RE: [openstack-dev] [Cinder][Ceph][Kingbird][Tricircle][Smaug]Build a 
multisite disaster recovery "stack"

Hello, Sébastien,

Thank you very much that you are interested in Kingbird, which is part of OPNFV 
Multisite project. Most of discussion was held in OPNFV thread. Maybe it's good 
to discuss whether to move the all activities to OpenStack thread.

And Tricircle is not only focus in NFV area. In fact, for V1 Tricircle (usually 
called OpenStack cascading, some Nova driver, Cinder Diver / L2/L3 agent were 
added to OpenStack ) is first used in public cloud, like Huawei Enterprise 
Cloud for China enterprises, and DT OTC cloud, and some other public/private 
clouds not mentioned here, they are not NFV area. The open source developed V2 
Tricircle, which is fully decoupled from OpenStack, provides an OpenStack API 
gateway and networking automation to allow multiple OpenStack instances, 
spanning in one site or multiple sites to be managed as a single OpenStack 
cloud.

The slides[1] may help you understand Tricircle, and the video[2] in the Austin 
summit can help you the difference between Tricircle and Kingbird and how they 
work together under different scenario.
[1] 
https://docs.google.com/presentation/d/1UQWeAMIJgJsWw-cyz9R7NvcAuSWUnKvaZFXLfRAQ6fI/edit?usp=sharing
[2] https://www.youtube.com/watch?v=I32rUlLFsUI

Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Sébastien Han [mailto:han.sebast...@gmail.com]
Sent: Monday, May 09, 2016 2:15 AM
To: Zhipeng Huang
Cc: OpenStack Development Mailing List (not for usage questions); 
opnfv-tech-disc...@lists.opnfv.org
Subject: Re: [openstack-dev] [Cinder][Ceph][Kingbird][Tricircle][Smaug]Build a 
multisite disaster recovery "stack"

Thanks for raising this. However we have "good" reasons to not talk about Smaug 
and Tricircle.
Those 2 are really focus on NFV use cases, where in our scenario we "only" save 
Cinder blocks and Glance images.
We do not guarantee the state of the VMs not want to replicate it.

We really aim for a basic approach, so we start small with Kingbird in order to 
address our first multi-site use case.
Perhaps in the future we will need Smaug and Tricircle but we are not there yet.

We will start contributing to Kingbird pretty soon and see how that goes.
Thanks!

--
Regards,
Sébastien Han.


On Fri, May 6, 2016 at 11:01 AM, Zhipeng Huang  wrote:
> Hi Folks,
>
> I was referred to this talk
> https://www.youtube.com/watch?v=VWFYC6W71tY by a colleague, and really 
> think several projects should collaborate on this subject.
>
> Two projects that are missed from the talk but would be helpful are 
> Smaug[1] and Tricircle[2]. Smaug provides data protection services for 
> VMs, whereas Tricircle provides an single API entrance for multisite 
> OpenStack management (cross L2/L3 networking, volume
> migration/replication)
>
> I think these projects could work together to address the issue :)
>
> [1]https://wiki.openstack.org/wiki/Smaug
> [2]https://wiki.openstack.org/wiki/Tricircle
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado

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

Re: [openstack-dev] [requirements] Bootstrapping new team for Requirements.

[Swapnil Kulkarni]

DIms,

I would like to see how I can get involved. Looking forward to the meeting.

Best Regards,
Swapnil Kulkarni
irc : coolsvap


On Sat, May 7, 2016 at 8:32 PM, Davanum Srinivas  wrote:
> Dirk, Haïkel, Igor, Alan, Tony, Ghe,
>
> Please see brain dump here - 
> https://etherpad.openstack.org/p/requirements-tasks
>
> Looking at time overlap, it seems that most of you are in one time
> range and Tony and I are outliers
> http://www.timeanddate.com/worldclock/meetingtime.html?iso=20160506&p1=43&p2=240&p3=195&p4=166&p5=83&p6=281&p7=141)
>
> So one choice for time is 7:00 AM or 8:00 AM my time which will be
> 9:00/10:00 PM for Tony. Are there other options that anyone sees?
> Please let me know which days work as well.
>
> dhellmann, sdague, markmcclain, ttx, lifeless,
> Since you are on the current requirements-core gerrit group, Can you
> please review the etherpad and add your thoughts/ideas/pointers to
> transfer knowledge to the new folks?
>
> To be clear, we are not yet adding new folks to the gerrit group, At
> the moment, i am just getting everyone familiar and productive with
> what we do now and see who is still around doing stuff in a couple of
> months :)
>
> Anyone else want to help, Jump in please!
>
> Thanks,
> Dims
>
> --
> 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 Development Mailing 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] cross-project deployment tool meeting

[j.kl...@cloudbau.de]

Hi,

I have created a doodle so we can find a slot for our first meeting. Please 
respond until this Friday so I can try an secure a spot in the cross project 
irc room.

https://doodle.com/poll/7wrmtpc4ffcwi428

Cheers,
Jan

Sent from my mobile 

> On 06 May 2016, at 22:13, Emilien Macchi  wrote:
> 
> I started https://etherpad.openstack.org/p/deployment-tools-wg
> Recent threads on openstack-dev shows that we need to work together
> (xenial things, etc).
> 
> If you represent an OpenStack deployment tool (Chef, Ansible, etc),
> please add your name and your TZ in the etherpad.
> Also feel free to bring topics, so we can start a bi-monthly meeting
> (maybe less/more?) and work together.
> 
> Thanks and enjoy WE.
> 
> On Fri, May 6, 2016 at 3:51 PM, Jesse Pretorius
>  wrote:
>> On 26 April 2016 at 17:54, Jan Klare  wrote:
>>> 
>>> 
>>> i just wanted to follow up on this session
>>> (https://etherpad.openstack.org/p/newton-deployment-tools-discussion) were
>>> we talked about a cross-project meeting for deployment tools. I would love
>>> to see something like that happen and it would be great if we can find a
>>> specific date (maybe monthly) to do something like that. If you are
>>> interested in going to such a meeting, please reply to this mail with a
>>> suggestion when you could join such a meeting.
>>> 
>>> Cheers,
>>> Jan (OpenStack Chef)
>> 
>> 
>> Thanks Jan. I think once per month will be enough.
>> 
>> I'm based in the UK and am reasonably flexible around times, although it is
>> usually more productive if it can be held during my day rather than my
>> evening.
>> 
>> __
>> OpenStack Development Mailing 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements] Bootstrapping new team for Requirements.

[Ghe Rivero]

On 07/05/16 17:02, Davanum Srinivas wrote:

Dirk, Haïkel, Igor, Alan, Tony, Ghe,

Please see brain dump here - https://etherpad.openstack.org/p/requirements-tasks

Nice starting point. Reading through all of it right now.


Looking at time overlap, it seems that most of you are in one time
range and Tony and I are outliers
http://www.timeanddate.com/worldclock/meetingtime.html?iso=20160506&p1=43&p2=240&p3=195&p4=166&p5=83&p6=281&p7=141)

So one choice for time is 7:00 AM or 8:00 AM my time which will be
9:00/10:00 PM for Tony. Are there other options that anyone sees?
Please let me know which days work as well.


I can do it almost any time, but will prefer to avoid Friday afternoons...

Ghe Rivero

__
OpenStack Development Mailing 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] [Cinder][Ceph][Kingbird][Tricircle][Smaug]Build a multisite disaster recovery "stack"

[Sébastien Han]

Thanks for the clarification :).
Not sure if I'll be in OSCON but who knows :).

Take care.

On Monday, 9 May 2016, Zhipeng Huang  wrote:

> Hi Sebastien,
>
> Totally understand your reasoning here, however there are some
> misunderstanding :P I'm not familiar with Smaug, but Tricircle is not a NFV
> specific project. We have use cases in OPNFV that is targeting NFV
> scenarios.
>
> As you correctly point out about the state of the VM, and Tricircle is not
> guarantee or replicate VM state either. It only provides a unified
> management gateway for a multi-site openstack deployment, user only obtain
> the state on a per-query basis.
>
> Anyways it is great start with Kingbird, and later on I think we could
> further group Tricircle or Smaug together to have more interesting features
> provided to DR :)
>
> BTW we will have a joint Ubernetes/Tricircle session in OSCON, you are
> also welcomed to check it out.
>
> On Mon, May 9, 2016 at 2:14 AM, Sébastien Han  > wrote:
>
>> Thanks for raising this. However we have "good" reasons to not talk
>> about Smaug and Tricircle.
>> Those 2 are really focus on NFV use cases, where in our scenario we
>> "only" save Cinder blocks and Glance images.
>> We do not guarantee the state of the VMs not want to replicate it.
>>
>> We really aim for a basic approach, so we start small with Kingbird in
>> order to address our first multi-site use case.
>> Perhaps in the future we will need Smaug and Tricircle but we are not
>> there yet.
>>
>> We will start contributing to Kingbird pretty soon and see how that goes.
>> Thanks!
>>
>> --
>> Regards,
>> Sébastien Han.
>>
>>
>> On Fri, May 6, 2016 at 11:01 AM, Zhipeng Huang > > wrote:
>> > Hi Folks,
>> >
>> > I was referred to this talk https://www.youtube.com/watch?v=VWFYC6W71tY
>> by a
>> > colleague, and really think several projects should collaborate on this
>> > subject.
>> >
>> > Two projects that are missed from the talk but would be helpful are
>> Smaug[1]
>> > and Tricircle[2]. Smaug provides data protection services for VMs,
>> whereas
>> > Tricircle provides an single API entrance for multisite OpenStack
>> management
>> > (cross L2/L3 networking, volume migration/replication)
>> >
>> > I think these projects could work together to address the issue :)
>> >
>> > [1]https://wiki.openstack.org/wiki/Smaug
>> > [2]https://wiki.openstack.org/wiki/Tricircle
>> >
>> > --
>> > Zhipeng (Howard) Huang
>> >
>> > Standard Engineer
>> > IT Standard & Patent/IT Prooduct Line
>> > Huawei Technologies Co,. Ltd
>> > Email: huangzhip...@huawei.com
>> 
>> > Office: Huawei Industrial Base, Longgang, Shenzhen
>> >
>> > (Previous)
>> > Research Assistant
>> > Mobile Ad-Hoc Network Lab, Calit2
>> > University of California, Irvine
>> > Email: zhipe...@uci.edu
>> 
>> > Office: Calit2 Building Room 2402
>> >
>> > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>>
>
>
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> 
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu 
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>


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

Re: [openstack-dev] [requirements] Bootstrapping new team for Requirements.

[Robert Collins]

I've replied on the etherpad.

-Rob

On 8 May 2016 at 03:02, Davanum Srinivas  wrote:
> Dirk, Haïkel, Igor, Alan, Tony, Ghe,
>
> Please see brain dump here - 
> https://etherpad.openstack.org/p/requirements-tasks
>
> Looking at time overlap, it seems that most of you are in one time
> range and Tony and I are outliers
> http://www.timeanddate.com/worldclock/meetingtime.html?iso=20160506&p1=43&p2=240&p3=195&p4=166&p5=83&p6=281&p7=141)
>
> So one choice for time is 7:00 AM or 8:00 AM my time which will be
> 9:00/10:00 PM for Tony. Are there other options that anyone sees?
> Please let me know which days work as well.
>
> dhellmann, sdague, markmcclain, ttx, lifeless,
> Since you are on the current requirements-core gerrit group, Can you
> please review the etherpad and add your thoughts/ideas/pointers to
> transfer knowledge to the new folks?
>
> To be clear, we are not yet adding new folks to the gerrit group, At
> the moment, i am just getting everyone familiar and productive with
> what we do now and see who is still around doing stuff in a couple of
> months :)
>
> Anyone else want to help, Jump in please!
>
> Thanks,
> Dims
>
> --
> 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



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [kolla] Gate precheck job failed due to minimum kernel version on ubuntu 14.04

[Steven Dake (stdake)]

The reason Kolla works in the gate is it is using the btrfs graph driver.  The 
AUFS graph driver in the 14.04 kernel is busted.  This is what the precheck is 
meant to check.  Apparently it needs to also check the graph driver type in use.

Regards
-steve

From: Jeffrey Zhang mailto:zhang.lei@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Sunday, May 8, 2016 at 1:57 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla] Gate precheck job failed due to minimum 
kernel version on ubuntu 14.04

Please check this[0]. The root cause is that the
> While all kernels should work for Docker, some older kernels may have
> issues with some of the different Docker backends such as AUFS and OverlayFS.

[0] 
http://docs.openstack.org/developer/kolla/quickstart.html#installing-dependencies

On Sun, May 8, 2016 at 4:45 PM, Steve Kowalik 
mailto:ste...@wedontsleep.org>> wrote:
On 08/05/16 08:11, lương hữu tuấn wrote:
Hi,

@Robert: I was successful to update the kernel without change the image.

But that was Robert's point entirely. Installing the kernel will work
fine, but it does not get you running that kernel -- also like Robert
said, you need to change the image to run a different kernel than what
it has installed.

--
Steve
"Stop breathing down my neck!"
"My breathing is merely a simulation."
"So is my neck! Stop it anyway."
 - EMH vs EMH, USS Prometheus


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



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

Re: [openstack-dev] [tc] Swift api compat. Was: supporting Go

[Thierry Carrez]

Fox, Kevin M wrote:

I think part of the problem with the whole Swift situation is that it does 
something most other OpenStack projects don't do. Its both a control plane and 
a data plane.
[...]


Yes, it is certainly part of the Go rationale (I wouldn't say 
"problem"). Swift implementing a data plane has more performance 
constraints and therefore replacing critical parts of it (of not all of 
it) in Go makes more sense there than anywhere else in OpenStack.


To your other point, it is also true that Swift does not act as an 
integration engine for available object storage technologies, and 
therefore is a bit unique in the OpenStack landscape.


Splitting Swift into two components (an OpenStack API/integration 
front-end and a pluggable separate object storage backend) was suggested 
in the past. The main objection to such a split by Swift developers was 
that there is no good split line in the Swift codebase -- the API 
frontend would end up being extremely thin. Maybe the lines moved over 
the last 3 years, but I doubt it.


There is of course little internal incentive in the Swift team to work 
on such decoupling (since they are 99% focused on the Swift engine). To 
make it really happen would probably require a separate team driving it 
and/or a more... radical change on the governance side. The fact that 
there is no such team forming (or more support for radical change) 
suggests that the situation is not critically broken...


--
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] [tc] License for specs repo

[Thierry Carrez]

Ben Swartzlander wrote:

On 05/05/2016 04:01 PM, Davanum Srinivas wrote:

Ben,

Have you seen this yet?

http://lists.openstack.org/pipermail/legal-discuss/2014-March/000201.html
https://wiki.openstack.org/wiki/Governance/Foundation/15Oct2012BoardMinutes#Approval_of_the_CCBY_License_for_Documentation.



No I hadn't seen this. It's helpful to know that there is official
support from the board for using the CCBY license but it's unclear what
that's supposed to look like, since I can't find a single project that's
converted their whole specs repo to the new license.

My confusion comes from how to handle the existing Apache 2.0 stuff in
the cookie cutter. I can't just drop the Apache 2.0 license... The only
obvious path forward is to create a gross mess like the existing specs
repos have where there's a mix of the 2 licenses and it's not clear
which license applies to what.


Looks like a question/discussion for the legal-discuss ML.

--
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] [tc] supporting Go

[Thomas Goirand]

On 05/08/2016 03:37 PM, Rayson Ho wrote:
> On Sun, May 8, 2016 at 5:16 AM, Thomas Goirand  > wrote:
>>  I've heard that upstream for
>> Golang was working on implementing shared libs, but I have no idea what
>> the status is. Does anyone know?
> 
> 
> In Go 1.5, the -buildmode option was introduced (eg. -buildmode=shared):
> 
> https://golang.org/cmd/go/#hdr-Description_of_build_modes
> 
> And the design doc: https://golang.org/s/execmodes
> 
> Rayson

Do you know if that's already in use in some distros?

Cheers,

Thomas


__
OpenStack Development Mailing 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] [HA] About next HA Team meeting (VoIP)

[Sam P]

Hi All,

 In today's ( 9th May 2016) meeting we agree to skip the next IRC
meeting (which is 16th May 2016)  in favour of a gotomeeting VoIP on
18th May 2016 (Wednesday).
 Today's meeting logs and summary can be found here.
 http://eavesdrop.openstack.org/meetings/ha/2016/ha.2016-05-09-08.04.html

 About the meeting Time:
 Every one was convenient with 8:00am UTC.
 However due to some resource allocation issues, I would like to shift
this VoIP meeting to
 9am UTC 18th May 2016

 Please let me know if you are convenient or not with this time slot.

--- Regards,
Sampath

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

[openstack-dev] [ironic] it's official: ironic-discoverd is EOL now

[Dmitry Tantsur]

Hey, you didn't know it wasn't EOL all this time? ;)

Well, now it is. The last PyPI release was ironic-discoverd 1.1.1 (it's 
not tagged in git due to technical reasons), and with Kilo going EOL we 
will have no more releases. Both stable/1.0 and stable/1.1 branches are 
gone now as well. I highly recommend switching to Liberty and beyond to 
enjoy many new features and fixes that ironic-inspector introduces.


Cheers,
Dmitry

P.S.
In case you don't known: ironic-discoverd was renamed to 
ironic-inspector in Liberty, and it is supported right now.


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

Re: [openstack-dev] [kolla] deploy kolla on ppc64

[Jeffrey Zhang]

This is fixed on master branch. please try and test it.[0][1]

[0]
https://git.openstack.org/cgit/openstack/kolla/commit/?id=070bf258357c85a7b4411dc97f75df7d19e9792c
[1] https://bugs.launchpad.net/kolla/+bug/1573544

On Fri, Apr 22, 2016 at 7:15 PM, Jeffrey Zhang 
wrote:

> this should be a bug. we do not support the custom base image now. I
> will try to fix this, anyway.
>
> On Fri, Apr 22, 2016 at 5:29 AM, Franck Barillaud 
> wrote:
>
>> I've been using Kola to deploy Mitaka on x86 and it works great. Now I
>> would like to do the same thing on IBM Power8 systems (ppc64). I've setup a
>> local registry with an Ubuntu image.
>> I've docker and a local registry running on a Power8 system. When I issue
>> the following command:
>>
>> kolla-build --base ubuntu --type source --registry  :4000
>> --push
>>
>> I get an 'exec format error' message. It seems that the build process
>> pulls the Ubuntu amd64 image from the public registry and not the ppc64
>> image from the local registry. Is there a configuration parameter I can
>> setup to force to pull the image from the local registry ?
>>
>>
>> Regards,
>> Franck Barillaud
>> Cloud Architect
>> Master Inventor
>> Ext Phone: (512) 286-5242Tie Line: 363-5242
>> e-mail: fbari...@us.ibm.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
>>
>>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>



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

[openstack-dev] [vitrage] Vitrage IRC meetings - notice the change of time

[Afek, Ifat (Nokia - IL)]

Hi,

Vitrage meeting this week will be SKIPPED, as many Vitrage developers won't be 
able to attend. 

Starting from next week, the meeting time and channel will be changed to:
Wednesday at 8:00 UTC, #openstack-meeting-4

See you next Week,
Ifat.



__
OpenStack Development Mailing 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] [tc] supporting Go

[Hayes, Graham]

On 08/05/2016 10:21, Thomas Goirand wrote:
> On 05/04/2016 01:29 AM, Hayes, Graham wrote:
>> On 03/05/2016 17:03, John Dickinson wrote:
>>> TC,
>>>
>>> In reference to 
>>> http://lists.openstack.org/pipermail/openstack-dev/2016-May/093680.html and 
>>> Thierry's reply, I'm currently drafting a TC resolution to update 
>>> http://governance.openstack.org/resolutions/20150901-programming-languages.html
>>>  to include Go as a supported language in OpenStack projects.
>>>
>>> As a starting point, what would you like to see addressed in the document 
>>> I'm drafting?
>>>
>>> --John
>>>
>>>
>>>
>>
>> Great - I was about to write a thread like this :)
>>
>> Designate is looking to move a single component of ours to Go - and we
>> were wondering what was the best way to do it.

> We discussed about this during the summit. You told me that the issue
> was a piece of code that needed optimization, to which I replied that
> probably, a C++ .so extension in a Python module is probably what you
> are looking for (with the advice of not using CFFI which is sometimes
> breaking things in distros).
>
> Did you think about this other possibility, and did you discuss it with
> your team?

We had a brief discussion about it, and we going to try a new POC in
C/C++ to validate it, but then this thread (and related TC policy) were
proposed.

If Golang is going to be a supported language, we would much rather
stick with one of the official OpenStack languages that suits our
use case instead of getting an exemption for another similar language.

When we spoke at the summit, I was under the impression that the feature
branch in swift was not going to be merged to master, and we would have
to get an exemption from the TC anyway - which we could have used to get
C / C++.

The team also much preferred the idea of Golang - we do not have much
C++ expertise in the Designate dev team, which would slow down the
development cycle for us.

-- Graham

> At the Linux distribution level, the main issue that there is with Go,
> is that it (still) doesn't support the concept of shared library. We see
> this as a bug, rather than a feature. As a consequence, when a library
> upgrades, the release team has to trigger rebuilds for each and every
> reverse dependencies. As the number of Go stuff increases over time, it
> becomes less and less manageable this way (and it may potentially be a
> security patching disaster in Stable). I've heard that upstream for
> Golang was working on implementing shared libs, but I have no idea what
> the status is. Does anyone know?
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
> __
> OpenStack Development Mailing 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][i18n] [config] translation import: No more pot files in git trees

[Doug Hellmann]

We had a group presentation in the upstream development track on Monday where 
we talked about the new work in Oslo. My section where I talked about the 
config generator and other documentation tools is at the end, starting around 
39:00.

https://www.openstack.org/videos/video/live-from-oslo 


> On May 8, 2016, at 11:51 PM, Nikhil Komawar  wrote:
> 
> I realized that the 'talk' could have been main conf (& thus recorded) and 
> not on Tues/oslo sessions, but could not find it 
> https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=oslo
>  
> 
>  ? 
> 
> I will take a chance to see if it's in the documentation section (as per 
> event description) of https://www.openstack.org/videos/video/live-from-oslo 
> 
> 
> On 5/8/16 6:48 PM, Doug Hellmann wrote:
>> Excerpts from Andreas Jaeger's message of 2016-05-08 12:35:00 +0200:
>>> On 05/08/2016 01:12 AM, Nikhil Komawar wrote:
 
 
 On 5/7/16 4:26 PM, Andreas Jaeger wrote:
> On 05/07/2016 10:06 PM, Nikhil Komawar wrote:
>> Hi Andreas,
>> 
>> Thank you for your email.
>> 
>> I got input from a helpful soul that the generated sample configs should
>> also be moved to somewhere publishable? Is that effort in progress as
>> well and any links to share (if so)?
> Nikhil,
> 
> look at the jobs defined in
> https://review.openstack.org/309560  
> (and refined with updates). You can
> do the same: Generate the file and then publish with the scp plug-in to
> a well-know place like tarballs.openstack.org/sample-configs/glance/master
> 
> Feel free to catch me on #openstack-infra if you have questions - or
> provide a first change and then let's work on it together...
 Much appreciated!
>>> 
>>> I just did this in a generic way so that other projects besides glance
>>> can use the same setup:
>>> 
>>> https://review.openstack.org/313919 
>>> 
>>> Andreas
>> Apparently neither of you attended our Oslo talk at the summit. ;-)
>> 
>> oslo.config has an extension module to hook into sphinx to generate the
>> configuration sample file as part of a doc build now. See
>> http://docs.openstack.org/developer/oslo.config/sphinxconfiggen.html 
>> 
>> 
>> 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] [HA] About next HA Team meeting (VoIP)

[Adam Spiers]

Sam P  wrote:
> Hi All,
> 
>  In today's ( 9th May 2016) meeting we agree to skip the next IRC
> meeting (which is 16th May 2016)  in favour of a gotomeeting VoIP on
> 18th May 2016 (Wednesday).
>  Today's meeting logs and summary can be found here.
>  http://eavesdrop.openstack.org/meetings/ha/2016/ha.2016-05-09-08.04.html
> 
>  About the meeting Time:
>  Every one was convenient with 8:00am UTC.
>  However due to some resource allocation issues, I would like to shift
> this VoIP meeting to
>  9am UTC 18th May 2016
> 
>  Please let me know if you are convenient or not with this time slot.

That later time is fine for me :)  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

[openstack-dev] [nova] api-ref sprint today & wed

[Sean Dague]

There is a lot of work to be done to get the api-ref into a final state.

Review / fix existing patches -
https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open
shows patches not yet merged. Please review them, and if there are
issues feel free to fix them.

Help create new API ref changes verifying some of the details -
https://wiki.openstack.org/wiki/NovaAPIRef

There is a burndown of the landed content here -
http://burndown.dague.org/ - we've started moving the needle, but there
is a long way to go.

Please pop up on #openstack-nova IRC if you have questions.

Thanks so far to our content contributors: Ronald Bradford, jichenjc,
Alex Xu, Sean Dague

And our reviewers: Alex Xu, Sean Dague

There is a ton of work to be done here, would love to have more
contributors dive in.

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] 答复: [probably forge email可能是仿冒邮件]Re: [vitrage] the section of vitrage.transformersin setup.cfg is not used

[dong . wenjuan]

Hi,

OK, i will fix it. Thank you for your response. :)

BR,
dwj







"Afek, Ifat (Nokia - IL)"  
2016-05-09 14:47
请答复 给
"OpenStack Development Mailing List \(not for usage questions\)" 



收件人
"OpenStack Development Mailing List (not for usage questions)" 

抄送

主题
[probably forge email可能是仿冒邮件]Re: [openstack-dev] [vitrage] the 
section of vitrage.transformersin setup.cfg is not used






Hi,
 
You are right, it is an old configuration that we should delete.
Thanks for reporting this bug, and you are welcome to contact us again 
with any questions or suggestions you might have J
 
Best regards,
Ifat.
 
 
From: EXT dong.wenj...@zte.com.cn [mailto:dong.wenj...@zte.com.cn] 
Sent: Monday, May 09, 2016 9:29 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [vitrage] the section of vitrage.transformers in 
setup.cfg is not used
 

Hi folks, 
I notice that in the setup.cfg file there is the `vitrage.transformers` 
section. 
It seems not be used. May I propose a bug to delete it? 
Thank you~ 

vitrage.transformers = 
nova.instance = 
vitrage.entity_graph.transformer.nova_transformer.instance_transformer.InstanceTransformer
 

nova.host = 
vitrage.entity_graph.transformer.nova_transformer.host_transformer.HostTransformer
 

nova.zone = 
vitrage.entity_graph.transformer.nova_transformer.zone_transformer.ZoneTransformer



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



ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
__
OpenStack Development Mailing 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] supporting OVS-DPDK and SRIOV

[Sanjay Upadhyay]

Hello Folks,

We have been working on Triple-O and NFV client for some time now.

We would like to work and get this feature (ovs-dpdk and sr-iov) rolled out
into tripleo installer.

We look for support and suggestions for the spec files -
ovs-dpdk - https://review.openstack.org/313871
sr-iov - https://review.openstack.org/313872

As it's our new steps into hacking tripleo, we welcome any suggestions.

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

[openstack-dev] [horizon] Feature Freeze one week earlier in Newton.

[Rob Cresswell (rcresswe)]

Hi all,

As requested we’ll be moving our feature freeze in Newton to R-6 
(http://releases.openstack.org/newton/schedule.html). This is one week earlier 
than in previous cycles, to give plugins a chance to finalise their own 
features for Newton without risk of breaking changes. The FFE process remains 
the same.

The patch documenting this change is here: 
https://review.openstack.org/#/c/314075/

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

[openstack-dev] [Heat] Summit recap

[Thomas Herve]

Hi all,

Here are some of my thoughts on the Austin summit sessions. Don't
hesitate to ask questions or fix my misunderstanding. I'll try to keep
it short, please also refer to the etherpads for more details
(sometimes :)):
https://wiki.openstack.org/wiki/Design_Summit/Newton/Etherpads#Heat


Release model
--

We'll continue to as usual in the cycle-with-milestones, and
investigate having a shorter feature freeze for more flexibility.


Default to convergence
-

Now's the time to enable it by default. We have a bunch of small
things to fix in tests, but the main point is to check that projects
using Heat work fine. If we can pull it off I hope to do the switch by
newton-1, so in 3 weeks. That we'll leave us with plenty of time for
feedback and improvements


Convergence improvements


There are some changes that we can now make to use convergence, like
not polling on hooks, which would be nice. But the main part is to
work on performance, to close the gap with the legacy engine. There is
at least one issue with messaging that we need to investigate.


Performance
--

This is what I hope will be a focus for the cycle, especially with
regard to large stacks. We have one major issue with the way we handle
files in the environment, which clogs our memory usage. That fix is in
good progress, once merged we'll find some smaller things to
incrementally improve on. We need to measure more to be able detect
regressions early and test new approaches. I'll see with infra if we
can get a periodic job for that and how storage works.


Continuous observer
--

The outcome of that session was basically that we don't want to do
this in Heat, at least for the time being. First, we're missing the
notifications on the resources that we spawn. Until that functionality
exists in OpenStack, it'll be tough to write a generic solution. Then,
it's a policy driven mechanism, and you need to be able to customize
how to react to failure on resources. So for now we want to document
how you can use the current APIs outside of Heat to achieve this, and
make sure that it works fine.


HOT parser
-

This was somewhat tricky subject, as we tried to mix external template
validation and template building. The former is difficult to pull off
without being wrong, duplicate efforts, or slowing down development
too much. It may be possible to do some basic validation, and we'll
see if we can create a reusable library for that. The latter is a bit
more clear (at least to me), and I hope something will be available
for Newton.


New heatclient commands
--

We listed improvements that can be made now that we completed the move
to OSC. I'm really interested on a way to get failures more easily, as
it's a common pattern and it'll improve user experience quite a bit.


Software deployment refinements


We decided to add a new property on SoftwareConfig indicating the
inputs which creates a replacement. We also need to improve timeouts
management, and allow the ability to send data when deployments are in
progress to get debug information.


Using DLM


We managed to not talk about ZooKeeper too much :). We want to remove
the database locks that we have and use tooz instead. The key is to
provide a nice upgrade path, so starting with the locks use for
convergence seems easier. If it turns out to be painless, we'll move
the stack locks from the legacy engine as well.


Validation improvements
---

Many subjects were mentioned here, with regard to the HOT parser topic
as well. The change I'd like to see is using placeholder objects
everywhere instead of None, so that we can clarify validations of
non-resolved data.


Integration tests
---

Not much to say on that subject. We want to move to use tempest
plugin, and the tempest runner, and remove as much custom code that we
have as possible.


Thanks,

-- 
Thomas

__
OpenStack Development Mailing 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] [tc] supporting Go

[Rayson Ho]

On Mon, May 9, 2016 at 4:57 AM, Thomas Goirand  wrote:
>
> Do you know if that's already in use in some distros?

Since the Go toolchain is pretty self-contained, most people just follow
the official instructions to get it installed... by a one-step:

# tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz

(Ref: https://golang.org/doc/install )

IMO, that the beauty of Go (the Go compiler is itself written in Go) -- as
the compiler generates static binaries, deployment is usually done by
copying the binaries to the remote machine.


And looks like Ubuntu 16.04 has official binaries for Go 1.6. Again, I've
never installed Go from apt-get or yum!

https://launchpad.net/ubuntu/xenial/+source/golang-1.6

Rayson

==
Open Grid Scheduler - The Official Open Source Grid Engine
http://gridscheduler.sourceforge.net/
http://gridscheduler.sourceforge.net/GridEngine/GridEngineCloud.html


>
> Cheers,
>
> Thomas
>
>
> __
> OpenStack Development Mailing 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] weekly meeting #80

[Emilien Macchi]

Hi,

Tomorrow, we'll have our weekly meeting, I added a few topics:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160510

Feel free to add more and also submit any outstanding bug or patch.

Thanks,

On Tue, May 3, 2016 at 7:58 AM, Emilien Macchi  wrote:
> Hi,
>
> If you have any topic that you would like to discuss, please add it to
> the topic list:
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160503
>
> If we don't have topics, we'll probably cancel the meeting this week.
> I'm currently working on a summary of what happened during the Summit
> for Puppet OpenStack project.
>
> Thanks,
> --
> Emilien Macchi



-- 
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] [Heat] Summit recap

[Julien Danjou]

On Mon, May 09 2016, Thomas Herve wrote:


[…]

> Using DLM
> 
>
> We managed to not talk about ZooKeeper too much :). We want to remove
> the database locks that we have and use tooz instead. The key is to
> provide a nice upgrade path, so starting with the locks use for
> convergence seems easier. If it turns out to be painless, we'll move
> the stack locks from the legacy engine as well.

I don't know what stack lock so my apologies if I'm saying anything
wrong.

There might be a nice upgrade path solution, which is to use your
database as the lock manager. Tooz provides locking primitive against
MySQL and PostgreSQL with their respective driver.

We do that by default in Gnocchi. It offers a very nice and simple
"works by default": Gnocchi picks the database URL and pass it to Tooz,
so we have a DLM "for free".

Then, bigger deployments can tweak the Tooz URL to make it point to
something more robust (ZooKeeper, etcd…).

My 2c,

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


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

Re: [openstack-dev] [tc] Swift api compat. Was: supporting Go

[Fox, Kevin M]

Yeah, the data plane api is much more complicated then the control plane. I 
agree the control api would be a pretty thin api. But just because its thin 
doesnt mean its not increadibly useful. :)

Also, just because the community isnt screaming yet doesnt mean its not really 
broken. We tend to put up with a lot of brokenness for a long time.

The lack of desire to split the two by swift makes sence. It forces some sites 
to have to use the implementation. It also makes sense though for them to allow 
it. Then swift might be added as an additional flavor to clouds that normally 
wouldnt.

I think if we raised the question of team forming to the storage vendors that 
have alternate swift data plane implementations, some developers to do the work 
might start showing up. I know we had to turn down a few of them this summit 
since they couldnt replace our existing endpoint. It can take a little while 
for the message to make it from the sales teams to developer teams.

Does the tc have an established channel to them to ask the question? If not, 
cinder has a pretty good channel I think. Maybe that could be used.

Thanks,
Kevin


From: Thierry Carrez
Sent: Monday, May 09, 2016 1:53:06 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc] Swift api compat. Was: supporting Go

Fox, Kevin M wrote:
> I think part of the problem with the whole Swift situation is that it does 
> something most other OpenStack projects don't do. Its both a control plane 
> and a data plane.
> [...]

Yes, it is certainly part of the Go rationale (I wouldn't say
"problem"). Swift implementing a data plane has more performance
constraints and therefore replacing critical parts of it (of not all of
it) in Go makes more sense there than anywhere else in OpenStack.

To your other point, it is also true that Swift does not act as an
integration engine for available object storage technologies, and
therefore is a bit unique in the OpenStack landscape.

Splitting Swift into two components (an OpenStack API/integration
front-end and a pluggable separate object storage backend) was suggested
in the past. The main objection to such a split by Swift developers was
that there is no good split line in the Swift codebase -- the API
frontend would end up being extremely thin. Maybe the lines moved over
the last 3 years, but I doubt it.

There is of course little internal incentive in the Swift team to work
on such decoupling (since they are 99% focused on the Swift engine). To
make it really happen would probably require a separate team driving it
and/or a more... radical change on the governance side. The fact that
there is no such team forming (or more support for radical change)
suggests that the situation is not critically broken...

--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [trove] timeouts in gate-trove-python34-db

[Peter Stachowski]

Hi Amrith,

We've had a lot of 'new' tests enabled for py34 in the last week - from your 
results you can see it's running 6x the number of tests (although it's taking 
8.5x as long).  It looks like python3 isn't as fast as python2.7?  If so, we 
may have to do something wrt the 'dangling-mock' detector code so that the 
tests run faster (I believe we can optimize it now that all the tests have 
moved over to the new paradigm).

Peter

From: Amrith Kumar [mailto:amr...@tesora.com]
Sent: May-08-16 8:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [trove] timeouts in gate-trove-python34-db


I'm seeing python34's gate job running very long and sometimes it is timing out 
at 40m. There is something amiss with this and I've let Victor and Abhishek 
know about it.



In https://review.openstack.org/#/c/313941/ which is a dummy commit (just 
changed README.rst) it took 37m.



2016-05-08 21:35:11.438 | Tests running...

2016-05-08 21:35:11.438 |

2016-05-08 21:35:11.438 | Ran 686 tests in 1581.090s

2016-05-08 21:35:11.439 | OK



On the other hand, in other reviews (https://review.openstack.org/#/c/222752/) 
it takes barely 15m.



2016-05-02 19:26:06.018 | Tests running...

2016-05-02 19:26:06.019 |

2016-05-02 19:26:06.019 | Ran 115 tests in 185.864s

2016-05-02 19:26:06.019 | OK



Running it on my desktop takes a long time as well. I guess we'll have to 
figure out why this is generating these failures.



-amrith
__
OpenStack Development Mailing 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][oslo] oslo.versionedobjects 1.9.0 release (newton)

[no-reply]

We are gleeful to announce the release of:

oslo.versionedobjects 1.9.0: Oslo Versioned Objects library

This release is part of the newton release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.versionedobjects 1.7.0..1.9.0
-

ad5d78d Updated from global requirements
1541c54 Imported Translations from Zanata
592c3ce Remove direct dependency on babel
d12a32b Imported Translations from Zanata
85dcf71 Introduce fixture to enforce sorted order for object changes
bb1fe93 Expose object context thru a public property
761b9d7 Updated from global requirements
50ac4b7 Updated from global requirements
09a39be Updated from global requirements
480cae4 Updated from global requirements
3d188b8 Updated from global requirements
0c7ec37 Add BaseEnumField valid_values introspection
788e3d0 Use primitive type name in ValueError for Object field coerce failure
c459d5e Update formatting for example statemachine field
15d9637 Remove the executable bit from files
e6c275a Updated from global requirements

Diffstat (except docs and test files)
-

oslo_versionedobjects/base.py  |  4 ++
oslo_versionedobjects/fields.py| 76 +-
oslo_versionedobjects/fixture.py   | 30 +
.../LC_MESSAGES/oslo_versionedobjects-log-error.po | 27 
.../LC_MESSAGES/oslo_versionedobjects-log-error.po |  8 +--
.../en_GB/LC_MESSAGES/oslo_versionedobjects.po |  8 +--
.../LC_MESSAGES/oslo_versionedobjects-log-error.po | 27 
.../LC_MESSAGES/oslo_versionedobjects-log-error.po |  8 +--
.../LC_MESSAGES/oslo_versionedobjects-log-error.po | 27 
.../locale/oslo_versionedobjects-log-error.pot | 10 +--
.../locale/oslo_versionedobjects.pot   | 48 +-
requirements.txt   |  9 ++-
setup.cfg  |  2 +-
17 files changed, 254 insertions(+), 71 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index b252929..a0b5a14 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5 +4,0 @@ six>=1.9.0 # MIT
-Babel>=1.3 # BSD
@@ -7,3 +6,3 @@ oslo.concurrency>=3.5.0 # Apache-2.0
-oslo.config>=3.4.0 # Apache-2.0
-oslo.context>=0.2.0 # Apache-2.0
-oslo.messaging>=4.0.0 # Apache-2.0
+oslo.config>=3.9.0 # Apache-2.0
+oslo.context>=2.2.0 # Apache-2.0
+oslo.messaging>=4.5.0 # Apache-2.0
@@ -12 +11 @@ oslo.utils>=3.5.0 # Apache-2.0
-iso8601>=0.1.9 # MIT
+iso8601>=0.1.11 # MIT



__
OpenStack Development Mailing 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] [trove] timeouts in gate-trove-python34-db

[Amrith Kumar]

So I'm able to run the py34 tests in about 10s if I run the dangling mock 
detector with a depth of 0 or 1.

I'd also like to figure out how we can get the py34 tests to show progress like 
py27 does. If a test fails, it is much harder to debug as it is now ...

-amrith

From: Peter Stachowski [mailto:pe...@tesora.com]
Sent: Monday, May 09, 2016 10:17 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [trove] timeouts in gate-trove-python34-db

Hi Amrith,

We've had a lot of 'new' tests enabled for py34 in the last week - from your 
results you can see it's running 6x the number of tests (although it's taking 
8.5x as long).  It looks like python3 isn't as fast as python2.7?  If so, we 
may have to do something wrt the 'dangling-mock' detector code so that the 
tests run faster (I believe we can optimize it now that all the tests have 
moved over to the new paradigm).

Peter

From: Amrith Kumar [mailto:amr...@tesora.com]
Sent: May-08-16 8:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [trove] timeouts in gate-trove-python34-db


I'm seeing python34's gate job running very long and sometimes it is timing out 
at 40m. There is something amiss with this and I've let Victor and Abhishek 
know about it.



In https://review.openstack.org/#/c/313941/ which is a dummy commit (just 
changed README.rst) it took 37m.



2016-05-08 21:35:11.438 | Tests running...

2016-05-08 21:35:11.438 |

2016-05-08 21:35:11.438 | Ran 686 tests in 1581.090s

2016-05-08 21:35:11.439 | OK



On the other hand, in other reviews (https://review.openstack.org/#/c/222752/) 
it takes barely 15m.



2016-05-02 19:26:06.018 | Tests running...

2016-05-02 19:26:06.019 |

2016-05-02 19:26:06.019 | Ran 115 tests in 185.864s

2016-05-02 19:26:06.019 | OK



Running it on my desktop takes a long time as well. I guess we'll have to 
figure out why this is generating these failures.



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

Re: [openstack-dev] [kolla] Gate precheck job failed due to minimum kernel version on ubuntu 14.04

[Steven Dake (stdake)]

On 5/8/16, 7:55 AM, "Monty Taylor"  wrote:

>On 05/08/2016 03:45 AM, Steve Kowalik wrote:
>> On 08/05/16 08:11, lương hữu tuấn wrote:
>>> Hi,
>>>
>>> @Robert: I was successful to update the kernel without change the
>>>image.
>>
>> But that was Robert's point entirely. Installing the kernel will work
>> fine, but it does not get you running that kernel -- also like Robert
>> said, you need to change the image to run a different kernel than what
>> it has installed.
>>
>
>We will be changing our images this cycle to Xenial from Trusty. I do
>not believe we have any intention of installing backported wily kernels
>in our trusty images, as what we want to test on them is Trusty.
>
>However, the Xenial transition should be happening soon enough - so
>things that need a newer kernel this release can happily just require
>Xenial images for testing.
>
>I think the question of why/how kolla grew a dependency on a newer
>kernel than what trusty has is worth checking. As of right now, trusty
>kernels are the newest thing supported in the gate.

Monty,

One of our dependencies, Docker, only works with the btrfs storage driver
on Trusty.  All other storage drivers for Trusty are DOA on Trusty without
kernel recompiles.  CentOS 7 works well with all storage drivers, although
overlayfs is a little flakey when building images because of  the yum OVL
plugin.  We recommend in the docs to upgrade the kernel to Willy howver
Xenail should work as well.

What comes out of this is a recommendation to use BTRFS as the storage
backend when using Trusty.  We should be documenting that anyway.

Regards
-steve

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

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

[openstack-dev] Ansible inventory - Would you need another inventory system for your openstack cloud and how would you like it to be?

[Jean-Philippe Evrard]

Hello everyone,

I am using ansible for some time now, and I think the current default Ansible 
inventory system is lacking a few features, at least when working on an 
OpenStack cloud - whether it's for its deployment, its support or its usage.
I'm thinking of developing a new inventory, based on (openstack-)ansible 
experience.


I started an etherpad [1], listing what I personnally expect from a proper 
ansible inventory system for OpenStack. Therefore, if you worked on 
ansible/inventory systems before, I'd be happy to have a return of your 
experience. So if you think about features you like/dislike in the way ansible 
fits your workflow for OpenStack, please write it down on the etherpad! (or 
vote for the things you really like).


I think all the results from this etherpad could be either used for ansible 
upstream or for the openstack-ansible project, so that's why I'm spamming here. 
Thank for your help!

Best regards,

Jean-Philippe Evrard


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

Re: [openstack-dev] [kolla] Gate precheck job failed due to minimum kernel version on ubuntu 14.04

[James Page]

On Sun, 8 May 2016 at 15:58 Monty Taylor  wrote:

> On 05/08/2016 03:45 AM, Steve Kowalik wrote:
> > On 08/05/16 08:11, lương hữu tuấn wrote:
> >> Hi,
> >>
> >> @Robert: I was successful to update the kernel without change the image.
> >
> > But that was Robert's point entirely. Installing the kernel will work
> > fine, but it does not get you running that kernel -- also like Robert
> > said, you need to change the image to run a different kernel than what
> > it has installed.
> >
>
> We will be changing our images this cycle to Xenial from Trusty. I do
> not believe we have any intention of installing backported wily kernels
> in our trusty images, as what we want to test on them is Trusty.
>
> However, the Xenial transition should be happening soon enough - so
> things that need a newer kernel this release can happily just require
> Xenial images for testing.
>
> I think the question of why/how kolla grew a dependency on a newer
> kernel than what trusty has is worth checking. As of right now, trusty
> kernels are the newest thing supported in the gate.
>

Probably worth noting that trusty does provide hardware enablement
(sometimes referred to as HWE) kernels from newer Ubuntu releases in
archive; however they are not used as the base for Ubuntu Cloud Images
(which just use the release kernel version for 14.04 which is 3.13) and
evidently the trusty images in gate.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Gate precheck job failed due to minimum kernel version on ubuntu 14.04

[Hui Kang]

FYI, I filed a bug about this issue
https://bugs.launchpad.net/kolla/+bug/1579583

- Hui

On Mon, May 9, 2016 at 10:42 AM, Steven Dake (stdake)  wrote:
>
>
> On 5/8/16, 7:55 AM, "Monty Taylor"  wrote:
>
>>On 05/08/2016 03:45 AM, Steve Kowalik wrote:
>>> On 08/05/16 08:11, lương hữu tuấn wrote:
 Hi,

 @Robert: I was successful to update the kernel without change the
image.
>>>
>>> But that was Robert's point entirely. Installing the kernel will work
>>> fine, but it does not get you running that kernel -- also like Robert
>>> said, you need to change the image to run a different kernel than what
>>> it has installed.
>>>
>>
>>We will be changing our images this cycle to Xenial from Trusty. I do
>>not believe we have any intention of installing backported wily kernels
>>in our trusty images, as what we want to test on them is Trusty.
>>
>>However, the Xenial transition should be happening soon enough - so
>>things that need a newer kernel this release can happily just require
>>Xenial images for testing.
>>
>>I think the question of why/how kolla grew a dependency on a newer
>>kernel than what trusty has is worth checking. As of right now, trusty
>>kernels are the newest thing supported in the gate.
>
> Monty,
>
> One of our dependencies, Docker, only works with the btrfs storage driver
> on Trusty.  All other storage drivers for Trusty are DOA on Trusty without
> kernel recompiles.  CentOS 7 works well with all storage drivers, although
> overlayfs is a little flakey when building images because of  the yum OVL
> plugin.  We recommend in the docs to upgrade the kernel to Willy howver
> Xenail should work as well.
>
> What comes out of this is a recommendation to use BTRFS as the storage
> backend when using Trusty.  We should be documenting that anyway.
>
> Regards
> -steve
>
>>
>>__
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] API-WG summit session recap

[michael mccune]

hello all,

We had a great session for the API working group in Austin, and I wanted 
to give a brief recap and extend a thank you to all who attended.


There were about 20-30 people in attendance for the double session 
fishbowl that took place on monday. This turnout was one of the larger 
we have had for the past few summits and it was exciting to see this 
level of engagement from the community. again, thank you =)


Full notes from the session can be found on the etherpad from summit[1].

The session began with a recap of the group's activities for the Mitaka 
cycle. We discussed the guidelines that have been added, as well as our 
success stories with regards to projects that have sought advice from 
the group.


With the old business out of the way, we moved on to discuss topics that 
are of importance to the group moving forward.


Promoting the guidelines


The heart of the API-WG has always been the guidelines that are 
produced, we had a nice discussion about how we can increase the 
awareness and usage of the guidelines.


One big request that came out of this discussion is the need to cleanup 
the group's guideline page to make it clearer which pages are just place 
holders and which contain guidelines.


The group talked about if, and how, we can better integrate with other 
working groups to help create a broader network for the guidelines and 
better APIs in general. The two main groups that were identified as 
possible partners are the Application Ecosystem WG and the SDK WG. 
Although these groups have different focuses than just APIs, there is 
certainly some room for collaboration and consensus among all the groups.


There was also a strong discussion about how the group could advocate 
for more projects to use the guidelines. The main result of this talk 
was the idea of an API-WG related governance tag. Having this tag would 
make a nice signal to end-users about the maturity and development 
status of a project's APIs. Although the details are still in flux, the 
main criteria of a tag were related to projects self-electing into the 
tag, and then creating a series of tests that would prove how their APIs 
follow the guidelines, as well as providing proper API documentation. 
This is still very much a work in progress.


Reviewing the guideline process
===

If the guidelines are the heart of the WG, then our review process is 
the pacemaker ;)


Within the group, a discussion had started before summit about the level 
of email we produce and if it is sufficient. When brought to the table 
at summit, this conversation continued and was well received by the 
audience.


There were several good suggestions about how we can more easily 
communicate what is happening within the group, the state of guidelines 
and reviews that need attention from the group.


the ultimate result of this discussion is that the API-WG will work over 
the Newton cycle to create a weekly email similar to the "What's Up Doc" 
emails from the doc team. These emails will include a summary of 
guidelines that are in freeze, those that have been recently merged, and 
a list of reviews with APIImpact as well as any other business the WG 
might have.


Improving WG participation
==

A constant note from many groups within the OpenStack community is 
participation. The API-WG is no stranger to this topic as we have 
continually searched for methods of improving participation from 
interested parties.


Although there were no clear solutions on this topic, there was wide 
agreement that relying on the CPLs for better engagement with the WG is 
a strong way forward. To this end, the WG will work to make it easier 
for CPLs to bring their APIImpact reviews, and their special interest 
topics, to the group. The methods for doing this will mainly center 
around being more focused in our mailings, and improving our 
communication with respect to guideline reviews.


Dropping the UTC meeting


Somewhere around the Kilo cycle, the API-WG added a second meeting time 
to help our friends in the Asian and Pacific regions join the 
discussion. Unfortunately, after a few cycles of this meeting, its 
attendance is nearly always zero. After some discussion during the 
summit, we have agreed to remove this meeting and return to a single 
weekly meeting at 1600UTC on Thursdays. If the need arises in the 
future, the API-WG will be more than happy to reinstate this meeting.



That about wraps up the review from our summit session, hopefully I 
haven't left out too many details ;)


Thanks again to everyone who attended the session, and thanks to the 
OpenStack community for another excellent summit.


regards,
mike

[1]: https://etherpad.openstack.org/p/austin-api-wg-session-plans

__
OpenStack Development Mailing List (not for usage questions)
Unsubscrib

Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration

[Weyl, Alexey (Nokia - IL)]

Hi Tim,

I agree – creating a datasource from Vitrage to Congress is the first step, and 
we should have some concrete use case in mind to help guide this process.

The most straightforward use case I would suggest is when there is a problem on 
an instance that is caused by some problem on the physical host. Then:


· Vitrage will notify about an alarm on the instance, which Congress 
will receive

· Congress can then call the Vitrage RCA API. The response will state 
that the cause of the instance alarm is the host alarm.

· Congress policy can define that in such a case, the instance should 
be migrated to (or healed on) a different physical host

Does this seem like a good first step for you?

Thanks,
Alexey

From: Tim Hinrichs [mailto:t...@styra.com]
Sent: Saturday, May 07, 2016 2:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration

Hi Alexey,

Thanks for the overview of how you see a Congress-Vitrage integration being 
valuable.

I'd imagine that the right first step in this integration would be creating a 
new datasource driver within Congress to pull data from Vitrage.  It doesn't 
need to pull all the data in your list to start, but enough so that we can try 
writing policy over that data.  It's helpful to have a policy in mind that you 
want to write and then set up the datasource driver to grab enough of the 
Vitrage data to write that policy.  Here are the relevant docs.

Datasource drivers
http://docs.openstack.org/developer/congress/cloudservices.html

Writing policy
http://docs.openstack.org/developer/congress/policy.html

Let me know if you have any questions,
Tim



On Wed, May 4, 2016 at 11:51 PM Weyl, Alexey (Nokia - IL) 
mailto:alexey.w...@nokia.com>> wrote:
Hi to all Vitrage and Congress contributors,

We had a good introduction meeting in Austin and we (Vitrage) think that we can 
have a good collaboration between the projects.

Vitrage, as an Openstack Root Cause Analysis (RCA) Engine, builds a topology 
graph of all the entities in the system (physical, virtual and application) 
from different datasources. It thus can enrich Congress by providing more data 
about what is happening in the system. Additionally, the Vitrage RCA and deduce 
alarms & states mechanism can enhance the visibility of faults and how they 
inter-relate.  By using this information Congress could then execute different 
policies and perform more accurate actions.

Another good property of Vitrage is that it can receive data also from 
non-openstack sources, like Nagios, which monitor the physical resources, 
including Switches (which are not modeled today in OpenStack).

There are many ways in which Congress-Vitrage combination would be helpful. To 
take just one example:
a. If a physical Switch is down, Vitrage can raise deduced alarms on the 
connected hosts and on the virtual machines affected by this change in switch 
state.
b. Congress will then be notified by Vitrage about these alarms, which can set 
off Congress policies of migration.
c. Furthermore, due to the RCA functionality, Congress will be aware that the 
Switch error is the source of the problem, and can determine the best place to 
create new instances of the VMs so that this  switch fault will not impact the 
new instances.

As you can see, for each fault, we can use Vitrage to link it to other faults, 
and create alarms to reflect them. This is all done via Vitrage Templates, so 
the system is configurable to the needs of the user. Thus many more cases such 
as the example above could be thought of.

To summarize, Vitrage can enrich Congress with the following four features:
a. RCA
b. Deduced alarms
c. Physical, virtual and application layers
d. Graph structure and topology of the system that defines the connections and 
relationships between all entities on which we can run quick graph algorithms 
to decide different actions to perform

If you can think of additional use cases that can be used here, please share ☺

For more data about Vitrage and its insights please take a look here:
https://wiki.openstack.org/wiki/Vitrage

Best Regards,
Alexey Weyl

__
OpenStack Development Mailing 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] [Neutron] FYI: Changed my irc nick to andreas_s (formerly scheuran)

[Andreas Scheuring]

-- 
-
Andreas (IRC: andreas_s) 



__
OpenStack Development Mailing 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][oslo] futurist 0.14.0 release (newton)

[no-reply]

We are eager to announce the release of:

futurist 0.14.0: Useful additions to futures, from the future.

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/futurist

With package available at:

https://pypi.python.org/pypi/futurist

Please report issues through launchpad:

http://bugs.launchpad.net/futurist

For more details, please see below.

Changes in futurist 0.13.0..0.14.0
--

8166a43 Updated from global requirements
29c5d14 Fix 'on_failure' param not be used
e74a776 Use prettytable to show pretty schedule/active/planned time table
9c41f41 Fix time related check in rejection test
74a8c7a Reduce/remove duplication in run functions
81991b6 Fix jitter strategies

Diffstat (except docs and test files)
-

futurist/periodics.py| 208 ---
requirements.txt |   1 +
4 files changed, 234 insertions(+), 91 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 5b22cfd..3ad5791 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -9,0 +10 @@ contextlib2>=0.4.0 # PSF License
+PrettyTable<0.8,>=0.7 # BSD



__
OpenStack Development Mailing 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][oslo] mox3 0.15.0 release (newton)

[no-reply]

We are chuffed to announce the release of:

mox3 0.15.0: Mock object framework for Python

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/mox3

With package available at:

https://pypi.python.org/pypi/mox3

Please report issues through launchpad:

http://bugs.launchpad.net/python-mox3

For more details, please see below.

Changes in mox3 0.14.0..0.15.0
--

a2752b8 Updated from global requirements
834728a Updated from global requirements

Diffstat (except docs and test files)
-

requirements.txt  | 2 +-
test-requirements.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 7722031..25cfc5d 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@ pbr>=1.6 # Apache-2.0
-fixtures>=1.3.1 # Apache-2.0/BSD
+fixtures<2.0,>=1.3.1 # Apache-2.0/BSD
diff --git a/test-requirements.txt b/test-requirements.txt
index 657fed0..ad30fa2 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -9 +9 @@ pyflakes==0.8.1 # MIT
-flake8<2.6.0,>2.4.1 # MIT
+flake8<2.6.0,>=2.5.4 # MIT



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

[no-reply]

We are chuffed to announce the release of:

oslo.concurrency 3.8.0: Oslo Concurrency library

This release is part of the newton release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.concurrency 3.6.0..3.8.0


0982776 Updated from global requirements
342efd3 Imported Translations from Zanata
8af8269 processutils: add support for missing process limits
7bc24c5 Remove direct dependency on babel
ca59541 Updated from global requirements
6da5df0 Updated from global requirements
f22886e Updated from global requirements
cbdf411 Add a few usage examples for lockutils
499d5aa Revert "Use tempfile.tempdir for lock_path if OSLO_LOCK_PATH is not set"
951be63 Updated from global requirements
5021ef8 Use tempfile.tempdir for lock_path if OSLO_LOCK_PATH is not set

Diffstat (except docs and test files)
-

.../en_GB/LC_MESSAGES/oslo_concurrency-log-info.po |  8 ++--
.../locale/en_GB/LC_MESSAGES/oslo_concurrency.po   |  8 ++--
.../es/LC_MESSAGES/oslo_concurrency-log-info.po|  8 ++--
.../locale/es/LC_MESSAGES/oslo_concurrency.po  |  8 ++--
.../fr/LC_MESSAGES/oslo_concurrency-log-info.po|  8 ++--
.../locale/fr/LC_MESSAGES/oslo_concurrency.po  |  8 ++--
.../locale/oslo_concurrency-log-info.pot   | 14 +++---
oslo_concurrency/locale/oslo_concurrency.pot   | 38 
oslo_concurrency/prlimit.py| 21 +
oslo_concurrency/processutils.py   | 38 +++-
requirements.txt   |  5 +--
test-requirements.txt  |  2 +-
14 files changed, 189 insertions(+), 65 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 74b224d..aa28515 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +5,0 @@ pbr>=1.6 # Apache-2.0
-Babel>=1.3 # BSD
@@ -8,2 +7,2 @@ enum34;python_version=='2.7' or python_version=='2.6' or 
python_version=='3.3' #
-iso8601>=0.1.9 # MIT
-oslo.config>=3.4.0 # Apache-2.0
+iso8601>=0.1.11 # MIT
+oslo.config>=3.9.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index f9925e1..d9b4f55 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -9 +9 @@ futures>=3.0;python_version=='2.7' or python_version=='2.6' # BSD
-fixtures>=1.3.1 # Apache-2.0/BSD
+fixtures<2.0,>=1.3.1 # Apache-2.0/BSD



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

[no-reply]

We are gleeful to announce the release of:

oslo.context 2.3.0: Oslo Context library

This release is part of the newton release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.context 2.2.0..2.3.0


82ffe9e Drop babel as requirement since its not used
d6585a8 Updated from global requirements
c63a359 Ensure to_dict() supports unicode

Diffstat (except docs and test files)
-

oslo_context/context.py| 2 +-
requirements.txt   | 1 -
3 files changed, 4 insertions(+), 3 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index b2608e4..95d0fe8 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +5,0 @@ pbr>=1.6 # Apache-2.0
-Babel>=1.3 # BSD



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

[no-reply]

We are pleased to announce the release of:

oslo.log 3.6.0: oslo.log library

This release is part of the newton release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.log 3.5.0..3.6.0


4f1ae84 Imported Translations from Zanata

Diffstat (except docs and test files)
-

oslo_log/locale/es/LC_MESSAGES/oslo_log.po |  8 
oslo_log/locale/ja/LC_MESSAGES/oslo_log.po |  8 
oslo_log/locale/oslo_log.pot   | 28 ++--
3 files changed, 22 insertions(+), 22 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] [release][oslo] oslo.cache 1.7.0 release (newton)

[no-reply]

We are tickled pink to announce the release of:

oslo.cache 1.7.0: Cache storage for Openstack projects.

This release is part of the newton release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.cache 1.5.0..1.7.0
--

d51ce5a Imported Translations from Zanata
7569f7d Remove direct dependency on babel
d2189db Imported Translations from Zanata
9bf41ef Updated from global requirements
ea191ca If caching is globally disabled force dogpile to use the null backend
e686318 Updated from global requirements
7961acc Updated from global requirements

Diffstat (except docs and test files)
-

oslo_cache/_opts.py   |  4 +-
oslo_cache/core.py|  4 +-
oslo_cache/locale/de/LC_MESSAGES/oslo_cache.po| 54 +++
oslo_cache/locale/es/LC_MESSAGES/oslo_cache.po| 55 
oslo_cache/locale/fr/LC_MESSAGES/oslo_cache.po| 55 
oslo_cache/locale/it/LC_MESSAGES/oslo_cache.po| 54 +++
oslo_cache/locale/ko_KR/LC_MESSAGES/oslo_cache.po | 52 +++
oslo_cache/locale/oslo_cache.pot  | 63 +++
oslo_cache/locale/pt_BR/LC_MESSAGES/oslo_cache.po | 55 
oslo_cache/locale/ru/LC_MESSAGES/oslo_cache.po| 56 
oslo_cache/locale/tr_TR/LC_MESSAGES/oslo_cache.po | 52 +++
oslo_cache/locale/zh_CN/LC_MESSAGES/oslo_cache.po | 51 ++
oslo_cache/locale/zh_TW/LC_MESSAGES/oslo_cache.po | 52 +++
requirements.txt  |  3 +-
setup.cfg |  2 +-
16 files changed, 621 insertions(+), 5 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index c005c80..35f4848 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5 +4,0 @@
-Babel>=1.3 # BSD
@@ -8 +7 @@ six>=1.9.0 # MIT
-oslo.config>=3.7.0 # Apache-2.0
+oslo.config>=3.9.0 # Apache-2.0



__
OpenStack Development Mailing 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] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[thomas.morin]

Hi Cathy,

Cathy Zhang:

I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday. Hope 
this time is good for all people who have interest and like to contribute to 
this work. We plan to start the first meeting on May 17.


I would be happy to participate, but I'm unlikely to be able to attend 
at that time.

Might 15:00 UTC work for others ?
If not, well, I'll make do with log/emails/pads/gerrit interactions.

-Thomas




-Original Message-
From: Cathy Zhang
Sent: Thursday, April 21, 2016 11:43 AM
To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions); 
Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim Daniel; Mathieu Rohon; 
Shaughnessy, David; Eichberger, German; Henry Fourie; arma...@gmail.com; Miguel 
Angel Ajo; Reedip; Thierry Carrez
Cc: Cathy Zhang
Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Hi everyone,

We have room 400 at 3:10pm on Thursday available for discussion of the two 
topics.
Another option is to use the common room with roundtables in "Salon C" during 
Monday or Wednesday lunch time.

Room 400 at 3:10pm is a closed room while the Salon C is a big open room which 
can host 500 people.

I am Ok with either option. Let me know if anyone has a strong preference.

Thanks,
Cathy


-Original Message-
From: Cathy Zhang
Sent: Thursday, April 14, 2016 1:23 PM
To: OpenStack Development Mailing List (not for usage questions); 'Ihar 
Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim Daniel'; 'Mathieu 
Rohon'; 'Shaughnessy, David'; 'Eichberger, German'; Cathy Zhang; Henry Fourie; 
'arma...@gmail.com'
Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Thanks for everyone's reply!

Here is the summary based on the replies I received:

1.  We should have a meet-up for these two topics. The "to" list are the people 
who have interest in these topics.
 I am thinking about around lunch time on Tuesday or Wednesday since some 
of us will fly back on Friday morning/noon.
 If this time is OK with everyone, I will find a place and let you know 
where and what time to meet.

2.  There is a bug opened for the QoS Flow Classifier 
https://bugs.launchpad.net/neutron/+bug/1527671
We can either change the bug title and modify the bug details or start with a 
new one for the common FC which provides info on all requirements needed by all 
relevant use cases. There is a bug opened for OVS agent extension 
https://bugs.launchpad.net/neutron/+bug/1517903

3.  There are some very rough, ugly as Sean put it:-), and preliminary work on 
common FC https://github.com/openstack/neutron-classifier which we can see how 
to leverage. There is also a SFC API spec which covers the FC API for SFC usage 
https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst,
the following is the CLI version of the Flow Classifier for your reference:

neutron flow-classifier-create [-h]
 [--description ]
 [--protocol ]
 [--ethertype ]
 [--source-port :]
 [--destination-port :]
 [--source-ip-prefix ]
 [--destination-ip-prefix ]
 [--logical-source-port ]
 [--logical-destination-port ]
 [--l7-parameters ] FLOW-CLASSIFIER-NAME

The corresponding code is here 
https://github.com/openstack/networking-sfc/tree/master/networking_sfc/extensions

4.  We should come up with a formal Neutron spec for FC and another one for OVS 
Agent extension and get everyone's review and approval. Here is the etherpad 
catching our previous requirement discussion on OVS agent (Thanks David for the 
link! I remember we had this discussion before) 
https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion


More inline.

Thanks,
Cathy


-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
Sent: Thursday, April 14, 2016 3:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Cathy Zhang  wrote:


Hi everyone,
Per Armando’s request, Louis and I are looking into the following
features for Newton cycle.
· Neutron Common FC used for SFC, QoS, Tap as a service etc.,
· OVS Agent extension
Some of you might know that we already developed a FC in
networking-sfc project and QoS also has a FC. It makes sense that we
have one common FC in Neutron that could be shared by SFC, QoS, Tap as a 
service etc.
features in Neutron.

I don’t actually know of any classifier in QoS. It’s only planned to emerge, 
but there are no specs or anything specific to the feature.

Anyway, I agree that classifier API belongs to core neutron and should be 
reused by all interested subprojects from there.


Different features may extend OVS agent and add different new OVS flow
tables to support their new functionality. A mechanism is 

Re: [openstack-dev] Ansible inventory - Would you need another inventory system for your openstack cloud and how would you like it to be?

[Monty Taylor]

On 05/09/2016 09:27 AM, Jean-Philippe Evrard wrote:

Hello everyone,

I am using ansible for some time now, and I think the current default
Ansible inventory system is lacking a few features, at least when
working on an OpenStack cloud - whether it's for its deployment, its
support or its usage.
I'm thinking of developing a new inventory, based on (openstack-)ansible
experience.


Before we talk about making a new OpenStack Inventory for ansible, let's 
work on fixing the existing one. We just replaced the nova.py dynamic 
inventory plugin in the last year with the new openstack.py system.


Gathering requirements and then making improvements to the current one 
is a GREAT idea. I'd love to hear the issues you're having with the 
current one.



I started an etherpad [1], listing what I personnally expect from a
proper ansible inventory system for OpenStack. Therefore, if you worked
on ansible/inventory systems before, I'd be happy to have a return of
your experience. So if you think about features you like/dislike in the
way ansible fits your workflow for OpenStack, please write it down on
the etherpad! (or vote for the things you really like).


From reading through the contents of the etherpad, it looks like you 
maybe haven't used openstack.py yet - or if you have the docs are not 
good enough to show you that it does most of what you're wanting. I'd be 
happy to connect on that. I've also added a few quick notes about things 
that are already there that you might not have been aware of.



I think all the results from this etherpad could be either used for
ansible upstream or for the openstack-ansible project, so that's why I'm
spamming here. Thank for your help!

Best regards,

Jean-Philippe Evrard


[1] https://etherpad.openstack.org/p/openstack-ansible-inventory-ideas



__
OpenStack Development Mailing 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] [release][oslo] debtcollector 1.4.0 release (newton)

[no-reply]

We are delighted to announce the release of:

debtcollector 1.4.0: A collection of Python deprecation patterns and
strategies that help you collect your technical debt in a non-
destructive manner.

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/debtcollector

With package available at:

https://pypi.python.org/pypi/debtcollector

Please report issues through launchpad:

http://bugs.launchpad.net/debtcollector

For more details, please see below.

Changes in debtcollector 1.3.0..1.4.0
-

c204667 Drop babel as requirement since its not used
3165b44 Updated from global requirements
29058b1 Updated from global requirements

Diffstat (except docs and test files)
-

requirements.txt  | 1 -
test-requirements.txt | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 010f7e8..395304c 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +5,0 @@ pbr>=1.6 # Apache-2.0
-Babel>=1.3 # BSD
diff --git a/test-requirements.txt b/test-requirements.txt
index 41fef15..b2db7ee 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -16 +16 @@ testtools>=1.4.0 # MIT
-fixtures>=1.3.1 # Apache-2.0/BSD
+fixtures<2.0,>=1.3.1 # Apache-2.0/BSD



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

[no-reply]

We are glad to announce the release of:

oslo.policy 1.7.0: Oslo Policy library

This release is part of the newton release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.policy 1.5.0..1.7.0
---

93aee73 Updated from global requirements
9536d53 Imported Translations from Zanata
cc9f17d Imported Translations from Zanata
fa3a368 Updated from global requirements
e0db341 Updated from global requirements
ea1268b Deprecate load_json() in favor of load()
83d209e Support policy file in YAML

Diffstat (except docs and test files)
-

.../locale/ar/LC_MESSAGES/oslo_policy-log-error.po | 24 +++
.../locale/cs/LC_MESSAGES/oslo_policy-log-error.po | 23 +++
oslo_policy/locale/cs/LC_MESSAGES/oslo_policy.po   | 38 +
.../locale/de/LC_MESSAGES/oslo_policy-log-error.po | 23 +++
oslo_policy/locale/de/LC_MESSAGES/oslo_policy.po   | 42 +++
.../en_AU/LC_MESSAGES/oslo_policy-log-error.po | 23 +++
.../en_GB/LC_MESSAGES/oslo_policy-log-error.po | 23 +++
.../locale/es/LC_MESSAGES/oslo_policy-log-error.po | 23 +++
oslo_policy/locale/es/LC_MESSAGES/oslo_policy.po   | 40 ++
.../locale/fr/LC_MESSAGES/oslo_policy-log-error.po | 23 +++
oslo_policy/locale/fr/LC_MESSAGES/oslo_policy.po   | 42 +++
.../locale/it/LC_MESSAGES/oslo_policy-log-error.po | 23 +++
oslo_policy/locale/it/LC_MESSAGES/oslo_policy.po   | 40 ++
.../locale/ja/LC_MESSAGES/oslo_policy-log-error.po | 23 +++
oslo_policy/locale/ja/LC_MESSAGES/oslo_policy.po   | 39 ++
.../ko_KR/LC_MESSAGES/oslo_policy-log-error.po | 23 +++
.../locale/ko_KR/LC_MESSAGES/oslo_policy.po| 38 +
oslo_policy/locale/oslo_policy-log-error.pot   | 30 ++
oslo_policy/locale/oslo_policy.pot | 47 ++
.../locale/pt/LC_MESSAGES/oslo_policy-log-error.po | 23 +++
.../pt_BR/LC_MESSAGES/oslo_policy-log-error.po | 23 +++
.../locale/pt_BR/LC_MESSAGES/oslo_policy.po| 39 ++
oslo_policy/locale/ru/LC_MESSAGES/oslo_policy.po   | 41 +++
.../tr_TR/LC_MESSAGES/oslo_policy-log-error.po | 23 +++
.../locale/tr_TR/LC_MESSAGES/oslo_policy.po| 36 +
.../vi_VN/LC_MESSAGES/oslo_policy-log-error.po | 23 +++
.../zh_CN/LC_MESSAGES/oslo_policy-log-error.po | 23 +++
.../locale/zh_CN/LC_MESSAGES/oslo_policy.po| 36 +
.../zh_TW/LC_MESSAGES/oslo_policy-log-error.po | 23 +++
.../locale/zh_TW/LC_MESSAGES/oslo_policy.po| 36 +
oslo_policy/policy.py  | 39 +++---
oslo_policy/shell.py   |  2 +-
requirements.txt   |  3 +-
35 files changed, 991 insertions(+), 14 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index e8793fa..8e217a1 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@ requests!=2.9.0,>=2.8.1 # Apache-2.0
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.9.0 # Apache-2.0
@@ -9,0 +10 @@ oslo.utils>=3.5.0 # Apache-2.0
+PyYAML>=3.1.0 # MIT



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

[no-reply]

We are thrilled to announce the release of:

oslo.middleware 3.9.0: Oslo Middleware library

This release is part of the newton release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.middleware 3.7.0..3.9.0
---

d5974a0 Imported Translations from Zanata
fe0bd54 Updated from global requirements
830149d Remove direct dependency on babel
179fd83 Updated from global requirements
8103c88 Updated from global requirements
c0264c4 Updated from global requirements
3f14482 Updated from global requirements
3988776 cors: prevent WebOb setting a default Content-Type
6a897ab CORS Middleware now honors upstream Vary header
f62c3a7 Disable http_proxy_to_wsgi middleware by default
cce21ca CORS tests now use a transient configuration
41bf7d9 Updated config documentation for cors_middleware
b23c46e Updated from global requirements
a1980b9 Updated from global requirements
67bf9d2 Revert "work around doc build error"
332c7f9 Clean up removed hacking rule from [flake8] ignore lists

Diffstat (except docs and test files)
-

.gitignore |   1 -
oslo_middleware/cors.py|  16 +-
oslo_middleware/http_proxy_to_wsgi.py  |  16 ++
.../de/LC_MESSAGES/oslo_middleware-log-error.po|   8 +-
.../locale/de/LC_MESSAGES/oslo_middleware.po   |   8 +-
.../en_GB/LC_MESSAGES/oslo_middleware-log-error.po |   8 +-
.../locale/en_GB/LC_MESSAGES/oslo_middleware.po|   8 +-
.../fr/LC_MESSAGES/oslo_middleware-log-error.po|   8 +-
.../locale/fr/LC_MESSAGES/oslo_middleware.po   |   8 +-
.../locale/oslo_middleware-log-error.pot   |  12 +-
.../locale/oslo_middleware-log-warning.pot |  33 ---
oslo_middleware/locale/oslo_middleware.pot |  12 +-
requirements.txt   |   9 +-
test-requirements.txt  |   2 +-
tox.ini|   3 +-
20 files changed, 277 insertions(+), 226 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 0745a66..f03122f 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +5,0 @@ pbr>=1.6 # Apache-2.0
-Babel>=1.3 # BSD
@@ -8,2 +7,2 @@ Jinja2>=2.8 # BSD License (3 clause)
-oslo.config>=3.4.0 # Apache-2.0
-oslo.context>=0.2.0 # Apache-2.0
+oslo.config>=3.9.0 # Apache-2.0
+oslo.context>=2.2.0 # Apache-2.0
@@ -11 +10 @@ oslo.i18n>=2.1.0 # Apache-2.0
-oslo.utils>=3.4.0 # Apache-2.0
+oslo.utils>=3.5.0 # Apache-2.0
@@ -13 +12 @@ six>=1.9.0 # MIT
-stevedore>=1.5.0 # Apache-2.0
+stevedore>=1.9.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 692402b..fc60e42 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -5 +5 @@
-fixtures>=1.3.1 # Apache-2.0/BSD
+fixtures<2.0,>=1.3.1 # Apache-2.0/BSD



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

[no-reply]

We are jubilant to announce the release of:

oslo.privsep 1.6.0: OpenStack library for privilege separation

This release is part of the newton release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.privsep 1.5.0..1.6.0


05ba634 Imported Translations from Zanata
54e2d2f Remove direct dependency on babel
0e5d1c9 Updated from global requirements

Diffstat (except docs and test files)
-

.../de/LC_MESSAGES/oslo_privsep-log-warning.po |  8 ++--
oslo_privsep/locale/de/LC_MESSAGES/oslo_privsep.po | 11 ++---
oslo_privsep/locale/oslo_privsep-log-error.pot | 34 ---
oslo_privsep/locale/oslo_privsep-log-info.pot  | 50 --
oslo_privsep/locale/oslo_privsep-log-warning.pot   | 14 +++---
oslo_privsep/locale/oslo_privsep.pot   | 26 +--
requirements.txt   |  1 -
7 files changed, 26 insertions(+), 118 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 4d4dd9a..11e30ae 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5 +4,0 @@
-Babel>=1.3 # BSD



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

[no-reply]

We are delighted to announce the release of:

oslo.rootwrap 4.2.0: Oslo Rootwrap

This release is part of the newton release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.rootwrap 4.1.0..4.2.0
-

cba9437 Updated from global requirements

Diffstat (except docs and test files)
-

test-requirements.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index 2de1043..14b8a6c 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -8 +8 @@ discover # BSD
-fixtures>=1.3.1 # Apache-2.0/BSD
+fixtures<2.0,>=1.3.1 # Apache-2.0/BSD



__
OpenStack Development Mailing 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][oslo] oslotest 2.5.0 release (newton)

[no-reply]

We are satisfied to announce the release of:

oslotest 2.5.0: Oslo test framework

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/oslotest

With package available at:

https://pypi.python.org/pypi/oslotest

Please report issues through launchpad:

http://bugs.launchpad.net/oslotest

For more details, please see below.

Changes in oslotest 2.3.0..2.5.0


9581cd0 Remove mockpatch re-implementations
90a1004 Updated from global requirements
4097ae5 Updated from global requirements
4150952 Updated from global requirements

Diffstat (except docs and test files)
-

oslotest/mockpatch.py | 74 +--
requirements.txt  |  2 +-
test-requirements.txt |  2 +-
4 files changed, 19 insertions(+), 114 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 216eaef..c52c09f 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5 +5 @@
-fixtures>=1.3.1 # Apache-2.0/BSD
+fixtures<2.0,>=1.3.1 # Apache-2.0/BSD
diff --git a/test-requirements.txt b/test-requirements.txt
index e06a946..bd87ecf 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -15 +15 @@ oslosphinx!=3.4.0,>=2.5.0 # Apache-2.0
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.9.0 # Apache-2.0



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

[no-reply]

We are glad to announce the release of:

oslo.utils 3.9.0: Oslo Utility library

This release is part of the newton release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.utils 3.7.0..3.9.0
--

3ac0253 Imported Translations from Zanata
a99969e Provide single step check if eventlet is monkey_patched
f082a5b Add method is_valid_cidr to netutils
2bb9015 Updated from global requirements
dfeebd0 Updated from global requirements
9e28e81 Add importutils.import_any method
081669b Add excutils.exception_filter
7e45bcc Explicitly exclude tests from bandit scan
811fb7f Add CHAPPASSWORD to list of sanitize keys
04e34e7 Enable bandit in gate
585bb02 Updated from global requirements

Diffstat (except docs and test files)
-

oslo_utils/eventletutils.py|  11 +
oslo_utils/excutils.py |  67 ++
oslo_utils/importutils.py  |  18 ++
oslo_utils/locale/de/LC_MESSAGES/oslo_utils.po |   8 +-
oslo_utils/locale/en_GB/LC_MESSAGES/oslo_utils.po  |  12 +-
.../locale/es/LC_MESSAGES/oslo_utils-log-error.po  |  23 ++
oslo_utils/locale/fr/LC_MESSAGES/oslo_utils.po |  17 +-
oslo_utils/locale/oslo_utils.pot   |  35 ++-
.../pt_BR/LC_MESSAGES/oslo_utils-log-error.po  |  23 ++
oslo_utils/netutils.py |  26 +++
oslo_utils/strutils.py |   6 +-
test-requirements.txt  |   4 +-
tox.ini|  10 +-
17 files changed, 515 insertions(+), 22 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index a758083..b702e0f 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -8 +8 @@ discover # BSD
-fixtures>=1.3.1 # Apache-2.0/BSD
+fixtures<2.0,>=1.3.1 # Apache-2.0/BSD
@@ -28 +28 @@ mock>=1.2 # BSD
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.9.0 # Apache-2.0



__
OpenStack Development Mailing 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][oslo] stevedore 1.13.0 release (newton)

[no-reply]

We are delighted to announce the release of:

stevedore 1.13.0: Manage dynamic plugins for Python applications

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/stevedore

With package available at:

https://pypi.python.org/pypi/stevedore

Please report issues through launchpad:

https://bugs.launchpad.net/python-stevedore

For more details, please see below.

Changes in stevedore 1.12.0..1.13.0
---

52dfe21 dont claim copyright for future years

Diffstat (except docs and test files)
-

1 file changed, 1 insertion(+), 1 deletion(-)




__
OpenStack Development Mailing 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] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[John McDowall]

Ryan,

Thanks - let me try and get the code cleaned up and rebased. One area that I 
could use your insight on is the interface to networking-ovn and how it should 
look.

Regards

John

From: Ryan Moats mailto:rmo...@us.ibm.com>>
Date: Sunday, May 8, 2016 at 8:32 PM
To: John McDowall 
mailto:jmcdow...@paloaltonetworks.com>>
Cc: "disc...@openvswitch.org" 
mailto:disc...@openvswitch.org>>, OpenStack 
Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall 
mailto:jmcdow...@paloaltonetworks.com>> wrote 
on 05/08/2016 07:34:52 PM:

> From: John McDowall 
> mailto:jmcdow...@paloaltonetworks.com>>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: "disc...@openvswitch.org" 
> mailto:disc...@openvswitch.org>>
> Date: 05/08/2016 07:35 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Correcting ovs address
>
> Ryan,
>
> Thanks for taking a look at these  - really appreciate it. I will
> work on the rebasing this week and get everything current. At the
> same time I can get rid of some excess code as I went through a few
> iterations to get to this point. There are still a lot of
> unaddressed edge conditions and details that need to be thought
> through and addressed - but once we reach consensus on the approach
> we can start to address them.
>
> Thinking though the various repos in reverse order.
>
> OVS
> ===
>
> I would like to change the code to follow the model that Russell
> Bryant did in his patches see:  
> https://github.com/russellb/ovs/
> commits/chaining
>
> They have several advantages:
> 1. Creates a new table for chaining which should help isolate the
> code and make chaining more "atomic"
> 2. He follows the port-pair/port-chain model of SFC so integration
> should be cleaner
> 3. Following the port-pair/port-chain model makes extending the
> solution to handle a chain of VNFs fairly easy.
> If everyone is good with this I can work this into the patches and rebase.

You are anticipating where I was looking to go, so I'm on board with
this idea.

> Networking-OVN
> ===
>
> There is some old code here in plugin.py that I think comes out.
> When I added OVN as a SFC Driver there was a lot of code that I
> added to  networking-ovn that became obsolete. The IDL code would be
> modified to follow the port-pair/port-chain. model.  The biggest
> question I have from your comments is the interface between the
> networking-sfc and networking-ovn. I think I agree with you that
> networking-ovn should expose an interface that is called by
> networking-sfc and that would remove the need to subclass OVNPlugin
> in the networking-sfc OVN driver. Is that what you were intending?

Yes, I was looking at how that subclass could be avoided.

> Networking-SFC
> ==
>
> If we follow Russell's model in OVN/OVS then there very close
> alignment with the SFC model and the code will become simpler. Also
> removing the OVNPlugin dependency will also clean things up.

Yes, I was hoping that would be a side effect as well...

I like all of your proposed ideas and am looking forward to seeing
the next iteration. Please feel free to reach out if you need
another pair of hands to help with coding...

Ryan Moats
__
OpenStack Development Mailing 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][oslo] oslo.reports 1.8.0 release (newton)

[no-reply]

We are eager to announce the release of:

oslo.reports 1.8.0: oslo.reports library

This release is part of the newton release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.reports 1.6.0..1.8.0


aaf9364 Remove direct dependency on babel
66fa3a9 Updated from global requirements
e85901e Updated from global requirements
da70fe7 Updated from global requirements

Diffstat (except docs and test files)
-

requirements.txt  | 1 -
test-requirements.txt | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index ae8992b..7d88640 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +6,0 @@ Jinja2>=2.8 # BSD License (3 clause)
-Babel>=1.3 # BSD
diff --git a/test-requirements.txt b/test-requirements.txt
index 39842cd..f1d52e8 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -13 +13 @@ sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.9.0 # Apache-2.0



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

[no-reply]

We are pumped to announce the release of:

oslo.serialization 2.5.0: Oslo Serialization library

This release is part of the newton release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.serialization 2.4.0..2.5.0
--

8985675 Drop babel as requirement since its not used
82758da Updated from global requirements
7ac405c Unified and simplified API for all serializers
056d701 Make msgpack registries copyable (and add __contains__)
da1475a msgpack: fix datetime serialization

Diffstat (except docs and test files)
-

oslo_serialization/msgpackutils.py | 204 
oslo_serialization/serializer/__init__.py  |   0
oslo_serialization/serializer/base_serializer.py   |  58 ++
oslo_serialization/serializer/json_serializer.py   |  38 
.../serializer/msgpack_serializer.py   |  36 
requirements.txt   |   1 -
7 files changed, 510 insertions(+), 38 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 359c249..4460946 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -11 +10,0 @@ pbr>=1.6 # Apache-2.0
-Babel>=1.3 # BSD



__
OpenStack Development Mailing 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][oslo] tooz 1.35.0 release (newton)

[no-reply]

We are eager to announce the release of:

tooz 1.35.0: Coordination library for distributed systems.

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/tooz

With package available at:

https://pypi.python.org/pypi/tooz

Please report issues through launchpad:

http://bugs.launchpad.net/python-tooz/

For more details, please see below.

Changes in tooz 1.34.0..1.35.0
--

82afcb5 Drop babel as requirement since its not used
340dc4c Updated from global requirements
512f58c Updated from global requirements
7f72cba Updated from global requirements
685e669 Updated from global requirements

Diffstat (except docs and test files)
-

requirements.txt  | 3 +--
test-requirements.txt | 4 ++--
2 files changed, 3 insertions(+), 4 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 135781e..dd65da7 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5,2 +5 @@ pbr>=1.6 # Apache-2.0
-Babel>=1.3 # BSD
-stevedore>=1.5.0 # Apache-2.0
+stevedore>=1.9.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index e82c1bb..665f71c 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -8 +8 @@ pyflakes==0.8.1 # MIT
-flake8<2.6.0,>2.4.1 # MIT
+flake8<2.6.0,>=2.5.4 # MIT
@@ -18 +18 @@ coverage>=3.6 # Apache-2.0
-fixtures>=1.3.1 # Apache-2.0/BSD
+fixtures<2.0,>=1.3.1 # Apache-2.0/BSD



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

[no-reply]

We are happy to announce the release of:

oslo.vmware 2.6.0: Oslo VMware library

This release is part of the newton release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.vmware 2.5.0..2.6.0
---

54fe092 Updated from global requirements
1a53380 Imported Translations from Zanata
c29d84b Updated from global requirements
251797b Updated from global requirements
8ec8c09 Should not raise Exception before connection close
90ca364 Remove explicit use of asserts
fa93ed4 Move bandit into pep8

Diffstat (except docs and test files)
-

.../locale/fr/LC_MESSAGES/oslo_vmware-log-error.po |  8 +--
.../locale/fr/LC_MESSAGES/oslo_vmware-log-info.po  |  8 +--
.../fr/LC_MESSAGES/oslo_vmware-log-warning.po  |  8 +--
oslo_vmware/locale/fr/LC_MESSAGES/oslo_vmware.po   |  8 +--
oslo_vmware/locale/oslo_vmware-log-error.pot   | 26 -
oslo_vmware/locale/oslo_vmware-log-info.pot| 18 +++---
oslo_vmware/locale/oslo_vmware-log-warning.pot | 22 +++
oslo_vmware/locale/oslo_vmware.pot | 68 +++---
oslo_vmware/objects/datastore.py   |  3 +-
oslo_vmware/rw_handles.py  |  3 +-
requirements.txt   |  2 +-
test-requirements.txt  |  4 +-
tox.ini|  7 ++-
15 files changed, 116 insertions(+), 101 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 11ace7c..cdae27e 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -7 +7 @@ pbr>=1.6 # Apache-2.0
-stevedore>=1.5.0 # Apache-2.0
+stevedore>=1.9.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 42010da..5508978 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -9 +9 @@ discover # BSD
-fixtures>=1.3.1 # Apache-2.0/BSD
+fixtures<2.0,>=1.3.1 # Apache-2.0/BSD
@@ -26 +26 @@ sphinx!=1.2.0,!=1.3b1,<1.3,>=1.1.2 # BSD
-bandit>=0.17.3 # Apache-2.0
+bandit>=1.0.1 # Apache-2.0



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

[no-reply]

We are pleased to announce the release of:

oslo.service 1.9.0: oslo.service library

This release is part of the newton release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.service 1.7.0..1.9.0


96ccba8 Updated from global requirements
c8499ee Remove direct dependency on babel
aa969d3 Updated from global requirements
a0e4a06 Updated from global requirements
9a2e792 Updated from global requirements
2996051 Updated from global requirements
63c62f2 Fix argument type for _sd_notify() on python3
9604fc9 Use a timeutils.StopWatch for cancel timing
c2e6478 Add ability to cancel Threads and ThreadGroups
9b82953 Exception: message need '_' function
6a56ec6 Fix Heartbeats stop when time is changed
58af2f3 Updated from global requirements

Diffstat (except docs and test files)
-

oslo_service/__init__.py   | 41 
oslo_service/eventlet_backdoor.py  |  8 ++--
oslo_service/loopingcall.py|  6 +--
oslo_service/service.py|  6 +--
oslo_service/systemd.py|  6 +--
oslo_service/threadgroup.py| 34 -
requirements.txt   |  7 ++--
test-requirements.txt  |  4 +-
11 files changed, 192 insertions(+), 22 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 9dfef9c..3b56e53 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5 +4,0 @@
-Babel>=1.3 # BSD
@@ -12 +11 @@ oslo.concurrency>=3.5.0 # Apache-2.0
-oslo.config>=3.4.0 # Apache-2.0
+oslo.config>=3.9.0 # Apache-2.0
@@ -17,2 +16,2 @@ PasteDeploy>=1.5.0 # MIT
-Routes!=2.0,!=2.1,>=1.12.3;python_version=='2.7' # MIT
-Routes!=2.0,>=1.12.3;python_version!='2.7' # MIT
+Routes!=2.0,!=2.1,!=2.3.0,>=1.12.3;python_version=='2.7' # MIT
+Routes!=2.0,!=2.3.0,>=1.12.3;python_version!='2.7' # MIT
diff --git a/test-requirements.txt b/test-requirements.txt
index 353ac9b..23d23c7 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -5 +5 @@
-fixtures>=1.3.1 # Apache-2.0/BSD
+fixtures<2.0,>=1.3.1 # Apache-2.0/BSD
@@ -18 +18 @@ coverage>=3.6 # Apache-2.0
-bandit>=0.17.3 # Apache-2.0
+bandit>=1.0.1 # Apache-2.0



__
OpenStack Development Mailing 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] [tc] supporting Go

[Pete Zaitcev]

On Mon, 9 May 2016 09:06:02 -0400
Rayson Ho  wrote:

> Since the Go toolchain is pretty self-contained, most people just follow
> the official instructions to get it installed... by a one-step:
> 
> # tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz

I'm pretty certain the humanity has moved on from this sort of thing.
Nowadays "most people" use packaged language runtimes that come with
the Linux they're running.

-- Pete

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

[no-reply]

We are delighted to announce the release of:

oslo.messaging 5.0.0: Oslo Messaging API

This release is part of the newton release series.

With source available at:

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

With package available at:

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

Please report issues through launchpad:

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

For more details, please see below.

Changes in oslo.messaging 4.5.0..5.0.0
--

51f3b7b Updated from global requirements
a98fa8f Fixes sumulator.py signal_handler logic
4df633d Improves exception handling and logging
4275044 Implements pika thread safe connection
5708d75 Fix incorrect parameters order in assertIn call
41dd8e3 Update the RPC cast() documentation.
c903a8b Fix unstable work of cast func tests
192eeb4 [zmq] Reduce threading from python proxy
fbe6e12 Imported Translations from Zanata
5b94b4b use thread safe fnmatch
6db00c7 Refactor base interfaces
a46237f Gracefully handle missing TCP_USER_TIMEOUT
439d8ca Simulator: handle SIGINT and SIGTERM signals
159762b Updated from global requirements
62b2206 Log the unique_id in listener than msg_id
404bebc serializer: deprecate RequestContextSerializer
dfcdec3 Amqp driver send method temporary work-around
d297ad6 Updated from global requirements
a705e0b Updated from global requirements
09d5669 Allow simulator to be launched from arbitrary directory
cbd6672 [zmq] Fix cast message loss in simulator
cbaf71e Make transport_url config option secret
8afa73b Fix oslo.messaging for Mac OS X
5d7d725 Refactor driver's listener interface
9a065e3 [kafka] Do not remove kafka_client during reset
d630b64 Updated from global requirements
fbc5df6 Replace expriration_time by timer
cc1cb30 [zmq] Reduce number of connections
990d894 Move server related logic from dispatchers
3728ccc Fix typos in Oslo.messaging files
b60af23 Fix Break in Windows platforms
f8969e9 [py34] replace file() with open()
5e0bda3 Claim python3 compatability for Newton onwards
6957173 Simulator: collect error stats
e2e59a5 Simulator: make parameter wait_after_msg float
cb7bbae Update CheckForLoggingIssues hacking rule from keystone
38b907a Support python3 in simulator.py
2fb5ad9 Fix typo passend should be passenv
98bc5fc Always set all socket timeouts
dad52c1 Add a py34 functional test for rabbit
50b5468 Small fixes
bec4ef4 Use only unique topics for the Kafka driver
1385df6 [zmq] Refactoring consumer side
d3fedf8 [Kafka] Ensure a topics before consume messages
0aca222 Fix problems during unstable network
89bc0e6 Missing version parameter in can_send_version()
b6a8d51 Bump rabbit_transient_queues_ttl to 30 mins
0f58e23 Explicitly exclude tests from bandit scan
fb73297 Fix Notification listener blocking behavior
f2f2d07 Pika: fix sending fanout messages
bb4121a Revert "Ensure the json result type is bytes on Python 3"
6d2d1b2 Replace deprecated LOG.warn with LOG.warning
5588279 Simulator: store results in JSON format
84109fe Simulator: calculate message latency statistics
f42d886 Fix the driver shutdown/failover logic
0774b5c Always delete exc_info tuple, even if reply fails
33f1a3b Do not leak Listeners on failover
37c0db5 Simulator: always use random messages for time-bound tests
4e4caf6 Fallback if git is absent
97385ef Simulator: implement own random generator instead of scipy
d2496c3 Simulator: fix batch-notify-server command
0de6bd6 Work with kombu from upstream
97655c1 Fail quickly if there on bad password
76ab2c4 [zmq] Dynamic port range is ignored
c721265 [zmq] Implement Response and Envelope classes
71450fa [kafka] Use notification priority
681f631 Make simulator more asynchronous
89cc47e Adds exhange declaration on sender's side
a95035c Updated from global requirements
bd81d09 Ensure the json result type is bytes on Python 3
8dfc064 test: Don't test message's reply timeout

Diffstat (except docs and test files)
-

oslo_messaging/_cmd/zmq_broker.py  |  42 --
oslo_messaging/_cmd/zmq_proxy.py   |  76 +++
oslo_messaging/_drivers/amqpdriver.py  |  29 +-
oslo_messaging/_drivers/base.py| 161 +-
oslo_messaging/_drivers/impl_fake.py   |  13 +-
oslo_messaging/_drivers/impl_kafka.py  |  32 +-
oslo_messaging/_drivers/impl_pika.py   | 174 --
oslo_messaging/_drivers/impl_rabbit.py |  79 ++-
oslo_messaging/_drivers/impl_zmq.py|  29 +-
.../_drivers/pika_driver/pika_commons.py   |  47 ++
.../_drivers/pika_driver/pika_connection.py| 497 
oslo_messaging/_drivers/pika_driver/pika_engine.py | 272 +
.../_drivers/pika_driver/pika_listener.py  |  72 +--
.../_drivers/pika_driver/pika_message.py   |  98 ++--
oslo_messaging/_drivers/pika_driver/pika_poller.py | 415 --
.../_drivers/protocols/amqp/controller.py  | 233 +---
oslo_messaging/_drivers/protoco

Re: [openstack-dev] [api] API-WG summit session recap

[Everett Toews]

> On May 9, 2016, at 10:12 AM, michael mccune  wrote:
> 
> Promoting the guidelines
> 
> 
> The heart of the API-WG has always been the guidelines that are produced, we 
> had a nice discussion about how we can increase the awareness and usage of 
> the guidelines.
> 
> One big request that came out of this discussion is the need to cleanup the 
> group's guideline page to make it clearer which pages are just place holders 
> and which contain guidelines.
> 
> The group talked about if, and how, we can better integrate with other 
> working groups to help create a broader network for the guidelines and better 
> APIs in general. The two main groups that were identified as possible 
> partners are the Application Ecosystem WG and the SDK WG. Although these 
> groups have different focuses than just APIs, there is certainly some room 
> for collaboration and consensus among all the groups.
> 
> There was also a strong discussion about how the group could advocate for 
> more projects to use the guidelines. The main result of this talk was the 
> idea of an API-WG related governance tag. Having this tag would make a nice 
> signal to end-users about the maturity and development status of a project's 
> APIs. Although the details are still in flux, the main criteria of a tag were 
> related to projects self-electing into the tag, and then creating a series of 
> tests that would prove how their APIs follow the guidelines, as well as 
> providing proper API documentation. This is still very much a work in 
> progress.

We've started an issue to track this at Guideline compliance doc [1]. We'd be 
interested to get feedback on the issue before forging ahead with the doc.

Thanks,
Everett

[1] https://bugs.launchpad.net/openstack-api-wg/+bug/1578728


__
OpenStack Development Mailing 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][oslo] taskflow 1.31.0 release (newton)

[no-reply]

We are chuffed to announce the release of:

taskflow 1.31.0: Taskflow structured state management library.

This release is part of the newton release series.

With source available at:

http://git.openstack.org/cgit/openstack/taskflow

With package available at:

https://pypi.python.org/pypi/taskflow

Please report issues through launchpad:

http://bugs.launchpad.net/taskflow/

For more details, please see below.

Changes in taskflow 1.30.0..1.31.0
--

e83a564 Updated from global requirements
7bcf508 Don't set html_last_updated_fmt without git
2869278 Updated from global requirements
720ee37 Fix export_to_dot for networkx package changes
89e023b Ensure upgrade for sqlalchemy is protected by a lock
a2d4731 Fallback if git is absent
ec26bbf Refactor Atom/BaseTask/Task/Retry class hierarchy

Diffstat (except docs and test files)
-

requirements.txt |   2 +-
taskflow/atom.py |  84 ++-
taskflow/engines/action_engine/compiler.py   |   2 +-
taskflow/engines/worker_based/worker.py  |   2 +-
taskflow/listeners/logging.py|   2 +-
taskflow/persistence/backends/impl_sqlalchemy.py |  30 +++---
taskflow/retry.py|  11 +-
taskflow/storage.py  |   2 +-
taskflow/task.py | 126 ---
taskflow/types/graph.py  |   3 +-
test-requirements.txt|   2 +-
12 files changed, 134 insertions(+), 141 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 8a7d201..f7190e5 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -29 +29 @@ contextlib2>=0.4.0 # PSF License
-stevedore>=1.5.0 # Apache-2.0
+stevedore>=1.9.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 10eeba7..2a2497e 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -26 +26 @@ SQLAlchemy<1.1.0,>=1.0.10 # MIT
-alembic>=0.8.0 # MIT
+alembic>=0.8.4 # MIT



__
OpenStack Development Mailing 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][mistral] Saga of process than ack and where can we go from here...

[Joshua Harlow]

Dmitry Tantsur wrote:

On 05/07/2016 01:00 AM, Joshua Harlow wrote:

Dmitry Tantsur wrote:

On 05/03/2016 11:24 PM, Joshua Harlow wrote:

Howdy folks,

So I meet up with *some* of the mistral folks during friday last
week at
the summit and I was wondering if we as a group can find a path to help
that project move forward in their desire to have some kind of process
than ack (vs the existing ack then process) in there usage of the
messaging layer.

I got to learn that the following exists in mistral (sad-face):

https://github.com/openstack/mistral/blob/master/mistral/engine/rpc.py#L38




And it got me thinking about how/if we can as a group possibly allow a
variant of https://review.openstack.org/#/c/229186/ to get worked on
and
merged in and release so that the above 'hack' can be removed.


Hey, lemme weigh in from ironic-inspector PoV.

As you maybe remember, we also need a queue with possibility of both
ways of ack'ing for our HA work. So something like this patch doesn't
seem to help us at all. We'll probably have to cargo-cult the mistral
approach.


U seem to be thinking about the queue as an implementation vs thinking
about what API do u really need and then say backing that API by a queue
(if u so want to).

Thus where https://review.openstack.org/#/c/260246/ comes into play here
because it thinks about the API first and the impl second (and if u
really want 2 impls, well they are at
https://github.com/openstack/taskflow/tree/master/taskflow/jobs/backends
but I'm avoiding trying to bring those into the picture, because the
top-level API seems unclear here still).

I guess it goes back to the 'why are people trying to use a message
queue as a work queue' when the semantics of these are different (and
let's not get into why we use a message queue as an RPC layer while we
are at it, ha).


And I have a trivial answer: because that's all we have working right
now ;)


Ya, that's what I expected :-/

I wonder how we can think about/work towards the longer/better path 
instead of the short term (it works sorta right now)... It reminds me of 
this saying, 'when all u have is a hammer, everything looks like a nail',


https://en.wiktionary.org/wiki/if_all_you_have_is_a_hammer,_everything_looks_like_a_nail 
(for those who have no idea what this means) ;)








Is it possible to have a manual ack feature? I.e. for the handler to
choose when to ack.



I also would like to come to some kind of understanding that we also
(mistral folks would hopefully help here) would remove this kind of
change in the future as the longer term goal (of something like
https://review.openstack.org/#/c/260246/) would progress.

Thoughts from folks (mistral and oslo)?

Anyway we can create a solution that works in the short term (allowing
for that hack to be removed) and working toward the longer term goal?

-Josh

__



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



__


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


__

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



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


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

[openstack-dev] config options: current state (R-21)

[Markus Zoeller]

We're close to have all options moved to "nova/conf/". At the bottom
is a list of the remaining options and their open reviews.

The documentation of the options in "nova/conf/" is done for ~ 150
options. Which means ~ 450 are missing. This means there are still
around 80 changes necessary to complete the work. The deadline for this
work is June 30th [1]. Please note that this is 2 weeks shorter than
usual due to the huge backlog of nova work items. 

If you have moved config options, please ensure that a follow up patch
which improves the config option help texts is ready for review.
This is the most important part of this effort.

For questions, ping me in #openstack-nova

References
[1] http://releases.openstack.org/newton/schedule.html

Regards, Markus Zoeller (markus_z)

Appendix:
=

 nova [1]https://review.openstack.org/314091
--- api [3]  https://review.openstack.org/#/c/309192/ et al.
-- metadata [4]see above ^^^
-- openstack [6]   see above ^^^
- compute [2]  see above ^^^ 
 legacy_v2 [2] see above ^^^ 
--- contrib [6]see above ^^^
--- cmd [2]  TODO markus_z
--- compute [1]  https://review.openstack.org/314123
--- db [4]   https://review.openstack.org/#/c/263804/
-- sqlalchemy [13]   https://review.openstack.org/#/c/263804/
--- image [7]https://review.openstack.org/314146
-- download [2]  TODO markus_z
--- network [2]  https://review.openstack.org/#/c/274210/
--- servicegroup [1] https://review.openstack.org/#/c/303074
-- libvirt [0]
- volume [11]https://review.openstack.org/#/c/309342/5 et al.
-- xenapi [3]https://review.openstack.org/#/c/302446/


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

[openstack-dev] [kolla] OpenPower support

[Franck Barillaud]

all, 

We have a Mitaka/Kolla control plane deployed on x86 in our lab with an 
OpenPower (Habanero system from Tyan) compute node attached to it and it 
works like a charm :-). 
Under SoftLayer we also have a Mitaka/Kolla control plane deployed on x86 
and we are trying to attach a Power8 system to it. The 
'neutron-openvswitah-agent' starts successfully but trying to start 
'nova-compute' leads to the following error:

2016-05-09 07:00:37.516 107958 ERROR oslo_service.service ServiceTooOld: 
This service is older (v9) than the minimum (v10) version of the rest of 
the deployment. Unable to continue.

All the oslo packages are exactly at the same level on the controller and 
on the compute node. Any idea where this error is coming from ?

Regards,
Franck Barillaud
Cloud Architect
Master Inventor
Ext Phone: (512) 286-5242Tie Line: 363-5242
e-mail: fbari...@us.ibm.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] [kolla] OpenPower support

[Davanum Srinivas]

Franck,

It's coming from Nova:
http://codesearch.openstack.org/?q=ServiceTooOld&i=nope&files=&repos=nova

Check the nova configuration files for a rpc version mismatch

-- Dims

On Mon, May 9, 2016 at 12:17 PM, Franck Barillaud  wrote:
> all,
>
> We have a Mitaka/Kolla control plane deployed on x86 in our lab with an
> OpenPower (Habanero system from Tyan) compute node attached to it and it
> works like a charm :-).
> Under SoftLayer we also have a Mitaka/Kolla control plane deployed on x86
> and we are trying to attach a Power8 system to it. The
> 'neutron-openvswitah-agent' starts successfully but trying to start
> 'nova-compute' leads to the following error:
>
> 2016-05-09 07:00:37.516 107958 ERROR oslo_service.service ServiceTooOld:
> This service is older (v9) than the minimum (v10) version of the rest of the
> deployment. Unable to continue.
>
> All the oslo packages are exactly at the same level on the controller and on
> the compute node. Any idea where this error is coming from ?
>
> Regards,
> Franck Barillaud
> Cloud Architect
> Master Inventor
> Ext Phone: (512) 286-5242Tie Line: 363-5242
> e-mail: fbari...@us.ibm.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
>



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

Re: [openstack-dev] [heat]Provides different stack quota to tenant

[Sylvernass Arthas]

Excerpts from Sylvernass Arthas's message of 2016-05-08 05:33:13 -0700:

> Hi, guys

>

>   Now, all tenant share the public config "max_stacks_per_tenant" which 
> decides maximum number of stacks any one tenant may have active at one time, 
> the default value is 1000.

> Should heat provides ability to set this config by different tenant? For 
> example, in a enterprise, maybe tenant A needs 1 stack quota, tenant B 
> needs 100 stack quota, but now heat can't manage with it, at least in 
> Liberity.

>   So in future, will heat provides this ability or other policy to solve this?



I think enough people have stated that they want it that it will happen some 
day. There may even be a spec now, I haven't been tracking all of the specs. 
However, I don't actually think there's any point to Heat quotas, as the 
resources used to run a Heat stack are so much cheaper compared to the 
resources it enables the user to consume -- servers, networks, volumes, etc. 
One might as well let users run as many heat stacks as they want within reason, 
as their quotas on those items will fill up far before they cost you any actual 
money.



In fact, the only reason the max setting exists now is to protect the code that 
does stack listing from eating up all of the memory on the servers.

It has a second unintended use case which is to prevent anyone from using Heat 
as free object storage. :)



It's important to take my words with a grain of salt. I'm not directly involved 
with Heat anymore.

__
OpenStack Development Mailing 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][CI] Elastic recheck bugs

[Sagi Shnaidman]

Hi, all

I'd like to enable elastic recheck on TripleO CI and have submitted patches
for refreshing the tracked logs [1] (please review) and for timeout case
[2].
But according to Derek's comment behind the timeout issue could be multiple
issues and bugs, so I'd like to clarify - what are criteria for elastic
recheck bugs?

I thought about those markers:

Nova:
1) "No valid host was found. There are not enough hosts"
Network issues:
2) "Failed to connect to trunk.rdoproject.org" OR "fatal: The remote end
hung up unexpectedly"  OR "Could not resolve host:"
Ironic:
3) "Error contacting Ironic server:"
4) "Introspection completed with errors:"
5) ": Introspection timeout"
6) "Timed out waiting for node "
Glance:
7) "500 Internal Server Error: Failed to upload image"
crm_resource:
8) "crm_resource for openstack "

and various puppet errors.

However almost all of these messages could have different root causes,
except of network failures. Easy to fix bug doesn't make to submit there,
because they will be fixed yet before recheck patch will be merged.
So, could you please think about right criteria of bugs for elastic recheck?

Thanks

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

Re: [openstack-dev] [kolla] CentOS binary and source gate failed due to the rabbitmq

[Hui Kang]

The ubuntu gate deploy failed too; that is awkward.

http://logs.openstack.org/05/314205/1/check/gate-kolla-dsvm-deploy-ubuntu-source/766ee43/console.html#_2016-05-09_16_58_39_411

- Hui

On Mon, May 9, 2016 at 1:48 AM, Jeffrey Zhang  wrote:
> I deploy the Kolla by using centos+source on centos host always.
> Never see such kinda of issue. So i can not re-produce this
> locally, now.
>
> On Mon, May 9, 2016 at 8:31 AM, Hui Kang  wrote:
>>
>> Hi, Jeffrey,
>> I tried deploying centos binary and source on my ubuntu host, which
>> completed successfully. Looking at the VMs on the failed gate, they
>> are centos VMs.
>>
>> I think we need to debug this problem locally by deploying centos
>> kolla on centos hosts. Is my understanding correct? Thanks.
>>
>> - Hui
>>
>> On Sat, May 7, 2016 at 9:54 AM, Jeffrey Zhang 
>> wrote:
>> > Recently, the centos binary and source gate failed due to the rabbitmq
>> > container
>> > existed. After making some debug. I do not found the root cause.
>> >
>> > does anyone has any idea for this?
>> >
>> > see this PS gate result[0]
>> > centos binary gate failed[1]
>> > CentOS source gate failed[2]
>> >
>> > [0] https://review.openstack.org/313838
>> > [1]
>> >
>> > http://logs.openstack.org/38/313838/1/check/gate-kolla-dsvm-deploy-centos-binary/ea293fe/
>> > [2]
>> >
>> > http://logs.openstack.org/38/313838/1/check/gate-kolla-dsvm-deploy-centos-source/d4cb127/
>> >
>> > --
>> > Regards,
>> > Jeffrey Zhang
>> > Blog: http://xcodest.me
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Neutron] Diagnostics & troubleshooting design summit summary and next steps

[Boden Russell]

Assaf, thanks for driving this session.

As a newbie to the design sessions, I think presenting a brief "context"
up-front is helpful. IMO the key word here is "brief" (5 min or less for
example) and furthermore should not open the floor for digression given
the short time-frame we have per session. Some of us will be experts on
the topic, others of us will not have had time to do the proper research
before heading into the session. This "intro" gets us all on the same page,
or closer to it.

Finally, it might be nice to collaborate on the intro content with the main
players of the session topic. Not saying the intro needs to be reviewed,
but typically it seems there are a few individuals with vested
interest / knowledge in the space and it would be nice if they could work
together on developing the content.


On 5/6/16 2:38 PM, Assaf Muller wrote:
> It is my personal experience that unless I do my homework, design
> summit discussions largely go over my head. I'd guess that most people
> don't have time to research the topic of every design session they
> intend to go to, so for the session I lead I decided to do the
> unthinkable and present the context of the discussion [1] with a few
> slides [2] (That part of the session took I think 3 minutes). I'd love
> to get feedback particularly on that, if people found it useful we may
> consider increasing adoption of that habit for the Barcelona design
> summit.
>
> The goal for the session was to achieve consensus on the very high
> level topics: Do we want to do Neutron diagnostics in-tree and via the
> API. I believe that goal was achieved, and the answer to both
> questions is 'yes'.
>
> Since there's been at least 4 RFEs submitted in this domain, the next
> step is to try and converge on one and iterate on an API. For these
> purposes we will be using Hynek's spec, under review here [3]. I was
> approached by multiple people that are interested in assisting with
> the implementation phase, please say so on the spec so that Hynek will
> be able to add you as a contributor.
>
> I foresee a few contention points, chief of which is the abstraction
> level of the API and how best to present diagnostics information in a
> way that is plugin agnostic. The trick will be to find an API that is
> not specific to the reference implementation while still providing a
> great user experience to the vast majority of OpenStack users.
>
> A couple of projects in the domain were mentioned, specifically
> Monasca and Steth. Contributors from these projects are highly
> encouraged to review the spec.
>
> [1] https://etherpad.openstack.org/p/newton-neutron-troubleshooting
> [2] 
> https://docs.google.com/presentation/d/1IBVZ6defUwhql4PEmnhy3fl9qWEQVy4iv_IR6pzkFKw/edit?usp=sharing
> [3] https://review.openstack.org/#/c/308973/
>
> __
> OpenStack Development Mailing 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] [Neutron] Team meeting this Tuesday at 1400 UTC

[Armando M.]

Hi neutrinos,

Just a reminder that from this week, we'll resume the usual schedule for
the weekly team meeting.

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

Re: [openstack-dev] [kolla] Gate precheck job failed due to minimum kernel version on ubuntu 14.04

[Paul Belanger]

On Sun, May 08, 2016 at 09:55:58AM -0500, Monty Taylor wrote:
> On 05/08/2016 03:45 AM, Steve Kowalik wrote:
> >On 08/05/16 08:11, lương hữu tuấn wrote:
> >>Hi,
> >>
> >>@Robert: I was successful to update the kernel without change the image.
> >
> >But that was Robert's point entirely. Installing the kernel will work
> >fine, but it does not get you running that kernel -- also like Robert
> >said, you need to change the image to run a different kernel than what
> >it has installed.
> >
> 
> We will be changing our images this cycle to Xenial from Trusty. I do not
> believe we have any intention of installing backported wily kernels in our
> trusty images, as what we want to test on them is Trusty.
> 
> However, the Xenial transition should be happening soon enough - so things
> that need a newer kernel this release can happily just require Xenial images
> for testing.
> 
> I think the question of why/how kolla grew a dependency on a newer kernel
> than what trusty has is worth checking. As of right now, trusty kernels are
> the newest thing supported in the gate.
> 
++

I'd like to bake in our current DIBs as long as possible before we consider
changing kernels.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [kolla] Gate precheck job failed due to minimum kernel version on ubuntu 14.04

[Steven Dake (stdake)]

Paul,

There is no request from the Kolla community to churn the images.  I don't
see that as adding any value.  We can just document the reality of the
situation, which is only BTRFS works well as a graph driver with 14.04.

Regards
-steve

On 5/9/16, 10:48 AM, "Paul Belanger"  wrote:

>On Sun, May 08, 2016 at 09:55:58AM -0500, Monty Taylor wrote:
>> On 05/08/2016 03:45 AM, Steve Kowalik wrote:
>> >On 08/05/16 08:11, lương hữu tuấn wrote:
>> >>Hi,
>> >>
>> >>@Robert: I was successful to update the kernel without change the
>>image.
>> >
>> >But that was Robert's point entirely. Installing the kernel will work
>> >fine, but it does not get you running that kernel -- also like Robert
>> >said, you need to change the image to run a different kernel than what
>> >it has installed.
>> >
>> 
>> We will be changing our images this cycle to Xenial from Trusty. I do
>>not
>> believe we have any intention of installing backported wily kernels in
>>our
>> trusty images, as what we want to test on them is Trusty.
>> 
>> However, the Xenial transition should be happening soon enough - so
>>things
>> that need a newer kernel this release can happily just require Xenial
>>images
>> for testing.
>> 
>> I think the question of why/how kolla grew a dependency on a newer
>>kernel
>> than what trusty has is worth checking. As of right now, trusty kernels
>>are
>> the newest thing supported in the gate.
>> 
>++
>
>I'd like to bake in our current DIBs as long as possible before we
>consider
>changing kernels.
>> 
>>_
>>_
>> OpenStack Development Mailing 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] [tc] supporting Go

[Fox, Kevin M]

I think you'll find that being able to embed a higher performance language 
inside python will be much easier to do for optimizing a function or two rather 
then deal with having a separate server have to be created, authentication be 
added between the two, and marshalling/unmarshalling the data to and from it to 
optimize one little piece. Last I heard, you couldn't just embed go in python. 
C/C++ is pretty easy to do. Maybe I'm wrong and its possible to embed go now. 
Someone, please chime in if you know of a good way.

Thanks,
Kevin

From: Hayes, Graham [graham.ha...@hpe.com]
Sent: Monday, May 09, 2016 4:33 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] supporting Go

On 08/05/2016 10:21, Thomas Goirand wrote:
> On 05/04/2016 01:29 AM, Hayes, Graham wrote:
>> On 03/05/2016 17:03, John Dickinson wrote:
>>> TC,
>>>
>>> In reference to 
>>> http://lists.openstack.org/pipermail/openstack-dev/2016-May/093680.html and 
>>> Thierry's reply, I'm currently drafting a TC resolution to update 
>>> http://governance.openstack.org/resolutions/20150901-programming-languages.html
>>>  to include Go as a supported language in OpenStack projects.
>>>
>>> As a starting point, what would you like to see addressed in the document 
>>> I'm drafting?
>>>
>>> --John
>>>
>>>
>>>
>>
>> Great - I was about to write a thread like this :)
>>
>> Designate is looking to move a single component of ours to Go - and we
>> were wondering what was the best way to do it.

> We discussed about this during the summit. You told me that the issue
> was a piece of code that needed optimization, to which I replied that
> probably, a C++ .so extension in a Python module is probably what you
> are looking for (with the advice of not using CFFI which is sometimes
> breaking things in distros).
>
> Did you think about this other possibility, and did you discuss it with
> your team?

We had a brief discussion about it, and we going to try a new POC in
C/C++ to validate it, but then this thread (and related TC policy) were
proposed.

If Golang is going to be a supported language, we would much rather
stick with one of the official OpenStack languages that suits our
use case instead of getting an exemption for another similar language.

When we spoke at the summit, I was under the impression that the feature
branch in swift was not going to be merged to master, and we would have
to get an exemption from the TC anyway - which we could have used to get
C / C++.

The team also much preferred the idea of Golang - we do not have much
C++ expertise in the Designate dev team, which would slow down the
development cycle for us.

-- Graham

> At the Linux distribution level, the main issue that there is with Go,
> is that it (still) doesn't support the concept of shared library. We see
> this as a bug, rather than a feature. As a consequence, when a library
> upgrades, the release team has to trigger rebuilds for each and every
> reverse dependencies. As the number of Go stuff increases over time, it
> becomes less and less manageable this way (and it may potentially be a
> security patching disaster in Stable). I've heard that upstream for
> Golang was working on implementing shared libs, but I have no idea what
> the status is. Does anyone know?
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

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

Re: [openstack-dev] [kolla] [bifrost] bifrost container.

[Mooney, Sean K]

Hi

If we choose to use bifrost to deploy ironic standalone I think combining 
kevins previous
suggestion of modifying the bifrost install playbook with Steve Dake's 
suggestion of creating a series
of supervisord configs for running each of the service is a reasonable approch.

I am currently look to scope how much effort would be required to split  the 
main task in the bifrost-ironic-install role
https://github.com/openstack/bifrost/blob/master/playbooks/roles/bifrost-ironic-install/tasks/main.yml
into 3 files which would be included in the main.yml:
Install_componets.yml (executed when skip_install is not defiend)
Bootstrap_components.yml (executed when skip_bootstrap is not defiend)
Start_components.yml  (executed when skip_start is not defiend)
By default all three would be executed maintain the current behavior of bifrost 
today,.

During the kolla build of the biforst image the 
https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml would 
be in
run with skip_bootstrap and skip_start defined as true so only 
Install_componets.yml will be executed by the main task.
This would install all software components of bifrost/ironic without preforming 
configuration or starting the services.

At deployment time during the bootstrap phase we would spawn an instance of the 
biforst-base container and invoke
https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml with 
skip_install and skip_start defined executing Bootstrap_components.yml

Bootstrap_components.yml would encapsulate all logic related to creating the 
ironic db(running migration scripts) and generating the configuration
Files for the biforst components.

Finally in the start phase we have 3 options

a)  Spawn an instance of the bifrost-supervisor container and use 
supervisord to run the bifrost/ironic services (fat container)

b)  Spawn an instance of the bifrost-base container and Invoke 
https://github.com/openstack/bifrost/blob/master/playbooks/install.yaml with
skip_install and skip_bootstrap and allow biforst to star the services.(fat 
container)

c)   Spawn a series of containers each running a single service sharing the 
required volumes to allow them  to communicate (app containers)


I would welcome any input for the bifrost community on this especially related 
to the decomposition of the main.yml into 3 phases.
Im hoping to do a quick poc this week to see how easy it is to do this 
decomposition.

I would also like to call out upfront that depending on the scope of this item 
I may have to withdraw from contributing to it.
I work in intel's network platforms group so enabling baremetal installation is 
somewhat outside the standard
Work our division undertakes.  If we can reuse bifrost to do most of the heavy 
lifting of creating the bifrost container and deploying ironic then
The scope of creating the bifrost container is small enough that I can justify 
spending some of my time working on it. if it requires
Significant changes to bifrost or rework of kolla's ironic support then I will 
have to step back and focus more on feature that are closer aligned to
Our teams core networking and orchestration focus such as enhancing kolla to be 
able to deploy ovs with dpdk  and/or opendaylight which are
Also items I would like to contribute to this cycle. I don't want to commit to 
delivering this feature unless I know I will have the time to work on
It but am happy to help where I can.

@kevin some replies to your questions inline.

Regards
Sean.


From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: Friday, May 6, 2016 9:17 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [kolla] [bifrost] bifrost container.

I was under the impression bifrost was 2 things, one, an installer/configurator 
of ironic in a stand alone mode, and two, a management tool for getting 
machines deployed without needing nova using ironic.
[Mooney, Sean K] yes this is correct, bifrost does provide both install 
playbooks for deploying ironic in standalone mode and a series of playbooks for 
dynamically enrolling node in ironic and dynamically deploy imanges to host
Without requiring nova. Bifrost also provides intergration with Disk image 
builder to generate machine images if desired.


The first use case seems like it should just be handled by enhancing kolla's 
ironic container stuff to directly to handle the use case, doing things the 
kolla way. This seems much cleaner to me. Doing it at runtime looses most of 
the benefits of doing it in a container at all.
[Mooney, Sean K] I was not suggestiong doing the installation at runtime. 
Option 2 and 3   suggested spawning a container as part of the build in which 
the install playbook would be run.
That container would then be stopped and exported to form the base image for 
the bifrost continer(s). The base image (bifrost-postinstall)  would either be 
use to create  a fat containter using an init system such as supervisor

Re: [openstack-dev] [tc] supporting Go

[Hayes, Graham]

On 09/05/2016 19:09, Fox, Kevin M wrote:
> I think you'll find that being able to embed a higher performance language 
> inside python will be much easier to do for optimizing a function or two 
> rather then deal with having a separate server have to be created, 
> authentication be added between the two, and marshalling/unmarshalling the 
> data to and from it to optimize one little piece. Last I heard, you couldn't 
> just embed go in python. C/C++ is pretty easy to do. Maybe I'm wrong and its 
> possible to embed go now. Someone, please chime in if you know of a good way.
>
> Thanks,
> Kevin

We won't be replacing any particular function, we will be replacing a
whole service.

There is no auth (or inter-service communications) from this component,
all it does it query the DB and spit out DNS packets.

I can't talk for what swift are doing, but we have a very targeted scope
for our Go work.

- Graham

> 
> From: Hayes, Graham [graham.ha...@hpe.com]
> Sent: Monday, May 09, 2016 4:33 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tc] supporting Go
>
> On 08/05/2016 10:21, Thomas Goirand wrote:
>> On 05/04/2016 01:29 AM, Hayes, Graham wrote:
>>> On 03/05/2016 17:03, John Dickinson wrote:
 TC,

 In reference to 
 http://lists.openstack.org/pipermail/openstack-dev/2016-May/093680.html 
 and Thierry's reply, I'm currently drafting a TC resolution to update 
 http://governance.openstack.org/resolutions/20150901-programming-languages.html
  to include Go as a supported language in OpenStack projects.

 As a starting point, what would you like to see addressed in the document 
 I'm drafting?

 --John



>>>
>>> Great - I was about to write a thread like this :)
>>>
>>> Designate is looking to move a single component of ours to Go - and we
>>> were wondering what was the best way to do it.
>
>> We discussed about this during the summit. You told me that the issue
>> was a piece of code that needed optimization, to which I replied that
>> probably, a C++ .so extension in a Python module is probably what you
>> are looking for (with the advice of not using CFFI which is sometimes
>> breaking things in distros).
>>
>> Did you think about this other possibility, and did you discuss it with
>> your team?
>
> We had a brief discussion about it, and we going to try a new POC in
> C/C++ to validate it, but then this thread (and related TC policy) were
> proposed.
>
> If Golang is going to be a supported language, we would much rather
> stick with one of the official OpenStack languages that suits our
> use case instead of getting an exemption for another similar language.
>
> When we spoke at the summit, I was under the impression that the feature
> branch in swift was not going to be merged to master, and we would have
> to get an exemption from the TC anyway - which we could have used to get
> C / C++.
>
> The team also much preferred the idea of Golang - we do not have much
> C++ expertise in the Designate dev team, which would slow down the
> development cycle for us.
>
> -- Graham
>
>> At the Linux distribution level, the main issue that there is with Go,
>> is that it (still) doesn't support the concept of shared library. We see
>> this as a bug, rather than a feature. As a consequence, when a library
>> upgrades, the release team has to trigger rebuilds for each and every
>> reverse dependencies. As the number of Go stuff increases over time, it
>> becomes less and less manageable this way (and it may potentially be a
>> security patching disaster in Stable). I've heard that upstream for
>> Golang was working on implementing shared libs, but I have no idea what
>> the status is. Does anyone know?
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

Re: [openstack-dev] [tc] supporting Go

[Clint Byrum]

Excerpts from Pete Zaitcev's message of 2016-05-09 08:52:16 -0700:
> On Mon, 9 May 2016 09:06:02 -0400
> Rayson Ho  wrote:
> 
> > Since the Go toolchain is pretty self-contained, most people just follow
> > the official instructions to get it installed... by a one-step:
> > 
> > # tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz
> 
> I'm pretty certain the humanity has moved on from this sort of thing.
> Nowadays "most people" use packaged language runtimes that come with
> the Linux they're running.
> 

Perhaps for mature languages. But go is still finding its way, and that
usually involves rapid changes that are needed faster than the multi-year
cycle Linux distributions offer.

Also worth noting, is that go is not a "language runtime" but a compiler
(that happens to statically link in a runtime to the binaries it
produces...).

The point here though, is that the versions of Python that OpenStack
has traditionally supported have been directly tied to what the Linux
distributions carry in their repositories (case in point, Python 2.6
was dropped from most things as soon as RHEL7 was available with Python
2.7). With Go, there might need to be similar restrictions.

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

Re: [openstack-dev] [TripleO][CI] Elastic recheck bugs

[Sagi Shnaidman]

Sorry, missed the mentioned patches:

[1] Refresh log files for tripleo project:
https://review.openstack.org/#/c/312985/
[2] Add bug for TripleO timeouts: https://review.openstack.org/#/c/313038/

On Mon, May 9, 2016 at 8:22 PM, Sagi Shnaidman  wrote:

> Hi, all
>
> I'd like to enable elastic recheck on TripleO CI and have submitted
> patches for refreshing the tracked logs [1] (please review) and for timeout
> case [2].
> But according to Derek's comment behind the timeout issue could be
> multiple issues and bugs, so I'd like to clarify - what are criteria for
> elastic recheck bugs?
>
> I thought about those markers:
>
> Nova:
> 1) "No valid host was found. There are not enough hosts"
> Network issues:
> 2) "Failed to connect to trunk.rdoproject.org" OR "fatal: The remote end
> hung up unexpectedly"  OR "Could not resolve host:"
> Ironic:
> 3) "Error contacting Ironic server:"
> 4) "Introspection completed with errors:"
> 5) ": Introspection timeout"
> 6) "Timed out waiting for node "
> Glance:
> 7) "500 Internal Server Error: Failed to upload image"
> crm_resource:
> 8) "crm_resource for openstack "
>
> and various puppet errors.
>
> However almost all of these messages could have different root causes,
> except of network failures. Easy to fix bug doesn't make to submit there,
> because they will be fixed yet before recheck patch will be merged.
> So, could you please think about right criteria of bugs for elastic
> recheck?
>
> Thanks
>
> --
> Best regards
> Sagi Shnaidman
>



-- 
Best regards
Sagi Shnaidman
__
OpenStack Development Mailing 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] [designate] multi-tenancy in Neutron's DNS integration

[Mike Spreitzer]

I just read 
http://docs.openstack.org/mitaka/networking-guide/adv-config-dns.html and, 
unless I missed something, it seems to be describing something that is not 
multi-tenant.  I am focused on FQDNs for Neutron Ports.  For those, only 
the "hostname" part (the first label, in official DNS jargon) is 
controllable by the Neutron user, the rest of the FQDN is fixed in Neutron 
configuration.  Have I got that right?  If so then I am surprised.  I 
would have expected something that isolates tenants (projects) from one 
another.  Is there any interest in such a thing?

Thanks,
Mike

__
OpenStack Development Mailing 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] [tc] supporting Go

[John Dickinson]

On 9 May 2016, at 11:14, Hayes, Graham wrote:

> On 09/05/2016 19:09, Fox, Kevin M wrote:
>> I think you'll find that being able to embed a higher performance language 
>> inside python will be much easier to do for optimizing a function or two 
>> rather then deal with having a separate server have to be created, 
>> authentication be added between the two, and marshalling/unmarshalling the 
>> data to and from it to optimize one little piece. Last I heard, you couldn't 
>> just embed go in python. C/C++ is pretty easy to do. Maybe I'm wrong and its 
>> possible to embed go now. Someone, please chime in if you know of a good way.
>>
>> Thanks,
>> Kevin
>
> We won't be replacing any particular function, we will be replacing a
> whole service.
>
> There is no auth (or inter-service communications) from this component,
> all it does it query the DB and spit out DNS packets.
>
> I can't talk for what swift are doing, but we have a very targeted scope
> for our Go work.
>
> - Graham

This is exactly the direction Swift is exploring--replacing a part of the whole 
that is already it's own daemon and/or network service.

--John




>
>> 
>> From: Hayes, Graham [graham.ha...@hpe.com]
>> Sent: Monday, May 09, 2016 4:33 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [tc] supporting Go
>>
>> On 08/05/2016 10:21, Thomas Goirand wrote:
>>> On 05/04/2016 01:29 AM, Hayes, Graham wrote:
 On 03/05/2016 17:03, John Dickinson wrote:
> TC,
>
> In reference to 
> http://lists.openstack.org/pipermail/openstack-dev/2016-May/093680.html 
> and Thierry's reply, I'm currently drafting a TC resolution to update 
> http://governance.openstack.org/resolutions/20150901-programming-languages.html
>  to include Go as a supported language in OpenStack projects.
>
> As a starting point, what would you like to see addressed in the document 
> I'm drafting?
>
> --John
>
>
>

 Great - I was about to write a thread like this :)

 Designate is looking to move a single component of ours to Go - and we
 were wondering what was the best way to do it.
>>
>>> We discussed about this during the summit. You told me that the issue
>>> was a piece of code that needed optimization, to which I replied that
>>> probably, a C++ .so extension in a Python module is probably what you
>>> are looking for (with the advice of not using CFFI which is sometimes
>>> breaking things in distros).
>>>
>>> Did you think about this other possibility, and did you discuss it with
>>> your team?
>>
>> We had a brief discussion about it, and we going to try a new POC in
>> C/C++ to validate it, but then this thread (and related TC policy) were
>> proposed.
>>
>> If Golang is going to be a supported language, we would much rather
>> stick with one of the official OpenStack languages that suits our
>> use case instead of getting an exemption for another similar language.
>>
>> When we spoke at the summit, I was under the impression that the feature
>> branch in swift was not going to be merged to master, and we would have
>> to get an exemption from the TC anyway - which we could have used to get
>> C / C++.
>>
>> The team also much preferred the idea of Golang - we do not have much
>> C++ expertise in the Designate dev team, which would slow down the
>> development cycle for us.
>>
>> -- Graham
>>
>>> At the Linux distribution level, the main issue that there is with Go,
>>> is that it (still) doesn't support the concept of shared library. We see
>>> this as a bug, rather than a feature. As a consequence, when a library
>>> upgrades, the release team has to trigger rebuilds for each and every
>>> reverse dependencies. As the number of Go stuff increases over time, it
>>> becomes less and less manageable this way (and it may potentially be a
>>> security patching disaster in Stable). I've heard that upstream for
>>> Golang was working on implementing shared libs, but I have no idea what
>>> the status is. Does anyone know?
>>>
>>> Cheers,
>>>
>>> Thomas Goirand (zigo)
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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.openst

Re: [openstack-dev] [tc] supporting Go

[Tim Simmons]

> The point here though, is that the versions of Python that OpenStack
> has traditionally supported have been directly tied to what the Linux
> distributions carry in their repositories (case in point, Python 2.6
> was dropped from most things as soon as RHEL7 was available with Python
> 2.7). With Go, there might need to be similar restrictions.

I'm not sure about this, backwards compatibility in Go (at least in the last 
year) has been good
for me.

But because like you say, you get a statically-linked binary, you don't need to
worry about some version of anything the distro is packaging because your binary
will run anywhere.

If you're looking to compile the code from scratch, it's intentionally simple 
to install the
compiler, and there isn't any reason that you couldn't install multiple 
versions simply.

>> I think you'll find that being able to embed a higher performance language 
>> inside python will be much
>> easier to do for optimizing a function or two rather then deal with having a 
>> separate server have to be created,
>> authentication be added between the two, and marshalling/unmarshalling the 
>> data to and from it to optimize one little piece.
>> Last I heard, you couldn't just embed go in python. C/C++ is pretty easy to 
>> do. 
>> Maybe I'm wrong and its possible to embed go now. Someone, please chime in 
>> if you know of a good way.

There isn't a good way to embed Go (as far as I know), but I'd argue that for a 
relatively isolated use case (like Graham described
of ours), it's better to just do the thing in Go than coerce C into Python. 
It'd introduce less risk and complexity than using Cython, imho.
But I guess if you know C and not Go, that could be arguable.

Tim Simmons

From: Clint Byrum 
Sent: Monday, May 9, 2016 1:15 PM
To: openstack-dev
Subject: Re: [openstack-dev] [tc] supporting Go

Excerpts from Pete Zaitcev's message of 2016-05-09 08:52:16 -0700:
> On Mon, 9 May 2016 09:06:02 -0400
> Rayson Ho  wrote:
>
> > Since the Go toolchain is pretty self-contained, most people just follow
> > the official instructions to get it installed... by a one-step:
> >
> > # tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz
>
> I'm pretty certain the humanity has moved on from this sort of thing.
> Nowadays "most people" use packaged language runtimes that come with
> the Linux they're running.
>

Perhaps for mature languages. But go is still finding its way, and that
usually involves rapid changes that are needed faster than the multi-year
cycle Linux distributions offer.

Also worth noting, is that go is not a "language runtime" but a compiler
(that happens to statically link in a runtime to the binaries it
produces...).

The point here though, is that the versions of Python that OpenStack
has traditionally supported have been directly tied to what the Linux
distributions carry in their repositories (case in point, Python 2.6
was dropped from most things as soon as RHEL7 was available with Python
2.7). With Go, there might need to be similar restrictions.

__
OpenStack Development Mailing 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] [ironic] API docs now publishing from our tree

[Devananda van der Veen]

Works for me. The api-ref stuff is much easier to maintain, review, and the
resulting docs are infinitely more usable for developers.

I'm already working on getting api-ref up to date; the current docs there
are sorely out of date and wrong. I'd like to land these patches quickly
and iterate on improving them, rather than stall any improvements until
this is perfect.

https://review.openstack.org/312795
https://review.openstack.org/313187
https://review.openstack.org/313708

You can view the results from the build in the new api-ref job, eg. here:
http://docs-draft.openstack.org/08/313708/1/check/gate-ironic-api-ref/5c28efa//api-ref/build/html/

--Deva


On Thu, May 5, 2016 at 6:18 AM Jim Rollenhagen 
wrote:

> On Wed, May 04, 2016 at 05:22:05PM -0400, Ruby Loo wrote:
> > Sweet. Thanks Jim (and everyone else that made this happen).
> >
> > I do want to make sure there is one "source of truth" to the API
> > documentation. We are already generating REST API documentation at
> > http://docs.openstack.org/developer/ironic/webapi/v1.html. The info for
> > this comes from docstrings etc in our code files.
> >
> > To make it easier and so that documentation doesn't get out of sync, I
> > don't really want people to have to remember to update the
> code/docstrings
> > as well as the new files that were added to generate this new api-ref
> > documentation.
>
> I agree. I think the first thing we need to do is get the api-ref tree
> up to date. After that, we can refactor the stuff in doc/source/webapi
> to be pointers to the new thing, and drop the API docs from the
> docstrings.
>
> Does that work for everyone?
>
> // jim
>
> > --ruby
> >
> >
> > On Wed, May 4, 2016 at 5:10 PM, Jim Rollenhagen 
> > wrote:
> >
> > > Hey y'all,
> > >
> > > I did the push this week to move the api-ref into our tree, and it's
> now
> > > publishing. \o/
> > >
> > > The docs are here: http://developer.openstack.org/api-ref/baremetal/
> > >
> > > The source is here:
> > > http://git.openstack.org/cgit/openstack/ironic/tree/api-ref/source
> > >
> > > I know devananda is doing a push to update some things there. If you'd
> > > like to help clean up and improve our docs, please sync with him. They
> > > need a lot of love, so all help is welcome. :)
> > >
> > > // 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
> > >
>
> >
> __
> > OpenStack Development Mailing 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] [tc] supporting Go

[Fox, Kevin M]

Ah. ok. Yeah, using Go for that use case wouldn't be too bad then.

Thanks,
Kevin

From: Hayes, Graham [graham.ha...@hpe.com]
Sent: Monday, May 09, 2016 11:14 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] supporting Go

On 09/05/2016 19:09, Fox, Kevin M wrote:
> I think you'll find that being able to embed a higher performance language 
> inside python will be much easier to do for optimizing a function or two 
> rather then deal with having a separate server have to be created, 
> authentication be added between the two, and marshalling/unmarshalling the 
> data to and from it to optimize one little piece. Last I heard, you couldn't 
> just embed go in python. C/C++ is pretty easy to do. Maybe I'm wrong and its 
> possible to embed go now. Someone, please chime in if you know of a good way.
>
> Thanks,
> Kevin

We won't be replacing any particular function, we will be replacing a
whole service.

There is no auth (or inter-service communications) from this component,
all it does it query the DB and spit out DNS packets.

I can't talk for what swift are doing, but we have a very targeted scope
for our Go work.

- Graham

> 
> From: Hayes, Graham [graham.ha...@hpe.com]
> Sent: Monday, May 09, 2016 4:33 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [tc] supporting Go
>
> On 08/05/2016 10:21, Thomas Goirand wrote:
>> On 05/04/2016 01:29 AM, Hayes, Graham wrote:
>>> On 03/05/2016 17:03, John Dickinson wrote:
 TC,

 In reference to 
 http://lists.openstack.org/pipermail/openstack-dev/2016-May/093680.html 
 and Thierry's reply, I'm currently drafting a TC resolution to update 
 http://governance.openstack.org/resolutions/20150901-programming-languages.html
  to include Go as a supported language in OpenStack projects.

 As a starting point, what would you like to see addressed in the document 
 I'm drafting?

 --John



>>>
>>> Great - I was about to write a thread like this :)
>>>
>>> Designate is looking to move a single component of ours to Go - and we
>>> were wondering what was the best way to do it.
>
>> We discussed about this during the summit. You told me that the issue
>> was a piece of code that needed optimization, to which I replied that
>> probably, a C++ .so extension in a Python module is probably what you
>> are looking for (with the advice of not using CFFI which is sometimes
>> breaking things in distros).
>>
>> Did you think about this other possibility, and did you discuss it with
>> your team?
>
> We had a brief discussion about it, and we going to try a new POC in
> C/C++ to validate it, but then this thread (and related TC policy) were
> proposed.
>
> If Golang is going to be a supported language, we would much rather
> stick with one of the official OpenStack languages that suits our
> use case instead of getting an exemption for another similar language.
>
> When we spoke at the summit, I was under the impression that the feature
> branch in swift was not going to be merged to master, and we would have
> to get an exemption from the TC anyway - which we could have used to get
> C / C++.
>
> The team also much preferred the idea of Golang - we do not have much
> C++ expertise in the Designate dev team, which would slow down the
> development cycle for us.
>
> -- Graham
>
>> At the Linux distribution level, the main issue that there is with Go,
>> is that it (still) doesn't support the concept of shared library. We see
>> this as a bug, rather than a feature. As a consequence, when a library
>> upgrades, the release team has to trigger rebuilds for each and every
>> reverse dependencies. As the number of Go stuff increases over time, it
>> becomes less and less manageable this way (and it may potentially be a
>> security patching disaster in Stable). I've heard that upstream for
>> Golang was working on implementing shared libs, but I have no idea what
>> the status is. Does anyone know?
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
>>
>> __
>> OpenStack Development Mailing 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

Re: [openstack-dev] [tc] supporting Go

[Monty Taylor]

On 05/09/2016 01:15 PM, Clint Byrum wrote:
> Excerpts from Pete Zaitcev's message of 2016-05-09 08:52:16 -0700:
>> On Mon, 9 May 2016 09:06:02 -0400
>> Rayson Ho  wrote:
>>
>>> Since the Go toolchain is pretty self-contained, most people just follow
>>> the official instructions to get it installed... by a one-step:
>>>
>>> # tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz
>>
>> I'm pretty certain the humanity has moved on from this sort of thing.
>> Nowadays "most people" use packaged language runtimes that come with
>> the Linux they're running.
>>
> 
> Perhaps for mature languages. But go is still finding its way, and that
> usually involves rapid changes that are needed faster than the multi-year
> cycle Linux distributions offer.
> 
> Also worth noting, is that go is not a "language runtime" but a compiler
> (that happens to statically link in a runtime to the binaries it
> produces...).
> 
> The point here though, is that the versions of Python that OpenStack
> has traditionally supported have been directly tied to what the Linux
> distributions carry in their repositories (case in point, Python 2.6
> was dropped from most things as soon as RHEL7 was available with Python
> 2.7). With Go, there might need to be similar restrictions.

Since this is a forward-facing thing, I think starting with the version
that's in xenial is probably fine for today, yeah? That will be the
version of go that will get installed in the gate starting with this cycle.


__
OpenStack Development Mailing 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] [tc] supporting Go

[Ben Swartzlander]

On 05/09/2016 02:15 PM, Clint Byrum wrote:

Excerpts from Pete Zaitcev's message of 2016-05-09 08:52:16 -0700:

On Mon, 9 May 2016 09:06:02 -0400
Rayson Ho  wrote:


Since the Go toolchain is pretty self-contained, most people just follow
the official instructions to get it installed... by a one-step:

# tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz


I'm pretty certain the humanity has moved on from this sort of thing.
Nowadays "most people" use packaged language runtimes that come with
the Linux they're running.



Perhaps for mature languages. But go is still finding its way, and that
usually involves rapid changes that are needed faster than the multi-year
cycle Linux distributions offer.


This statement right here would be the nail in the coffin of this idea 
if I were deciding. As a community we should not be building software 
based on unstable platforms and languages.


I have nothing against golang in particular but I strongly believe that 
mixing 2 languages within a project is always the wrong decision, and 
doubly so if one of those languages is a niche language. The reason is 
simple: it's hard enough to find programmers who are competent in one 
language -- finding programmers who know both languages well will be 
nearly impossible. You'll end up with core reviewers who can't review 
half of the code and developers who can only fix bugs in half the code.


If you want to write code in a language that's not Python, go start 
another project. Don't call it OpenStack. If it ends up being a better 
implementation than the reference OpenStack Swift implementation, it 
will win anyways and perhaps Swift will start to look more like the rest 
of the projects in OpenStack with a standardized API and multiple 
plugable implementations.


-Ben Swartzlander


Also worth noting, is that go is not a "language runtime" but a compiler
(that happens to statically link in a runtime to the binaries it
produces...).

The point here though, is that the versions of Python that OpenStack
has traditionally supported have been directly tied to what the Linux
distributions carry in their repositories (case in point, Python 2.6
was dropped from most things as soon as RHEL7 was available with Python
2.7). With Go, there might need to be similar restrictions.

__
OpenStack Development Mailing 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] [tc] supporting Go

[Hayes, Graham]

On 09/05/2016 19:39, Ben Swartzlander wrote:
> On 05/09/2016 02:15 PM, Clint Byrum wrote:
>> Excerpts from Pete Zaitcev's message of 2016-05-09 08:52:16 -0700:
>>> On Mon, 9 May 2016 09:06:02 -0400
>>> Rayson Ho  wrote:
>>>
 Since the Go toolchain is pretty self-contained, most people just follow
 the official instructions to get it installed... by a one-step:

 # tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz
>>>
>>> I'm pretty certain the humanity has moved on from this sort of thing.
>>> Nowadays "most people" use packaged language runtimes that come with
>>> the Linux they're running.
>>>
>>
>> Perhaps for mature languages. But go is still finding its way, and that
>> usually involves rapid changes that are needed faster than the multi-year
>> cycle Linux distributions offer.
>
> This statement right here would be the nail in the coffin of this idea
> if I were deciding. As a community we should not be building software
> based on unstable platforms and languages.
>
> I have nothing against golang in particular but I strongly believe that
> mixing 2 languages within a project is always the wrong decision, and
> doubly so if one of those languages is a niche language. The reason is
> simple: it's hard enough to find programmers who are competent in one
> language -- finding programmers who know both languages well will be
> nearly impossible. You'll end up with core reviewers who can't review
> half of the code and developers who can only fix bugs in half the code.
>
> If you want to write code in a language that's not Python, go start
> another project. Don't call it OpenStack. If it ends up being a better
> implementation than the reference OpenStack Swift implementation, it
> will win anyways and perhaps Swift will start to look more like the rest
> of the projects in OpenStack with a standardized API and multiple
> plugable implementations.
>

Sure - the Designate team could maintain 2 copies of our DNS server,
one in python as a reference, and one externally in Golang / C / C++ /
Rust / $language, which would in reality need to be used by anything
over a medium size deployment.

That seems less than ideal for our users though.

This is not a "Go seems cool - lets go try that" decision from us - we
know we have a performance problem with one of our components, and we
have come to the conclusion that Go (or something like it) is the
solution.

 From a deck about "the rise and fall of Bind 10" [0] -

   "Python is awesome, but too damn slow for DNS"

0 - 
https://ripe68.ripe.net/presentations/208-The_Decline_and_Fall_of_BIND_10.pdf

-- Graham

>
>> Also worth noting, is that go is not a "language runtime" but a compiler
>> (that happens to statically link in a runtime to the binaries it
>> produces...).
>>
>> The point here though, is that the versions of Python that OpenStack
>> has traditionally supported have been directly tied to what the Linux
>> distributions carry in their repositories (case in point, Python 2.6
>> was dropped from most things as soon as RHEL7 was available with Python
>> 2.7). With Go, there might need to be similar restrictions.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

Re: [openstack-dev] [neutron] [designate] multi-tenancy in Neutron's DNS integration

[Hayes, Graham]

On 09/05/2016 19:21, Mike Spreitzer wrote:
> I just read
> http://docs.openstack.org/mitaka/networking-guide/adv-config-dns.htmland, 
> unless
> I missed something, it seems to be describing something that is not
> multi-tenant.  I am focused on FQDNs for Neutron Ports.  For those, only
> the "hostname" part (the first label, in official DNS jargon) is
> controllable by the Neutron user, the rest of the FQDN is fixed in
> Neutron configuration.  Have I got that right?  If so then I am
> surprised.  I would have expected something that isolates tenants
> (projects) from one another.  Is there any interest in such a thing?
>
> Thanks,
> Mike

In the case where the network in question is shared, and the network is
set to publish all port FQDNs to Designate - yes the current
implementation has the zone name as shared.

If you have per-project networks the integration can be done on a
project by project basis, with floating IPs assigned the name from
the port and the zone from the private network.

I would be interested in seeing a multi-tenented implementation of
Use Case 1[0] from that page, if we can find developer time to do it.

0 - 
http://docs.openstack.org/mitaka/networking-guide/adv-config-dns.html#use-case-1-ports-are-published-directly-in-the-external-dns-service

-- Graham

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

[openstack-dev] [ironic] weekly sub team status report

[Loo, Ruby]

Hi,


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


Bugs (dtantsur)

===

- Stats (diff with 18 Apr 2016):

- Ironic: 190 bugs (-13) + 173 wishlist items (+7). 17 new (-13), 133 in 
progress (-1), 0 critical (-1), 26 high (+2) and 19 incomplete (+1)

- Inspector: 12 bugs (-1) + 17 wishlist items (+1). 1 new, 7 in progress (+1), 
0 critical, 4 high and 1 incomplete (+1)

- Nova bugs with Ironic tag: 15. 2 new (+2), 0 critical, 0 high

- monthly diff (with 04 Apr 2016)

- Ironic: 190 bugs (-6) + 173 wishlist items (+10), 133 in progress (-2)

- Inspector: 12 bugs (-2) + 17 wishlist items (+1), 7 in progress (0)


Upgrade (aka Grenade) testing (jlvillal/mgould):



- Conducted audio conference concerning Grenade work

- Etherpad for Grenade work: 
https://etherpad.openstack.org/p/ironic-newton-grenade-whiteboard

- https://github.com/JohnVillalovos/devstack-gate-test

- Progress is being made. Getting some patches added.

- lucasgomes has reported that he is getting farther along than before.

- Multiple people have reported running the grenade tests.

- Using tinyipa for the grenade test.

- jroll has posted a patch for 'tempest smoke' as we need to have 'tempest 
smoke' passing to have a real Grenade job.


Network isolation (Neutron/Ironic work) (jroll, TheJulia, devananda)



- should have upgrade testing before landing

- patches are ready for reviews

- should we lift -2 from the first patch or at least move it to the next 
patch? it's just API for portgroups.

- possibly, though it would be nice to land the api changes somewhat 
together

- [deva] Please, no. Landing a new API endpoint that has zero 
functionality and zero testing is misleading to users.


Gate improvements (jlvillal, lucasagomes, dtantsur)

===

- dtantsur figures out feature parity of tinyipa with inspection

- logs support is missing due to absent journald/syslog, we may want to 
work around by dumping IPA log in a file


Node search API (jroll, lintan, rloo)

=

- spec ready for reviews: https://review.openstack.org/#/c/306092/


Multiple compute hosts (jroll, devananda)

=

- had a good long chat with jaypipes about using generic-resource-pools work 
for this; looks promising


Generic boot-from-volume (TheJulia, dtantsur, lucasagomes)

==

- both specs had some comments to address the last time I've looked. see below 
about Julia's PTO.


Driver composition (dtantsur)

=

- the spec https://review.openstack.org/188370 lacks some details, but may use 
reviews anyway.


Cross-project:

==

- Nova Liaisons (jlvillal & mrda)

- Conducted bug scrub

- mrda had taken a TODO to review a Nova patch.

- Oslo (lintan)

- Doc (jroll, liliars)

- api-ref is now in our tree \o/

- lots of clean up in progress: https://review.openstack.org/312795 and 
following patches


Inspector (dtansur)

===

- ironic-inspector 2.2.6 released for Liberty

- the HA spec got merged: 
http://specs.openstack.org/openstack/ironic-inspector-specs/specs/HA_inspector.html

- releases for Mitaka and Newton will be made this week


Bifrost (TheJulia)

==

- Julia is Out on PTO for at least two weeks


.


Until next week,

--ruby


[0] https://etherpad.openstack.org/p/IronicWhiteBoard
__
OpenStack Development Mailing 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] Ansible inventory - Would you need another inventory system for your openstack cloud and how would you like it to be?

[Jesse Pretorius]

On 9 May 2016 at 15:27, Jean-Philippe Evrard 
wrote:

> I am using ansible for some time now, and I think the current default
> Ansible inventory system is lacking a few features, at least when working
> on an OpenStack cloud - whether it's for its deployment, its support or its
> usage.
> I'm thinking of developing a new inventory, based on (openstack-)ansible
> experience.
>
There were discussions at the summit around the implementation of an
inventory system to cater for many of the things you're outlining. I wasn't
party to them but as I recall there were both presentations and design
discussions and the effort is being led by a team of OSIC developers.

My view is that all of this most certainly does not belong in Ansible and
most of it does not belong in an Ansible dynamic inventory script either.
It should be handled somewhere else and Ansible should simply consume it.

> I think all the results from this etherpad could be either used for
> ansible upstream or for the openstack-ansible project, so that's why I'm
> spamming here. Thank for your help!
>
Specifically for OpenStack-Ansible we need something that's easily
implemented for small or dev/test environments, but ideally if a deployment
is using a complex production inventory system or a non-complex development
system the interactions should be the same. This is one of the reasons
we've discussed (in theory) the use of a dynamic inventory with the tooz
library - it can do file back-ends or more distributed back-ends.
__
OpenStack Development Mailing 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] [Tacker][NFV] Tacker - Weekly IRC Meeting - new time

[Sridhar Ramaswamy]

Tackers,

We are resuming Tacker IRC weekly meeting at a new time slot (an hour
earlier) and at a new channel.

When: Tuesday 1600 UTC
Where: #openstack-meeting
Duration: 1hr

Here is the agenda for tomorrow's meeting,


https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_May_10.2C_2016


   - Announcements
   - Newton Working Plan
   - Alarm based VDU Scaling - Scope, What it is and What it isn't
   - VNF FFG - Descriptor Template
   - Open Discussion


Let's pick up steam for Newton!
Sridhar
__
OpenStack Development Mailing 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] [tc] supporting Go

[Doug Hellmann]

Excerpts from Tim Simmons's message of 2016-05-09 18:29:30 +:
> > The point here though, is that the versions of Python that OpenStack
> > has traditionally supported have been directly tied to what the Linux
> > distributions carry in their repositories (case in point, Python 2.6
> > was dropped from most things as soon as RHEL7 was available with Python
> > 2.7). With Go, there might need to be similar restrictions.
> 
> I'm not sure about this, backwards compatibility in Go (at least in the last 
> year) has been good
> for me.
> 
> But because like you say, you get a statically-linked binary, you don't need 
> to
> worry about some version of anything the distro is packaging because your 
> binary
> will run anywhere.
> 
> If you're looking to compile the code from scratch, it's intentionally simple 
> to install the
> compiler, and there isn't any reason that you couldn't install multiple 
> versions simply.

I think the idea is to avoid having a compile-time dependency on a version
that isn't part of what the distros package (and therefore have available
for building packages of the software we've written). We push them hard
on library dependencies, but try to be flexible with language tools.
That's why we waited to drop python 2.6 support until everyone had at
least 2.7, for example.

Doug

> 
> >> I think you'll find that being able to embed a higher performance language 
> >> inside python will be much
> >> easier to do for optimizing a function or two rather then deal with having 
> >> a separate server have to be created,
> >> authentication be added between the two, and marshalling/unmarshalling the 
> >> data to and from it to optimize one little piece.
> >> Last I heard, you couldn't just embed go in python. C/C++ is pretty easy 
> >> to do. 
> >> Maybe I'm wrong and its possible to embed go now. Someone, please chime in 
> >> if you know of a good way.
> 
> There isn't a good way to embed Go (as far as I know), but I'd argue that for 
> a relatively isolated use case (like Graham described
> of ours), it's better to just do the thing in Go than coerce C into Python. 
> It'd introduce less risk and complexity than using Cython, imho.
> But I guess if you know C and not Go, that could be arguable.
> 
> Tim Simmons
> 
> From: Clint Byrum 
> Sent: Monday, May 9, 2016 1:15 PM
> To: openstack-dev
> Subject: Re: [openstack-dev] [tc] supporting Go
> 
> Excerpts from Pete Zaitcev's message of 2016-05-09 08:52:16 -0700:
> > On Mon, 9 May 2016 09:06:02 -0400
> > Rayson Ho  wrote:
> >
> > > Since the Go toolchain is pretty self-contained, most people just follow
> > > the official instructions to get it installed... by a one-step:
> > >
> > > # tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz
> >
> > I'm pretty certain the humanity has moved on from this sort of thing.
> > Nowadays "most people" use packaged language runtimes that come with
> > the Linux they're running.
> >
> 
> Perhaps for mature languages. But go is still finding its way, and that
> usually involves rapid changes that are needed faster than the multi-year
> cycle Linux distributions offer.
> 
> Also worth noting, is that go is not a "language runtime" but a compiler
> (that happens to statically link in a runtime to the binaries it
> produces...).
> 
> The point here though, is that the versions of Python that OpenStack
> has traditionally supported have been directly tied to what the Linux
> distributions carry in their repositories (case in point, Python 2.6
> was dropped from most things as soon as RHEL7 was available with Python
> 2.7). With Go, there might need to be similar restrictions.
> 

__
OpenStack Development Mailing 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] [tc] supporting Go

[Edward Leafe]

On May 9, 2016, at 1:58 PM, Hayes, Graham  wrote:

> This is not a "Go seems cool - lets go try that" decision from us - we
> know we have a performance problem with one of our components, and we
> have come to the conclusion that Go (or something like it) is the
> solution.

Whenever I hear claims that Python is “too slow for X”, I wonder what’s so 
special about X that makes it so much more demanding than, say, serving up 
YouTube. YouTube is written nearly entirely in Python, and has been for many, 
many years. The only parts that aren’t are those that were identified as 
particular performance bottlenecks, such as some parts of the encoding process. 
These were then written in C, which is drop-in compatible with Python using 
ctypes.


-- Ed Leafe






__
OpenStack Development Mailing 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] [designate] Summit Recap

[Hayes, Graham]

I started writing this on a plane on the way home from Austin, TX where 
we just
finished up the Newton design summit for OpenStack, and finished it a 
few days
later - please excuse any weirdness in syntax or flow :)


6 Months On: Where are we
=

One of the things I did before this design summit was to look at what we had
achieved last cycle.

We had a quiet cycle overall, but we did merge some vital features.

Operators no longer need to use the awful config format we created for pools
in Kilo, we now have a much easier to read YAML file that is loaded into the
database via the designate-manage cli, we now actually support multiple
pools in a real way with the addition of a scheduler in designate-central.


Where are we going?
===

So - the point of the design summit is to plan the future of the 
projects - and
designate is no exception. We were in a (very nice boardroom) room for a few
hours - and we talked through quite a few things.

The collection of etherpads for the summit are available [0]


Golang Replacement of MiniDNS
-

One of the nicer things about our current architecture is the 
flexibility that
we have because we use the standard DNS protocols to update the target DNS
servers. This has the downside however, that we are writing code that 
deals with
DNS packets in python, which is slow. timsim from RackSpace has written 
a POC
in go that has a very large performance improvement.[1]

This needs to documented, and permission requested from the TC to move this
component to Go, (and will be a separate post in its own right).

After we got back it turned out that we were not the only project 
considering
this, and swift actually have a feature branch with code in place. So, 
based on
this, we are going to collaborate with them on the integration of Go to
OpenStack.

Worker Model


As we discussed in Galway - we need to replace the current 
:bash:`*-manager` services
with a generic service that can scale out horizontally. As part of this we
planned out our upgrade and implementation plans for these services.

Docs, Deprecations and more Docs


Docs were a common theme - we were asked to improve them, and also have them
located in the main docs on the OpenStack.org website.

We had a member of the docs team in the room, who gave us some great 
guidance
on how to include our docs in the correct place.

VMT - The application process
-

On of the teams that supports OpenStack is the Vulnerability Management 
Team.
They deal with disclosures and assigning OSSA numbers to issues that 
could present
and issue to our deployers.

They had a session this summit on how that process might work, and designate
was one of the projects chosen to be used as a pilot as I have previously
produced Threat Analysis documentation for Designate inside of Hewlett 
Packard
Enterprise - this information is currently being processed for release to
the community.

Searchlight
---

Searchlight is a new (ish) project in OpenStack that enables true searching
capabilities on clouds. We have a designate plugin, but there are issues
with how we emit notifications from the v1 and the v2 API.

We decided that when we move the Horizon panels to v2, we will just 
listen for
v2 notifications in Searchlight.

API Docs


There was an interesting session on how the community are moving to document
their APIs. It will now reside in the projects repo, and is based on a
custom sphinx extension that was written for OpenStack.

As this progresses we will migrate designate to these docs, and remove our
current docs, as they are much harder to read.


-- Graham

0 - https://etherpad.openstack.org/p/newton-design-designate
1 - https://github.com/rackerlabs/mdns

__
OpenStack Development Mailing 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][stable][winstackers] os-win 0.4.2 release (mitaka)

[no-reply]

We are overjoyed to announce the release of:

os-win 0.4.2: Windows / Hyper-V library for OpenStack projects.

This release is part of the mitaka stable release series.

With source available at:

http://git.openstack.org/cgit/openstack/os-win

With package available at:

https://pypi.python.org/pypi/os-win

Please report issues through launchpad:

http://bugs.launchpad.net/os-win

For more details, please see below.

Changes in os-win 0.4.1..0.4.2
--

37ac7ff Fix event listeners
561358f Adds missing attribute from get_cpus_info query
c7a2d10 Fix retrieving VHDX block size
a7bbf8b Fix retrieving VM notes race condition
2fb2f57 Fix retrieving VM physical disk mapping
0be9c80 Copies get_share_capacity_info to diskutils

Diffstat (except docs and test files)
-

os_win/__init__.py |  8 
os_win/utils/compute/clusterutils.py   | 10 +++-
os_win/utils/compute/vmutils.py| 31 +---
os_win/utils/hostutils.py  |  6 ++-
os_win/utils/network/networkutils.py   | 12 -
os_win/utils/storage/diskutils.py  | 35 +-
os_win/utils/storage/smbutils.py   |  2 +
os_win/utils/storage/virtdisk/vhdutils.py  | 12 -
.../utils/storage/virtdisk/virtdisk_constants.py   |  1 +
14 files changed, 206 insertions(+), 32 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] [tc] supporting Go

[Fox, Kevin M]

Go static linking/portability is something of a misnomer too. Last I looked Go 
only statically linked Go code, so any system libraries used still were 
dynamic. So it gets you somewhat to the use case of container level portability 
but not all the way unless you can do literally everything in Go. So I think 
its better to just leave portability to containers.

Thanks,
Kevin

From: Doug Hellmann [d...@doughellmann.com]
Sent: Monday, May 09, 2016 12:14 PM
To: openstack-dev
Subject: Re: [openstack-dev] [tc] supporting Go

Excerpts from Tim Simmons's message of 2016-05-09 18:29:30 +:
> > The point here though, is that the versions of Python that OpenStack
> > has traditionally supported have been directly tied to what the Linux
> > distributions carry in their repositories (case in point, Python 2.6
> > was dropped from most things as soon as RHEL7 was available with Python
> > 2.7). With Go, there might need to be similar restrictions.
>
> I'm not sure about this, backwards compatibility in Go (at least in the last 
> year) has been good
> for me.
>
> But because like you say, you get a statically-linked binary, you don't need 
> to
> worry about some version of anything the distro is packaging because your 
> binary
> will run anywhere.
>
> If you're looking to compile the code from scratch, it's intentionally simple 
> to install the
> compiler, and there isn't any reason that you couldn't install multiple 
> versions simply.

I think the idea is to avoid having a compile-time dependency on a version
that isn't part of what the distros package (and therefore have available
for building packages of the software we've written). We push them hard
on library dependencies, but try to be flexible with language tools.
That's why we waited to drop python 2.6 support until everyone had at
least 2.7, for example.

Doug

>
> >> I think you'll find that being able to embed a higher performance language 
> >> inside python will be much
> >> easier to do for optimizing a function or two rather then deal with having 
> >> a separate server have to be created,
> >> authentication be added between the two, and marshalling/unmarshalling the 
> >> data to and from it to optimize one little piece.
> >> Last I heard, you couldn't just embed go in python. C/C++ is pretty easy 
> >> to do.
> >> Maybe I'm wrong and its possible to embed go now. Someone, please chime in 
> >> if you know of a good way.
>
> There isn't a good way to embed Go (as far as I know), but I'd argue that for 
> a relatively isolated use case (like Graham described
> of ours), it's better to just do the thing in Go than coerce C into Python. 
> It'd introduce less risk and complexity than using Cython, imho.
> But I guess if you know C and not Go, that could be arguable.
>
> Tim Simmons
> 
> From: Clint Byrum 
> Sent: Monday, May 9, 2016 1:15 PM
> To: openstack-dev
> Subject: Re: [openstack-dev] [tc] supporting Go
>
> Excerpts from Pete Zaitcev's message of 2016-05-09 08:52:16 -0700:
> > On Mon, 9 May 2016 09:06:02 -0400
> > Rayson Ho  wrote:
> >
> > > Since the Go toolchain is pretty self-contained, most people just follow
> > > the official instructions to get it installed... by a one-step:
> > >
> > > # tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz
> >
> > I'm pretty certain the humanity has moved on from this sort of thing.
> > Nowadays "most people" use packaged language runtimes that come with
> > the Linux they're running.
> >
>
> Perhaps for mature languages. But go is still finding its way, and that
> usually involves rapid changes that are needed faster than the multi-year
> cycle Linux distributions offer.
>
> Also worth noting, is that go is not a "language runtime" but a compiler
> (that happens to statically link in a runtime to the binaries it
> produces...).
>
> The point here though, is that the versions of Python that OpenStack
> has traditionally supported have been directly tied to what the Linux
> distributions carry in their repositories (case in point, Python 2.6
> was dropped from most things as soon as RHEL7 was available with Python
> 2.7). With Go, there might need to be similar restrictions.
>

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

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

Re: [openstack-dev] [TripleO][CI] Elastic recheck bugs

[Clark Boylan]

On Mon, May 9, 2016, at 10:22 AM, Sagi Shnaidman wrote:
> Hi, all
> 
> I'd like to enable elastic recheck on TripleO CI and have submitted
> patches
> for refreshing the tracked logs [1] (please review) and for timeout case
> [2].
> But according to Derek's comment behind the timeout issue could be
> multiple
> issues and bugs, so I'd like to clarify - what are criteria for elastic
> recheck bugs?
> 
> I thought about those markers:
> 
> Nova:
> 1) "No valid host was found. There are not enough hosts"
> Network issues:
> 2) "Failed to connect to trunk.rdoproject.org" OR "fatal: The remote end
> hung up unexpectedly"  OR "Could not resolve host:"
> Ironic:
> 3) "Error contacting Ironic server:"
> 4) "Introspection completed with errors:"
> 5) ": Introspection timeout"
> 6) "Timed out waiting for node "
> Glance:
> 7) "500 Internal Server Error: Failed to upload image"
> crm_resource:
> 8) "crm_resource for openstack "
> 
> and various puppet errors.
> 
> However almost all of these messages could have different root causes,
> except of network failures. Easy to fix bug doesn't make to submit there,
> because they will be fixed yet before recheck patch will be merged.
> So, could you please think about right criteria of bugs for elastic
> recheck?

I have reviewed the change to index these logs, you need to create log
files that are indexable before you can index them. Timestamps are a
huge thing here as we use delayed processing of the log files.

As far as criteria for elastic recheck bugs you are correct, the
preference is to identify specific failures in the service logs. For
example 500 internal server error: Failed to upload image is what the
client sees but the server should specifically log what the error was in
the service logs. The elastic recheck bug should be based on those
service logs.

Clark

__
OpenStack Development Mailing 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][sahara] sahara-tests 0.2.0 release

[no-reply]

We are glad to announce the release of:

sahara-tests 0.2.0: Sahara tests

With source available at:

https://git.openstack.org/cgit/openstack/sahara-tests

For more details, please see below.

0.2.0
^

Discovery of data sources with relative paths is now fixed.

Fix default resource discovery from the installed package.

Migrate auth system from keystoneclient to keystoneauth

Removed the need of a .testr.conf file when calling the test runner.


Bug Fixes
*

* Datasources with relative paths are now properly found from the
  default resources.

* The default set of resources (test templates for each plugin, etc)
  can now be properly discovered when the package is installed.

* A .testr.conf file was previously required in the runner execution
  directory, now this is handled internally.


Other Notes
***

* The default timeout for cluster polling was raised from 1800 to
  3600 seconds.

Changes in sahara-tests 0.1.0..0.2.0


943d7a4 Fix report generating
1bf5f7a Raise the timeout for cluster polling
169ff72 Improve readme contents
88269b5 Run the tests inside the test directory
ef229a2 Fix resource discovery for datasources
53e7d37 Fix relative path for default templates
f80a795 Migrated auth system from keystoneclient to keystoneauth
be091c3 Updated from global requirements
bd7a68b Add mapr 5.0.0 to liberty

Diffstat (except docs and test files)
-

CONTRIBUTING.rst   |  2 +-
README.rst | 24 +
etc/scenario/gate/edp.yaml.mako|  6 +--
.../fix-datasource-discovery-b690920189f0b161.yaml |  6 +++
...talled-resource-discovery-36ffa157cf9b06b9.yaml |  6 +++
.../increase-cluster-timeout-0e97fb7d7a6ea75a.yaml |  4 ++
.../migrate-to-keystoneauth-c65c162d74b5d7b9.yaml  |  3 ++
...implify-testrunner-config-d3a19014db107ff1.yaml |  7 +++
requirements.txt   |  4 +-
.../scenario/defaults/ambari-2.3.yaml.mako |  2 +-
.../scenario/defaults/liberty/ambari-2.3.yaml.mako |  2 +-
.../defaults/liberty/mapr-5.0.0.mrv2.yaml.mako | 52 ++
26 files changed, 302 insertions(+), 101 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index b8e959c..0bda827 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -9,0 +10 @@ jsonschema!=2.5.0,<3.0.0,>=2.0.0 # MIT
+keystoneauth1>=2.1.0 # Apache-2.0
@@ -16 +16,0 @@ paramiko>=1.16.0 # LGPL
-python-keystoneclient!=1.8.0,!=2.1.0,>=1.6.0 # Apache-2.0
@@ -20 +20 @@ python-swiftclient>=2.2.0 # Apache-2.0
-python-neutronclient>=4.1.1 # Apache-2.0
+python-neutronclient>=4.2.0 # Apache-2.0



__
OpenStack Development Mailing 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] [tc] supporting Go

[Adam Young]

On 05/09/2016 02:14 PM, Hayes, Graham wrote:

On 09/05/2016 19:09, Fox, Kevin M wrote:

I think you'll find that being able to embed a higher performance language 
inside python will be much easier to do for optimizing a function or two rather 
then deal with having a separate server have to be created, authentication be 
added between the two, and marshalling/unmarshalling the data to and from it to 
optimize one little piece. Last I heard, you couldn't just embed go in python. 
C/C++ is pretty easy to do. Maybe I'm wrong and its possible to embed go now. 
Someone, please chime in if you know of a good way.

Thanks,
Kevin

We won't be replacing any particular function, we will be replacing a
whole service.

There is no auth (or inter-service communications) from this component,
all it does it query the DB and spit out DNS packets.

I can't talk for what swift are doing, but we have a very targeted scope
for our Go work.

- Graham
I'm assuming you have a whole body of work discussing Bind and why it is 
not viable for these cases.  Is there a concise version of the discussion?







From: Hayes, Graham [graham.ha...@hpe.com]
Sent: Monday, May 09, 2016 4:33 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] supporting Go

On 08/05/2016 10:21, Thomas Goirand wrote:

On 05/04/2016 01:29 AM, Hayes, Graham wrote:

On 03/05/2016 17:03, John Dickinson wrote:

TC,

In reference to 
http://lists.openstack.org/pipermail/openstack-dev/2016-May/093680.html and 
Thierry's reply, I'm currently drafting a TC resolution to update 
http://governance.openstack.org/resolutions/20150901-programming-languages.html 
to include Go as a supported language in OpenStack projects.

As a starting point, what would you like to see addressed in the document I'm 
drafting?

--John




Great - I was about to write a thread like this :)

Designate is looking to move a single component of ours to Go - and we
were wondering what was the best way to do it.

We discussed about this during the summit. You told me that the issue
was a piece of code that needed optimization, to which I replied that
probably, a C++ .so extension in a Python module is probably what you
are looking for (with the advice of not using CFFI which is sometimes
breaking things in distros).

Did you think about this other possibility, and did you discuss it with
your team?

We had a brief discussion about it, and we going to try a new POC in
C/C++ to validate it, but then this thread (and related TC policy) were
proposed.

If Golang is going to be a supported language, we would much rather
stick with one of the official OpenStack languages that suits our
use case instead of getting an exemption for another similar language.

When we spoke at the summit, I was under the impression that the feature
branch in swift was not going to be merged to master, and we would have
to get an exemption from the TC anyway - which we could have used to get
C / C++.

The team also much preferred the idea of Golang - we do not have much
C++ expertise in the Designate dev team, which would slow down the
development cycle for us.

-- Graham


At the Linux distribution level, the main issue that there is with Go,
is that it (still) doesn't support the concept of shared library. We see
this as a bug, rather than a feature. As a consequence, when a library
upgrades, the release team has to trigger rebuilds for each and every
reverse dependencies. As the number of Go stuff increases over time, it
becomes less and less manageable this way (and it may potentially be a
security patching disaster in Stable). I've heard that upstream for
Golang was working on implementing shared libs, but I have no idea what
the status is. Does anyone know?

Cheers,

Thomas Goirand (zigo)


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



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

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



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



_

[openstack-dev] [neutron] Re: [stable] Requesting exception for stable/kilo

[Dave Walker]

On 4 May 2016 at 17:55, Sukhdev Kapur  wrote:

> Hi Stable Maintainers,
>
> We have a critical bug impacting customers production network. This is a
> minor fix.
> I would like to request an exception so that the customers do not have to
> baby
> sit this patch.
>
> https://review.openstack.org/#/c/309653/
>
> Please allow this to be merged.
>
> Thanks
> -Sukhdev
>
> __
> OpenStack Development Mailing 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] [neutron] Re: [stable] Requesting exception for stable/kilo

[Dave Walker]

On 4 May 2016 at 17:55, Sukhdev Kapur  wrote:

> Hi Stable Maintainers,
>
> We have a critical bug impacting customers production network. This is a
> minor fix.
> I would like to request an exception so that the customers do not have to
> baby
> sit this patch.
>
> https://review.openstack.org/#/c/309653/
>
> Please allow this to be merged.
>
> Thanks
> -Sukhdev
>
>
Hi,

Thanks for raising this.

I'm currently blocking the 2015.1.4 release on this request.  As it isn't a
clean backport and the 11th hour, I really want a review from neutron-core.

However, this hasn't been forthcoming.  I really need this asap, or we will
have to release without it.

Ps. apologies for the empty reply just now.

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