[openstack-dev] [neutron] core and driver teams attrition

[Armando M.]

Hi Neutrinos,

By now a few of us have noticed that the neutron core and driver teams have
lost a number of very talented and experienced engineers: well...this sucks
there's no more polite way to put it!!

These engineers are the collective memory of the project, know the kinks
and gotchas of the codebase, and are very intimate with the overall
openstack machine. They leave a big void behind. It sad to see them go, but
personally I have the utmost confidence in the fact that they have groomed
other engineers to step up in a role of greater responsibility.

Ocata might be seen by some as a hiatus, and that's ok: take the time to
rest if you can, because the team is going to grow back stronger than ever,
and it will make neutron kick-ass, even more so than it already is.

You can count on it.

Happy hacking!
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] [tripleo] Proposing Alex Schultz core on puppet-tripleo

[Jiří Stránský]

On 1.12.2016 23:26, Emilien Macchi wrote:

Team,

Alex Schultz (mwhahaha on IRC) has been active on TripleO since a few
months now.  While he's very active in different areas of TripleO, his
reviews and contributions on puppet-tripleo have been very useful.
Alex is a Puppet guy and also the current PTL of Puppet OpenStack. I
think he perfectly understands how puppet-tripleo works. His
involvement in the project and contributions on puppet-tripleo deserve
that we allow him to +2 puppet-tripleo.

Thanks Alex for your involvement and hard work in the project, this is
very appreciated!

As usual, I'll let the team to vote about this proposal.

Thanks,


+1

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

Re: [openstack-dev] [tripleo] Proposing Alex Schultz core on puppet-tripleo

[Michele Baldessari]

On Thu, Dec 01, 2016 at 05:26:31PM -0500, Emilien Macchi wrote:
> Team,
> 
> Alex Schultz (mwhahaha on IRC) has been active on TripleO since a few
> months now.  While he's very active in different areas of TripleO, his
> reviews and contributions on puppet-tripleo have been very useful.
> Alex is a Puppet guy and also the current PTL of Puppet OpenStack. I
> think he perfectly understands how puppet-tripleo works. His
> involvement in the project and contributions on puppet-tripleo deserve
> that we allow him to +2 puppet-tripleo.
> 
> Thanks Alex for your involvement and hard work in the project, this is
> very appreciated!
> 
> As usual, I'll let the team to vote about this proposal.

+1

-- 
Michele Baldessari
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D

__
OpenStack Development Mailing 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][monasca] Can we uncap python-kafka ?

[Mehdi Abaakouk]

On Fri, Dec 02, 2016 at 03:19:26PM +1100, Tony Breeds wrote:

On Thu, Dec 01, 2016 at 07:57:37AM +0100, Mehdi Abaakouk wrote:
I think the solution is pretty simple. Just Fix it.  I'm not saying it's easy
but it is *simple*.  We're a group of skilled individuals We have several ways
forward which just haven't been done in the last 8 months.  Waiting doesn't seem
to be a viable course anymore.


I agree the solution is *simple*.


From my POV this really feels more like a social problem then a technical one.
I'd like to remind everyone with a technical stake in this that it's OpenStack
First, Project Team Second[1].  The thing that's best for OpenStack is for the
oslo.mesaging and monasca teams to come together and find a path forward.  It's
really great that this thread has started that process!


No they are no social issue here, I always tried to fix other projects
issues even they are not in my area of expertise when I want to go
forward. But I'm realistic, I can only do this only if the invest and
the time it requires is not too big. And to fix (by code) that one, this
is just too high for me, sorry.

Cheers,
--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

__
OpenStack Development Mailing 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] Stepping down from core

[Andreas Scheuring]

Henry, it was a pleasure working with you! Thanks!
All the best for your further journey!


-- 
-
Andreas 
IRC: andreas_s



On Do, 2016-12-01 at 17:51 -0500, Henry Gessau wrote:
> I've already communicated this in the neutron meeting and in some neutron
> policy patches, but yesterday the PTL actually updated the gerrit ACLs so I
> thought I'd drop a note here too.
> 
> My work situation has changed and leaves me little time to keep up with my
> duties as core reviewer, DB lieutenant, and drivers team member.
> 
> Working with the diverse and very talented contributors to Neutron has been
> the best experience of my career (which started before many of you were born).
> Thank you all for making the team such a great community. Because of you the
> project is thriving and will continue to be successful!
> 
> I will still be around on IRC, contribute some small patches here and there,
> and generally try to keep abreast of Neutron's progress. Don't hesitate to
> ping 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] [gnocchi] influxdb driver gate error

[Mehdi Abaakouk]

Le 2016-12-01 23:48, Sam Morrison a écrit :

Using influxdb v1.1 works fine. anything less than 1.0 I would deem
unusable for influxdb. So to get this to work we’d need a newer
version of influxdb installed.


That's work for me.


Any idea how to do this? I see they push out a custom ceph repo to
install a newer ceph so I guess we’d need to do something similar
although influx don’t provide a repo, just a deb.


We do this kind of thing in tooz:

https://github.com/openstack/tooz/blob/master/tox.ini#L73
https://github.com/openstack/tooz/blob/master/setup-consul-env.sh

A tarball and setting the PATH is easiest and compatible with more 
platforms.


--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

__
OpenStack Development Mailing 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] [Zun] Propose a change of Zun core membership

[shubham sharma]

+1 for both.  Welcome Pradeep :)

Regards
Shubham

On Thu, Dec 1, 2016 at 5:07 AM, Hongbin Lu  wrote:

> Hi Zun cores,
>
>
>
> I am going to propose the following change of the Zun core reviewers team:
>
> + Pradeep Kumar Singh (pradeep-singh-u)
>
> - Vivek Jain (vivek-jain-openstack)
>
>
>
> Pradeep was proven to be a significant contributor to Zun. He ranked first
> at the number of commits, and his patches were non-trivial and with high
> quality. His reviews were also very helpful, and often prompted us to
> re-think the design. It would be great to have him in the core team. I
> would like to thank Vivek for his interest to join the core team when Zun
> was found. However, he became inactive in the past a few months, but he is
> welcomed to re-join the core team as long as he becomes active again.
>
>
>
> According to the OpenStack Governance process [1], we require a minimum of
> 4 +1 votes from Zun core reviewers within a 1 week voting window (consider
> this proposal as a +1 vote from me). A vote of -1 is a veto. If we cannot
> get enough votes or there is a veto vote prior to the end of the voting
> window, this proposal is rejected.
>
>
>
> [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
>
>
>
> Best regards,
>
> Hongbin
>
> __
> OpenStack Development Mailing List (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] [Zun] Propose a change of Zun core membership

[Yanyan Hu]

+1 for both.

2016-12-01 7:37 GMT+08:00 Hongbin Lu :

> Hi Zun cores,
>
>
>
> I am going to propose the following change of the Zun core reviewers team:
>
> + Pradeep Kumar Singh (pradeep-singh-u)
>
> - Vivek Jain (vivek-jain-openstack)
>
>
>
> Pradeep was proven to be a significant contributor to Zun. He ranked first
> at the number of commits, and his patches were non-trivial and with high
> quality. His reviews were also very helpful, and often prompted us to
> re-think the design. It would be great to have him in the core team. I
> would like to thank Vivek for his interest to join the core team when Zun
> was found. However, he became inactive in the past a few months, but he is
> welcomed to re-join the core team as long as he becomes active again.
>
>
>
> According to the OpenStack Governance process [1], we require a minimum of
> 4 +1 votes from Zun core reviewers within a 1 week voting window (consider
> this proposal as a +1 vote from me). A vote of -1 is a veto. If we cannot
> get enough votes or there is a veto vote prior to the end of the voting
> window, this proposal is rejected.
>
>
>
> [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
>
>
>
> Best regards,
>
> Hongbin
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,

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

Re: [openstack-dev] [tripleo] Proposing Alex Schultz core on puppet-tripleo

[Juan Antonio Osorio]

+1

On Fri, Dec 2, 2016 at 12:50 AM, Pradeep Kilambi  wrote:

>
>
> On Thu, Dec 1, 2016 at 5:26 PM, Emilien Macchi  wrote:
>
>> Team,
>>
>> Alex Schultz (mwhahaha on IRC) has been active on TripleO since a few
>> months now.  While he's very active in different areas of TripleO, his
>> reviews and contributions on puppet-tripleo have been very useful.
>> Alex is a Puppet guy and also the current PTL of Puppet OpenStack. I
>> think he perfectly understands how puppet-tripleo works. His
>> involvement in the project and contributions on puppet-tripleo deserve
>> that we allow him to +2 puppet-tripleo.
>>
>> Thanks Alex for your involvement and hard work in the project, this is
>> very appreciated!
>>
>> As usual, I'll let the team to vote about this proposal.
>>
>
>
> +1
>
>
>>
>> Thanks,
>> --
>> Emilien Macchi
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [oslo][monasca] Can we uncap python-kafka ?

[Tony Breeds]

On Thu, Dec 01, 2016 at 04:52:52PM +, Keen, Joe wrote:

> Unfortunately there’s nothing wrong on the Monasca side so far as we know.
>  We test new versions of the kafka-python library outside of Monasca
> before we bother to try integrating a new version.  Since 1.0 the
> kafka-python library has suffered from crashes and memory leaks severe
> enough that we’ve never attempted using it in Monasca itself.  We reported
> the bugs we found to the kafka-python project but they were closed once
> they released a new version.

So Opening bugs isn't working.  What about writing code?

Yours Tony.


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] [oslo][monasca] Can we uncap python-kafka ?

[Tony Breeds]

On Thu, Dec 01, 2016 at 08:41:54AM -0800, Joshua Harlow wrote:
> Keen, Joe wrote:
> > I¹ll look into testing the newest version of kafka-python and see if it
> > meets our needs.  If it still isn¹t stable and performant enough what are
> > the available options?
> 
> Fix the kafka-python library or fix monasca; those seem to be the options to
> me :)

Yup, Also worth including fix oslo.messaging to meet monasca's needs.  But
*something* needs fixing.
 
> I'd also not like to block the rest of the world (from using newer versions
> of kafka-python) during this as well. But then this may diverge/expand into
> a discussion we had a few summits ago, about getting rid of
> co-instability...

lalalalala not listening ;P

Less flippantly, there are a couple of ways to do this but IMO they're not in
the best interest of OpenStack.

1. vendor/fork python-kafka 0.X
2. Stop the proposal-bot from syncing with monasca, thereby allowing it to use
python-kafka 0.X at the expense of co-installability.

Fortunately either option is easy to reverse once the underlying issue is fixed.

Yours Tony.


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] [oslo][monasca] Can we uncap python-kafka ?

[Tony Breeds]

On Thu, Dec 01, 2016 at 07:57:37AM +0100, Mehdi Abaakouk wrote:
> I'm aware of all of that, oslo.messaging patch for the new version is
> ready since 8 months now. And we are still blocked... capping libraries,
> whatever the reason, is very annoying and just freezes people work.

And I agree with that statement.  Capping isn't the right solution.  By the
same token uncapping isn't eaither as we know we'll cause breakage.

> From the API pov python-kafka haven't break anything, the API is still
> here and documented (and deprecated). What monasca raises is performance
> issue due to how their uses the library, and on absumption on how it works
> internally. Blocking all projects for that looks not fair to me.

I understand that your blocked, but blocking the other team isn't the solution
either.
 
> As nadya said, now, we have users that that prefers using an unmerged
> patch and the new lib instead of using upstream supported
> version with the old lib. This is not an acceptable situation to me but
> that's just my thought.
> 
> Where is the solution to allow oslo.messaging works blocked since 8
> month to continue ?
> 
> So, I'm waiting for monasca team input now and hope we can move forward.

I think the solution is pretty simple. Just Fix it.  I'm not saying it's easy
but it is *simple*.  We're a group of skilled individuals We have several ways
forward which just haven't been done in the last 8 months.  Waiting doesn't seem
to be a viable course anymore.

From my POV this really feels more like a social problem then a technical one.
I'd like to remind everyone with a technical stake in this that it's OpenStack
First, Project Team Second[1].  The thing that's best for OpenStack is for the
oslo.mesaging and monasca teams to come together and find a path forward.  It's
really great that this thread has started that process!

Other people are much better placed to define the way forward, clearly fixing
python-kafka is the best option which almost certainly means joining that
community.

Worst case if we really can't find a way forward, monasca can just vendor/fork
python-kafka 0.X and we'll all admit defeat.

Yours Tony.

[1] 
http://governance.openstack.org/reference/principles.html#openstack-first-project-team-second-company-third


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

[openstack-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Dec. 2 2016

[hu . zhijiang]

1) Roll Call
2) China Telecom Support (Storage & Bare Metal) 
3) OPNFV: Daisy CI Progress
4) AoB


B.R.,
Zhijiang



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

Re: [openstack-dev] [kolla] Vote to add zhubingbing to core team

[Swapnil Kulkarni]

On Tue, Nov 29, 2016 at 9:51 PM, Michał Jastrzębski  wrote:
> Hello team!
>
> I'd like to propose to add zhubingbing to kolla (and kolla-ansible)
> core teams. He did great job reviewing code during last couple of
> months.
>
> Consider this proposal +1 from me, voting will be open for 1 week
> (until Dec 6) or if we get unanimous agreement (or veto) before.
>
> Regards,
> Michal
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

+1

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

Re: [openstack-dev] [Openstack] OpenStack Ocata B1 for Ubuntu 16.04 LTS

[Jeffrey Zhang]

Cool. And Kolla has upgrade ubuntu repo to b1 in master branch.

btw, if there is any way or help doc for proposing a new package into
ubuntu-cloud-archive? like kolla.



On Fri, Dec 2, 2016 at 12:53 AM, Corey Bryant 
wrote:

> Hi All,
>
>
> The Ubuntu OpenStack team is pleased to announce the general availability
> of the OpenStack Ocata B1 milestone in Ubuntu 16.04 LTS via the Ubuntu
> Cloud Archive.
>
>
> Ubuntu 16.04 LTS
>
> 
>
>
> You can enable the Ubuntu Cloud Archive pocket for OpenStack Ocata on
> Ubuntu 16.04 installations by running the following commands:
>
>
> echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu
> xenial-updates/ocata main" | sudo tee /etc/apt/sources.list.d/ocata-
> uca.list
>
> sudo apt install -y ubuntu-cloud-keyring
>
> sudo apt update
>
>
> The Ubuntu Cloud Archive for Ocata includes updates for: cinder, glance,
> horizon, keystone, manila, networking-ovn, neutron, neutron-fwaas,
> neutron-lbaas, neutron-dynamic-routing, nova, openstack-trove, and swift
> (2.11.0).
>
>
> You can check out the full list of packages and versions at [0].
>
>
> Branch Package Builds
>
> ---
>
>
> If you want to try out the latest updates to stable branches, we are
> delivering continuously integrated packages on each upstream commit via the
> following PPA’s:
>
>
>sudo add-apt-repository ppa:openstack-ubuntu-testing/liberty
>
>sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka
>
>sudo add-apt-repository ppa:openstack-ubuntu-testing/newton
>
>sudo add-apt-repository ppa:openstack-ubuntu-testing/ocata
>
>
> bear in mind these are built per-commit-ish (30 min checks for new commits
> at the moment) so ymmv from time-to-time.
>
>
> Reporting bugs
>
> -
>
>
> Any issues please report bugs using the 'ubuntu-bug' tool:
>
>
>   sudo ubuntu-bug nova-conductor
>
>
> this will ensure that bugs get logged in the right place in Launchpad.
>
>
> Thanks and have fun!
>
>
> Regards,
>
> Corey
>
> (on behalf of the Ubuntu OpenStack team)
>
>
> [0] http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-
> archive/ocata_versions.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
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] [Zun] Propose a change of Zun core membership

[Qiao, Liyong]

+1 

Best Regards

