<div dir="ltr"><div dir="ltr">I don't think I have enough coffee in me to fully digest this, but wanted to<br>point out a couple of things. FWIW, this is something I've thought we should do<br>for a while now.<br></div><div dir="ltr"><br></div><div dir="ltr">On Sat, Jun 1, 2019 at 8:43 AM Mohammed Naser <<a href="mailto:mnaser@vexxhost.com">mnaser@vexxhost.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi everyone,<br>
<br>
This is something that I've discussed with a few people over time and<br>
I think I'd probably want to bring it up by now.  I'd like to propose<br>
and ask if it makes sense to perhaps replace devstack entirely with<br>
openstack-ansible.  I think I have quite a few compelling reasons to<br>
do this that I'd like to outline, as well as why I *feel* (and I could<br>
be biased here, so call me out!) that OSA is the best option in terms<br>
of a 'replacement'<br>
<br>
# Why not another deployment project?<br>
I actually thought about this part too and considered this mainly for<br>
ease of use for a *developer*.<br>
<br>
At this point, Puppet-OpenStack pretty much only deploys packages<br>
(which means that it has no build infrastructure, a developer can't<br>
just get $commit checked out and deployed).<br>
<br>
TripleO uses Kolla containers AFAIK and those have to be pre-built<br>
beforehand, also, I feel they are much harder to use as a developer<br>
because if you want to make quick edits and restart services, you have<br>
to enter a container and make the edit there and somehow restart the<br>
service without the container going back to it's original state.<br>
Kolla-Ansible and the other combinations also suffer from the same<br>
"issue".<br></blockquote><div><br></div><div>FWIW, kolla-ansible (and maybe tripleo?) has a "development" mode which mounts<br>the code as a volume, so you can make edits and just run "docker restart<br>$service". Though systemd does make that a bit nicer due to globs (e.g.<br>systemctl restart nova-*).<br><br>That said, I do agree moving to something where systemd is running the services<br>would make for a smoother transition for developers.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
OpenStack Ansible is unique in the way that it pretty much just builds<br>
a virtualenv and installs packages inside of it.  The services are<br>
deployed as systemd units.  This is very much similar to the current<br>
state of devstack at the moment (minus the virtualenv part, afaik).<br>
It makes it pretty straight forward to go and edit code if you<br>
need/have to.  We also have support for Debian, CentOS, Ubuntu and<br>
SUSE.  This allows "devstack 2.0" to have far more coverage and make<br>
it much more easy to deploy on a wider variety of operating systems.<br>
It also has the ability to use commits checked out from Zuul so all<br>
the fancy Depends-On stuff we use works.<br>
<br>
# Why do we care about this, I like my bash scripts!<br>
As someone who's been around for a *really* long time in OpenStack,<br>
I've seen a whole lot of really weird issues surface from the usage of<br>
DevStack to do CI gating.  For example, one of the recent things is<br>
the fact it relies on installing package-shipped noVNC, where as the<br>
'master' noVNC has actually changed behavior a few months back and it<br>
is completely incompatible at this point (it's just a ticking thing<br>
until we realize we're entirely broken).<br>
<br>
To this day, I still see people who want to POC something up with<br>
OpenStack or *ACTUALLY* try to run OpenStack with DevStack.  No matter<br>
how many warnings we'll put up, they'll always try to do it.  With<br>
this way, at least they'll have something that has the shape of an<br>
actual real deployment.  In addition, it would be *good* in the<br>
overall scheme of things for a deployment system to test against,<br>
because this would make sure things don't break in both ways.<br></blockquote><div><br></div><div>++</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Also: we run Zuul for our CI which supports Ansible natively, this can<br>
remove one layer of indirection (Zuul to run Bash) and have Zuul run<br>
the playbooks directly from the executor.<br>
<br>
# So how could we do this?<br>
The OpenStack Ansible project is made of many roles that are all<br>
composable, therefore, you can think of it as a combination of both<br>
Puppet-OpenStack and TripleO (back then).  Puppet-OpenStack contained<br>
the base modules (i.e. puppet-nova, etc) and TripleO was the<br>
integration of all of it in a distribution.  OSA is currently both,<br>
but it also includes both Ansible roles and playbooks.<br>
<br>
In order to make sure we maintain as much of backwards compatibility<br>
as possible, we can simply run a small script which does a mapping of<br>
devstack => OSA variables to make sure that the service is shipped<br>
with all the necessary features as per local.conf.<br></blockquote><div><br></div><div>++</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
So the new process could be:<br>
<br>
1) parse local.conf and generate Ansible variables files<br>
2) install Ansible (if not running in gate)<br>
3) run playbooks using variable generated in #1<br>
<br>
The neat thing is after all of this, devstack just becomes a thin<br>
wrapper around Ansible roles.  I also think it brings a lot of hands<br>
together, involving both the QA team and OSA team together, which I<br>
believe that pooling our resources will greatly help in being able to<br>
get more done and avoiding duplicating our efforts.<br>
<br>
# Conclusion<br>
This is a start of a very open ended discussion, I'm sure there is a<br>
lot of details involved here in the implementation that will surface,<br>
but I think it could be a good step overall in simplifying our CI and<br>
adding more coverage for real potential deployers.  It will help two<br>
teams unite together and have more resources for something (that<br>
essentially is somewhat of duplicated effort at the moment).<br>
<br>
I will try to pick up sometime to POC a simple service being deployed<br>
by an OSA role instead of Bash, placement which seems like a very<br>
simple one and share that eventually.<br>
<br>
Thoughts? :)<br></blockquote><div><br></div>The reason this hasn't been pushed on in the past is to avoid the perception<br>that the TC or QA team is choosing a "winner" in the deployment space. I don't<br>think that's a good reason not to do something like this (especially with the<br>drop in contributors since I've had that discussion). However, we do need to<br><div>message this carefully at a minimum.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
Mohammed Naser — vexxhost<br>
-----------------------------------------------------<br>
D. 514-316-8872<br>
D. 800-910-1726 ext. 200<br>
E. <a href="mailto:mnaser@vexxhost.com" target="_blank">mnaser@vexxhost.com</a><br>
W. <a href="http://vexxhost.com" rel="noreferrer" target="_blank">http://vexxhost.com</a><br>
<br>
</blockquote></div></div>