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

[Brandon Jozsa]

On April 4, 2018 at 4:21:58 PM, Michał Jastrzębski 
(inc...@gmail.com) wrote:

On 4 April 2018 at 14:45, Brandon Jozsa  wrote:
> I’ve been a part of the OpenStack-Helm project from the very beginning, and
> there was a lot of early brainstorming on how we could collaborate and
> contribute directly to Kolla-Kubernetes. In fact, this was the original
> intent when we met with Kolla back in Barcelona. We didn’t like the idea of
> fragmenting interested Kubernetes developers/operators in the
> OpenStack-via-Kubernetes space. Whatever the project, we wanted all the
> domain expertise concentrated on a single deployment effort. Even though
> OSH/K-k8s couldn’t reach an agreement on how to handle configmaps (our
> biggest difference from the start), there was a lot of early collaboration
> between the project cores. Early K-k8s contributors may remember Halcyon,
> which cores from both sides promoted for early development of
> OpenStack-via-Kubernetes, regardless of the project.
>
> One of the requests from the initial OSH team (in Barcelona) was to formally
> separate Kolla from Kolla-foo deployment projects, both at a project level
> and from a core perspective. Why have the same cores giving +2’s to Kolla,
> Kolla-Ansible, Kolla-Mesos (now dead) and Kolla-Kubernetes, who may not have
> any interest in another given discipline? We wanted reviews to be timely,
> and laser-focused, and we felt that this more atomic approach would benefit
> Kolla in the end. But unfortunately there was heavy resistance with limited
> yet very influential cores. I honestly think pushback was also because it
> would mean that any Kolla sub-projects would be subject to re-acceptance as
> big tent projects.

