<div dir="ltr">Hello Alex!<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 9, 2015 at 9:29 PM, Alex Schultz <span dir="ltr"><<a href="mailto:aschultz@mirantis.com" target="_blank">aschultz@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey folks,<br>
<br>
I'm testing[0] out flipping our current method of consuming upstream<br>
puppet modules from using pinned versions hosted on fuel-infra to be<br>
able to use the ones directly from upstream (master). This work is<br>
primarily to be closer aligned with the other OpenStack projects as<br>
well as switching the current way we manage Fuel into a downstream of<br>
the upstream community version. As part of this work we have also been<br>
working towards improving the upstream modules support different<br>
package sets. Specifically running Debian packages on Ubuntu[1][2].<br>
This work is the start of being able to allow a user of Fuel to be<br>
able to specify a specific package set and having it be able to work.<br>
If we can properly split out the puppet modules and package<br>
dependencies this will make Fuel a more flexible deployment engine as<br>
I believe we would be better positioned to support multiple versions<br>
of OpenStack for a given Fuel release.<br>
<br>
I'm currently working to get a PoC of Fuel consuming upstream puppet<br>
modules and the UCA packages together and documenting all of the<br>
issues so that we can address them. So far I have been able to deploy<br>
the upstream modules via a custom ISO using the MOS package set and it<br>
works locally. Unfortunately the CI seems to be hitting some issues<br>
that I think might be related to recently merged keystone changes but<br>
I did not run into the same problem when running a manual deployment.<br>
As I work through this PoC, I'm also attempting to develop a small<br>
plugin that could be used to capture the work arounds to the<br>
deployment process. I've run into a few issues so far as I work to<br>
switch out the package sets.<br>
<br>
For the sake of providing additional visibility into this work, here<br>
are the issues that I've hit so far.<br>
<br>
The first issue I ran across is that currently the MOS repositories<br>
contain packages for both OpenStack and other system dependencies for<br>
creating our HA implementation. This is problematic when we want to<br>
switch out the OpenStack packages but still want the MOS packages for<br>
our HA items. I'm working around this by adding the UCA repository as<br>
a higher priorities for deployments. As such I've run into an issue<br>
with the haproxy package that MOS provides vs the upstream Ubuntu<br>
package. To get around this, I've pinned the MOS version for now<br>
until I can circle back around and figure out if the difference is a<br>
config or functionality issue.<br></blockquote><div><br></div><div>I know at least for one difference between the MOS and Ubuntu versions: HAProxy from MOS has a patch to support the "include" configuration parameter.<br></div><div>This is unrelated to your mail but I think this fork should die since it will never be accepted upstream and there are other ways to address the use case [0].<br><br>HTH,<br>Simon<br><br>[0] <a href="http://marc.info/?l=haproxy&m=130817444025140&w=2">http://marc.info/?l=haproxy&m=130817444025140&w=2</a><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>
The second issue that I have run across is that we are appending<br>
read_timeout=60 to our mysql connection strings for our<br>
configurations. This seems to be unsupported by the libraries and<br>
OpenStack components provided by the UCA package set. I'm not sure<br>
how the priority of python-pymsql vs python-mysqldb is resolved as I<br>
had both packages installed but it continued to fail on read_timeout<br>
being in the connection string. For now I've updated the fuel-library<br>
code to remove this item from the connection strings and will be<br>
circling back around to figure out the correct 'fix' for this issue.<br>
<br>
I'm hoping to be able to have a working ISO, plugin and a set of<br>
instructions that can be used to deploy a basic cloud using Fuel by<br>
the end of this week.<br>
<br>
Thanks,<br>
-Alex<br>
<br>
[0] <a href="https://review.openstack.org/#/c/240325/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/240325/</a><br>
[1] <a href="https://review.openstack.org/#/c/241615/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/241615/</a><br>
[2] <a href="https://review.openstack.org/#/c/241741/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/241741/</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>