Open Stack

Alex

That's great to hear that. But be aware - making all of the components work
exactly the way they work within MOS is actually identical to upstreaming
MOS. We are using some components of different versions to satisfy many
requirements for our Reference Architecutre implementation. It will not be
so easy to base them upon existing 3rd party distributions. For example,
`read timeout` for SQL requests is crucial for our HA as it handles cases
when an SQL node dies while serving the request. And you will find myriads
of them. And as we do not control things in upstream, we will always have
some downstream divergence.

I guess, the optimal solution is to figure out the actual divergence
between upstream and downstream and try to push things upstream as hard as
we can, while retaining overrides for some packages and manifests on top of
upstream versions. Do not get me wrong, but it seems there is exactly 0
(zero) ways you can get Fuel working with upstream packages unless they
support exactly the same feature set and fix the same bugs in various
components that Fuel expect them to support or fix. By 'working' I mean
passing the same set of at least smoke and destructive tests, let alone
passing scale tests.

Simon

AFAIK, this patch is really simple and can be easily applied to any version
of HAProxy. So it is not too hard handle it while it provides sufficient
benefits to our deployment engineers. If you have any better solution,
please feel free to share the code with us.

On Tue, Nov 10, 2015 at 12:54 PM, Stanislaw Bogatkin <sbogatkin at mirantis.com
> wrote:

> 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
>>
>>
>
> __________________________________________________________________________
> 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
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151110/81cc9d25/attachment.html>