Re: [openstack-dev] [tripleo] Proposing Enrique Llorente Pastora as a core reviewer for TripleO

[Martin André]

On Thu, Nov 15, 2018 at 5:00 PM Wesley Hayutin  wrote:
>
>
>
> On Thu, Nov 15, 2018 at 8:52 AM Sagi Shnaidman  wrote:
>>
>> Hi,
>> I'd like to propose Quique (@quiquell) as a core reviewer for TripleO. 
>> Quique is actively involved in improvements and development of TripleO and 
>> TripleO CI. He also helps in other projects including but not limited to 
>> Infrastructure.
>> He shows a very good understanding how TripleO and CI works and I'd like 
>> suggest him as core reviewer of TripleO in CI related code.
>>
>> Please vote!
>> My +1 is here :)
>
>
> +1 for tripleo-ci core, I don't think we're proposing tripleo core atm.
> Thanks for proposing and sending this Sagi!

+1

Martin

>>
>>
>> Thanks
>> --
>> Best regards
>> Sagi Shnaidman
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (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 Alan Bishop tripleo core on storage bits

[Martin André]

On Wed, Jun 13, 2018 at 5:50 PM, Emilien Macchi  wrote:
> Alan Bishop has been highly involved in the Storage backends integration in
> TripleO and Puppet modules, always here to update with new features, fix
> (nasty and untestable third-party backends) bugs and manage all the
> backports for stable releases:
> https://review.openstack.org/#/q/owner:%22Alan+Bishop+%253Cabishop%2540redhat.com%253E%22
>
> He's also well knowledgeable of how TripleO works and how containers are
> integrated, I would like to propose him as core on TripleO projects for
> patches related to storage things (Cinder, Glance, Swift, Manila, and
> backends).
>
> Please vote -1/+1,

+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] [kolla][vote] Nominating Steve Noyes for kolla-cli core reviewer

[Martin André]

If Steve wrote half of kolla-cli then it's a no brainer to me. +1!

On Thu, May 31, 2018 at 7:02 PM, Borne Mace  wrote:
> Greetings all,
>
> I would like to propose the addition of Steve Noyes to the kolla-cli core
> reviewer team.  Consider this nomination as my personal +1.
>
> Steve has a long history with the kolla-cli and should be considered its
> co-creator as probably half or more of the existing code was due to his
> efforts.  He has now been working diligently since it was pushed upstream to
> improve the stability and testability of the cli and has the second most
> commits on the project.
>
> The kolla core team consists of 19 people, and the kolla-cli team of 2, for
> a total of 21.  Steve therefore requires a minimum of 11 votes (so just 10
> more after my +1), with no veto -2 votes within a 7 day voting window to end
> on June 6th.  Voting will be closed immediately on a veto or in the case of
> a unanimous vote.
>
> As I'm not sure how active all of the 19 kolla cores are, your attention and
> timely vote is much appreciated.
>
> Thanks!
>
> -- Borne
>
>
> __
> OpenStack Development Mailing List (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] Is there any way to recheck only one job?

[Martin André]

On Mon, Apr 30, 2018 at 10:41 AM, Jens Harbott  wrote:
> 2018-04-30 7:12 GMT+00:00 Slawomir Kaplonski :
>> Hi,
>>
>> I wonder if there is any way to recheck only one type of job instead of 
>> rechecking everything.
>> For example sometimes I have to debug some random failure in specific job 
>> type, like „neutron-fullstack” and I want to collect some additional data or 
>> test something. So in such case I push some „Do not merge” patch and waits 
>> for job result - but I really don’t care about e.g. pep8 or UT results so 
>> would be good is I could run (recheck) only job which I want. That could 
>> safe some resources for other jobs and speed up my tests a little as I could 
>> be able to recheck only my job faster :)
>>
>> Is there any way that I can do it with gerrit and zuul currently? Or maybe 
>> it could be consider as a new feature to add? What do You think about it?
>
> This is intentionally not implemented as it could be used to trick
> patches leading to unstable behaviour into passing too easily, hiding
> possible issues.

Perhaps for these type of patches aimed at gathering data in CI, we
could make it easier for developers to selectively trigger jobs while
still retaining the "all voting jobs must pass in the same run" policy
in place.

I'm thinking maybe a specially formatted line in the commit message
could do the trick:

  Trigger-Job: neutron-fullstack

Even better if we can automatically put a Workflow -1 on the patches
that contains a job triggering marker to prevent them from
accidentally merging, and indicate to reviewers they can skip these
patches.
It's not uncommon to see such DNM patches, so I imagine we can save
quite a lot of CI resource by implementing a system like that. And
devs will be happier too because it can also be tricky at times to
find what triggers a given job.

Martin

__
OpenStack Development Mailing 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]Core nomination for Mark Goddard (mgoddard) as kolla core member

[Martin André]

+1

On Thu, May 3, 2018 at 9:51 AM, duon...@vn.fujitsu.com
 wrote:
> +1
>
>
>
> Sorry for my late reply, thank you for your contribution in Kolla.
>
>
>
> Regards,
>
> Duong
>
>
>
> From: Jeffrey Zhang [mailto:zhang.lei@gmail.com]
> Sent: Thursday, April 26, 2018 10:31 PM
> To: OpenStack Development Mailing List 
> Subject: [openstack-dev] [kolla][vote]Core nomination for Mark Goddard
> (mgoddard) as kolla core member
>
>
>
> Kolla core reviewer team,
>
>
>
> It is my pleasure to nominate
>
> mgoddard for kolla core team.
>
> Mark has been working both upstream and downstream with kolla and
> kolla-ansible for over two years, building bare metal compute clouds with
> ironic for HPC. He's been involved with OpenStack since 2014. He started
> the kayobe deployment project which complements kolla-ansible. He is
> also the most active non-core contributor for last 90 days[1]
>
> Consider this nomination a +1 vote from me
>
> A +1 vote indicates you are in favor of
>
> mgoddard as a candidate, a -1
> is a
>
> veto. Voting is open for 7 days until
>
> May
>
>
>
> 4
>
> th, or a unanimous
> response is reached or a veto vote occurs.
>
> [1] http://stackalytics.com/report/contribution/kolla-group/90
>
>
>
> --
>
> 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] [kolla] [tripleo] On moving start scripts out of Kolla images

[Martin André]

On Thu, Apr 5, 2018 at 2:16 PM, Paul Bourke  wrote:
> Hi all,
>
> This mail is to serve as a follow on to the discussion during yesterday's
> team meeting[4], which was regarding the desire to move start scripts out of
> the kolla images [0]. There's a few factors at play, and it may well be best
> left to discuss in person at the summit in May, but hopefully we can get at
> least some of this hashed out before then.
>
> I'll start by summarising why I think this is a good idea, and then attempt
> to address some of the concerns that have come up since.
>
> First off, to be frank, this is effort is driven by wanting to add support
> for loci images[1] in kolla-ansible. I think it would be unreasonable for
> anyone to argue this is a bad objective to have, loci images have very
> obvious benefits over what we have in Kolla today. I'm not looking to drop
> support for Kolla images at all, I simply want to continue decoupling things
> to the point where operators can pick and choose what works best for them.
> Stemming from this, I think moving these scripts out of the images provides
> a clear benefit to our consumers, both users of kolla and third parties such
> as triple-o. Let me explain why.

It's still very obscure to me how removing the scripts from kolla
images will benefit consumers. If the reason is that you want to
re-use them in other, non-kolla images, I believe we should package
the scripts. I've left some comments in your spec review.

> Normally, to run a docker image, a user will do 'docker run
> helloworld:latest'. In any non trivial application, config needs to be
> provided. In the vast majority of cases this is either provided via a bind
> mount (docker run -v hello.conf:/etc/hello.conf helloworld:latest), or via
> environment variables (docker run --env HELLO=paul helloworld:latest). This
> is all bog standard stuff, something anyone who's spent an hour learning
> docker can understand.
>
> Now, lets say someone wants to try out OpenStack with Docker, and they look
> at Kolla. First off they have to look at something called set_configs.py[2]
> - over 400 lines of Python. Next they need to understand what that script
> consumes, config.json [3]. The only reference for config.json is the files
> that live in kolla-ansible, a mass of jinja and assumptions about how the
> service will be run. Next, they need to figure out how to bind mount the
> config files and config.json into the container in a way that can be
> consumed by set_configs.py (which by the way, requires the base kolla image
> in all cases). This is only for the config. For the service start up
> command, this need to also be provided in config.json. This command is then
> parsed out and written to a location in the image, which is consumed by a
> series of start/extend start shell scripts. Kolla is *unique* in this
> regard, no other project in the container world is interfacing with images
> in this way. Being a snowflake in this regard is not a good thing. I'm still
> waiting to hear from a real world operator who would prefer to spend time
> learning the above to doing:

You're pointing a very real documentation issue. I've mentioned in the
other kolla thread that I have a stub for the kolla API documentation.
I'll push a patch for what I have and we can iterate on that.

>   docker run -v /etc/keystone:/etc/keystone keystone:latest --entrypoint
> /usr/bin/keystone [args]
>
> This is the Docker API, it's easy to understand and pretty much the standard
> at this point.

Sure, using the docker API works for simpler cases, not too
surprisingly once you start doing more funky things with your
containers you're quickly reach the docker API limitations. That's
when the kolla API comes in handy.
See for example this recent patch
https://review.openstack.org/#/c/556673/ where we needed to change
some file permission to the uid/gid of the user inside the container.

The first iteration basically used the docker API and started an
additional container to fix the permissions:

  docker run -v
/etc/pki/tls/certs/neutron.crt:/etc/pki/tls/certs/neutron.crt:rw \
-v /etc/pki/tls/private/neutron.key:/etc/pki/tls/private/neutron.key:rw
\
neutron_image \
/bin/bash -c 'chown neutron:neutron
/etc/pki/tls/certs/neutron.crt; chown neutron:neutron
/etc/pki/tls/private/neutron.key'

You'll agree this is not the most obvious. And it had a nasty side
effect that is changes the permissions of the files _on the host_.
While using kolla API we could simply add to our config.json:

  - path: /etc/pki/tls/certs/neutron.crt
owner: neutron:neutron
  - path: /etc/pki/tls/private/neutron.key
owner: neutron:neutron

> The other argument is that this removes the possibility for immutable
> infrastructure. The concern is, with the new approach, a rookie operator
> will modify one of the start scripts - resulting in uncertainty that what
> was first deployed matches what is currently running. But with the 

Re: [openstack-dev] [kolla][tc][openstack-helm][tripleo]propose retire kolla-kubernetes project

[Martin André]

On Mon, Apr 2, 2018 at 4:38 PM, Steven Dake (stdake) <std...@cisco.com> wrote:
>
>
>
> On April 2, 2018 at 6:00:15 AM, Martin André (m.an...@redhat.com) wrote:
>
> On Sun, Apr 1, 2018 at 12:07 AM, Steven Dake (stdake) <std...@cisco.com>
> wrote:
>> My viewpoint is as all deployments projects are already on an equal
>> footing
>> when using Kolla containers.
>
> While I acknowledge Kolla reviewers are doing a very good job at
> treating all incoming reviews equally, we can't realistically state
> these projects stand on an equal footing today.
>
>
> At the very least we need to have kolla changes _gating_ on TripleO
> and OSH jobs before we can say so. Of course, I'm not saying other
> kolla devs are opposed to adding more CI jobs to kolla, I'm pretty
> sure they would welcome the changes if someone volunteers for it, but
> right now when I'm approving a kolla patches I can only say with
> confidence that it does not break kolla-ansible. In that sense,
> kolla_ansible is special.
>
> Martin,
>
> Personally I think all of OpenStack projects that have a dependency or
> inverse dependency should cross-gate.  For example, Nova should gate on
> kolla-ansible, and at one point I think they agreed to this, if we submitted
> gate work to do so.  We never did that.
>
> Nobody from TripleO or OSH has submitted gates for Kolla.  Submit them and
> they will follow the standard mechanism used in OpenStack
> experimental->non-voting->voting (if people are on-call to resolve
> problems).  I don't think gating is relevant to equal footing.  TripleO for
> the moment has chosen to gate on their own image builds, which is fine.  If
> the gating should be enhanced, write the gates :)
>
> Here is a simple definition from the internet:
>
> "with the same rights and conditions as someone you are competing with"
>
> Does that mean if you want to split the kolla repo into 40+ repos for each
> separate project, the core team will do that?  No.  Does that mean if there
> is a reasonable addition to the API the patch would merge?  Yes.
>
> Thats right, deployment tools compete, but they also cooperate and
> collaborate.  The containers (atleast from my perspective) are an area where
> Kolla has chosen to collaborate.  FWIW I also think we have chosen to
> collobrate a bit in areas we compete (the deployment tooling itself).  Its a
> very complex topic.  Splitting the governance and PTLs doesn't change the
> makeup of the core review team who ultimately makes the decision about what
> is reasonable.

Collaboration is good, there is no question about it.
I suppose the question we need to answer is "would splitting kolla and
kolla-ansible further benefit kolla and the projects that consume
it?". I believe if you look at it from this angle maybe you'll find
areas that are neglected because they are lower priority for
kolla-ansible developers.