Eli Qiao(乔立勇）OpenStack Core team OTC Intel.
-- 


在 16/12/2 上午9:55，“Shuu Mutou” 写入:

+1 for both.

Thanks,
Shu

> -Original Message-
> From: Hongbin Lu [mailto:hongbin...@huawei.com]
> Sent: Thursday, December 01, 2016 8:38 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [Zun] Propose a change of Zun core membership
> 
> Hi Zun cores,
> 
> 
> 
> I am going to propose the following change of the Zun core reviewers team:
> 
> + Pradeep Kumar Singh (pradeep-singh-u)
> 
> - Vivek Jain (vivek-jain-openstack)
> 
> 
> 
> Pradeep was proven to be a significant contributor to Zun. He ranked first
> at the number of commits, and his patches were non-trivial and with high
> quality. His reviews were also very helpful, and often prompted us to
> re-think the design. It would be great to have him in the core team. I 
would
> like to thank Vivek for his interest to join the core team when Zun was
> found. However, he became inactive in the past a few months, but he is
> welcomed to re-join the core team as long as he becomes active again.
> 
> 
> 
> According to the OpenStack Governance process [1], we require a minimum
> of 4 +1 votes from Zun core reviewers within a 1 week voting window 
(consider
> this proposal as a +1 vote from me). A vote of -1 is a veto. If we cannot
> get enough votes or there is a veto vote prior to the end of the voting
> window, this proposal is rejected.
> 
> 
> 
> [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> 
> 
> 
> 
> Best regards,
> 
> Hongbin


__
OpenStack Development Mailing List (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] [Zun] Propose a change of Zun core membership

[Shuu Mutou]

+1 for both.

Thanks,
Shu

> -Original Message-
> From: Hongbin Lu [mailto:hongbin...@huawei.com]
> Sent: Thursday, December 01, 2016 8:38 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [Zun] Propose a change of Zun core membership
> 
> Hi Zun cores,
> 
> 
> 
> I am going to propose the following change of the Zun core reviewers team:
> 
> + Pradeep Kumar Singh (pradeep-singh-u)
> 
> - Vivek Jain (vivek-jain-openstack)
> 
> 
> 
> Pradeep was proven to be a significant contributor to Zun. He ranked first
> at the number of commits, and his patches were non-trivial and with high
> quality. His reviews were also very helpful, and often prompted us to
> re-think the design. It would be great to have him in the core team. I would
> like to thank Vivek for his interest to join the core team when Zun was
> found. However, he became inactive in the past a few months, but he is
> welcomed to re-join the core team as long as he becomes active again.
> 
> 
> 
> According to the OpenStack Governance process [1], we require a minimum
> of 4 +1 votes from Zun core reviewers within a 1 week voting window (consider
> this proposal as a +1 vote from me). A vote of -1 is a veto. If we cannot
> get enough votes or there is a veto vote prior to the end of the voting
> window, this proposal is rejected.
> 
> 
> 
> [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> 
> 
> 
> 
> Best regards,
> 
> Hongbin


__
OpenStack Development Mailing List (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] What's Up, Doc? Holiday Edition!

[Lana Brindley]

Hi everyone,

The end of the year is nearly upon us already, and this will be my last 
newsletter for 2016, before I disappear for the holidays on the 16th. I've had 
yet another wonderful year with all you lovely OpenStack people, and I wish all 
of you and your families a happy and safe holiday, wherever and however you 
celebrate it. Here in Australia, the temperature is starting to soar, so I'm 
off on another cruise, followed by a few lazy days by the pool with family and 
friends. I'll be back in the office early in the new year, and ready to kick 
Ocata out of the door!

As many of you already know, I'm not planning on running for Pike PTL. If 
you're interested in running for PTL (for Pike or any future release), and 
would like a crash course in PTLing, please let me know and I can share 
whatever meagre wisdom I've gleaned before self nominations open in mid-January.

== Progress towards Ocata ==

82 days to go!

Closed 106 bugs so far.

Release tasks are being tracked here: 
https://wiki.openstack.org/wiki/Documentation/OcataDeliverables

== The Road to PTG in Atlanta ==

Event info is available here: http://www.openstack.org/ptg 
Purchase tickets here: https://pikeptg.eventbrite.com/ 

Docs is a horizontal project, so our sessions will run across the Monday and 
Tuesday of the event.

The incoming PTL will be responsible for planning and running sessions at the 
Atlanta PTG.

== Speciality Team Reports ==

* API: Anne Gentle
The App Dev Support WG is working on a survey to determine which content areas 
to invest in for content on http://www.openstack.org/appdev 
(http://lists.openstack.org/pipermail/user-committee/2016-November/001469.html)

* Configuration Reference and CLI Reference: Tomoyuki Kato
We try to recreating the single page view for the "openstack" command. I'd like 
to generate the reference from source code automatically. However, 
python-openstackclient has many plug-ins. It is difficulty, but worth to tackle 
it. We need your help!

* High Availability Guide: Andrew Beekhof
No formal report, but Alex Settle has been doing a lot of work on this guide 
recently, cleaning up, and raising bugs for some of the TODO items. We need to 
consider if the HA guide is an ongoing concern. Ben Silverman is wondering if 
we can fold the content into the Ops/Arch Guides. This will be raised on the 
mailing list for more conversation. 

* Hypervisor Tuning Guide: Joe Topjian
No report this week

* Installation guides: Lana Brindley
We've heard back from Foundation on design resources, I'm going to reply to  
that email today and hopefully start drafting the new design next week. I've 
also got Piet from the UX team  on board to help. Anyone who wants to be 
involved with that, please contact me.

* Networking Guide: John Davidge
No update this week.

* Operations and Architecture Design guides: Darren Chan
For the Arch guide, patches for networking and compute content were merged, 
thanks to Ben and Shaun. For the Ops Guide, there is patch up to update the 
upgrades chapter and include links to the project upgrade notes: 
https://review.openstack.org/#/c/404528/

* Security Guide: Nathaniel Dillon
No update this week.

* Training Guides: Matjaz Pancur
BCN Upstream training article in the Superuser magazine: 
http://superuser.openstack.org/articles/openstack-upstream-training-revamp/ - 
actively looking for contributors to join the Upstream training, please see 
http://lists.openstack.org/pipermail/openstack-docs/2016-November/009382.html - 
cleaned test entries in the Launchpad bug queue and the Sandbox repository 
(left from the Barcelona Upstream training) - updated Training guides README.rst

* Training labs: Pranav Salunke, Roger Luethi
No update this week.

* User guides: Joseph Robinson
The legacy command conversion continues at a good pace. I have some more 
updates to patch today. The only obstacle I have run into is generating new 
output to match the OpenStack command client. Otherwise, contributors have been 
adding to the table, and there's been steady patching completed. Just a 
reminder to update the table if making a change: 
https://wiki.openstack.org/wiki/Documentation/ReorganizeUserGuides

== Doc team meeting ==

Our next meeting will be on Thursday 16 December at 2100 UTC in 
#openstack-meeting-alt

For more meeting details, including minutes and the agenda: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

--

Keep on doc'ing!

Lana

https://wiki.openstack.org/wiki/Documentation/WhatsUpDoc#1_December_2016


-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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

[openstack-dev] Fw: Re: Re: [kolla] Obtaining version information for Docker container

[hu . zhijiang]

Adrian,

Thank you for the information.

B.R.,
Zhijiang




发件人: Adrian Mouat 
收件人: hu.zhiji...@zte.com.cn, 
抄送:   "OpenStack Development Mailing List (not for usage questions)" 

日期:   2016-12-01 23:49
主题:   Re: Re: [openstack-dev] [kolla] Obtaining version information for 
Docker container



You can get labels without pulling the full image (it's part of the 
metadata rather than the image itself. For example, Skopeo (
https://github.com/projectatomic/skopeo)  can do this:

./skopeo inspect docker://amouat/network-utils
{
"Name": "docker.io/amouat/network-utils",
"Digest": 
"sha256:fcb208490240b82af947a24b233cbc208ee9761035731bddbeb888bb33b71d14",
"RepoTags": [
"latest"
],
"Created": "2016-11-11T12:59:09.461996171Z",
"DockerVersion": "1.12.3",
"Labels": {
"org.label-schema.build-date": "2016-11-11 12:57:22+00:00",
"org.label-schema.docker.dockerfile": "/Dockerfile",
"org.label-schema.vcs-type": "Git",
"org.label-schema.vcs-url": "
https://github.com/amouat/network-utils-container;
},
"Architecture": "amd64",
"Os": "linux",
"Layers": [

"sha256:386a066cd84a33a04d560c42bef66d1dd64ebfc76de78550e5fd0f8d57778bca",

"sha256:44f8daaa54e7d5a2fc678d26ae691ab0f7c6a51bb7346fbdd581697f22b1a120",

"sha256:c6a1e73879c72e17e7a917b197d0927494f48f42bd560f2ff61ab8efa3814830"
]
}


On Thu, Dec 1, 2016 at 10:57 AM,  wrote:
For #1, I think the requirement is that before pulling the image to local
registry, one can get its metadata about the version info before hand,
thus save time and space spend on pulling wrong images. I don't know if
the info in docker label can be retrieved before before pulling the image
to local registry. If not, holding such info in docker label may be not a
good solution since we have to pull the image first.

Another thought is how about let the kolla build command to generate a
report about what component version it used to build for each image and
just let it output this report to a file or stdout? Then this well
formatted output can be published along with the images(docker save...)
but not inside of images.


B.R.,
Zhijiang




发件人: Pete Birley 
收件人: "OpenStack Development Mailing List (not for usage
questions)" , Adrian Mouat
,
日期:   2016-11-19 02:17
主题:   Re: [openstack-dev] [kolla] Obtaining version information for
Docker container



I've been thinking about this a bit as well, and think that we should
consider using the docker label schema (http://label-schema.org/rc1/) as a
solution for #1, it would be possible to add labeling to kolla-build to
add these labels simply. This solution is gaining traction in the docker
community, and integrates well with external tools e.g.
https://microbadger.com. One of the maintainers of this project (Adrian
Mouat) works in the same room as me and I've cc'd him in case he has any
additional insight or perspective that may be useful.

Unfortunately this does not provide a solution to the 2nd problem, and
currently it is not possible to query labels from within a container. I
think Steve's suggestion of a simple shell tool to query the containers
package manager(s) and produce a report is probably the right way to go:
but we should draw up a specification that scoped what data we collected
in such a manifest as if we simply do the equivalent of 'rpm -qa' then I
think Paul's point is valid and we don't gain much from the exercise.

Cheers

Pete

On Fri, Nov 18, 2016 at 11:51 AM, Steven Dake (stdake) 
wrote:
Zhu,

This isn’t the first time this question has been asked :)

Since this is a technical matter, I’ve copied openstack-dev for a wider
audience.  I don’t have a clear solution to obtaining version manifests
for container content or the upstream container version.  Perhaps someone
in our broader community may have an answer.

The best I’ve got is we could add a general shell command that can be run
with docker exec to obtain a proper version manifest of both 1 and 2
(formatted in YAML or plaintext).  This could be placed in the base
container image to enable a general diagnostic and certificate of origin
tool.

Perhaps someone has a better solution?

Regards
-steve


From: "zhu.z...@zte.com.cn" 
Date: Friday, November 18, 2016 at 1:56 AM
To: Steven Dake 
Subject: 

Hello，nice to meet you. I am a contributor of Kolla.
Excuse me, I have a question to bother you.
The question is that how to get openstack component version from a running
container or image.
you know , the version info is wrapped by the container, it is not easy to
get them
there are two type of versions
one: version in a image, two: version in a running container
two is easy, for example , we can get it by 

Re: [openstack-dev] [infra]help on the description update in github repository

[joehuang]

Thank you very much. It's updated :-)

Best Regards
Chaoyi Huang (joehuang)


From: Jeremy Stanley [fu...@yuggoth.org]
Sent: 02 December 2016 0:08
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [infra]help on the description update in github 
repository

On 2016-12-01 07:14:58 + (+), joehuang wrote:
> The short project description of Tricircle is: "Tricircle is to
> provide networking automation across Neutron." in
> http://git.openstack.org/cgit/openstack/tricircle/,
> the official repository.
>
> But the description in the mirrored github
> repository(https://github.com/openstack/tricircle/) below the code
> tab is still "Tricircle is a project for OpenStack cascading
> solution. ",  it's old and obsolete description.

Our automation which maintains the github.com mirror configuration
doesn't currently update repository descriptions, because it
maintains insufficient state and attempting to query all our 1.5k+
repos there overruns their API throttling limits very quickly.

> I contacted github help desk, they said they have no right to
> update it, only the guy from OpenStack who has update(or write)
> right can update it manually.

Correct, only the organization admins for the repo in question can
update its description. For the "openstack" organization that's
basically the Infra team's root sysadmins.

> So would someone help to update the Tricircle description in
> github, Tricircle is one OpenStack official project now, it's
> better to keep the description consistent.

I have done this just now, as requested.
--
Jeremy Stanley

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

__
OpenStack Development Mailing 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] Stepping down from core

[Matt Riedemann]

On 12/1/2016 4:51 PM, Henry Gessau wrote:

I've already communicated this in the neutron meeting and in some neutron
policy patches, but yesterday the PTL actually updated the gerrit ACLs so I
thought I'd drop a note here too.

My work situation has changed and leaves me little time to keep up with my
duties as core reviewer, DB lieutenant, and drivers team member.

Working with the diverse and very talented contributors to Neutron has been
the best experience of my career (which started before many of you were born).
Thank you all for making the team such a great community. Because of you the
project is thriving and will continue to be successful!

I will still be around on IRC, contribute some small patches here and there,
and generally try to keep abreast of Neutron's progress. Don't hesitate to
ping 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



I'm not a regular Neutron guy but I like to show up in the channel and 
complain about things, and Henry you were one of the few people that 
would respond constructively to my grumblings and help me out, and for 
that I thank you. You also helped me get the get-me-a-network stuff 
started on the Nova side, which was a major priority for Nova in the 
Newton release, so again, thanks for your help there.


Good luck with everything.

--

Thanks,

Matt Riedemann


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

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

[Neil Jerram]

Thanks for your help with recent neutron-lib transitions, and best wishes
for your future work, Henry!

 Neil


On Thu, Dec 1, 2016 at 11:06 PM Dariusz Śmigiel 
wrote:

> Henry,
> it's very sad to see you stepping down.
> Thank you for all the time and help in Keystone v3 development.
>
> I hope you will have a lot of new, even better, experiences in your
> further journey.
>
> Thank you
>
> 2016-12-01 16:51 GMT-06:00 Henry Gessau :
> > I've already communicated this in the neutron meeting and in some neutron
> > policy patches, but yesterday the PTL actually updated the gerrit ACLs
> so I
> > thought I'd drop a note here too.
> >
> > My work situation has changed and leaves me little time to keep up with
> my
> > duties as core reviewer, DB lieutenant, and drivers team member.
> >
> > Working with the diverse and very talented contributors to Neutron has
> been
> > the best experience of my career (which started before many of you were
> born).
> > Thank you all for making the team such a great community. Because of you
> the
> > project is thriving and will continue to be successful!
> >
> > I will still be around on IRC, contribute some small patches here and
> there,
> > and generally try to keep abreast of Neutron's progress. Don't hesitate
> to
> > ping 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
>
>
>
> --
> Darek "dasm" Śmigiel
>
> 
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
>
> __
> OpenStack Development Mailing List (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] [keystone] team logo (initial draft)

[Morgan Fainberg]

Looks good! Commented on the Form, but the "grey section" might be even
better if there was a little color to it. As it is, It might be too "stark"
a contrast as it is to a black laptop/background (white alone tends to be)
if the white sections are opaque, and it might fade into a "white" or
silver background (aka macbook (pro) style).

It might even be cooler if the grey sections were provided with a variety
of color differences.

Overall the turtle looks great stylistically, I like that the shell almost
has a "keystone" (as in what goes in an arch) shape to it.

Cheers,
--Morgan

On Thu, Dec 1, 2016 at 2:09 PM, Steve Martinelli 
wrote:

> keystoners, we finally have a logo! well a draft version of it :)
>
> Please provide feedback by Tuesday, Dec. 13 (good or bad) at:
> www.tinyurl.com/OSmascot
> Heidi (cc'ed) will be out of the office Dec. 2-12 but promises to respond
> to questions as swiftly as possible when she returns.
>
> All hail the turtle!
>
> stevemar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Move unapproved specs to Pike

[Matt Riedemann]

We now have the Pike structure in place for the nova-specs repo:

https://specs.openstack.org/openstack/nova-specs/specs/pike/index.html

So if you have specs which weren't approved for Ocata and you plan on 
pursuing them again in Pike, please move them over to the 
specs/pike/approved/ directory structure.


There have been no changes to the Template except for the 'History' 
section saying Pike instead of Ocata.


Failure to move specs from ocata to pike within some amount of time will 
result in being subject to mikal's favorite abandon-bot script. You've 
been warned. :)


--

Thanks,

Matt Riedemann


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

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

[Dariusz Śmigiel]

Henry,
it's very sad to see you stepping down.
Thank you for all the time and help in Keystone v3 development.

I hope you will have a lot of new, even better, experiences in your
further journey.

Thank you

2016-12-01 16:51 GMT-06:00 Henry Gessau :
> I've already communicated this in the neutron meeting and in some neutron
> policy patches, but yesterday the PTL actually updated the gerrit ACLs so I
> thought I'd drop a note here too.
>
> My work situation has changed and leaves me little time to keep up with my
> duties as core reviewer, DB lieutenant, and drivers team member.
>
> Working with the diverse and very talented contributors to Neutron has been
> the best experience of my career (which started before many of you were born).
> Thank you all for making the team such a great community. Because of you the
> project is thriving and will continue to be successful!
>
> I will still be around on IRC, contribute some small patches here and there,
> and generally try to keep abreast of Neutron's progress. Don't hesitate to
> ping 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



-- 
Darek "dasm" Śmigiel


Q: Why is this email five sentences or less?
A: http://five.sentenc.es

__
OpenStack Development Mailing List (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] Stepping down from core

[Henry Gessau]

I've already communicated this in the neutron meeting and in some neutron
policy patches, but yesterday the PTL actually updated the gerrit ACLs so I
thought I'd drop a note here too.

My work situation has changed and leaves me little time to keep up with my
duties as core reviewer, DB lieutenant, and drivers team member.

Working with the diverse and very talented contributors to Neutron has been
the best experience of my career (which started before many of you were born).
Thank you all for making the team such a great community. Because of you the
project is thriving and will continue to be successful!

I will still be around on IRC, contribute some small patches here and there,
and generally try to keep abreast of Neutron's progress. Don't hesitate to
ping 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] [tripleo] Proposing Alex Schultz core on puppet-tripleo

[Pradeep Kilambi]

On Thu, Dec 1, 2016 at 5:26 PM, Emilien Macchi  wrote:

> Team,
>
> Alex Schultz (mwhahaha on IRC) has been active on TripleO since a few
> months now.  While he's very active in different areas of TripleO, his
> reviews and contributions on puppet-tripleo have been very useful.
> Alex is a Puppet guy and also the current PTL of Puppet OpenStack. I
> think he perfectly understands how puppet-tripleo works. His
> involvement in the project and contributions on puppet-tripleo deserve
> that we allow him to +2 puppet-tripleo.
>
> Thanks Alex for your involvement and hard work in the project, this is
> very appreciated!
>
> As usual, I'll let the team to vote about this proposal.
>


+1


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

Re: [openstack-dev] [gnocchi] influxdb driver gate error

[Sam Morrison]

I’ve been working a bit on this and the errors I’m getting in the gate I can 
now replicate in my environment if I use the same version of influxdb in the 
gate (0.10)

Using influxdb v1.1 works fine. anything less than 1.0 I would deem unusable 
for influxdb. So to get this to work we’d need a newer version of influxdb 
installed. 

Any idea how to do this? I see they push out a custom ceph repo to install a 
newer ceph so I guess we’d need to do something similar although influx don’t 
provide a repo, just a deb.

Sam




> On 30 Nov. 2016, at 7:35 pm, Sam Morrison  wrote:
> 
> 
>> On 30 Nov. 2016, at 6:23 pm, Mehdi Abaakouk  wrote:
>> 
>> 
>> 
>> Le 2016-11-30 08:06, Sam Morrison a écrit :
>>> 2016-11-30 06:50:14.969302 | + pifpaf -e GNOCCHI_STORAGE run influxdb
>>> -- pifpaf -e GNOCCHI_INDEXER run mysql -- ./tools/pretty_tox.sh
>>> 2016-11-30 06:50:17.399380 | ERROR: pifpaf: 'ascii' codec can't decode
>>> byte 0xc2 in position 165: ordinal not in range(128)
>>> 2016-11-30 06:50:17.415485 | ERROR: InvocationError:
>>> '/home/jenkins/workspace/gate-gnocchi-tox-db-py27-mysql-ubuntu-xenial/run-tests.sh’
>> 
>> You can temporary pass '--debug' to pifpaf to get the full backtrace.
> 
> Good idea, thanks! Get this error. Don’t get it on the py3 job though
> 
> Get further with the py3 job but get some other errors I don’t see in my env 
> so trying to figure out what is different.
> 
> 
> 2016-11-30 07:40:17.209979 | + pifpaf --debug -e GNOCCHI_STORAGE run influxdb 
> -- pifpaf -e GNOCCHI_INDEXER run mysql -- ./tools/pretty_tox.sh
> 2016-11-30 07:40:17.746304 | DEBUG: pifpaf.drivers: executing: ['influxd', 
> '-config', '/tmp/tmp.7pq0EBpjgt/tmpikRcvn/config']
> 2016-11-30 07:40:17.759236 | DEBUG: pifpaf.drivers: influxd[20435] output: 
> 2016-11-30 07:40:17.759804 | DEBUG: pifpaf.drivers: influxd[20435] output:  
> 888   .d888 888   888b.  88b.
> 2016-11-30 07:40:17.759909 | DEBUG: pifpaf.drivers: influxd[20435] output:
> 888d88P"  888   888  "Y88b 888  "88b
> 2016-11-30 07:40:17.760003 | DEBUG: pifpaf.drivers: influxd[20435] output:
> 888888888   888888 888  .88P
> 2016-11-30 07:40:17.760094 | DEBUG: pifpaf.drivers: influxd[20435] output:
> 888   8b.  88 888 888  888 888  888 888888 888K.
> 2016-11-30 07:40:17.760196 | DEBUG: pifpaf.drivers: influxd[20435] output:
> 888   888 "88b 888888 888  888  Y8bd8P' 888888 888  "Y88b
> 2016-11-30 07:40:17.760296 | DEBUG: pifpaf.drivers: influxd[20435] output:
> 888   888  888 888888 888  888   X88K   888888 888888
> 2016-11-30 07:40:17.760384 | DEBUG: pifpaf.drivers: influxd[20435] output:
> 888   888  888 888888 Y88b 888 .d8""8b. 888  .d88P 888   d88P
> 2016-11-30 07:40:17.760474 | DEBUG: pifpaf.drivers: influxd[20435] output:  
> 888 888  888 888888  "Y8 888  888 888P"  888P"
> 2016-11-30 07:40:17.760516 | DEBUG: pifpaf.drivers: influxd[20435] output: 
> 2016-11-30 07:40:17.760643 | DEBUG: pifpaf.drivers: influxd[20435] output: 
> 2016/11/30 07:40:17 InfluxDB starting, version 0.10.0, branch unknown, commit 
> unknown, built unknown
> 2016-11-30 07:40:17.760722 | DEBUG: pifpaf.drivers: influxd[20435] output: 
> 2016/11/30 07:40:17 Go version go1.6rc1, GOMAXPROCS set to 8
> 2016-11-30 07:40:17.859524 | DEBUG: pifpaf.drivers: influxd[20435] output: 
> 2016/11/30 07:40:17 Using configuration at: 
> /tmp/tmp.7pq0EBpjgt/tmpikRcvn/config
> 2016-11-30 07:40:17.860852 | DEBUG: pifpaf.drivers: influxd[20435] output: 
> [meta] 2016/11/30 07:40:17 Starting meta service
> 2016-11-30 07:40:17.861033 | DEBUG: pifpaf.drivers: influxd[20435] output: 
> [meta] 2016/11/30 07:40:17 Listening on HTTP: 127.0.0.1:51232
> 2016-11-30 07:40:17.871362 | DEBUG: pifpaf.drivers: influxd[20435] output: 
> [metastore] 2016/11/30 07:40:17 Using data dir: 
> /tmp/tmp.7pq0EBpjgt/tmpikRcvn/meta
> 2016-11-30 07:40:17.878511 | DEBUG: pifpaf.drivers: influxd[20435] output: 
> [metastore] 2016/11/30 07:40:17 Node at localhost:51233 [Follower]
> 2016-11-30 07:40:19.079831 | DEBUG: pifpaf.drivers: influxd[20435] output: 
> [metastore] 2016/11/30 07:40:19 Node at localhost:51233 [Leader]. 
> peers=[localhost:51233]
> 2016-11-30 07:40:19.180811 | Traceback (most recent call last):
> 2016-11-30 07:40:19.180865 |   File "/usr/lib/python2.7/logging/__init__.py", 
> line 884, in emit
> 2016-11-30 07:40:19.182121 | stream.write(fs % msg.encode("UTF-8"))
> 2016-11-30 07:40:19.182194 | UnicodeDecodeError: 'ascii' codec can't decode 
> byte 0xc2 in position 211: ordinal not in range(128)
> 2016-11-30 07:40:19.182225 | Logged from file __init__.py, line 80
> 2016-11-30 07:40:19.183188 | ERROR: pifpaf: Traceback (most recent call last):
> 2016-11-30 07:40:19.183271 |   File 
> 

Re: [openstack-dev] [tripleo] Proposing Alex Schultz core on puppet-tripleo

[Carlos Camacho Gonzalez]

+1

On Thu, Dec 1, 2016 at 11:37 PM, Dan Trainor  wrote:
> +1
>
> On Dec 1, 2016 5:36 PM, "James Slagle"  wrote:
>>
>> On Thu, Dec 1, 2016 at 5:26 PM, Emilien Macchi  wrote:
>> > Team,
>> >
>> > Alex Schultz (mwhahaha on IRC) has been active on TripleO since a few
>> > months now.  While he's very active in different areas of TripleO, his
>> > reviews and contributions on puppet-tripleo have been very useful.
>> > Alex is a Puppet guy and also the current PTL of Puppet OpenStack. I
>> > think he perfectly understands how puppet-tripleo works. His
>> > involvement in the project and contributions on puppet-tripleo deserve
>> > that we allow him to +2 puppet-tripleo.
>> >
>> > Thanks Alex for your involvement and hard work in the project, this is
>> > very appreciated!
>> >
>> > As usual, I'll let the team to vote about this proposal.
>>
>> +1
>>
>>
>> --
>> -- James Slagle
>> --
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (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] Proposing Alex Schultz core on puppet-tripleo

[Dan Trainor]

+1

On Dec 1, 2016 5:36 PM, "James Slagle"  wrote:

> On Thu, Dec 1, 2016 at 5:26 PM, Emilien Macchi  wrote:
> > Team,
> >
> > Alex Schultz (mwhahaha on IRC) has been active on TripleO since a few
> > months now.  While he's very active in different areas of TripleO, his
> > reviews and contributions on puppet-tripleo have been very useful.
> > Alex is a Puppet guy and also the current PTL of Puppet OpenStack. I
> > think he perfectly understands how puppet-tripleo works. His
> > involvement in the project and contributions on puppet-tripleo deserve
> > that we allow him to +2 puppet-tripleo.
> >
> > Thanks Alex for your involvement and hard work in the project, this is
> > very appreciated!
> >
> > As usual, I'll let the team to vote about this proposal.
>
> +1
>
>
> --
> -- James Slagle
> --
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Proposing Alex Schultz core on puppet-tripleo

[Brent Eagles]

On Thu, Dec 1, 2016 at 7:03 PM, James Slagle  wrote:

> On Thu, Dec 1, 2016 at 5:26 PM, Emilien Macchi  wrote:
> > Team,
> >
> > Alex Schultz (mwhahaha on IRC) has been active on TripleO since a few
> > months now.  While he's very active in different areas of TripleO, his
> > reviews and contributions on puppet-tripleo have been very useful.
> > Alex is a Puppet guy and also the current PTL of Puppet OpenStack. I
> > think he perfectly understands how puppet-tripleo works. His
> > involvement in the project and contributions on puppet-tripleo deserve
> > that we allow him to +2 puppet-tripleo.
> >
> > Thanks Alex for your involvement and hard work in the project, this is
> > very appreciated!
> >
> > As usual, I'll let the team to vote about this proposal.
>
> +1
>
>
​+1 indeed!​
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Proposing Alex Schultz core on puppet-tripleo

[James Slagle]

On Thu, Dec 1, 2016 at 5:26 PM, Emilien Macchi  wrote:
> Team,
>
> Alex Schultz (mwhahaha on IRC) has been active on TripleO since a few
> months now.  While he's very active in different areas of TripleO, his
> reviews and contributions on puppet-tripleo have been very useful.
> Alex is a Puppet guy and also the current PTL of Puppet OpenStack. I
> think he perfectly understands how puppet-tripleo works. His
> involvement in the project and contributions on puppet-tripleo deserve
> that we allow him to +2 puppet-tripleo.
>
> Thanks Alex for your involvement and hard work in the project, this is
> very appreciated!
>
> As usual, I'll let the team to vote about this proposal.

+1


-- 
-- James Slagle
--

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

[openstack-dev] [tripleo] Proposing Alex Schultz core on puppet-tripleo

[Emilien Macchi]

Team,

Alex Schultz (mwhahaha on IRC) has been active on TripleO since a few
months now.  While he's very active in different areas of TripleO, his
reviews and contributions on puppet-tripleo have been very useful.
Alex is a Puppet guy and also the current PTL of Puppet OpenStack. I
think he perfectly understands how puppet-tripleo works. His
involvement in the project and contributions on puppet-tripleo deserve
that we allow him to +2 puppet-tripleo.

Thanks Alex for your involvement and hard work in the project, this is
very appreciated!

As usual, I'll let the team to vote about this proposal.

Thanks,
-- 
Emilien Macchi

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

Re: [openstack-dev] [nova] Status of imagebackend refactor patches

[Jay Pipes]

Just following up on this. All of the above are now approved and working 
their way through the gate. Big thanks to Sean Dague, Feodor Tersin, and 
Melanie Witt for review assistance over the last couple weeks. Also 
thanks to Chris Dent for reviewing the bulk of the series today as well 
and leaving some excellent questions and comments.


Best,
-jay

On 11/29/2016 12:48 PM, Matthew Booth wrote:

I'm continuing to work through updating the imagebackend refactor
patches. A bunch of them at the top of the queue already have +2 from
jaypipes, who expressed an interest in getting some of these merged. I
think the following could be ready to go (in order):

https://review.openstack.org/#/c/337159/  libvirt: Rewrite
_test_finish_migration [1]
https://review.openstack.org/#/c/338993/  libvirt: Test disk creation in
test_hard_reboot
https://review.openstack.org/#/c/339114/  libvirt: Cleanup
test_create_configdrive
https://review.openstack.org/#/c/333272/  libvirt: Rename Backend
snapshot and image [2]
https://review.openstack.org/#/c/331115/  libvirt: Never copy a swap
disk during cold migration
https://review.openstack.org/#/c/331118/  libvirt: Don't re-resize disks
in finish_migration() [3]

[1] This has -1 from melwitt, but I don't personally think this issue is
worth a respin. However, she mentioned on IRC that there may be more, so
that could be moot. Anyway, being the top of the queue this is obviously
a blocker.

[2] This doesn't have +2 from jaypipes, although it's uncontroversial
and uncomplicated. Hopefully just an oversight?

[3] This patch removes the function which melwitt identified in [1] lost
some test coverage, which is why I'm hoping not to respin for that.

I'll leave it there for the moment, because I need to talk through the
next patch with ftersin. It looks like it will require a release note at
least, if not a change.

If anybody would like to slog through some of the above and add a second
+2 I'd be very grateful. There's plenty more in the queue after those!

Thanks,

Matt
--
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)



__
OpenStack Development Mailing List (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] [Horizon][Keystone] Weekly meeting log (2016/12/1)

[Richard Jones]

Hi folks,

The meeting bot disappeared during the meeting so the record is
incomplete. The last 20 minutes are still in the channel log here:

http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-cp/%23openstack-meeting-cp.2016-12-01.log.html#t2016-12-01T20:42:08


Richard

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

[openstack-dev] [release] Release management team draft logo

[Doug Hellmann]

Release team, please take a look at the attached logo and let me know what you 
think.

Doug

> Begin forwarded message:
> 
> From: Heidi Joy Tretheway
> Subject: Release management team draft logo
> Date: December 1, 2016 at 2:29:05 PM EST
> To: Doug Hellmann 
> 
> Thanks to you and your team for your patience as our illustrators created 
> nearly 60 project mascot logos. As I alerted you earlier, we weren’t happy 
> with the initial draft, so we pushed our illustrators to create a logo that 
> we’re truly happy with before we shared it with your team to review/react to 
> it. 
> 
> We now have a draft logo (without color) and we’d love for you to share this 
> form with your team for feedback: www.tinyurl.com/OSmascot 
>   - This really helps us stay organized, 
> evaluate conflicting feedback, and give a clear direction to the illustrators!
> 
> Please feel free to share this with your team and we’d love to have your 
> feedback by Tuesday, Dec. 13. 
> 
> We’re doing our best to get these ready for the PTG and I really appreciate 
> your team’s patience!
> 
> 
> 
> 
> 

__
OpenStack Development Mailing List (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] [qa] [openstack-health] Avoid showing non-official projects failure ratios

[Ken'ichi Ohmichi]

Hi QA-team,

In the big-tent policy, we continue creating new projects.
On the other hand, some projects became non-active.
That seems natural thing.

Now openstack-health[1] shows non-active project as 100% failure ratio
on "Project Status".
The project has became non-official since
https://review.openstack.org/#/c/324412/
So I feel it is nice to have black-list or something to make it
disappear from the dashboard for concentrating on active projects'
failures.

Any thoughts?

Thanks
Ken Ohmichi
---

[1]: http://status.openstack.org/openstack-health/#/

__
OpenStack Development Mailing List (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] [Telemetry] team draft logo

[Julien Danjou]

Hi team,

Attached is our logo. You can share feedback here or directly with the
Foundation at www.tinyurl.com/OSmascot

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


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

Re: [openstack-dev] [neutron][octavia] Neutron LBaaS governance change and Octavia to the big tent

[Armando M.]

On 1 December 2016 at 08:04, Michael Johnson  wrote:

> There are a lot more than just those three (which are under packaging
> and not neutron btw).
>
> I will start working on moving/scrubbing the bugs today.
>

At the same time, I'll be working to make sure we have a coordinated access
to lbaas backports (i.e. tweaking gerrit ACLs).

Cheers,
Armando


>
> Michael
>
> On Thu, Dec 1, 2016 at 7:30 AM, Brian Haley  wrote:
> > On 12/01/2016 08:54 AM, Ihar Hrachyshka wrote:
> >>
> >> Armando M.  wrote:
> >>
> >>> Hi folks,
> >>>
> >>> A few hours ago a governance change [1] has been approved by TC
> members.
> >>> This
> >>> means that from now on, the efforts for Load Balancing as a Service
> >>> efforts
> >>> rest officially in the hands of the Octavia PTL and the Octavia core
> >>> team.
> >>>
> >>> I will work with the help of the respective core teams to implement a
> >>> smooth
> >>> transition. My suggestion at this point is for any ML communication
> that
> >>> pertain LBaaS issues to include [octavia] tag on the email subject.
> >>>
> >>> Please do not hesitate to reach out for any questions and/or
> >>> clarifications.
> >>>
> >>> Cheers,
> >>> Armando
> >>>
> >>> [1] https://review.openstack.org/#/c/313056/
> >>
> >>
> >> Should we also move all neutron lbaas-tagged bugs to octavia in LP? And
> >> kill the
> >> ‘lbaas’ tag from doc/source/policies/bugs.rst?
> >
> >
> > Yes.  I added the lbaas bugs.rst tag removal to
> > https://review.openstack.org/#/c/404872/ already.  Can someone from
> Octavia
> > close and/or move-over any remaining lbaas bugs?  I only see three at
> > https://bugs.launchpad.net/ubuntu/+source/neutron-lbaas
> >
> > Thanks,
> >
> > -Brian
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (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] jobs shuffle to add IPv6 coverage

[Ben Nemec]

On 11/15/2016 10:41 AM, Gabriele Cerami wrote:

On 18 Oct, Gabriele Cerami wrote:

Hello,

after adding coverage in CI for HA IPv6 scenario here
https://review.openstack.org/363674 we wanted to add IPv6 testing on the
gates.
To not use any more resources the first suggestion to add IPv6 to the
gates was to make all HA jobs IPv6, move network isolation testing for
IPv4 on non-ha job, and test non-netiso environment on multinode.


This is still up for debate, another possibility is to test IPv6 just in
the updates jobs.


The updates job with ipv6 should be working now.  I've proposed 
https://review.openstack.org/405560 to get it back in the check queue as 
non-voting for now.


I do want to note that I've softened my position on this though.  I 
still think we need the updates job and that 3 jobs provides us the 
necessary test coverage (no net-iso, ipv4 net-iso, ipv6 net-iso), but I 
do recognize that we're far more likely to break ipv6 than the no 
net-iso case so if the updates job ends up blocked for some reason I'd 
be okay with the changes proposed here.





This is almost done here https://review.openstack.org/382515 with one
exception. Liberty HA IPv6 fails during ping test with the error:
503 Service unavailable.


This issue was solved during the summit


Moreover, swift memecache code in liberty is clearly not IPv6
compatible, it gives an error on the overcloud, not being able to get
host and port from a correctly formed IPv6 URL. To make it compatible
with IPv6 this should be backported https://review.openstack.org/258704


This still remains.


Before continuing the debugging I wanted to be sure that:
- this is an acceptable shuffle for the gates jobs
- we are really interested in testing liberty IPv6


I have another question to add to the mix. Do we care to test IPv6 with
SSL ? Our current certificate handling code is dealing only with IPv4
addresses, so if we need to test both, we'll have to add that part too.


Agree with Emilien that this is something we should do.  I believe I saw 
a patch up for the updates job to add this, which will be good to have. 
I would prefer to wait on adding features to either ipv6-based job until 
we have something voting on patches though.  Getting some sort of ipv6 
coverage in is higher priority in the short-term IMHO than getting all 
the features enabled there, and every feature we add is one more 
potential thing to block the ipv6 job becoming voting.


__
OpenStack Development Mailing 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][neutron-vpnaas] Finish test job transition to Ubuntu Xenial

[Andreas Jaeger]

On 12/01/2016 05:22 PM, Armando M. wrote:
> 
> 
> On 1 December 2016 at 07:45, Andreas Jaeger  > wrote:
> 
> On 11/15/2016 12:30 AM, Clark Boylan wrote:
> > [...]
> 
> Just a friendly reminder that this is still happening. We will be
> updating any jobs running on Trusty that should be running on
> Xenial on
> December 6th. I have seen a few projects jump on this and start
> making
> the necessary changes. Thank you for doing that!
> 
> 
> The rally team has been updating jobs and neutron-vpnaas does not
> work for them since xenial now uses strongswan instead of openswan.
> 
> They have disabled vpnaas now:
> https://review.openstack.org/#/c/403493/4
> 
> 
> vpnaas team, you will have to fix your setup so that your plugin
> works with Xenial! Would be great if you could do this before
> Tuesday - you might not be able to merge anything after the switch
> to Xenial,
> 
> 
> I did file bug [1]. FWIW, vpnaas on strongswan works fine in xenial [2],
> and if the rally teams feel like not losing vpnaas coverage, they could
> switch to strongswan. 
> 
> [1] https://bugs.launchpad.net/python-neutronclient/+bug/1645819
> [2] https://review.openstack.org/#/c/404369/

Thanks.

I expect that your change https://review.openstack.org/#/c/404367/ that
you abandoned basically is all that needs to be done for neutron-vpnaas
- together with the switch to xenial.

This might need some coordination: Change master jobs to xenial, then
merge 404367 or a variant of it,

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


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

Re: [openstack-dev] [keystone][devstack][rally][python-novaclient][magnum] switching to keystone v3 by default

[Andrey Kurilin]

On Thu, Dec 1, 2016 at 7:39 PM, Morgan Fainberg 
wrote:

> On Dec 1, 2016 8:25 AM, "Andrey Kurilin"  wrote:
> >
> > As I replied at IRC, please do not mix two separate issues!
> > Yes, we have several scenarios which are not support keystone v3 yet. It
> is an issue, but it is unrelated issue to described in the first mail.
> > We have a job which is configured with proper IDENTITY_API_VERSION flag
> and should be launched against Keystone v2, but there is only keystone v3
> and it is a real issue.
> >
> > On Thu, 1 Dec 2016 at 17:48, Lance Bragstad  wrote:
> >>
> >> FWIW - i'm seeing a common error in several of the rally failures [0]
> [1] [2] [3]. Dims also pointed out a few bugs in rally for keystone v3
> support [4].
> >>
> >> I checked with the folks in #openstack-containers to see if they were
> experiencing anymore fallout, but it looks like the magnum gate is under
> control [5]. We're currently in #openstack-keystone talking through options
> for the rally situation in case anyone feels like joining.
> >>
> >>
> >> [0] http://logs.openstack.org/87/404887/4/check/gate-rally-
> dsvm-neutron-existing-users-rally/ff60a83/console.html#_
> 2016-12-01_08_05_55_268772
> >> [1] http://logs.openstack.org/43/405143/3/check/gate-rally-
> dsvm-neutron-existing-users-rally/3ee975b/console.html#_
> 2016-12-01_08_39_02_618302
> >> [2] http://logs.openstack.org/83/394583/26/check/gate-rally-
> dsvm-cli/af28c0f/console.html#_2016-12-01_14_09_19_584427
> >> [3] http://logs.openstack.org/83/394583/26/check/gate-rally-
> dsvm-neutron-existing-users-rally/26cd009/console.html#_
> 2016-12-01_14_15_17_147016
> >> [4] https://bugs.launchpad.net/rally?field.searchtext=keystone+v3
> >> [5] http://eavesdrop.openstack.org/irclogs/%23openstack-containers/%
> 23openstack-containers.2016-12-01.log.html#t2016-12-01T14:57:00
> >>
> >> On Thu, Dec 1, 2016 at 6:39 AM, Spyros Trigazis 
> wrote:
> >>>
> >>> I think for magnum we are OK.
> >>>
> >>> This job [1] finished using keystone v3 [2]
> >>>
> >>> Spyros
> >>>
> >>> [1] http://logs.openstack.org/93/400593/9/check/gate-
> functional-dsvm-magnum-api/93e8c14/
> >>> [2] http://logs.openstack.org/93/400593/9/check/gate-
> functional-dsvm-magnum-api/93e8c14/logs/devstacklog.txt.
> gz#_2016-12-01_11_32_58_033
> >>>
> >>> On 1 December 2016 at 12:26, Davanum Srinivas 
> wrote:
> 
>  It has taken years to get here with a lot of work from many folks.
> 
>  -1 for Any revert!
> 
>  https://etherpad.openstack.org/p/v3-only-devstack
>  http://markmail.org/message/aqq7itdom36omnf6
>  https://review.openstack.org/#/q/status:merged+project:
> openstack-dev/devstack+branch:master+topic:bp/keystonev3
> 
>  Thanks,
>  Dims
> 
>  On Thu, Dec 1, 2016 at 5:38 AM, Andrey Kurilin 
> wrote:
>  > Hi folks!
>  >
>  > Today devstack team decided to switch to keystone v3 by default[0].
>  > Imo, it is important thing, but it was made in silent, so other
> project was
>  > unable to prepare to that change. Also, proposed way to select
> Keystone API
>  > version via devstack configuration doesn't work(IDENTITY_API_VERSION
>  > variable doesn't work [1] ).
>  >
>  > Switching to keystone v3 broke at least Rally and Magnum(based on
> comment to
>  > [0])  gates. Also, python-novaclient has two separate jobs for
> checking
>  > compatibility with keystone V2 and V3. One of these jobs became
> redundant.
>  >
>  > That is why I submitted a revert [2] .
>  >
>  > PS: Please, do not make such changes in silent!
>  >
>  > [0] - https://review.openstack.org/#/c/386183
>  > [1] -
>  > https://github.com/openstack-infra/project-config/blob/
> master/jenkins/jobs/rally.yaml#L70-L74
>  > [2] - https://review.openstack.org/405264
>  >
>  > --
>  > Best regards,
>  > Andrey Kurilin.
>  >
>  > 
> __
>  > OpenStack Development Mailing List (not for usage questions)
>  > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
>  > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  >
> 
> 
> 
>  --
>  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:
> 

Re: [openstack-dev] [nova][SR-IOV] update the SR-IOV meeting to bi-weekly

[Beliveau, Ludovic]

Agreed.  Also considering that the amount of known bugs is under control 
(compared to previous cycle), I'm in favor of going to bi-weekly meetings.

/ludovic

-Original Message-
From: Stephen Finucane [mailto:sfinu...@redhat.com] 
Sent: December-01-16 12:38 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova][SR-IOV] update the SR-IOV meeting to 
bi-weekly

