<div dir="ltr"><div><br></div>the v1 helion product was a joke for deployment at scale. I still don't know whose hair brained idea it was to use OOO there and then. but it was hair brained at best. From my perspective the biggest issue with helion, was insane architecture decisions like that one being made with no adherence to the constraints of reality.<div><br></div><div>I recall at around early 2015 or so, at an operators meetup someone asking if anyone was using OOO and the response was a room full of laughter. And yet by this point helion had already decided to proceed with it, despite their own people telling them it would take years to make usable.<div><br></div><div></rant></div></div><div><br></div><div>I like the idea of OOO but it takes time to harden that sort of deployment scenario. And trying to build a generic tool to hit hardware in the wild is an exercise in futility, to a point. Crowbar actually kind of made sense in so far as it was designed to let you write the connector bits you'd need to write. I figure over time OOO will be forced into that sort of pattern as every automated deployment framework has been for the past 20 years or so. It's amazing how many times i've seen people try to reinvent this wheel, and how many times they've outright ignored the lessons of those who went before.</div><div><br></div><div>-Matt</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 3, 2016 at 9:00 AM, Fegan, Joe <span dir="ltr"><<a href="mailto:joe.fegan@hpe.com" target="_blank">joe.fegan@hpe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-IE" link="#0563C1" vlink="#954F72">
<div>
<p class="MsoNormal"><span lang="EN-US">Hi folks,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">I agree. HP(E) were major contributors to TripleO in the early days, and our V1 Helion product was based on it. But, as Dan says, we wrote a new OpenStack installer from scratch for V2+. Mostly in Ansible. The sources
are up on GitHub with an Apache2 license - feel free to take and use them. We call it HLM (Helion Lifecycle Manager) but you can call it whatever you want ;)<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Our production experience and customer feedback with V1, TripleO were and are … “eventful”. And hard to debug / restart / continue. That was the main motivation for a newer and better install/upgrade mechanism. Of course
I’m biased lol ;) The group working on it in HPE are all ex-public cloud and/or HPC production background, so we hope that we always have the real user perspective in mind.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Thanks,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Joe.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
</div>
<br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div><br></div></div>