Re: [openstack-dev] [TripleO] Let's use Ansible to deploy OpenStack services on Kubernetes

[Ryan Hallisey]

> I think this at some point might be single biggest benefit of using
> helm on the long run - leverage infrastructure charts that aren't
> openstack-centric. Things like etcd are already written and
> potentially we can just help support them.

I think the tools that are being discussion here are both very good
(helm & ansible), but I have a slightly different opinion about how
Helm should be used.

Helm is a *package manager*. It's scope is for simple applications
that need to bundle resources.  It's great at saving me time on doing
simple recipes like: kubectl create -f  and kubectl create -f
 over and over again. But, beyond a single app with a few
resources, Helm is going to struggle on it's own. Meaning, either Helm
would have to change or another tool would have to fill the gaps.

If Helm wants to change, it becomes less differentiated from what
Ansible already does. It's niche as a simple app package manager will
evaporate and Ansible already owns the orchestration space. Therefore,
I think long term Helm as an orchestration tool doesn't make sense
because it's limited to Kubernetes and Ansible adoption is wide
spread.

That doesn't mean that Helm is useless.  In fact, I think the Helm
charts are great when used as simple standalone recipes. However, for
a complex app like OpenStack, I think you need something like Ansible
to provide the orchestration. Underneath, you can use whatever you
want to create the Kubernetes resources. In the end, the difference
will be `helm create mariadb` vs `kubectl create -f mariadb-pod.yaml`.
Both solutions will work, but the Helm work seems to be much farther
along.

One other thing to mention. Maybe folks can speed up writing these
playbooks by using kolla-ansible's playbooks as a shell. Here's an
example: [1] Take lines 1-16 and replace it with helm install mariadb
or
kubectl create -f mariabd-pod.yaml and set inventory to localhost.
Just a thought.

There may be some other playbooks out there I don' know about that you
can use, but that could at least get some of the collaboration started
so folks don't have to start from scratch.

[1] - 
https://github.com/openstack/kolla-ansible/blob/afdd11b9a22ecca70962a4637d89ad50b7ded2e5/ansible/roles/mariadb/tasks/start.yml#L1-L16

Sincerely,
Ryan

On Mon, Jul 17, 2017 at 1:37 PM, Michał Jastrzębski  wrote:
> On 17 July 2017 at 10:13, Emilien Macchi  wrote:
>> On Mon, Jul 17, 2017 at 5:32 AM, Flavio Percoco  wrote:
>>> On 14/07/17 08:08 -0700, Emilien Macchi wrote:

 On Fri, Jul 14, 2017 at 2:17 AM, Flavio Percoco  wrote:
>
>
> Greetings,
>
> As some of you know, I've been working on the second phase of TripleO's
> containerization effort. This phase if about migrating the docker based
> deployment onto Kubernetes.
>
> These phase requires work on several areas: Kubernetes deployment,
> OpenStack
> deployment on Kubernetes, configuration management, etc. While I've been
> diving
> into all of these areas, this email is about the second point, OpenStack
> deployment on Kubernetes.
>
> There are several tools we could use for this task. kolla-kubernetes,
> openstack-helm, ansible roles, among others. I've looked into these tools
> and
> I've come to the conclusion that TripleO would be better of by having
> ansible
> roles that would allow for deploying OpenStack services on Kubernetes.
>
> The existing solutions in the OpenStack community require using Helm.
> While
> I
> like Helm and both, kolla-kubernetes and openstack-helm OpenStack
> projects,
> I
> believe using any of them would add an extra layer of complexity to
> TripleO,
> which is something the team has been fighting for years years -
> especially
> now
> that the snowball is being chopped off.
>
> Adopting any of the existing projects in the OpenStack communty would
> require
> TripleO to also write the logic to manage those projects. For example, in
> the
> case of openstack-helm, the TripleO team would have to write either
> ansible
> roles or heat templates to manage - install, remove, upgrade - the charts
> (I'm
> happy to discuss this point further but I'm keepping it at a high-level
> on
> purpose for the sake of not writing a 10k-words-long email).
>
> James Slagle sent an email[0], a couple of days ago, to form TripleO
> plans
> around ansible. One take-away from this thread is that TripleO is
> adopting
> ansible more and more, which is great and it fits perfectly with the
> conclusion
> I reached.
>
> Now, what this work means is that we would have to write an ansible role
> for
> each service that will deploy the service on a Kubernetes cluster.
> Ideally
> these
> roles will also generate the configuration files (removing the need of
> puppet
> entirely) and they would manage the lifecycle. The

Re: [openstack-dev] [kolla][kubernetes] kolla channel in Kubernetes slack

[Ryan Hallisey]

The topic wasn't very clear.  Fixing that...

-Ryan

- Original Message -
From: "Ryan Hallisey" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, November 21, 2016 1:48:51 PM
Subject: [openstack-dev] [kolla][kubernetes] kolla slack channel

Hey folks,

I spoke with the Kubernetes community manager about the interop
between Openstack and Kubernetes with respect to Kolla.  We agreed
that it would make sense to have a channel in the Kubernetes Slack
group for kolla.

In addition, we talked about mirroring the slack and irc channels
essentially combining them into one. But, free slack has a group wide
10,000 message cache and Kolla has about 1-2 messages a minute. At
that rate, Kolla would consume about 20% of the total live message
cache.  Since that's large for a single channel, the channels won't
be mirrored at first, but the CNCF is looking at ways to solve this.

For now, can cores please join kolla's slack channel to get use to
having a foot in each community. Especially kolla-kubernetes cores :).

If you haven't used slack it's really easy to get started.  You
can make an account and join the Kubernetes group.  From there,
you'll find kolla listed as one of the channels.

Thanks,
-Ryan

__
OpenStack Development Mailing List (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] [kolla][kubernetes] kolla slack channel

[Ryan Hallisey]

Hey folks,

I spoke with the Kubernetes community manager about the interop
between Openstack and Kubernetes with respect to Kolla.  We agreed
that it would make sense to have a channel in the Kubernetes Slack
group for kolla.

In addition, we talked about mirroring the slack and irc channels
essentially combining them into one. But, free slack has a group wide
10,000 message cache and Kolla has about 1-2 messages a minute. At
that rate, Kolla would consume about 20% of the total live message
cache.  Since that's large for a single channel, the channels won't
be mirrored at first, but the CNCF is looking at ways to solve this.

For now, can cores please join kolla's slack channel to get use to
having a foot in each community. Especially kolla-kubernetes cores :).

If you haven't used slack it's really easy to get started.  You
can make an account and join the Kubernetes group.  From there,
you'll find kolla listed as one of the channels.

Thanks,
-Ryan

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

[Ryan Hallisey]

+1

-Ryan

- Original Message -
From: "Michał Jastrzębski" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Wednesday, November 16, 2016 1:23:27 PM
Subject: [openstack-dev] [kolla][kolla-ansible][kolla-kubernetes] Kolla core 
election policy change - vote

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


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

[openstack-dev] [kolla][kubernetes] kolla-kubernetes spec voting delay

[Ryan Hallisey]

Hey folks,

There has been a lot of input in the spec and tons IRC discussion
over the last two days.  I'm glad the discussion is very active :).

The goal of the spec is to capture the ideas and the discussion in
one readable doc so no one has to read the 1 lines of IRC
discussion that has occurred. Right now, the spec reflects about 95%
of the discussion so it isn't complete. Therefore, voting will be
delayed at least another day from the deadline I set (today).

Thanks,
-Ryan

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

__
OpenStack Development Mailing 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][kubernetes]kolla-kubernetes achitectures spec

[Ryan Hallisey]

Forgot to include the link to the spec :)

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

Thanks,
Ryan

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

[openstack-dev] [kolla][kubernetes]kolla-kubernetes achitectures spec

[Ryan Hallisey]

Hey folks,

The kolla-kubernetes architecture spec has been under review
for a day now. The plan is to keep it open for 7 days after
the initial review was posted (November 8th).  Therefore, voting on
the spec will commence on November 15th. So be sure to add any input
you may have before that date.

For folks that are curious about OpenStack on Kubernetes, it is worth a
read since there are a lot of good ideas being thrown around.

Thanks,
-Ryan

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

Re: [openstack-dev] [kolla] Propose removal of TrivialFix requirement

[Ryan Hallisey]

+1

-Ryan

- Original Message -
From: "Swapnil Kulkarni" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Friday, November 4, 2016 8:48:49 AM
Subject: Re: [openstack-dev] [kolla] Propose removal of TrivialFix  
requirement

On Thu, Nov 3, 2016 at 6:51 PM, Paul Bourke  wrote:
> 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?
>
> 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

I feel TrivialFix is consistently used by people just to avoid going
to lanuchpad and filing a bug. It should only be used only if the "Fix
is Trivial"
This has been well documented in the contributing doc [1] and this
should be referred to people when they do not have the bug/bp in the
commit message.

If the commits are important then there is no harm in creating a
tracking bug for it.
It would take 1/30(I am just making highest time for a build/deploy
gate) amount of time you need to verify the (important)fix on gate.

[1] docs.openstack.org/developer/kolla/CONTRIBUTING.html

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

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

[openstack-dev] kolla-kubernetes Ocata goals [kolla][kubernetes]

[Ryan Hallisey]

Hey folks,

I wanted to highlight some of the discussion that was held at summit
and outline goals for kolla-kubernetes in the Ocata cycle.

The number one goal for the kolla-kubernetes project in the Ocata cycle is to
have a 1.0 release. As discussed at summit, the community is going to pursue 
Helm,
the Kubernetes package manager, as the means for deployment. The goal is to have
Helm fill the gap for orchestration that is challenging to solve with only 
native
Kubernetes.

Action items:
- Spec outlining how the community will use Helm to fill the orchestration gap
  and any missing features with Helm.
- POC using kolla-kubernetes with Helm

For the Ocata cycle and beyond, the community needs to look at the interop 
between
Kubernetes and OpenStack. In order for OpenStack to function best on Kubernetes,
there needs to be features added to both Kubernetes and OpenStack. Since this 
project
exists in both spaces, the community needs to be familiar with and identify 
areas for
improvement in each.

Action items:
- Define the interop between Kubernetes and OpenStack community by mailing list 
or
  spec.

Let's start with these action items to get things rolling post summit.

Thanks,
- Ryan

The etherpads from Summit design sessions for further reading:
https://etherpad.openstack.org/p/kolla-ocata-summit-kolla-k8s-architecture
https://etherpad.openstack.org/p/kolla-ocata-summit-kolla-k8s-road-map

Blueprints:
https://blueprints.launchpad.net/kolla-kubernetes

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

[openstack-dev] Kolla-kubernetes new contributors [kolla][kubernetes][kolla-kubernetes]

[Ryan Hallisey]

Hi all, 

There has been a bunch of new contributors looking for the best way 
to get into kolla-kubernetes community. I want to guide anyone 
interested in joining the community by providing some low hanging 
fruit as well as a few suggestions. 

***Quickstart***

https://github.com/openstack/kolla-kubernetes/blob/master/doc/source/minikube-quickstart.rst

The minikube-quickstart guide is the best doc for getting a single
node deployment working. This guide is what most community members
use and all the steps are tested in the gate.

***Blueprints***

https://blueprints.launchpad.net/kolla-kubernetes 

First is the launchpad link to the kolla-kubernetes blueprints. I'd
recommend bookmarking that link because it outlines all the work the
community plans to do in the coming cycles.  All the blueprints have
been described and prioritized. If you want to take on a piece of work
there, assign it to yourself or ask a member of the community to
assign it to you. 

***Low Hanging Fruit***

https://blueprints.launchpad.net/kolla-kubernetes/+spec/cli-replace
- Add kubectl replace command support into the CLI

https://blueprints.launchpad.net/kolla-kubernetes/+spec/cluster-map 
- Add a CLI feature that provides a map of services in the cluster.

https://blueprints.launchpad.net/kolla-kubernetes/+spec/dry-run-cli
- The --dry-run flag in the CLI will output all the necessary CLI
commands to start a service.

There's also the remaining services that don't have pods created
for them: Swift, Heat, Ceilometer, MongoDB, ect... The best way
to implement a service is to follow an existing template.

***IRC and Meetings***

The community hangs out in the #openstack-kolla channel on freenode.
Kolla-kubernetes has a slot in the Kolla weekly meeting to discuss
what's going on in the community. Meetings are on Wednesdays at
16:00 UTC in #openstack-meeting-4. If you're going to OpenStack
Summit in Barcelona, there are two scheduled kolla-kubernetes
sessions so be sure not to miss those. In addition, feel free to
reach out to me if you have any questions or want to discuss
anything about the project.

Thanks,
Ryan


__
OpenStack Development Mailing 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][fuel][tripleo] Reference architecture to deploy OpenStack on k8s

[Ryan Hallisey]

Thanks for starting the discussion Fabio.

> As someone that started looking into this topic just recently, I'd love to see
> our communities collaborate more wherever possible. For example, it'd be great
> to see us working on a reference architecture for deploying OpenStack on
> kubernetes, letting the implementation details aside for a bit. I'd assume 
> some
> folks have done this already and I bet we can all learn more from it if we 
> work
> on this together.

Agreed Flavio. Members of the kolla-kubernetes community have some ideas of
how this will look.  I can put together some diagrams over the weekend to depict
this and maybe others that have some ideas can comment and share theirs.

> So, let me go ahead and ask some further questions here, I might be missing 
> some
> history and/or context:
> - Is there any public documentation that acts as a reference architecture for
>  deploying OpenStack on kubernetes?

These specs [1][2] might be a good start.

> - Is this something the architecture working group could help with? Or would 
> it
>  be better to hijack one of kolla meetings?

kolla-kubernetes has a booked slot in the weekly kolla meetings. This could be
discussed there.

>> So issue is, I know of few other openstacks on k8s and everyone does
>> that slightly differently. So far we lack proof points and real world
>> data to determine best approaches to stuff. This is still not-to-well
>> researched field. Right now it's mostly opinions and assumptions.
>> We're not ready to make document without having a flame war around
>> it;) Not enough knowledge in our collective brains.

> Awesome input, thanks.

Michal is right, there are a bunch of implementations that exist. The tricky
part is pulling together all the groups to figure out the best solution.

When the kolla-kubernetes project was created, my hope that this new repo would
be a place where anyone curious about the OpenStack and Kubernetes interaction
could come and express their opinion in code or conversation. The community 
still
remains open to any changes with it's implementation and the current
implementation is a reflection of who is participating.

I agree that it would be ideal for a single place to collaborate. It would be
awesome to bring together the community that is looking to solve this
problem around a single project. Doesn't matter what that project is, but I'd
like for more collaboration :).

>> As for Kolla-k8s we are still deep in development, so we are free to
>> take best course of action we know of. We don't have any technical
>> debt now. Current state of stuff represents what we thing is best
>> approach.