On Thu, 2016-12-01 at 14:48 +, Moshe Levi wrote:
> Hi all,
> 
> I would like to update the frequency of the SR-IOV meeting to be  bi- 
> weekly [1].
> Does anyone see value in keeping it as weekly meeting?
> 
> [1] - https://review.openstack.org/#/c/405415/

Seeing as we don't have any specs during this short cycle, I think moving back 
to bi-weekly is a good idea. We can reassess come February and the Pike cycle.

Stephen

__
OpenStack Development Mailing List (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] [keystone][devstack][rally][python-novaclient][magnum] switching to keystone v3 by default

[Morgan Fainberg]

On Dec 1, 2016 8:25 AM, "Andrey Kurilin"  wrote:
>
> As I replied at IRC, please do not mix two separate issues!
> Yes, we have several scenarios which are not support keystone v3 yet. It
is an issue, but it is unrelated issue to described in the first mail.
> We have a job which is configured with proper IDENTITY_API_VERSION flag
and should be launched against Keystone v2, but there is only keystone v3
and it is a real issue.
>
> On Thu, 1 Dec 2016 at 17:48, Lance Bragstad  wrote:
>>
>> FWIW - i'm seeing a common error in several of the rally failures [0]
[1] [2] [3]. Dims also pointed out a few bugs in rally for keystone v3
support [4].
>>
>> I checked with the folks in #openstack-containers to see if they were
experiencing anymore fallout, but it looks like the magnum gate is under
control [5]. We're currently in #openstack-keystone talking through options
for the rally situation in case anyone feels like joining.
>>
>>
>> [0]
http://logs.openstack.org/87/404887/4/check/gate-rally-dsvm-neutron-existing-users-rally/ff60a83/console.html#_2016-12-01_08_05_55_268772
>> [1]
http://logs.openstack.org/43/405143/3/check/gate-rally-dsvm-neutron-existing-users-rally/3ee975b/console.html#_2016-12-01_08_39_02_618302
>> [2]
http://logs.openstack.org/83/394583/26/check/gate-rally-dsvm-cli/af28c0f/console.html#_2016-12-01_14_09_19_584427
>> [3]
http://logs.openstack.org/83/394583/26/check/gate-rally-dsvm-neutron-existing-users-rally/26cd009/console.html#_2016-12-01_14_15_17_147016
>> [4] https://bugs.launchpad.net/rally?field.searchtext=keystone+v3
>> [5]
http://eavesdrop.openstack.org/irclogs/%23openstack-containers/%23openstack-containers.2016-12-01.log.html#t2016-12-01T14:57:00
>>
>> On Thu, Dec 1, 2016 at 6:39 AM, Spyros Trigazis 
wrote:
>>>
>>> I think for magnum we are OK.
>>>
>>> This job [1] finished using keystone v3 [2]
>>>
>>> Spyros
>>>
>>> [1]
http://logs.openstack.org/93/400593/9/check/gate-functional-dsvm-magnum-api/93e8c14/
>>> [2]
http://logs.openstack.org/93/400593/9/check/gate-functional-dsvm-magnum-api/93e8c14/logs/devstacklog.txt.gz#_2016-12-01_11_32_58_033
>>>
>>> On 1 December 2016 at 12:26, Davanum Srinivas  wrote:

 It has taken years to get here with a lot of work from many folks.

 -1 for Any revert!

 https://etherpad.openstack.org/p/v3-only-devstack
 http://markmail.org/message/aqq7itdom36omnf6

