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