> I wonder if we can start writing these assumptions down and update them as we
> go. I don't expect you to do it, I'm happy to help with this. We could put it 
> in
> kolla-k8s docs if that makes sense to other kolla-k8s folks.

It's not that Kolla-k8s has tech debt, but rather the community is still 
testing the
waters with its implementation. For instance, the community is looking at a 
workflow
that will execute the deployment of OpenStack and hand off to Kubernetes to 
manage it.
This solution raises some questions: why do you need a workflow at all? Why not
use Kubernetes, a Container Orchestration Engine, to orchestrate the services?  
A lot
of these fundamental questions were outlined in this spec [1] and the answers 
to them
are still WIP [3].

> I'll probably start pinging you guys on IRC with questions so I can help 
> writing
> this down.

That would be fantastic! There's also room for collaboration at summit too.
Kolla-kubernetes will have a design session/fishbowl scheduled.

>> There is also part that k8s is constantly growing and it lacks certain
>> features that created these issues in the first place, if k8s solves
>> them on their side, that will affect decision on our side.

> Thanks a lot, Michal. This is indeed the kind of info I was looking for and
> where I'd love to start from.

Agreed Michal.  The community has been adapting on the fly based on features 
coming
out of Kubernetes.  Things like init containers and petsets were recent features
that have found their way into kolla-kubernetes.

The flow of work in kolla-kubernetes has been following the work items in the
spec [1], but in a different order.  The basic outline for putting OpenStack on
Kubernetes will follow a similar path. Where as things like the templates will
be similar, but the orchestration method can vary. I think that's where the
biggest controversy lies.

Thanks!
-Ryan

[1] - https://review.openstack.org/#/c/304182/
[2] - https://specs.openstack.org/openstack/fuel-specs/specs/10.0/ccp.html
[3] - https://review.openstack.org/#/c/335279/

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

[Ryan Hallisey]

I agree with Michal and Martin. I was a little reluctant to respond here 
because the Debian additions are new, while Fedora has been around since the 
beginning and never got a ton of testing.

Berendt what's your take here?

Thanks,
Ryan 

- Original Message -
From: "Michał Jastrzębski" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Thursday, September 22, 2016 10:42:13 AM
Subject: Re: [openstack-dev] [vote][kolla] deprecation for debian distro
support

I'm also reluctant to deprecation of debian.There are few changes to
ubuntu and it might just work:) However, I'd love to ask whoever would
like us to keep using debian to create gates for it.

I would like to give debian one more release to go and deprecate it if
we fail to create gates in Ocata timeframe, how about that?

On 22 September 2016 at 06:48, Martin André  wrote:
> 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. Th

Re: [openstack-dev] [vote][kolla] deprecation for fedora distro support

[Ryan Hallisey]

option 2

Thanks
-Ryan

- Original Message -
From: "Mauricio Lima" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, September 19, 2016 2:21:51 PM
Subject: Re: [openstack-dev] [vote][kolla] deprecation for fedora distro
support

Option 2 

2016-09-19 14:56 GMT-03:00 Christian Berendt < bere...@betacloud-solutions.de > 
: 


Thanks for moving this forward. 

> On 19 Sep 2016, at 19:40, Jeffrey Zhang < zhang.lei@gmail.com > wrote: 
> 
> 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 

+1 on option 2. 

__ 
OpenStack Development Mailing List (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] Splitting out Ansible into a separate deliverable

[Ryan Hallisey]

Option c.

- Ryan

> On Sep 15, 2016, at 4:33 AM, Paul Bourke  wrote:
> 
> c)   Split the repository shortly after tagging 3.0.0 – creating a 
> kolla-ansible deliverable for Ocata.
> 
>> On 15/09/16 07:12, Steven Dake (stdake) wrote:
>> Core Reviewers:
>> 
>> 
>> 
>> The facts:
>> 
>> We have roughly 250 bugs in rc2.  Of those, I suspect over half can just
>> be closed out as dupes, fixed, wontfix, or the like.
>> 
>> The core reviewer team has had various discussions around splitting the
>> repository at various times but has not come to a concrete conclusion
>> via a vote.
>> 
>> Once RC1 is tagged, the stable/newton branch will be created automatically.
>> 
>> All rc2 bug fixes will require bug IDs and backports to stable/newton to
>> enable the ability to manage the release of rc2 and 3.0.0.
>> 
>> There is an expectation for core reviewers to do the work of backporting
>> to stable/newton – only our backports team typically does this work –
>> however during release we really need everyone’s participation.
>> 
>> 
>> 
>> My understanding of general consensus beliefs:
>> 
>> We believe splitting out the Ansible implementation into a separate
>> repository will produce a better outcome for both Kolla-Ansible and
>> Kolla-Kubernetes
>> 
>> We have been unable to achieve consensus on the right timing for a repo
>> split in the past but generally believe the timing is right at some
>> point between rc1 and Summit or shortly thereafter, if we are to do the
>> repo split during Newton or very early Ocata.)
>> 
>> 
>> 
>> This vote is a multiple choice (one choice please) vote.  Feel free to
>> discuss before making a decision.
>> 
>> 
>> 
>> Please vote:
>> 
>> a)   Do not split the repository between rc1 and Summit or shortly
>> thereafter at all, keeping the Ansible implementation intact in Ocata
>> 
>> b)   Split the repository shortly after tagging RC1 – creating of a
>> kolla-ansible deliverable for Ocata.
>> 
>> c)   Split the repository shortly after tagging 3.0.0 – creating a
>> kolla-ansible deliverable for Ocata.
>> 
>> 
>> 
>> Voting is open for 7 days until September 21^st , 2016. Please do not
>> abstain on this critical vote.  Remember, no veto vote is available in
>> roll-call votes.  If a majority can’t be reached on any one choice, but
>> there is a majority around B & C, (which are the same idea, but
>> different timing) a second vote will be triggered around when to split
>> the repository.  The implication there is if you vote for b or c, your
>> voting for a repository split.  If you vote for A you are voting for no
>> repository split.  I hate to overload voting in this way.  It is only an
>> optimization to speed things up as execution may need to happen now, or
>> can be pushed out a month, or may not be needed at this time.
>> 
>> 
>> 
>> 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

Re: [openstack-dev] [kolla][vote] Core nomination for Dave Walker (Daviey on irc)

[Ryan Hallisey]

+1

-Ryan

- Original Message -
From: "Michał Jastrzębski" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Wednesday, August 24, 2016 10:41:57 AM
Subject: Re: [openstack-dev] [kolla][vote] Core nomination for Dave Walker 
(Daviey on irc)

+1 good job Davey:)

On 24 August 2016 at 08:27, Mauricio Lima  wrote:
> +1
>
> 2016-08-24 9:15 GMT-03:00 Kwasniewska, Alicja
> :
>>
>> +1
>>
>>
>>
>> From: Eduardo Gonzalez [mailto:dabar...@gmail.com]
>> Sent: Wednesday, August 24, 2016 1:42 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [kolla][vote] Core nomination for Dave Walker
>> (Daviey on irc)
>>
>>
>>
>> +1
>>
>>
>>
>> On Wed, Aug 24, 2016, 1:25 PM Martin André  wrote:
>>
>> +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
>>
>>
>> __
>> OpenStack Development Mailing List (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] [vote][kolla] Core nomination proposal for Eduardo Gonzalez Gutierrez (egonzales90 on irc)

[Ryan Hallisey]

+1

-Ryan

- Original Message -
From: "Steven Dake (stdake)" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Thursday, August 18, 2016 7:09:35 PM
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] [TripleO] a new Undercloud install driven by Heat

[Ryan Hallisey]

Hi,

There are a few additional items needed here before you can use the container 
work
from tht in the undercloud.

First, we deploy on Atomic.  Atomic already has docker started when it boots. 
We can't
use Atomic for the undercloud because there is no yum to install the clients.  
The clients
would have to be in another container. Instead of using Atomic, Docker could be 
setup and
configured by a script before the deployment. Second, you need to build the 
images locally
and push them to a local Docker registry. Therefore, there needs to be 
additional bits
that configure and set up the registry followed by cloning Kolla and building 
the
container images.  Lastly, configs are generated using puppet tags. I'm not 
sure every
service has a _config tag in the puppet scripts currently.

Thanks,
-Ryan


- Original Message -
From: "Dan Prince" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Friday, August 5, 2016 7:34:32 AM
Subject: Re: [openstack-dev] [TripleO] a new Undercloud install driven by Heat


Lastly, there is container work ongoing for the Overcloud. Again, I'd
like to see us adopt a format that would allow it to be used in the
Undercloud as well as opposed to having to re-implement features in the
Over and Under clouds all the time.


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

[openstack-dev] [kolla][kolla-kubernetes]

[Ryan Hallisey]

Hi all,

The kolla-kubernetes project is in need of introducing some changes into
kolla's globals.yml.  This could quickly become an issue because the community
does not want to have too many variables exposed and create a mess for any
backports.

In order to get kolla-kubernetes unblocked, kolla-kubernetes users will need
to copy/paste variables into the globals.yml.  This will be documented on the
kolla-kubernetes side. The Kolla config will be setup to pickup these vars
and make any changes.  This solution will work for the time being until Kolla
reaches the conclusion of the N cycle and the community evaluates a repo split
and a config split.

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

Thanks,
Ryan

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

[Ryan Hallisey]

Agreed, it's been a week. The vote can be brought up again when
the conclusion of N is closer.

-Ryan

- Original Message -
From: "Steven Dake (stdake)" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Wednesday, July 27, 2016 11:46:44 AM
Subject: Re: [openstack-dev] [kolla] repo split

Martin,

Thanks for your feedback.  This vote has expired without a consensus.  I
think we need to try a new vote once the core team gets comfortable with
the backporting process I spoke about earlier in a different thread this
vote would likely pass.

Regards
-steve

On 7/27/16, 3:09 AM, "Martin André"  wrote:

>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


__
OpenStack Development Mailing List (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] [kolla] repo split

[Ryan Hallisey]

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

Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

[Ryan Hallisey]

+1

-Ryan

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

Sent: Monday, July 18, 2016 9:16:09 PM
Subject: Re: [openstack-dev] [kolla][vote] Applying for stable-follows tag

+1 to apply
I'd like to be the volunteer.

On Mon, Jul 18, 2016 at 9:04 PM, Swapnil Kulkarni (coolsvap)
 wrote:
> On Mon, Jul 18, 2016 at 6:23 PM, Paul Bourke  wrote:
>> Hi Steve,
>>
>> +1 to applying. I'll volunteer for the backport team also.
>>
>> -Paul
>>
>>
>> On 18/07/16 13:07, Steven Dake (stdake) wrote:
>>>
>>> Hey Koalians,
>>>
>>> I'd like us to consider applying  for the stable follows policy tag.
>>>   Full details are here:
>>>
>>>
>>> http://github.com/openstack/governance/blob/master/reference/tags/stable_follows-policy.rst
>>>
>>> Because of the magic work we did to make liberty functional, it is
>>> possible that we may not be able to apply for this tag until Liberty
>>> falls into EOL.  Still I personally believe intent matters most, and our
>>> intent has always been for these to be stable low-rate-of-change
>>> no-feature-backport branches.  There are some exceptions I think we
>>> would fit under for the Liberty case, so I think it is worth a shot.
>>>
>>> I'd need 2-4 people to commit to joining the stable backport team for
>>> Kolla reviews specifically.  These folks would be the only folks that
>>> could ACK patches in the stable branch maintenance queue.  Anyone could
>>> continue to submit backport patches as they desire.
>>>
>>> I'll leave voting open for 1 week or until there I a majority (6 core
>>> reviewers) or until there is a unanimous vote.  If there is not, then we
>>> won't apply.  The deadline for this vote is July 25th.
>>>
>>> Thanks!
>>> -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
>
> +1 to apply for stable follows policy.
> I would like to volunteer for the backport team.
>
> __
> OpenStack Development Mailing 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] our mascot - input needed

[Ryan Hallisey]

koala bear

-Ryan

- Original Message -
From: "Vikram Hosakote (vhosakot)" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Saturday, July 16, 2016 1:24:08 PM
Subject: Re: [openstack-dev] [kolla] our mascot - input needed

Sorry, I missed the kolla mid-cycle summit as I was at a conference. 

I will review the mid-cycle etherpad. 

Yes for the koala bear!! :) 

Regards, 
Vikram Hosakote 
IRC: vhosakot 

From: "Steven Dake (stdake)" < std...@cisco.com > 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" < 
openstack-dev@lists.openstack.org > 
Date: Thursday, July 14, 2016 at 1:08 PM 
To: "OpenStack Development Mailing List (not for usage questions)" < 
openstack-dev@lists.openstack.org > 
Subject: [openstack-dev] [kolla] our mascot - input needed 

Hey folks, 

The OpenStack foundation is putting together mascots for every project with a 
proper artist doing the work. The cool thing about this is we a) get stickers 
b) have consistent look and feel among mascots in OpenStack. 

The downside is we have to make a decision. The foundation wants 3-5 choices. 

The mascot must be an animal and it can't involve glue or other inc007 inspired 
ideas :) 

Obviously Koala bear is probably everyone's first choice since we have sort of 
been using that as a mascot since day one. Anyone else have anything else for 
me to provide the foundation with a choices 2-5? 

Please respond quickly, the foundation needs the information shortly. I'd like 
to offer up two alternatives just in case. 

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] Stepping down from core

[Ryan Hallisey]

Angus and Michal,

Thanks for your hard work! I hope our paths will cross again in the future.

Good luck!
Ryan

- Original Message -
From: "Martin André" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Friday, July 8, 2016 7:34:27 AM
Subject: Re: [openstack-dev] [kolla] Stepping down from core

On Fri, Jul 8, 2016 at 10:44 AM, Angus Salkeld  wrote:
>
> On Fri, Jul 8, 2016 at 10:01 AM Michal Rostecki 
> wrote:
>>
>> Hi,
>>
>> I'd like to announce that I'm leaving the Kolla core team and I will not
>> work on this project anymore (at least in the near future). I'm fully
>> focusing on working in Kubernetes upstream directly. That said, I want
>> to thank you for working together!
>
>
> Steve: I must do this too (Michal and I are working together upstream in
> kubernetes) I just don't have the time to do any reviews in kolla). Thanks
> for encouraging us, the kolla-mesos stuff was fun and I learned a lot.

/me sadface

Thank you both for all the hard work on kolla-mesos and kolla in
general. Enjoy you new kubernetes adventures.

Martin

> -Angus
>
>>
>>
>> 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] Build the docker images in a graceful way

[Ryan Hallisey]

Hey Jeff,

Can you write up a spec with the details?  That way the community can see the 
full layout
of the proposal.