https://review.openstack.org/#/q/status:merged+project:openstack-dev/devstack+branch:master+topic:bp/keystonev3

 Thanks,
 Dims

 On Thu, Dec 1, 2016 at 5:38 AM, Andrey Kurilin 
wrote:
 > Hi folks!
 >
 > Today devstack team decided to switch to keystone v3 by default[0].
 > Imo, it is important thing, but it was made in silent, so other
project was
 > unable to prepare to that change. Also, proposed way to select
Keystone API
 > version via devstack configuration doesn't work(IDENTITY_API_VERSION
 > variable doesn't work [1] ).
 >
 > Switching to keystone v3 broke at least Rally and Magnum(based on
comment to
 > [0])  gates. Also, python-novaclient has two separate jobs for
checking
 > compatibility with keystone V2 and V3. One of these jobs became
redundant.
 >
 > That is why I submitted a revert [2] .
 >
 > PS: Please, do not make such changes in silent!
 >
 > [0] - https://review.openstack.org/#/c/386183
 > [1] -
 >
https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/rally.yaml#L70-L74
 > [2] - https://review.openstack.org/405264
 >
 > --
 > Best regards,
 > Andrey Kurilin.
 >
 >
__
 > OpenStack Development Mailing List (not for usage questions)
 > Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 >



 --
 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
>>>
>>
>>
__
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 

Re: [openstack-dev] [nova][SR-IOV] update the SR-IOV meeting to bi-weekly

[Stephen Finucane]

On Thu, 2016-12-01 at 14:48 +, Moshe Levi wrote:
> Hi all,
> 
> I would like to update the frequency of the SR-IOV meeting to be  bi-
> weekly [1].
> Does anyone see value in keeping it as weekly meeting?
> 
> [1] - https://review.openstack.org/#/c/405415/

Seeing as we don't have any specs during this short cycle, I think
moving back to bi-weekly is a good idea. We can reassess come February
and the Pike cycle.

Stephen

__
OpenStack Development Mailing 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][monasca] Can we uncap python-kafka ?

[Keen, Joe]

On 12/1/16, 9:44 AM, "Julien Danjou"  wrote:

>On Thu, Dec 01 2016, Keen, Joe wrote:
>
>Hi Joe,
>
>[…]
>
>> The message context wrapped around every message is extra overhead we
>> don¹t want.  
>> There¹s no support for batch sends to Kafka.
>> There¹s no support for keyed producers.
>> The forced auto_commit on consumers isn¹t something we can tolerate.
>> There is no auto balance of multiple consumers in the same consumer
>>group
>> on a topic.
>
>This sounds like interesting features and optimizations to add to
>oslo.messaging. Did you already send patches or spec to oslo.messaging
>to improve that? What there the issues you encountered to fix those
>problems / add those new abilities?
>
>-- 
>Julien Danjou
>// Free Software hacker
>// https://julien.danjou.info


I haven’t submitted any patches to oslo.messaging.  When I wrote the Kafka
interfaces for Monasca I didn’t know oslo.messaging existed.  Since then I
just haven’t had the time to try merging the two approaches into one
library.  If anyone else is interested in what we’ve done I can help with
that.

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

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

[Chris Dent]

Greetings OpenStack community,

Some good attendance and discussion this week. For many months the API-WG has been 
claiming that it would try to review any commit that contained an 'APIImpact' tag. This 
has proven impractical so instead of maintaining a task on our list that we know we're 
not going to do, we've decided to make it official that we aren't doing that anymore (see 
below about "Highlighting your API impacting issues"). Though APIImpact is 
still meaningful within the projects that use it, it should no longer be considered a bat 
signal for the API-WG.

We also discussed the continued ambiguity of when to use a 404 or a 400 
response code when making an incorrect reference to a resource in the body of a 
request. A cinder review[4] started the conversation and the conversation 
(resolving to use 400) led to a proposed adjustment to the guidelines[5].

# New guidelines

No newly merged guidelines this week.

# API guidelines that have been recently merged

Nothing in the recent past.

# API guidelines proposed for freeze

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

* Add the operator for "not in" to the filter guideline
  https://review.openstack.org/#/c/399131/

# Guidelines currently under review [3]

Both of these are going to require quite a bit of input from a wide audience. 
Both have been tried a few times in the past.

* Define pagination guidelines
  https://review.openstack.org/#/c/390973/
  This one is a bit stuck, any volunteers to pick it up?

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

# Highlighting your API impacting issues

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

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

## References

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

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

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

Re: [openstack-dev] [oslo][monasca] Can we uncap python-kafka ?

[Joshua Harlow]

Reopen them?

If they weren't fixed, then seems like the right thing to try to do, and
rinse and repeat until actually fixed :-P

Keen, Joe wrote:
> We reported
> the bugs we found to the kafka-python project but they were closed once
> they released a new version.

__
OpenStack Development Mailing 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][monasca] Can we uncap python-kafka ?

[Joshua Harlow]

Damn, that's supposed to say co-installability...

Lol,

-Josh

Joshua Harlow wrote:

Keen, Joe wrote:

I¹ll look into testing the newest version of kafka-python and see if it
meets our needs. If it still isn¹t stable and performant enough what are
the available options?


Fix the kafka-python library or fix monasca; those seem to be the
options to me :)

I'd also not like to block the rest of the world (from using newer
versions of kafka-python) during this as well. But then this may
diverge/expand into a discussion we had a few summits ago, about getting
rid of co-instability...

-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-dev] [Openstack] OpenStack Ocata B1 for Ubuntu 16.04 LTS

[Corey Bryant]

Hi All,


The Ubuntu OpenStack team is pleased to announce the general availability
of the OpenStack Ocata B1 milestone in Ubuntu 16.04 LTS via the Ubuntu
Cloud Archive.


Ubuntu 16.04 LTS




You can enable the Ubuntu Cloud Archive pocket for OpenStack Ocata on
Ubuntu 16.04 installations by running the following commands:


echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu
xenial-updates/ocata main" | sudo tee /etc/apt/sources.list.d/ocata-uca.list

sudo apt install -y ubuntu-cloud-keyring

sudo apt update


The Ubuntu Cloud Archive for Ocata includes updates for: cinder, glance,
horizon, keystone, manila, networking-ovn, neutron, neutron-fwaas,
neutron-lbaas, neutron-dynamic-routing, nova, openstack-trove, and swift
(2.11.0).


You can check out the full list of packages and versions at [0].


Branch Package Builds

---


If you want to try out the latest updates to stable branches, we are
delivering continuously integrated packages on each upstream commit via the
following PPA’s:


   sudo add-apt-repository ppa:openstack-ubuntu-testing/liberty

   sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka

   sudo add-apt-repository ppa:openstack-ubuntu-testing/newton

   sudo add-apt-repository ppa:openstack-ubuntu-testing/ocata


bear in mind these are built per-commit-ish (30 min checks for new commits
at the moment) so ymmv from time-to-time.


Reporting bugs

-


Any issues please report bugs using the 'ubuntu-bug' tool:


  sudo ubuntu-bug nova-conductor


this will ensure that bugs get logged in the right place in Launchpad.


Thanks and have fun!


Regards,

Corey

(on behalf of the Ubuntu OpenStack team)


[0]
http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/ocata_versions.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][monasca] Can we uncap python-kafka ?

[Keen, Joe]

On 12/1/16, 9:41 AM, "Joshua Harlow"  wrote:

>Keen, Joe wrote:
>> I¹ll look into testing the newest version of kafka-python and see if it
>> meets our needs.  If it still isn¹t stable and performant enough what
>>are
>> the available options?
>
>Fix the kafka-python library or fix monasca; those seem to be the
>options to me :)
>
>I'd also not like to block the rest of the world (from using newer
>versions of kafka-python) during this as well. But then this may
>diverge/expand into a discussion we had a few summits ago, about getting
>rid of co-instability...
>
>-Josh

Unfortunately there’s nothing wrong on the Monasca side so far as we know.
 We test new versions of the kafka-python library outside of Monasca
before we bother to try integrating a new version.  Since 1.0 the
kafka-python library has suffered from crashes and memory leaks severe
enough that we’ve never attempted using it in Monasca itself.  We reported
the bugs we found to the kafka-python project but they were closed once
they released a new version.

__
OpenStack Development Mailing 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][monasca] Can we uncap python-kafka ?

[Julien Danjou]

On Thu, Dec 01 2016, Keen, Joe wrote:

Hi Joe,

[…]

> The message context wrapped around every message is extra overhead we
> don¹t want.  
> There¹s no support for batch sends to Kafka.
> There¹s no support for keyed producers.
> The forced auto_commit on consumers isn¹t something we can tolerate.
> There is no auto balance of multiple consumers in the same consumer group
> on a topic.

This sounds like interesting features and optimizations to add to
oslo.messaging. Did you already send patches or spec to oslo.messaging
to improve that? What there the issues you encountered to fix those
problems / add those new abilities?

-- 
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] [oslo][monasca] Can we uncap python-kafka ?

[Joshua Harlow]

Keen, Joe wrote:

I¹ll look into testing the newest version of kafka-python and see if it
meets our needs.  If it still isn¹t stable and performant enough what are
the available options?


Fix the kafka-python library or fix monasca; those seem to be the 
options to me :)


I'd also not like to block the rest of the world (from using newer 
versions of kafka-python) during this as well. But then this may 
diverge/expand into a discussion we had a few summits ago, about getting 
rid of co-instability...


-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

Re: [openstack-dev] [All][neutron-vpnaas] Finish test job transition to Ubuntu Xenial

[Ihar Hrachyshka]

Armando M.  wrote:



I did file bug [1]. FWIW, vpnaas on strongswan works fine in xenial [2],  
and if the rally teams feel like not losing vpnaas coverage, they could  
switch to strongswan.


[1] https://bugs.launchpad.net/python-neutronclient/+bug/1645819
[2] https://review.openstack.org/#/c/404369/


There is also https://bugs.launchpad.net/neutron/+bug/1645516 reported for  
vpnaas itself. I believe that’s the right place to fix it, because the  
client bug is already fixed, and not in a manner that would help rally.


Ihar

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

Re: [openstack-dev] [keystone][devstack][rally][python-novaclient][magnum] switching to keystone v3 by default

[Andrey Kurilin]

As I replied at IRC, please do not mix two separate issues!
Yes, we have several scenarios which are not support keystone v3 yet. It is
an issue, but it is unrelated issue to described in the first mail.
We have a job which is configured with proper IDENTITY_API_VERSION flag and
should be launched against Keystone v2, but there is only keystone v3 and
it is a real issue.

On Thu, 1 Dec 2016 at 17:48, Lance Bragstad  wrote:

> FWIW - i'm seeing a common error in several of the rally failures [0] [1]
> [2] [3]. Dims also pointed out a few bugs in rally for keystone v3 support
> [4].
>
> I checked with the folks in #openstack-containers to see if they were
> experiencing anymore fallout, but it looks like the magnum gate is under
> control [5]. We're currently in #openstack-keystone talking through options
> for the rally situation in case anyone feels like joining.
>
>
> [0]
> http://logs.openstack.org/87/404887/4/check/gate-rally-dsvm-neutron-existing-users-rally/ff60a83/console.html#_2016-12-01_08_05_55_268772
> [1]
> http://logs.openstack.org/43/405143/3/check/gate-rally-dsvm-neutron-existing-users-rally/3ee975b/console.html#_2016-12-01_08_39_02_618302
> [2]
> http://logs.openstack.org/83/394583/26/check/gate-rally-dsvm-cli/af28c0f/console.html#_2016-12-01_14_09_19_584427
> [3]
> http://logs.openstack.org/83/394583/26/check/gate-rally-dsvm-neutron-existing-users-rally/26cd009/console.html#_2016-12-01_14_15_17_147016
> [4] https://bugs.launchpad.net/rally?field.searchtext=keystone+v3
> [5]
> http://eavesdrop.openstack.org/irclogs/%23openstack-containers/%23openstack-containers.2016-12-01.log.html#t2016-12-01T14:57:00
>
> On Thu, Dec 1, 2016 at 6:39 AM, Spyros Trigazis 
> wrote:
>
> I think for magnum we are OK.
>
> This job [1] finished using keystone v3 [2]
>
> Spyros
>
> [1]
> http://logs.openstack.org/93/400593/9/check/gate-functional-dsvm-magnum-api/93e8c14/
> [2]
> http://logs.openstack.org/93/400593/9/check/gate-functional-dsvm-magnum-api/93e8c14/logs/devstacklog.txt.gz#_2016-12-01_11_32_58_033
>
> On 1 December 2016 at 12:26, Davanum Srinivas  wrote:
>
> It has taken years to get here with a lot of work from many folks.
>
> -1 for Any revert!
>
> https://etherpad.openstack.org/p/v3-only-devstack
> http://markmail.org/message/aqq7itdom36omnf6
>
> https://review.openstack.org/#/q/status:merged+project:openstack-dev/devstack+branch:master+topic:bp/keystonev3
>
> Thanks,
> Dims
>
> On Thu, Dec 1, 2016 at 5:38 AM, Andrey Kurilin 
> wrote:
> > Hi folks!
> >
> > Today devstack team decided to switch to keystone v3 by default[0].
> > Imo, it is important thing, but it was made in silent, so other project
> was
> > unable to prepare to that change. Also, proposed way to select Keystone
> API
> > version via devstack configuration doesn't work(IDENTITY_API_VERSION
> > variable doesn't work [1] ).
> >
> > Switching to keystone v3 broke at least Rally and Magnum(based on
> comment to
> > [0])  gates. Also, python-novaclient has two separate jobs for checking
> > compatibility with keystone V2 and V3. One of these jobs became
> redundant.
> >
> > That is why I submitted a revert [2] .
> >
> > PS: Please, do not make such changes in silent!
> >
> > [0] - https://review.openstack.org/#/c/386183
> > [1] -
> >
> https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/rally.yaml#L70-L74
> > [2] - https://review.openstack.org/405264
> >
> > --
> > Best regards,
> > Andrey Kurilin.
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> 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
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [oslo][monasca] Can we uncap python-kafka ?

[Keen, Joe]

On 12/1/16, 3:11 AM, "Julien Danjou"  wrote:

>On Thu, Dec 01 2016, Mehdi Abaakouk wrote:
>
>> I'm aware of all of that, oslo.messaging patch for the new version is
>> ready since 8 months now. And we are still blocked... capping libraries,
>> whatever the reason, is very annoying and just freezes people work.
>>
>> From the API pov python-kafka haven't break anything, the API is still
>> here and documented (and deprecated). What monasca raises is performance
>> issue due to how their uses the library, and on absumption on how it
>>works
>> internally. Blocking all projects for that looks not fair to me.
>>
>> As nadya said, now, we have users that that prefers using an unmerged
>> patch and the new lib instead of using upstream supported
>> version with the old lib. This is not an acceptable situation to me but
>>that's
>> just my thought.
>>
>> Where is the solution to allow oslo.messaging works blocked since 8
>> month to continue ?
>
>+1
>
>And if Monasca is using messaging, I wonder why they don't rely on
>oslo.messaging, which would also solve this entire problem in a snap.


Julien, I looked at the current oslo.messaging Kafka driver and
unfortunately I don¹t think it meets our needs.  There are several major
pieces that are a problem.

The message context wrapped around every message is extra overhead we
don¹t want.  
There¹s no support for batch sends to Kafka.
There¹s no support for keyed producers.
The forced auto_commit on consumers isn¹t something we can tolerate.
There is no auto balance of multiple consumers in the same consumer group
on a topic.

The current Kafka driver we use in monasca-common has all these features.
Without them we can¹t meet the durability and performance levels we need.

What sort of performance levels is oslo.messaging tested at?

I¹ll look into testing the newest version of kafka-python and see if it
meets our needs.  If it still isn¹t stable and performant enough what are
the available options?


__
OpenStack Development Mailing 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][neutron-vpnaas] Finish test job transition to Ubuntu Xenial

[Armando M.]

On 1 December 2016 at 07:45, Andreas Jaeger  wrote:

> On 11/15/2016 12:30 AM, Clark Boylan wrote:
> > [...]
>
>> Just a friendly reminder that this is still happening. We will be
>> updating any jobs running on Trusty that should be running on Xenial on
>> December 6th. I have seen a few projects jump on this and start making
>> the necessary changes. Thank you for doing that!
>>
>
> The rally team has been updating jobs and neutron-vpnaas does not work for
> them since xenial now uses strongswan instead of openswan.
>
> They have disabled vpnaas now:
> https://review.openstack.org/#/c/403493/4
>
> vpnaas team, you will have to fix your setup so that your plugin works
> with Xenial! Would be great if you could do this before Tuesday - you might
> not be able to merge anything after the switch to Xenial,
>
>
I did file bug [1]. FWIW, vpnaas on strongswan works fine in xenial [2],
and if the rally teams feel like not losing vpnaas coverage, they could
switch to strongswan.

[1] https://bugs.launchpad.net/python-neutronclient/+bug/1645819
[2] https://review.openstack.org/#/c/404369/


> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] [tripleo-quickstart] Tripleo-Quickstart root privileges

[Lars Kellogg-Stedman]

On Thu, Dec 01, 2016 at 09:03:30AM -0500, John Trowbridge wrote:
> 1. Doing tasks as root on the virthost makes clean up trickier. With the
> current model, deleting the non-root quickstart user cleans up almost
> everything. By keeping all of the root privilege tasks in the provision
> and environment roles, it is much easier to reason about the few things
> that do not get cleaned up when deleting the quickstart user. If we
> start allowing root privilege tasks in the libvirt role, this will be
> harder.
> 
> 2. Theoretically, (I have not actually heard anyone actually doing
>this), someone could set up a virthost for use by quickstart, and
>then...

The particular use case that inspired the current architecture was the
situation in which people did not want a random script from the
internet running with privileges on their system.

The existing model means that you can manually configure a host for
use by quickstart (installing libvirt, creating the necessary bridges
devices and permissions, etc), and then use quickstart exclusively as
a non-root user.

This is really nice for a number of reasons.  For example, I often
have multiple quickstart-provisioned environments on my virt host,
each associated with a particular user.  Being able to run everything
as a non-root user means that it's easy to keep these separate, and
that I won't accidentally break one environment because of a typo or
something (because my "master tripleo" user is not able to modify the
environment of my "rdo release" user).

-- 
Lars Kellogg-Stedman  | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack  | http://blog.oddbit.com/



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] [infra]help on the description update in github repository

[Jeremy Stanley]

