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 <spasqu...@mirantis.com> wrote: > Hello Alex! > > On Mon, Nov 9, 2015 at 9:29 PM, Alex Schultz <aschu...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