Thanks,
-Ryan

- Original Message -
From: "Jeffrey Zhang" 
To: "OpenStack Development Mailing List" 
Sent: Wednesday, June 29, 2016 8:50:28 AM
Subject: [openstack-dev] [kolla] Build the docker images in a graceful way

Recently, Ansible release 2.1 version with lots of new feature. One of the 
interesting feature 
is the management for docker. 

Redhat also announced the Ansible Container project[0][1], which can build 
docker images by using 
Ansible Playbooks. No more write the ugly Dockerfile script. I think this will 
be more graceful. 

Here the explanation that why not use Dockerfile from ansible-container readme 
file. 




A Dockerfile is not much more than a script with hand-crafted shell commands. 
We're well past the 
point where we should be managing build processes with manually maintained 
series of shell scripts. 
That's why we wrote Ansible in the first place, and this is just as applicable 
to containers. 

Ansible Container permits orchestration even during the build process, whereas 
docker build does 
not. For example, in a Django project, your VCS may contain a bunch of sources 
for static assets 
that need to be compiled and then collected. With Ansible Container, you can 
compile the static 
assets in your Django container and then collect them into your static file 
serving container. 

Many people use Docker for development environments only but then use Ansible 
playbooks to push 
out to staging or production. This allows you to use the same playbooks and 
roles in your Docker 
dev environment as in your production environments. 

Ansible Container does all of this without installing SSH, leaving Ansible 
artifacts on your 
built images, or having excess layers to the union filesystem. 

​I also pushed a PS to implement ​almost the same thing for Kolla[3]. There 
many benefit for this. 

​1. more easy to understand. The original base/Dockerfile is too long, mixed 
with different base image logical 
and different install type. Whereas in the new implement, it is more clearly. 
it is split into multi 
YAML file. 
​2. easy to extend. We can reuse the role concept for the Ansible. For example, 
when you want to extend 
the neutron-server container. You can write your own roles, like 
neutron-server-lbaas role, and just 
add this to the neutron-server playbooks. In this way, we can implement the 
customize issue. ( this will 
implement later.) 
3. It is also possible to change the exist data. For example, i want to change 
the repo url to a internal 
ones. ​ 
​ 
​The user can provide a ansible variables file, which hold the new repo url and 
overwrite the 
exist one. 

This PS is in POC stage. Post this mail to gather any advise and better ideas. 

​[0] https://github.com/ansible/ansible-container 
[1] 
https://www.helpnetsecurity.com/2016/06/20/ansible-native-container-workflow-project/
 
[2] https://review.openstack.org/334208 

-- 
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] Cinder multiple backends

[Ryan Hallisey]

Hey Carlos,

The work to enable you to do this is in progress.  Kolla needs to refactor the 
way the Dockerfiles
are templated in order to create additional flexibility.

You can follow the work here: 
https://blueprints.launchpad.net/kolla/+spec/third-party-plugin-support

Thanks,
Ryan

- Original Message -
From: "Carlos Cesario" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, June 20, 2016 9:29:27 AM
Subject: [openstack-dev]  [kolla]  Cinder multiple backends

Hi folks, 

It seems that Kolla does nos provide option to enable multiple backends in 
Cinder config. 

Currently in my deploy/setup I needed enable the Storwize Cinder driver - 
http://docs.openstack.org/mitaka/config-reference/block-storage/drivers/ibm-storwize-svc-driver.html
 - 
and to this I added into /etc/kolla/config/cinder.conf my configs 

  [DEFAULT] 
  default_volume_type = ibm 

  [ibm] 
  
volume_driver=cinder.volume.drivers.ibm.storwize_svc.storwize_svc_fc.StorwizeSVCFCDriver
 
  san_ip=xxx.xx.xx.xx 
  san_login=superuser 
  san_password=mypass 
  san_ssh_port=22 
  storwize_svc_volpool_name=myPool 
  volume_backend_name=ibm 
  verbose = True 
  debug = True 


And I changed manually the file 
/var/src/kolla-master/ansible/roles/cinder/templates/cinder.conf.j2 as well. 

But for the driver works correctly, it was needed install manually some 
aditional packs. 

$ apt-get install sysfsutils sg3-utils on cinder-volume container 
$ apt-get install multipath-tools sysfsutils on nova-compute container

Is there any doc/spec to create a automatic process for this ? Could someone 
give us details how is the best way to make it "automatized" !? 



Best regards, 

- Carlos
__
OpenStack Development Mailing List (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] Potential direction proposal - unified OpenStack containers

[Ryan Hallisey]

Sergey,

Thanks for reaching out to the community!  I think there is a lot to discuss. I 
added some comments on
the spec and I'm sure many kolla folks will follow up.


Thanks,
Ryan

- Original Message -
From: "Sergey Lukjanov" 
To: "OpenStack Development Mailing List" 
Sent: Thursday, June 16, 2016 10:04:06 AM
Subject: [openstack-dev] [kolla] Potential direction proposal - unified 
OpenStack containers

Hi folks, 

I'd like to share some thoughts about the OpenStack containerization in the 
form of a specification for Kolla and have some discussion on the proposed 
items in the review. 

In general it's a meta spec to describe potential direction for Kolla to 
provide Unified deployment tool agnostic containers for anyone to use. 

We very much welcome your feedback on the following spec. 

Link: https://review.openstack.org/330575 

Thanks. 


-- 
Sincerely yours, 
Sergey Lukjanov 
Principal Software Engineer 
Mirantis 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] [kolla] Request for changing the meeting time to 1600 UTC for all meetings

[Ryan Hallisey]

+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

Re: [openstack-dev] [kolla] stepping down from core

[Ryan Hallisey]

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

Re: [openstack-dev] [kolla] prototype of a DSL for generating Dockerfiles

[Ryan Hallisey]

Looking at some of the capabilities jinja2 has, it's hard to justify changing 
the method already in place.
I think jinja2 can provide a clear and operational way for operators to 
customize the dockerfiles as needed.
Kolla just hasn't applied them yet.

I'm extremely hesitant to agree on changing this because I think kolla can 
solve these issues without having
the overhead that will come with this change.

-Ryan

- Original Message -
From: "Michał Jastrzębski" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Wednesday, June 1, 2016 4:55:50 PM
Subject: Re: [openstack-dev] [kolla] prototype of a DSL for generating  
Dockerfiles

Aaaand correct link: https://review.openstack.org/#/c/323589/ sorry
for pastefail.

On 1 June 2016 at 15:55, Michał Jastrzębski  wrote:
> So this is prototype of working template overrides:
> https://review.openstack.org/#/c/323612/
>
> Pass --template-overrides=path-to-file to build.py
> in file override you can add any custom code/logic/dockerfile stuff to
> any of hooks we provide in Dockerfiles, and we'll provide a lot of
> them as it's free and non breaking operation. With enough block you'll
> be able to do virtually anything with any of the containers.
>
> This one is already working. Only work needed is to provide more
> hooks/continue with refactoring of dockerfiles.
>
> Cheers,
> Michal
>
> On 31 May 2016 at 19:36, Steven Dake (stdake)  wrote:
>>
>>
>> On 5/31/16, 1:42 PM, "Michał Jastrzębski"  wrote:
>>
>>>I am opposed to this idea as I don't think we need this. We can solve
>>>many problems by using jinja2 to greater extend. I'll publish demo of
>>>few improvements soon, please bear with me before we make a
>>>arch-changing call.
>>
>> Can you make a specification please as you have asked me to do?
>>
>>>
>>>On 29 May 2016 at 14:41, Steven Dake (stdake)  wrote:

>On 5/27/16, 1:58 AM, "Steven Dake (stdake)"  wrote:
>
>>
>>
>>On 5/26/16, 8:45 PM, "Swapnil Kulkarni (coolsvap)" 
>>wrote:
>>
>>>On Fri, May 27, 2016 at 8:35 AM, Steven Dake (stdake)
>>>
>>>wrote:
 Hey folks,

 While Swapnil has been busy churning the dockerfile.j2 files to all
match
 the same style, and we also had summit where we declared we would
solve
the
 plugin problem, I have decided to begin work on a DSL prototype.

 Here are the problems I want to solve in order of importance by this
work:

 Build CentOS, Ubuntu, Oracle Linux, Debian, Fedora containers
 Provide a programmatic way to manage Dockerfile construction rather
then a
 manual (with vi or emacs or the like) mechanism
 Allow complete overrides of every facet of Dockerfile construction,
most
 especially repositories per container (rather than in the base
container) to
 permit the use case of dependencies from one version with
dependencies
in
 another version of a different service
 Get out of the business of maintaining 100+ dockerfiles but instead
maintain
 one master file which defines the data that needs to be used to
construct
 Dockerfiles
 Permit different types of optimizations or Dockerfile building by
changing
 around the parser implementation ­ to allow layering of each
operation,
or
 alternatively to merge layers as we do today

 I don't believe we can proceed with both binary and source plugins
given our
 current implementation of Dockerfiles in any sane way.

 I further don't believe it is possible to customize repositories &
installed
 files per container, which I receive increasing requests for
offline.

 To that end, I've created a very very rough prototype which builds
the
base
 container as well as a mariadb container.  The mariadb container
builds
and
 I suspect would work.

 An example of the DSL usage is here:
 https://review.openstack.org/#/c/321468/4/dockerdsl/dsl.yml

 A very poorly written parser is here:
 https://review.openstack.org/#/c/321468/4/dockerdsl/load.py

 I played around with INI as a format, to take advantage of
oslo.config
and
 kolla-build.conf, but that didn't work out.  YML is the way to go.

 I'd appreciate reviews on the YML implementation especially.

 How I see this work progressing is as follows:

 A yml file describing all docker containers for all distros is
placed
in
 kolla/docker
 The build tool adds an option ‹use-yml which uses the YML file
 A parser (such as load.py above) is integrated into build.py to lay
down he
 Dock

[openstack-dev] [keystone] orchestration and db_sync

[Ryan Hallisey]

Hi all,

When orchestrating an openstack service from nothing, there are a few steps that
need to occur before you have a running service assuming the database already 
exists.

- Create the service's users and add a password into the databse
- Sync the service with the database
- Start the service

I was wondering if for some services they could be aware of whether or not they 
need
to sync with the database at startup.  Or maybe the service runs a db_sync 
every time
is starts?  I figured I would start a thread about this because Keystone has 
some
flexibility when running N+1 in a cluster of N. If Keystone could have that
that ability maybe Keystone could db_sync each time it starts without harming 
the
cluster?

It may be wishful thinking, but I'm curious to hear more thought about the 
topic.

Thanks,
Ryan

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

[Ryan Hallisey]

I think the community will want to split apart the CLI to run tasks.  This was 
an idea being thrown around at the same time
as the ectd addition.  This would give the operator the ability to like you 
said, to skip any task that isn't required.

Using etcd is a way for the operator to guarantee that a bootstrapping task can 
run without another service interrupting it.
The goal is to try and make use of the Kubernetes like workflow as much as 
possible.  I agree, the community should avoid
automagic setup.  It can lead to a lot of dangerous corner cases. I think Kolla 
learned this lesson way back during the
compose era.

The tasks are define as:
  - bootstrap /
  - deploy /

Any further workflow tweaking could be handled by contacting etcd.  The 
community could also break down the tasks further
if there is a use case for it.

Thanks,
Ryan

- Original Message -
From: "Kevin M Fox" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Thursday, May 26, 2016 11:41:12 AM
Subject: Re: [openstack-dev] [kubernetes]

Two issues I can see with that approach.

1. It needs to be incredibly well documented as well as tools provided to 
update states in etcd manually when an op needs to recover from things 
partially working.
2. Consider the case where an op has an existing cloud. He/She installs k8s on 
their existing control plane, and then one openstack service at a time wants to 
"upgrade" the system from non container to containers. If the user wants to do 
so, with the jobs method, the op just skips the bootstrap jobs. With magic 
baked into the containers and etcd, the same kinds of things in issue #1 needs 
fixing in etcd so it doesn't try and reinit things. This makes it harder to get 
clouds migrated to kolla-k8s.

I know the idea is to try and simplify deployment by making the containers do 
all the initing automagically. but I'm afraid that just sweeps issues under the 
rug, out of the light where they still will come up, but more unexpectedly. The 
ops still need to understand the automagic that is happening. As an Op, I'd 
rather it be explicit, out front, where I know its happening, and I can easily 
tweak the workflow when necessary to get out of a bind.

Thanks,
Kevin
____
From: Ryan Hallisey [rhall...@redhat.com]
Sent: Thursday, May 26, 2016 5:20 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kubernetes]

Thanks for the feedback Kevin.

The community has been investigation other options this week.  The option that 
is currently being looked at involves
using etcd to provide a locking mechanic so that services in the cluster are 
aware bootstrapping is underway.

The concept involves extending kolla's dockerfiles and having them poll etcd to 
determine whether a bootstrap is in progress or complete [1].

I'll follow up by adding this to the spec.

Thanks,
Ryan

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

- Original Message -
From: "Kevin M Fox" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, May 23, 2016 11:37:33 AM
Subject: Re: [openstack-dev] [kubernetes]

+1 for using k8s to do work where possible.

-1 for trying to shoehorn a feature in so that k8s can deal with stuff its not 
ready to handle. We need to ensure Operators have everything they need in order 
to successfully operate their cloud.

The current upgrade stuff in k8s is focused around replacing one, usually 
stateless, thing for another. It never had Database Schema upgrades in mind.  
It is great to use for minor version bumps. It is insufficient for major 
OpenStack upgrades. If you follow the OpenStack release notes, they tend to be 
quite linear, in a workflow. K8s isn't designed for that. Hence the need for a 
tool outside of k8s to drive the creation/upgrading of Deployments and Jobs in 
the proper order.

Init containers also do not look like a good fit. As far as I can gather from 
the spec, they are intended to init something on a node when a pod is spawned. 
This is a very different thing from upgrading a shared database's schema. I 
don't believe they should be used for that.

I've upgraded many OpenStack clouds over the years. One of the things that has 
bit me from time to time is a failed schema update and having to tweak code and 
then rerun schema upgrades. This will continue to happen and needs to be 
covered. The Job's workflow as discussed in the spec allows an operator to do 
just that. Hiding it in an init container makes that much harder for Operators.

As an Op, we need the ability to tweak the workflow as needed and run/rerun 
only the pieces that we need.

Thanks,
Kevin