On 2016-12-01 07:14:58 + (+), joehuang wrote:
> The short project description of Tricircle is: "Tricircle is to
> provide networking automation across Neutron." in
> http://git.openstack.org/cgit/openstack/tricircle/,
> the official repository.
> 
> But the description in the mirrored github
> repository(https://github.com/openstack/tricircle/) below the code
> tab is still "Tricircle is a project for OpenStack cascading
> solution. ",  it's old and obsolete description.

Our automation which maintains the github.com mirror configuration
doesn't currently update repository descriptions, because it
maintains insufficient state and attempting to query all our 1.5k+
repos there overruns their API throttling limits very quickly.

> I contacted github help desk, they said they have no right to
> update it, only the guy from OpenStack who has update(or write)
> right can update it manually.

Correct, only the organization admins for the repo in question can
update its description. For the "openstack" organization that's
basically the Infra team's root sysadmins.

> So would someone help to update the Tricircle description in
> github, Tricircle is one OpenStack official project now, it's
> better to keep the description consistent.

I have done this just now, as requested.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [neutron][octavia] Neutron LBaaS governance change and Octavia to the big tent

[Michael Johnson]

There are a lot more than just those three (which are under packaging
and not neutron btw).

I will start working on moving/scrubbing the bugs today.

Michael

On Thu, Dec 1, 2016 at 7:30 AM, Brian Haley  wrote:
> On 12/01/2016 08:54 AM, Ihar Hrachyshka wrote:
>>
>> Armando M.  wrote:
>>
>>> Hi folks,
>>>
>>> A few hours ago a governance change [1] has been approved by TC members.
>>> This
>>> means that from now on, the efforts for Load Balancing as a Service
>>> efforts
>>> rest officially in the hands of the Octavia PTL and the Octavia core
>>> team.
>>>
>>> I will work with the help of the respective core teams to implement a
>>> smooth
>>> transition. My suggestion at this point is for any ML communication that
>>> pertain LBaaS issues to include [octavia] tag on the email subject.
>>>
>>> Please do not hesitate to reach out for any questions and/or
>>> clarifications.
>>>
>>> Cheers,
>>> Armando
>>>
>>> [1] https://review.openstack.org/#/c/313056/
>>
>>
>> Should we also move all neutron lbaas-tagged bugs to octavia in LP? And
>> kill the
>> ‘lbaas’ tag from doc/source/policies/bugs.rst?
>
>
> Yes.  I added the lbaas bugs.rst tag removal to
> https://review.openstack.org/#/c/404872/ already.  Can someone from Octavia
> close and/or move-over any remaining lbaas bugs?  I only see three at
> https://bugs.launchpad.net/ubuntu/+source/neutron-lbaas
>
> Thanks,
>
> -Brian
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [keystone][devstack][rally][python-novaclient][magnum] switching to keystone v3 by default

[Lance Bragstad]

FWIW - i'm seeing a common error in several of the rally failures [0] [1]
[2] [3]. Dims also pointed out a few bugs in rally for keystone v3 support
[4].

I checked with the folks in #openstack-containers to see if they were
experiencing anymore fallout, but it looks like the magnum gate is under
control [5]. We're currently in #openstack-keystone talking through options
for the rally situation in case anyone feels like joining.


[0]
http://logs.openstack.org/87/404887/4/check/gate-rally-dsvm-neutron-existing-users-rally/ff60a83/console.html#_2016-12-01_08_05_55_268772
[1]
http://logs.openstack.org/43/405143/3/check/gate-rally-dsvm-neutron-existing-users-rally/3ee975b/console.html#_2016-12-01_08_39_02_618302
[2]
http://logs.openstack.org/83/394583/26/check/gate-rally-dsvm-cli/af28c0f/console.html#_2016-12-01_14_09_19_584427
[3]
http://logs.openstack.org/83/394583/26/check/gate-rally-dsvm-neutron-existing-users-rally/26cd009/console.html#_2016-12-01_14_15_17_147016
[4] https://bugs.launchpad.net/rally?field.searchtext=keystone+v3
[5]
http://eavesdrop.openstack.org/irclogs/%23openstack-containers/%23openstack-containers.2016-12-01.log.html#t2016-12-01T14:57:00

On Thu, Dec 1, 2016 at 6:39 AM, Spyros Trigazis  wrote:

> I think for magnum we are OK.
>
> This job [1] finished using keystone v3 [2]
>
> Spyros
>
> [1] http://logs.openstack.org/93/400593/9/check/gate-
> functional-dsvm-magnum-api/93e8c14/
> [2] http://logs.openstack.org/93/400593/9/check/gate-
> functional-dsvm-magnum-api/93e8c14/logs/devstacklog.txt.
> gz#_2016-12-01_11_32_58_033
>
> On 1 December 2016 at 12:26, Davanum Srinivas  wrote:
>
>> It has taken years to get here with a lot of work from many folks.
>>
>> -1 for Any revert!
>>
>> https://etherpad.openstack.org/p/v3-only-devstack
>> http://markmail.org/message/aqq7itdom36omnf6
>> https://review.openstack.org/#/q/status:merged+project:opens
>> tack-dev/devstack+branch:master+topic:bp/keystonev3
>>
>> Thanks,
>> Dims
>>
>> On Thu, Dec 1, 2016 at 5:38 AM, Andrey Kurilin 
>> wrote:
>> > Hi folks!
>> >
>> > Today devstack team decided to switch to keystone v3 by default[0].
>> > Imo, it is important thing, but it was made in silent, so other project
>> was
>> > unable to prepare to that change. Also, proposed way to select Keystone
>> API
>> > version via devstack configuration doesn't work(IDENTITY_API_VERSION
>> > variable doesn't work [1] ).
>> >
>> > Switching to keystone v3 broke at least Rally and Magnum(based on
>> comment to
>> > [0])  gates. Also, python-novaclient has two separate jobs for checking
>> > compatibility with keystone V2 and V3. One of these jobs became
>> redundant.
>> >
>> > That is why I submitted a revert [2] .
>> >
>> > PS: Please, do not make such changes in silent!
>> >
>> > [0] - https://review.openstack.org/#/c/386183
>> > [1] -
>> > https://github.com/openstack-infra/project-config/blob/maste
>> r/jenkins/jobs/rally.yaml#L70-L74
>> > [2] - https://review.openstack.org/405264
>> >
>> > --
>> > Best regards,
>> > Andrey Kurilin.
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>>
>> --
>> Davanum Srinivas :: https://twitter.com/dims
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [All][neutron-vpnaas] Finish test job transition to Ubuntu Xenial

[Andreas Jaeger]

On 11/15/2016 12:30 AM, Clark Boylan wrote:
> [...]

Just a friendly reminder that this is still happening. We will be
updating any jobs running on Trusty that should be running on Xenial on
December 6th. I have seen a few projects jump on this and start making
the necessary changes. Thank you for doing that!


The rally team has been updating jobs and neutron-vpnaas does not work 
for them since xenial now uses strongswan instead of openswan.


They have disabled vpnaas now:
https://review.openstack.org/#/c/403493/4

vpnaas team, you will have to fix your setup so that your plugin works 
with Xenial! Would be great if you could do this before Tuesday - you 
might not be able to merge anything after the switch to Xenial,


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


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

Re: [openstack-dev] [kolla] propose to remove COPY_ONCE feature

[Michał Jastrzębski]

K8s shouldn't matter as configmaps are the thing out there, not really
kolla-config. Configmap will copy the file where it needs to be
copied, so k8s doesn't care that much which is it. Also, having
copy-once with this all "ephemeral" "die and restart" pod structure is
volatile at least.

On 1 December 2016 at 08:09, Steven Dake (stdake)  wrote:
> Jeffrey,
>
>
>
> Can’t post inline (outlook bug).
>
>
>
> kolla-kubernetes has no use-case for COPY_ALWAYS.
>
>
>
> The kolla-kubernetes deliverable uses a construct called EmptyDir to store
> configuration files.
>
>
>
> There is no way to hand-modify the configuration files in EmptyDir that I am
> aware of nor was any of the core team aware of during the review processes
> that have been taking place in the helm reviews.
>
>
>
> Therefore, kolla-kubernetes has standardized on COPY_ONCE for immutability
> since hand-modification of config files is an impossibility.
>
>
>
> Hope that clears things up.
>
>
>
> Regards
>
> -steve
>
>
>
> From: Jeffrey Zhang 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Thursday, December 1, 2016 at 5:53 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [kolla] propose to remove COPY_ONCE feature
>
>
>
> @sdake
>
> we can keep COPY_ONCE and COPY_ALWAY in docker images. But in
>
> kolla-ansible side, only implement COPY_ALWAY.
>
>
>
> And does kolla-k8s will only implement COPY_ONCE?
>
>
>
> @Gerard
>
> COPY_ALWAYS only affect the configuration file, like /etc/nova/nova.conf.
>
> others are still immutable.
>
>
>
> @Paul
>
> For the end-user, either COPY_ONCE or COPY_ALWAYS is transparent. When he
>
> running kolla-ansible, there is no big difference.
>
>
>
>
>
> On Thu, Dec 1, 2016 at 6:29 PM, Paul Bourke  wrote:
>
> While I would be interested to know how many people actually do use
> COPY_ONCE, I think if I was in charge of a production deployment I would use
> COPY_ONCE.
>
>
>
> On 01/12/16 02:27, Jeffrey Zhang wrote:
>
> Kolla has a config_strategy option during deployment. it supports
> COPY_ONCE and
> COPY_ALWAYS.  which means whether copy the configuration files defined in
> config.json again during starting containers.
>
> COPY_ALWAYS: copy all configuration files always during every start (
> default
>  value now )
> COPY_ONCE: copy only once for the first start, then it
>won't copy even the configuration is changed
>
> COPY_ALWAYS is more common for most users. change configuration, then
> restart
> containers and it works. but COPY_ONCE is not. after changing the
> configuration,
> should remove the container and start it again.
>
> for COPY_ONCE, the pro is keeping immutability of the container.  the con is
> making thing difficult. no matter for kolla code or end-user.
>
> I am curiosity does end-user really care about the immutability cause by
> configuration file? how many user really need such a feature?
>
> So I propose to remove COPY_ONCE.
>
> any idea is welcome ;)
>
> --
> 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

[openstack-dev] 3rd party CI - tempest config override changes

[Sean Dague]

Yesterday we merged - https://review.openstack.org/#/c/293954/ - which
was long standing work to get Tempest to be configured explicitly in
it's *very late* phase in devstack.

This was needed by projects that have devstack plugins that need to do
something once the whole cloud is up and running in post-extra, but have
to guaruntee they are fully completed doing that before Tempest
configuration runs. Previously nothing was guarunteeing that, so there
were certain situations where a devstack plugin couldn't build a working
setup for a new project.

What was missed, was not realizing that a few 3rd party CI systems were
using the post-extra config file merge to tweak tempest config before
running. And we didn't (yet) have a way to do this at the test-config phase.

A new patch to fix that is here -
https://review.openstack.org/#/c/405446/ - we'll make sure it is merged
by the EOD.

Users of this should just change their local.conf to use test-config
instead of post-extra if they want to change TEMPEST_CONF file after
it's been configured.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [neutron][octavia] Neutron LBaaS governance change and Octavia to the big tent

[Brian Haley]

On 12/01/2016 08:54 AM, Ihar Hrachyshka wrote:

Armando M.  wrote:


Hi folks,

A few hours ago a governance change [1] has been approved by TC members. This
means that from now on, the efforts for Load Balancing as a Service efforts
rest officially in the hands of the Octavia PTL and the Octavia core team.

I will work with the help of the respective core teams to implement a smooth
transition. My suggestion at this point is for any ML communication that
pertain LBaaS issues to include [octavia] tag on the email subject.

Please do not hesitate to reach out for any questions and/or clarifications.

Cheers,
Armando

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


Should we also move all neutron lbaas-tagged bugs to octavia in LP? And kill the
‘lbaas’ tag from doc/source/policies/bugs.rst?


Yes.  I added the lbaas bugs.rst tag removal to
https://review.openstack.org/#/c/404872/ already.  Can someone from Octavia 
close and/or move-over any remaining lbaas bugs?  I only see three at

https://bugs.launchpad.net/ubuntu/+source/neutron-lbaas

Thanks,

-Brian

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

[openstack-dev] [nova][SR-IOV] update the SR-IOV meeting to bi-weekly

[Moshe Levi]

Hi all,

I would like to update the frequency of the SR-IOV meeting to be  bi-weekly [1].
Does anyone see value in keeping it as weekly meeting?

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

Thanks, 
Moshe Levi



__
OpenStack Development Mailing 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] [ALU] [vitrage] datasource driver returns entities only?

[Yujun Zhang]

Another question, how do we describe an entity from *another* datasource in
static datasource config?

In the test resources of static_physical datasource, it seems to be
referred as following. Does it means that it will be `nova.host` to find
the matched resource? If so, how will `nova.host` identify the resource, by
name or by id?

relationships:
  - type: nova.host
name: host-2
id: 2
relation_type: attached


On Thu, Dec 1, 2016 at 9:50 PM Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:

> Hi Yujun,
>
>
>
> Get_all does returns a list of entities to be sent.
>
>
>
> Each event that is sent from the driver to the processor contains also all
> the details of the neighbors that it connects to.
>
> For example, the event and data that we receive from nova about an
> instance also contains the host (compute) that it sits on, and that is how
> we decide to connect it to the correct host.
>
>
>
> I think it is ok that the event of static (from driver to the processor)
> will contain for each entity it neighbors that it is supposed to be
> connected to.
>
>
>
> BR,
>
> Alexey
>
>
>
> *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> *Sent:* Thursday, December 01, 2016 3:20 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [ALU] [openstack-dev] [vitrage] datasource driver returns
> entities only?
>
>
>
> During the implementation of static datasource driver[1], I got a question
> on the return format of `get_all` method.
>
>
>
> If I understand correctly, it should return a list of entities to be sent
> to the queue. Does it infer that the relationship should be embedded in
> entity, just like the legacy static_physical datasource?
>
>
>
> Suppose a link between two switches are created, how should we emit this
> change in `get_all` or `get_changes`?
>
>
>
> Currently I made a compromise by emitting the relationship as an update of
> the connected entity. This is not very elegant and it seems we are going
> back to the legacy static_physical datasource.
>
>
>
> [1] https://review.openstack.org/#/c/405354/
>
> --
>
> Yujun
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] propose to remove COPY_ONCE feature

[Steven Dake (stdake)]

Jeffrey,

Can’t post inline (outlook bug).

kolla-kubernetes has no use-case for COPY_ALWAYS.

The kolla-kubernetes deliverable uses a construct called EmptyDir to store 
configuration files.

There is no way to hand-modify the configuration files in EmptyDir that I am 
aware of nor was any of the core team aware of during the review processes that 
have been taking place in the helm reviews.

Therefore, kolla-kubernetes has standardized on COPY_ONCE for immutability 
since hand-modification of config files is an impossibility.

Hope that clears things up.

Regards
-steve

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

Date: Thursday, December 1, 2016 at 5:53 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [kolla] propose to remove COPY_ONCE feature

@sdake
we can keep COPY_ONCE and COPY_ALWAY in docker images. But in
kolla-ansible side, only implement COPY_ALWAY.

And does kolla-k8s will only implement COPY_ONCE?

@Gerard
COPY_ALWAYS only affect the configuration file, like /etc/nova/nova.conf.
others are still immutable.

@Paul
For the end-user, either COPY_ONCE or COPY_ALWAYS is transparent. When he
running kolla-ansible, there is no big difference.


On Thu, Dec 1, 2016 at 6:29 PM, Paul Bourke 
> wrote:
While I would be interested to know how many people actually do use COPY_ONCE, 
I think if I was in charge of a production deployment I would use COPY_ONCE.


On 01/12/16 02:27, Jeffrey Zhang wrote:
Kolla has a config_strategy option during deployment. it supports
COPY_ONCE and
COPY_ALWAYS.  which means whether copy the configuration files defined in
config.json again during starting containers.

COPY_ALWAYS: copy all configuration files always during every start (
default
 value now )
COPY_ONCE: copy only once for the first start, then it
   won't copy even the configuration is changed

COPY_ALWAYS is more common for most users. change configuration, then
restart
containers and it works. but COPY_ONCE is not. after changing the
configuration,
should remove the container and start it again.

for COPY_ONCE, the pro is keeping immutability of the container.  the con is
making thing difficult. no matter for kolla code or end-user.

I am curiosity does end-user really care about the immutability cause by
configuration file? how many user really need such a feature?

So I propose to remove COPY_ONCE.

any idea is welcome ;)

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

Re: [openstack-dev] [tripleo] [tripleo-quickstart] Tripleo-Quickstart root privileges

[John Trowbridge]

On 11/22/2016 03:49 PM, Gabriele Cerami wrote:
> On 22 Nov, Yolanda Robla Mota wrote:
>> Hi all
>> I wanted to start a thread about the current privileges model for TripleO 
>> quickstart.
>> Currently there is the assumption that quickstart does not need root 
>> privileges after the environment and provision roles. However, this 
>> assumption cannot be valid for several use cases.
>> In particular, I have the need of creating working directories outside the 
>> home directory of the user running quickstart. This can be useful on 
>> environments where /home partition is small and cannot be modified (so there 
>> is not enough disk space to host TripleO quickstart artifacts there).
>> This is the change i'm working on for that use case: 
>> https://review.openstack.org/#/c/384892
> 
> Hi,
> 
> I may suggest a compromise that will allow not to break the model, and
> moving forward with you patch.
> If you can make it work, you can try to move the working_dir creation
> tasks to the provision role.
> You already moved working_dir default var to common role, so it should
> work.
> 
> Any other thoughts ?
> Thanks for raising the question.
> 

Sorry for the slow response, and thanks for raising this question. I
added Lars to the thread as well, because he was the original architect
of the current privilege model in quickstart.

There were two reasons (I can think of anyways) for the current model:

1. Doing tasks as root on the virthost makes clean up trickier. With the
current model, deleting the non-root quickstart user cleans up almost
everything. By keeping all of the root privilege tasks in the provision
and environment roles, it is much easier to reason about the few things
that do not get cleaned up when deleting the quickstart user. If we
start allowing root privilege tasks in the libvirt role, this will be
harder.

2. Theoretically, (I have not actually heard anyone actually doing
this), someone could set up a virthost for use by quickstart, and then
hand it over to someone with only non-root privileges. While I do not
know of anyone using quickstart this way today, it is a compelling use
case for setting up training environments using quickstart. An
admin/trainer could set up a bunch of virthosts for a training and the
students would only have non-root access to the machines.

I think at the very least, we want to maintain the default running of
quickstart with the current model. If some feature absolutely needs to
break this model, it needs to be guarded by a variable defaulted to false.

In the specific case of https://review.openstack.org/#/c/384892 I do
think we could do the directory creation tasks earlier, and then we do
not need to break the model at all to support your use case.

There is also https://review.openstack.org/#/c/399704/ that is running
into the same thing, but again, I think we could probably move all of
the root stuff to earlier roles (though I have yet to thoroughly review
that yet, so I am less sure).

I have also been working with some folks from the OPNFV Apex (which is
tripleo based) team to port their CI to quickstart. I have not seen
patches yet, but it does seem some of the networking requirements may
require us to run the virtual machines under qemu://system which will
break the current privilege model completely. Their case is why we may
need to make the model optional.

@Yolanda wdyt about the suggestion to move directory creation to an
earlier role in your patch? Also, thanks for all your work on quickstart!

-trown

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

Re: [openstack-dev] [nova] Continued reduction in NFV tech debt - input?

[Matt Riedemann]

On 12/1/2016 4:51 AM, Stephen Finucane wrote:

nova has worked hard over the last few cycles to identify and reduce
the amount of tech debt we're carrying. One such item identified early
on was the lack of automated testing and upstream documentation for NFV
features, such as CPU pinning, realtime, hugepages, SR-IOV, and PCI
passthrough. We discussed this at the Austin (M) summit and have been
slowly chugging away at it since through a combination of weekly SR-IOV
meetings [1] and changes to the docs [2][3][4][5], code and in- [6] and
out-of-tree tests [7].

This work will continue for this cycle, however, we'd like to ask is
there any of these features where developers or operators can still
identify significant holes in either validation or (upstream)
documentation? If so, please give us a shout. This is something we'll
probably double back on in a PTG session, but we'd like to make full
use of the few months between now and then to really build on these
features.

I'd also like to take the opportunity to promote the weekly SR-IOV
meeting. We regularly address all things NFV at this meeting, so if
you've ideas on how to improve or build upon these features, this is as
good a place to bring said ideas up.

Cheers,
Stephen (sfinucan)

[1] http://eavesdrop.openstack.org/#SR-IOV/PCI_Passthrough_Meeting
[2] http://docs.openstack.org/networking-guide/config-sriov.html
[3] http://docs.openstack.org/admin-guide/compute-pci-passthrough.html
[4] http://docs.openstack.org/admin-guide/compute-cpu-topologies.html
[5] http://docs.openstack.org/admin-guide/compute-huge-pages.html
[6] https://github.com/openstack/nova/tree/master/nova/tests/functional
/libvirt
[7] https://github.com/openstack/intel-nfv-ci-tests

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



Stephen, thanks for asking for input. You might want to cross-post to 
the openstack-operators mailing list if you're looking for operational 
input on these features in nova. It's fun to fish either way. :)


One immediate thing is we approved this spec for Ocata:

https://blueprints.launchpad.net/nova/+spec/sriov-pf-passthrough-neutron-port-vlan

But there is no code up for review yet. I'm getting a bit antsy about 
blueprints that don't have code yet for Ocata, and this change seems 
pretty straight-forward, so it would be good to get some people driving 
that.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [neutron][octavia] Neutron LBaaS governance change and Octavia to the big tent

[Ihar Hrachyshka]

Armando M.  wrote:


Hi folks,

A few hours ago a governance change [1] has been approved by TC members.  
This means that from now on, the efforts for Load Balancing as a Service  
efforts rest officially in the hands of the Octavia PTL and the Octavia  
core team.


I will work with the help of the respective core teams to implement a  
smooth transition. My suggestion at this point is for any ML  
communication that pertain LBaaS issues to include [octavia] tag on the  
email subject.


Please do not hesitate to reach out for any questions and/or  
clarifications.


Cheers,
Armando

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


Should we also move all neutron lbaas-tagged bugs to octavia in LP? And  
kill the ‘lbaas’ tag from doc/source/policies/bugs.rst?


Ihar

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

Re: [openstack-dev] [ALU] [vitrage] datasource driver returns entities only?

[Weyl, Alexey (Nokia - IL)]

Hi Yujun,

