<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>+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?).<br>
</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p>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)<br>
</p>
<p> <br>
Thank you,<br>
Mark</p>
<br>
<div class="moz-cite-prefix">On 7/28/2016 8:56 AM, Fox, Kevin M
wrote:<br>
</div>
<blockquote
cite="mid:1A3C52DFCD06494D8528644858247BF01B9AEF1B@EX10MBOX03.pnnl.gov"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
<div style="direction: ltr;font-family: Tahoma;color:
#000000;font-size: 10pt;">I really see 3 issues raised in the
spec mentioned that have any disagreement as far as I can tell.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
Maybe something like:<br>
1. kolla commits to split out kolla-ansible as soon as possible
(right after newton tagged)<br>
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?)<br>
3. We keep the optional stuff so we don't break existing
deployments.<br>
<br>
Is this reasonable?<br>
<br>
Thanks,<br>
Kevin<br>
<div style="font-family: Times New Roman; color: #000000;
font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF681073"><font
face="Tahoma" color="#000000" size="2"><b>From:</b>
Vladimir Kozhukalov [<a class="moz-txt-link-abbreviated" href="mailto:vkozhukalov@mirantis.com">vkozhukalov@mirantis.com</a>]<br>
<b>Sent:</b> Thursday, July 28, 2016 5:48 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for
usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Kolla] [Fuel] [tc]
Looks like Mirantis is getting Fuel CCP (docker/k8s)
kicked off<br>
</font><br>
</div>
<div>
<div dir="ltr">
<div class="gmail_default"
style="font-family:monospace,monospace">
<p
id="gmail-docs-internal-guid-7c686a65-3189-4032-0f26-c9511bbb38d2"
dir="ltr" style="line-height:1.38; margin-top:0pt;
margin-bottom:0pt">
<span style="font-size:14.6667px; font-family:arial;
color:rgb(0,0,0); background-color:transparent;
font-weight:400; font-style:normal;
font-variant:normal; text-decoration:none;
vertical-align:baseline">>1. Alter the mission
statement of fuel to match the reality being</span></p>
<p dir="ltr" style="line-height:1.38; margin-top:0pt;
margin-bottom:0pt"><span style="font-size:14.6667px;
font-family:arial; color:rgb(0,0,0);
background-color:transparent; font-weight:400;
font-style:normal; font-variant:normal;
text-decoration:none; vertical-align:baseline">>published
by the press and Mirantis's executive team</span></p>
<p dir="ltr" style="line-height:1.38; margin-top:0pt;
margin-bottom:0pt"><span style="font-size:14.6667px;
font-family:arial; color:rgb(0,0,0);
background-color:transparent; font-weight:400;
font-style:normal; font-variant:normal;
text-decoration:none; vertical-align:baseline">>2.
Include these non-experimental repos in the
projects.yaml governance</span></p>
<p dir="ltr" style="line-height:1.38; margin-top:0pt;
margin-bottom:0pt"><span style="font-size:14.6667px;
font-family:arial; color:rgb(0,0,0);
background-color:transparent; font-weight:400;
font-style:normal; font-variant:normal;
text-decoration:none; vertical-align:baseline">>Repository</span></p>
<br>
<p dir="ltr" style="line-height:1.38; margin-top:0pt;
margin-bottom:0pt"><span style="font-size:14.6667px;
font-family:arial; color:rgb(0,0,0);
background-color:transparent; font-weight:400;
font-style:normal; font-variant:normal;
text-decoration:none; vertical-align:baseline">Frankly,
I don’t understand what part of the press release
contradicts with Fuel mission.
</span></p>
<p dir="ltr" style="line-height:1.38; margin-top:0pt;
margin-bottom:0pt"><span style="font-size:14.6667px;
font-family:arial; color:rgb(0,0,0);
background-color:transparent; font-weight:400;
font-style:normal; font-variant:normal;
text-decoration:none; vertical-align:baseline">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.
</span></p>
<br>
<p dir="ltr" style="line-height:1.38; margin-top:0pt;
margin-bottom:0pt"><span style="font-size:14.6667px;
font-family:arial; color:rgb(0,0,0);
background-color:transparent; font-weight:400;
font-style:normal; font-variant:normal;
text-decoration:none; vertical-align:baseline">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. </span>
</p>
<br>
<p dir="ltr" style="line-height:1.38; margin-top:0pt;
margin-bottom:0pt"><span style="font-size:14.6667px;
font-family:arial; color:rgb(0,0,0);
background-color:transparent; font-weight:400;
font-style:normal; font-variant:normal;
text-decoration:none; vertical-align:baseline">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. </span></p>
<br>
<p dir="ltr" style="line-height:1.38; margin-top:0pt;
margin-bottom:0pt"><span style="font-size:14.6667px;
font-family:arial; color:rgb(0,0,0);
background-color:transparent; font-weight:400;
font-style:normal; font-variant:normal;
text-decoration:none; vertical-align:baseline">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
</span><a moz-do-not-send="true"
href="https://review.openstack.org/#/c/330575"
style="text-decoration:none" target="_blank"><span
style="font-size:14.6667px; font-family:arial;
color:rgb(17,85,204);
background-color:transparent; font-weight:400;
font-style:normal; font-variant:normal;
text-decoration:underline;
vertical-align:baseline">https://review.openstack.org/#/c/330575</span></a><span
style="font-size:14.6667px; font-family:arial;
color:rgb(0,0,0); background-color:transparent;
font-weight:400; font-style:normal;
font-variant:normal; text-decoration:none;
vertical-align:baseline">) 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).</span></p>
<br>
<p dir="ltr" style="line-height:1.38; margin-top:0pt;
margin-bottom:0pt"><span style="font-size:14.6667px;
font-family:arial; color:rgb(0,0,0);
background-color:transparent; font-weight:400;
font-style:normal; font-variant:normal;
text-decoration:none; vertical-align:baseline">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.
</span></p>
<br>
<span style="font-size:14.6667px; font-family:arial;
color:rgb(0,0,0); background-color:transparent;
font-weight:400; font-style:normal;
font-variant:normal; text-decoration:none;
vertical-align:baseline">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.<br>
<br>
<br>
</span></div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature">
<div>Vladimir Kozhukalov</div>
</div>
</div>
<br>
<div class="gmail_quote">On Thu, Jul 28, 2016 at 7:45 AM,
Steven Dake (stdake) <span dir="ltr">
<<a moz-do-not-send="true"
href="mailto:stdake@cisco.com" target="_blank">stdake@cisco.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex; border-left:1px #ccc solid; padding-left:1ex">
<span class=""><br>
<br>
On 7/27/16, 2:12 PM, "Jay Pipes" <<a
moz-do-not-send="true"
href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>>
wrote:<br>
<br>
>On 07/27/2016 04:42 PM, Ed Leafe wrote:<br>
>> On Jul 27, 2016, at 2:42 PM, Fox, Kevin M
<<a moz-do-not-send="true"
href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>>
wrote:<br>
>><br>
>>> Its not an "end user" facing thing, but
it is an "operator" facing<br>
>>>thing.<br>
>><br>
>> Well, the end user for Kolla is an
operator, no?<br>
>><br>
>>> I deploy kolla containers today on non
kolla managed systems in<br>
>>>production, and rely on that api being
consistent.<br>
>>><br>
>>> I'm positive I'm not the only operator
doing this either. This sounds<br>
>>>like a consumable api to me.<br>
>><br>
>> I donąt think that an API has to be RESTful
to be considered an<br>
>>interface for we should avoid duplication.<br>
><br>
>Application *Programming* Interface. There's
nothing that is being<br>
>*programmed* or *called* in Kolla's image
definitions.<br>
><br>
>What Kolla is/has is not an API. As Stephen
said, it's more of an<br>
>Application Binary Interface (ABI). It's not
really an ABI, though, in<br>
>the traditional sense of the term that I'm used
to.<br>
><br>
>It's an agreed set of package bases,
installation procedures/directories<br>
>and configuration recipes for OpenStack and
infrastructure components.<br>
<br>
</span>Jay,<br>
<br>
From my perspective, this isn't about ABI
proliferation or competition.<br>
This is about open public discourse.<br>
<br>
It is the responsibility of all community members to
protect the four<br>
opens.<br>
<br>
Given the intent of fuel-ccp to fully adopt K8S into
Fuel described here:<br>
<a moz-do-not-send="true"
href="https://techcrunch.com/2016/07/25/openstack-will-soon-be-able-to-run-on-top%0A-of-kubernetes/"
rel="noreferrer" target="_blank">https://techcrunch.com/2016/07/25/openstack-will-soon-be-able-to-run-on-top<br>
-of-kubernetes/</a><br>
<br>
<br>
It is hard to understand the arguments in the reviews
related to "this is<br>
an experimental project, so its not targeted towards
big tent" yet Boris<br>
wrote in that press release its Fuel's next big thing.<br>
<br>
I raised the objection early on that a mission
statement change was needed<br>
by Fuel if they wanted to proceed down this path, to
which I was told K8S<br>
support is not going into big tent.<br>
<br>
As a result of Mirantis's change in mind about
fuel-ccp being NOT<br>
experimental and being targeted for big tent, I'd like
the record set<br>
straight in the governance repository since the
intentions are being<br>
published in the press and the current intentions of
this project are<br>
public.<br>
<br>
I could see how people could perceive many violations
of the four opens in<br>
all of the activities related to the fuel-ccp
project. We as a community<br>
value open discourse because we are all intelligent
human beings. We<br>
value honesty and integrity because trust is the
foundation of how our<br>
community operates. I feel the best way for Fuel to
repair the perceived<br>
violations of the four opens going forward is to:<br>
<br>
1. Alter the mission statement of fuel to match the
reality being<br>
published by the press and Mirantis's executive team<br>
2. Include these non-experimental repos in the
projects.yaml governance<br>
repository<br>
<br>
That would satisfy my four opens concerns.<br>
<br>
If the Fuel PTL doesn't want to do these two things,
I'd like a public<br>
explanation as to why from Vladimir who thus far has
remained quiet on<br>
this thread.<br>
<br>
Thanks<br>
-steve<br>
<div class="HOEnZb">
<div class="h5"><br>
<br>
<br>
<br>
><br>
>I see no reason for the OpenStack community to
standardize on those<br>
>things, frankly. It's like asking RedHat and
Canonical to agree to "just<br>
>use RPM" as their package specification
format. I wonder how that<br>
>conversation would go.<br>
><br>
>Best,<br>
>-jay<br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for
usage questions)<br>
>Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>