+1 to one more pass at using the same images. Doing so will become
practically impossible in a matter of weeks or months, and in the long
term the additional shared human resources outweigh the interpersonal
complexities (and for any who don't think so - maybe you're wasting your
time here?).
Logically, I just view Kolla's existing containers as a thin wrapper
around OpenStack projects' debs and rpms (though I understand there are
many differences from a purely technical standpoint, and that the
containers can be built entirely from source instead). I suppose I view
them this way because building the existing containers creates
deployable artifacts (that is, the images) and these images have a lot
of the same qualities as traditional deb/rpm packages. The resulting
artifacts in both cases are somewhat immutable, they both put programs
in certain places, both expect configs in certain places, both configure
logs to be written in certain places, etc. In fact a lot of these
locations in the container's case are dictated by where they are
expected in the packages. Sharing the images could further standardize
things.
This is different IMHO than deployment tooling in the usual
configuration management sense, which I presume is one of the reasons
for this possible Kolla repo-split to begin with. I certainly see the
upsides to having a diverse set of tooling to deploy project artifacts
(deb/rpm/container image/git commit [i.e. from source]), but I don't get
duplicating the artifacts themselves over relatively simple
technicalities. I highly doubt anyone would create a major packaging
variation in the deb/rpm packaging (perhaps where all OpenStack projects
are deployable from a single rpm or deb [wouldn't that be fun!], or
perhaps a switch to FPM) merely because it made sense for a new
deployment project. (to be clear though, I am in general happy to have
more deployment options coming online)
Thank you,
Mark
On 7/28/2016 8:56 AM, Fox, Kevin M wrote:
I really see 3 issues raised in the spec mentioned that have any
disagreement as far as I can tell.
1. mirantis would like to see kolla-ansible split from the base kolla
repo. This has a lot of support and is likely to come up for a final
vote soon. It was postponed due to not wanting to split in the middle
of a cycle. - This does not seem like a good reason at this point to
spawn a new project. I support the split.
2. mirantis would like to see repos split for each docker container
definition to be one per container. This is purely a management style
difference. Split or combined both has advantages, and at present
scaling issues have not been hit, so change has a cost that doesn't
yet have a significant benefit. If it started to be, I'm sure it would
be re-evaluated. This does not seem like a good reason at this point
to spawn a new project. I think splitting seems unnecessary at this
point, but if the whole thing comes down to this one issue, I'd
support splitting the repos just so we don't duplicate so much work
over such a minor thing.
3. Some bootstrap logic in some of the containers. mirantis would like
to see it gone. Its completely optional (just don't set the BOOTSTRAP
env vars) and needs to stay for api backwards compatibility in
existing containers. It does not have to be used by deployment tools
that don't wish to use it. This does not seem like a good reason at
this point to spawn a new project. I support keeping it to not break
things as its optional.
Are these really that contentious that we have to split a community
over? Can we get both sides to give in a little and help each other out?
Maybe something like:
1. kolla commits to split out kolla-ansible as soon as possible (right
after newton tagged)
2. Some middle ground here. Maybe its keep as is, but come up with a
formal procedure for re-evaluating when it becomes painful and make a
change. (Seems similar to the fuel/puppet repo upstreaming thing, in a
way. Maybe some of the same process could work here? Some time to
review metrics?)
3. We keep the optional stuff so we don't break existing deployments.
Is this reasonable?
Thanks,
Kevin
------------------------------------------------------------------------
*From:* Vladimir Kozhukalov [vkozhuka...@mirantis.com]
*Sent:* Thursday, July 28, 2016 5:48 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis
is getting Fuel CCP (docker/k8s) kicked off
>1. Alter the mission statement of fuel to match the reality being
>published by the press and Mirantis's executive team
>2. Include these non-experimental repos in the projects.yaml governance
>Repository
Frankly, I don’t understand what part of the press release contradicts
with Fuel mission.
Current Fuel mission is “To streamline and accelerate the process of
deploying, testing and maintaining various configurations of OpenStack
at scale.” which means we are not bound to any specific technology
when deploying OpenStack.
At the moment Fuel deploys RPM/DEB packages using Puppet and Fuel
specific orchestration mechanism. We are not going to drop this
approach immediately, it works quite well and we are working hard to
make things better (including ability to upgrade). But we also keep in
mind that technologies are constantly changing and we’d like to
benefit of this progress. That is why we are now looking at Docker
containers and Kubernetes. Our users know that it is not our first
experience of trying to use containers. Fuel releases prior to 9.0
used to deploy Fuel services in containers on the Fuel admin node.
Many of you know how difficult it is to upgrade OpenStack clusters. We
hope that containers could help us to solve not all but some of
problems that we encounter when upgrading cluster. Maintaining and
hence upgrade of OpenStack clusters is a part of Fuel mission and we
are just trying to find a way how to do things.
Why not Kolla but Fuel-ccp? It is not a secret that Fuel is driven by
Mirantis. At Mirantis we deploy and maintain OpenStack. In attempts to
find a way how to make OpenStack easily maintainable, some of Mirantis
folks spent some time to contribute to Kolla and Mesos. But there were
some concerns that were discussed several times (including this Kolla
spec https://review.openstack.org/#/c/330575) that would make it not
so easy to use Kolla containers for our use cases. Fuel-ccp is just an
attempt to address these concerns. Frankly, I don’t see anything bad
in having more than one set of container images (like we have more
than one set of RPM/DEB distributions).
Those concerns are, for example, container images should not be bound
to any specific deployment technology. Containers in some sense are a
similar concept to RPM/DEB packages and it does not matter what
deployment tool (puppet, ansible) one uses to install them. There
should be mature CI pipeline for building/testing/publishing images.
There should be a convenient way (kind of DSL) to deal with dozens of
images. I’d like to avoid discussing this here once again.
Fuel-ccp repositories are public, everyone is welcome to participate.
I don’t see where we violate “4 opens”. These repos are now
experimental. At the moment the team is working on building CI
pipeline and developing functional tests that are to be run as a part
of CI process. These repos are not to be a part of Fuel Newton
release. From time to time we add and retire git repos and it is a
part of development process. Not all these repos are to become a part
of Big tent.
Vladimir Kozhukalov
On Thu, Jul 28, 2016 at 7:45 AM, Steven Dake (stdake)
<std...@cisco.com <mailto:std...@cisco.com>> wrote:
On 7/27/16, 2:12 PM, "Jay Pipes" <jaypi...@gmail.com
<mailto:jaypi...@gmail.com>> wrote:
>On 07/27/2016 04:42 PM, Ed Leafe wrote:
>> On Jul 27, 2016, at 2:42 PM, Fox, Kevin M <kevin....@pnnl.gov
<mailto:kevin....@pnnl.gov>> wrote:
>>
>>> Its not an "end user" facing thing, but it is an "operator" facing
>>>thing.
>>
>> Well, the end user for Kolla is an operator, no?
>>
>>> I deploy kolla containers today on non kolla managed systems in
>>>production, and rely on that api being consistent.
>>>
>>> I'm positive I'm not the only operator doing this either. This
sounds
>>>like a consumable api to me.
>>
>> I don¹t think that an API has to be RESTful to be considered an
>>interface for we should avoid duplication.
>
>Application *Programming* Interface. There's nothing that is being
>*programmed* or *called* in Kolla's image definitions.
>
>What Kolla is/has is not an API. As Stephen said, it's more of an
>Application Binary Interface (ABI). It's not really an ABI,
though, in
>the traditional sense of the term that I'm used to.
>
>It's an agreed set of package bases, installation
procedures/directories
>and configuration recipes for OpenStack and infrastructure
components.
Jay,
From my perspective, this isn't about ABI proliferation or
competition.
This is about open public discourse.
It is the responsibility of all community members to protect the four
opens.
Given the intent of fuel-ccp to fully adopt K8S into Fuel
described here:
https://techcrunch.com/2016/07/25/openstack-will-soon-be-able-to-run-on-top
-of-kubernetes/
<https://techcrunch.com/2016/07/25/openstack-will-soon-be-able-to-run-on-top%0A-of-kubernetes/>
It is hard to understand the arguments in the reviews related to
"this is
an experimental project, so its not targeted towards big tent" yet
Boris
wrote in that press release its Fuel's next big thing.
I raised the objection early on that a mission statement change
was needed
by Fuel if they wanted to proceed down this path, to which I was
told K8S
support is not going into big tent.
As a result of Mirantis's change in mind about fuel-ccp being NOT
experimental and being targeted for big tent, I'd like the record set
straight in the governance repository since the intentions are being
published in the press and the current intentions of this project are
public.
I could see how people could perceive many violations of the four
opens in
all of the activities related to the fuel-ccp project. We as a
community
value open discourse because we are all intelligent human beings. We
value honesty and integrity because trust is the foundation of how our
community operates. I feel the best way for Fuel to repair the
perceived
violations of the four opens going forward is to:
1. Alter the mission statement of fuel to match the reality being
published by the press and Mirantis's executive team
2. Include these non-experimental repos in the projects.yaml
governance
repository
That would satisfy my four opens concerns.
If the Fuel PTL doesn't want to do these two things, I'd like a public
explanation as to why from Vladimir who thus far has remained quiet on
this thread.
Thanks
-steve
>
>I see no reason for the OpenStack community to standardize on those
>things, frankly. It's like asking RedHat and Canonical to agree
to "just
>use RPM" as their package specification format. I wonder how that
>conversation would go.
>
>Best,
>-jay
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://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://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
