Re: [openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty

On 02/20/2016 05:39 PM, Steven Dake (stdake) wrote: Sam, I seem to recall Paul was not in favor, so there was not a majority of cores there. There were 6 core reviewers at the midcycle, and if you only count kolla-core (which at this time I do for policy changes) that means we had a vote of 5.

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

On Sat, Feb 20, 2016 at 8:27 PM, Michał Jastrzębski wrote: > I don't think kolla will need limit of cores per company, we are > diverse and our diversity grows if anything. Mirantis did make a lot > of commitment this release, and that's great, but that won't change > our

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

I don't think kolla will need limit of cores per company, we are diverse and our diversity grows if anything. Mirantis did make a lot of commitment this release, and that's great, but that won't change our diversity really. Let's deal with this case-by-case, I'd hate to disqualify someone for core

Re: [openstack-dev] [all] Please do *not* use git (and specifically "git log") when generating the docs

On Saturday, February 20, 2016, Thomas Goirand wrote: > On 02/19/2016 05:39 AM, Dolph Mathews wrote: > > > > On Thu, Feb 18, 2016 at 11:17 AM, Thomas Goirand > > >> wrote: > > > > Hi, > > > > I've

[openstack-dev] [sahara][stable] kilo and liberty are blocked on failing pep8 jobs

bashate 0.4 has new error checks which fail the pep8 job for sahara in stable/kilo and stable/liberty. I've backported some fixes from master plus additional changes needed on the stable branches [1]. The Sahara Hadoop Cluster CI is failing but I don't know if that's legitimate or not. If

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 20 Feb 2016 00:21, "Walter A. Boring IV" wrote: > Not that I'm adding much to this conversation that hasn't been said already, but I am pro v2 API, purely because of how painful and long it's been to get the official OpenStack projects to adopt the v2 API from v1. I

Re: [openstack-dev] [kolla][infra] Publishing kolla images to docker-registry.openstack.org

Hi Steve When you say the registry would require a machine with plenty of disk space, do you have an estimate of storage needed? Regards 2016-02-20 14:21 GMT+01:00 Steven Dake (stdake) : > Infra folks, > > I'd like to see a full CI/CD pipeline of Kolla to an OpenStack >

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

I don't think neutron has a limit. There are 4 from redhat and 3 from hp and mirantis right now. https://review.openstack.org/#/admin/groups/38,members On Feb 20, 2016 13:02, "Steven Dake (stdake)" wrote: > Neutron, the largest project in OpenStack by active committers and >

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

On 2/20/16, 10:39 AM, "Joshua Harlow" wrote: >Out of curiosity, who are kollas big users? > >If it's mirantis and redhat (and nobody much else?) then meh, does this >really matter. Sure work on getting more usage and adoption and other >companies interested but why

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

Neutron, the largest project in OpenStack by active committers and reviewers as measured by the governance repository teamstats tool, has a limit of 2 core reviewers per company. They do that for a reason. I expect Kolla will grow over time (we are about 1/4 their size in terms of

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

Oracle, Redhat, Mirantis, Servosity, 99cloud. Those are the biggest users, at least according to the reviews and commits. I am not in favor of limiting the number of cores from a single company. However, it is an unwritten rule that I've heard and abide by that a company should not push a patch

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

Out of curiosity, who are kollas big users? If it's mirantis and redhat (and nobody much else?) then meh, does this really matter. Sure work on getting more usage and adoption and other companies interested but why stagnate a project (by doing this) while that is underway? Other question;

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

I think setting these limits is wrong, some companies have more overall representation then others. The core reviewer job should be on a personal basis and not on a company basis, i think the PTL of each project needs to make sure the diversity and the community voice is heard in each project and

[openstack-dev] [kolla] discussion about core reviewer limitations by company

Hey folks, Mirantis has been developing a big footprint in the core review team, and Red Hat already has a big footprint in the core review team. These are all good things, but I want to avoid in the future a situation in which one company has a majority of core reviewers. Since core

[openstack-dev] OpenStack Developer Mailing List Digest Feb 13-19

OpenStack Operators Midcycle * Takeaways from the OpenStack Mid-Cycle Ops Meetup: first time’s the charm [1] * OpenStack Upgrading Tutorial: 11 pitfalls and solutions [2] “No Open Core” in 2016 (continuing) === * Continuing with

Re: [openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty

Sam, I seem to recall Paul was not in favor, so there was not a majority of cores there. There were 6 core reviewers at the midcycle, and if you only count kolla-core (which at this time I do for policy changes) that means we had a vote of 5. We have 11 core reviewers, so we need a vote of

Re: [openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty

I was under the impression we did have a majority of cores in favor of the idea at the midcycle. But if this is a vote-vote, then I am a very strong +1 as well. This is something operators will absolutely want and and need. Sam Yaple On Sat, Feb 20, 2016 at 4:27 PM, Michał Jastrzębski

Re: [openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty

Strong +1 from me. This have multiple benefits: Easier (aka possible) debugging of networking in running envs (not having tools like tcpdump at your disposal is a pain) - granted, there are ways to get this working without thin containers but require fair amount of docker knowledge. Docker daemon

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On 02/17/2016 09:26 AM, Michael Krotscheck wrote: We (that is, the cores, contributors, and consumers that I've been collaborating with over the past year on this) came to the consensus that leaving the cors middleware as generic & configurable as possible was preferable, and that an

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

On 2016-02-19 19:06:17 -0800 (-0800), Armando M. wrote: [...] > In fact, if we continue to keep --nic an optional parameter, we > can reconcile the behavior between nova-net and neutron (which is > really the win here - make different clouds behave alike). [...] Restated, Nova network feature

Re: [openstack-dev] [kolla]

Thank you Steve. I will clean out the yum Python / everything and place the emphasis on pip. Then when i can fully engage I'll hop on freenode. Thank you again!!! On Sat, Feb 20, 2016 at 9:09 AM Steven Dake (stdake) wrote: > Wade, > > My guess is you have six installed via both

[openstack-dev] [kolla] Metting schedule changes - next IRC meeting at 16:30 UTC!

Hi folks, With this review[1] our meeting times have been changed as follows based upon a community vote[2] of the best US/APAC time: Our US/EMEA meeting time remains unchanged. We don't have a EMEA/APAC meeting because there is not enough core reviewers to hold such a meeting. Even work

Re: [openstack-dev] [kolla]

Wade, My guess is you have six installed via both pip and RPM and they are different versions. If you want help, join us on irc on #freenode, and we can get you going. Its much faster then debugging over a mailing list. Regards -steve From: Wade Holler

[openstack-dev] [kolla]

Just a little help probably. On CentOS 7.2 I tried to follow the quickstart very closely. [root@cpn00012 kolla]# python --version Python 2.7.5 [root@cpn00012 kolla]# pip --version pip 8.0.2 from /usr/lib/python2.7/site-packages (python 2.7) tools/build.py fails like this: tools/build.py

Re: [openstack-dev] [kolla] kolla-mesos IRC meeting

Michal, I want to make sure we fix all of the problems, not just the timezone issue (which in progress by the apac friendly meeting). On 1/15/16, 4:38 AM, "Michal Rostecki" wrote: >Hi, > >Currently we're discussing stuff about kolla-mesos project on kolla IRC

Re: [openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty

Just clarifying, this is not a "revote" - there were not enough core reviewers in favor of this idea at the Kolla midcycle, so we need to have a vote on the mailing list to sort out this policy decision of managing stable/liberty. Regards, -steve From: Steven Dake

Re: [openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty

From: Steven Dake > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Saturday, February 20, 2016 at 6:28 AM To: "OpenStack Development Mailing

[openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty

Folks, There were not enough core reviewers to pass a majority approval of the neutron thin container backport idea, so we separated it out from fixing stable/liberty itself. I am going to keep voting open for *2* weeks this time. The reason for the two weeks is I would like a week of

[openstack-dev] [kolla][infra] Publishing kolla images to docker-registry.openstack.org

Infra folks, I'd like to see a full CI/CD pipeline of Kolla to an OpenStack infrastructure hosted registry. With docker registry 2.2 and earlier a Docker push of Kolla containers took 5-10 hours. This is because of design problems in Docker which made a push each layer of each Docker image

[openstack-dev] [tricircle] playing tricircle with devstack under two-region configuration

Hi Joe and Zhiyuan, I encounter an error when executing the following command: stack@nyp-VirtualBox:~/devstack$ curl -X POST http://192.168.56.101:1/v1.0/pods -H "Content-Type: application/json" -H "X-Auth-Token: 0ead350329ef4b07ab3b823a9d37b724" -d '{"pod": {"pod_name": "RegionOne"}}'

Re: [openstack-dev] [Fuel] Wildcards instead of

Hi, +1 to Igor, plugin developer should be able to granularly define what she/he wants to be executed on the node, without assumptions from our side. `exclude` - field doesn't look like a good solution to me, it will be hard to support and migrate plugins to newer version OpenStack release. I