From: Ryan Hallisey [rhall...@redhat.com]
Sent: Sunday, May 22, 2016 12:50 PM
To: OpenStack Development Mailing List (not for usage quest

Re: [openstack-dev] [kubernetes]

[Ryan Hallisey]

Thanks for the feedback Kevin.

The community has been investigation other options this week.  The option that 
is currently being looked at involves
using etcd to provide a locking mechanic so that services in the cluster are 
aware bootstrapping is underway.

The concept involves extending kolla's dockerfiles and having them poll etcd to 
determine whether a bootstrap is in progress or complete [1].

I'll follow up by adding this to the spec.

Thanks,
Ryan

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

- Original Message -
From: "Kevin M Fox" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, May 23, 2016 11:37:33 AM
Subject: Re: [openstack-dev] [kubernetes]

+1 for using k8s to do work where possible.

-1 for trying to shoehorn a feature in so that k8s can deal with stuff its not 
ready to handle. We need to ensure Operators have everything they need in order 
to successfully operate their cloud.

The current upgrade stuff in k8s is focused around replacing one, usually 
stateless, thing for another. It never had Database Schema upgrades in mind.  
It is great to use for minor version bumps. It is insufficient for major 
OpenStack upgrades. If you follow the OpenStack release notes, they tend to be 
quite linear, in a workflow. K8s isn't designed for that. Hence the need for a 
tool outside of k8s to drive the creation/upgrading of Deployments and Jobs in 
the proper order.

Init containers also do not look like a good fit. As far as I can gather from 
the spec, they are intended to init something on a node when a pod is spawned. 
This is a very different thing from upgrading a shared database's schema. I 
don't believe they should be used for that.

I've upgraded many OpenStack clouds over the years. One of the things that has 
bit me from time to time is a failed schema update and having to tweak code and 
then rerun schema upgrades. This will continue to happen and needs to be 
covered. The Job's workflow as discussed in the spec allows an operator to do 
just that. Hiding it in an init container makes that much harder for Operators.

As an Op, we need the ability to tweak the workflow as needed and run/rerun 
only the pieces that we need.

Thanks,
Kevin
____
From: Ryan Hallisey [rhall...@redhat.com]
Sent: Sunday, May 22, 2016 12:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev]  [kolla][kolla-kubernetes][kubernetes]

Hi all,

At the Kolla meeting last week, I brought up some of the challenges around the 
bootstrapping
process in Kubernetes.  The main highlight revolved around how the 
bootstrapping process will
work.

Currently, in the kolla-kubernetes spec [1], the process for bootstrapping 
involves
outside orchestration running Kubernetes 'Jobs' that will handle the database 
initialization,
creating users, etc...  One of the flaws in this approach, is that 
kolla-kubernetes can't use
native Kubernetes upgrade tooling. Kubernetes does upgrades as a single action 
that scales
down running containers and replaces them with the upgraded containers. So 
instead of having
Kubernetes manage the upgrade, it would be guided by an external engine.  Not 
saying this is
a bad thing, but it does loosen the control Kubernetes would have over stack 
management.

Kubernetes does have some incoming new features that are a step in the right 
direction to
allow for kolla-kubernetes to make complete use of Kubernetes tooling like init 
containers [2].
There is also the introduction to wait.for conditions in the kubectl [3].

   kubectl get pod my-pod --wait --wait-for="pod-running"

Upgrades will be in the distant future for kolla-kubernetes, but I want to make 
sure the
community maintains an open mind about bootstrap/upgrades since there are 
potentially many
options that could come down the road.

I encourage everyone to add your input to the spec!

Thanks,
Ryan

[1] SPEC - https://review.openstack.org/#/c/304182/
[2] Init containers - https://github.com/kubernetes/kubernetes/pull/23567
[3] wait.for kubectl - https://github.com/kubernetes/kubernetes/issues/1899

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

[Ryan Hallisey]

Right, I wouldn't either.

The problem has to do with being able to clearly define the difference between 
bootstrapping and upgrading in Kubernetes.
Bootstrapping has a series of steps it needs to run.  Upgrades have a different 
series of steps.  How can kolla-kubernetes
be able to perform one or the other based on whether the operator is 
boostrapping or upgrading the same pod?  And how
will those steps be ordered?

Maybe a combination of Kubernetes hooks and health checks could solve this?  
I'm not entirely sure. However, you can
still get bootstrapping and upgrades using outside orchestration.  For now, I 
think kolla-kubernetes will focus on outside
orchestration until Kubernetes reaches a point where the community can do this 
in a pod.

Thanks,
Ryan



- Original Message -
From: "Britt Houser (bhouser)" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, May 23, 2016 8:49:43 AM
Subject: Re: [openstack-dev] [kolla][kolla-kubernetes][kubernetes]

I wouldn't expect new users to be created on upgrade, so is the problem with 
bootstrap and upgrade that we do the database migration during bootstrap too?

Thx,
britt



On 5/22/16, 3:50 PM, "Ryan Hallisey"  wrote:

>Hi all,
>
>At the Kolla meeting last week, I brought up some of the challenges around the 
>bootstrapping
>process in Kubernetes.  The main highlight revolved around how the 
>bootstrapping process will
>work.
>
>Currently, in the kolla-kubernetes spec [1], the process for bootstrapping 
>involves
>outside orchestration running Kubernetes 'Jobs' that will handle the database 
>initialization,
>creating users, etc...  One of the flaws in this approach, is that 
>kolla-kubernetes can't use
>native Kubernetes upgrade tooling. Kubernetes does upgrades as a single action 
>that scales
>down running containers and replaces them with the upgraded containers. So 
>instead of having
>Kubernetes manage the upgrade, it would be guided by an external engine.  Not 
>saying this is
>a bad thing, but it does loosen the control Kubernetes would have over stack 
>management.
>
>Kubernetes does have some incoming new features that are a step in the right 
>direction to
>allow for kolla-kubernetes to make complete use of Kubernetes tooling like 
>init containers [2].
>There is also the introduction to wait.for conditions in the kubectl [3].
>
>   kubectl get pod my-pod --wait --wait-for="pod-running"
>
>Upgrades will be in the distant future for kolla-kubernetes, but I want to 
>make sure the
>community maintains an open mind about bootstrap/upgrades since there are 
>potentially many
>options that could come down the road.
>
>I encourage everyone to add your input to the spec!
>
>Thanks,
>Ryan
>
>[1] SPEC - https://review.openstack.org/#/c/304182/
>[2] Init containers - https://github.com/kubernetes/kubernetes/pull/23567
>[3] wait.for kubectl - https://github.com/kubernetes/kubernetes/issues/1899
>
>__
>OpenStack Development Mailing List (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] [kolla][kolla-kubernetes][kubernetes]

[Ryan Hallisey]

Hi all,

At the Kolla meeting last week, I brought up some of the challenges around the 
bootstrapping
process in Kubernetes.  The main highlight revolved around how the 
bootstrapping process will
work.

Currently, in the kolla-kubernetes spec [1], the process for bootstrapping 
involves
outside orchestration running Kubernetes 'Jobs' that will handle the database 
initialization,
creating users, etc...  One of the flaws in this approach, is that 
kolla-kubernetes can't use
native Kubernetes upgrade tooling. Kubernetes does upgrades as a single action 
that scales
down running containers and replaces them with the upgraded containers. So 
instead of having
Kubernetes manage the upgrade, it would be guided by an external engine.  Not 
saying this is
a bad thing, but it does loosen the control Kubernetes would have over stack 
management.

Kubernetes does have some incoming new features that are a step in the right 
direction to
allow for kolla-kubernetes to make complete use of Kubernetes tooling like init 
containers [2].
There is also the introduction to wait.for conditions in the kubectl [3].

   kubectl get pod my-pod --wait --wait-for="pod-running"

Upgrades will be in the distant future for kolla-kubernetes, but I want to make 
sure the
community maintains an open mind about bootstrap/upgrades since there are 
potentially many
options that could come down the road.

I encourage everyone to add your input to the spec!

Thanks,
Ryan

[1] SPEC - https://review.openstack.org/#/c/304182/
[2] Init containers - https://github.com/kubernetes/kubernetes/pull/23567
[3] wait.for kubectl - https://github.com/kubernetes/kubernetes/issues/1899

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

[Ryan Hallisey]

+1 nice work mlima!

-Ryan

- Original Message -
From: "Vikram Hosakote (vhosakot)" 
To: openstack-dev@lists.openstack.org
Sent: Wednesday, May 18, 2016 9:45:53 AM
Subject: Re: [openstack-dev] [kolla] Proposing Mauricio Lima for core   reviewer

Yes, +1 for sure! 

Thanks a lot Mauricio for all the great work especially for adding Manila to 
kolla and also updating the cleanup scripts and documentation! 


Regards, 
Vikram Hosakote 
IRC: vhosakot 

From: "Steven Dake (stdake)" < std...@cisco.com > 
Reply-To: " openstack-dev@lists.openstack.org " < 
openstack-dev@lists.openstack.org > 
Date: Tuesday, May 17, 2016 at 3:00 PM 
To: " openstack-dev@lists.openstack.org " < openstack-dev@lists.openstack.org > 
Subject: [openstack-dev] [kolla] Proposing Mauricio Lima for core reviewer 

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

__
OpenStack Development Mailing 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][kubernetes] One repo vs two

[Ryan Hallisey]

Most of the code is not an overlap. We will preserve the ABI while customizing 
the ansible config generation (if we do end up using it). We can use some of 
what's in kolla as a starting point.

I'd say the code overlap is a bootstrapping point for the project.

-Ryan

- Original Message -
From: "Kevin M Fox" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, May 2, 2016 12:56:22 PM
Subject: Re: [openstack-dev] [kolla][kubernetes] One repo vs two

One thing we didn't talk about too much at the summit is the part of the spec 
that says we will reuse a bunch of ansible stuff to generate configs for the 
k8s case...

Do we believe that code would be minimal and not impact separate repo's much or 
is the majority of the work in the end going to be focused there? If most of 
the code ends up landing there, then its probably not worth splitting?

Thanks,
Kevin

From: Steven Dake (stdake) [std...@cisco.com]
Sent: Monday, May 02, 2016 6:05 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla][kubernetes] One repo vs two

On 5/1/16, 10:32 PM, "Swapnil Kulkarni"  wrote:

>On Mon, May 2, 2016 at 9:54 AM, Britt Houser (bhouser)
> wrote:
>> Although it seems I'm in the minority, I am in favor of unified repo.
>>
>> From: "Steven Dake (stdake)" 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Sunday, May 1, 2016 at 5:03 PM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: [openstack-dev] [kolla][kubernetes] One repo vs two
>>
>> Ryan had rightly pointed out that when we made the original proposal 9am
>> morning we had asked folks if they wanted to participate in a separate
>> repository.
>>
>> 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'll leave it open to the new folks that want to do the work if they
>>want to
>> work on an offshoot repository and open us up to the possible problems
>> above.
>>
>> If you are on this list:
>>
>> Ryan Hallisey
>> 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)
>>
>> Keith Byrne (kbyrne)
>>
>> Zdenek Janda (xdeu)
>>
>> Brandon Jozsa (v1k0d3n)
>>
>> Rajath Agasthya (rajathagasthya)
>> Jinay Vora
>> Hui Kang
>> Davanum Srinivas
>>
>>
>>
>> Please speak up if you are in favor of a separate repository or a
>>unified
>> repository.
>>
>> The core reviewers will still take responsibility for determining if we
>> proceed on the action of implementing kubernetes in general.
>>
>> Th

Re: [openstack-dev] [kolla][vote][kubernetes][infra] kolla-kubernetes repository management proposal up for vote

[Ryan Hallisey]

+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)
>
> Keith Byrne (kbyrne)
>
> Zdenek Janda (xdeu)
>
> Brandon Jozsa (v1k0d3n)
>
> Rajath Agasthya (rajathagasthya)
>
>
> If you already are in the kolla-core review team, you won't be added to the
> kolla-k8s-core team as you will already have the necessary ACLs to do the
> job.  If you feel you would like to join this initial bootstrapping process,
> please add your name to the etherpad in [1].
>
> After 8 weeks (July 15h), folks that have not been actively reviewing or
> committing code will be removed from the kolla-k8s-core group.  We will use
> the governance repository metrics for team size [2] which is either 30
> reviews over 6 months (in this case, 10 reviews), or 6 commits over 6 months
> (in this case 2 commits) to the repository.  Folks that don't meet the
> qualifications are still welcome to commit to the repository and contribute
> code or documentation but will lose approval rights on patches.
>
> The kubernetes codebase will be maintained in the
> https://github.com/openstack/kolla repository under the kubernees top level
> directory.  Contributors that become active in the kolla repository itself
> will be proposed over time to the kolla-core group.  Only core-kolla members
> will be permitted to participate in policy decisions and voting thereof, so
> there is some minimal extra responsibi

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

[Ryan Hallisey]

>I am in the favor of having two separate repos and evaluating the
>merge/split option later.
>Though in the longer run, I would recommend having a single repo with
>multiple stable deployment tools(maybe too early to comment views but
>yeah)
>
>Swapnil

>Swapnil,

>I gather this is what people want but this cannot be done with git and
>maintain history.  To do this, we would have to "cp oldrepo/files to
>newrepo/files" and the git history would be lost.  That is why choosing
>two repositories up front is irreversible.

When the community votes to either merge or not to merge down the road, it 
won't be far
enough in the future that losing the git history will be catastrophic. There 
won't
even be a release for the Kubernetes solution at that point. Plus it's still up 
in
the air whether the history gets lost at all because it's not a guarantee the 
community
votes to merge it.

-Ryan

__
OpenStack Development Mailing 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][kubernetes] One repo vs two

[Ryan Hallisey]

I'm voting for separate repo.  I'm not keen to adding 20 new cores to a stable 
repo.  I'd prefer it to be in a different repo while it gets going.  Yes, we 
will lose some git history *if* we vote to merge it into the main repo.  It's 
not a guarantee.

If this were to go into the main repo, I think it becomes harder for both 
ansible and kubernetes to ever come out.  I'd rather start outside since it's 
easier to move in if we choose to do that.

-Ryan

- Original Message -
From: "Steven Dake (stdake)" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Sunday, May 1, 2016 5:03:57 PM
Subject: [openstack-dev] [kolla][kubernetes] One repo vs two

Ryan had rightly pointed out that when we made the original proposal 9am 
morning we had asked folks if they wanted to participate in a separate 
repository. 

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'll leave it open to the new folks that want to do the work if they want to 
work on an offshoot repository and open us up to the possible problems above. 

If you are on this list: 



* Ryan Hallisey 
* 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) 


* Keith Byrne (kbyrne) 


* Zdenek Janda (xdeu) 


* Brandon Jozsa (v1k0d3n) 


* Rajath Agasthya (rajathagasthya) 
* Jinay Vora 
* Hui Kang 
* Davanum Srinivas 


Please speak up if you are in favor of a separate repository or a unified 
repository. 

The core reviewers will still take responsibility for determining if we proceed 
on the action of implementing kubernetes in general. 

