<div><span style="color: rgb(160, 160, 168);">On Thursday, February 13, 2014 at 1:27 PM, Robert Collins wrote:</span></div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>So progressing with the 'and folk that want to use packages can' arc,</div><div>we're running into some friction.</div><div><br></div><div>I've copied -operators in on this because its very relevant IMO to operators :)</div><div><br></div><div>So far:</div><div> - some packages use different usernames</div><div> - some put things in different places (and all of them use different</div><div>places to the bare metal ephemeral device layout which requires</div><div>/mnt/).</div><div> - possibly more in future.</div><div><br></div><div>Now, obviously its a 'small matter of code' to deal with this, but the</div><div>impact on ops folk isn't so small. There are basically two routes that</div><div>I can see:</div><div><br></div><div># A</div><div> - we have a reference layout - install from OpenStack git / pypi</div><div>releases; this is what we will gate on, and can document.</div><div> - and then each distro (both flavor of Linux and also possibly things</div><div>like Fuel that distribution OpenStack) is different - install on X,</div><div>get some delta vs reference.</div><div> -> we need multiple manuals describing how to operate and diagnose</div><div>issues in such a deployment, which is a matrix that overlays platform</div><div>differences the user selects like 'Fedora' and 'Xen'.</div><div><br></div><div># B</div><div> - we have one layout, with one set of install paths, usernames</div><div> - package installs vs source installs make no difference - we coerce</div><div>the package into reference upstream shape as part of installing it.</div><div> - documentation is then identical for all TripleO installs, except</div><div>the platform differences (as above - systemd on Fedora, upstart on</div><div>Ubuntu, Xen vs KVM)</div><div><br></div><div>B seems much more useful to our ops users - less subtly wrong docs, we</div><div>avoid bugs where tools we write upstream make bad assumptions,</div><div>experience operating a TripleO deployed OpenStack is more widely</div><div>applicable (applies to all such installs, not just those that happened</div><div>to use the same package source).</div><div><br></div><div>I see this much like the way Nova abstracts out trivial Hypervisor</div><div>differences to let you 'nova boot' anywhere, that we should be hiding</div><div>these incidental (vs fundamental capability) differences.</div></div></div></span></blockquote><div>I personally like B. In the OpenStack Chef community, there has been quite a bit of excitement over the work that Craig Tracey has been doing with omnibus-openstack [1]. It is very similar to B, however, it builds a super package per distro, with all dependencies into a known location (e.g. /opt/openstack/).</div><div><br></div><div>Regardless of how B is ultimately implemented, I personally like the suggestion.</div><div><br></div><div>[1] https://github.com/craigtracey/omnibus-openstack</div><div><div></div></div><div><br></div><div>John</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><div>What say ye all?</div><div><br></div><div>-Robv</div><div><br></div><div><br></div><div>-- </div><div>Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>></div><div>Distinguished Technologist</div><div>HP Converged Cloud</div><div><br></div><div>_______________________________________________</div><div>OpenStack-operators mailing list</div><div><a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a></div><div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>