>> I would invite the TripleO team who did integration with the Kolla API to
>> provide their thoughts.
>
> The Kolla API is stable and incredibly useful... it's also
> undocumented. I have a stub for a documentation change that's been
> collecting dust on my hard drive for month, maybe it's time I brush it
>
> Most of Kolla unfortunately is undocumented.  The API is simple and
> straightforward enough that TripleO, OSH, and several proprietary vendors
> (the ones Jeffrey mentioned) have managed to implement deployment tooling
> that consume the API.  Documentation for any part of Kolla would be highly
> valued - IMO it is the Kolla project's biggest weakness.
>
>
> up and finally submit it. Today unless you're a kolla developer
> yourself, it's difficult to understand how to use the API, not the
> most user friendly.
>
> Another thing that comes for free with Kolla, the extend_start.sh
> scripts are for the most part only useful in the context of
> kolla_ansible. For instance, hardcoding path for log dirs to
> /var/log/kolla and changing groups to 'kolla'.
> In TripleO, we've chosen to not depend on the extend_start.sh scripts
> whenever possible for this exact reason.
>
> I don't disagree.  I was never fond of extend_start, and thought any special
> operations it provided belong in the API itself.  This is why there are
> mkdir operations and chmod/chown -R operations in the API.  The JSON blob
> handed to the API during runtime is where the API begins and ends.  The
> implementation (what set_cfg.py does with start.sh and extend_start.sh) are
> not part of the API but part of the API implementation.

One could argue that the environment variables we pass to the
containers to control what extend_start.sh does are also part of the
API. That's not my point. There is a lot of cruft in these scr

Re: [openstack-dev] [kolla][tc][openstack-helm][tripleo]propose retire kolla-kubernetes project

[Martin André]

On Sun, Apr 1, 2018 at 12:07 AM, Steven Dake (stdake)  wrote:
>
>
>
> On March 31, 2018 at 12:35:31 PM, Jeremy Stanley (fu...@yuggoth.org) wrote:
>
> On 2018-03-31 18:06:07 + (+), Steven Dake (stdake) wrote:
>> I appreciate your personal interest in attempting to clarify the
>> Kolla mission statement.
>>
>> The change in the Kolla mission statement you propose is
>> unnecessary.
> [...]
>
> I should probably have been more clear. The Kolla mission statement
> right now says that the Kolla team produces two things: containers
> and deployment tools. This may make it challenging for the team to
> avoid tightly coupling their deployment tooling and images, creating
> a stratification of first-class (those created by the Kolla team)
> and second-class (those created by anyone else) support for
> deployment tools using those images.
>
>
> The problems raised in this thread (tension - tight coupling - second class
> citizens - stratification) was predicted early on - prior to Kolla 1.0.
> That prediction led to the creation of a technical solution - the Kolla API.
> This API permits anyone to reuse the containers as they see fit if they
> conform their implementation to the API.  The API is not specifically tied
> to the Ansible deployment technology.  Instead the API is tied to the
> varying requirements that various deployment teams have had in the past
> around generalized requirements for making container lifecycle management a
> reality while running OpenStack services and their dependencies inside
> containers.
>
> Is the intent to provide "a container-oriented deployment solution
> and the container images it uses" (kolla-ansible as first-class
> supported deployment engine for these images) or "container images
> for use by arbitrary deployment solutions, along with an example
> deployment solution for use with them" (kolla-ansible on equal
> footing with competing systems that make use of the same images)?
>
> My viewpoint is as all deployments projects are already on an equal footing
> when using Kolla containers.

While I acknowledge Kolla reviewers are doing a very good job at
treating all incoming reviews equally, we can't realistically state
these projects stand on an equal footing today.
At the very least we need to have kolla changes _gating_ on TripleO
and OSH jobs before we can say so. Of course, I'm not saying other
kolla devs are opposed to adding more CI jobs to kolla, I'm pretty
sure they would welcome the changes if someone volunteers for it, but
right now when I'm approving a kolla patches I can only say with
confidence that it does not break kolla-ansible. In that sense,
kolla_ansible is special.

> I would invite the TripleO team who did integration with the Kolla API to
> provide their thoughts.

The Kolla API is stable and incredibly useful... it's also
undocumented. I have a stub for a documentation change that's been
collecting dust on my hard drive for month, maybe it's time I brush it
up and finally submit it. Today unless you're a kolla developer
yourself, it's difficult to understand how to use the API, not the
most user friendly.

Another thing that comes for free with Kolla, the extend_start.sh
scripts are for the most part only useful in the context of
kolla_ansible. For instance, hardcoding path for log dirs to
/var/log/kolla and changing groups to 'kolla'.
In TripleO, we've chosen to not depend on the extend_start.sh scripts
whenever possible for this exact reason.

The other critical kolla feature we're making extensive use of in
TripleO is the ability to customize the image in any imaginable way
thanks to the template override mechanism. There would be no
containerized deployments via TripleO without it.

Kolla is a great framework for building container images for OpenStack
services any project can consume. We could do a better job at
advertising it. I guess bringing kolla and kolla-kubernetes under
separate governance (even it the team remains mostly the same) is one
way to enforce the independence of kolla-the-images project and
recognize people may be interested in the images but not the
deployment tools.

One last though. Would you imagine a kolla PTL who is not heavily
invested in kolla_ansible?

Martin

> I haven't kept up with OSH development, but perhaps that team could provide
> their viewpoint as well.
>
>
> Cheers
>
> -steve
>
>
> --
> 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] [kolla][vote] core nomination for caoyuan

[Martin André]

+1

On Tue, Mar 13, 2018 at 5:50 PM, Swapnil Kulkarni  wrote:
> On Mon, Mar 12, 2018 at 7:36 AM, Jeffrey Zhang  
> wrote:
>> Kolla core reviewer team,
>>
>> It is my pleasure to nominate caoyuan for kolla core team.
>>
>> caoyuan's output is fantastic over the last cycle. And he is the most
>> active non-core contributor on Kolla project for last 180 days[1]. He
>> focuses on configuration optimize and improve the pre-checks feature.
>>
>> Consider this nomination a +1 vote from me.
>>
>> A +1 vote indicates you are in favor of caoyuan as a candidate, a -1
>> is a veto. Voting is open for 7 days until Mar 12th, or a unanimous
>> response is reached or a veto vote occurs.
>>
>> [1] http://stackalytics.com/report/contribution/kolla-group/180
>> --
>> 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
>>
>
> +1
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] Nominate Gaël Chamoulaud (gchamoul) for tripleo-validations core

[Martin André]

+1! Gaël has been doing a fantastic job in tripleo-validations for a long time.

On Thu, Dec 7, 2017 at 3:34 PM, Ana Krivokapic  wrote:
> Hey TripleO devs,
>
> Gaël has consistently been contributing high quality reviews and patches to
> the tripleo-validations project. The project would highly benefit from his
> addition to the core reviewer team.
>
> Assuming that there are no objections, we will add Gaël to the core team
> next week.
>
> Thanks!
>
> --
> Regards,
> Ana Krivokapic
> Senior Software Engineer
> OpenStack team
> Red Hat Inc.
>
> __
> OpenStack Development Mailing List (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 Wesley Hayutin core on TripleO CI

[Martin André]

+1

On Wed, Dec 6, 2017 at 4:45 PM, Emilien Macchi  wrote:
> Team,
>
> Wes has been consistently and heavily involved in TripleO CI work.
> He has a very well understanding on how tripleo-quickstart and
> tripleo-quickstart-extras work, his number and quality of reviews are
> excellent so far. His experience with testing TripleO is more than
> valuable.
> Also, he's always here to help on TripleO CI issues or just
> improvements (he's the guy filling bugs on a Saturday evening).
> I think he would be a good addition to the TripleO CI core team
> (tripleo-ci, t-q and t-q-e repos for now).
> Anyway, thanks a lot Wes for your hard work on CI, I think it's time
> to move on and get you +2 ;-)
>
> As usual, it's open for voting, feel free to bring any feedback.
> Thanks everyone,
> --
> 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] [tripleo] Nominate akrivoka for tripleo-validations core

[Martin André]

+1 Hooray for Ana

On Wed, Nov 8, 2017 at 1:00 PM, Michele Baldessari  wrote:
> +1
>
> On Wed, Nov 08, 2017 at 12:11:40PM +0100, Jiří Stránský wrote:
>> +1!
>>
>> On 6.11.2017 15:32, Honza Pokorny wrote:
>> > Hello people,
>> >
>> > I would like to nominate Ana Krivokapić (akrivoka) for the core team for
>> > tripleo-validations.  She has really stepped up her game on that project
>> > in terms of helpful reviews, and great patches.
>> >
>> > With Ana's help as a core, we can get more done, and innovate faster.
>> >
>> > If there are no objections within a week, we'll proceed with adding Ana
>> > to the team.
>> >
>> > Thanks
>> >
>> > Honza Pokorny
>> >
>> > __
>> > OpenStack Development Mailing List (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
>
> --
> 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

__
OpenStack Development Mailing 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] Proposal to add Marcin (hrw) to kolla images core team

[Martin André]

+1

On Thu, Nov 2, 2017 at 4:58 PM, Michał Jastrzębski  wrote:
> It's my great pleasure to start another voting for core team addition!
>
> Everyone knows hrw, thanks to him Kolla now runs on both Power and ARM!
> Voting will be open for 14 days (until 16th of Nov).
>
> Consider this mail my +1 vote
>
> 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

__
OpenStack Development Mailing 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] stable/pike gate is broken with containers

[Martin André]

On Sun, Sep 10, 2017 at 10:47 PM, Emilien Macchi  wrote:
> Today I found 2 issues:
>
> 1) https://bugs.launchpad.net/tripleo/+bug/1716256
>
> http://logs.openstack.org/94/500794/2/check-tripleo/gate-tripleo-ci-centos-7-ovb-containers-oooq/c3e3945/logs/undercloud/home/jenkins/overcloud_prep_containers.log.txt.gz#_2017-09-10_14_49_29
>
> I think we need this backport: https://review.openstack.org/#/c/502291
> but it fails here:
> http://logs.openstack.org/91/502291/1/check-tripleo/gate-tripleo-ci-centos-7-ovb-containers-oooq/8140294/logs/undercloud/home/jenkins/overcloud_prep_containers.log.txt.gz#_2017-09-10_19_42_16
>
> We probably missed some other backports. Can anyone familiar with this
> piece help?

I've replied to the bug, it's an issue with the python-tripleoclient
package used on the undercloud that is too old and doesn't have the
code that was merged 10 days ago in the stable/pike branch. Not sure
what is going on.

> 2) https://bugs.launchpad.net/tripleo/+bug/1716280
>
> stable/pike CI deploys Queens containers, tag is missing in Docker
> Registry. I'm cc'ing dprince because I think he has access to the
> dockerhub account, in case we need to do any change there.

Here I'm rebuilding the images for pike with the appropriate tag. Once
this is done we can use the pike tag in CI.

Martin

> Thanks for the help,
> --
> 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] [kolla][kolla-ansible] Proposing Bertrand Lallau for kolla and kolla-ansible core

[Martin André]

+1

On Wed, May 3, 2017 at 3:10 PM, Mauricio Lima  wrote:
> +1
>
> 2017-05-03 1:43 GMT-03:00 Christian Berendt
> :
>>
>> +1
>>
>> > On 2. May 2017, at 17:30, Michał Jastrzębski  wrote:
>> >
>> > Hello,
>> >
>> > It's my pleasure to start another core reviewer vote. Today it's
>> > Bertrand (blallau). Consider this mail my +1 vote. Members of
>> > kolla-ansible and kolla core team, please cast your votes:) Voting
>> > will be open for 2 weeks (until 16th of May).
>> >
>> > I also wanted to say that Bertrand went through our core mentorship
>> > program (if only for few weeks because he did awesome job before too)
>> > :)
>> >
>> > Thank you,
>> > 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
>>
>> --
>> Christian Berendt
>> Chief Executive Officer (CEO)
>>
>> Mail: bere...@betacloud-solutions.de
>> Web: https://www.betacloud-solutions.de
>>
>> Betacloud Solutions GmbH
>> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>>
>> Geschäftsführer: Christian Berendt
>> Unternehmenssitz: Stuttgart
>> Amtsgericht: Stuttgart, HRB 756139
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [tripleo] Proposing Florian Fuchs for tripleo-validations core

[Martin André]

Hellooo,

I'd like to propose we extend Florian Fuchs +2 powers to the
tripleo-validations project. Florian is already core on tripleo-ui
(well, tripleo technically so this means there is no changes to make
to gerrit groups).

Florian took over many of the stalled patches in tripleo-validations
and is now the principal contributor in the project [1]. He has built
a good expertise over the last months and I think it's time he has
officially the right to approve changes in tripleo-validations.

Consider this my +1 vote.

Martin

[1] 
http://stackalytics.com/?module=tripleo-validations=patches=pike

__
OpenStack Development Mailing 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] container jobs are unstable

[Martin André]

On Wed, Mar 22, 2017 at 2:20 PM, Dan Prince <dpri...@redhat.com> wrote:
> On Wed, 2017-03-22 at 13:35 +0100, Flavio Percoco wrote:
>> On 22/03/17 13:32 +0100, Flavio Percoco wrote:
>> > On 21/03/17 23:15 -0400, Emilien Macchi wrote:
>> > > Hey,
>> > >
>> > > I've noticed that container jobs look pretty unstable lately; to
>> > > me,
>> > > it sounds like a timeout:
>> > > http://logs.openstack.org/19/447319/2/check-tripleo/gate-tripleo-
>> > > ci-centos-7-ovb-containers-oooq-nv/bca496a/console.html#_2017-03-
>> > > 22_00_08_55_358973
>> >
>> > There are different hypothesis on what is going on here. Some
>> > patches have
>> > landed to improve the write performance on containers by using
>> > hostpath mounts
>> > but we think the real slowness is coming from the images download.
>> >
>> > This said, this is still under investigation and the containers
>> > squad will
>> > report back as soon as there are new findings.
>>
>> Also, to be more precise, Martin André is looking into this. He also
>> fixed the
>> gate in the last 2 weeks.
>
> I spoke w/ Martin on IRC. He seems to think this is the cause of some
> of the failures:
>
> http://logs.openstack.org/32/446432/1/check-tripleo/gate-tripleo-ci-cen
> tos-7-ovb-containers-oooq-nv/543bc80/logs/oooq/overcloud-controller-
> 0/var/log/extra/docker/containers/heat_engine/log/heat/heat-
> engine.log.txt.gz#_2017-03-21_20_26_29_697
>
>
> Looks like Heat isn't able to create Nova instances in the overcloud
> due to "Host 'overcloud-novacompute-0' is not mapped to any cell'. This
> means our cells initialization code for containers may not be quite
> right... or there is a race somewhere.

