Open Stack

Hi Simon,

using 'include' in HAProxy is damn conveniently, I don't think it should
die. There is just one way I know to use haproxy with several different
conf's - to construct looooooooooong command line with all of them - and
it's really inconvenient.

On Tue, Nov 10, 2015 at 12:20 PM, Simon Pasquier <spasquier at mirantis.com>
wrote:

> 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
>>
>
>
> __________________________________________________________________________
> 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/7f9af0f4/attachment.html>