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

[Jeremy Stanley]

On 2018-03-31 18:06:07 + (+), Steven Dake (stdake) wrote:
> I appreciate your personal interest in attempting to clarify the
> Kolla mission statement.
> 
> The change in the Kolla mission statement you propose is
> unnecessary.
[...]

I should probably have been more clear. The Kolla mission statement
right now says that the Kolla team produces two things: containers
and deployment tools. This may make it challenging for the team to
avoid tightly coupling their deployment tooling and images, creating
a stratification of first-class (those created by the Kolla team)
and second-class (those created by anyone else) support for
deployment tools using those images.

Is the intent to provide "a container-oriented deployment solution
and the container images it uses" (kolla-ansible as first-class
supported deployment engine for these images) or "container images
for use by arbitrary deployment solutions, along with an example
deployment solution for use with them" (kolla-ansible on equal
footing with competing systems that make use of the same images)?
-- 
Jeremy Stanley


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

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

[Michał Jastrzębski]

So my take on the issue.

I think splitting Kolla and Kolla-Ansible to completely new project
(including name change and all) might look good from purity
perspective (they're effectively separate), but would cause chaos and
damage to production deployments people use. While code will be the
same, do we scrub "kolla" name from kolla-ansible code? Do we change
config paths? Configs lands in /etc/kolla so I guess new project
shouldn't do that? Not to mention that operators are used to this
nomenclature and build tools around it (for example Kayobe) and there
is no telling how many production deployments would get hurt. At the
same time I don't think there is much to gain from split like that, so
that's not really practical.

We can do this for Kolla-kubernetes as it hasn't released 1.0 so there
won't (or shouldn't) be production environments based on it.

We already have separate core teams for Kolla and Kolla-Ansible. From
my experience organizing PTG and other events for both (or rather all
3 deliverables) together makes sense and makes scheduling of
attendance much easier.

On 31 March 2018 at 11:06, Steven Dake (stdake)  wrote:
> On March 31, 2018 at 6:45:03 AM, Jeremy Stanley (fu...@yuggoth.org) wrote:
>
> [...]
> Given this, it sounds like the current Kolla mission statement of
> "provide production-ready containers and deployment tools for
> operating OpenStack clouds" could use some adjustment to drop the
> production-ready containers aspect for further clarity. Do you
> agree?
> [...]
>
> I appreciate your personal interest in attempting to clarify the Kolla
> mission statement.
>
> The change in the Kolla mission statement you propose is unnecessary.
>
> Regards
>
> -steve
>
>
>
> Jeremy Stanley
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing 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-kubernete][tc][openstack-helm]propose retire kolla-kubernetes project

[Steven Dake (stdake)]

On March 31, 2018 at 6:45:03 AM, Jeremy Stanley 
(fu...@yuggoth.org) wrote:
[...]
Given this, it sounds like the current Kolla mission statement of
"provide production-ready containers and deployment tools for
operating OpenStack clouds" could use some adjustment to drop the
production-ready containers aspect for further clarity. Do you
agree?
[...]

I appreciate your personal interest in attempting to clarify the Kolla mission 
statement.

The change in the Kolla mission statement you propose is unnecessary.

Regards

-steve


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

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

[Jeremy Stanley]

On 2018-03-31 03:13:01 + (+), Steven Dake (stdake) wrote:
[...]
> When contributors joined the Kolla project, we had a clear mission
> of providing containers and deployment tools.  Our ultimate
> objective was to make deployment *EASY* and solve from my
> perspective as PTL at the time what was OpenStack's number one
> pain point.
[...]

So, if I understand what you're suggesting, Kolla is a deployment
project. It uses Ansible and builds container images, but those are
merely implementation details. Other projects have found the
container images useful outside of Kolla and so the Kolla team has
attempted to be helpful in supporting their direct in unrelated
deployment tools but has no desire to decouple the deployment
tooling and image building components any further than necessary.

Given this, it sounds like the current Kolla mission statement of
"provide production-ready containers and deployment tools for
operating OpenStack clouds" could use some adjustment to drop the
production-ready containers aspect for further clarity. Do you
agree?
-- 
Jeremy Stanley


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

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

[Steven Dake (stdake)]

On March 30, 2018 at 2:17:09 AM, Thierry Carrez 
(thie...@openstack.org) wrote:

There is a 3rd option, which I've been advocating for a while.

The tension here lies in the fact that the Kolla team is both a
low-level provider (Kolla the docker image provider) and a higher-level
deployment provider (kolla-ansible, kolla-k8s). The low-level images are
used outside of the team (TripleO, openstack-helm), in the team
(kolla-ansible) and in the team but by a different group (kolla-k8s).