Get_all does returns a list of entities to be sent.

Each event that is sent from the driver to the processor contains also all the 
details of the neighbors that it connects to.
For example, the event and data that we receive from nova about an instance 
also contains the host (compute) that it sits on, and that is how we decide to 
connect it to the correct host.

I think it is ok that the event of static (from driver to the processor) will 
contain for each entity it neighbors that it is supposed to be connected to.

BR,
Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
Sent: Thursday, December 01, 2016 3:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] [openstack-dev] [vitrage] datasource driver returns entities 
only?

During the implementation of static datasource driver[1], I got a question on 
the return format of `get_all` method.

If I understand correctly, it should return a list of entities to be sent to 
the queue. Does it infer that the relationship should be embedded in entity, 
just like the legacy static_physical datasource?

Suppose a link between two switches are created, how should we emit this change 
in `get_all` or `get_changes`?

Currently I made a compromise by emitting the relationship as an update of the 
connected entity. This is not very elegant and it seems we are going back to 
the legacy static_physical datasource.

[1] https://review.openstack.org/#/c/405354/
--
Yujun
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [vitrage] datasource driver returns entities only?

[Yujun Zhang]

During the implementation of static datasource driver[1], I got a question
on the return format of `get_all` method.

If I understand correctly, it should return a list of entities to be sent
to the queue. Does it infer that the relationship should be embedded in
entity, just like the legacy static_physical datasource?

Suppose a link between two switches are created, how should we emit this
change in `get_all` or `get_changes`?

Currently I made a compromise by emitting the relationship as an update of
the connected entity. This is not very elegant and it seems we are going
back to the legacy static_physical datasource.

[1] https://review.openstack.org/#/c/405354/
--
Yujun
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptl][release] ocata release management communication

[Rob Cresswell (rcresswe)]

It looks like your email was already replied to:

http://lists.openstack.org/pipermail/openstack-dev/2016-November/108141.html


On 30 Nov 2016, at 18:38, Rob C > 
wrote:

[Resending without the PTLs in CC because it got my mail stuck in the spam 
filters]

I'm struggling to find good info on when the adjusted PTL nomination cycle 
starts.

I've checked here: 
https://releases.openstack.org/ocata/schedule.html#pike-ptls-self-nomination 
but it looks like the 'elections' section was supposed to be added to the table 
and wasn't.

I know from the updates to the charter that the elections should happen on or 
before R-3 but it doesn't provide any clarity on how much before then the 
nominations should be made?

Cheers
-Rob

On Tue, Nov 1, 2016 at 7:45 PM, Doug Hellmann 
> wrote:
PTLs,

As we did for the Mitaka and Newton cycles, I want to start this
cycle by making sure the expectations for communications with the
release team are clear to everyone so there is no confusion or
miscommunication about any of the process or deadlines. This
email is being sent to the openstack-dev mailing list as well as
the PTLs of all official OpenStack projects individually, to
improve the odds that all of the PTLs see it.  I will not be
taking the extra step of CCing individual PTLs or liaisons for
future emails.

(If you were a PTL last cycle, you may want to skip ahead to the
Things for you to do right now section at the end.)

Volunteers filling PTL and liaison positions are responsible for
ensuring communication between project teams happens smoothly. As
a community, we rely on three primary communication
strategies/tools for different purposes:

1. Email, for announcements and for asynchronous communication.

  We will be using the "[release]" topic tag on the openstack-dev
  mailing list for important messages related to release
  management.  Besides special announcements and instructions, I
  will send the countdown emails I sent last cycle, with weekly
  updates on focus, tasks, and upcoming dates. PTLs and release
  liaisons should configure your mailing list subscription and
  email client to ensure that those messages are visible (and
  then read them) so that you are aware of all deadlines, process
  changes, etc.

2. IRC, for time-sensitive interactions.

  There are far too many of you (56) to make it realistic for the
  three members of the release team to track you down
  individually when there is a deadline. We need you to do your
  part by making yourself available by configuring your IRC
  bouncer to listen in #openstack-release. You are, of course,
  welcome to stay in channel all the time, but you need to be
  there at least during deadline periods (the week before and
  week of each deadline).

3. Written documentation, for relatively stable information.

  The release team has published the schedule for the Ocata cycle
  to http://releases.openstack.org/ocata/schedule.html. Although
  I will highlight dates in the countdown emails, you may want to
  add important dates from the schedule to your calendar.

  Some projects have also added their own project-specific
  deadlines to that list. If you have something unique, please
  feel free to update it by patching the openstack/releases
  repository. There is no need to add a project-specific deadline
  that is the same as the global deadline.

The Ocata cycle overlaps with several major holidays, including
the new year. If you are planning time off, please make sure your
duties are being covered by someone else on the team. Its best to
let the release team know in advance so we dont delay approval
for release requests from someone we dont recognize, waiting for
your +1.

Please ensure that the release liaison for your project has the
time and ability to handle the communication necessary to manage
your release.  The release team is here to facilitate, but
finishing the work of preparing the release is ultimately the
responsibility of the project team. Failing to follow through on
a needed process step may block you from successfully meeting
deadlines or releasing.  Our release milestones and deadlines are
date-based, not feature-based.  When the date passes, so does the
milestone. If you miss it, you miss it. A few of you ran into
problems in past cycles because of missed communications. My goal
is to have all teams meet all deadlines during Ocata. We came
very very close for Newton; please help by keeping up to date on
deadlines.


Things for you to do right now:

1. Update your cross-project liaison on
   https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management

2. Make sure your IRC nickname and email address listed in
   
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
   are correct. The release team, foundation staff, and TC all
   use those contact details to try to reach you at important
   points 

Re: [openstack-dev] [kolla] propose to remove COPY_ONCE feature

[Jeffrey Zhang]

@sdake
we can keep COPY_ONCE and COPY_ALWAY in docker images. But in
kolla-ansible side, only implement COPY_ALWAY.

And does kolla-k8s will only implement COPY_ONCE?

@Gerard
COPY_ALWAYS only affect the configuration file, like /etc/nova/nova.conf.
others are still immutable.

@Paul
For the end-user, either COPY_ONCE or COPY_ALWAYS is transparent. When he
running kolla-ansible, there is no big difference.


On Thu, Dec 1, 2016 at 6:29 PM, Paul Bourke  wrote:

> While I would be interested to know how many people actually do use
> COPY_ONCE, I think if I was in charge of a production deployment I would
> use COPY_ONCE.
>
>
> On 01/12/16 02:27, Jeffrey Zhang wrote:
>
>> Kolla has a config_strategy option during deployment. it supports
>> COPY_ONCE and
>> COPY_ALWAYS.  which means whether copy the configuration files defined in
>> config.json again during starting containers.
>>
>> COPY_ALWAYS: copy all configuration files always during every start (
>> default
>>  value now )
>> COPY_ONCE: copy only once for the first start, then it
>>won't copy even the configuration is changed
>>
>> COPY_ALWAYS is more common for most users. change configuration, then
>> restart
>> containers and it works. but COPY_ONCE is not. after changing the
>> configuration,
>> should remove the container and start it again.
>>
>> for COPY_ONCE, the pro is keeping immutability of the container.  the con
>> is
>> making thing difficult. no matter for kolla code or end-user.
>>
>> I am curiosity does end-user really care about the immutability cause by
>> configuration file? how many user really need such a feature?
>>
>> So I propose to remove COPY_ONCE.
>>
>> any idea is welcome ;)
>>
>> --
>> Regards,
>> Jeffrey Zhang
>> Blog: http://xcodest.me 
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
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] [keystone][devstack][rally][python-novaclient][magnum] switching to keystone v3 by default

[Spyros Trigazis]

I think for magnum we are OK.

This job [1] finished using keystone v3 [2]

Spyros

[1]
http://logs.openstack.org/93/400593/9/check/gate-functional-dsvm-magnum-api/93e8c14/
[2]
http://logs.openstack.org/93/400593/9/check/gate-functional-dsvm-magnum-api/93e8c14/logs/devstacklog.txt.gz#_2016-12-01_11_32_58_033

On 1 December 2016 at 12:26, Davanum Srinivas  wrote:

> It has taken years to get here with a lot of work from many folks.
>
> -1 for Any revert!
>
> https://etherpad.openstack.org/p/v3-only-devstack
> http://markmail.org/message/aqq7itdom36omnf6
> https://review.openstack.org/#/q/status:merged+project:
> openstack-dev/devstack+branch:master+topic:bp/keystonev3
>
> Thanks,
> Dims
>
> On Thu, Dec 1, 2016 at 5:38 AM, Andrey Kurilin 
> wrote:
> > Hi folks!
> >
> > Today devstack team decided to switch to keystone v3 by default[0].
> > Imo, it is important thing, but it was made in silent, so other project
> was
> > unable to prepare to that change. Also, proposed way to select Keystone
> API
> > version via devstack configuration doesn't work(IDENTITY_API_VERSION
> > variable doesn't work [1] ).
> >
> > Switching to keystone v3 broke at least Rally and Magnum(based on
> comment to
> > [0])  gates. Also, python-novaclient has two separate jobs for checking
> > compatibility with keystone V2 and V3. One of these jobs became
> redundant.
> >
> > That is why I submitted a revert [2] .
> >
> > PS: Please, do not make such changes in silent!
> >
> > [0] - https://review.openstack.org/#/c/386183
> > [1] -
> > https://github.com/openstack-infra/project-config/blob/
> master/jenkins/jobs/rally.yaml#L70-L74
> > [2] - https://review.openstack.org/405264
> >
> > --
> > Best regards,
> > Andrey Kurilin.
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> 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] [Openstack-operators] Destructive / HA / fail-over scenarios

[Jorge Cardoso (Cloud Operations and Analytics, IT R Division)]

Hi Timur,

You can also consider Stepler from Mirantis https://github.com/Mirantis/stepler.
I never tried it, but the documentation states: "Stepler framework is intended 
to provide the community with a testing framework that is capable of perform 
advanced scenario and destructive test cases, like batch instances launching, 
instances migration, services restarts and different HA-specific cases."

Cheers,
Jorge


-Original Message-
From: Adam Spiers [mailto:aspi...@suse.com] 
Sent: Monday, November 28, 2016 3:09 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Openstack-operators] Destructive / HA / fail-over 
scenarios

Timur Nurlygayanov  wrote:
> Hi OpenStack developers and operators,
> 
> we are going to create the test suite for destructive testing of 
> OpenStack clouds. We want to hear your feedback and ideas about 
> possible destructive and failover scenarios which we need to check.
> 
> Which scenarios we need to check if we want to make sure that some 
> OpenStack cluster is configured in High Availability mode and can be 
> published as a "production/enterprise" cluster.
> 
> Your ideas are welcome, let's discuss the ideas of test scenarios in 
> this email thread.

I applaud the effort to boost automated testing of failure scenarios!
And thanks a lot for polling the list before starting any work on this.

Regarding the implementation, did you consider reusing Cloud 99, and if not, 
please could you? :-) Obviously it would be good to avoid reinventing wheels 
where possible.


https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/high-availability-and-resiliency-testing-strategies-for-openstack-clouds

https://github.com/cisco-oss-eng/Cloud99

If there are some gaps between Cloud99 and what is needed then it would be 
worth evaluating them in order to determine whether it makes sense to start 
from scratch versus simply develop Cloud99 further.

Also it would be great if you could join the #openstack-ha IRC channel where 
you will find friendly folks from the broader OpenStack HA sub-community who 
I'm sure will be happy to discuss this further.

You are also very welcome to join our weekly IRC meetings:

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

Thanks!
Adam

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

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

Re: [openstack-dev] [oslo] Should we drop kafka driver ?

[Mehdi Abaakouk]

Le 2016-11-30 17:45, Joshua Harlow a écrit :

One of the places for gate testing that is still being worked on is
the following: https://github.com/jd/pifpaf/pull/28


I just finished the work on this: https://github.com/jd/pifpaf/pull/35
And I used it in oslo.messaging here: 
https://review.openstack.org/#/c/404802/


We can now run 'tox -epy27-func-kafka' to run the test kafka driver.

But currently 0 test pass, the driver just print very bad backtrace.

--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

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

Re: [openstack-dev] [keystone][devstack][rally][python-novaclient][magnum] switching to keystone v3 by default

[Davanum Srinivas]

It has taken years to get here with a lot of work from many folks.

-1 for Any revert!

https://etherpad.openstack.org/p/v3-only-devstack
http://markmail.org/message/aqq7itdom36omnf6
https://review.openstack.org/#/q/status:merged+project:openstack-dev/devstack+branch:master+topic:bp/keystonev3

Thanks,
Dims

On Thu, Dec 1, 2016 at 5:38 AM, Andrey Kurilin  wrote:
> Hi folks!
>
> Today devstack team decided to switch to keystone v3 by default[0].
> Imo, it is important thing, but it was made in silent, so other project was
> unable to prepare to that change. Also, proposed way to select Keystone API
> version via devstack configuration doesn't work(IDENTITY_API_VERSION
> variable doesn't work [1] ).
>
> Switching to keystone v3 broke at least Rally and Magnum(based on comment to
> [0])  gates. Also, python-novaclient has two separate jobs for checking
> compatibility with keystone V2 and V3. One of these jobs became redundant.
>
> That is why I submitted a revert [2] .
>
> PS: Please, do not make such changes in silent!
>
> [0] - https://review.openstack.org/#/c/386183
> [1] -
> https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/rally.yaml#L70-L74
> [2] - https://review.openstack.org/405264
>
> --
> Best regards,
> Andrey Kurilin.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

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

[openstack-dev] [neutron] Remove deprecated utility method - camelize

[Gary Kotton]

Hi,
This method is now supported by neutron-lib. The patch [1] remove this from 
neutron.
Thanks
Gary

[1] https://review.openstack.org/#/c/403690
__
OpenStack Development Mailing 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] Obtaining version information for Docker container

[hu . zhijiang]

For #1, I think the requirement is that before pulling the image to local 
registry, one can get its metadata about the version info before hand, 
thus save time and space spend on pulling wrong images. I don't know if 
the info in docker label can be retrieved before before pulling the image 
to local registry. If not, holding such info in docker label may be not a 
good solution since we have to pull the image first. 

Another thought is how about let the kolla build command to generate a 
report about what component version it used to build for each image and 
just let it output this report to a file or stdout? Then this well 
formatted output can be published along with the images(docker save...) 
but not inside of images. 


B.R.,
Zhijiang




发件人: Pete Birley 
收件人: "OpenStack Development Mailing List (not for usage 
questions)" , Adrian Mouat 
, 
日期:   2016-11-19 02:17
主题:   Re: [openstack-dev] [kolla] Obtaining version information for 
Docker container



I've been thinking about this a bit as well, and think that we should 
consider using the docker label schema (http://label-schema.org/rc1/) as a 
solution for #1, it would be possible to add labeling to kolla-build to 
add these labels simply. This solution is gaining traction in the docker 
community, and integrates well with external tools e.g. 
https://microbadger.com. One of the maintainers of this project (Adrian 
Mouat) works in the same room as me and I've cc'd him in case he has any 
additional insight or perspective that may be useful.

Unfortunately this does not provide a solution to the 2nd problem, and 
currently it is not possible to query labels from within a container. I 
think Steve's suggestion of a simple shell tool to query the containers 
package manager(s) and produce a report is probably the right way to go: 
but we should draw up a specification that scoped what data we collected 
in such a manifest as if we simply do the equivalent of 'rpm -qa' then I 
think Paul's point is valid and we don't gain much from the exercise.

Cheers

Pete

On Fri, Nov 18, 2016 at 11:51 AM, Steven Dake (stdake)  
wrote:
Zhu,

This isn’t the first time this question has been asked :)

Since this is a technical matter, I’ve copied openstack-dev for a wider 
audience.  I don’t have a clear solution to obtaining version manifests 
for container content or the upstream container version.  Perhaps someone 
in our broader community may have an answer.

The best I’ve got is we could add a general shell command that can be run 
with docker exec to obtain a proper version manifest of both 1 and 2 
(formatted in YAML or plaintext).  This could be placed in the base 
container image to enable a general diagnostic and certificate of origin 
tool.

Perhaps someone has a better solution?

Regards
-steve


From: "zhu.z...@zte.com.cn" 
Date: Friday, November 18, 2016 at 1:56 AM
To: Steven Dake 
Subject: 

Hello，nice to meet you. I am a contributor of Kolla.
Excuse me, I have a question to bother you.
The question is that how to get openstack component version from a running 
container or image.
you know , the version info is wrapped by the container, it is not easy to 
get them 
there are two type of versions 
one: version in a image, two: version in a running container 
two is easy, for example , we can get it by calling docker exec... 
but how to get the one, Is there any way, 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




-- 

Pete Birley / Director 
pete@port.direct / +447446862551
PORT.DIRECT 
United Kingdom 
https://port.direct


This e-mail message may contain confidential or legally privileged 
information and is intended only for the use of the intended recipient(s). 
Any unauthorized disclosure, dissemination, distribution, copying or the 
taking of any action in reliance on the information herein is prohibited. 
E-mails are not secure and cannot be guaranteed to be error free as they 
can be intercepted, amended, or contain viruses. Anyone who communicates 
with us by e-mail is deemed to have accepted these risks. Port.direct is 
not responsible for errors or omissions in this message and denies any 
responsibility for any damage arising from the use of e-mail. Any opinion 
and other statement contained in this message and any attachment are 
solely those of the author and do not necessarily represent those of the 
company.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

[openstack-dev] [nova] Continued reduction in NFV tech debt - input?

[Stephen Finucane]

