<div dir="ltr">Alex<div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Simon</div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 12:54 PM, Stanislaw Bogatkin <span dir="ltr"><<a href="mailto:sbogatkin@mirantis.com" target="_blank">sbogatkin@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Simon,<div><br></div><div>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.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 12:20 PM, Simon Pasquier <span dir="ltr"><<a href="mailto:spasquier@mirantis.com" target="_blank">spasquier@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello Alex!<br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>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></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" target="_blank">http://marc.info/?l=haproxy&m=130817444025140&w=2</a><br></div><span><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></span></div><br></div></div>
<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>
<br></blockquote></div><br></div>
</div></div><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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>35bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div>