Here are some findings. I've looked at time measures from CI for
https://review.openstack.org/#/c/448533/ which provided the most
recent results:

* gate-tripleo-ci-centos-7-ovb-ha [1]
undercloud install: 23
overcloud deploy: 72
total time: 125
* gate-tripleo-ci-centos-7-ovb-nonha [2]
undercloud install: 25
overcloud deploy: 48
total time: 122
* gate-tripleo-ci-centos-7-ovb-updates [3]
undercloud install: 24
overcloud deploy: 57
total time: 152
* gate-tripleo-ci-centos-7-ovb-containers-oooq-nv [4]
undercloud install: 28
overcloud deploy: 48
total time: 165 (timeout)

Looking at the undercloud & overcloud install times, the most task
consuming tasks, the containers job isn't doing that bad compared to
other OVB jobs. But looking closer I could see that:
- the containers job pulls docker images from dockerhub, this process
takes roughly 18 min.
- the overcloud validate task takes 10 min more than it should because
of the bug Dan mentioned (a fix is in the queue at
https://review.openstack.org/#/c/448575/)
- the postci takes a long time with quickstart, 13 min (4 min alone
spent on docker log collection) whereas it takes only 3 min when using
tripleo.sh

Adding all these numbers, we're at about 40 min of additional time for
oooq containers job which is enough to cross the CI job limit.

There is certainly a lot of room for optimization here and there and
I'll explore how we can speed up the containers CI job over the next
weeks.

Martin

[1] 
http://logs.openstack.org/33/448533/2/check-tripleo/gate-tripleo-ci-centos-7-ovb-ha/d2c1b16/
[2] 
http://logs.openstack.org/33/448533/2/check-tripleo/gate-tripleo-ci-centos-7-ovb-nonha/d6df760/
[3] 
http://logs.openstack.org/33/448533/2/check-tripleo/gate-tripleo-ci-centos-7-ovb-updates/3b1f795/
[4] 
http://logs.openstack.org/33/448533/2/check-tripleo/gate-tripleo-ci-centos-7-ovb-containers-oooq-nv/b816f20/

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

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

Re: [openstack-dev] [kolla] Proposing duonghq for core

[Martin André]

On Wed, Mar 8, 2017 at 7:41 AM, Michał Jastrzębski  wrote:
> Hello,
>
> I'd like to start voting to include Duong (duonghq) in Kolla and
> Kolla-ansible core teams. Voting will be open for 2 weeks (ends at
> 21st of March).
>
> Consider this my +1 vote.

+1
Martin

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

__
OpenStack Development Mailing 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 Sergey (Sagi) Shnaidman for core on tripleo-ci

[Martin André]

On Tue, Jan 24, 2017 at 6:03 PM, Juan Antonio Osorio
 wrote:
> Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both
> on the current CI solution and in getting tripleo-quickstart jobs for
> it); So I would like to propose him as part of the TripleO CI core team.
>
> I think he'll make a great addition to the team and will help move CI
> issues forward quicker.

+1

> Best Regards,
>
>
>
> --
> Juan Antonio Osorio R.
> jaosorior
>
>
> __
> OpenStack Development Mailing List (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 Honza Pokorny core on tripleo-ui

[Martin André]

On Tue, Jan 24, 2017 at 2:52 PM, Emilien Macchi  wrote:
> I have been discussed with TripleO UI core reviewers and it's pretty
> clear Honza's work has been valuable so we can propose him part of
> Tripleo UI core team.
> His quality of code and reviews make him a good candidate and it would
> also help the other 2 core reviewers to accelerate the review process
> in UI component.
>
> Like usual, this is open for discussion, Tripleo UI core and TripleO
> core, please vote.

Of course +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] [tripleo] Update TripleO core members

[Martin André]

On Mon, Jan 23, 2017 at 8:03 PM, Emilien Macchi  wrote:
> Greeting folks,
>
> I would like to propose some changes in our core members:
>
> - Remove Jay Dobies who has not been active in TripleO for a while
> (thanks Jay for your hard work!).
> - Add Flavio Percoco core on tripleo-common and tripleo-heat-templates
> docker bits.
> - Add Steve Backer on os-collect-config and also docker bits in
> tripleo-common and tripleo-heat-templates.
>
> Indeed, both Flavio and Steve have been involved in deploying TripleO
> in containers, their contributions are very valuable. I would like to
> encourage them to keep doing more reviews in and out container bits.
>
> As usual, core members are welcome to vote on the changes.

+1 to all. Great work guys!

> 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] [vote][kolla] deprecation for Debian distro support

[Martin André]

On Thu, Jan 19, 2017 at 11:53 AM, Christian Berendt
 wrote:
> As discussed in one of the last team meetings I want to propose the 
> deprecation (this cycle) and removal (next cycle) of the Debian support in 
> Kolla.
>
> More than 1 week ago I sent a pre warning mail to the openstack-operators 
> mailing list, without any reply [0].
>
> Kolla core reviewers, please vote now. The vote will be open for 7 days 
> (26.01.2017).
>
> 1. Kolla needs support for Debian, it should not be deprecated
>
> 2. Kolla should deprecate support for Debian

Option 2 since nobody volunteered to maintain the Debian images.

> [0] 
> http://lists.openstack.org/pipermail/openstack-operators/2017-January/012427.html
>
> --
> Christian Berendt
> Chief Executive Officer (CEO)
>
> Mail: bere...@betacloud-solutions.de
> Web: https://www.betacloud-solutions.de
>
> Betacloud Solutions GmbH
> Teckstrasse 62 / 70190 Stuttgart / Deutschland
>
> Geschäftsführer: Christian Berendt
> Unternehmenssitz: Stuttgart
> Amtsgericht: Stuttgart, HRB 756139
>
>
> __
> OpenStack Development Mailing List (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][kolla-ansible][kolla-kubernetes] Kolla core election policy change - vote

[Martin André]

On Wed, Nov 16, 2016 at 7:23 PM, Michał Jastrzębski  wrote:
> Hello,
>
> In light of recent events (kolla-kubernetes becoming thriving project,
> kolla-ansible being split) I feel we need to change of core reviewer
> election process.
>
> Currently Kolla was single core team. That is no longer the case, as
> right now we have 3 distinct core teams (kolla, kolla-ansible and
> kolla-kubernetes), although for now with big overlap in terms of
> people in them.
>
> For future-proofing, as we already have difference between teams, I
> propose following change to core election process:
>
>
> Core reviewer voting rights are reserved by core team in question.
> Which means if someone propose core reviewer to kolla-kubernetes, only
> kolla-kubernetes cores has a voting right (not kolla or kolla-ansible
> cores).

Makes sense. +1

Martin

> Voting will be open until 30 Nov '16 end of day. Reviewers from all
> core teams in kolla has voting rights on this policy change.
>
> 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

__
OpenStack Development Mailing 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] [vote] Re: [kolla] Propose removal of TrivialFix requirement

[Martin André]

On Sun, Nov 6, 2016 at 7:52 PM, Steven Dake (stdake)  wrote:
> This may have got lost in the noise of the last few days of ml.  As a
> result, I am tagging with [vote].  I currently count 7 +1’s but again – lots
> of mailing list traffic so I may be off on my counting.
>
>
>
> For all core reviewers:
>
> In the future to help inc0 out with tallying the votes for votes core
> reviewers propose, please tag the email with [vote].
>
>
>
> Regards
>
> -steve
>
>
>
>
>
> From: Paul Bourke 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Thursday, November 3, 2016 at 6:21 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [openstack-dev] [kolla] Propose removal of TrivialFix requirement
>
>
>
> Kolleagues,
>
>
>
> How do people feel above removing the requirement of having TrivialFix
>
> in commit messages where a bug/bp is not required?
>
>
>
> I'm seeing a lot of valid and important commits being held up because of
>
> this, in my opinion, unnecessary requirement. It also causes friction
>
> for new contributers to the project.
>
>
>
> Are there any major benefits we're getting from the use of this tag that
>
> I'm missing?

This is my feeling as well. The tag really should only be used as an
indication given to the reviewers rather than as a way to enforce a
policy where all commits should have tags.

+1 for not requiring a TrivialFix tag in the commit message where
there is no related bp/bug.

Martin

> Cheers,
>
> -Paul
>
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
>
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing List (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] [vote][kolla] deprecation for fedora distro support

[Martin André]

My vote goes to option 2. It's common knowledge Kolla's Fedora base
image is in bad shape and doesn't get any attention from developers.
It's time to deprecated it.

Martin

On Mon, Sep 19, 2016 at 7:40 PM, Jeffrey Zhang  wrote:
> Kolla core reviewer team,
>
> Kolla supports multiple Linux distros now, including
>
> * Ubuntu
> * CentOS
> * RHEL
> * Fedora
> * Debian
> * OracleLinux
>
> But only Ubuntu, CentOS, and OracleLinux are widely used and we have
> robust gate to ensure the quality.
>
> For fedora, Kolla hasn't any test for it and nobody reports any bug
> about it( i.e. nobody use fedora as base distro image). We (kolla
> team) also do not have enough resources to support so many Linux
> distros. I prefer to deprecate fedora support now.  This is talked in
> past but inconclusive[0].
>
> Please vote:
>
> 1. Kolla needs support fedora( if so, we need some guys to set up the
> gate and fix all the issues ASAP in O cycle)
> 2. Kolla should deprecate fedora support
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-June/098526.html
>
>
> --
> 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] [vote][kolla] deprecation for debian distro support

[Martin André]

I'm -1 on deprecating Debian base image considering it's a recent
addition to Kolla and we can legitimately assume the person who
contributed it had plans to use it. I would love to get Benedikt’s
input.

Martin

On Tue, Sep 20, 2016 at 7:27 PM, Steven Dake (stdake)  wrote:
> Matthias,
>
>
>
> I was asked why this is so by a different person.  The reason is determining
> majority is impossible if the electorate isn’t well defined in advance of
> the vote.  In this case, the electorate is the core team who were selected
> by their peers to serve as the leadership of the project.  We could correct
> this deficiency by holding votes across all contributors for the last year.
> The authorized votes for the PTL election [1] for Kolla Newton were 114
> people, and 69 voted.
>
>
>
> The PTL election was a major vote – not something simple like a deprecation
> vote.  Yet 60% of eligible voters voted.  Using this mechanism would result
> in an inability to obtain a majority on any issue in my opinion, would be
> more heavyweight, and require a whole lot more work, and finally slow down
> decision making processes.
>
>
>
> We vote on proposals such as this to remove logjams (if there are any to be
> removed) and we want it to be lightweight.
>
>
>
> Regards
>
> -steve
>
>
>
>
>
>
>
> From: Steven Dake 
> Date: Tuesday, September 20, 2016 at 8:32 AM
>
>
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [vote][kolla] deprecation for debian distro
> support
>
>
>
> Mathias,
>
>
>
> Thank you for voicing your opinion (and anyone is welcome to do that in
> Kolla), however, core reviewer votes are the only binding votes in the
> decision making process.
>
>
>
> Regards
>
> -steve
>
>
>
>
>
> From: Mathias Ewald 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Tuesday, September 20, 2016 at 7:25 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [vote][kolla] deprecation for debian distro
> support
>
>
>
> Option 2
>
>
>
> 2016-09-20 16:07 GMT+02:00 Steven Dake (stdake) :
>
> Consider this a reversal of my vote for Debian deprecation.
>
> Swapnil, thanks for bringing this fact to our attention.  It was missing
> from the original vote.  I don’t know why I didn’t bring up Benedikt’s
> contributions (which were substantial) just as Paul’s were substantial for
> Oracle Linux.  I guess the project is too busy for me to keep all the
> context in my brain.  The fact that there is no debian gate really is
> orthogonal to the discussion in my mind.  With this action we would be
> turning away a contributor who has made real contributions, and send the
> signal his work doesn’t matter or fit in with the project plans.
>
> This is totally the wrong message to send.  Further others might interpret
> such an act as a “we don’t care about anyone’s contributions” which is not
> the culture we have cultivated since origination of the project.  We have
> built a culture of “you build it, we will accept it once it passes review”.
> We want to hold on to that – it’s a really good thing for Kolla.  There have
> been rumblings in this thread and on irc of the expanding support matrix and
> our (lack) of dealing with it appropriately.  I think there are other ways
> to solve that problem without a policy hammer.
>
> I added the fedora work originally along with others who have since moved on
> to other projects.  I personally have been unsuccessful at maintaining it,
> because of the change to DNF (And PTL is a 100% time commitment without a
> whole lot of time for implementation work).  That said Fedora moves too fast
> for me personally to commit to maintenance there – so my vote there remains
> unchanged.
>
> Regards
> -steve
>
>
>
>
>
>
> On 9/20/16, 2:34 AM, "Paul Bourke"  wrote:
>
> If it's the case Benedict or noone else is interested in continuing
> Debian, I can reverse my vote. Though it seems I'll be outvoted anyway
> ;)
>
> On 20/09/16 10:21, Swapnil Kulkarni wrote:
> > On Tue, Sep 20, 2016 at 2:38 PM, Paul Bourke 
> wrote:
> >> -1 for deprecating Debian.
> >>
> >> As I mentioned in https://review.openstack.org/#/c/369183/, Debian
> support
> >> was added incrementally by Benedikt Trefzer as recently as June. So
> it's
> >> reasonable to believe there is at least one active user of Debian.
> >>
> >> I would like to try get some input from him on whether he's still
> using it
> >> and would be interested in helping maintain by adding gates etc.
> >>
> >> On 19/09/16 18:44, Jeffrey Zhang wrote:
> >>>
> >>> Kolla core reviewer team,
> >>>
> >>> Kolla supports multiple Linux distros now, including
>  

Re: [openstack-dev] [poll][kolla] Name of baremetal role/group

[Martin André]

On Wed, Sep 7, 2016 at 11:58 PM, Steven Dake (stdake)  wrote:
> Sean,
>
>
>
> I’d recommend deploy-hosts (I assume this is the bootstrap renamed?)

+1
I also like deploy-host better than the other proposed names. Can we
update the poll to include this option?

> I’d also add a duplicate API of “deploy” and mark deploy as deprecated and
> follow the standard deprecation policies.  I’d recommend making the new
> OpenStack specific deploy command deploy-openstack

Agreed.

Martin

> Regards
>
> -steve
>
>
>
>
>
> From: "sean.k.moo...@intel.com" 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Wednesday, September 7, 2016 at 11:51 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [openstack-dev] [poll][kolla] Name of baremetal role/group
>
>
>
> Hi
>
> I recently introduced a new baremetal role/group which is used as part of
> the kolla-host playbook.
>
> https://github.com/openstack/kolla/tree/master/ansible/roles/baremetal
>
> This baremetal role is used to install all the dependencies required to
> deploy kolla containers on a “baremetal” host.
>
> The host does not have to be baremetal it can be a vm but the term baremetal
> was originally chosen as unlike other rules in
>
> Kolla it installs and configures packages on the host os.
>
>
>
> Given that kolla also has baremetal as a service via ironic and baremetal
> provision of servers with bifrost the question I would like
>
> To ask is should we change the name of the current role to install the kolla
> dependencies to something else.
>
>
>
> I have created a strawpoll link for this here
> http://www.strawpoll.me/11175159
>
> The options available in the strawpool are:
>
> · kolla-host
>
> · host
>
> · baremetal
>
> · pre-install
>
> If there are any other suggestions fell free to discuss them in this thread.
>
> I will check the poll Friday evening gmt and submit a patch for review if
> consensus is that it should be changed.
>
>
>
> Regards
>
> Sean.
>
>
> __
> OpenStack Development Mailing List (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] [vote][kolla] Core Nomination for Christian Berendt (berendt on irc)

[Martin André]

+1, nice work Christian.

Martin

On Thu, Sep 8, 2016 at 4:59 AM, Steven Dake (stdake)  wrote:
> Kolla core reviewer team,
>
>
>
> It is my pleasure to nominate Christian Berendt for the Kolla core team.
>
>
>
> Christian’s output over the last cycle has been fantastic – cracking the top
> 10 reviewer list for the full cycle.  His 30 day stats [1] place him in
> solid 7th position, and considering the size of the core review team we
> have, this is a great accomplishment.  Christian also has solid 60 day
> review stats [2] place him in solid 7th position.  But more importantly his
> reviews are of high quality.  He has great IRC participation as well as
> having implemented all kinds of bug fixes all over the code base.  He
> clearly understands Kolla by the quality of his reviews.
>
>
>
> Consider this nomination a +1 vote from me.
>
>
>
> A +1 vote indicates you are in favor of Christian as a candidate, a 0 vote
> indicates an abstain, and a -1 is a veto.  Voting is open for 7 days until
> September 15th, or a unanimous response is reached or a veto vote occurs.
> If a unanimous response is reached or a veto occurs, voting will close
> early.
>
>
>
> Regards,
>
> -steve
>
>
>
> [1] http://stackalytics.com/report/contribution/kolla/30
>
> [2] http://stackalytics.com/report/contribution/kolla/60
>
>
>
>
> __
> OpenStack Development Mailing List (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][vote] Core nomination for Dave Walker (Daviey on irc)

[Martin André]

+1

On Tue, Aug 23, 2016 at 10:45 PM, Steven Dake (stdake)  wrote:
> Kolla core reviewers,
>
> I am nominating Dave Walker for the Kolla core reviewer team.  His 30 day
> review stats [1] place him in the middle of the pack for reviewers and his
> 60 day stats[2] are about equivalent.  Dave participates heavily in IRC and
> has done some good technical work including the Watcher playbook and
> container.  He also worked on Sensu, but since we are unclear if we are
> choosing Sensu or Tig, that work is on hold.  He will also be helping us
> sort out how to execute with PBR going into the future on our stable and
> master branches.  Dave has proven to me his reviews are well thought out and
> he understands the Kolla Architecture.  Dave is part time like many Kolla
> core reviewers and is independent of any particular affiliation.
>
> Consider this nomination as a +1 from me.
>
> As a reminder, a +1 vote indicates you approve of the candidate, an abstain
> vote indicates you don't care or don't know for certain, and a –1 vote
> indicates a veto.  If a veto occurs or a unanimous response is reached prior
> to our 7 day voting window which concludes on August 30th, voting will be
> closed early.
>
> [1] http://stackalytics.com/report/contribution/kolla/30
> [2] http://stackalytics.com/report/contribution/kolla/60
>
> __
> OpenStack Development Mailing List (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] [vote][kolla] Core nomination proposal for Eduardo Gonzalez Gutierrez (egonzales90 on irc)

[Martin André]

+1

On Fri, Aug 19, 2016 at 8:52 PM, Vikram Hosakote (vhosakot)
 wrote:
> +1.
>
> Great work Eduardo contributing to the third party plugin support kolla
> blueprint!
>
> Regards,
> Vikram Hosakote
> IRC:  vhosakot
>
> From: "Steven Dake (stdake)" 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Thursday, August 18, 2016 at 7:09 PM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [openstack-dev] [vote][kolla] Core nomination proposal for Eduardo
> Gonzalez Gutierrez (egonzales90 on irc)
>
> Kolla Core Review Team:
>
> I am nominating Eduardo for the core reviewer team.  His reviews are
> fantastic, as I'm sure most of you have seen after looking over the review
> queue.  His 30 day stats place him at #3 by review count [1] and 60 day
> stats [2] at #4 by review count.  He is also first to review a significant
> amount of the time – which is impressive for someone new to Kolla.  He
> participates in IRC and he has done some nice code contribution as well [3]
> including the big chunk of work on enabling Senlin in Kolla, the dockerfile
> customizations work, as well as a few documentation fixes.  Eduardo is not
> affiliated with any particular company.  As a result he is not full time on
> Kolla like many of our other core reviewers.  The fact that he is part time
> and still doing fantastically well at reviewing is a great sign of things to
> come :)
>
> Consider this nomination as my +1 vote.
>
> Voting is open for 7 days until August 24th.  Joining the core review team
> requires a majority of the core review team to approve within a 1 week
> period with no veto (-1) votes.  If a veto or unanimous decision is reached
> prior to August 24th, voting will close early.
>
> Regards
> -steve
>
> [1] http://stackalytics.com/report/contribution/kolla/30
> [2] http://stackalytics.com/report/contribution/kolla/60
> [3]
> https://review.openstack.org/#/q/owner:%22Eduardo+Gonzalez+%253Cdabarren%2540gmail.com%253E%22
>
> __
> OpenStack Development Mailing List (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] repo split

[Martin André]

On Thu, Jul 21, 2016 at 5:21 PM, Steven Dake (stdake)  wrote:
> I am voting -1 for now, but would likely change my vote after we branch
> Newton.  I'm not a super big fan of votes way ahead of major events (such
> as branching) because a bunch of things could change between now and then
> and the vote would be binding.
>
> Still community called the vote - so vote stands :)

IIUC, if split there is, it's scheduled for when we branch out Newton
which is only 1 month ahead.

I'm +1 on splitting ansible deployment code into kolla-ansible.

Martin

> Regards
> -steve
>
>
> On 7/20/16, 1:48 PM, "Ryan Hallisey"  wrote:
>
>>Hello.
>>
>>The repo split discussion that started at summit was brought up again at
>>the midcycle.
>>The discussion was focused around splitting the Docker containers and
>>Ansible code into
>>two separate repos [1].
>>
>>One of the main opponents to the split is backports.  Backports will need
>>to be done
>>by hand for a few releases.  So far, there hasn't been a ton of
>>backports, but that could
>>always change.
>>
>>As for splitting, it provides a much clearer view of what pieces of the
>>project are where.
>>Kolla-ansible with its own repo will sit along side kolla-kubernetes as
>>consumers of the
>>kolla repo.
>>
>>The target for the split will be for day 1 of Occata. The core team will
>>vote on
>>the change of splitting kolla into kolla-ansible and kolla.
>>
>>Cores please respond with a +1/-1 to approve or disapprove the repo
>>split. Any community
>>member feel free to weigh in with your opinion.
>>
>>+1
>>-Ryan
>>
>>[1] - https://etherpad.openstack.org/p/kolla-N-midcycle-repo-split
>>
>>__
>>OpenStack Development Mailing List (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] tripleo-common bugs, bug tracking and launchpad tags

[Martin André]

On Tue, Jul 19, 2016 at 5:20 PM, Steven Hardy  wrote:
> On Mon, Jul 18, 2016 at 12:28:10PM +0100, Julie Pichon wrote:
>> Hi,
>>
>> On Friday Dougal mentioned on IRC that he hadn't realised there was a
>> separate project for tripleo-common bugs on Launchpad [1] and that he'd
>> been using the TripleO main tracker [2] instead.
>>
>> Since the TripleO tracker is also used for client bugs (as far as I can
>> tell?), and there doesn't seem to be a huge amount of tripleo-common
>> bugs perhaps it would make sense to also track those in the main
>> tracker? If there is a previous conversation or document about bug
>> triaging beyond [3] I apologise for missing it (and would love a
>> URL!). At the moment it's a bit confusing.
>
> Thanks for raising this, yes there is a bit of a proliferation of LP
> projects, but FWIW the only one I'm using to track coordinated milestone
> releases for Newton is this one:
>
> https://launchpad.net/tripleo/
>
>> If we do encourage using the same bug tracker for multiple components,
>> I think it would be useful to curate a list of official tags [4]. The
>> main advantage of doing that is that the tags will auto-complete so
>> it'd be easier to keep them consistent (and thus actually useful).
>
> +1 I'm fine with adding tags, but I would prefer that we stopped adding
> more LP projects unless the associated repos aren't planned to be part of
> the coordinated release (e.g I don't have to track them ;)
>
>> Personally, I wanted to look through open bugs against
>> python-tripleoclient but people use different ways of marking them at
>> the moment - e.g. [tripleoclient] or [python-tripleoclient] or
>> tripleoclient (or nothing?) in the bug name. I tried my luck at adding
>> a 'tripleoclient' tag [5] to the obvious ones as an example. Maybe
>> something shorter like 'cli', 'common' would make more sense. If there
>> are other tags that come back regularly it'd probably be helpful to
>> list them explicitly as well.
>
> Sure, well I know that many python-*clients do have separate LP projects,
> but in the case of TripleO our client is quite highly coupled to the the
> other TripleO pieces, in particular tripleo-common.  So my vote is to
> create some tags in the main tripleo project and use that to filter bugs as
> needed.
>
> There are two projects we might consider removing, tripleo-common, which
> looks pretty much unused and tripleo-validations which was recently added
> by the sub-team working on validations.
>
> If folks find either useful then they can stay, but it's going to be easier
> to get a clear view on when to cut a release if we track everything
> considered part of the tripleo deliverable in one place IMHO.

The tripleo-validations issues on launchpad now live in the tripleo
bug tracker with the 'validations' tag.
I'm going to retire the tripleo-validation launchpad once I find how to do it.

Here's the relevant tripleo-validations patch:
https://review.openstack.org/347706

Thanks,
Martin

> Thanks,
>
> Steve
>
>>
>> Julie
>>
>> [1] https://bugs.launchpad.net/tripleo-common
>> [2] https://bugs.launchpad.net/tripleo
>> [3] https://wiki.openstack.org/wiki/TripleO#Bug_Triage
>> [4] https://wiki.openstack.org/wiki/Bug_Tags
>> [5] https://bugs.launchpad.net/tripleo?field.tag=tripleoclient
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> Steve Hardy
> Red Hat Engineering, Cloud
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] Consolidating TripleO validations with Browbeat validations

[Martin André]

On Tue, Jun 21, 2016 at 12:41 PM, Tomas Sedovic <tsedo...@redhat.com> wrote:
> On 06/20/2016 06:37 PM, Joe Talerico wrote:
>>
>> Hello - It would seem there is a little bit of overlap with TripleO
>> validations ( clapper validations ) and Browbeat *Checks*. I would
>> like to see these two come together, and I wanted to get some feedback
>> on this.
>>
>> For reference here are the Browbeat checks :
>> https://github.com/openstack/browbeat/tree/master/ansible/check
>>
>> We check for common deployment mistakes, possible deployment
>> performance issues and some bugs that could impact the scale and
>> performance of your cloud... At the end we build a report of found
>> issues with the cloud, like :
>>
>> https://github.com/openstack/browbeat/blob/master/ansible/check/browbeat-example-bug_report.log
>>
>> We eventually wanted to take these findings and push them to
>> ElasticSearch as metadata for our result data (just so we would be
>> aware of any BZs or possibly missed tuning).
>>
>> Anyhoo, I just would like to get feedback on consolidating these
>> checks into TripleO Validations if that makes sense. If this does make
>> sense, who could I work with to see that this happens?
>
>
> Hey!
>
> I'd love to have a single place for all the validations if it's at all
> possible.
>
> Our repos are structured a little differently, but I hope we can come up
> with a solution that works for both uses.
>
> The primary idea behind the tripleo-validations (née Clapper) repo is to
> have have checks in the various stages of the deployment to find potential
> hardware issues or incorrect configuration early.
>
> We want to have these run by the cli and the web ui automatically, which is
> why we opted for the one validation (playbook) with extra metadata per file
> approach.
>
> There are two people working on these right now: myself and Martin André.
> We're in #tripleo (mandre & shadower). Feel free to talk to either of us,
> though I suspect I may have more time for this.
>
> We're both in the CE(S)T so there should be some overlap for realtime chat.

This is great! There's indeed a lot of overlap between browbreat
checks and tripleo-validations, and yeah, I think it makes perfect
sense to try to consolidate the tripleo-validations. You'll notice the
tripleo-validations repo is currently empty; we're starting from a
clean slate and haven't yet imported any of the the existing clapper
validations so now is actually a good time to discuss what you want to
see in the repo.

There will be a mistral workflow [1] that runs the validations (or
groups of validations). We can imagine an action (or separate
workflow) that pushes the results to ElasticSearch, but that would
require you to run the validations through mistral. Alternatively, we
could probably build this mechanism directly in ansible by adding some
kind of hook.

Martin

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

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

[Martin André]

This is not a goodbye Jeff. Have fun on your next adventure.

Martin

On Tue, Jun 7, 2016 at 1:40 PM, Ryan Hallisey  wrote:
> Thanks for all the hard work Jeff!  I'm sure our paths will cross again!
>
> -Ryan
>
> - Original Message -
> From: "Michał Jastrzębski" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Sent: Monday, June 6, 2016 7:13:00 PM
> Subject: Re: [openstack-dev] [kolla] stepping down from core
>
> Damn, bad news:( All the best Jeff!
>
> On 6 June 2016 at 17:57, Vikram Hosakote (vhosakot)  
> wrote:
>> Thanks for all the contributions to kolla and good luck Jeff!
>>
>> Regards,
>> Vikram Hosakote
>> IRC: vhosakot
>>
>> From: "Steven Dake (stdake)" 
>> Reply-To: OpenStack Development Mailing List
>> 
>> Date: Monday, June 6, 2016 at 6:14 PM
>> To: OpenStack Development Mailing List 
>> Subject: Re: [openstack-dev] [kolla] stepping down from core
>>
>> Jeff,
>>
>> Thanks for the notification.  Likewise it has been a pleasure working with
>> you over the last 3 years on Kolla.  I've removed you from gerrit.
>>
>> You have made a big impact on Kolla.  For folks that don't know, at one
>> point Kolla was nearly dead, and Jeff was one of our team of 3 that stuck
>> to it.  Without Jeff to carry the work forward, OpenStack deployment in
>> containers would have been set back years.
>>
>> Best wishes on what you work on next.
>>
>> Regards
>> -steve
>>
>> On 6/6/16, 12:36 PM, "Jeff Peeler"  wrote:
>>
>> Hi all,
>>
>> This is my official announcement to leave core on Kolla /
>> Kolla-Kubernetes. I've enjoyed working with all of you and hopefully
>> we'll cross paths again!
>>
>> Jeff
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [kolla] Request for changing the meeting time to 1600 UTC for all meetings

[Martin André]

+1

On Thu, Jun 9, 2016 at 12:34 PM, Ryan Hallisey  wrote:
> +1
>
> On Jun 8, 2016, at 11:43 PM, Vikram Hosakote (vhosakot) 
> wrote:
>
> +1
>
> Regards,
> Vikram Hosakote
> IRC: vhosakot
>
> From: "Swapnil Kulkarni (coolsvap)" 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Wednesday, June 8, 2016 at 8:54 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [openstack-dev] [kolla] Request for changing the meeting time to
> 1600 UTC for all meetings
>
> Dear Kollagues,
>
> Some time ago we discussed the requirement of alternating meeting
> times for Kolla weekly meeting due to major contributors from
> kolla-mesos were not able to attend weekly meeting at UTC 1600 and we
> implemented alternate US/APAC meeting times.
>
> With kolla-mesos not active anymore and looking at the current active
> contributors, I wish to reinstate the UTC 1600 time for all Kolla
> Weekly meetings.
>
> Please let me know your views.
>
> --
> Best Regards,
> Swapnil Kulkarni
> irc : coolsvap
>
> __
> OpenStack Development Mailing List (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] [kolla] Proposing Mauricio Lima for core reviewer

[Martin André]

+1, of course.

On Wed, May 18, 2016 at 5:23 AM, Jeffrey Zhang  wrote:
> +1
> nice work Mauricio Lima
>
> On Wed, May 18, 2016 at 11:03 AM, Swapnil Kulkarni  wrote:
>>
>> On Wed, May 18, 2016 at 12:30 AM, Steven Dake (stdake) 
>> wrote:
>> > Hello core reviewers,
>> >
>> > I am proposing Mauricio (mlima on irc) for the core review team.  He has
>> > done a fantastic job reviewing appearing in the middle of the pack for
>> > 90
>> > days [1] and appearing as #2 in 45 days [2].  His IRC participation is
>> > also
>> > fantastic and does a good job on technical work including implementing
>> > Manila from zero experience :) as well as code cleanup all over the code
>> > base and documentation.  Consider my proposal a +1 vote.
>> >
>> > I will leave voting open for 1 week until May 24th.  Please vote +1
>> > (approve), or –2 (veto), or abstain.  I will close voting early if there
>> > is
>> > a veto vote, or a unanimous vote is reached.
>> >
>> > Thanks,
>> > -steve
>> >
>> > [1] http://stackalytics.com/report/contribution/kolla/90
>> > [2] http://stackalytics.com/report/contribution/kolla/45
>> >
>> >
>> > __
>> > OpenStack Development Mailing 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
>
>
>
>
> --
> 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] [kolla] Vagrant environment for kolla-kubernetes

[Martin André]

On Fri, May 13, 2016 at 8:57 AM, Britt Houser (bhouser)
 wrote:
> Would we ever run AIO-k8s vagrant w/o Kolla repo?  If not, then it makes 
> sense to me just to extend Vagrant kolla repo.

Agreed. Vagrant is for developers and developers will want the kolla
repo for building the container images.
Having a config options to setup the Vagrant environment for the
different deployment methods seems appropriate here.

Martin

> Thx,
> britt
>
>
>
>
> On 5/13/16, 2:37 AM, "Michal Rostecki"  wrote:
>
>>Hi,
>>
>>Currently we have nice guide about setting up AIO k8s environment in
>>review. But at the same time I'm thinking also about automating this by
>>Vagrant, like we did in kolla-mesos.
>>
>>Here comes the question - what repo is good for keeping the Vagrant
>>stuff for kolla-k8s? I see two options.
>>
>>1) Create a Vagrantfile in kolla-k8s repo
>>
>>That's what we've done in kolla-mesos. And that was a huge problem, because:
>>- we had to copy dhcp-leases script for vagrant-libvirt
>>- we almost copied all the logic of overriding the resources via
>>Vagrantfile.custom
>>
>>While we can do something with the first con - by trying to drop the
>>dhcp-leases script and use eth0 for keepalived/haproxy and endpoints,
>>getting rif of the second con may be hard.
>>
>>2) Extend Vagrantfile in kolla repo
>>
>>That would be easy - it requires just adding some boolean to the
>>Vagrantfile and additional provisioning script.
>>
>>But it sounds odd, to have separate repo for kolla-k8s and at the same
>>time centralize only some compoments in the one repo.
>>
>>What are your thoughts?
>>
>>Cheers,
>>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
> __
> OpenStack Development Mailing List (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][kolla-k8s] Core team

[Martin André]

On Tue, May 3, 2016 at 6:48 PM, Michał Jastrzębski  wrote:
> Hello,
>
> Since it seems that we have voted for separation of kolla-k8s repos
> (yay!) I would like to table another discussion (but let's wait till
> its official).
>
> Core Team.
>
> We need to build up new core team that will guard the gates on our
> brand new repo (when it arrives). One of ideas Steven pointed out is
> to add people from etherpad to core team, but I'd like to throw
> different idea to the mix, to keep things interesting.
>
> Idea is: let's start with current kolla core team and for the time
> being add new cores to kolla-k8s by invitation by existing core
> member. For example, I'm kolla core, working with k8s and I see some
> guy doing great job and investing time into it, I would propose him
> for core, and instead of normal voting, he will get his +2 powers
> immediately. This would allow quick core team buildout and not start
> with bunch of people who doesn't necessary want to contribute or even
> know each other.

Interesting idea. I wonder if this will favor diversity or on the
contrary cause cores to nominate their friends.

Just to put things back in context, we're in this nice situation in
the kolla project where a couple of companies wrote their own solution
to run containers with kubernetes and now want to share their work
with the community. Instead of encouraging a code dump, we'll start a
new kolla-kubernetes effort from scratch where we can confront ideas
and incorporate the work from these companies and other contributors.
We certainly don't want to end up in a situation where a company is
over-represented, leading to unbalanced discussions, or even worse to
self-approved patches.

In addition to having cores we trust, I think we can avoid most of
conflicts by following a simple rule: a company can't push a patch
through. In other words, we ask core reviewers from different
affiliations to validate a patch before it can be approved.

Martin

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

__
OpenStack Development Mailing 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][kubernetes][infra] kolla-kubernetes repository management proposal up for vote

[Martin André]

+1 for kolla-kubernetes.

On Mon, May 2, 2016 at 1:07 PM, Mauricio Lima  wrote:
> Just to clarify my vote.
>
> +1 for single repository
>
> 2016-05-02 14:11 GMT-03:00 Jeff Peeler :
>>
>> Also +1 for working on kolla-kubernetes. (Please read this thread if
>> you haven't yet):
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2016-May/093575.html
>>
>> On Mon, May 2, 2016 at 10:56 AM, Ryan Hallisey 
>> wrote:
>> > +1 to start kolla-kubernetes work.
>> >
>> > - Original Message -
>> > From: "Swapnil Kulkarni" 
>> > To: "OpenStack Development Mailing List (not for usage questions)"
>> > 
>> > Sent: Monday, May 2, 2016 12:59:40 AM
>> > Subject: Re: [openstack-dev] [kolla][vote][kubernetes][infra]
>> > kolla-kubernetes repository management proposal up for vote
>> >
>> > On Mon, May 2, 2016 at 10:08 AM, Vikram Hosakote (vhosakot)
>> >  wrote:
>> >> A separate repo will land us in the same spot as we had with
>> >> kolla-mesos
>> >> originally.  We had all kinds of variance in the implementation.
>> >>
>> >> I’m in favor of a single repo.
>> >>
>> >> +1 for the single repo.
>> >>
>> >
>> > I agree with you Vikram, but we should consider the bootstrapping
>> > requirements for new deployment technologies and learn from our
>> > failures with kolla-mesos.
>> >
>> > At the same time, it will help us evaluate the deployment technologies
>> > going ahead without distrupting the kolla repo which we can treat as a
>> > repo with stable images & associated deployment tools.
>> >
>> >> Regards,
>> >> Vikram Hosakote
>> >> IRC: vhosakot
>> >>
>> >> From: Vikram Hosakote 
>> >> Date: Sunday, May 1, 2016 at 11:36 PM
>> >>
>> >> To: "OpenStack Development Mailing List (not for usage questions)"
>> >> 
>> >> Subject: Re: [openstack-dev] [kolla][vote][kubernetes][infra]
>> >> kolla-kubernetes repository management proposal up for vote
>> >>
>> >> Please add me too to the list!
>> >>
>> >> Regards,
>> >> Vikram Hosakote
>> >> IRC: vhosakot
>> >>
>> >> From: Michał Jastrzębski 
>> >> Reply-To: "OpenStack Development Mailing List (not for usage
>> >> questions)"
>> >> 
>> >> Date: Saturday, April 30, 2016 at 9:58 AM
>> >> To: "OpenStack Development Mailing List (not for usage questions)"
>> >> 
>> >> Subject: Re: [openstack-dev] [kolla][vote][kubernetes][infra]
>> >> kolla-kubernetes repository management proposal up for vote
>> >>
>> >> Add me too please Steven.
>> >>
>> >> On 30 April 2016 at 09:50, Steven Dake (stdake) 
>> >> wrote:
>> >>
>> >> Fellow core reviewers,
>> >>
>> >> We had a fantastic turnout at our fishbowl kubernetes as an underlay
>> >> for
>> >> Kolla session.  The etherpad documents the folks interested and
>> >> discussion
>> >> at summit[1].
>> >>
>> >> This proposal is mostly based upon a combination of several discussions
>> >> at
>> >> open design meetings coupled with the kubernetes underlay discussion.
>> >>
>> >> The proposal (and what we are voting on) is as follows:
>> >>
>> >> Folks in the following list will be added to a kolla-k8s-core group.
>> >>
>> >>   This kolla-k8s-core group will be responsible for code reviews and
>> >> code
>> >> submissions to the kolla repository for the /kubernetes top level
>> >> directory.
>> >> Individuals in kolla-k8s-core that consistently approve (+2) or
>> >> disapprove
>> >> with a (-2) votes to TLD directories other then kubernetes will be
>> >> handled
>> >> on a case by case basis with several "training warnings" followed by
>> >> removal
>> >> of the kolla-k8s-core group.  The kolla-k8s-core group will be added as
>> >> a
>> >> subgroup of the kolla-core reviewer team, which means they in effect
>> >> have
>> >> all of the ACL access as the existing kolla repository.  I think it is
>> >> better in this case to trust these individuals to the right thing and
>> >> only
>> >> approve changes for the kubernetes directory until proposed for the
>> >> kolla-core reviewer group where they can gate changes to any part of
>> >> the
>> >> repository.
>> >>
>> >> Britt Houser
>> >>
>> >> mark casey
>> >>
>> >> Steven Dake (delta-alpha-kilo-echo)
>> >>
>> >> Michael Schmidt
>> >>
>> >> Marian Schwarz
>> >>
>> >> Andrew Battye
>> >>
>> >> Kevin Fox (kfox)
>> >>
>> >> Sidharth Surana (ssurana)
>> >>
>> >>   Michal Rostecki (mrostecki)
>> >>
>> >>Swapnil Kulkarni (coolsvap)
>> >>
>> >>MD NADEEM (mail2nadeem92)
>> >>
>> >>Vikram Hosakote (vhosakot)
>> >>
>> >>Jeff Peeler (jpeeler)
>> >>
>> >>Martin Andre (mandre)
>> >>
>> >>Ian Main (Slower)
>> >>
>> >> Hui Kang (huikang)
>> >>
>> >> Serguei Bezverkhi (sbezverk)
>> >>
>> >> Alex Polvi (polvi)
>> >>
>> >> Rob Mason
>> >>
>> >> Alicja Kwasniewska
>> >>
>> >> sean mooney (sean-k-mooney)

Re: [openstack-dev] [kolla][kubernetes] One repo vs two

[Martin André]

On Mon, May 2, 2016 at 1:23 PM, Jeff Peeler  wrote:
> On Sun, May 1, 2016 at 5:03 PM, Steven Dake (stdake)  wrote:
>> I don't think a separate repository is the correct approach based upon one
>> off private conversations with folks at summit. Many people from that list
>> approached me and indicated they would like to see the work integrated in
>> one repository as outlined in my vote proposal email.  The reasons I heard
>> were:
>>
>> Better integration of the community
>> Better integration of the code base
>> Doesn't present an us vs them mentality that one could argue happened during
>> kolla-mesos
>> A second repository makes k8s a second class citizen deployment architecture
>> without a voice in the full deployment methodology
>> Two gating methods versus one
>> No going back to a unified repository while preserving git history
>>
>> I favor of the separate repositories I heard
>>
>> It presents a unified workspace for kubernetes alone
>> Packaging without ansible is simpler as the ansible directory need not be
>> deleted
>>
>> There were other complaints but not many pros.  Unfortunately I failed to
>> communicate these complaints to the core team prior to the vote, so now is
>> the time for fixing that.
>
> I favor the repository split, but the reason being is that I think
> Ansible along with Kubernetes should each be a separate repository.
> Keeping a monolithic repository is the opposite of the "Unix
> philosophy". It was even recommended at one point to split every
> single service into a separate repository [1].
>
> Repository management, backports, and additional gating are all things
> that I'll admit are more work with more than one single repository.
> However, the ease of ramping up where everything is separated out
> makes it worth it in my opinion. I believe the success of a given
> community is partially due to proper delineation of expertise
> (otherwise, why not put all OpenStack services in one gigantic repo?).
> I'm echoing this comment somebody said at the summit: stretching the
> core team across every orchestration tool is not scalable. I'm really
> hoping more projects will grow around the Kolla ecosystem and can do
> so without being required to become proficient with every other
> orchestration system.
>
> One argument for keeping a single repository is to compare to the
> mesos effort (that has stopped now) in a different repository. But as
> it has already been said, mesos should have been given fairness with
> ansible split out as well. If everything were in a single repository,
> it has been suggested that the community will review more. However, I
> don't personally believe that with gerrit in use that affects things
> at all. OpenStack even has a gerrit dashboard creator [2], but I think
> developers are capable enough at easily finding what they want to
> consistently review.
>
> As I said in a previous reply [3], I don't think git history should
> affect this decision as we can make it work in either scenario. ACL
> permissions seem overly complicated to be in the same repository, even
> if we can arrange for a feature branch to have different permissions
> from the main repo.
>
> My views here are definitely focused on the long term view. If any
> short term plans can be made to allow ourselves to eventually align
> with having separate repositories, I don't think I'd have a problem
> with that. However, I thought the Ansible code was supposed to have
> been separated out a long time ago. This is a natural inflection point
> to change policy and mode of operating, which is why I don't enjoy the
> idea of waiting any longer. Luckily, having Ansible in the same
> repository currently does not inhibit any momentum with Kubernetes in
> a separate repository.
>
> As far as starting the repositories split and then merging them in the
> future (assuming Ansible also stays in one repo), I don't know why we
> would want that. But perhaps after the Kubernetes effort has
> progressed we can better determine if that makes sense with a clear
> view of what the project files actually end up looking like. I don't
> think that any project that changes the containers' ABI is suitable to
> be labeled as "Kolla", so there wouldn't be any dockerfiles part of
> the repository.
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-April/093213.html
> [2] https://github.com/openstack/gerrit-dash-creator
> [3] http://lists.openstack.org/pipermail/openstack-dev/2016-May/093645.html

Jeff, I 100% agree here.

The strongest argument for single repo, IMO, is that it facilitates
code reviews for changes affecting both the container images and the
deployment tool, and makes it easier for backports.
On the other hand, having "better integration" as Steve put it, is not
always desirable: deployment tools each come with their specific
features and philosophy and I'd hate to see a patch receive negative
feedback because the developers can't agree on 

Re: [openstack-dev] [kolla][vote] Nit-picking documentation changes

[Martin André]

On Tue, Apr 12, 2016 at 10:05 PM, Steve Gordon  wrote:

> - Original Message -
> > From: "Jeff Peeler" 
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> >
> > On Mon, Apr 11, 2016 at 3:37 AM, Steven Dake (stdake) 
> > wrote:
> > > Hey folks,
> > >
> > > The reviewers in Kolla tend to nit-pick the quickstart guide to death
> > > during
> > > reviews.  I'd like to keep that high bar in place for the QSG, because
> it
> > > is
> > > our most important piece of documentation at present.  However, when
> new
> > > contributors see the nitpicking going on in reviews, I think they may
> get
> > > discouraged about writing documentation for other parts of Kolla.
> > >
> > > I'd prefer if the core reviewers held a lower bar for docs not related
> to
> > > the philosophy or quiickstart guide document.  We can always iterate on
> > > these new documents (like the operator guide) to improve them and
> raise the
> > > bar on their quality over time, as we have done with the quickstart
> guide.
> > > That way contributors don't feel nitpicked to death and avoid
> improving the
> > > documentation.
> > >
> > > If you are a core reveiwer and agree with this approach please +1, if
> not
> > > please –1.
> >
> > I'm fine with relaxing the reviews on documentation. However, there's
> > a difference between having a missed comma versus the whole patch
> > being littered with misspellings. In general in the former scenario I
> > try to comment and leave the code review set at 0, hoping the
> > contributor fixes it. The danger is that a 0 vote people sometimes
> > miss, but it doesn't block progress.
>
> My typical experience with (very) occasional drive by commits to
> operational project docs (albeit not Kolla) is that the type of nit that
> comes up is more typically -1 thanks for adding X, can you also add Y and
> Z. Before you know it a simple drive by commit to flesh out one area has
> become an expectation to write an entire chapter.
>

That's because you're a native speaker and you write proper English to
begin with :)

We should be asking ourselves this simple question when reviewing
documentation patch "does it make the documentation better?". Often the
answer is yes, that's why I'm trying to ask for additional improvements in
follow-up patches.

Regarding spelling or a grammatical mistakes, why not fix it now while it's
still hot when we spot one in the new documentation that's being written?
It's more time consuming to fix it later. If needed a native speaker can
take over the patch and correct English.

Martin


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

Re: [openstack-dev] [kolla][vote] Nominating Vikram Hosakot for Core Reviewer

[Martin André]

+1
Nice work Vikram.

On Thu, Mar 31, 2016 at 4:04 PM, Jeff Peeler  wrote:

> +1
>
> On Tue, Mar 29, 2016 at 12:07 PM, Steven Dake (stdake) 
> wrote:
> > Hey folks,
> >
> > Consider this proposal a +1 in favor of Vikram joining the core reviewer
> > team.  His reviews are outstanding.  If he doesn’t have anything useful
> to
> > add to a review, he doesn't pile on the review with more –1s which are
> > slightly disheartening to people.  Vikram has started a trend amongst the
> > core reviewers of actually diagnosing gate failures in peoples patches as
> > opposed to saying gate failed please fix.  He does this diagnosis in
> nearly
> > every review I see, and if he is stumped  he says so.  His 30 days review
> > stats place him in pole position and his 90 day review stats place him in
> > second position.  Of critical notice is that Vikram is ever-present on
> IRC
> > which in my professional experience is the #1 indicator of how well a
> core
> > reviewer will perform long term.   Besides IRC and review requirements,
> we
> > also have code requirements for core reviewers.  Vikram has implemented
> only
> > 10 patches so far, butI feel he could amp this up if he had feature work
> to
> > do.  At the moment we are in a holding pattern on master development
> because
> > we need to fix Mitaka bugs.  That said Vikram is actively working on
> > diagnosing root causes of people's bugs in the IRC channel pretty much
> 12-18
> > hours a day so we can ship Mitaka in a working bug-free state.
> >
> > Our core team consists of 11 people.  Vikram requires at minimum 6 +1
> votes,
> > with no veto –2 votes within a 7 day voting window to end on April 7th.
> If
> > there is a veto vote prior to April 7th I will close voting.  If there
> is a
> > unanimous vote prior to April 7th, I will make appropriate changes in
> > gerrit.
> >
> > Regards
> > -steve
> >
> > [1] http://stackalytics.com/report/contribution/kolla-group/30
> > [2] http://stackalytics.com/report/contribution/kolla-group/90
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][vote] exception for backporting upgrades to liberty/stable

[Martin André]

On Tue, Mar 8, 2016 at 2:41 AM, Steven Dake (stdake) 
wrote:

>
>
> On 3/7/16, 10:16 AM, "Paul Bourke"  wrote:
>
> >This is a messy topic. I feel there's been some miscommunication and
> >confusion on the issue which hopefully I can sum up.
> >
> >As far as I remember it, Sam is correct, we did always plan to do
> >Liberty upgrades. However, over the course of time post Tokyo these
> >plans didn't really materialise, at which point Micheal kindly stepped
> >forward to kick things into action [0].
> >
> >Between now and then the focus shifted to "how do we get from Liberty to
> >Mitaka", and the original discussion of moving between minor Liberty
> >releases fell by the wayside. I think this is where the confusion has
> >arisen.
>
> This is accurate.  It wasn¹t a matter of not materializing, however, we
> were capacity constrained.  We will have upgrades working for Mitaka but
> it required a lot of everyone's time.
>

The initial work on upgrade took some time, but that doesn't mean it's not
an easy backport to Liberty. As far as I can tell it's perfectly isolated
code and can be backported without too much trouble.

I'd like to stick to what we agreed in Tokyo, I'm +1 on backporting upgrade
playbooks to 1.1.0.

Martin


> Regards
> -stev
>
> >
> >As I mentioned before I have been opposed to backporting features to
> >stable/liberty, as this is against the philosophy of a stable branch
> >etc. etc. However, as has been mentioned many times before, this is a
> >new project, hindsight is a great thing. Ideally users running Liberty
> >who encounter a CVE could be told to go to Mitaka, but in reality this
> >is an unreasonable expectation and operators who have gone on our
> >previous release notes that Liberty is ready to rock will feel screwed
> >over.
> >
> >So based on the above I am +1 to get upgrades into Liberty, I hope this
> >makes sense.
> >
> >Regards,
> >-Paul
> >
> >[0]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081467.ht
> >ml
> >
> >On 07/03/16 16:00, Sam Yaple wrote:
> >> On Mon, Mar 7, 2016 at 3:03 PM, Steven Dake (stdake)  >> > wrote:
> >>
> >> Hi folks,
> >>
> >> It was never really discussed if we would back-port upgrades to
> >> liberty.  This came up during  an irc conversation Friday [1], and a
> >> vote was requested.  Tthe facts of the discussion distilled are:
> >>
> >>   * We never agreed as a group to do back-port of upgrade during our
> >> back-port discussion
> >>   * An operator that can't upgrade her Z version of Kolla (1.1.1
> >> from 1.1.0) is stuck without CVE or OSSA corrections.
> >>   * Because of a lack of security upgrades, the individual
> >> responsible for executing the back-port would abandon the work
> >> (but not tuse the abaondon feature for of gerrit for changes
> >> already in the queue)
> >>
> >> Since we never agreed, in that IRC discussion a vote was requested,
> >> and I am administering the vote.  The vote request was specifically
> >> should we have a back-port of upgrade in 1.1.0.  Both parties agreed
> >> they would live with the results.
> >>
> >> I would like to point out that not porting upgrades means that the
> >> liberty branch would essentially become abandoned unless some other
> >> brave soul takes up a backport.  I would also like to point out that
> >> that is yet another exception much like thin-containers back-port
> >> which was accepted.  See how exceptions become the way to the dark
> >> side.  We really need to stay exception free going forward (in
> >> Mitaka and later) as much as possible to prevent expectations that
> >> we will make exceptions when none should be made.
> >>
> >> This is not an exception. This was always a requirement. If you disagree
> >> with that then we have never actually had a stable branch. The fact is
> >> we _always_ needed z version upgrades for Kolla. It was _always_ the
> >> plan to have them. Feel free to reference the IRC logs and our prior
> >> mid-cycle and our Tokyo upgrade sessions. What changed was time and
> >> peoples memories and that's why this is even a conversation.
> >>
> >> Please vote +1 (backport) or ­1 (don¹t backport).  An abstain in
> >> this case is the same as voting ­1, so please vote either way.  I
> >> will leave the voting open for 1 week until April 14th.  If there I
> >> a majority in favor, I will close voting early.  We currently
> >> require 6 votes for majority as our core team consists of 11 people.
> >>
> >> Regards,
> >> -steve
> >>
> >>
> >> [1]
> >>
> >>
> http://eavesdrop.openstack.org/irclogs/%23kolla/%23kolla.2016-03-04.log.h
> >>tml#t2016-03-04T18:23:26
> >>
> >> Warning [1] was a pretty heated argument and there may have been
> >> some swearing :)
> >>
> >> voting.
> >>
> >> "Should we 

Re: [openstack-dev] [kolla][vote] Proposing Alicja Kwasniewska for core reviewer

[Martin André]

+1

On Tue, Mar 8, 2016 at 12:48 AM, Sam Yaple  wrote:

> +1 Keep up the great reviews and patches!
>
> Sam Yaple
>
> On Mon, Mar 7, 2016 at 3:41 PM, Jeff Peeler  wrote:
>
>> +1
>>
>> On Mon, Mar 7, 2016 at 3:57 AM, Michal Rostecki 
>> wrote:
>> > +1
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][security] Obtaining the vulnerability:managed tag

[Martin André]

On Wed, Mar 2, 2016 at 1:55 AM, Steven Dake (stdake) 
wrote:

> Core reviewers,
>
> Please review this document:
>
> https://github.com/openstack/governance/blob/master/reference/tags/vulnerability_managed.rst
>
> It describes how vulnerability management is handled at a high level for
> Kolla.  When we are ready, I want the kolla delivery repos vulnerabilities
> to be managed by the VMT team.  By doing this, we standardize with other
> OpenStack processes for handling security vulnerabilities.
>
> The first step is to form a kolla-coresec team, and create a separate
> kolla-coresec tracker.  I have already created the tracker for
> kolla-coresec and the kolla-coresec team in launchpad:
>
> https://launchpad.net/~kolla-coresec
>
> https://launchpad.net/kolla-coresec
>
> I have a history of security expertise, and the PTL needs to be on the
> team as an escalation point as described in the VMT tagging document
> above.  I also need 2-3 more volunteers to join the team.  You can read the
> requirements of the job duties in the vulnerability:managed tag.
>
> If your interested in joining the VMT team, please respond on this
> thread.  If there are more then 4 individuals interested in joining this
> team, I will form the team from the most active members based upon liberty
> + mitaka commits, reviews, and PDE spent.
>

How many more cores do you need? If you don't have enough volunteers you
can sign me up for it.

Martin
__
OpenStack Development Mailing 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] Decision of how to manage stable/liberty from Kolla Midcycle

[Martin André]

On Wed, Feb 17, 2016 at 3:15 AM, Steven Dake (stdake) 
wrote:

> Hey folks,
>
> We held a midcycle Feb 9th and 10th.  The full notes of the midcycle are
> here:
> https://etherpad.openstack.org/p/kolla-mitaka-midcycle
>
> We had 3 separate ~40 minute sessions on making stable stable.  The reason
> for so many sessions on this topic were that it took a long time to come to
> an agreement about the problem and solution.
>
> There are two major problems with stable:
> Stable is hard-pinned to 1.8.2 of docker.  Ansible 1.9.4 is the last
> version of Ansible in the 1 z series coming from Ansible.  Ansible 1.9.4
> docker module is totally busted with Docker 1.8.3 and later.
>
> Stable uses data containers.  Data containers used with Ansible can
> result, in some very limited instances, such as an upgrade of the data
> container image, *data loss*.  We didn't really recognize this until
> recently.  We can't really fix Ansible to behave correctly with the data
> containers.
>
> The solution:
> Use the kolla-docker.py module to replace ansible's built in docker
> module.  This is not a fork of that module from Ansible's upstream so it
> has no GPLv3 licensing concerns.  Instead its freshly written code in
> master.  This allows the Kolla upstream to implement support for any
> version of docker we prefer.
>
> We will be making 1.9 and possibly 1.10 depending on the outcome of a thin
> containers vote the minimum version of docker required to run
> stable/liberty.
>
> We will be replacing the data containers with named volumes.  Named
> volumes offer a similar functionality (persistent data containment) in a
> different implementation way.  They were introduced in Docker 1.9, because
> data containers have many shortcomings.
>
> This will require some rework on the playbooks.  Rather then backport the
> 900+ patches that have entered master since liberty, we are going to
> surgically correct the problems with named volumes.  We suspect this work
> will take 4-6 weeks to complete and will be less then 15 patches on top of
> stable/liberty.  The numbers here are just estimates, it could be more or
> less, but on that order of magnitude.
>
> The above solution is what we decided we would go with, after nearly 3
> hours of debate ;)  If I got any of that wrong, please feel free to chime
> in for folks that were there.  Note there was a majority of core reviewers
> present, and nobody raised objection to this plan of activity, so I'd
> consider it voted and approved :)  There was not a majority approval for
> another proposal to backport thin containers for neutron which I will
> handle in a separate email.
>

As one of the core reviewers that couldn't make it to the mid-cycle I want
to say that I fully agree with this plan.


> Going forward, my personal preference is that we make stable branches a
> low-rate-of-change branch, rather then how it  is misnamed to to imply a
> high rate of backports to fix problems.  We will have further design
> sessions about stable branch maintenance at the Austin ODS.
>

In all fairness, we're still pretty early in the life of Kolla, I expect
the rate of backports to slow down naturally over time.

Martin

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

Re: [openstack-dev] [kolla] Nominating Lei Zhang (Jeffrey Zhang in English) - jeffrey4l on irc

[Martin André]

On Tue, Jan 19, 2016 at 6:36 PM, Michal Rostecki 
wrote:

> On 01/19/2016 10:20 AM, Paul Bourke wrote:
>
>> I was also thinking of adding Lei. He was a big help to me only recently
>> with fixing plugin support and adding unit test support to build.py. +1
>> from me.
>>
>> -Paul
>>
>> On 19/01/16 08:26, Steven Dake (stdake) wrote:
>>
>>> Hi folks,
>>>
>>> I would like to propose Lei Zhang for our core reviewer team.  Count
>>> this proposal as a +1 vote from me.  Lei has done a fantastic job in his
>>> reviews over the last 6 weeks and has managed to produce some really
>>> nice implementation work along the way.  He participates in IRC
>>> regularly, and has a commitment from his management team at his employer
>>> to work full time 100% committed to Kolla for the foreseeable future
>>> (although things can always change in the future :)
>>>
>>> Please vote +1 if you approve of Lei for core reviewer, or –1 if wish to
>>> veto his nomination.  Remember just one –1 vote is a complete veto, so
>>> if your on the fence, another option is to abstain from voting.
>>>
>>> I would like to change from our 3 votes required, as our core team has
>>> grown, to requiring a simple majority of core reviewers with no veto
>>> votes.  As we have 9 core reviewers, this means Lei requires 4 more  +1
>>> votes with no veto vote in the voting window to join the core reviewer
>>> team.
>>>
>>> I will leave the voting open for 1 week as is the case with our other
>>> core reviewer nominations until January 26th.  If the vote is unanimous
>>> or there is a veto vote before January 26th I will close voting.  I'll
>>> make appropriate changes to gerrit permissions if Lei is voted into the
>>> core reviewer team.
>>>
>>> Thank you for your time in evaluating Lei for the core review team.
>>>
>>> Regards
>>> -steve
>>>
>>>
> +1
>
> He did amazing job on plugins, unit tests and introducing oslo.config.


Big +1 for me.

Martin


> __
> OpenStack Development Mailing List (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] Please vote -> Removal of Harm Weites from the core reviewer team

[Martin André]

On Sat, Jan 16, 2016 at 5:34 AM, Harm Weites  wrote:

> Hi guys,
>
> As Steven noted, activity from my side has dropped significantly, and with
> +2 comes a certain responsibility of at the very least keeping track of the
> codebase. Various reasons keep me from even doing that so this seems the
> logical outcome.
>
> Thanks for your support, it’s been a great ride :)
>
> see you in #kolla!
>

Harm, I know from experience it's difficult to keep up to date with Kolla's
codebase, even after a small hiatus. Thanks for your helpful reviews. I
hope we'll see you again soon among the core reviewers.

Martin


> Op 15 jan. 2016, om 20:10 heeft Steven Dake (stdake) 
> het volgende geschreven:
>
> I counted 6 votes in favor of removal.  We have 10 people on our core
> team.  A majority has been met and I have removed Harm from the core
> reviewer team.
>
> Harm,
>
> Thanks again for your helpful reviews and remember, your always welcome
> back in the future if your availability changes.
>
> For the record, the core reviewers that voted for removal were:
> Steven Dake
> Jeff Peeler
> Paul Bourke
> Michal Jastrzebski
> Ryan Hallisey
> Michal Rostecki
>
> Regards,
> -steve
>
>
> From: Steven Dake 
> Reply-To: openstack-dev 
> Date: Thursday, January 14, 2016 at 5:12 PM
> To: openstack-dev 
> Subject: [openstack-dev] [kolla] Please vote -> Removal of Harm Weites
> from the core reviewer team
>
> Hi fellow core reviewers,
>
> Harm joined Kolla early on with great enthusiasm and did a bang-up job for
> several months working on Kolla.  We voted unanimously to add him to the
> core team.  Over the last 6 months Harm hasn't really made much
> contribution to Kolla.  I have spoken to him about it in the past, and he
> indicated his work and other activities keep him from being able to execute
> the full job of a core reviewer and nothing environmental is changing in
> the near term that would improve things.
>
> I faced a similar work/life balance problem when working on Magnum as a
> core reviewer and also serving as PTL for Kolla.  My answer there was to
> step down from the Magnum core reviewer team [1] because Kolla needed a PTL
> more then Magnum needed a core reviewer.  I would strongly prefer if folks
> don't have the time available to serve as a Kolla core reviewer, to step
> down as was done in the above example.  Folks that follow this path will
> always be welcome back as a core reviewer in the future once they become
> familiar with the code base, people, and the project.
>
> The other alternative to stepping down is for the core reviewer team to
> vote to remove an individual from the core review team if that is deemed
> necessary.  For future reference, if you as a core reviewer have concerns
> about a fellow core reviewer's performance, please contact the current PTL
> who will discuss the issue with you.
>
> I propose removing Harm from the core review team.  Please vote:
>
> +1 = remove Harm from the core review team
> -1 = don't remove Harm from the core review team
>
> Note folks that are voted off the core review team are always welcome to
> rejoin the core team in the future once they become familiar with the code
> base, people, and the project.  Harm is a great guy, and I hope in the
> future he has more time available to rejoin the Kolla core review team
> assuming this vote passes with simple majority.
>
> It is important to explain why, for some folks that may be new to a core
> reviewer role (which many of our core reviewers are), why a core reviewer
> should have their +2/-2 voting rights removed when they become inactive or
> their activity drops below an acceptable threshold for extended or
> permanent periods.  This hasn't happened in Harm's case, but it is possible
> that a core reviewer could approve a patch that is incorrect because they
> lack sufficient context with the code base.  Our core reviewers are the
> most important part of ensuring quality software.  If the individual has
> lost context with the code base, their voting may be suspect, and more
> importantly the other core reviewers may not trust the individual's votes.
> Trust is the cornerstone of a software review process, so we need to
> maximize trust on a technical level between our core team members.  That is
> why maintaining context with the code base is critical and why I am
> proposing a vote to remove Harm from the core reviewer team.
>
> On a final note, folks should always know, joining the core review team is
> never "permanent".  Folks are free to move on if their interests take them
> into other areas or their availability becomes limited.  Core Reviewers can
> also be removed by majority vote.  If there is any core reviewer's
> performance you are concerned with, please contact the current PTL to first
> work on improving performance, or alternatively initiating a core reviewer
> removal 

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

[Martin André]

On Sun, Jan 17, 2016 at 1:29 PM, Steven Dake (stdake) 
wrote:

> Ryan,
>
> I read your response and the idea of incubators is interesting, but the
> risk there is we will end up with "two core teams" with different
> objectives, purpose, focus, and most importantly a lack of coordinated
> efforts and thinking.  I'd like to experiment with converting two of our
> meetings to an apac timezone meeting, since the main problem I think at
> the moment is some folks in apac can't participate in our weekly meetings.
>
> How do folks feel about that idea?
>

Steve, the risk in doing so is to have two completely different groups of
core reviewers attending the different meetings. I would be opposed for
example to an APAC friendly meeting time where you and other highly active
members can't join. We've tried in the past and it didn't work well. Maybe
now we'll be able to get more people attend the APAC friendly meeting.
Basically I'm not in favor of anything that would split up the community,
kolla-* projects should all work toward a common goal.

Angus, I feel your pain. The meeting is at 1:30 am for me (for two more
month before I move to EMEA), and I would also be happy with a more decent
meeting time.

Martin


> Thanks
> -steve
>
> Regards
> -steve
>
> On 1/15/16, 6:10 AM, "Ryan Hallisey"  wrote:
>
> >Hello,
> >
> >I think creating a separate kolla-mesos meeting is a good idea. My only
> >issue is that I'm a little afraid it might separate our community a
> >little, but I think it's necessary for kolla-mesos to grow.  My other
> >thought is what is there to come of other kolla-* repos? That being not
> >only kolla-mesos, but in the future kolla-anisble.  Maybe kolla meetings
> >can be an incubator for those repos until they need to move out on their
> >own?  Just a thought here.
> >
> >+1
> >-Ryan
> >
> >- Original Message -
> >From: "Michal Rostecki" 
> >To: openstack-dev@lists.openstack.org
> >Sent: Friday, January 15, 2016 6:38:39 AM
> >Subject: [openstack-dev] [kolla] kolla-mesos IRC meeting
> >
> >Hi,
> >
> >Currently we're discussing stuff about kolla-mesos project on kolla IRC
> >meetings[1]. We have an idea of creating the separate meeting for
> >kolla-mesos. I see the following reasons for that:
> >
> >- kolla-mesos has some contributors which aren't able to attend kolla
> >meeting because of timezone reasons
> >- kolla meetings had a lot of topics recently and there was a short time
> >for discussing kolla-mesos things
> >- in the most of kolla meetings, we treated the whole kolla-mesos as one
> >topic, which is bad in terms of analyzing single problems inside this
> >project
> >
> >The things I would like to know from you is:
> >- whether you're +1 or -1 to the whole idea of having separate meeting
> >- what is your preferred time of meeting - please use this etherpad[2]
> >(I already added there some names of most active contributors from who
> >I'd like to hear an opinion, so if you're interested - please "override
> >color"; if not, remove the corresponding line)
> >
> >About the time of meeting and possible conflicts - I think that in case
> >of conflicting times and the equal number of votes, opinion of core
> >reviewers and people who are already contributing to the project
> >(reviews and commits) will be more important. You can see the
> >contributors here[3][4].
> >
> >[1] https://wiki.openstack.org/wiki/Meetings/Kolla
> >[2] https://etherpad.openstack.org/p/kolla-mesos-irc-meeting
> >[3] http://stackalytics.com/?module=kolla-mesos
> >[4] http://stackalytics.com/?module=kolla-mesos=commits
> >
> >Cheers,
> >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
> >
> >__
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Proposing Michal Rostecki for Core Reviewer (nihilfer on IRC)

[Martin André]

+1!

On Sat, Nov 14, 2015 at 4:32 AM, Harm Weites  wrote:

> +1 :)
>
> Jeff Peeler schreef op 2015-11-13 19:51:
>
>> On 12/11/15 08:41, Steven Dake (stdake) wrote:
>>>
>>> Hey folks,
>>>
>>> Its been awhile since we have had a core reviewer nomination, but I
>>> really feel like Michal has the right stuff. If you look at the 30 day
>>> stats for kolla[1] , he is #3 in reviews (70 reviews) with 6 commits in
>>> a 30 day period. He is beating 2/3rds of our core reviewer team on all
>>> stats. I think his reviews, while could use a little more depth, are
>>> solid and well considered. That said he participates on the mailing
>>> list more then others and has been very active in IRC. He has come up
>>> to speed on the code base in quick order and I expect if he keeps pace,
>>> the top reviewers in Kolla will be challenged to maintain their spots :)
>>> Consider this proposal as a +1 vote from me.
>>>
>>> As a reminder, our core review process requires 3 core reviewer +1
>>> votes, with no core reviewer –1 (veto) votes within a 1 week period. If
>>> your on the fence, best to abstain :) I'll close voting November 20th,
>>> or sooner if there I a veto vote or a unanimous vote.
>>>
>>> Regards
>>> -steve
>>>
>>> http://stackalytics.com/report/contribution/kolla-group/30
>>>
>>
>> +1!
>>
>>___
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (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] proposing Michal Jastrzebski (inc0) for core reviewer

[Martin André]

On Wed, Sep 30, 2015 at 7:20 AM, Steven Dake (stdake) 
wrote:

> Hi folks,
>
> I am proposing Michal for core reviewer.  Consider my proposal as a +1
> vote.  Michal has done a fantastic job with rsyslog, has done a nice job
> overall contributing to the project for the last cycle, and has really
> improved his review quality and participation over the last several months.
>
> Our process requires 3 +1 votes, with no veto (-1) votes.  If your
> uncertain, it is best to abstain :)  I will leave the voting open for 1
> week until Tuesday October 6th or until there is a unanimous decision or a
>  veto.
>

+1, without hesitation.

Martin


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

Re: [openstack-dev] [kolla] Followup to review in gerrit relating to RHOS + RDO types

[Martin André]

On Thu, Sep 17, 2015 at 3:22 AM,  wrote:

> There is an apparent need for having official RHOS being supported from
> our end, and we just so happen to have the possibility of filling that
> need. Should the need arise to support whatever fancy proprietary backend
> system or even have Kolla integrate with Oracle Solaris or something, that
> need would most probably be backed by a company plus developer effort. I
> believe the burden for our current (great) team would more or less stay the
> same (eg. lets assume we don't know anything about Solaris), so this
> company should ship in devvers to aid their 'wish'. The team effort with
> these additional devvers would indeed grow, bigtime. Keeping our eyes on
> the matters feels like a fair solution, allowing for these additions while
> guarding the effort they take. Should Kolla start supporting LXC besides
> Docker, that would be awesome (uhm...) - but I honestly don't see a need to
> be thinking about that right now, if someone comes up with a spec about it
> and wants to invest time+effort we can atleast review it. We shouldn't
> prepare our Dockerfiles for such a possibility though, whereas the
> difference between RHOS and CentOS is very little. Hence, support is rather
> easy to implement.
>
> The question was if Kolla wants/should support integrating with 3rd party
> tools, and I think we should support it. There should be rules, yes. We
> probably shouldn't be worrying about proprietary stuff that other projects
> hardly take seriously (even though drivers have been accepted)...
>
> Vote: +1
>
> - harmw
>
> Sam Yaple schreef op 2015-09-14 13:44:
>
>> On Mon, Sep 14, 2015 at 11:19 AM, Paul Bourke 
>> wrote:
>>
>> On 13/09/15 18:34, Steven Dake (stdake) wrote:
>>>
>>> Response inline.

 From: Sam Yaple >
 Reply-To: "s...@yaple.net"
 >
 Date: Sunday, September 13, 2015 at 1:35 AM
 To: Steven Dake >
 Cc: "OpenStack Development Mailing List (not for usage
 questions)"


>>>   tack-...@lists.openstack.org> openstack-dev@lists.openstack.org>>
>>
>>> Subject: Re: [kolla] Followup to review in gerrit relating to
 RHOS + RDO types

 On Sun, Sep 13, 2015 at 3:01 AM, Steven Dake (stdake)
 > wrote:
 Response inline.

 From: Sam Yaple >
 Reply-To: "s...@yaple.net"
 >
 Date: Saturday, September 12, 2015 at 11:34 PM
 To: Steven Dake >
 Cc: "OpenStack Development Mailing List (not for usage
 questions)"


>>>   tack-...@lists.openstack.org> openstack-dev@lists.openstack.org>>
>>
>>> Subject: Re: [kolla] Followup to review in gerrit relating to
 RHOS + RDO types

 Sam Yaple

 On Sun, Sep 13, 2015 at 1:15 AM, Steven Dake (stdake)
 > wrote:

 From: Sam Yaple >
 Reply-To: "s...@yaple.net"
 >
 Date: Saturday, September 12, 2015 at 11:01 PM
 To: Steven Dake >
 Cc: "OpenStack Development Mailing List (not for usage
 questions)"


>>>   tack-...@lists.openstack.org> openstack-dev@lists.openstack.org>>
>>
>>> Subject: Re: [kolla] Followup to review in gerrit relating to
 RHOS + RDO types

 On Sun, Sep 13, 2015 at 12:39 AM, Steven Dake (stdake)
 > wrote:
 Hey folks,

 Sam had asked a reasonable set of questions regarding a patchset:
 https://review.openstack.org/#/c/222893/ [1]


 The purpose of the patchset is to enable both RDO and RHOS as
 binary choices on RHEL platforms.  I suspect over time,
 from-source deployments have the potential to become the norm, but
 the business logistics of such a change are going to take some
 significant time to sort out.

 Red Hat has two distros of OpenStack neither of which are from
 source.  One is free called RDO and the other is paid called
 RHOS.  In order to obtain support for RHEL VMs running in an
 OpenStack cloud, you must be running on RHOS RPM binaries.  You
 must also be running on RHEL.  It remains to be seen whether Red
 Hat will actively support Kolla deployments with a RHEL+RHOS set
 of packaging in containers, but my hunch says they will.  It is
 in Kolla’s best interest to implement this model and not make it
 hard on Operators since many of them do indeed want Red Hat’s
 support structure for their OpenStack deployments.

 Now to Sam’s questions:

Re: [openstack-dev] [kolla] Proposing Swapnil Kulkarni (coolsvap) for kolla core reviewer team

[Martin André]

On Fri, Aug 14, 2015 at 3:29 PM, Steven Dake (stdake) std...@cisco.com
wrote:

 Hi folks,

 Swapnil has done a bunch of great technical work, participates heavily in
 IRC, and has contributed enormously to the implementation of Kolla.  I’d
 like to see more reviews from Swapnil, but he has committed to doing more
 reviews and already has gone from something like 0 reviews to 90 reviews in
 about a month.  Count this proposal as a +1 from me.

 His 90 day stats are:
 http://stackalytics.com/report/contribution/kolla-group/90

 The process we go to select new core reviewers is that we require a
 minimum of 3 +1 votes within a 1 week voting window.  A vote of –1 is a
 veto.  It is fine to abstain as well without any response to this email.
 If the vote is unanimous or there is a veto vote prior to the end of the
 voting window, I’ll close voting then.

 The voting is open until Friday August 21st.


I'm abstaining from the vote as I haven't been very involved lately and
feel I can't judge on Swapnil's work. That being said, I entirely trust
other cores' judgment and am sure he'll be an excellent kolla core.

Martin



 __
 OpenStack Development Mailing List (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] Mission change suggested by the TC for big tent

[Martin André]

On Mon, Aug 3, 2015 at 5:47 PM, Steven Dake (stdake) std...@cisco.com
wrote:



 On 7/30/15, 4:26 PM, Doug Hellmann d...@doughellmann.com wrote:

 Excerpts from Steven Dake (stdake)'s message of 2015-07-30 15:27:15 +:
 
  On 7/29/15, 1:23 PM, Doug Hellmann d...@doughellmann.com wrote:
 
  Excerpts from Steven Dake (stdake)'s message of 2015-07-29 20:07:26
 +:
   Doug Hellman of the TC suggested we change the mission statement of
  Kolla to be a little less specific.  The new mission statement I
  submitted in the review is here Is basically cutting off the last part
  of the mission statement sentence:
  
   https://review.openstack.org/#/c/206789/
  
   If your a Kolla core eviewer, please vote ­1 (indicating you are a
 core
  reviewer in the review) if you dislike this change and think we should
  strive to keep our mission unchanged.  If you don¹t really have a
 strong
  preference, please abstain from voting as to not add non-useful
  information to the review.  Our core team knows what our true mission
 is
  and I don¹t think Doug¹s wording changes the mission significantly.
  
  My intent is not to change it at all, but to remove the marketing
  fluff, to be consistent with the nature of the missions described
  by most of the other projects.  By all means, hold to those other
  ideals and goals, but in the project list we want the mission to
  say what you're doing as clearly and concisely as possible.
  
  Doug
 
  Doug,
 
  Its all good, I think the change you suggested simplifies the statement
  without changing the intent.  We can still do all those other things as
  you just indicated if we choose to.
 
  I still want to give the core reviewer team an opportunity to vote on
 the
  change which is why I set the short deadline of Aug 3rd to vote -1 (and
  act as a veto vote) which would trigger irc meetings to rework the
 mission
  statement.
 
 Sure, having the team vote  comment is absolutely appropriate, I
 just wanted to clarify the reasons for the change. :-)

 Doug,

 I communicated with all but one of our core reviewers (Martin Andre) who
 is moving countries ATM and the core reviewer team are +1 on the mission
 statement change.  I’m not sure when Martin gets settled, and I don’t want
 to block.  Knowing Martin, he wouldn’t have a strong opinion on the matter.


More precisely, I'm taking time off between jobs, with intermittent access
to the internet :)

To get back to the point, I have no objection to simplify the mission
statement as suggested by Doug, and I'm glad to see Kolla on its way to
join the big tent.

Regards,
Martin


 Regards
 -steve

 
  Thanks for the good feedback, I actually think the modified mission
  statement is faster to say which is always a good thing :)
 
 ++
 
 Doug
 
 
  Regards
  -steve
 
  
  
   I¹ll keep the schedule open until August 3rd and ask the TC to hold
 off
  on approving the submitted mission until the core team has not weighed
  in with a ­1 vote.  A vote of ­1 will count as a veto from the core
  reviewer team, and we will have to have some kind of
 super-brainstorming
  session like we did before to simplify the Kolla mission statement to
  something the TC would accept.
  
   Regards
   -steve
  
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

__
OpenStack Development Mailing 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] Proposal for Paul Bourke for Kolla Core

[Martin André]

On Tue, Jul 14, 2015 at 11:40 AM, Steven Dake (stdake) std...@cisco.com
wrote:

  Hey folks,

  I am proposing Paul Bourke for the Kolla core team.  He did a fantastic
 job getting Kolla into shape to support multiple distros and from
 source/from binary installation.  His statistics are fantastic including
 both code and reviews.  His reviews are not only voluminous, but
 consistently good.  Paul is helping on many fronts and I would feel make a
 fantastic addition to our core reviewer team.

  Consider my proposal to count as one +1 vote.

  Any Kolla core is free to vote +1, abstain, or vote –1.  A –1 vote is a
 veto for the candidate, so if you are on the fence, best to abstain :)  We
 require 3 core reviewer votes to approve a candidate.  I will leave the
 voting open until July 20th  UTC.  If the vote is unanimous prior to
 that time or a veto vote is received, I’ll close voting and make
 appropriate adjustments to the gerrit groups.

  Regards
 -steve


+1
No hesitation, Paul's contribution have always been excellent.

Martin


 __
 OpenStack Development Mailing List (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