Thank you 
-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][kubernetes][infra] kolla-kubernetes repository management proposal up for vote

[Ryan Hallisey]

-1 to not having a separate kolla-kubernetes repo.

> The kubernetes codebase will be maintained in the 
> https://github.com/openstack/kolla repository under the kubernees top level 
> directory.

I don't agree here.  This needs to be its own repo.

> I feel we made a couple errors with the creation of Kolla-mesos that I feel 
> needs correction. Our first error the kolla-mesos-core team made a lack of a 
> diversely affiliated team membership developing the code base. The above list 
> has 
> significant diversity. 

I don't think diversity is a requirement for an alternative deployment tool to 
be created in the Kolla community. It would be great, I agree, but sometimes 
communities are diverse and sometimes they arn't.  Kolla can't require that. 
It's not in kolla's mission statement.  

> The second error is that the repository was split in the first place. 
> This resulted in a separate ABI to the containers being implemented which was 
> a sore spot for me personally. We did our best to build both 
> sides of the bridge here, but this time I'd like the bridge between these two 
> interests and set of individuals to be fully built before beginning. 

Kolla cores are there to guard the gate and we can only recommend a way to 
build a deployment tool around the Kolla containers. The creation of the 
alternative ABI was a Kolla-mesos choice. Therefore, next time the kolla cores, 
myself included, need to be more active in the discussion around the ABI in 
other deployment tools trying to consume kolla containers.  I agree that it 
would be great to unify around one consumption method of the containers, but 
that's not a guarantee.

> As such, I'd ask the existing kolla-core team to trust my judgement on this 
> point and 
> roll with it. We can always change the structure later if this model doesn't 
> work out as I expect it will, but if we started with split repos and a 
> changed structure to begin with, we can't go back to a non-split repo as the 
> action is 
> irreversible according to dims. 
> I know this proposal may seem uncomfortable for our existing kolla-core team. 
> I can assure you based upon twenty years of open source participation this 
> will result in a better outcome. We had talked about splitting the 
> repositories, 
> and our plan around that is to punt until such action is absolutely 
> necessary. Keeping things in one repository can always be split later, but a 
> premature split can never be undone without losing git commit history. 

I don't agree. A lot of people in the community liked the split of 
kolla-kubernetes until the project reaches a point where Kolla cores need to 
revisit the repo split action.  Then, Kolla cores vote to pull kolla-kubernetes 
in or vote to split out kolla-ansible. Ansible still hasn't been split out and 
a unified CLI will guarantee both kolla-ansible and kolla-kubernetes will never 
be split. That's not a punt. We may lose some git history, but adding 30 new 
cores to kolla will do more damage to the project.

It's not a matter of trusting judgment. Everyone kolla core has +1 or -1. We'll 
see if other cores agree.

> We will mark the kubernetes orchestration in Kolla as experimental until 
> existing feature parity is achieved in the kolla CLI tool. After the initial 
> implementation is ready, we will mark it as ready for evaluation . At the 
> conclusion 
> of Newton, assuming the implementation works well, we will mark the 
> implementation as "production ready", just as our current Ansible 
> orchestrated implementation is recorded. 
>
> ** All CLI features of the kolla-ansible shell script to be implemented for 
> "ready-for-evaluation" stage. ** 
>
> This includes the following CLI operations where they make sense: 
>
>
>1. Prechecks 
>2. mariadb_recvoery 
>3. Deploy 
>4. Post-deploy 
>5. Pull 
>6. Upgrade 
>7. Reconfgiure 
>8. Certificates 
> As part of this change, I will be submitting a change to rename kolla-ansible 
> to kolla with appropriate documentation changes. This one shell script will 
> in the future will read from globals.yml a yaml variable which is 
> "orchestratoin_engine" which may be either ansible or kubernetes. In this 
> way, the terminology I strongly dislike "first class citizen" will be removed 
> from our lexicon in the Kolla repository. Instead of first class/second class 
> citizen, we will have all orchestration systems as "first class citizens" 
> with varying levels of maturity. 

There will always be tools out there that choose not to join the Kolla repo.  
Pulling in a deployment tool that wants to use Kolla's containers is a mistake. 
 Everyone has the same level of access to kolla's containers.  In my mind, one 
repo doesn't send this message.

> Please vote +1 if in favor, -1 if not in favor. 7 votes will trigger early 
> closing of the vote and the creation of the kubernetes directory with a 
> README.rst. The voting will remain open for 1 week until May 6th unless a 

Re: [openstack-dev] [kolla][vote] Place kolla-mesos in openstack-attic

[Ryan Hallisey]

+1

- Original Message -
From: "Angus Salkeld" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Sunday, April 24, 2016 11:01:38 AM
Subject: Re: [openstack-dev] [kolla][vote] Place kolla-mesos in openstack-attic



+1 
On Sat, 23 Apr 2016 3:08 am Michał Rostecki < michal.roste...@gmail.com > 
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-dev] kolla-kubernetes [kolla][kubernetes]

[Ryan Hallisey]

Just want to give everyone a heads up about a schedule change for kolla
summit sessions.  Kolla-kubernetes was a kolla spec [1] that we had intended
to cover at summit in a design session.  We are going to change it to a fish 
bowl
session instead to be held on Wednesday at 9am and the documentation fish bowl
will be moved to a design session.

Would love to see everyone interested in the topic attend!
https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Kolla%3A

Thanks
-Ryan

[1] - https://review.openstack.org/#/c/304182/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] Nit-picking documentation changes

[Ryan Hallisey]

I'm definitely guilty of nit picking docs.  I'm fine with holding back and 
following up with a patch to fix any grammar/misspelling mistakes. +1

-Ryan  

- Original Message -
From: "Paul Bourke" 
To: openstack-dev@lists.openstack.org
Sent: Tuesday, April 12, 2016 4:49:09 AM
Subject: Re: [openstack-dev] [kolla][vote] Nit-picking documentation changes

I've said in the past I'm not a fan of nitpicking docs. That said, I 
feel it's important for spelling and grammar to be correct. The 
quickstart guide is the first point of contact for many people to the 
project, and rightly or wrongly it will give an overall impression of 
the quality of the project.

When I review doc changes I try not to nitpick on the process being 
described - e.g. if an otherwise fine patch is already 5 iterations in 
and the example given to configure a service could be done in 3 lines 
less bash, I'll usually comment but still +2. If on the otherhand it is 
rife with typos (which by the way is easily solved with a spellchecker), 
and reads really badly I will flag it.

-Paul

On 11/04/16 19:27, Steven Dake (stdake) wrote:
> My proposal was for docs-only patches not code contributions with docs.
> Obviously we want a high bar for code contributions.  This is part of the
> reason we have the DocImpact flag (for folks that don't feel comfortable
> writing documentation because perhaps of ESL, or other reasons).
>
> We already have a way to decouple code from docs with DocImpact.
>
> Regards
> -steve
>
> On 4/11/16, 6:17 AM, "Michał Jastrzębski"  wrote:
>
>> So one way to approach it is to decouple docs from code, make it 2
>> reviews. We can -1 code without docs and ask to create separate
>> patchset depending on one in question with docs. Then we can nitpick
>> all we want:) new contributor will get his/hers code merged, at least
>> one patchset, so it will work better on morale, and we'll be able to
>> keep high bar for QSG and other docs. There is possibility that author
>> will leave docs patch after code merge, but well, we can take over
>> docs review.
>>
>> What do you think guys? I'd really like to keep high quality standard
>> all the way and don't scare off new commiters at the same time.
>>
>> Cheers,
>> Michal
>>
>> On 11 April 2016 at 03:50, Steven Dake (stdake)  wrote:
>>>
>>>
>>> On 4/11/16, 1:38 AM, "Gerard Braad"  wrote:
>>>
 Hi,

 On Mon, Apr 11, 2016 at 4:20 PM, Steven Dake (stdake) 
 wrote:
> On 4/11/16, 12:54 AM, "Gerard Braad"  wrote:
> as
>> at the moment getting an environment up-and-running according to the
>> quickstart guide is a hit and miss
> I don't think deployment is not hit or miss as long as the QSG are
> followed to a T :)

 Maybe saying "at the moment" was incorrect. As the deployment
 according to the QSG has been a few weeks ago. Sorry about this... as
 you guys have put a lot of effort into it recently.


> I agree we need more clarity in what belongs in the QSG.
 This can be a separate discussion (Not intending to hijack this thread).


 I am not a core reviewer, but I keep it as-is. I do not see a need for
>>>
>>> Even though your not a core reviewer, your comments are valued.  The
>>> reason I addressed core reviewers specifically as they have +2
>>> permissions
>>> and I would like more leniency on new documentation in other files
>>> outside
>>> those listed above (philosophy document, QSG) with a pubic statement of
>>> such.
>>>
 a lower-bar. Although, documentation is the entry-point into a
 community (as user and potential contributor) and therefore it should
 be of a high quality. Maybe I would be to provide more suggestions
 instead of just indication of 'change this for that'.
>>>
>>> The issue I see with our QSG is it has the highest bar for review
>>> passage
>>> of any file in the repository.  Any QSG change typically requires 10 or
>>> more patch sets to make it through the core reviewer gauntlet.  This
>>> discourages people from writing new documentation.  I don't want this to
>>> carry over into other parts of the documentation that are as of yet
>>> unwritten.  I'd like new documentation to be ok with misspellings,
>>> grammar
>>> errors, formatting problems, ESL authors, and that sort of thing.
>>>
>>> The QSG should tolerate none of these types of errors at this point - it
>>> must be absolutely perfect (at least in English:) as to not cause
>>> confusion to new operators.
>>>
>>> Regards
>>> -steve
>>>

 regards,


 Gerard

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

Re: [openstack-dev] [all] Newton Summit: cross-project session for deployment tools projects

[Ryan Hallisey]

Good idea Emilien!

Working in both tripleo and Kolla, I'd like to be a part of the conversation.

-Ryan

- Original Message -
From: "Samuel Cassiba" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Thursday, March 31, 2016 6:08:28 PM
Subject: Re: [openstack-dev] [all] Newton Summit: cross-project session for 
deployment tools projects

On Thu, Mar 31, 2016 at 2:40 PM, Emilien Macchi < emil...@redhat.com > wrote: 


Hi, 

OpenStack big tent has different projects for deployments: Puppet, 
Chef, Ansible, Kolla, TripleO, (...) but we still have some topics in 
common. 
I propose we use the Cross-project day to meet and talk about our 
common topics: CI, doc, release, backward compatibility management, 
etc. 

Feel free to look at the proposed session and comment: 
https://etherpad.openstack.org/p/newton-cross-project-sessions 


+1 on this. Looking forward to meeting people and discussing our common pain 
points. 

__
OpenStack Development Mailing List (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] Just make Mitaka deploy Liberty within the Liberty branch

[Ryan Hallisey]

Agreed this needs to happen +1,

- Original Message -
From: "Jeff Peeler" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Wednesday, March 30, 2016 1:22:31 PM
Subject: Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty 
within the Liberty branch

On Wed, Mar 30, 2016 at 3:52 AM, Steven Dake (stdake)  wrote:
>
>
> From: Jeffrey Zhang 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Wednesday, March 30, 2016 at 12:29 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [kolla][vote] Just make Mitaka deploy Liberty
> within the Liberty branch
>
> +1
>
> A lot of changes has been make in Mitaka. Backport is difficult.
>
> But using Mitaka deploy Liberty also has *much works*. For example,
> revert config file change which deprecated in Mitaka and Liberty support.
>
> A important one is the `keystone-manage bootstrap` command to create the
> keystone admin account. This is adderecently and only exist in the Mitaka
> branch. So when using this method, we should revert some commit and use
> the old way method.
>
>
> Agreed.

I'm sure there will be some checking and such once all the code has
been shuffled around, but I think doing this work is better than
abandoning a branch. So +1 to proposal.

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

[Ryan Hallisey]

+1

- Original Message -
From: "Paul Bourke" 
To: openstack-dev@lists.openstack.org
Sent: Tuesday, March 29, 2016 12:10:38 PM
Subject: Re: [openstack-dev] [kolla][vote] Nominating Vikram Hosakot for Core 
Reviewer

+1

On 29/03/16 17:07, 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] deprecation of icehosue/juno/kilo branches

[Ryan Hallisey]

+1 for sure

-Ryan

- Original Message -
From: "Paul Bourke" 
To: openstack-dev@lists.openstack.org
Sent: Friday, March 25, 2016 11:43:06 AM
Subject: Re: [openstack-dev] [kolla][vote] deprecation of icehosue/juno/kilo 
branches

+1

On 25/03/16 15:36, Steven Dake (stdake) wrote:
> Hey folks,
>
> These branches are essentially unmaintained and we have completely given
> up on them.  That’s ok – they were paths of our development.  I didn't
> really want to branch them in the first place, but the community
> demanded it, so I delivered that :)
>
> Now that our architecture is fairly stable in liberty and mitaka, I
> think it makes sense to do the following
> 1.. tag each of the above branches with icehosue-eol, juno-eol, kilo-eol
> 2. Ask infrastructure to remove the branches from git
>
> This is possible; I have just verified in openstack-infra.  I'd like a
> vote from the core review team.  If you would like to see the kilo
> branch stay, please note that, and if there is a majority on
> icehosue/juno but not kilo I'll make the appropriate arrangements with
> openstack-infra.
>
> I will leave voting open for 1 week until Saturday April 2nd.  I will
> close voting early if there is a majority vote.
>
> 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

Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

[Ryan Hallisey]

>>> Hello,
>>>
>>> So Ryan, I think you can make use of heat all the way. Architecture of
>>> kolla doesn't require you to use ansible at all (in fact, we separate
>>> ansible code to a different repo). Truth is that ansible-kolla is
>>> developed by most people and considered "the way to deploy kolla" by
>>> most of us, but we make sure that we won't cut out other deployment
>>> engines from our potential.
>>
>>> So bottom line, heat may very well replace ansible code if you can
>>> duplicate logic we have in playbooks in heat templates. That may
>>> require docker resource with pretty complete featureset of docker
>>> itself (named volumes being most important). Bootstrap is usually done
>>> inside container, so that would be possible too.

>> Heat can call Anisble.

>> Why would it not be Heats responsibility for creating the stack, and
>> then Kolla-ansible for setting everything up?

>> Heat is more esoteric than Ansible.  I expcet the amount of people that
>> know and use Ansible to far outweight the number of people that know
>> Heat.  Let's make it easy for them to get involved.  Use each as
>> appropriate, but let the config with Heat clearly map to a config
>> without it for a Kolla based deploy.

I didn't know heat can call Ansible.  Now that I know that let me refine.
I think it would be nice to have heat use kolla-ansible.