The proposals on the table only partly resolve that tension. Keeping
kolla-k8s in kolla, spinning it out or merging it with OSH still make
kolla both a low-level and a high-level provider. As long as
kolla-ansible shares naming and is produced by the exact same team
producing Kolla itself, anything else than kolla-ansible will stay a
second-class consumer, breeding validation fears like the one described
above.

For the structure to match the technical goals, I wonder if "Kolla"
should not focus on low-level image production, with the various
higher-level Kolla consumers being set up as separate projects on an
equal footing. I understand that Kolla and Kolla-Ansible are currently
mostly the same group of people, but nothing in OpenStack prevents
anyone from being part of two teams. Setting up discrete groups would
actually encourage people interested in Kolla but not so much in
Kolla-Ansible to join the Kolla team. It would encourage the Kolla team
to treat all consumers equally and test their images on those various
consumers equally.

So my 3rd option would be to split the current Kolla team into three
teams with different names, matching the three deliverables that this
team currently has. Then if kolla-k8s needs to be sunset or merged with
OSH, so be it.

--
Thierry Carrez (ttx)


Just got back from Ready Player One.  Good Movie!

Thanks Thierry for offering up your advocated position.

When contributors joined the Kolla project, we had a clear mission of providing 
containers and deployment tools.  Our ultimate objective was to make deployment 
*EASY* and solve from my perspective as PTL at the time what was OpenStack's 
number one pain point.

What you're asking is for people to divide their time between two separate 
projects and take responsibility for making containers functional for other 
projects.

Currently the core team has been generous with our time reviewing people's work 
in addition with +2/+As that want to use other deployment tools with Kolla 
containers, as referenced by TripleO, OSH, as well as a variety of other 
proprietary deployment tools.  Some of these contributors are also core 
reviewers themselves.  I don't expect this work would slow down under the 
current governance model of Kolla as we provide a very clear API to use when 
interfacing with Kolla.  Hence we do not *make it hard* to contribute to the 
containers deliverable.  The same cannot be said in your proposed governance 
model.

What your proposal asks is for contributors that came to scratch an itch to 
scratch a bunch of other itches that may not be to their interest, attend twice 
as meetings, attend twice as many PTG sessions or midcycles and grow some 
amount of expertise in understanding the various problems of other deployment 
projects.  Ultimately I have a big concern this would drive contributors away, 
rather than solve a perceived second order problem with our current governance 
model.

Regards,
-steve

[1] is for more reading about the structure or Kolla.

[1] https://www.ansible.com/blog/openstack-kolla

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/maila man/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-kubernete][tc][openstack-helm]propose retire kolla-kubernetes project

[Thierry Carrez]

Richard Wellum wrote:
> So as a current Kolla-Kubernetes Core - I have a slightly different
> opinion than most, I'll try to verbalize it coherently.

Thanks Rich for posting this -- I was really feeling like we missed part
of the story.

> Lets talk about what Kolla is:
> 
> Kolla is a project that builds OpenStack docker images, stores them on
> dockerhub, and provides tools to build your own images from your own
> source. Both the images and the tools it provides, are widely used, very
> popular and extremely stable; TripleO, openstack-helm and kolla-ansible
> to name a few are all deployment methods that use Kolla.
> 
> Kolla has two sub-projects, that both revolve around deployment methods;
> kolla-ansible and kolla-kubernetes. Kolla-ansible is proven, stable and
> used by many in the industry. Part of Kolla's quality is it's rock-solid
> dependability in many scenarios. As Kubernetes took over most of the COE
> world, it's only correct that the Kolla team created this sub-project;
> if swarm became suddenly very popular then we should create a
> kolla-swarm sub-project.
> 
> So if we abandon kolla-kubernetes ('sunset' seems much more romantic
> admittedly) - we are abandoning the core Kolla team's efforts in this
> space. No matter how good openstack-helm is (and I've deployed it, know
> a lot of the cores and it's truly excellent and well driven), what
> happens down the line if openstack-helm decide to move on from Kolla -
> say focussing on Loci images or a new flavor that comes along? Then
> Kolla the core project, will no longer have any validation of it's
> docker images/containers running on Kubernetes. That to me is the big
> risk here.

There is a 3rd option, which I've been advocating for a while.

The tension here lies in the fact that the Kolla team is both a
low-level provider (Kolla the docker image provider) and a higher-level
deployment provider (kolla-ansible, kolla-k8s). The low-level images are
used outside of the team (TripleO, openstack-helm), in the team
(kolla-ansible) and in the team but by a different group (kolla-k8s).

The proposals on the table only partly resolve that tension. Keeping
kolla-k8s in kolla, spinning it out or merging it with OSH still make
kolla both a low-level and a high-level provider. As long as
kolla-ansible shares naming and is produced by the exact same team
producing Kolla itself, anything else than kolla-ansible will stay a
second-class consumer, breeding validation fears like the one described
above.

For the structure to match the technical goals, I wonder if "Kolla"
should not focus on low-level image production, with the various
higher-level Kolla consumers being set up as separate projects on an
equal footing. I understand that Kolla and Kolla-Ansible are currently
mostly the same group of people, but nothing in OpenStack prevents
anyone from being part of two teams. Setting up discrete groups would
actually encourage people interested in Kolla but not so much in
Kolla-Ansible to join the Kolla team. It would encourage the Kolla team
to treat all consumers equally and test their images on those various
consumers equally.

So my 3rd option would be to split the current Kolla team into three
teams with different names, matching the three deliverables that this
team currently has. Then if kolla-k8s needs to be sunset or merged with
OSH, so be it.

-- 
Thierry Carrez (ttx)

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

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

[Richard Wellum]

On Thu, Mar 29, 2018 at 8:14 PM Surya Singh 
wrote:

> Dear All,
>
> Thanks Rich for putting thoughts on continuation with kolla-k8s.
>
>
> On Fri, Mar 30, 2018 at 2:26 AM, Richard Wellum 
> wrote:
> >
> > Hi,
> >
> > So as a current Kolla-Kubernetes Core - I have a slightly different
> opinion than most, I'll try to verbalize it coherently.
> >
> > Lets talk about what Kolla is:
> >
> > Kolla is a project that builds OpenStack docker images, stores them on
> dockerhub, and provides tools to build your own images from your own
> source. Both the images and the tools it provides, are widely used, very
> popular and extremely stable; TripleO, openstack-helm and kolla-ansible to
> name a few are all deployment methods that use Kolla.
> >
> > Kolla has two sub-projects, that both revolve around deployment methods;
> kolla-ansible and kolla-kubernetes. Kolla-ansible is proven, stable and
> used by many in the industry. Part of Kolla's quality is it's rock-solid
> dependability in many scenarios. As Kubernetes took over most of the COE
> world, it's only correct that the Kolla team created this sub-project; if
> swarm became suddenly very popular then we should create a kolla-swarm
> sub-project.
> >
> > So if we abandon kolla-kubernetes ('sunset' seems much more romantic
> admittedly) - we are abandoning the core Kolla team's efforts in this
> space. No matter how good openstack-helm is (and I've deployed it, know a
> lot of the cores and it's truly excellent and well driven), what happens
> down the line if openstack-helm decide to move on from Kolla - say
> focussing on Loci images or a new flavor that comes along? Then Kolla the
> core project, will no longer have any validation of it's docker
> images/containers running on Kubernetes. That to me is the big risk here.
> >
> > The key issue in my opinion is that the core Kolla team has focussed on
> kolla-ansible almost exclusively, and have not migrated to using
> kolla-kubernetes as well. As the code base has stagnated, the gates get
> intro trouble, and new features and configurations added to kolla-ansible
> are not translated to kolla-kubernetes.
> >
> > So I think the real question is not whether we should 'sunset'
> kolla-kubernetes the sub-project, but should we drop Kolla support on
> Kubernetes? Relying on a different team to do so is probably not the
> answer; although it's the one championed in this thread.
>
> +1
>
> >
> > In my opinion we should set some realistic goals before we sunset:
> >
> > 1. Pick a feature set for a Rocky v1.0 release, and commit to trying to
> get there. We have a long list of items, maybe pair this down to something
> reasonable.
>
> I am agree that we should have feature set for Rocky v1.0 release and
> AFAIK community already have that.
>
> > 2. Agreement within Kolla core team to learn kolla-kubernetes and start
> to put a percentage of time into this sub-project.
> > 3. Identify the people who are genuinely interested in working with it
> within the Kolla team.
>
> Though currently I am not the MVP in kolla-k8s but i would love to
> help with some concrete item for v1.0, IMHO before that we need a
> leader then identify volunteers.
> And for that if we need more thought on this
> https://review.openstack.org/#/c/552531
>
> I missed this and will review.

Thanks,

||Rich


> >
> > Without '2' I think sunsetting is the way forward, but the risks should
> be fully understood and hopefully I've made a case for what those are above.
> >
> > Thanks,
> >
> > ||Rich
> >
> >
> > On Wed, Mar 28, 2018 at 1:54 PM Chuck Short  wrote:
> >>
> >> +1
> >>
> >> Regards
> >> chuck
> >> On Wed, Mar 28, 2018 at 11:47 AM, Jeffrey Zhang <
> zhang.lei@gmail.com> wrote:
> >>>
> >>> There are two projects to solve the issue that run OpenStack on
> >>> Kubernetes, OpenStack-helm, and kolla-kubernetes. Them both
> >>> leverage helm tool for orchestration. There is some different
> perspective
> >>> at the beginning, which results in the two teams could not work
> together.
> >>>
> >>> But recently, the difference becomes too small. and there is also no
> active
> >>> contributor in the kolla-kubernetes project.
> >>>
> >>> So I propose to retire kolla-kubernetes project. If you are still
> >>> interested in running OpenStack on kubernetes, please refer to
> >>> openstack-helm project.
> >>>
> >>> --
> >>> 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:
> 

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

[Richard Wellum]

Hi Gema,

On Thu, Mar 29, 2018 at 2:48 PM Gema Gomez  wrote:

>
>
> On 29/03/18 18:26, Richard Wellum wrote:
> > Hi,
> >
> > So as a current Kolla-Kubernetes Core - I have a slightly different
> > opinion than most, I'll try to verbalize it coherently.
> >
> > Lets talk about what Kolla is:
> >
> > Kolla is a project that builds OpenStack docker images, stores them on
> > dockerhub, and provides tools to build your own images from your own
> > source. Both the images and the tools it provides, are widely used, very
> > popular and extremely stable; TripleO, openstack-helm and kolla-ansible
> > to name a few are all deployment methods that use Kolla.
> >
> > Kolla has two sub-projects, that both revolve around deployment methods;
> > kolla-ansible and kolla-kubernetes. Kolla-ansible is proven, stable and
> > used by many in the industry. Part of Kolla's quality is it's rock-solid
> > dependability in many scenarios. As Kubernetes took over most of the COE
> > world, it's only correct that the Kolla team created this sub-project;
> > if swarm became suddenly very popular then we should create a
> > kolla-swarm sub-project.
> >
> > So if we abandon kolla-kubernetes ('sunset' seems much more romantic
> > admittedly) - we are abandoning the core Kolla team's efforts in this
> > space. No matter how good openstack-helm is (and I've deployed it, know
> > a lot of the cores and it's truly excellent and well driven), what
> > happens down the line if openstack-helm decide to move on from Kolla -
> > say focussing on Loci images or a new flavor that comes along? Then
> > Kolla the core project, will no longer have any validation of it's
> > docker images/containers running on Kubernetes. That to me is the big
> > risk here.
> >
> > The key issue in my opinion is that the core Kolla team has focussed on
> > kolla-ansible almost exclusively, and have not migrated to using
> > kolla-kubernetes as well. As the code base has stagnated, the gates get
> > intro trouble, and new features and configurations added to
> > kolla-ansible are not translated to kolla-kubernetes.
> >
> > So I think the real question is not whether we should 'sunset'
> > kolla-kubernetes the sub-project, but should we drop Kolla support on
> > Kubernetes? Relying on a different team to do so is probably not the
> > answer; although it's the one championed in this thread.
> >
> > In my opinion we should set some realistic goals before we sunset:
> >
> > 1. Pick a feature set for a Rocky v1.0 release, and commit to trying to
> > get there. We have a long list of items, maybe pair this down to
> > something reasonable.
>
> Are you volunteering to drive this effort forward? I'd be happy to help
> define MVP for Rocky.
>

Yes I am.


>
> > 2. Agreement within Kolla core team to learn kolla-kubernetes and start
> > to put a percentage of time into this sub-project.
>
> Whilst this would be ideal, we cannot really force people that have no
> interest in this sub-project to contribute.
>

That's not what I was inferring, more trying to get a shift in attitude
within the Kolla team. For example, if I am working on kolla-kubernetes,
and make a change that breaks kolla-ansible - the Kolla community would
expect me to fix it of course? Same if I added a feature, and didn't apply
and test it with kolla-ansible then the same no? So I'm just saying that
the same should apply in the other direction; which it is currently not. As
a community we should support both deployment methods. Or if we don't then
we are all agreeing that Kolla will not have support on Kubernetes from the
core Kolla community.


>
> > 3. Identify the people who are genuinely interested in working with it
> > within the Kolla team.
>
> +1 if we find enough contributors to make the reasonable list of items
> happen during Rocky.
>
> > Without '2' I think sunsetting is the way forward, but the risks should
> > be fully understood and hopefully I've made a case for what those are
> above.
>
> How many contributors are necessary to make MVP?
>
We were doing fairly well with 4-5 contributors imo.

Thanks,

||Rich


>
> Cheers,
> Gema
>
> >
> > Thanks,
> >
> > ||Rich
> >
> >
> > On Wed, Mar 28, 2018 at 1:54 PM Chuck Short  > > wrote:
> >
> > +1
> >
> > Regards
> > chuck
> > On Wed, Mar 28, 2018 at 11:47 AM, Jeffrey Zhang
> > > wrote:
> >
> > There are two projects to solve the issue that run OpenStack on
> > Kubernetes, OpenStack-helm, and kolla-kubernetes. Them both
> > leverage helm tool for orchestration. There is some different
> > perspective
> > at the beginning, which results in the two teams could not work
> > together.
> >
> > But recently, the difference becomes too small. and there is
> > also no active
> > contributor in the kolla-kubernetes project.
> >
> > So I propose to 

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

[Surya Singh]

Dear All,

Thanks Rich for putting thoughts on continuation with kolla-k8s.


On Fri, Mar 30, 2018 at 2:26 AM, Richard Wellum  wrote:
>
> Hi,
>
> So as a current Kolla-Kubernetes Core - I have a slightly different opinion 
> than most, I'll try to verbalize it coherently.
>
> Lets talk about what Kolla is:
>
> Kolla is a project that builds OpenStack docker images, stores them on 
> dockerhub, and provides tools to build your own images from your own source. 
> Both the images and the tools it provides, are widely used, very popular and 
> extremely stable; TripleO, openstack-helm and kolla-ansible to name a few are 
> all deployment methods that use Kolla.
>
> Kolla has two sub-projects, that both revolve around deployment methods; 
> kolla-ansible and kolla-kubernetes. Kolla-ansible is proven, stable and used 
> by many in the industry. Part of Kolla's quality is it's rock-solid 
> dependability in many scenarios. As Kubernetes took over most of the COE 
> world, it's only correct that the Kolla team created this sub-project; if 
> swarm became suddenly very popular then we should create a kolla-swarm 
> sub-project.
>
> So if we abandon kolla-kubernetes ('sunset' seems much more romantic 
> admittedly) - we are abandoning the core Kolla team's efforts in this space. 
> No matter how good openstack-helm is (and I've deployed it, know a lot of the 
> cores and it's truly excellent and well driven), what happens down the line 
> if openstack-helm decide to move on from Kolla - say focussing on Loci images 
> or a new flavor that comes along? Then Kolla the core project, will no longer 
> have any validation of it's docker images/containers running on Kubernetes. 
> That to me is the big risk here.
>
> The key issue in my opinion is that the core Kolla team has focussed on 
> kolla-ansible almost exclusively, and have not migrated to using 
> kolla-kubernetes as well. As the code base has stagnated, the gates get intro 
> trouble, and new features and configurations added to kolla-ansible are not 
> translated to kolla-kubernetes.
>
> So I think the real question is not whether we should 'sunset' 
> kolla-kubernetes the sub-project, but should we drop Kolla support on 
> Kubernetes? Relying on a different team to do so is probably not the answer; 
> although it's the one championed in this thread.

+1

>
> In my opinion we should set some realistic goals before we sunset:
>
> 1. Pick a feature set for a Rocky v1.0 release, and commit to trying to get 
> there. We have a long list of items, maybe pair this down to something 
> reasonable.

I am agree that we should have feature set for Rocky v1.0 release and
AFAIK community already have that.

> 2. Agreement within Kolla core team to learn kolla-kubernetes and start to 
> put a percentage of time into this sub-project.
> 3. Identify the people who are genuinely interested in working with it within 
> the Kolla team.

Though currently I am not the MVP in kolla-k8s but i would love to
help with some concrete item for v1.0, IMHO before that we need a
leader then identify volunteers.
And for that if we need more thought on this
https://review.openstack.org/#/c/552531

>
> Without '2' I think sunsetting is the way forward, but the risks should be 
> fully understood and hopefully I've made a case for what those are above.
>
> Thanks,
>
> ||Rich
>
>
> On Wed, Mar 28, 2018 at 1:54 PM Chuck Short  wrote:
>>
>> +1
>>
>> Regards
>> chuck
>> On Wed, Mar 28, 2018 at 11:47 AM, Jeffrey Zhang  
>> wrote:
>>>
>>> There are two projects to solve the issue that run OpenStack on
>>> Kubernetes, OpenStack-helm, and kolla-kubernetes. Them both
>>> leverage helm tool for orchestration. There is some different perspective
>>> at the beginning, which results in the two teams could not work together.
>>>
>>> But recently, the difference becomes too small. and there is also no active
>>> contributor in the kolla-kubernetes project.
>>>
>>> So I propose to retire kolla-kubernetes project. If you are still
>>> interested in running OpenStack on kubernetes, please refer to
>>> openstack-helm project.
>>>
>>> --
>>> Regards,
>>> Jeffrey Zhang
>>> Blog: http://xcodest.me
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

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

[Gema Gomez]

On 29/03/18 18:26, Richard Wellum wrote:
> Hi,
> 
> So as a current Kolla-Kubernetes Core - I have a slightly different
> opinion than most, I'll try to verbalize it coherently.
> 
> Lets talk about what Kolla is:
> 
> Kolla is a project that builds OpenStack docker images, stores them on
> dockerhub, and provides tools to build your own images from your own
> source. Both the images and the tools it provides, are widely used, very
> popular and extremely stable; TripleO, openstack-helm and kolla-ansible
> to name a few are all deployment methods that use Kolla.
> 
> Kolla has two sub-projects, that both revolve around deployment methods;
> kolla-ansible and kolla-kubernetes. Kolla-ansible is proven, stable and
> used by many in the industry. Part of Kolla's quality is it's rock-solid
> dependability in many scenarios. As Kubernetes took over most of the COE
> world, it's only correct that the Kolla team created this sub-project;
> if swarm became suddenly very popular then we should create a
> kolla-swarm sub-project.
> 
> So if we abandon kolla-kubernetes ('sunset' seems much more romantic
> admittedly) - we are abandoning the core Kolla team's efforts in this
> space. No matter how good openstack-helm is (and I've deployed it, know
> a lot of the cores and it's truly excellent and well driven), what
> happens down the line if openstack-helm decide to move on from Kolla -
> say focussing on Loci images or a new flavor that comes along? Then
> Kolla the core project, will no longer have any validation of it's
> docker images/containers running on Kubernetes. That to me is the big
> risk here.
> 
> The key issue in my opinion is that the core Kolla team has focussed on
> kolla-ansible almost exclusively, and have not migrated to using
> kolla-kubernetes as well. As the code base has stagnated, the gates get
> intro trouble, and new features and configurations added to
> kolla-ansible are not translated to kolla-kubernetes.
> 
> So I think the real question is not whether we should 'sunset'
> kolla-kubernetes the sub-project, but should we drop Kolla support on
> Kubernetes? Relying on a different team to do so is probably not the
> answer; although it's the one championed in this thread.
> 
> In my opinion we should set some realistic goals before we sunset:
> 
> 1. Pick a feature set for a Rocky v1.0 release, and commit to trying to
> get there. We have a long list of items, maybe pair this down to
> something reasonable.

Are you volunteering to drive this effort forward? I'd be happy to help
define MVP for Rocky.

> 2. Agreement within Kolla core team to learn kolla-kubernetes and start
> to put a percentage of time into this sub-project.

Whilst this would be ideal, we cannot really force people that have no
interest in this sub-project to contribute.

> 3. Identify the people who are genuinely interested in working with it
> within the Kolla team.

+1 if we find enough contributors to make the reasonable list of items
happen during Rocky.

> Without '2' I think sunsetting is the way forward, but the risks should
> be fully understood and hopefully I've made a case for what those are above.

How many contributors are necessary to make MVP?

Cheers,
Gema

> 
> Thanks,
> 
> ||Rich
> 
> 
> On Wed, Mar 28, 2018 at 1:54 PM Chuck Short  > wrote:
> 
> +1
> 
> Regards
> chuck
> On Wed, Mar 28, 2018 at 11:47 AM, Jeffrey Zhang
> > wrote:
> 
> There are two projects to solve the issue that run OpenStack on 
> Kubernetes, OpenStack-helm, and kolla-kubernetes. Them both
> leverage helm tool for orchestration. There is some different
> perspective
> at the beginning, which results in the two teams could not work
> together. 
> 
> But recently, the difference becomes too small. and there is
> also no active
> contributor in the kolla-kubernetes project. 
> 
> So I propose to retire kolla-kubernetes project. If you are still
> interested in running OpenStack on kubernetes, please refer to 
> openstack-helm project.
> 
> -- 
> 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
> 

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

[Richard Wellum]

Hi,

So as a current Kolla-Kubernetes Core - I have a slightly different opinion
than most, I'll try to verbalize it coherently.

Lets talk about what Kolla is:

Kolla is a project that builds OpenStack docker images, stores them on
dockerhub, and provides tools to build your own images from your own
source. Both the images and the tools it provides, are widely used, very
popular and extremely stable; TripleO, openstack-helm and kolla-ansible to
name a few are all deployment methods that use Kolla.

Kolla has two sub-projects, that both revolve around deployment methods;
kolla-ansible and kolla-kubernetes. Kolla-ansible is proven, stable and
used by many in the industry. Part of Kolla's quality is it's rock-solid
dependability in many scenarios. As Kubernetes took over most of the COE
world, it's only correct that the Kolla team created this sub-project; if
swarm became suddenly very popular then we should create a kolla-swarm
sub-project.

So if we abandon kolla-kubernetes ('sunset' seems much more romantic
admittedly) - we are abandoning the core Kolla team's efforts in this
space. No matter how good openstack-helm is (and I've deployed it, know a
lot of the cores and it's truly excellent and well driven), what happens
down the line if openstack-helm decide to move on from Kolla - say
focussing on Loci images or a new flavor that comes along? Then Kolla the
core project, will no longer have any validation of it's docker
images/containers running on Kubernetes. That to me is the big risk here.

The key issue in my opinion is that the core Kolla team has focussed on
kolla-ansible almost exclusively, and have not migrated to using
kolla-kubernetes as well. As the code base has stagnated, the gates get
intro trouble, and new features and configurations added to kolla-ansible
are not translated to kolla-kubernetes.

So I think the real question is not whether we should 'sunset'
kolla-kubernetes the sub-project, but should we drop Kolla support on
Kubernetes? Relying on a different team to do so is probably not the
answer; although it's the one championed in this thread.

In my opinion we should set some realistic goals before we sunset:

1. Pick a feature set for a Rocky v1.0 release, and commit to trying to get
there. We have a long list of items, maybe pair this down to something
reasonable.
2. Agreement within Kolla core team to learn kolla-kubernetes and start to
put a percentage of time into this sub-project.
3. Identify the people who are genuinely interested in working with it
within the Kolla team.

Without '2' I think sunsetting is the way forward, but the risks should be
fully understood and hopefully I've made a case for what those are above.

Thanks,

||Rich


On Wed, Mar 28, 2018 at 1:54 PM Chuck Short  wrote:

> +1
>
> Regards
> chuck
> On Wed, Mar 28, 2018 at 11:47 AM, Jeffrey Zhang 
> wrote:
>
>> There are two projects to solve the issue that run OpenStack on
>> Kubernetes, OpenStack-helm, and kolla-kubernetes. Them both
>> leverage helm tool for orchestration. There is some different perspective
>> at the beginning, which results in the two teams could not work together.
>>
>> But recently, the difference becomes too small. and there is also no
>> active
>> contributor in the kolla-kubernetes project.
>>
>> So I propose to retire kolla-kubernetes project. If you are still
>> interested in running OpenStack on kubernetes, please refer to
>> openstack-helm project.
>>
>> --
>> Regards,
>> Jeffrey Zhang
>> Blog: http://xcodest.me
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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-kubernete][tc][openstack-helm]propose retire kolla-kubernetes project

[Chuck Short]

+1

Regards
chuck

On Wed, Mar 28, 2018 at 11:47 AM, Jeffrey Zhang 
wrote:

> There are two projects to solve the issue that run OpenStack on
> Kubernetes, OpenStack-helm, and kolla-kubernetes. Them both
> leverage helm tool for orchestration. There is some different perspective
> at the beginning, which results in the two teams could not work together.
>
> But recently, the difference becomes too small. and there is also no active
> contributor in the kolla-kubernetes project.
>
> So I propose to retire kolla-kubernetes project. If you are still
> interested in running OpenStack on kubernetes, please refer to
> openstack-helm project.
>
> --
> 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][kolla-kubernete][tc][openstack-helm]propose retire kolla-kubernetes project

[MCEUEN, MATT]

The OpenStack-Helm team would eagerly welcome contributions from 
Kolla-Kubernetes team members!  Several of the current OSH team come from a 
Kolla-Kubernetes background, and the project has benefitted greatly from their 
experience and domain knowledge.

Please reach out to me or say hi in #openstack-helm if you'd like to get looped 
in.
Thanks,
Matt

-Original Message-
From: Paul Bourke [mailto:paul.bou...@oracle.com] 
Sent: Wednesday, March 28, 2018 11:17 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] 
[kolla][kolla-kubernete][tc][openstack-helm]propose retire kolla-kubernetes 
project

+1

Thanks Jeffrey for taking the time to investigate.

On 28/03/18 16:47, Jeffrey Zhang wrote:
> There are two projects to solve the issue that run OpenStack on
> Kubernetes, OpenStack-helm, and kolla-kubernetes. Them both
> leverage helm tool for orchestration. There is some different perspective
> at the beginning, which results in the two teams could not work together.
> 
> But recently, the difference becomes too small. and there is also no active
> contributor in the kolla-kubernetes project.
> 
> So I propose to retire kolla-kubernetes project. If you are still
> interested in running OpenStack on kubernetes, please refer to
> openstack-helm project.
> 
> -- 
> Regards,
> Jeffrey Zhang
> Blog: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__xcodest.me=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=_C5hC_103uW491yNPPpNmA=aRg_FabM3_QiSWpeuGcuJXSLceTM0KGMLJgHyDOfrAo=hQmYlooBLjpF5tBAsthjxDFNn1zNssgnvtW-smJ7MYk=
>   
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__xcodest.me_=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=_C5hC_103uW491yNPPpNmA=aRg_FabM3_QiSWpeuGcuJXSLceTM0KGMLJgHyDOfrAo=7Vt9-yWUIKGUXCEAsyBJPfJAa72zKCfZme2yL0ImwoE=
>  >
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=_C5hC_103uW491yNPPpNmA=aRg_FabM3_QiSWpeuGcuJXSLceTM0KGMLJgHyDOfrAo=UQmPU1ND-ti1FNE8yfZx9qDP_I4gwW-jC2EOybg58mA=
>  
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=LFYZ-o9_HUMeMTSQicvjIg=_C5hC_103uW491yNPPpNmA=aRg_FabM3_QiSWpeuGcuJXSLceTM0KGMLJgHyDOfrAo=UQmPU1ND-ti1FNE8yfZx9qDP_I4gwW-jC2EOybg58mA=
 
__
OpenStack Development Mailing 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-kubernete][tc][openstack-helm]propose retire kolla-kubernetes project

[楊睿豪]

+1 
To consolidate them


> Paul Bourke  於 2018年3月29日 上午12:16 寫道：
> 
> +1
> 
> Thanks Jeffrey for taking the time to investigate.
> 
>> On 28/03/18 16:47, Jeffrey Zhang wrote:
>> There are two projects to solve the issue that run OpenStack on
>> Kubernetes, OpenStack-helm, and kolla-kubernetes. Them both
>> leverage helm tool for orchestration. There is some different perspective
>> at the beginning, which results in the two teams could not work together.
>> But recently, the difference becomes too small. and there is also no active
>> contributor in the kolla-kubernetes project.
>> So I propose to retire kolla-kubernetes project. If you are still
>> interested in running OpenStack on kubernetes, please refer to
>> openstack-helm project.
>> -- 
>> Regards,
>> Jeffrey Zhang
>> Blog: http://xcodest.me 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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-kubernete][tc][openstack-helm]propose retire kolla-kubernetes project

[Paul Bourke]

+1

Thanks Jeffrey for taking the time to investigate.

On 28/03/18 16:47, Jeffrey Zhang wrote:

There are two projects to solve the issue that run OpenStack on
Kubernetes, OpenStack-helm, and kolla-kubernetes. Them both
leverage helm tool for orchestration. There is some different perspective
at the beginning, which results in the two teams could not work together.

But recently, the difference becomes too small. and there is also no active
contributor in the kolla-kubernetes project.

So I propose to retire kolla-kubernetes project. If you are still
interested in running OpenStack on kubernetes, please refer to
openstack-helm project.

--
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][kolla-kubernete][tc][openstack-helm]propose retire kolla-kubernetes project

[Davanum Srinivas]

+1 to consolidate.

Thanks,
Dims

On Wed, Mar 28, 2018 at 11:47 AM, Jeffrey Zhang  wrote:
> There are two projects to solve the issue that run OpenStack on
> Kubernetes, OpenStack-helm, and kolla-kubernetes. Them both
> leverage helm tool for orchestration. There is some different perspective
> at the beginning, which results in the two teams could not work together.
>
> But recently, the difference becomes too small. and there is also no active
> contributor in the kolla-kubernetes project.
>
> So I propose to retire kolla-kubernetes project. If you are still
> interested in running OpenStack on kubernetes, please refer to
> openstack-helm project.
>
> --
> 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
>



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

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

[openstack-dev] [kolla][kolla-kubernete][tc][openstack-helm]propose retire kolla-kubernetes project

[Jeffrey Zhang]

There are two projects to solve the issue that run OpenStack on
Kubernetes, OpenStack-helm, and kolla-kubernetes. Them both
leverage helm tool for orchestration. There is some different perspective
at the beginning, which results in the two teams could not work together.

But recently, the difference becomes too small. and there is also no active
contributor in the kolla-kubernetes project.

So I propose to retire kolla-kubernetes project. If you are still
interested in running OpenStack on kubernetes, please refer to
openstack-helm project.

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