<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Dan Prince <<a href="mailto:dprince@redhat.com">dprince@redhat.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Sunday, April 3, 2016 at 4:54 PM<br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div>On Thu, 2016-03-31 at 08:22 +0000, Steven Dake (stdake) wrote:</div>
<blockquote type="cite">
<div>Kevin,</div>
<div><br>
</div>
<div>I am not directly answering your question, but from the perspective of Kolla, our upgrades are super simple because we don't make a big mess in the first place to upgrade from. In my experience, this is the number one problem with upgrades – everyone
makes a mess of the first deployment, so upgrading from there is a minefield. Better to walk straight through that minefield by not making a mess of the system in the first place using my favorite deployment tool: Kolla ;-)</div>
</blockquote>
<div><br>
</div>
<div>I think any containers based solution (Kolla or not) would be naturally "less messy" than a baremetal deployment that isn't containerized. So I think TripleO would achieve much of the same by switching to any containerized deployment architecture right?
Is there something special about the Kolla/Ansible approach that I'm missing here?</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>Dan,</div>
<div><br>
</div>
<div>Yes there is something your missing.</div>
<div><br>
</div>
<div>What I'd ask of you, and all of the TripleO developers in fact, is to spend 4 hours and deploy Kolla on a single bare metal node (AIO). Get a feel for the workflow. Get a feel for the nearly-dependency-free deployment model. Get a feel for the simplicity.</div>
<div><br>
</div>
<div>I know 4 hours is a lot to ask, but it won't be a waste of your time.</div>
<div><br>
</div>
<div>If you run into trouble which can happen if the QSG isn't followed, come hit us up in #openstack-kolla on IRC. Our community is very inviting and helpful and I can guarantee will get you a working deployment of Kolla.</div>
<div><br>
</div>
<div>Kolla may have gaps compared to tripleO, but for the moment, I'd ask you to put those aside, since that seems to be the main objection raised when a tripleo+kolla integration is proposed. Any gap can be fixed easily in Kolla if you tell us what you want,
or do the work yourself.</div>
<div><br>
</div>
<div>Once you have a working AIO deployment, you will have the answer to your question and more...</div>
<div><br>
</div>
<div>Regards,</div>
<div>-steve</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div><br>
</div>
<blockquote type="cite">
<div><br>
</div>
<div>Kolla upgrades rock. I have no doubt we will have some minor issues in the field, but we have tested 1 month old master to master upgrades with database migrations of the services we deploy, and it takes approximately 10 minutes on a 64 (3 control rest
compute) node cluster without VM downtime or loss of networking service to the virtual machines. This is because our upgrades, while not totally atomic across the clsuter, are pretty darn close and upgrade the entire filesystem runtime in one atomic action
per service while rolling the ugprade in the controller nodes.</div>
<div><br>
</div>
<div>During the upgrade process there may be some transient failures for API service calls, but they are typically repeated by clients and no real harm is done. Note we follow project's best practices for handling upgrades, without the mess of dealing with
packaging or configuration on the filesystem and migration thereof.</div>
<div><br>
</div>
<div>Regards</div>
<div>-steve</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>"Fox, Kevin M" <<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Wednesday, March 30, 2016 at 9:12 PM<br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO<br>
</div>
<div><br>
</div>
<blockquote style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
<div>
<div>The main issue is one of upgradability, not stability. We all know tripleo is stable. Tripleo cant do upgrades today. We're looking for ways to get there. So "upgrading" to ansible isnt nessisary for sure since folks deploying tripleo today must assume
they cant upgrade anyway.<br>
<br>
Honestly I have doubts any config management system from puppet to heat software deployments can be coorced to do a cloud upgrade without downtime without a huge amount of workarounds. You really either need a workflow oriented system with global knowledge
like ansible or a container orchestration system like kubernes to ensure you dont change too many things at once and break things. You need to be able to run some old things and some new, all at the same time. And in some cases different versions/config of
the same service on different machines. <br>
<br>
Thoughts on how this may be made to work with puppet/heat?<br>
<br>
Thanks,<br>
Kevin <strong>
<div><font face="Tahoma" color="#000000" size="2"> </font></div>
</strong>
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b> Dan Prince<br>
<b>Sent:</b> Monday, March 28, 2016 12:07:22 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO<br>
</font><br>
<div></div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On Wed, 2016-03-23 at 07:54 -0400, Ryan Hallisey wrote:<br>
> *Snip*<br>
> <br>
> > <br>
> > Indeed, this has literally none of the benefits of the ideal Heat <br>
> > deployment enumerated above save one: it may be entirely the wrong<br>
> > tool <br>
> > in every way for the job it's being asked to do, but at least it<br>
> > is <br>
> > still well-integrated with the rest of the infrastructure.<br>
> > <br>
> > Now, at the Mitaka summit we discussed the idea of a 'split<br>
> > stack', <br>
> > where we have one stack for the infrastructure and a separate one<br>
> > for <br>
> > the software deployments, so that there is no longer any tight <br>
> > integration between infrastructure and software. Although it makes<br>
> > me a <br>
> > bit sad in some ways, I can certainly appreciate the merits of the<br>
> > idea <br>
> > as well. However, from the argument above we can deduce that if<br>
> > this is <br>
> > the *only* thing we do then we will end up in the very worst of<br>
> > all <br>
> > possible worlds: the wrong tool for the job, poorly integrated.<br>
> > Every <br>
> > single advantage of using Heat to deploy software will have<br>
> > evaporated, <br>
> > leaving only disadvantages.<br>
> I think Heat is a very powerful tool having done the container<br>
> integration<br>
> into the tripleo-heat-templates I can see its appeal. Something I<br>
> learned<br>
> from integration, was that Heat is not the best tool for container<br>
> deployment,<br>
> at least right now. We were able to leverage the work in Kolla, but<br>
> what it<br>
> came down to was that we're not using containers or Kolla to its max<br>
> potential.<br>
> <br>
> I did an evaluation recently of tripleo and kolla to see what we<br>
> would gain<br>
> if the two were to combine. Let's look at some items on tripleo's<br>
> roadmap.<br>
> Split stack, as mentioned above, would be gained if tripleo were to<br>
> adopt<br>
> Kolla. Tripleo holds the undercloud and ironic. Kolla separates<br>
> config<br>
> and deployment. Therefore, allowing for the decoupling for each<br>
> piece of<br>
> the stack. Composable roles, this would be the ability to land<br>
> services<br>
> onto separate hosts on demand. Kolla also already does this [1].<br>
> Finally,<br>
> container integration, this is just a given :).<br>
> <br>
> In the near term, if tripleo were to adopt Kolla as its overcloud it<br>
> would<br>
> be provided these features and retire heat to setting up the<br>
> baremetal nodes<br>
> and providing those ips to ansible. This would be great for kolla<br>
> too because<br>
> it would provide baremetal provisioning.<br>
> <br>
> Ian Main and I are currently working on a POC for this as of last<br>
> week [2].<br>
> It's just a simple heat template :).<br>
> <br>
> I think further down the road we can evaluate using kubernetes [3].<br>
> For now though, kolla-anisble is rock solid and is worth using for<br>
> the<br>
> overcloud.<br>
<br>
Yeah, well TripleO heat Overclouds are rock solid too. They just aren't<br>
using containers everywhere yet. So lets fix that.<br>
<br>
I'm not a fan of replacing the TripleO overcloud configuration with<br>
Kolla. I don't think there is feature parity, the architectures are<br>
different (HA, etc.) and I don't think you could easily pull off an<br>
upgrade from one deployment to the other (going from TripleO Heat<br>
template deployed overcloud to Kolla deployed overcloud).<br>
<br>
> <br>
> Thanks!<br>
> -Ryan<br>
> <br>
> [1] - <a href="https://github.com/openstack/kolla/blob/master/ansible/inventor">
https://github.com/openstack/kolla/blob/master/ansible/inventor</a><br>
> y/multinode<br>
> [2] - <a href="https://github.com/rthallisey/kolla-heat-templates">https://github.com/rthallisey/kolla-heat-templates</a><br>
> [3] - <a href="https://review.openstack.org/#/c/255450/">https://review.openstack.org/#/c/255450/</a><br>
> <br>
> <br>
> _____________________________________________________________________<br>
> _____<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubs<br>
> cribe<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</span></font></div>
</div>
</blockquote>
</span>
<pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></pre>
</blockquote>
</div>
</div>
</blockquote>
</span>
</body>
</html>