With split-stack/composable-roles, the tripleo-heat-templates are going
to undergo major reconstruction.  So then the questions are, do we
construct the templates to 1) use kolla-ansible or 2) rewrite them with
kolla-ansible logic in heat or 3) go with kolla-kubernetes.

1) This solution involves merging the kolla and tripleo communities.
kolla-tripleo maybe?  This path will come to a solution significantly faster
since it will be completely leveraging the work kolla has done.  I think
ansible is a good tool, but I don't know if it's the best for container
deployment/management.

2) This solution is right along the lines of dprince's patch series [1],
but with focus on deploying kolla's containers.  This option has a longer
road than 1.  I think it could work and I think it would be a good
solution.

> I'd be happy to hear other opinions on that though. Maybe we don't care
> about any of that container cluster management stuff, and if something
> fails we just let everything run degraded until we can pull in a
> replacement? I don't know.

3) Kolla-kubernetes is only a spec at this point, but with kubernetes the
undercloud would use magnum.  This option to me, has the most upside, but
the longest road.  I think the cluster management tools: replication
controllers, health checks, deployments, ect., would be great additions.

My excitement around kolla-ansible stems from the fact that it is significantly
farther along than kolla-kubernetes.  I haven't done a deployment of
kolla-kuberenetes since we dropped it a year ago.  But having done an evaluation
of it recently, I think it's the best option long term.  Until I use it with
kolla + magnum, I won't know for certain.

Thanks,
-Ryan

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

__
OpenStack Development Mailing 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][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

[Ryan Hallisey]

*Snip*

> Indeed, this has literally none of the benefits of the ideal Heat 
> deployment enumerated above save one: it may be entirely the wrong tool 
> in every way for the job it's being asked to do, but at least it is 
> still well-integrated with the rest of the infrastructure.

> Now, at the Mitaka summit we discussed the idea of a 'split stack', 
> where we have one stack for the infrastructure and a separate one for 
> the software deployments, so that there is no longer any tight 
> integration between infrastructure and software. Although it makes me a 
> bit sad in some ways, I can certainly appreciate the merits of the idea 
> as well. However, from the argument above we can deduce that if this is 
> the *only* thing we do then we will end up in the very worst of all 
> possible worlds: the wrong tool for the job, poorly integrated. Every 
> single advantage of using Heat to deploy software will have evaporated, 
> leaving only disadvantages.

I think Heat is a very powerful tool having done the container integration
into the tripleo-heat-templates I can see its appeal.  Something I learned
from integration, was that Heat is not the best tool for container deployment,
at least right now.  We were able to leverage the work in Kolla, but what it
came down to was that we're not using containers or Kolla to its max potential.

I did an evaluation recently of tripleo and kolla to see what we would gain
if the two were to combine. Let's look at some items on tripleo's roadmap.
Split stack, as mentioned above, would be gained if tripleo were to adopt
Kolla.  Tripleo holds the undercloud and ironic.  Kolla separates config
and deployment.  Therefore, allowing for the decoupling for each piece of
the stack.  Composable roles, this would be the ability to land services
onto separate hosts on demand.  Kolla also already does this [1]. Finally,
container integration, this is just a given :).

In the near term, if tripleo were to adopt Kolla as its overcloud it would
be provided these features and retire heat to setting up the baremetal nodes
and providing those ips to ansible.  This would be great for kolla too because
it would provide baremetal provisioning.

Ian Main and I are currently working on a POC for this as of last week [2].
It's just a simple heat template :).

I think further down the road we can evaluate using kubernetes [3].
For now though,  kolla-anisble is rock solid and is worth using for the
overcloud.

Thanks!
-Ryan

[1] - https://github.com/openstack/kolla/blob/master/ansible/inventory/multinode
[2] - https://github.com/rthallisey/kolla-heat-templates
[3] - https://review.openstack.org/#/c/255450/


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

[Ryan Hallisey]

Another tricky situation..

Given that changes to Docker were the cause of the first two backports I'd 
consider those to not be exceptions, but necessary adaptations that Kolla has 
to deal with.  Unfortunately, this case seems more like an exception.  But, I'm 
not opposed to a necessary exception since we planned to deliver on it, but ran 
out of time. +1 to the backport. We definitely need it.

Thanks,
Ryan


- Original Message -
From: "Steven Dake (stdake)" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Tuesday, March 8, 2016 1:15:10 PM
Subject: Re: [openstack-dev] [kolla][vote] exception for backporting upgrades 
to liberty/stable

Exceptions can always be rationalized which is one reason exceptions are evil 
among many. The facts however speak for themselves. If we don't have a way to 
introduce new content in liberty when CVEs are fixed, stable/liberty is just as 
flawed as the data loss problem which was the original trigger for the 
backporting of the playbooks in the first place to introduce named volumes. 

As a result, I am +1 to 1.1.0 backport. 

I am –1 to a 1.2.0 because back to back releases are a pain in the ass to 
manage and offer little value. 1.1.1 without upgrades would be flawed just as 
1.1.0 is today. 

Regards 
-steve 

From: Steven Dake < std...@cisco.com > 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" < 
openstack-dev@lists.openstack.org > 
Date: Monday, March 7, 2016 at 8:03 AM 
To: "OpenStack Development Mailing List (not for usage questions)" < 
openstack-dev@lists.openstack.org > 
Subject: [openstack-dev] [kolla][vote] exception for backporting upgrades to 
liberty/stable 




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. 

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.html#t2016-03-04T18:23:26
 

Warning [1] was a pretty heated argument and there may have been some swearing 
:) 

voting. 

"Should we back-port upgrades 

__
OpenStack Development Mailing List (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] Proposing Alicja Kwasniewska for core reviewer

[Ryan Hallisey]

+1 Nice Job Alicja!

-Ryan

- Original Message -
From: "Eric LEMOINE" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Friday, March 4, 2016 5:04:10 PM
Subject: Re: [openstack-dev] [kolla][vote] Proposing Alicja Kwasniewska for 
core reviewer



+1 

Looking forward to more collaboration on Diagnostics and other stuff :) 


Le 4 mars 2016 17:58, "Steven Dake (stdake)" < std...@cisco.com > a écrit : 
> 
> Core Reviewers, 
> 
> Alicja has been instrumental in our work around jinja2 docker file creation, 
> removing our symlink madness. She has also been instrumental in actually 
> getting Diagnostics implemented in a sanitary fashion. She has also done a 
> bunch of other work that folks in the community already know about that I 
> won't repeat here. 
> 
> I had always hoped she would start reviewing so we could invite her to the 
> core review team, and over the last several months she has reviewed quite a 
> bit! Her 90 day stats[1] place her at #9 with a solid ratio of 72%. Her 30 
> day stats[2] are even better and place her at #6 with an improving ratio of 
> 67%. She also just doesn't rubber stamp reviews or jump in reviews at the 
> end; she sticks with them from beginning to end and finds real problems, not 
> trivial things. Finally Alicja is full time on Kolla as funded by her 
> employer so she will be around for the long haul and always available. 
> 
> Please consider my proposal to be a +1 vote. 
> 
> To be approved for the core reviewer team, Alicja requires a majority vote of 
> 6 total votes with no veto within the one week period beginning now and 
> ending Friday March 11th. If your on the fence, you can always abstain. If 
> the vote is unanimous before the voting ends, I will make appropriate changes 
> to gerrit's acls. If their is a veto vote, voting will close prior to March 
> 11th. 
> 
> Regards, 
> -steve 
> 
> [1] http://stackalytics.com/report/contribution/kolla-group/90 
> [2] http://stackalytics.com/report/contribution/kolla-group/30 
> 
> __ 
> OpenStack Development Mailing List (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

[Ryan Hallisey]

Hello,

I have experience writing selinux policy. My plan was to write the selinux 
policy for Kolla in the next cycle.  I'd be interested in joining if that fits 
the criteria here.

Thanks,
-Ryan

- Original Message -
From: "Steven Dake (stdake)" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Tuesday, March 1, 2016 11:55:55 AM
Subject: [openstack-dev] [kolla][security] Obtaining the
vulnerability:managed tag

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. 

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] discussion about core reviewer limitations by company

[Ryan Hallisey]

Hey Steve,

I think the concept of having a limit on cores from a company or a block on # 
core reviewers
from the same company on a patch is not the right approach.  I understand the 
methodology behind
this is to make sure we stay honest to the code base and objective when 
reviewing, but I don't
think rules/guidelines will accomplish that.  I think what will is that each 
core understands the
culture of the kolla community.  We have a strong and diverse community and 
it's important that we
keep it this way.

The culture will remain strong as long as the message of maintaining the 
culture is echoed by the
PTL and respected by the community members.  That being said, I think we solve 
this problem by
electing PTLs that maintain this culture and electing core reviews that will 
respect this culture.
You've done a great job Steve as PTL voicing your concern about maintaining 
Kolla's diversity as well as
the rest of the core team for following it.  I think this thread is very 
important and glad you
brought it up because as we grow, we don't want to lose sight of this.

Thanks,
-Ryan

__
OpenStack Development Mailing 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] port neutron thin containers to stable/liberty

[Ryan Hallisey]

Hi all.

I'm a little conflicted with my vote.  I'm against the concept of backporting a 
feature, but
this feature also has some important additions to stability. It's just whether 
or not the
stability advantages are critical enough.  To me, it seems like they are.

I just want to note that we need to be mindful of the fact that we are 
dependent on Docker
and that Docker will change very quickly over time.  Given the circumstance, 
the next release
may have some new way of doing something, which can increase stability in an 
old branch.
We need to be mindful that this can happen and it may not be worthy of backport.

In this case I think it's worth it.
+1

-Ryan

__
OpenStack Development Mailing 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] Proposing Angus Salkeld for kolla-core

[Ryan Hallisey]

+1.  Nice work Angus!

-Ryan

> On Feb 19, 2016, at 11:51 PM, Michał Jastrzębski  wrote:
> 
> +1 on condition that he will appear in kolla itself, after
> all...you'll be a kolla core as well right?;)
> 
>> On 19 February 2016 at 21:44, Sam Yaple  wrote:
>> +1 of course. I mean, its Angus. Who can say no to Angus?
>> 
>> Sam Yaple
>> 
>> On Fri, Feb 19, 2016 at 10:57 PM, Michal Rostecki 
>> wrote:
>>> 
 On 02/19/2016 07:04 PM, Steven Dake (stdake) wrote:
 
 Angus is already in kolla-mesos-core but doesn't have broad ability to
 approve changes for all of kolla-core.  We agreed by majority vote in
 Tokyo that folks in kolla-mesos-core that integrated well with the
 project would be moved from kolla-mesos-core to kolla-core.  Once
 kolla-mesos-core is empty, we will deprecate that group.
 
 Angus has clearly shown his commitment to Kolla:
 He is #9 in reviews for Mitaka and #3 in commits(!) as well as shows a
 solid PDE of 64 (meaning 64 days of interaction with either reviews,
 commits, or mailing list participation.
 
 Count my vote as a +1.  If your on the fence, feel free to abstain.  A
 vote of –1 is a VETO vote, which terminates the voting process.  If
 there is unanimous approval prior to February 26, or a veto vote, the
 voting will be closed and appropriate changes made.
 
 Remember now we agreed it takes a majority vote to approve a core
 reviewer, which means Angus needs a +1 support from at least 6 core
 reviewers with no veto votes.
 
 Regards,
 -steve
>>> 
>>> +1
>>> Good job, Angus!
>>> 
>>> __
>>> OpenStack Development Mailing List (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] Nominating Lei Zhang (Jeffrey Zhang in English) - jeffrey4l on irc

[Ryan Hallisey]

+1 nice work!

-Ryan

- Original Message -
From: "Steven Dake (stdake)" 
To: openstack-dev@lists.openstack.org
Sent: Tuesday, January 19, 2016 3:26:38 AM
Subject: [openstack-dev] [kolla] Nominating Lei Zhang (Jeffrey Zhang in 
English) - jeffrey4l on irc

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 


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

[Ryan Hallisey]

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&metric=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

Re: [openstack-dev] [kolla] Please vote -> Removal of Harm Weites from the core reviewer team

[Ryan Hallisey]

Hello all,

Harm, really appreciate all your reviews.  You were always very thorough and 
insightful.  You'll always be welcome back to the core team in the future. 
Thanks for everything Harm! 

+1
-Ryan

- Original Message -
From: "Michal Rostecki" 
To: openstack-dev@lists.openstack.org
Sent: Friday, January 15, 2016 6:46:43 AM
Subject: Re: [openstack-dev] [kolla] Please vote -> Removal of Harm Weites from 
the core reviewer team

On 01/15/2016 01:12 AM, Steven Dake (stdake) wrote:
> 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 voting process.
>
> On a more personal note, I want to personally thank Harm for his many
> and significant contributions to Kolla and especially going above and
> beyond by taking on the responsibility of a core reviewer.  Harm's
> reviews were always very thorough and very high quality, and I really do
> hope in the future Harm will rejoin the Kolla core team.
>
> Regards,
> -steve
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-October/077844.html
>

Hi all,

First of all, thank you Harm for your work on Kolla in the Liberty 
release. And especially for your good reviews and advices when I was 
beginning my contribution to this project.

For now, I'm +1 for removing Harm from core team. But I also hope that 
in future it will be possible for him to rejoin our team and be as 
active as before.

Cheers,
Michal

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.

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

[Ryan Hallisey]

+1 Nice work Michal.

-Ryan

- Original Message -
From: "Sam Yaple" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Friday, November 13, 2015 1:15:05 PM
Subject: Re: [openstack-dev] [kolla] Proposing Michal Rostecki for Core 
Reviewer (nihilfer on IRC)

Michal does great patches and is very receptive to feedback. +1 for me. 

We may need to call him Michal2 though. Might get confusing to have multiple 
Michals on the team. 

Sam Yaple 

On Thu, Nov 12, 2015 at 9:23 AM, Paul Bourke < paul.bou...@oracle.com > wrote: 


+1 


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 


__ 
OpenStack Development Mailing List (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] Integrating kollacli as python-kollaclient

[Ryan Hallisey]

+1

I think it's an excellent addition to kolla.
I think this should help tremendously with usability and building better docs 
around how to use kolla.

-Ryan

> On Oct 23, 2015, at 5:33 PM, Harm Weites  wrote:
> 
> +1 this sort of stuff makes live a lot better :)
> 
> Swapnil Kulkarni schreef op 2015-10-23 07:08:
>> On Thu, Oct 22, 2015 at 3:50 AM, Steven Dake (stdake)
>>  wrote:
>>> Hello Folks,
>>> Oracle has developed a CLI tool for managing OpenStack Kolla
>>> clusters.  Several months ago at our midcycle, the topic was
>>> brought up an I suggested to go ahead and get started on the work. 
>>> We clearly didn't spend enough time discussing how it should be
>>> integrated into the code base or developed or even what its features
>>> should be, and that is my error.
>>> What ended up happening is sort of a code dump, which is not ideal,
>>> but I can only work so many 20 hour days ;)  I didn't believe our
>>> community had the bandwidth to deal with integrating a CLI directly
>>> into the tree while we were focused on our major objective of
>>> implementing Ansible deployment of OpenStack in Docker containers. 
>>> Possibly the wrong call, but it is what it is and it is my error,
>>> not Oracles.
>> I think user experience will of the one of the major milestones for
>> Kolla in Mitaka, e.g. user facing documentation, operator integration
>> etc. a CLI would be helpful in that.
>>> The code can be cloned from:
>>> git clone git://oss.oracle.com/git/openstack-kollacli.git [1]
>>> The code as is is very high quality but will likely need to go
>>> through alot of refactoring to ReST-ify it.  There are two major
>>> authors of the code, Borne Mace and Steve Noyes.
>>> I'd like a majority vote from the core team as to whether we should
>>> add this repository to our list of governed repositories in the
>>> OpenStack Kolla governance repository here:
>> hub.com/openstack/governance/blob/master/reference/projects.yaml#L1509
>>> [2]
>>> Consider this email a +1 vote from me.
>> +1 from me 
>>> A completely separate email thread and decision will be made by the
>>> community about core team membership changes to handle maintenance
>>> of the code.  Assuming this code is voted into Kolla's governance,
>>> I plan to propose Borne as a core reviewer, which will be open to
>>> core team vote as a separate act with our 3 +1 votes no vetos within
>>> 1 week period.  We will address that assuming a majority vote of
>>> the code merge wins.  Steve can follow the normal processes for
>>> joining the core team if he wishes (reviewing patches) - clearly his
>>> code contributions are there.  Borne already does some reviews, and
>>> although he isn't a top reviewer, he does have some contribution in
>>> this area making it into the top 10 for the Liberty cycle.
>>>  
>>> Kolla CLI Features:
>>> * dynamic ansible inventory manipulation via the host, group and
>>> service commands
>>> * ssh key push via the host setup command
>>> * ssh key validation via the host check command
>>> * ansible deployment via the deploy command
>>> * property viewing and modification with the property list, set and
>>> clear commands
>>> * cleanup of docker containers on a single, multiple or all hosts
>>> via the host destroy command
>>> * debug data collection via the dump command
>>> * configuration of openstack passwords via the password command
>>> * Lines of python = 2700
>>> * Lines of  test case code =  1800
>>> * ~ 200 commits
>>   ___
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe [3]
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> [4]
>> Links:
>> --
>> [1] http://oss.oracle.com/git/openstack-kollacli.git
>> [2]
>> hub.com/openstack/governance/blob/master/reference/projects.yaml#L1509
>> [3] http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> [4] 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 Jastrzebski (inc0) for core reviewer

