I hear you, Matt. TripleO is great, and v useful for what it is. But I agree
that in our (been-there-done-that) experience, it was never intended to be a
production-ready environment - and it isn’t.
Ø I like the idea of OOO
I do too - we all do! But in a production environment it’s currently (imho) too
difficult & too volatile, and it’s hard to see how that can be fixed without a
fundamental shake up.
Ø 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.
Yep, I hear ya. Things like installing the node with an operating system have
already been done 9,000 times. Why reinvent Cobbler, when the real Cobbler
already does that? Or Crowbar, or whatever? Makes no sense.
If you have ideas let me know directly (anyone!). I’m right in the middle of
HPE’s OpenStack install/upgrade work and would really like to hear where you
want us to go.
Thanks,
Joe.
From: Silence Dogood [mailto:m...@nycresistor.com]
Sent: 03 August 2016 16:09
To: Fegan, Joe
Cc: OpenStack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] Who's using TripleO in production?
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.
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.
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.
-Matt
On Wed, Aug 3, 2016 at 9:00 AM, Fegan, Joe
mailto:joe.fe...@hpe.com>> wrote:
Hi folks,
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 ;)
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.
Thanks,
Joe.
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