nova has worked hard over the last few cycles to identify and reduce
the amount of tech debt we're carrying. One such item identified early
on was the lack of automated testing and upstream documentation for NFV
features, such as CPU pinning, realtime, hugepages, SR-IOV, and PCI
passthrough. We discussed this at the Austin (M) summit and have been
slowly chugging away at it since through a combination of weekly SR-IOV 
meetings [1] and changes to the docs [2][3][4][5], code and in- [6] and
out-of-tree tests [7].

This work will continue for this cycle, however, we'd like to ask is
there any of these features where developers or operators can still
identify significant holes in either validation or (upstream)
documentation? If so, please give us a shout. This is something we'll
probably double back on in a PTG session, but we'd like to make full
use of the few months between now and then to really build on these
features.

I'd also like to take the opportunity to promote the weekly SR-IOV
meeting. We regularly address all things NFV at this meeting, so if
you've ideas on how to improve or build upon these features, this is as
good a place to bring said ideas up.

Cheers,
Stephen (sfinucan)

[1] http://eavesdrop.openstack.org/#SR-IOV/PCI_Passthrough_Meeting
[2] http://docs.openstack.org/networking-guide/config-sriov.html
[3] http://docs.openstack.org/admin-guide/compute-pci-passthrough.html
[4] http://docs.openstack.org/admin-guide/compute-cpu-topologies.html
[5] http://docs.openstack.org/admin-guide/compute-huge-pages.html
[6] https://github.com/openstack/nova/tree/master/nova/tests/functional
/libvirt
[7] https://github.com/openstack/intel-nfv-ci-tests

__
OpenStack Development Mailing List (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] [keystone][devstack][rally][python-novaclient][magnum] switching to keystone v3 by default

[Andrey Kurilin]

Hi folks!

Today devstack team decided to switch to keystone v3 by default[0].
Imo, it is important thing, but it was made in silent, so other project was
unable to prepare to that change. Also, proposed way to select Keystone API
version via devstack configuration doesn't work(IDENTITY_API_VERSION
variable doesn't work [1] ).

Switching to keystone v3 broke at least Rally and Magnum(based on comment
to [0])  gates. Also, python-novaclient has two separate jobs for checking
compatibility with keystone V2 and V3. One of these jobs became redundant.

That is why I submitted a revert [2] .

PS: Please, do not make such changes in silent!

[0] - https://review.openstack.org/#/c/386183
[1] -
https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/rally.yaml#L70-L74
[2] - https://review.openstack.org/405264

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

Re: [openstack-dev] [Openstack-operators] Heat: signaling using SW config/deployment API.

[Rabi Mishra]

Moving to openstack-dev for more visibility and discussion.

We currently have signal API for heat resources(not for standalone software
config/deployment). However, you can probably use a workaround with swift
temp_url like tripleo[1] to achieve your use case.

We do have rpc api[2] for signalling deployments. It would probably not be
that difficult to add REST API support for native/cfn signalling, though I
don't know if there are more reasons for it not being added yet.

Steve Baker(original author) would probably know more about it and can give
you a better answer:)


[1]
https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/deployment.py
[2]
https://github.com/openstack/heat/blob/master/heat/engine/service_software_config.py#L262

On Wed, Nov 30, 2016 at 5:54 PM, Pasquale Lepera 
wrote:

> Hi,
> we're trying to use the Heat Software configuration APIs, but we're facing
> a problem with the signaling.
> We quite well know how to use Software config/deployment inside stack
> Templates, and in that case what we got on the target VM is something like
> this:
>
> #os-collect-config --print
> inputs:[
> …
>  {
>   "type": "String",
>   "name": "deploy_signal_transport",
>   "value": "CFN_SIGNAL",
>   "description": "How the server should signal to heat with the
> deployment output values."
>  },
>  {
>   "type": "String",
>   "name": "deploy_signal_id",
>   "value": "http://ctrl-liberty.nuvolacsi.it:8000/v1/signal/arn%
> 3Aopenstack%3Aheat%3A%3Ab570fe9ea2c94cb8ba72fe07fa034b62%
> 3Astacks%2FStack_test_from_view_galera-53040%2F15d0e95a-
> e422-4994-9f17-bb2f543952f7%2Fresources%2Fdeployment_sw_
> mariadb2?Timestamp=2016-11-24T16%3A35%3A12Z=HmacSHA256&
> AWSAccessKeyId=72ef8cef2e174926b74252754617f347&
> SignatureVersion=2=H5QcAv7yIZgBQzhztb4%2B0NJi7Z3q
> O%2BmwToqINUiKbvw%3D",
>   "description": "ID of signal to use for signaling output values"
>  },
>  {
>   "type": "String",
>   "name": "deploy_signal_verb",
>   "value": "POST",
>   "description": "HTTP verb to use for signaling output values"
>  }
>
> This part, we suppose, is generated by heat during the Template processing
> and is pushed to the target so that, when the deployment is finished, the
> os-apply-config uses CFN to signal to the orchestrator the SUCCESS/FAILED
> job.
>
> The problem is that, when we try to use directly the software config
> creation API and the deployment one, what we got in the target VM is
> something like this:
>
> #os-collect-config --print
> ...
>{
> "inputs": [],
> "group": null,
> "name": "test_key_gen_9aznXZ7DE9",
> "outputs": [],
> "creation_time": "2016-11-24T15:50:50",
> "options": {},
> "config": "#!/bin/bash\ntouch /tmp/test \nhostname > /tmp/test \n",
> "id": "d9395163-4238-4e94-902f-1e8abdbfa2bb"
>}
>
> This appens because we pass to the create SW config API no explicit
> parameter in the “inputs” key.
> Of course, this config causes no signaling back to Heat.
>
> So the questions are:
>
> Is it possible to use the cfn signaling with the software
> configuration/deployment creation APIs?
>
> How?
>
> Is it possible to have a signaling back to the orchestration without
> passing manually a deploy_signal_id inside the API's configuration
> parameters?
>
> If not, another way to give a signal back to Orchestrator, could be a
> workaround creating a self-standing stack containing only
> “OS::Heat::WaitCondition” and “OS::Heat::WaitConditionHandlewaitsignals”
> resources, but before using this workaround we want to be sure that is not
> possible in other ways.
>
> Thanks
>
> Pasquale
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 
Regards,
Rabi Misra
__
OpenStack Development Mailing 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] propose to remove COPY_ONCE feature

[Paul Bourke]

While I would be interested to know how many people actually do use 
COPY_ONCE, I think if I was in charge of a production deployment I would 
use COPY_ONCE.


On 01/12/16 02:27, Jeffrey Zhang wrote:

Kolla has a config_strategy option during deployment. it supports
COPY_ONCE and
COPY_ALWAYS.  which means whether copy the configuration files defined in
config.json again during starting containers.

COPY_ALWAYS: copy all configuration files always during every start (
default
 value now )
COPY_ONCE: copy only once for the first start, then it
   won't copy even the configuration is changed

COPY_ALWAYS is more common for most users. change configuration, then
restart
containers and it works. but COPY_ONCE is not. after changing the
configuration,
should remove the container and start it again.

for COPY_ONCE, the pro is keeping immutability of the container.  the con is
making thing difficult. no matter for kolla code or end-user.

I am curiosity does end-user really care about the immutability cause by
configuration file? how many user really need such a feature?

So I propose to remove COPY_ONCE.

any idea is welcome ;)

--
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] [oslo][monasca] Can we uncap python-kafka ?

[Julien Danjou]

On Thu, Dec 01 2016, Mehdi Abaakouk wrote:

> I'm aware of all of that, oslo.messaging patch for the new version is
> ready since 8 months now. And we are still blocked... capping libraries,
> whatever the reason, is very annoying and just freezes people work.
>
> From the API pov python-kafka haven't break anything, the API is still
> here and documented (and deprecated). What monasca raises is performance
> issue due to how their uses the library, and on absumption on how it works
> internally. Blocking all projects for that looks not fair to me.
>
> As nadya said, now, we have users that that prefers using an unmerged
> patch and the new lib instead of using upstream supported
> version with the old lib. This is not an acceptable situation to me but that's
> just my thought.
>
> Where is the solution to allow oslo.messaging works blocked since 8
> month to continue ?

+1

And if Monasca is using messaging, I wonder why they don't rely on
oslo.messaging, which would also solve this entire problem in a snap.

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

[Takashi Yamamoto]

On Mon, Nov 28, 2016 at 8:37 PM, Takashi Yamamoto  wrote:
> Anil,
>
> do you have any opinion?
>
> i'm thinking to branch stable/newton at around
> 675af77205d4e404bc7c185c13ab6d86f300d185

after taas meeting, i went ahead and create the branch.

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

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

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

On Thu, Dec 1, 2016 at 1:02 AM, Armando M.  wrote:
>
>
> On 27 November 2016 at 20:50, Takashi Yamamoto 
> wrote:
>>
>> On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
>> > Hi
>> >
>> > As of today, the project neutron-vpnaas is no longer part of the neutron
>> > governance. This was a decision reached after the project saw a dramatic
>> > drop in active development over a prolonged period of time.
>> >
>> > What does this mean in practice?
>> >
>> > From a visibility point of view, release notes and documentation will no
>> > longer appear on openstack.org as of Ocata going forward.
>> > No more releases will be published by the neutron release team.
>> > The neutron team will stop proposing fixes for the upstream CI, if not
>> > solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >
>> > How does it affect you, the user or the deployer?
>> >
>> > You can continue to use vpnaas and its CLI via the python-neutronclient
>> > and
>> > expect it to work with neutron up until the newton
>> > release/python-neutronclient 6.0.0. After this point, if you want a
>> > release
>> > that works for Ocata or newer, you need to proactively request a release
>> > [5], and reach out to a member of the neutron release team [3] for
>> > approval.
>> > Assuming that the vpnaas CI is green, you can expect to have a working
>> > vpnaas system upon release of its package in the foreseeable future.
>> > Outstanding bugs and new bug reports will be rejected on the basis of
>> > lack
>> > of engineering resources interested in helping out in the typical
>> > OpenStack
>> > review workflow.
>> > Since we are freezing the development of the neutron CLI in favor of the
>> > openstack unified client (OSC), the lack of a plan to make the VPN
>> > commands
>> > available in the OSC CLI means that at some point in the future the
>> > neutron
>> > client CLI support for vpnaas may be dropped (though I don't expect this
>> > to
>> > happen any time soon).
>> >
>> > Can this be reversed?
>> >
>> > If you are interested in reversing this decision, now it is time to step
>> > up.
>> > That said, we won't be reversing the decision for Ocata. There is quite
>> > a
>> > curve to ramp up to make neutron-vpnaas worthy of being classified as a
>> > neutron stadium project, and that means addressing all the gaps
>> > identified
>> > in [6]. If you are interested, please reach out, and I will work with
>> > you to
>> > add your account to [4], so that you can drive the neutron-vpnaas agenda
>> > going forward.
>> >
>> > Please do not hesitate to reach out to ask questions and/or
>> > clarifications.
>>
>> hi,
>>
>> i'm interested in working on the project.
>> well, at least on the parts which is used by networking-midonet.
>
>
> That's great to hear Yamamoto. Since you are already a neutron-core I assume
> you are already intimate with the work required to strengthen the VPNaaS
> project. I have added you to [4] and you can lean on me for any changes that
> needs reviewing.

thank you.

>
>>
>>
>> >
>> > Cheers,
>> > Armando
>> >
>> > [1] https://review.openstack.org/#/c/392010/
>> > [2] https://review.openstack.org/#/c/397924/
>> > [3] https://review.openstack.org/#/admin/groups/150,members
>> > [4] https://review.openstack.org/#/admin/groups/502,members
>> > [5] https://github.com/openstack/releases
>> > [6]
>> >
>> > http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.html
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (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][tc] Exposing project team's metadata in README files

[Flavio Percoco]

On 30/11/16 08:53 -0800, Michael Johnson wrote:

Hi Flavio,

These tags don't seem to be rendering/laying out well for octavia:
https://github.com/openstack/octavia/blob/master/README.rst

Any pointers to get this corrected or is this part of the backend
rendering work you mentioned in the keystone message above?



This was a bug in the SVG generation. The TL;DR is that the height and width
were not being set for the root SVG. It should now be fixed.

Note that github caches images locally. I wrote a script to purge the cache for
all the badges that have landed already and I've added a cache control rules to
the vhost serving these files now. Once this lands, I'll try purging the cache
from GH again and hopefully it'll stop caching these images, which are not meant
to be cached forever.

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

If you need to purge the cache yourself, you can do it by issuing this command:

$ curl -x PURGE $THE_GITHUB_IMAGE_URL

Hope this helps,
Flavio


Michael

On Wed, Nov 30, 2016 at 1:34 AM, Flavio Percoco  wrote:

On 25/11/16 13:46 +, Amrith Kumar wrote:


Flavio,

I see a number of patches[1] which have been landed on this project but I
find
that at least the ones that were landed for Trove, and a random sampling
of
the others all to be different from what you proposed below[2] in one
important aspect.

In [2] you proposed a structure where the title of the document; or the
first,
and most prominent heading, would be the existing heading of the document,
and
the tags would be below that. In [2] for example, that was:

"kombu - Messaging library for Python"

and the tags would be in smaller font below that.



Hi,

Some fixes landed yesterday to improve the badges layout. For those
interested,
here's an example of what it looks like now:

https://github.com/openstack/keystone

Basically, the horizontal padding was reduced to the minimum needed and the
badges width was set to the total width of the image.

Hope this helps,
Flavio



What I see in [3] the patch for Trove and the proposed example [4] is:

"Team and repository tags" as the first, and most conspicuous header, and
the
header "Trove" below that.

In some cases the second header is the same font as the "Team and
repository
tags" header.

I think this change (these 124 changes) as proposed are not consistent
with
the proposal you made below, and certainly seem to be less suitable than
that
proposal. The end product for the four trove repositories [4], [5], [6],
and
[7]

I think we should have a discussion on the ML whether we feel that this
new
structure is the appropriate one, and before some projects approve these
changes and others don't that these be all marked WF-1.

Thanks,

-amrith

[1] https://review.openstack.org/#/q/topic:project-badges
[2] https://github.com/celery/kombu/blob/master/README.rst
[3] https://review.openstack.org/#/c/402547/
[4] https://gist.github.com/anonymous/4ccf1cc6e531bb50e78cb4d64dfe1065
[5] https://gist.github.com/1f38def1c65c733b7e4cec3d07399e99
[6] https://gist.github.com/2f1c6e9b800db6d4a49d46f5b0623c1d
[7] https://gist.github.com/9e9e2e2ba4ecfdece7827082114f8258





-Original Message-
From: Flavio Percoco [mailto:fla...@redhat.com]
Sent: Thursday, October 13, 2016 7:07 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [all][tc] Exposing project team's metadata
in
README files

On 12/10/16 11:01 -0400, Doug Hellmann wrote:
>Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200:
>> Greetings,
>>
>> One of the common complains about the existing project organization
>> in the big tent is that it's difficult to wrap our heads around the
>> many projects there are, their current state (in/out the big tent),
>> their
tags, etc.
>>
>> This information is available on the governance website[0]. Each
>> official project team has a page there containing the information
>> related to the deliverables managed by that team. Unfortunately, I
>> don't think this page is checked often enough and I believe it's not
>> known
by everyone.
>>
>> In the hope that we can make this information clearer to people
>> browsing the many repos (most likely on github), I'd like to propose
>> that we include the information of each deliverable in the readme
>> file. This information would be rendered along with the rest of the
>> readme (at least on Github, which might not be our main repo but it's
>> the
place most humans go to to check our projects).
>>
>> Rather than duplicating this information, I'd like to find a way to
>> just "include it" in the Readme file. As far as showing the
>> "official" badge goes, I believe it'd be quite simple. We can do it
>> the same way CI tags are exposed when using travis (just include an
>> image). As for the rest of the tags, it might require some extra
>> hacking.
>>
>> So, before I start digging more into this, I wanted to get other
>> opinions/ideas 

Re: [openstack-dev] [kolla] propose to remove COPY_ONCE feature

[Gerard Braad]

On Thu, Dec 1, 2016 at 4:43 PM, Steven Dake (stdake)  wrote:
> The kolla-kubernetes deliverable requires COPY_ONCE not COPY_ALWAYS.
> Some operators prefer immutability over hand-modification of configuration
> From: Jeffrey Zhang 
> I am curiosity does end-user really care about the immutability

Yes, I care. I prefer immutability.

-- 

   Gerard Braad | http://gbraad.nl
   [ Doing Open Source Matters ]

__
OpenStack Development Mailing 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] propose to remove COPY_ONCE feature

[Steven Dake (stdake)]

Jeffrey,

The kolla-kubernetes deliverable requires COPY_ONCE not COPY_ALWAYS.

Some operators prefer immutability over hand-modification of configuration 
files on all nodes.

Therefore, I propose we keep both in place.

Regards
-steve


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

Date: Wednesday, November 30, 2016 at 7:27 PM
To: OpenStack Development Mailing List 
Subject: [openstack-dev] [kolla] propose to remove COPY_ONCE feature

Kolla has a config_strategy option during deployment. it supports COPY_ONCE and
COPY_ALWAYS.  which means whether copy the configuration files defined in
config.json again during starting containers.

COPY_ALWAYS: copy all configuration files always during every start ( default
 value now )
COPY_ONCE: copy only once for the first start, then it
   won't copy even the configuration is changed

COPY_ALWAYS is more common for most users. change configuration, then restart
containers and it works. but COPY_ONCE is not. after changing the configuration,
should remove the container and start it again.

for COPY_ONCE, the pro is keeping immutability of the container.  the con is
making thing difficult. no matter for kolla code or end-user.

I am curiosity does end-user really care about the immutability cause by
configuration file? how many user really need such a feature?

So I propose to remove COPY_ONCE.

any idea is welcome ;)

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