Limited, but very influential cores sounds like bad community, and as
it happens I was leading this community at that time, so I feel I
should comment. We would love to increase number of cores (raise a
limit) of images, but that comes with a cost. Cost being that person
who would like to become a core would need to contribute to project in
question and review other people contributions. Proper way to address
this problem would be just that - contributing to Kolla and reviewing
code. If I failed to notice contributions from someone who did that a
lot (I hope I didn't), I'm sorry. This is best and only way to solve
problem in question.


I think you did the best you could, Michal. As I understand it there are 
essentially three active projects under Kolla today; Kolla, Kolla-Ansible, 
Kolla-Kubernetes (and others that have been abandoned or dead), and only Kolla 
shows up under the project navigator. I assume this means they are all still 
under one project umbrella? I think this is a bit of a stretch for a 
single-project core team, especially since there are fundamental differences 
between Ansible and Kubernetes.

So my comment was far less about you or anyone personally as a PTL or core, but 
really more about the “laser-focused” discipline of the group as a whole. Kolla 
is the only project I am aware of that has this catch all mission allowing it 
to be any type of deployment that consumes Kolla as a base, and it leverages 
the same resources. In fact, any other container-based OpenStack projects have 
been met with a bit of a strange resistance. See: 
https://review.openstack.org/#/c/449224/


>
> There were also countless discussions about the preservation of the Kolla
> API, or Ansible + Jinja portions of Kolla-Ansible. It became clear to us
> that Kubernetes wasn’t going to be the first class citizen for the
> deployment model in Kolla-Kubernetes, forcing operators to troubleshoot
> between OpenStack, Kolla (container builds), Ansible, Kubernetes, and Helm.
> This is apparent still today. And while I understand the hesitation to
> change Kolla/Kolla-Ansible, I think this code-debt has somewhat contributed
> to sustainability of Kolla-Kubernetes. Somewhat to the point of tension, I
> very much agree with Thierry’s comments earlier.

How k8s wasn't first class citizen? I don't understand. All processes
were the same, time in PTG was generous compared to ansible etc. More
people uses Ansible due to it's maturity so it's obvious it's going to
have better testing etc, but again, solved by contributions.

I’m not talking about at a project level. I think Kolla has done a wonderful 
job in that respect. All of my comments above are about the mixed-use of 
technologies leveraged to drive the project. Compare how Kubernetes configmaps 
are generated for each of the projects. Then ask yourself what drove that 
design? Was it simplicity or adherence to previous debt/models?

Technical details like these need to be called out (good/bad/indifferent), and 
planned for accordingly in the event that the projects do merge at some point. 
I think this is the most confusing part for new users, because both communities 
have been asked countless times “what are the differences between x and 

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

[Michał Jastrzębski]

On 4 April 2018 at 14:45, Brandon Jozsa  wrote:
> I’ve been a part of the OpenStack-Helm project from the very beginning, and
> there was a lot of early brainstorming on how we could collaborate and
> contribute directly to Kolla-Kubernetes. In fact, this was the original
> intent when we met with Kolla back in Barcelona. We didn’t like the idea of
> fragmenting interested Kubernetes developers/operators in the
> OpenStack-via-Kubernetes space. Whatever the project, we wanted all the
> domain expertise concentrated on a single deployment effort. Even though
> OSH/K-k8s couldn’t reach an agreement on how to handle configmaps (our
> biggest difference from the start), there was a lot of early collaboration
> between the project cores. Early K-k8s contributors may remember Halcyon,
> which cores from both sides promoted for early development of
> OpenStack-via-Kubernetes, regardless of the project.
>
> One of the requests from the initial OSH team (in Barcelona) was to formally
> separate Kolla from Kolla-foo deployment projects, both at a project level
> and from a core perspective. Why have the same cores giving +2’s to Kolla,
> Kolla-Ansible, Kolla-Mesos (now dead) and Kolla-Kubernetes, who may not have
> any interest in another given discipline? We wanted reviews to be timely,
> and laser-focused, and we felt that this more atomic approach would benefit
> Kolla in the end. But unfortunately there was heavy resistance with limited
> yet very influential cores. I honestly think pushback was also because it
> would mean that any Kolla sub-projects would be subject to re-acceptance as
> big tent projects.

Limited, but very influential cores sounds like bad community, and as
it happens I was leading this community at that time, so I feel I
should comment. We would love to increase number of cores (raise a
limit) of images, but that comes with a cost. Cost being that person
who would like to become a core would need to contribute to project in
question and review other people contributions. Proper way to address
this problem would be just that - contributing to Kolla and reviewing
code. If I failed to notice contributions from someone who did that a
lot (I hope I didn't), I'm sorry. This is best and only way to solve
problem in question.

>
> There were also countless discussions about the preservation of the Kolla
> API, or Ansible + Jinja portions of Kolla-Ansible. It became clear to us
> that Kubernetes wasn’t going to be the first class citizen for the
> deployment model in Kolla-Kubernetes, forcing operators to troubleshoot
> between OpenStack, Kolla (container builds), Ansible, Kubernetes, and Helm.
> This is apparent still today. And while I understand the hesitation to
> change Kolla/Kolla-Ansible, I think this code-debt has somewhat contributed
> to sustainability of Kolla-Kubernetes. Somewhat to the point of tension, I
> very much agree with Thierry’s comments earlier.

How k8s wasn't first class citizen? I don't understand. All processes
were the same, time in PTG was generous compared to ansible etc. More
people uses Ansible due to it's maturity so it's obvious it's going to
have better testing etc, but again, solved by contributions.

> I want all of these projects to succeed but consolidation with purposeful
> and deliberate planning, which Rich has so kindly agreed to do, could be the
> right answer. So I +1 the idea, because I think it puts all like-minded
> individuals on the same focus (for the overall benefit of OpenStack and the
> overall OpenStack community). But we have to make sure there isn’t a lot of
> fallout from the decision either. To Steve Dake's previous point, there
> could be orphaned users/operators who feel “forced” into another project. I
> would hate to see that. It would be nice to at least plan this with the
> user-base and give them fair warning. And to this point, what is the active
> specific Kolla-Kubernetes core? Who is “PTL” of Kolla-Kubernetes today?

As per election results it's Jeffrey.

> On the other hand, I think that OSH has some improvements to make as well.
> Gating could use some help and the OpenStack-Infra team has been kindly
> helping out recently (a huge "thank you" to them). Docs…I think docs could
> always use some love. Please offer your experiences to the OSH team! We
> would love to hear your user input. Ultimately, if users/operators want to
> run something that even closely resembles production, then we need some
> decent production quality docs as opposed to leveraging the nascent gate
> scripts (Zuulv3 ansible+heat). Releases and release planning should be
> addressed, as users/vendors are going to want to be closer to OpenStack
> release dates (recent versions of OpenStack, Helm and Kubernetes). Clear and
> open roadmaps, with potential use of community-led planning tools. Open
> elections for PTL. Finally, the OSH team may still be be interested in
> diversifying it’s core-base. Matt M. would have to address this. I know 

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

[Brandon Jozsa]

I’ve been a part of the OpenStack-Helm project from the very beginning, and 
there was a lot of early brainstorming on how we could collaborate and 
contribute directly to Kolla-Kubernetes. In fact, this was the original intent 
when we met with Kolla back in Barcelona. We didn’t like the idea of 
fragmenting interested Kubernetes developers/operators in the 
OpenStack-via-Kubernetes space. Whatever the project, we wanted all the domain 
expertise concentrated on a single deployment effort. Even though OSH/K-k8s 
couldn’t reach an agreement on how to handle configmaps (our biggest difference 
from the start), there was a lot of early collaboration between the project 
cores. Early K-k8s contributors may remember Halcyon, which cores from both 
sides promoted for early development of OpenStack-via-Kubernetes, regardless of 
the project.

One of the requests from the initial OSH team (in Barcelona) was to formally 
separate Kolla from Kolla-foo deployment projects, both at a project level and 
from a core perspective. Why have the same cores giving +2’s to Kolla, 
Kolla-Ansible, Kolla-Mesos (now dead) and Kolla-Kubernetes, who may not have 
any interest in another given discipline? We wanted reviews to be timely, and 
laser-focused, and we felt that this more atomic approach would benefit Kolla 
in the end. But unfortunately there was heavy resistance with limited yet very 
influential cores. I honestly think pushback was also because it would mean 
that any Kolla sub-projects would be subject to re-acceptance as big tent 
projects.

There were also countless discussions about the preservation of the Kolla API, 
or Ansible + Jinja portions of Kolla-Ansible. It became clear to us that 
Kubernetes wasn’t going to be the first class citizen for the deployment model 
in Kolla-Kubernetes, forcing operators to troubleshoot between OpenStack, Kolla 
(container builds), Ansible, Kubernetes, and Helm. This is apparent still 
today. And while I understand the hesitation to change Kolla/Kolla-Ansible, I 
think this code-debt has somewhat contributed to sustainability of 
Kolla-Kubernetes. Somewhat to the point of tension, I very much agree with 
Thierry’s comments earlier.

I want all of these projects to succeed but consolidation with purposeful and 
deliberate planning, which Rich has so kindly agreed to do, could be the right 
answer. So I +1 the idea, because I think it puts all like-minded individuals 
on the same focus (for the overall benefit of OpenStack and the overall 
OpenStack community). But we have to make sure there isn’t a lot of fallout 
from the decision either. To Steve Dake's previous point, there could be 
orphaned users/operators who feel “forced” into another project. I would hate 
to see that. It would be nice to at least plan this with the user-base and give 
them fair warning. And to this point, what is the active specific 
Kolla-Kubernetes core? Who is “PTL” of Kolla-Kubernetes today?

On the other hand, I think that OSH has some improvements to make as well. 
Gating could use some help and the OpenStack-Infra team has been kindly helping 
out recently (a huge "thank you" to them). Docs…I think docs could always use 
some love. Please offer your experiences to the OSH team! We would love to hear 
your user input. Ultimately, if users/operators want to run something that even 
closely resembles production, then we need some decent production quality docs 
as opposed to leveraging the nascent gate scripts (Zuulv3 ansible+heat). 
Releases and release planning should be addressed, as users/vendors are going 
to want to be closer to OpenStack release dates (recent versions of OpenStack, 
Helm and Kubernetes). Clear and open roadmaps, with potential use of 
community-led planning tools. Open elections for PTL. Finally, the OSH team may 
still be be interested in diversifying it’s core-base. Matt M. would have to 
address this. I know that I was actively seeking cores when I was initially 
PTL, and truthfully…there’s nobody nicer or easier to work with than Matt. He’s 
an awesome PTL, and any project would be fortunate to have him. All these 
things could all be improved on, but it requires a diverse base with a lot of 
great ideas.

That said, I am in favor of consolidation…if it makes sense and if there's a 
strong argument for it. We just need to think what’s best for the OpenStack 
community as a whole, and put away the positions of the individual projects for 
a moment. To me, that makes things pretty clear, regardless of where the 
commits are going. And with the +1’s, I think we’re hearing you. Now we just 
have to plan it out and take action (on both sides).

Brandon



On April 2, 2018 at 11:14:01 AM, Martin André 
(m.an...@redhat.com) wrote:

On Mon, Apr 2, 2018 at 4:38 PM, Steven Dake (stdake)  wrote:
>
>
>
> On April 2, 2018 at 6:00:15 AM, Martin André (m.an...@redhat.com) wrote:
>
> On Sun, Apr 1, 2018 at 12:07 AM, Steven Dake (stdake) 

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

[Martin André]

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

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

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

One could argue that the environment variables we pass to the
containers to control what extend_start.sh does are also part of the
API. That's not my point. There is a lot of cruft in these scripts
that remain from the days where kolla-ansible was the only consumer of
kolla images.

> I don't think I said anywhere the API is perfectly implemented.  I'm not
> sure I've ever seen this mythical perfection thing in an API anyway :)
>
> Patches are welcome to improve the API to make it more general, as 

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

[Steven Dake (stdake)]

On April 2, 2018 at 6:00:15 AM, Martin André 
(m.an...@redhat.com) wrote:

On Sun, Apr 1, 2018 at 12:07 AM, Steven Dake (stdake)  wrote:
> My viewpoint is as all deployments projects are already on an equal footing
> when using Kolla containers.

While I acknowledge Kolla reviewers are doing a very good job at
treating all incoming reviews equally, we can't realistically state
these projects stand on an equal footing today.

At the very least we need to have kolla changes _gating_ on TripleO
and OSH jobs before we can say so. Of course, I'm not saying other
kolla devs are opposed to adding more CI jobs to kolla, I'm pretty
sure they would welcome the changes if someone volunteers for it, but
right now when I'm approving a kolla patches I can only say with
confidence that it does not break kolla-ansible. In that sense,
kolla_ansible is special.

Martin,

Personally I think all of OpenStack projects that have a dependency or inverse 
dependency should cross-gate.  For example, Nova should gate on kolla-ansible, 
and at one point I think they agreed to this, if we submitted gate work to do 
so.  We never did that.

Nobody from TripleO or OSH has submitted gates for Kolla.  Submit them and they 
will follow the standard mechanism used in OpenStack 
experimental->non-voting->voting (if people are on-call to resolve problems).  
I don't think gating is relevant to equal footing.  TripleO for the moment has 
chosen to gate on their own image builds, which is fine.  If the gating should 
be enhanced, write the gates :)

Here is a simple definition from the internet:

"with the same 
rights and 
conditions
 as someone you are 
competing 
with"

Does that mean if you want to split the kolla repo into 40+ repos for each 
separate project, the core team will do that?  No.  Does that mean if there is 
a reasonable addition to the API the patch would merge?  Yes.

Thats right, deployment tools compete, but they also cooperate and collaborate. 
 The containers (atleast from my perspective) are an area where Kolla has 
chosen to collaborate.  FWIW I also think we have chosen to collobrate a bit in 
areas we compete (the deployment tooling itself).  Its a very complex topic.  
Splitting the governance and PTLs doesn't change the makeup of the core review 
team who ultimately makes the decision about what is reasonable.

|

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

The Kolla API is stable and incredibly useful... it's also
undocumented. I have a stub for a documentation change that's been
collecting dust on my hard drive for month, maybe it's time I brush it

Most of Kolla unfortunately is undocumented.  The API is simple and 
straightforward enough that TripleO, OSH, and several proprietary vendors (the 
ones Jeffrey mentioned) have managed to implement deployment tooling that 
consume the API.  Documentation for any part of Kolla would be highly valued - 
IMO it is the Kolla project's biggest weakness.

up and finally submit it. Today unless you're a kolla developer
yourself, it's difficult to understand how to use the API, not the
most user friendly.

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

I don't disagree.  I was never fond of extend_start, and thought any special 
operations it provided belong in the API itself.  This is why there are mkdir 
operations and chmod/chown -R operations in the API.  The JSON blob handed to 
the API during runtime is where the API begins and ends.  The implementation 
(what set_cfg.py does with start.sh and extend_start.sh) are not part of the 
API but part of the API implementation.

I don't think I said anywhere the API is perfectly implemented.  I'm not sure 
I've ever seen this mythical perfection thing in an API anyway :)

Patches are welcome to improve the API to make it more general, as long as they 
maintain backward compatibility.


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


We knew people would find creative ways to use the plugin templating 
technology, and help drive adoption of Kolla as a standard...

Kolla is a great framework for building container images for OpenStack
services any project can consume. We could do a better job at
advertising it. I guess bringing 

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

[Martin André]

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

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

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

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

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

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

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

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

Martin

> I haven't kept up with OSH development, but perhaps that team could provide
> their viewpoint as well.
>
>
> Cheers
>
> -steve
>
>
> --
> Jeremy Stanley
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[Jeffrey Zhang]

Thanks to all guys.

The mail is a little off-topic. First of all, let us back to the topic of
this
mail.


**kolla-kubernetes**

The root issue for kolla-kubernetes is no active contributors. if more
person
is interested in this project, I would like to give more time to this
project.
But leave it in kolla governance may not good for its growth. Because it is
a
**totally different** technical stack with kolla-ansible. so migrate it to
TC
governance should the best solution.


**for kolla and kolla-ansible split**

kolla(container) is widely used by multi-project (TripleO, OSH). And I also
heard some internal projects are using it too. kolla and kolla-ansible are
well
decoupled. The usage or the API kolla provides always stable and backward
compatible. kolla images are also used in many produce environment through
different deployment tools So kolla(container) is worth say "provide
production-ready containers".  This should not be negative, just because of
kolla and kolla-ansible are under the same team governance.

the team split would let people fouse on one thing and make it looks better.
but we have two different teams, kolla-core team, and the
kolla-ansible-core team
already. anyone is welcome to join one of the team.  But in fact, the
members
of these two teams are almost the same.  if we split the team now, all we
gain
is making chaos and hard to manage.

I think it may be proper time when the members of kolla-core team and
the kolla-ansible-core team is different (50% maybe?).
​


On Sun, Apr 1, 2018 at 7:16 AM, Jeremy Stanley  wrote:

> On 2018-03-31 22:07:03 + (+), Steven Dake (stdake) wrote:
> [...]
> > The problems raised in this thread (tension - tight coupling -
> > second class citizens - stratification) was predicted early on -
> > prior to Kolla 1.0.  That prediction led to the creation of a
> > technical solution - the Kolla API.   This API permits anyone to
> > reuse the containers as they see fit if they conform their
> > implementation to the API.  The API is not specifically tied to
> > the Ansible deployment technology.  Instead the API is tied to the
> > varying requirements that various deployment teams have had in the
> > past around generalized requirements for making container
> > lifecycle management a reality while running OpenStack services
> > and their dependencies inside containers.
> [...]
>
> Thanks! That's where my fuzzy thought process was leading. Existence
> of a stable API guarantee rather than treating the API as "whatever
> kolla-ansible does" significantly increases the chances of other
> projects being able to rely on kolla's images in the long term.
> --
> 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
>
>


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

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

[Jeremy Stanley]

On 2018-03-31 22:07:03 + (+), Steven Dake (stdake) wrote:
[...]
> The problems raised in this thread (tension - tight coupling -
> second class citizens - stratification) was predicted early on -
> prior to Kolla 1.0.  That prediction led to the creation of a
> technical solution - the Kolla API.   This API permits anyone to
> reuse the containers as they see fit if they conform their
> implementation to the API.  The API is not specifically tied to
> the Ansible deployment technology.  Instead the API is tied to the
> varying requirements that various deployment teams have had in the
> past around generalized requirements for making container
> lifecycle management a reality while running OpenStack services
> and their dependencies inside containers.
[...]

Thanks! That's where my fuzzy thought process was leading. Existence
of a stable API guarantee rather than treating the API as "whatever
kolla-ansible does" significantly increases the chances of other
projects being able to rely on kolla's images in the long term.
-- 
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][tc][openstack-helm][tripleo]propose retire kolla-kubernetes project

[Steven Dake (stdake)]

On March 31, 2018 at 12:35:31 PM, Jeremy Stanley 
(fu...@yuggoth.org) wrote:

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

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


The problems raised in this thread (tension - tight coupling - second class 
citizens - stratification) was predicted early on - prior to Kolla 1.0.  That 
prediction led to the creation of a technical solution - the Kolla API.   This 
API permits anyone to reuse the containers as they see fit if they conform 
their implementation to the API.  The API is not specifically tied to the 
Ansible deployment technology.  Instead the API is tied to the varying 
requirements that various deployment teams have had in the past around 
generalized requirements for making container lifecycle management a reality 
while running OpenStack services and their dependencies inside containers.

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

My viewpoint is as all deployments projects are already on an equal footing 
when using Kolla containers.

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

I haven't kept up with OSH development, but perhaps that team could provide 
their viewpoint as well.


Cheers

-steve


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