<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1" class="" style="word-wrap:break-word">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Yeah, but if the deployment tools have to implement support for every project, it becomes combinatorial to support all the projects in all the deployment tools. let alone document
it for each deployment project. If there was a foundational infrastructure that the other big tent projects could rely on always being there, then the big tent projects could themselves work on the deployment tooling and do it only once. The idea is not to
deprecate the big tent projects, but deprecate deploying them with so many different tools. Deploy the base openstack parts using chef, ansible, etc and then use the common tooling to deploy the rest. Just a thought.<br>
<br>
Thanks,<br>
Kevin<br>
<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF52477"><font face="Tahoma" size="2" color="#000000"><b>From:</b> Tim Bell [Tim.Bell@cern.ch]<br>
<b>Sent:</b> Thursday, February 16, 2017 11:28 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef<br>
</font><br>
</div>
<div></div>
<div><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 16 Feb 2017, at 19:42, Fox, Kevin M <<a href="mailto:Kevin.Fox@pnnl.gov" class="" target="_blank">Kevin.Fox@pnnl.gov</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">+1. The assumption was market forces will cause the best OpenStack deployment tools to win. But the sad reality is, market forces are causing people to look for non OpenStack solutions instead as the pain is still too high.<br class="">
<br class="">
While k8s has a few different deployment tools currently, they are focused on getting the small bit of underlying plumbing deployed. Then you use the common k8s itself to deploy the rest. Adding a dashboard, dns, ingress, sdn, other component is easy in that
world.<br class="">
<br class="">
IMO, OpenStack needs to do something similar. Standardize a small core and get that easily deployable, then make it easy to deploy/upgrade the rest of the big tent projects on top of that, not next to it as currently is being done.<br class="">
<br class="">
Thanks,<br class="">
Kevin<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
Unfortunately, the more operators and end users question the viability of a specific project, the less likely it is to be adopted.
<p class="MsoNormal">It is a very very difficult discussion with an end user to explain that function X is no longer available because the latest OpenStack upgrade had to be done for security/functional/stability reasons and this project/function is not available. </p>
<p class="MsoNormal">The availability of a function may also have been one of the positives for the OpenStack selection so finding a release or two later that it is no longer in the portfolio is difficult.</p>
<p class="MsoNormal">The deprecation policy really helps so we can give a good notice but this assumes an equivalent function is available. For example, the built in Nova EC2 to EC2 project was an example where we had enough notice to test the new solution
in parallel and then move with minimum disruption. Moving an entire data centre from Chef to Puppet or running a parallel toolchain, for example, has a high cost.</p>
<p class="MsoNormal">Given the massive functionality increase in other clouds, It will be tough to limit the OpenStack offering to the small core. However, expanding with unsustainable projects is also not attractive.</p>
<p class="MsoNormal">Tim</p>
<p class="MsoNormal"><br class="">
</p>
<blockquote type="cite" class="">
<div class="">
<div class="">________________________________________<br class="">
From: Joshua Harlow [<a href="mailto:harlowja@fastmail.com" class="" target="_blank">harlowja@fastmail.com</a>]<br class="">
Sent: Thursday, February 16, 2017 10:24 AM<br class="">
To: OpenStack Development Mailing List (not for usage questions)<br class="">
Subject: Re: [openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef<br class="">
<br class="">
Alex Schultz wrote:<br class="">
<blockquote type="cite" class="">On Thu, Feb 16, 2017 at 9:12 AM, Ed Leafe<<a href="mailto:ed@leafe.com" class="" target="_blank">ed@leafe.com</a>> wrote:<br class="">
<blockquote type="cite" class="">On Feb 16, 2017, at 10:07 AM, Doug Hellmann<<a href="mailto:doug@doughellmann.com" class="" target="_blank">doug@doughellmann.com</a>> wrote:<br class="">
<br class="">
<blockquote type="cite" class="">When we signed off on the Big Tent changes we said competition<br class="">
between projects was desirable, and that deployers and contributors<br class="">
would make choices based on the work being done in those competing<br class="">
projects. Basically, the market would decide on the "optimal"<br class="">
solution. It's a hard message to hear, but that seems to be what<br class="">
is happening.<br class="">
</blockquote>
This.<br class="">
<br class="">
We got much better at adding new things to OpenStack. We need to get better at letting go of old things.<br class="">
<br class="">
-- Ed Leafe<br class="">
<br class="">
<br class="">
<br class="">
</blockquote>
<br class="">
I agree that the market will dictate what continues to survive, but if<br class="">
you're not careful you may be speeding up the decline as the end user<br class="">
(deployer/operator/cloud consumer) will switch completely to something<br class="">
else because it becomes to difficult to continue to consume via what<br class="">
used to be there and no longer is. I thought the whole point was to<br class="">
not have vendor lock-in. Honestly I think the focus is too much on<br class="">
the development and not enough on the consumption of the development<br class="">
output. What are the point of all these features if no one can<br class="">
actually consume them.<br class="">
<br class="">
</blockquote>
<br class="">
+1 to that.<br class="">
<br class="">
I've been in the boat of development and consumption of it for my<br class="">
*whole* journey in openstack land and I can say the product as a whole<br class="">
seems 'underbaked' with regards to the way people consume the<br class="">
development output. It seems we have focused on how to do the dev. stuff<br class="">
nicely and a nice process there, but sort of forgotten about all that<br class="">
being quite useless if no one can consume them (without going through<br class="">
much pain or paying a vendor).<br class="">
<br class="">
This has or has IMHO been a factor in why certain are companies (and the<br class="">
people they support) are exiting openstack and just going elsewhere.<br class="">
<br class="">
I personally don't believe fixing this is 'let the market forces' figure<br class="">
it out for us (what a slow & horrible way to let this play out; I'd<br class="">
almost rather go pull my fingernails out). I do believe it will require<br class="">
making opinionated decisions which we have all never been very good at.<br class="">
<br class="">
__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="" target="_blank">
OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class="">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
<br class="">
__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br class="">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</body>
</html>