Open Stack

Hello Alex!

On Mon, Nov 9, 2015 at 9:29 PM, Alex Schultz <aschultz at mirantis.com> wrote:

> Hey folks,
>
> I'm testing[0] out flipping our current method of consuming upstream
> puppet modules from using pinned versions hosted on fuel-infra to be
> able to use the ones directly from upstream (master).  This work is
> primarily to be closer aligned with the other OpenStack projects as
> well as switching the current way we manage Fuel into a downstream of
> the upstream community version. As part of this work we have also been
> working towards improving the upstream modules support different
> package sets.  Specifically running Debian packages on Ubuntu[1][2].
> This work is the start of being able to allow a user of Fuel to be
> able to specify a specific package set and having it be able to work.
> If we can properly split out the puppet modules and package
> dependencies this will make Fuel a more flexible deployment engine as
> I believe we would be better positioned to support multiple versions
> of OpenStack for a given Fuel release.
>
> I'm currently working to get a PoC of Fuel consuming upstream puppet
> modules and the UCA packages together and documenting all of the
> issues so that we can address them.  So far I have been able to deploy
> the upstream modules via a custom ISO using the MOS package set and it
> works locally. Unfortunately the CI seems to be hitting some issues
> that I think might be related to recently merged keystone changes but
> I did not run into the same problem when running a manual deployment.
> As I work through this PoC, I'm also attempting to develop a small
> plugin that could be used to capture the work arounds to the
> deployment process. I've run into a few issues so far as I work to
> switch out the package sets.
>
> For the sake of providing additional visibility into this work, here
> are the issues that I've hit so far.
>
> The first issue I ran across is that currently the MOS repositories
> contain packages for both OpenStack and other system dependencies for
> creating our HA implementation.  This is problematic when we want to
> switch out the OpenStack packages but still want the MOS packages for
> our HA items.  I'm working around this by adding the UCA repository as
> a higher priorities for deployments.  As such I've run into an issue
> with the haproxy package that MOS provides vs the upstream Ubuntu
> package.  To get around this, I've pinned the MOS version for now
> until I can circle back around and figure out if the difference is a
> config or functionality issue.
>

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.
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].

HTH,
Simon

[0] http://marc.info/?l=haproxy&m=130817444025140&w=2


>
> The second issue that I have run across is that we are appending
> read_timeout=60 to our mysql connection strings for our
> configurations. This seems to be unsupported by the libraries and
> OpenStack components provided by the UCA package set.  I'm not sure
> how the priority of python-pymsql vs python-mysqldb is resolved as I
> had both packages installed but it continued to fail on read_timeout
> being in the connection string.  For now I've updated the fuel-library
> code to remove this item from the connection strings and will be
> circling back around to figure out the correct 'fix' for this issue.
>
> I'm hoping to be able to have a working ISO, plugin and a set of
> instructions that can be used to deploy a basic cloud using Fuel by
> the end of this week.
>
> Thanks,
> -Alex
>
> [0] https://review.openstack.org/#/c/240325/
> [1] https://review.openstack.org/#/c/241615/
> [2] https://review.openstack.org/#/c/241741/
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151110/7ca96f1b/attachment.html>