<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Sorry for the double post, but the part about people wasting
their time reads far more inflammatory than I really intended. I
merely mean community effort is a strong theme.<br>
</p>
<br>
<div class="moz-cite-prefix">On 7/28/2016 11:20 AM, Mark Casey
wrote:<br>
</div>
<blockquote
cite="mid:e1e8ee20-c151-2937-ee5f-ebd0a2b5d1b7@pointofrental.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<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 moz-do-not-send="true"
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 moz-do-not-send="true" 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 moz-do-not-send="true" 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>
<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>