[Ryan Hallisey]

Way to go Michal! +1

-Ryan

- Original Message -
From: "Swapnil Kulkarni" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Wednesday, September 30, 2015 5:00:27 AM
Subject: Re: [openstack-dev] [kolla] proposing Michal Jastrzebski (inc0) for 
core reviewer



On Wed, Sep 30, 2015 at 3:50 AM, Steven Dake (stdake) < std...@cisco.com > 
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 :) 




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

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

[Ryan Hallisey]

> Core reviewers: 
> Please vote +1 if you ARE satisfied with integration with third party 
> unusable without a license software, specifically Cinder volume drivers, 
> Neutron network drivers, and various for-pay distributions of OpenStack and 
> container runtimes. 
> Please vote –1 if you ARE NOT satisfied with integration with third party 
> unusable without a license software, specifically Cinder volume drivers, 
> Neutron network drivers, and various for pay distributions of OpenStack and 
> container runtimes. 

> A bit of explanation on your vote might be helpful. 

> My vote is +1. I have already provided my rationale. 

> Regards, 
> -steve 

Sorry I'm a little late with my response.

I think it's good for us to allow outside parties in.  Our community is 
growing, but in order to get to the next level, we need to be welcoming of more 
outside parties.
Furthermore, I think having a defined structure on how outside parties will fit 
in is important so we maintain project organization.
The ideas that have been listed below I agree with. +1 for integration given 
our set of rules.

-Ryan

> __ 
> OpenStack Development Mailing List (not for usage questions) 
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> Both arguments sound valid to me, both have pros and cons. 
> 
> I think it's valuable to look to the experiences of Cinder and Neutron in 
> this area, both of which seem to have the same scenario and have existed much 
> longer than Kolla. From what I know of how these operate, proprietary code is 
> allowed to exist in the mainline so long as certain set of criteria is met. 
> I'd have to look it up but I think it mostly comprises of the relevant 
> parties must "play by the rules", e.g. provide a working CI, help with 
> reviews, attend weekly meetings, etc. If Kolla can look to craft a similar 
> set of criteria for proprietary code down the line, I think it should work 
> well for us. 
> 
> Steve has a good point in that it may be too much overhead to implement a 
> plugin system or similar up front. Instead, we should actively monitor the 
> overhead in terms of reviews and code size that these extra implementations 
> add. Perhaps agree to review it at the end of Mitaka? 
> 
> Given the project is young, I think it can also benefit from the increased 
> usage and exposure from allowing these parties in. I would hope independent 
> contributors would not feel rejected from not being able to use/test with the 
> pieces that need a license. The libre distros will remain #1 for us. 
> 
> So based on the above explanation, I'm +1. 
> 
> -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 
> 
> 
> Given Paul's comments I would agree here as well. I would like to get that 
> 'criteria' required for Kolla to allow this proprietary code into the main 
> repo down as soon as possible though and suggest that we have a bare minimum 
> of being able to gate against it as one of the criteria. 
> 
> As for a plugin system, I also agree with Paul that we should check the 
> overhead of including these other distros and any types needed after we have 
> had time to see if they do introduce any additional overhead. 
> 
> So for the question 'Do we allow code that relies on proprietary packages?' I 
> would vote +1, with the condition that we define the requirements of allowing 
> that code as soon as possible. 
> 
> __ 
> OpenStack Development Mailing List (not for usage questions) 
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> I am +1 on the system with following criteria we already discussed above 
> 
> - Set of defined requirements to adhere to for contributing and maintaining 
> - Set of contributors contributing to and reviewing the changes in Kolla. 
> - Set of maintainers available to connect with if we require any urgent 
> attention to any failures in Kolla due to the code. 
> - CI if possible, we can evaluate the options as we finalize. 
> 
> Since we are on the subject of " OpenStack as a whole", I think OpenStack has 
> evolved better with more operators contributing to the code base, since we 
> need to let the code break to make it robust. This can be very easily 
> observed with Cinder and Neutron specially, the different nature of 
> implementations has always helped the base source improvements which were 
> never thought of. 
> 
> I agree with Paul that Kolla benefit more with increased participa

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

[Ryan Hallisey]

+1 Nice job!

-Ryan

- Original Message -
From: "Steven Dake (stdake)" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Friday, August 14, 2015 9:29:10 AM
Subject: [openstack-dev] [kolla] Proposing Swapnil Kulkarni (coolsvap) for 
kolla core reviewer team

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. 

Thanks! 
-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] [TripleO] [Puppet] [kolla] Deploying OpenStack with Puppet modules on Docker with Heat

[Ryan Hallisey]

> I have a few questions:

> * when do you run puppet? before starting the container so we can
> generate a configuration file?

We would run puppet before starting the container that way puppet can
generate the config and the container absorb it.

> * so iiuc, Puppet is only here to generate OpenStack configuration files
> and we noop all other operations. Right?

Correct.  So far this is the case.

> * from a Puppet perspective, I really prefer this approach:
> https://review.openstack.org/#/c/197172/ where we assign tags to
> resources so we can easily modify/drop Puppet resources using our
> modules. What do you think (for long term)?

It's possible.  I'd have to look into this, but it's something we can
explore.

> * how do you manage multiple configuration files? (if a controller is
> running multiple nova-api containers with different configuration files?

In the heat template we could specify the exact config file to hand into
the container.  This is the same case for say neutron that has multiple
config files for a single service.

> Once I understand a bit more where we go, I'll be happy to help to make
> it happen in our modules, we already have folks deploying our modules
> with containers, I guess we can just talk and collaborate here.
> Also, I'll be interested to bringing containers support in our CI, but
> that's a next step :-)

Cool!  Will keep the thread posted on how the work progresses.
You can follow along with this patch: https://review.openstack.org/#/c/209505/1

-Ryan

__
OpenStack Development Mailing 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] Deprecating config-internal

[Ryan Hallisey]

- Original Message -
From: "James Slagle" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Friday, August 7, 2015 11:20:59 AM
Subject: Re: [openstack-dev] [kolla][tripleo] Deprecating config-internal

On Fri, Aug 7, 2015 at 11:08 AM, Dan Prince  wrote:
> On Fri, 2015-08-07 at 14:21 +, Steven Dake (stdake) wrote:
>> James and Dan,
>>
>> During the ansible-multi spec process that James Slagle reviewed,
>> there was a serious commitment by the Kolla core team to maintain
>> config-internal, pretty much for the tripleo use case.  We didn’t
>> want to leave our partner projects in the lurch and at the time
>> Ryan/Ian’s implementation of tripleo containers were based upon
>> config-internal.  It would be immensely helpful for Kolla if we could
>> deprecate that model during l3, and I think Dan’s judgement is to use
>> config-external (with some additional beefing up of some of the
>> containers like snmp+ceilometer compute plus possibly some other
>> minor solveable requirements).
>
> Correct. I'm heavily leaning towards using config-external assuming we
> can make it support use of multiple config files, and then have a way
> to tie that into starting the service with the same files (neutron ml2
> agent for example uses multiple configs)
>
>>
>> Can I get a general ack from the tripleo community that deprecating
>> config-internal is a-ok so we can just remove it before being stuck
>> with it for Liberty?
>
> ++ from me

I think using external config works well. The existing puppet recipes
are very advanced so it would provide more config options available to use
with the containerized services.

+1
-Ryan

>
>>   I don’t want to deprecate something we committed to supporting if
>> there is still requirement from the tripleo community to maintain it,
>> but it would make our lives a lot easier and thus far the config
>> -internal case is really only for TripleO.
>>
>> Comments welcome.
>>
>> Thanks!
>> -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



-- 
-- James Slagle
--

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

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

Re: [openstack-dev] [TripleO] [Puppet] [kolla] Deploying OpenStack with Puppet modules on Docker with Heat

[Ryan Hallisey]

Tagging kolla so the kolla community also sees it.
Pardon the top posting.

-Ryan

- Original Message -
From: "Dan Prince" 
To: "openstack-dev" 
Sent: Wednesday, August 5, 2015 2:29:13 PM
Subject: [openstack-dev] [TripleO] [Puppet] Deploying OpenStack with Puppet 
modules on Docker with Heat

Hi,

There is a lot of interest in getting support for container based
deployment within TripleO and many different ideas and opinions on how
to go about doing that.

One idea on the table is to use Heat to help orchestrate the deployment
of docker containers. This would work similar to our tripleo-heat
-templates implementation except that when using docker you would swap
in a nested stack template that would configure containers on
baremetal. We've even got a nice example that shows what a
containerized TripleO overcloud might look like here [1]. The approach
outlines how you might use kolla docker containers alongside of the
tripleo-heat-templates to do this sort of deployment.

This is all cool stuff but one area of concern is how we do the actual
configuration of the containers. The above implementation relies on
passing environment variables into kolla built docker containers which
then self configure all the required config files and start the
service. This sounds like a start... but creating (and maintaining)
another from scratch OpenStack configuration tool isn't high on my list
of things to spend time on. Sure there is already a kolla community
helping to build and maintain this configuration tooling (mostly
thinking config files here) but this sounds a bit like what tripleo
-image-elements initially tried to do and it turns out there are much
more capable configuration tools out there.

Since we are already using a good bit of Puppet in tripleo-heat
-templates the idea came up that we would try to configure Docker
containers using Puppet. Again, here there are several ideas in the
Puppet community with regards to how docker might best be configured
with Puppet. Keeping those in mind we've been throwing some ideas out
on an etherpad here [2] that describes using Heat for orchestration,
Puppet for configuration, and Kolla docker images for containers.

A quick outline of the approach is:

-Extend the heat-container-agent [3] that runs os-collect-config and
all the required hooks we require for deployment. This includes docker
-compute, bash scripts, and Puppet. NOTE: As described in the etherpad
I've taken to using DIB to build this container. I found this to be
faster from a TripleO development baseline.

-To create config files the heat-container-agent would run a puppet
manifest for a given role and generate a directory tree of config files
(/var/lib/etc-data for example).

-We then run a docker-compose software deployment that mounts those
configuration file(s) into a read only volume and uses them to start
the containerized service.

The approach could look something like this [4]. This nice thing about
this is that it requires no modification to OpenStack Puppet modules.
We can use those today, as-is. Additionally, although Puppet runs in
the agent container we've created a mechanism to set all the resources
to noop mode except for those that generate config files. And lastly,
we can use exactly the same role manifest for docker that we do for
baremetal. Lots of re-use here... and although we are disabling a lot
of Puppet functionality in setting all the non-config resources to noop
the Kolla containers already do some of that stuff for us (starting
services, etc.).



All that said (and trying to keep this short) we've still got a bit of
work to do around wiring up externally created config files to kolla
build docker containers. A couple of issues are:

-The external config file mechanism for Kolla containers only seems to
support a single config file. Some services (Neutron) can have multiple
files. Could we extend the external config support to use multiple
files?

-If a service has multiple files kolla may need to adjust its service
startup script to use multiple files. Perhaps a conf.d approach would
work here?

-We are missing published version of some key kolla containers. Namely
openvswitch and the neutron-openvswitch-agent for starters but I'd also
like to have a Ceilometer agent and SNMP agent container as well so we
have feature parity with the non-docker compute role.

Once we have solutions for the above I think we'll be very close to a
fully dockerized compute role with TripleO heat templates. From there
we can expand the idea to cover other roles within the tripleo-heat
-templates too.

I'll stop there for now. Any ideas and thoughts appreciated.

Dan

-

[1] https://review.openstack.org/#/c/178840/ (Containerized TripleO
Overcloud.)
[2] https://etherpad.openstack.org/p/tripleo-docker-puppet
[3] http://git.openstack.org/cgit/openstack/heat
-templates/log/hot/software-config/heat-container-agent
[4] https://review.openstack.org/#/c/209505/  (Docker compute role
configured 

Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

[Ryan Hallisey]

+1 I echo all the prior comments.

-Ryan

- Original Message -
From: "Steven Dake (stdake)" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, July 13, 2015 10:40:11 PM
Subject: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

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 

