<div dir="ltr"><div>For many people in enterprise git / pypi deployments are non starters.  We use real package management systems with real signed packages for a bunch of policy and architectural reasons.  So anyone who is under the mistaken impression that pypi especially will be a usable deployment model in the real world let me disabuse you of that notion right now. <br>
<br></div>-Matt<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 8:08 PM, James Slagle <span dir="ltr"><<a href="mailto:james.slagle@gmail.com" target="_blank">james.slagle@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Thu, Feb 13, 2014 at 4:27 PM, Robert Collins<br>
<<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
> So progressing with the 'and folk that want to use packages can' arc,<br>
> we're running into some friction.<br>
><br>
> I've copied -operators in on this because its very relevant IMO to operators :)<br>
><br>
> So far:<br>
>  - some packages use different usernames<br>
>  - some put things in different places (and all of them use different<br>
> places to the bare metal ephemeral device layout which requires<br>
> /mnt/).<br>
>  - possibly more in future.<br>
><br>
> Now, obviously its a 'small matter of code' to deal with this, but the<br>
> impact on ops folk isn't so small. There are basically two routes that<br>
> I can see:<br>
><br>
> # A<br>
>  - we have a reference layout - install from OpenStack git / pypi<br>
> releases; this is what we will gate on, and can document.<br>
>  - and then each distro (both flavor of Linux and also possibly things<br>
> like Fuel that distribution OpenStack) is different - install on X,<br>
> get some delta vs reference.<br>
<br>
</div>So far I think the delta is: service name and user account names. You<br>
mention install paths below, but I'll reply to that there.<br>
<br>
For service names, I think we already have a solution with the<br>
os-svc-* tools. We're going to need tools like those anyway just to<br>
account for system service name differences. We might as well tell<br>
people to use them for the OpenStack services too.<br>
<br>
For user account names, we don't have a great solution for this yet.<br>
<div class=""><br>
>  -> we need multiple manuals describing how to operate and diagnose<br>
> issues in such a deployment, which is a matrix that overlays platform<br>
> differences the user selects like 'Fedora' and 'Xen'.<br>
<br>
</div>I think the delta is rather small, and I don't think that it's<br>
necessarily TripleO's job to document it all. We have the reference<br>
layout and that's what should be documented well. People who choose to<br>
use packages know that they're doing so. In fact they are likely doing<br>
so b/c they want the defined and consistent patterns they're used to.<br>
They don't want every OpenStack service running in its own virtualenv<br>
with dependencies duplicated across them. That's why they're using to<br>
choose packages. They've deviated from the reference, that's Ok IMO.<br>
<div class=""><br>
> # B<br>
>  - we have one layout, with one set of install paths, usernames<br>
<br>
</div>I'm actually not clear what you mean by install paths. Do you mean the<br>
execution path to get stuff installed? Or where stuff ends up on the<br>
actual filesystem?<br>
<br>
Assuming you mean the latter, e.g., moving files that were installed<br>
by a package under /opt/stack so the package install is the same as<br>
the source install, I think that's a bit counter-intuitive to one of<br>
the reasons people might be using packages to begin with.<br>
<br>
Like I mentioned, one of the reasons that people  want to use packages<br>
is for the consistent patterns they provide.  Moving python code out<br>
from underneath site-packages so that it's all under /opt/stack even<br>
for a packaged install makes the documentation worse IMO. We'd have to<br>
document everything we've done to change the package, b/c we've undone<br>
what people expect. That goes against the principle of least surprise,<br>
b/c people who use packages, are expecting (and I suspect wanting)<br>
stuff to end up where the package puts it.<br>
<div class=""><br>
>  - package installs vs source installs make no difference - we coerce<br>
> the package into reference upstream shape as part of installing it.<br>
<br>
</div>We could document the reference and it would apply to everything. But,<br>
I don't think the problem is solved. We would need to add<br>
documentation for stuff like:<br>
- your package manager is now going to complain about this set of<br>
things, which you are safe to ignore<br>
- your package dependencies aren't going to be reported correctly<br>
- probably more<br>
<div class=""><br>
>  - documentation is then identical for all TripleO installs, except<br>
> the platform differences (as above - systemd on Fedora, upstart on<br>
> Ubuntu, Xen vs KVM)<br>
<br>
</div>If we didn't do B, I think the documentation is still mostly<br>
identical. IMO, it's not up to TripleO to document how rpm's install<br>
OpenStack or how debs install OpenStack, or how Fuel does it.<br>
<div class=""><br>
> B seems much more useful to our ops users - less subtly wrong docs, we<br>
> avoid bugs where tools we write upstream make bad assumptions,<br>
> experience operating a TripleO deployed OpenStack is more widely<br>
> applicable (applies to all such installs, not just those that happened<br>
> to use the same package source).<br>
<br>
</div>Personally, I think B is much less useful to operators. But, I'm not<br>
actually an operator :-).<br>
<br>
However, if I were, and I used TripleO with package based installs,<br>
and TripleO moved everything around and undid much of what the package<br>
was laying down, I would find that extremely frustrating and not<br>
useful at all.<br>
<br>
Keep in mind I'm not talking about doing configuration changes, which<br>
I think are well within the scope of stuff TripleO should do. But most<br>
(if not all) package managers allow and support configuration changes<br>
to config files without complaining.<br>
<br>
All that being said, assuming if we go with "A", I think we could<br>
likely come up with some more elegant solutions to account for some of<br>
the differences in the package and source installs. It's mostly<br>
procedural at the moment handled by if/else's. I'm sure we could come<br>
up with something a bit more declarative to minimize the pain.<br>
<br>
In fact, you're pretty much going to need the same code to exist<br>
whether we go with A or B, it's just whether that code accounts for<br>
the differences that exist, or attempts to reconcile them. Either way,<br>
we have to express the differences.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
-- James Slagle<br>
--<br>
</font></span><div class="HOEnZb"><div class="h5"><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" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br></div>