__
OpenStack Development Mailing List (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 new core-reviewer Harm Waites

[Ryan Hallisey]

+1 Great job with Cinder.

-Ryan

- Original Message -
From: "Steven Dake (stdake)" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Sunday, June 14, 2015 1:48:48 PM
Subject: [openstack-dev] [kolla] Proposal for new core-reviewer Harm Waites

Hey folks, 

I am proposing Harm Waites for the Kolla core team. He did a fantastic job 
implementing Designate in a container[1] which I’m sure was incredibly 
difficult and never gave up even though there were 13 separate patch reviews :) 
Beyond Harm’s code contributions, he is responsible for 32% of the 
“independent” reviews[1] where independents compose 20% of our total reviewer 
output. I think we should judge core reviewers on more then output, and I knew 
Harm was core reviewer material with his fantastic review of the cinder 
container where he picked out 26 specific things that could be broken that 
other core reviewers may have missed ;) [3]. His other reviews are also as 
thorough as this particular review was. Harm is active in IRC and in our 
meetings for which his TZ fits. Finally Harm has agreed to contribute to the 
ansible-multi implementation that we will finish in the liberty-2 cycle. 

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 :) Since our core 
team has grown a bit, I’d like 3 core reviewer +1 votes this time around (vs 
Sam’s 2 core reviewer votes). I will leave the voting open until June 21  
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] https://review.openstack.org/#/c/182799/ 
[2] 
http://stackalytics.com/?project_type=all&module=kolla&company=%2aindependent 
[3] https://review.openstack.org/#/c/170965/ 

__
OpenStack Development Mailing List (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 changing 1600UTC meeting to 1700 UTC

[Ryan Hallisey]

After some upstream discussion, moving the meeting from 1600 to 1700 UTC does 
not seem very popular.
It was brought up that changing the time to 16:30 UTC could accommodate more 
people.

For the people that attend the 1600 UTC meeting time slot can you post further 
feedback to address this?

Thanks,
Ryan

- Original Message -
From: "Jeff Peeler" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Tuesday, June 9, 2015 2:19:00 PM
Subject: Re: [openstack-dev] [kolla] Proposal for changing 1600UTC meeting to 
1700 UTC

On Mon, Jun 08, 2015 at 05:15:54PM +, Steven Dake (stdake) wrote:
>Folks,
>
>Several people have messaged me from EMEA timezones that 1600UTC fits 
>right into the middle of their family life (ferrying kids from school 
>and what-not) and 1700UTC while not perfect, would be a better fit 
>time-wise.
>
>For all people that intend to attend the 1600 UTC, could I get your 
>feedback on this thread if a change of the 1600UTC timeslot to 1700UTC 
>would be acceptable?  If it wouldn’t be acceptable, please chime in as 
>well.

Both 1600 and 1700 UTC are fine for me.

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

Re: [openstack-dev] [kolla] Add core approver Sam Yaple

[Ryan Hallisey]

+1

Sam has done an great job integrating his work into Kolla and I look forward to 
seeing more of his contributions!

-Ryan

- Original Message -
From: "Andre Martin" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, May 25, 2015 9:37:24 PM
Subject: Re: [openstack-dev] [kolla] Add core approver Sam Yaple


On May 26, 2015, at 03:59, Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:

Hi folks,

I propose Sam Yaple for core approver for the Kolla team.  Sam has a lot of 
great ideas and has done some really cool work lately.  Sam is active in IRC 
and is starting to pick up more reviews.  Of particular interest to me his his 
idea of merging the work he has done on YAODU into Kolla.  This would be 
fantastic for Kolla and allow us to deliver on our goals of providing high 
availability which depends on multi-node deployment in our container 
architecture.

Some really complex and nice improvements to the codebase:
https://review.openstack.org/#q,Ifc7bac0d827470f506c8b5c004a833da9ce13b90,n,z
https://review.openstack.org/#q,Ic0ff96bb8119ddfab15b99e9f1e21cfe8d321dab,n,z
https://review.openstack.org/#q,I95101136dad56e9331d8b92cd394495f7bd0576a,n,z

Sam's stats for Liberty and Kilo:
http://stackalytics.com/?project_type=all&user_id=s8m&module=kolla&release=all

Count my proposal as a +1.  Since our core team is only 5 people presently, I 
think it makes sense to only require one additional +1.  Typically projects 
require 3 +1 votes but have larger core teams, so we will use that in the 
future.  -1 = veto, so vote wisely.  Folks often abstain if they are not 
certain how their vote should go – so don’t feel compelled to vote.

I’ll keep the voting open until May 29th.  If the vote is unanimous or vetoed 
prior, I’ll close voting.

Huge +1 for me. Sam is an excellent engineer with lots of interesting ideas, he 
would be a great addition to the core team.

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


"PLEASE NOTE:  This email,  and  any  attachments  hereto,  are
intended only  for use  by the specified addressee(s)  and  may
contain legally privileged and/or confidential and/or proprietary
information of KVH Co., Ltd.  and/or its affiliates  (including
personal information).  If you are not the intended recipient of
this email, please immediately notify the sender by email,  and
please permanently  delete the original,  any print out and any
copies of the foregoing. "



__
OpenStack Development Mailing List (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][kolla] Investigating containerizing TripleO

[Ryan Hallisey]

Hi,

Over the last few weeks Ian Main and I have been working on getting some 
integration between Kolla and tripleo.
For a simple proof of concept, we launched devstack to serve as an undercloud 
and used heat to spawn an overcloud
on a rhel-atomic image. In the overcloud, we deployed openstack in containers 
pulling from the latest kolla images.
We successfully tested keystone, loading an image into glance, booting an image 
in nova, and sshing into that image.

We're starting to move over to a tripleo environment to try and directly 
integrate now that we've proven it works.
Here is the heat template that we are using: 
https://github.com/rthallisey/atomic-osp-installer/blob/master/heat/openstack_deploy.yaml
This will serve as a template that will get openstack up and running on a 
single node.  This template is a good foundation 
to create addition templates since any other config is mostly going to be a 
copy and paste.  

This POC uses atomic to start up openstack, but it can also be done using 
docker-compose.
The heat template for docker compose should look about the same.

We're going to push this work upstream shortly, but in the meantime the work 
can be tracked in the repo I linked above.

Thanks,
Ryan Hallisey

__
OpenStack Development Mailing 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] making Daneyon Hansen core

[Ryan Hallisey]

Great work Daneyon!  Excellent job with neutron and nova-networking!

+1
-Ryan

- Original Message -
From: "Steven Dake" 
To: "OpenStack Development Mailing List" 
Sent: Wednesday, October 22, 2014 11:04:24 AM
Subject: [openstack-dev] [kolla] making Daneyon Hansen core

A few weeks ago in IRC we discussed the criteria for joining the core 
team in Kolla.  I believe Daneyon has met all of these requirements by 
reviewing patches along with the rest of the core team and providing 
valuable comments, as well as implementing neutron and helping get 
nova-networking implementation rolling.

Please vote +1 or -1 if your kolla core.  Recall a -1 is a veto.  It 
takes 3 votes.  This email counts as one vote ;)

Regards
-steve


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] Kolla Blueprints

[Ryan Hallisey]

Hi all,

The blueprints have been setup for Kolla: https://blueprints.launchpad.net/kolla

Currently, there are blueprints for all of the openstack services and a few 
supporting services.
They are, nova, swift, cinder, neutron, horizon, keystone, glance, ceilometer, 
heat, trove, 
zaqar, sahara, mysql, and rabbitmq.

Feel free to take ownership of a service!

Thanks,
Ryan Hallisey

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack][keystone] (98)Address already in use: make_sock: could not bind to address [::]:5000 & 0.0.0.0:5000

[Ryan Hallisey]

Hi,

You can handle this one of two ways.

1)
semanage port -m -t  -p tcp 5000

Which will relabel port 5000 as whatever you choose.

2)
Or you could allow  to bind to commplex_main_port_t

allow  commplex_main_port_t:tcp_socket name_bind;

This will allow  to connect to any port labeled 
commplex_main_port_t. 

Sincerely,
Ryan

- Original Message -
From: "Ray Chen" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Thursday, July 17, 2014 10:57:41 AM
Subject: Re: [openstack-dev] [devstack][keystone] (98)Address already in use: 
make_sock: could not bind to address [::]:5000 & 0.0.0.0:5000

try to disable the selinux module. I can setup devstack env on my fedora 
machine with selinux disabled 

on my fedora machine, selinux is disable, and port 5000 look likes are still 
used by selinux, 
[ray@fedora devstack]$ sudo semanage port -l|grep 5000 
cluster_port_t tcp 5149, 40040, 50006-50008 
cluster_port_t udp 5149, 50006-50008 
commplex_main_port_t tcp 5000 
commplex_main_port_t udp 5000 

[ray@fedora devstack]$ netstat -anp | grep 5000 

tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN 6171/python 
[ray@fedora devstack]$ ps -ef | grep python 
ray 6171 5695 0 21:34 pts/3 00:00:07 python 
/opt/stack/keystone/bin/keystone-all --config-file /etc/keystone/keystone.conf 
--debug 




On Thu, Jul 17, 2014 at 10:23 PM, Rich Megginson < rmegg...@redhat.com > wrote: 



On 07/16/2014 10:40 PM, Joe Jiang wrote: 



Hi all, 
Thanks for your responds. 

I try to running # sudo semanage port -l|grep 5000 in my envrionment and get 
same infomation. 
>> ... 
>> commplex_main_port_t tcp 5000 
>> commplex_main_port_t udp 5000 
then, I wanna remove this port(5000) from SELinux policy rules list use this 
command(semanage port -d -p tcp -t commplex_port_t 5000), 
the console echo is "/usr/sbin/semanage: Port tcp/5000 is defined in policy, 
cannot be deleted" , and 'udp/5000' is same reply. 
Some sounds[1] say, this port is declared in the corenetwork source policy 
which is compiled in the base module. 
So, Have to recompile selinux module? 

I think that's the only way to do it if you want to relabel port 5000. 








Thanks. 
Joe. 

[1] 
http://www.redhat.com/archives/fedora-selinux-list/2009-September/msg00056.html 




>> Another problem with port 5000 in Fedora, and probably more recent
>> versions of RHEL, is the selinux policy:
>>  
>> # sudo semanage port -l|grep 5000
>> ...
>> commplex_main_port_t tcp 5000
>> commplex_main_port_t udp 5000
>>  
>> There is some service called "commplex" that has already "claimed" port
>> 5000 for its use, at least as far as selinux goes. 




___ 
OpenStack-dev mailing list 
OpenStack-dev@lists.openstack.org 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Fwd: OpenStack and SELinux fixes

[Ryan Hallisey]

Hi,

Could everyone please test OpenStack+SELinux with the latest RHEL7.0 builds.  
We are running into the same avc's that have fixes released for them.

https://brewweb.devel.redhat.com/buildinfo?buildID=357647

Thank you.

Regards,
Miroslav and Ryan

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone]

[Ryan Hallisey]

I retested by adding the '.info' suffix then looked at the message queue and it 
still isn't there.

The line notifier.info({}, "some type", "some payload") labels it so that it 
should be
sent to notifications.info. For example if I changed it to notifier.warn it 
should appear
in the queue as notifier.warn.

I can successfully send a message from nova with: 

#!/usr/bin/env python   

from nova import config
from oslo.config import cfg
from nova.openstack.common import log as logging
from oslo import messaging
import sys

CONF = cfg.CONF
config.parse_args(sys.argv)
logging.setup("nova")

transport = messaging.get_transport(CONF)

notifier = messaging.Notifier(transport,
  'test_pub_id')

notifier.info({}, "some type", "some payload")



- Original Message -
From: "Nader Lahouti" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, April 14, 2014 5:10:03 PM
Subject: Re: [openstack-dev] [keystone]

Are you sure that Notifier adds '.info' suffix to the topic that you provided? 
I think you should use topic=' notification.info '. 

Thanks, 
Nader. 



On Mon, Apr 14, 2014 at 12:02 PM, Ryan Hallisey < rhall...@redhat.com > wrote: 


Hello, 

I am unable to send a keystone notification with these parameters in 
keystone.conf: 

rabbit_password = stack 
rabbit_hosts = localhost 
rpc_backend = rabbit 
notification_driver = messaging 

When I look at the message queues: sudo /usr/sbin/rabbitmqctl list_queues 

notifications.audit 0 
notifications.critical 0 
notifications.debug 0 
notifications.error 0 
notifications.info 0 
notifications.sample 0 
notifications.warn 0 
notifications_bis.audit 0 
notifications_bis.critical 0 
notifications_bis.debug 0 
notifications_bis.error 0 
notifications_bis.info 0 
notifications_bis.sample 0 
notifications_bis.warn 0 

I don't get a 1 under notifications.info . Any thoughts about why I am not 
seeing the notification? 

I send the notification by: 

import os 
import sys 
from keystone import config 
from oslo import messaging 
import pbr.version 

CONF = config.CONF 
transport = messaging.get_transport(CONF) 
notifier = messaging.Notifier(transport, 
'test_pub_id', 
driver='messaging', 
topic='notifications') 

notifier.info ({}, "some type", "some payload") 



Thanks, 
Ryan Hallisey 

___ 
OpenStack-dev mailing list 
OpenStack-dev@lists.openstack.org 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone]

[Ryan Hallisey]

Hello,

I am unable to send a keystone notification with these parameters in 
keystone.conf:

rabbit_password = stack
rabbit_hosts = localhost
rpc_backend = rabbit
notification_driver = messaging

When I look at the message queues: sudo /usr/sbin/rabbitmqctl list_queues

notifications.audit 0
notifications.critical  0
notifications.debug 0
notifications.error 0
notifications.info  0
notifications.sample0
notifications.warn  0
notifications_bis.audit 0
notifications_bis.critical  0
notifications_bis.debug 0
notifications_bis.error 0
notifications_bis.info  0
notifications_bis.sample0
notifications_bis.warn  0

I don't get a 1 under notifications.info.  Any thoughts about why I am not 
seeing the notification?

I send the notification by:

import os
import sys
from keystone import config
from oslo import messaging
import pbr.version

CONF = config.CONF
transport = messaging.get_transport(CONF)
notifier = messaging.Notifier(transport,
  'test_pub_id',
  driver='messaging',
  topic='notifications')

notifier.info({}, "some type", "some payload")



Thanks,
Ryan Hallisey

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] [horizon] [nova]

[Ryan Hallisey]

Currently, when you delete a tenant that has 1 or more running instances, the 
tenant will be deleted
without warning and the running instance(s) will be left in place. Should there 
be a warning
and should the admin be allowed to do this?  Or should it be left be?

Thanks,
-Ryan Hallisey


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev