Re: [openstack-dev] [puppet] proposal to create puppet-neutron-core and add Sergey Kolekonov

[Alex Schultz]

+1

On Fri, Mar 4, 2016 at 10:07 AM, Matt Fischer  wrote:

> +1 from me!
>
> gmail/openstack-dev is doing its thing where I see your email 4 hours
> before Emilien's original, so apologies for the reply ordering
>
> On Fri, Mar 4, 2016 at 8:49 AM, Cody Herriges  wrote:
>
>> Emilien Macchi wrote:
>> > Hi,
>> >
>> > To scale-up our review process, we created pupept-keystone-core and it
>> > worked pretty well until now.
>> >
>> > I propose that we continue this model and create puppet-neutron-core.
>> >
>> > I also propose to add Sergey Kolekonov in this group.
>> > He's done a great job helping us to bring puppet-neutron rock-solid for
>> > deploying OpenStack networking.
>> >
>> > http://stackalytics.com/?module=puppet-neutron=marks
>> > http://stackalytics.com/?module=puppet-neutron=commits
>> > 14 commits and 47 reviews, present on IRC during meetings & bug triage,
>> > he's always helpful. He has a very good understanding of Neutron &
>> > Puppet so I'm quite sure he would be a great addition.
>> >
>> > As usual, please vote!
>>
>> +1 from me.  Excited to continue seeing neutron get better.
>>
>> --
>> Cody
>>
>>
>> __
>> 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

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

[Alex Schultz]

On Thu, Mar 3, 2016 at 7:19 AM, Matthew Mosesohn  wrote:
>
> Hi Fuelers,
>
> I would like to bring your attention a dilemma we have here. It seems
> that there is a dispute as to whether we should maintain the releases
> list for example plugins[0]. In this case, this is for adding version
> 9.0 to the list.
>
> Right now, we run a swarm test that tries to install the example
> plugin and do a deployment, but it's failing only for this reason. I
> should add that this is the only automated daily test that will verify
> that our plugin framework actually works. During the Mitaka
> development  cycle, we already had an extended period where plugins
> were broken[1]. Removing this test (or leaving it permanently red,
> which is effectively the same), would raise the risk to any member of
> the Fuel community who depends on plugins actually working.
>

IMHO we need to fix the plugins and this should just be part of the
basic maintenance of the plugins for each release cycle. These are
effectively documentation that needs to be updated on a regular basis
and should not be let to go stale.  Integrating with fuel and plugins
is already a complex task so having something that can be used as an
example is very important from an end user experiance standpoint.

>
> The other impact of abandoning maintenance of example plugins is that
> it means that a given interested Fuel Plugin developer would not be
> able to easily get started with plugin development. It might not be
> inherently obvious to add the current Fuel release to the
> metadata.yaml file and it would likely discourage such a user. In this
> case, I would propose that we remove example plugins from fuel-plugins
> GIT repo if they are not maintained. Non-functioning code is worse
> than deleted code in my opinion.
>
> Please share your opinions and let's decide which way to go with this bug[2]
>
> [0] https://github.com/openstack/fuel-plugins/tree/master/examples
> [1] https://bugs.launchpad.net/fuel/+bug/1544505
> [2] https://launchpad.net/bugs/1548340
>
> Best Regards,
> Matthew Mosesohn
>
> __
> 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

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

[Alex Schultz]

+1

On Wed, Feb 24, 2016 at 5:50 AM, Vladimir Kuklin 
wrote:

> Fellow Fuelers
>
> I would like to kindly ask you to consider voting for Matthew Mosesohn as
> a Fuel Library Core
> reviewer.
>
> Matthew has been working with Fuel since its inception, worked on
> countless amount of features, such as :
>
> Master Node Upgrades and Backup
> Improvements to Fuel Infra
> Mitaka, Kilo and Juno Support
> Detachable Services Plugins
> RHOS Support in Fuel
> UCA Support
> Refactoring of Haproxy and Firewall pieces
>
> He has also been known as our Fuel Master node and Docker guru and has
> been continuously working on bugfixing where he scores as a bug squashing
> monster with more than 150 bugfixes to all the parts of Fuel Library (#1
> throughout FL history).
>
> As you can see, there is not a piece of Fuel Library that he has not yet
> gained experience with.
>
> And this can easily be fetched with simple statistics of Matt's
> contribution. He is the topmost contributor to all Fuel projects among all
> Fuel Library folks and is the 3rd contributor of Fuel Library.
> He also reviews a lot and has a fair amount of -1's (he is not as cruel as
> me, though :-))
>
> Having that said, I would like to open the vote to promote Matt to
> OpenStack Fuel Library core reviewers.
>
> --
> 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 
> www.mirantis.ru
> vkuk...@mirantis.com
>
> __
> 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

Re: [openstack-dev] [puppet] is puppet-keystone using v3 credentials correctly ?

[Alex Schultz]

On Tue, Feb 23, 2016 at 1:48 AM, Ptacek, MichalX 
wrote:

> Hello again,
>
>
>
> In last days I realized that rpm/deb packages from supported platforms are
> too old (OSC, python-PROJECTclient,….)
>
> so I suppose that I should install newer versions not via deb/rpm packages
> but as pip packages.
>
> This kind of dependency on system packages when trying to install v7
> openstack puppet modules is probably natural for more experienced puppet
> guys,
>
> but I think it should be covered somewhere in doc.
>
>
>

So for our testing we're using the RDO or UCA package sets for the
releases.  Unfortunately you need to have a matching set of packages and
puppet modules for everything to work. What you're running into is trying
to use distro provide packages (probably for kilo or older) with manifests
that were written for something much newer like Liberty or Mitaka.  We do
have a module[0] that can help pull in these newer repos when you're
setting up your system.  You shouldn't pip install anything but rather
leverage the matching package set for the version of OpenStack you are
trying to deploy.




> I suppose I should install openstack clients as pip packages instead …
>
> Like. pip install python-openstackclient==2.0.0, pip install
> python-keystoneclient, …
>
>
>
> by installing them in this way, manifest deployment finished smoothly, but
> I realized that “missing rpm/deb packages” are also installed (even when
> pip version is present),
>
> which might lead to some inconsistency …
>
>
>
> like currently I am fighting with some issue on glance:
>
> ERROR glance.common.config [-] Unable to load glance-api-keystone from
> configuration  file /etc/glance/glance-api-paste.ini.
>
> Got: ImportError(‘No module named middleware.auth_token’),
>
> (I think it’s asking for this file
>
> /usr/lib/python2.7/dist-packages/keystoneclient/middleware
>
> Which is present on the system)
>
>
>
> so my small and general question would be …
>
> What is the procedure if one would like to work with liberty openstack on
> old/supported platform  ?
>
> (currently I am using Ubuntu 14.04 LTS)
>
>
>

For this configuration you'd want ot use the Liberty UCA package set[1]
with 14.04 and it should work.

Thanks,
-Alex

[0] http://git.openstack.org/cgit/openstack/puppet-openstack_extras
[1] https://wiki.ubuntu.com/ServerTeam/CloudArchive



Thanks,
>
> Michal
>
>
>
>
>
> *From:* Ptacek, MichalX [mailto:michalx.pta...@intel.com]
> *Sent:* Monday, February 22, 2016 9:50 AM
>
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [puppet] is puppet-keystone using v3
> credentials correctly ?
>
>
>
> Hi Matt,
>
>
>
> thanks for good hint !
>
> Issue disappeared with newer python-openstackclient-1.0.3-3.fc23.noarch
>
> python-openstackclient-1.0.1-1.fc22.noarch is too old,
>
>
>
> it’s interesting, as supported platforms for puppet-openstack is
> fedora21,22 and I get it running just with fc23 J
>
>
>
> best regards,
>
> Michal
>
>
>
> *From:* Matt Fischer [mailto:m...@mattfischer.com ]
> *Sent:* Friday, February 19, 2016 4:27 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [puppet] is puppet-keystone using v3
> credentials correctly ?
>
>
>
> You shouldn't have to do any of that, it should just work. I have OSC
> 2.0.0 in my environment though (Ubuntu). I'm just guessing but perhaps that
> client is too old? Maybe a Fedora user could recommend a version.
>
>
>
> On Fri, Feb 19, 2016 at 7:38 AM, Matthew Mosesohn 
> wrote:
>
> Hi Michal,
>
> Just add --os-identity-api-version=3 to your command it will work. The
> provider uses v3 openstackclient via env var
> OS_IDENTITY_API_VERSION=3. The default is still 2.
>
> Best Regards,
> Matthew Mosesohn
>
>
> On Fri, Feb 19, 2016 at 5:25 PM, Matt Fischer 
> wrote:
> > What version of openstack client do you have? What version of the module
> are
> > you using?
> >
> > On Feb 19, 2016 7:20 AM, "Ptacek, MichalX" 
> wrote:
> >>
> >> Hi all,
> >>
> >>
> >>
> >> I was playing some time with puppet-keystone deployments,
> >>
> >> and also reported one issue related to this:
> >>
> >> https://bugs.launchpad.net/puppet-keystone/+bug/1547394
> >>
> >> but in general my observations are that keystone_service is using v3
> >> credentials with openstack cli commands that are not compatible
> >>
> >>
> >>
> >> e.g.
> >>
> >> Error: Failed to apply catalog: Execution of '/bin/openstack service
> list
> >> --quiet --format csv --long' returned 2: usage: openstack service list
> [-h]
> >> [-f {csv,table}] [-c COLUMN]
> >>   [--max-width ]
> >>   [--quote {all,minimal,none,nonnumeric}]
> >> openstack service list: error: unrecognized arguments: --long
> >>
> >>

Re: [openstack-dev] [puppet] how to run rspec tests? r10k issue

[Alex Schultz]

On Thu, Feb 18, 2016 at 3:26 PM, Matt Fischer  wrote:

> Is anyone able to share the secret of running spec tests since the r10k
> transition? bundle install && bundle exec rake spec have issues because
> r10k is not being installed. Since I'm not the only one hopefully this
> question will help others.
>
> +
> PUPPETFILE=/etc/puppet/modules/keystone/openstack/puppet-openstack-integration/Puppetfile
> + /var/lib/gems/1.9.1/bin/r10k puppetfile install -v
> /etc/puppet/modules/keystone/openstack/puppet-openstack-integration/functions:
> line 51: /var/lib/gems/1.9.1/bin/r10k: No such file or directory
> rake aborted!
>

I assume you were trying to run the tests on the keystone module so it
should have been installed with the bundle install as it is listed in the
Gemfile[0].  Are you sure your module is up to date?

-Alex

[0] https://github.com/openstack/puppet-keystone/blob/master/Gemfile#L26


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

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

[Alex Schultz]

On Thu, Feb 18, 2016 at 4:00 AM, Aleksandr Didenko 
wrote:

> > Given the requirements to be able to use new features in fuel, with an
> older version of OpenStack, what alternative would you propose?
>
> For example, it's possible to use existing "release" functionality in Fuel
> (release contains granular tasks configuration, puppet modules and
> manifests, configuration data). So after upgrade from 8.0 to 9.0 it will
> look like this [0] - with separate composition layer for every supported
> "release".
>
> > We should allow a user to specify that they want a build a cloud using X
> fuel release to deploy Y os with Z OpenStack release.
>
> [0] should work for this as well. But the number of X-Y-Z combinations
> will be limited. Well, it will be limited in any case, I don't think that
> it's possible to support unlimited number of OpenStack versions in a single
> Fuel release.
>
>
I agree it should not be unlimited but it should be created than the 1-1-1
we currently support.  Since we push for upstream openstack puppet to
support current and best effort on current-1, I think being able to support
at least that should be doable.


> In case we want to use single composition layer for more than one
> openstack version, we need to resolve the following blockers:
> - Move everything except composition layer (top-scope manifests and other
> granular tasks) from fuel-library to their own repos. Otherwise we'll have
> OpenStack version conditionals in modules manifets, providers and functions
> which would be a mess.
> - Refactor tasks upload/serialization in Nailgun
> - (?) Refactor configuration data serialization in Nailgun
>
> And still we'll have to add conditionals to puppet functions that relay on
> configuration data directly (like generate_network_config.rb). Or write
> some sort of data serialization in front of them in manifests. Or leave
> nailgun serialization based on installed version (which is almost the same
> as using separate composition layers [0]).
>
> In either case (separate releases or single composition layer) it will
> double CI load and testing efforts, because we need to CI/test new features
> and patches for 9.0+mitaka and 9.0+liberty.
>
> Regards,
> Alex
>
> [0] http://paste.openstack.org/show/487383/
>
>
> On Thu, Feb 18, 2016 at 9:31 AM, Bogdan Dobrelya 
> wrote:
>
>> On 17.02.2016 18:23, Bogdan Dobrelya wrote:
>> >> So we'll have tons of conditionals in composition layer, right? Even if
>> >> some puppet-openstack class have just one new parameter in new release,
>> >> then we'll have to write a conditional and duplicate class
>> declaration. Or
>> >> write complex parameters hash definitions/merges and use
>> >> create_resources(). The more releases we want to support the more
>> >> complicated composition layer will become. That won't make
>> contribution to
>> >> fuel-library easier and even can greatly reduce development speed.
>> Also are
>> >> we going to add new features to stable releases using this workflow
>> with
>> >> single composition layer?
>> >
>> > As I can see from an example composition [0], such code would be an
>> > unmaintainable burden for development and QA process. Next imagine a
>> > case for incompatible *providers* like network transformations - shall
>> > we put multiple if/case to the ruby providers as well?..
>> >
>> > That is not a way to go for a composition, sorry. While the idea may be
>> > doable, I agree, but perhaps another way.
>> >
>> > (tl;dr)
>> > By the way, this reminded me "The wrong abstraction" [1] article and
>> > discussion. I agree with the author and believe one should not group
>> > code (here it is versioned puppet modules & compositions) in a way which
>> > introduces abstractions (here a super-composition) with multiple
>> > if/else/case and hardcoded things to switch the execution flow based on
>> > version of things. Just keep code as is - partially duplicated by
>> > different releases in separate directories with separate modules and
>> > composition layers and think of better solutions please.
>> >
>> > There is also a nice comment: "...try to optimize my code around
>> > reducing state, coupling, complexity and code, in that order". I
>> > understood that like a set of "golden rules":
>> > - Make it coupled more tight to decrease (shared) state
>> > - Make it more complex to decrease coupling
>> > - Make it duplicated to decrease complexity (e.g. abstractions)
>> >
>> > (tl;dr, I mean it)
>> > So, bringing those here.
>> > - The shared state is perhaps the Nailgun's world view of all data and
>> > versioned serializers for supported releases, which know how to convert
>> > the only latest existing data to any of its supported previous versions.
>> > - Decoupling we do by putting modules with its compositions to different
>> > versioned /etc/puppet subdirectories. I'm not sure how do we decouple
>> > Nailgun serializers though.
>> > - Complexity is how we compose those 

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

[Alex Schultz]

On Wed, Feb 17, 2016 at 10:23 AM, Bogdan Dobrelya 
wrote:

> > So we'll have tons of conditionals in composition layer, right? Even if
> > some puppet-openstack class have just one new parameter in new release,
> > then we'll have to write a conditional and duplicate class declaration.
> Or
> > write complex parameters hash definitions/merges and use
> > create_resources(). The more releases we want to support the more
> > complicated composition layer will become. That won't make contribution
> to
> > fuel-library easier and even can greatly reduce development speed. Also
> are
> > we going to add new features to stable releases using this workflow with
> > single composition layer?
>
> As I can see from an example composition [0], such code would be an
> unmaintainable burden for development and QA process. Next imagine a
> case for incompatible *providers* like network transformations - shall
> we put multiple if/case to the ruby providers as well?..
>
> That is not a way to go for a composition, sorry. While the idea may be
> doable, I agree, but perhaps another way.
>

So I agree that the provided example isn't exactly the cleanest
implementation but I think the point is that we need to start considering
supporting multiple versions of OpenStack for a given set of fuel-library
manifests. I think the provided example begins to show some issues with the
way we currently structure our modular tasks.  We basically don't have any
organized structure which leads to having to sprinkle random if/elses
throughout the code to try and provide some semblance of backwards
compatibility or deprecation for tasks.  As I see it today in fuel-library
we are too closely tied to the current development version of OpenStack and
with every release we are not providing proper deprecation for
configuration tasks between each release of fuel. I'm sure fuel plugin
developers could probably attest to the amount of pain each release brings
trying to re-reverse engineer the deployment process to see what has
changed.

I think it's unrealistic to expect that all users are going to want the
latest version of OpenStack as soon as it's released. Fuel is
an OpenStack deployment tool, so why can't we deploy different versions
with a single version of fuel?  Technically we should have a way to do with
with releases in Fuel but it seems that we've handicapped any ability to
try and leverage this information to support a different version of
OpenStack.  Much like the UCA work where we started to extract out the
package/repo information, we need to extract out the OpenStack release
information (version/repos/etc). We should allow a user to specify that
they want a build a cloud using X fuel release to deploy Y os with Z
OpenStack release.  If we can't provide this type of flexibility I'm not
seeing why someone would want to use Fuel over their own OS
provisioning+puppet/ansible/chef deployment method.



> (tl;dr)
> By the way, this reminded me "The wrong abstraction" [1] article and
> discussion. I agree with the author and believe one should not group
> code (here it is versioned puppet modules & compositions) in a way which
> introduces abstractions (here a super-composition) with multiple
> if/else/case and hardcoded things to switch the execution flow based on
> version of things. Just keep code as is - partially duplicated by
> different releases in separate directories with separate modules and
> composition layers and think of better solutions please.
>

Completely duplicating the fuel-library for each OpenStack release is
probably even more unmanageable then beginning to structure our composition
layer into something that supports multiple OpenStack resources but I guess
that could be an option...


>
> There is also a nice comment: "...try to optimize my code around
> reducing state, coupling, complexity and code, in that order". I
> understood that like a set of "golden rules":
> - Make it coupled more tight to decrease (shared) state
> - Make it more complex to decrease coupling
> - Make it duplicated to decrease complexity (e.g. abstractions)
>
> (tl;dr, I mean it)
> So, bringing those here.
> - The shared state is perhaps the Nailgun's world view of all data and
> versioned serializers for supported releases, which know how to convert
> the only latest existing data to any of its supported previous versions.
> - Decoupling we do by putting modules with its compositions to different
> versioned /etc/puppet subdirectories. I'm not sure how do we decouple
> Nailgun serializers though.
> - Complexity is how we compose those modules / write logic of serializers.
> - Duplication is puppet classes (and providers) with slightly different
> call parameters from a version to version. Sometimes even not backwards
> compatible. Probably same to the serializers?
>
> So, we're going to *increase complexity* by introducing
> super-compositions for multi OpenStack releases. Not sure about what to
> happen to the 

Re: [openstack-dev] [Fuel][library] relax downstream policy for puppet modules managed by librarian

[Alex Schultz]

On Fri, Jan 29, 2016 at 2:12 AM, Bogdan Dobrelya  wrote:
> This is a continuation of the forked discussion [0].
>
> The idea is to relax Fuel-library downstream policy and implement a
> "lazy downstreaming", which is to not create a downstream fork of a
> puppet module referenced in the librarian Puppetfile unless we have to
> do so.
>

So what exactly would be the change to the policy? Just allowing for
different source git repo?

Currently, we have basically been enforcing the following:
1) requiring a fuel-infra mirror
2) requiring a tag

See https://wiki.openstack.org/wiki/Fuel/Library_and_Upstream_Modules

This is being validated by the verify-fuel-library-puppetfile fuel-ci
job.  See 
https://github.com/openstack/fuel-library/blob/master/utils/jenkins/fuel_validate_puppetfile.rb

If the change you're proposing is to just relax the first requirement,
I could agree with that.  If it's to allow for the relaxing of both,
then no I don't agree. When we first switched to using using a
Puppetfile, we had discussions specifically around the tag requirement
and that is there to ensure that when we build we are always pulling
in the same expected version for every build.  While we could support
a hash instead of a tag, I would prefer that we not do that.

> The relaxed policy would unblock an upstream switching of the rabbitmq
> [1] and corosync [2] modules as well.
>
> Pros:
> - Reduced costs of maintaining downstream forks because of the laziness
> of the forking process. This much better distributes load to Fuel
> engineering and HW resources in time. Even though related tasks may be
> one-time, HW resources and network bandwidth shall not be wasted for
> keeping and cloning unnecessary forks (unless we have no choice but to
> fork things)

We aren't maintaining forks for every module, we are using normal git
sync processes to pull in the tags from the upstream modules as well.
This is completely hands off so we're not managing tags for most
upstream modules, and these days I think we're only creating tags and
managing some minor forks only the openstack modules.  And this is
primarily because the upstream openstack modules do not get new tags
the previous stable versions.  I think we only have maybe 4 commits
that are being maintained across 2 or 3 of the modules? The puppet
guys have a list.  Doing a quick look, it appears we're managing 18
custom tags (13 of which are openstack modules) and relying on 17
upstream tags.

> -  A module might remain as direct upstream reference in the Puppetfile
> for quite a while. This as well shows an amount of the hidden technical
> debt in much more clean representation - downstream vs upstream refs in
> the Puppetfile.

I'm not sure how this is addressed by using the upstream source repo
and a tagged version. This is the same problem with any versions. The
only way this gets fixed is to switch to branches across the board and
deal with the changes that pop up or have a periodic job that tests
this. But this completely violates what we agreed to when we switched
to librarian in the first place.

> - Some generic, non OpenStack puppet modules will barely require
> backporting of separate patches by older tags as they work just
> straightforward and the latest version works for every supported Fuel
> release as well. Those would save resources because of the laziness of
> the relaxed process will never require to create downstream forks for
> such modules!

What resources are we saving?  We don't create forks unless we need
to. We're using tags, it's just that the git repo is not the original
source because of the policy we put in place when we switched to
librarian.  And like I said, I'm a little more flexible on that part.

>
> Cons:
> - I see none. For "unlucky" modules, the *same* amount of work shall be
> done anyway, although with the lazy process in place it will be
> distributed in time much better.
>

A large con is that we're moving the work of creating a mirror (not
necessarily a fork as you call it), from the front of the dev cycle
when we have more time to the end where we're in a pinch because we've
run across something that evidently needs to be fixed asap.  Getting a
mirror created is currently just a ticket to fuel-infra...

As I've stated multiple times now, I tend to agree with the premise of
this proposal but it needs to be thought out and well defined as to
what we are expecting and what should be enforced. Today we have a
process that is 1) documented, 2) tested in CI, and 3) has workflows
and infrastructure to support it. I'd like to see more concrete
details on what changes you're proposing and make sure we properly
understand the impact from these changes as part of the development
process.

The reason why in the previous thread I mentioned the
upstream/downstream items needs to be solidified before this policy
change is that I believe the current policy should turn into the
downstream policy and the upstream fuel policy 

Re: [openstack-dev] [Fuel] Relieving CI/gate jenkins bottleneck

[Alex Schultz]

r vintage
>> >> lovers.
>> >>
>> >> BP
>> >>
>> >> On Thu, Jan 21, 2016 at 11:03 AM, Aleksandr Didenko
>> >> <adide...@mirantis.com <mailto:adide...@mirantis.com>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> > I also think 3.3 is the version that ships with 14.04.
>> >>
>> >> 3.4.3 is shipped with Ubuntu-14.04. I think 3.4, 3.8 and 4
>> >> should be enough.
>> >>
>> >> Regards,
>> >> Alex
>> >>
>> >> On Wed, Jan 20, 2016 at 6:38 PM, Sergii Golovatiuk
>> >> <sgolovat...@mirantis.com
>> >> <mailto:sgolovat...@mirantis.com>>
>> >> wrote:
>> >>
>> >> +1 for 3.3, 3.4, 3.8 and 4
>> >>
>> >>
>> >> --
>> >> Best regards,
>> >> Sergii Golovatiuk,
>> >> Skype #golserge
>> >> IRC #holser
>> >>
>> >> On Wed, Jan 20, 2016 at 6:12 PM, Alex Schultz
>> >> <aschu...@mirantis.com <mailto:aschu...@mirantis.com>>
>> >> wrote:
>> >>
>> >> On Wed, Jan 20, 2016 at 9:02 AM, Matthew Mosesohn
>> >> <mmoses...@mirantis.com
>> >> <mailto:mmoses...@mirantis.com>> wrote:
>> >> > Hi all,
>> >> >
>> >> > Unit tests on CI and gate bottleneck are really
>> >> slowing down commit
>> >> > progress. We recently had a meeting to discuss
>> >> possible ways to improve
>> >> > this, including symlinks, caching git
>> >> repositories, etc, but one thing we
>> >> > can do much faster is to simply disable 3.3-3.7
>> >> puppet jobs. We don't deploy
>> >> > Fuel 9.0 (or 8.0) on earlier Puppet versions, so
>> >> what value is there to the
>> >> > checks? I propose we remove these tests, and
>> >> hopefully we will see some
>> >> > immediate relief.
>> >> >
>> >>
>> >> How about we reduce to 3.3, 3.4, 3.8 and 4?  We
>> >> would remove  3.6 and
>> >> 3.7 which would reduce the number of jobs by a
>> >> third  The goal of
>> >> keeping the others was to ensure that if/when we
>> >> are
>> >> able to install
>> >> fuel-library without our version of puppet that a
>> >> user could use
>> >> whatever version their environment has. There were
>> >> some changes
>> >> between 3.3 and 3.4 (if I remember correctly) so we
>> >> should keep
>> >> checking that as it's also the oldest version
>> >> supported by the
>> >> upstream puppet openstack modules.  I also think
>> >> 3.3
>> >> is the version
>> >> that ships with 14.04.  Additionally we used 3.4 in
>> >> fuel 7 and below
>> >> so we should keep those around.
>> >>
>> >> -Alex
>> >>
>> >> > Best Regards,
>> >> > Matthew Mosesohn
>> >> >
>> >> >
>> >>
>> >> __
>> >> > OpenStack Development Mailing List (not for usage
>> >> questions)
>> >> > Unsubscribe:
>> >>
>> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >>
>> >> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>> >> >
&

Re: [openstack-dev] [Fuel][Plugins] Tasks ordering between plugins

[Alex Schultz]

On Jan 27, 2016 4:58 PM, "Andrew Woodward"  wrote:
>
> Simon, you should use the deployment_tasks.yaml interface (which will
likely eventually move to '*/tasks.yaml' (to mimic library) This uses the
same task system as granular deploy. you can set task ordering between
known tasks and roles names, in the case that they are not registered they
will simply be ignored.
>
> The result will be that the engine will parse out the precise location
for tasks to run in the graph (you can run outside of the post-deployment
with them). In most cases, you will not need to specify precise ordering
between the plugins. I know there is the odd case that two components need
to modify the same parts, there are a couple of ways we can work this out,
but it ultimately will come down to a case-by case until we solidify the
config-db workflow

Kind of along this topic I've actually run into difficulties when trying to
wedge a plugins tasks at the absolute end of a deployment using the
deployment_tasks.yaml. I was only able to get it working reliably by using
the tasks.yaml method. I feel that forcing plugin developers to know what
possible tasks could be executed for all cases puts too much on them since
we don't really supply good ways to get the task lists. It seems like you
basically need to be a fuel dev to understand it. Before we get rid of
tasks.yaml can we provide a mechanism for plugin devs could leverage to
have tasks executes at specific points in the deploy process.  Basically
provide the stage concept from tasks.yaml with documented task anchors? For
my case it would have been nice to be able to pin to run after post
deployment end.

-Alex

>
> On Wed, Jan 27, 2016 at 5:45 AM Simon Pasquier 
wrote:
>>
>> Hi,
>>
>> I see that tasks.yaml is going to be deprecated in the future MOS
versions [1]. I've got one question regarding the ordering of tasks between
different plugins.
>> With tasks.yaml, it was possible to coordinate the execution of tasks
between plugins without prior knowledge of which plugins were installed [2].
>> For example, lets say we have 2 plugins: A and B. The plugins may or may
not be installed in the same environment and the tasks execution should be:
>> 1. Run task X for plugin A (if installed).
>> 2. Run task Y for plugin B (if installed).
>> 3. Run task Z for plugin A (if installed).
>>
>> Right now, we can set task priorities like:
>>
>> # tasks.yaml for plugin A
>> - role: ['*']
>>   stage: post_deployment/1000
>>   type: puppet
>>   parameters:
>> puppet_manifest: puppet/manifests/task_X.pp
>> puppet_modules: puppet/modules
>>
>> - role: ['*']
>>   stage: post_deployment/3000
>>   type: puppet
>>   parameters:
>> puppet_manifest: puppet/manifests/task_Z.pp
>> puppet_modules: puppet/modules
>>
>> # tasks.yaml for plugin B
>> - role: ['*']
>>   stage: post_deployment/2000
>>   type: puppet
>>   parameters:
>> puppet_manifest: puppet/manifests/task_Y.pp
>> puppet_modules: puppet/modules
>>
>> How would it be handled without tasks.yaml?
>>
>> Regards,
>> Simon
>>
>> [1] https://review.openstack.org/#/c/271417/
>> [2] https://wiki.openstack.org/wiki/Fuel/Plugins#Plugins_deployment_order
>>
__
>> 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
>
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
>
> __
> 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

Re: [openstack-dev] [Fuel][Bugs] Time sync problem when testing.

[Alex Schultz]

On Tue, Jan 26, 2016 at 11:42 AM, Stanislaw Bogatkin
 wrote:
> Hi guys,
>
> for some time we have a bug [0] with ntpdate. It doesn't reproduced 100% of
> time, but breaks our BVT and swarm tests. There is no exact point where
> problem root located. To better understand this, some verbosity to ntpdate
> output was added but in logs we can see only that packet exchange between
> ntpdate and server was started and was never completed.
>

So when I've hit this in my local environments there is usually one or
two possible causes for this. 1) lack of network connectivity so ntp
server never responds or 2) the stratum is too high.  My assumption is
that we're running into #2 because of our revert-resume in testing.
When we resume, the ntp server on the master may take a while to
become stable. This sync in the deployment uses the fuel master for
synchronization so if the stratum is too high, it will fail with this
lovely useless error.  My assumption on what is happening is that
because we aren't using a set of internal ntp servers but rather
relying on the standard ntp.org pools.  So when the master is being
resumed it's struggling to find a good enough set of servers so it
takes a while to sync. This then causes these deployment tasks to fail
because the master has not yet stabilized (might also be geolocation
related).  We could either address this by fudging the stratum on the
master server in the configs or possibly introducing our own more
stable local ntp servers. I have a feeling fudging the stratum might
be better when we only use the master in our ntp configuration.

> As this bug is blocker, I propose to merge [1] to better understanding
> what's going on. I created custom ISO with this patchset and tried to run
> about 10 BVT tests on this ISO. Absolutely with no luck. So, if we will
> merge this, we would catch the problem much faster and understand root
> cause.
>

I think we should merge the increased logging patch anyway because
it'll be useful in troubleshooting but we also might want to look into
getting an ntp peers list added into the snapshot.

> I appreciate your answers, folks.
>
>
> [0] https://bugs.launchpad.net/fuel/+bug/1533082
> [1] https://review.openstack.org/#/c/271219/
> --
> with best regards,
> Stan.
>

Thanks,
-Alex

__
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

Re: [openstack-dev] [Fuel][Bugs] Time sync problem when testing.

[Alex Schultz]

On Tue, Jan 26, 2016 at 2:16 PM, Stanislaw Bogatkin
<sbogat...@mirantis.com> wrote:
> When there is too high strata, ntpdate can understand this and always write
> this into its log. In our case there are just no log - ntpdate send first
> packet, get an answer - that's all. So, fudging won't save us, as I think.
> Also, it's a really bad approach to fudge a server which doesn't have a real
> clock onboard.

Do you have a debug output of the ntpdate somewhere? I'm not finding
it in the bugs or in some of the snapshots for the failures. I did
find one snapshot with the -v change that didn't have any response
information so maybe it's the other problem where there is some
network connectivity isn't working correctly or the responses are
getting dropped somewhere?

-Alex

>
> On Tue, Jan 26, 2016 at 10:41 PM, Alex Schultz <aschu...@mirantis.com>
> wrote:
>>
>> On Tue, Jan 26, 2016 at 11:42 AM, Stanislaw Bogatkin
>> <sbogat...@mirantis.com> wrote:
>> > Hi guys,
>> >
>> > for some time we have a bug [0] with ntpdate. It doesn't reproduced 100%
>> > of
>> > time, but breaks our BVT and swarm tests. There is no exact point where
>> > problem root located. To better understand this, some verbosity to
>> > ntpdate
>> > output was added but in logs we can see only that packet exchange
>> > between
>> > ntpdate and server was started and was never completed.
>> >
>>
>> So when I've hit this in my local environments there is usually one or
>> two possible causes for this. 1) lack of network connectivity so ntp
>> server never responds or 2) the stratum is too high.  My assumption is
>> that we're running into #2 because of our revert-resume in testing.
>> When we resume, the ntp server on the master may take a while to
>> become stable. This sync in the deployment uses the fuel master for
>> synchronization so if the stratum is too high, it will fail with this
>> lovely useless error.  My assumption on what is happening is that
>> because we aren't using a set of internal ntp servers but rather
>> relying on the standard ntp.org pools.  So when the master is being
>> resumed it's struggling to find a good enough set of servers so it
>> takes a while to sync. This then causes these deployment tasks to fail
>> because the master has not yet stabilized (might also be geolocation
>> related).  We could either address this by fudging the stratum on the
>> master server in the configs or possibly introducing our own more
>> stable local ntp servers. I have a feeling fudging the stratum might
>> be better when we only use the master in our ntp configuration.
>>
>> > As this bug is blocker, I propose to merge [1] to better understanding
>> > what's going on. I created custom ISO with this patchset and tried to
>> > run
>> > about 10 BVT tests on this ISO. Absolutely with no luck. So, if we will
>> > merge this, we would catch the problem much faster and understand root
>> > cause.
>> >
>>
>> I think we should merge the increased logging patch anyway because
>> it'll be useful in troubleshooting but we also might want to look into
>> getting an ntp peers list added into the snapshot.
>>
>> > I appreciate your answers, folks.
>> >
>> >
>> > [0] https://bugs.launchpad.net/fuel/+bug/1533082
>> > [1] https://review.openstack.org/#/c/271219/
>> > --
>> > with best regards,
>> > Stan.
>> >
>>
>> Thanks,
>> -Alex
>>
>> __
>> 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
>
>
>
>
> --
> with best regards,
> Stan.
>
> __
> 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-dev] [fuel] facter update has broken fuel-library ci for 3.8

[Alex Schultz]

Hey Folks,

So on Friday our CI unit tests for puppet version 3.8 started
failing[0] due to an update to facter which seems to have issues with
one of our ceph facts[1].  This has blocked up the pipeline, so in
order to unstick it we are looking at updating the ceph
osd_devices_list fact[2] to address the CI failures.  Currently this
issue is preventing the merge of things to address Bug 1533082[3] and
Bug 1536608[4] which block BVT.

Thanks,
-Alex

[0] https://bugs.launchpad.net/fuel/+bug/1537102
[1] https://tickets.puppetlabs.com/browse/FACT-1318
[2] https://review.openstack.org/#/c/271521/
[3] https://bugs.launchpad.net/fuel/+bug/1533082
[4] https://bugs.launchpad.net/fuel/+bug/1536608

__
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

Re: [openstack-dev] [Fuel] Relieving CI/gate jenkins bottleneck

[Alex Schultz]

On Wed, Jan 20, 2016 at 9:02 AM, Matthew Mosesohn
 wrote:
> Hi all,
>
> Unit tests on CI and gate bottleneck are really slowing down commit
> progress. We recently had a meeting to discuss possible ways to improve
> this, including symlinks, caching git repositories, etc, but one thing we
> can do much faster is to simply disable 3.3-3.7 puppet jobs. We don't deploy
> Fuel 9.0 (or 8.0) on earlier Puppet versions, so what value is there to the
> checks? I propose we remove these tests, and hopefully we will see some
> immediate relief.
>

How about we reduce to 3.3, 3.4, 3.8 and 4?  We would remove  3.6 and
3.7 which would reduce the number of jobs by a third  The goal of
keeping the others was to ensure that if/when we are able to install
fuel-library without our version of puppet that a user could use
whatever version their environment has. There were some changes
between 3.3 and 3.4 (if I remember correctly) so we should keep
checking that as it's also the oldest version supported by the
upstream puppet openstack modules.  I also think 3.3 is the version
that ships with 14.04.  Additionally we used 3.4 in fuel 7 and below
so we should keep those around.

-Alex

> Best Regards,
> Matthew Mosesohn
>
> __
> 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

Re: [openstack-dev] [puppet] proposing Alex Schultz part of core team

[Alex Schultz]

On Wed, Jan 6, 2016 at 4:40 PM, Emilien Macchi <emil...@redhat.com> wrote:
>
>
> On 01/05/2016 12:55 PM, Emilien Macchi wrote:
>> Hi,
>>
>> Alex Schultz (mwhahaha on IRC) has been a very active contributor over
>> the last months in the Puppet OpenStack group:
>> * He's doing a lot of reviews and they are very valuable. He's in my
>> opinion fully aware of our conventions and has nice insights to improve
>> our modules.
>> * He's very helpful to work on bugs or new features when needed.
>> * Always present during meetings and actively participating.
>> * Always on IRC, he never hesitates to give a hand on something or help
>> people.
>>
>> I think we're very lucky to have Alex part of our group and I would like
>> to promote him core reviewer of all our modules.
>>
>> Team, please vote if you like the idea,
>
> Quite enough positive votes.
>
> Welcome Alex and thanks for your hard work!
> --
> Emilien Macchi
>

Thanks everyone. I look forward to continuing to improve the puppet modules.

-Alex

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

Re: [openstack-dev] [Fuel] Wipe of the nodes' disks

[Alex Schultz]

On Thu, Dec 24, 2015 at 1:29 AM, Artur Svechnikov
 wrote:
> Hi,
> We have faced the issue that nodes' disks are wiped after stop deployment.
> It occurs due to the logic of nodes removing (this is old logic and it's not
> actual already as I understand). This logic contains step which calls
> erase_node[0], also there is another method with wipe of disks [1]. AFAIK it
> was needed for smooth cobbler provision and ensure that nodes will not be
> booted from disk when it shouldn't. Instead of cobbler we use IBP from
> fuel-agent where current partition table is wiped before provision stage.
> And use disks wiping for insurance that nodes will not booted from disk
> doesn't seem good solution. I want to propose not to wipe disks and simply
> unset bootable flag from node disks.
>
> Please share your thoughts. Perhaps some other components use the fact that
> disks are wiped after node removing or stop deployment. If it's so, then
> please tell about it.
>
> [0]
> https://github.com/openstack/fuel-astute/blob/master/lib/astute/nodes_remover.rb#L132-L137
> [1]
> https://github.com/openstack/fuel-astute/blob/master/lib/astute/ssh_actions/ssh_erase_nodes.rb
>

I thought the erase_node[0] mcollective action was the process that
cleared a node's disks after their removal from an environment. When
do we use the ssh_erase_nodes?  Is it a fall back mechanism if the
mcollective fails?  My understanding on the history is based around
needing to have the partitions and data wiped so that the LVM groups
and other partition information does not interfere with the
installation process the next time the node is provisioned.  That
might have been a side effect of cobbler and we should test if it's
still an issue for IBP.


Thanks,
-Alex

[0] https://github.com/openstack/fuel-astute/blob/master/mcagents/erase_node.rb

> Best regards,
> Svechnikov Artur
>
> __
> 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

Re: [openstack-dev] [Fuel] Error running RPC method verify_networks: Network verification not avaliable because nodes ["1"] not avaliable via mcollective

[Alex Schultz]

Hey John,


On Fri, Dec 18, 2015 at 11:15 AM, John Menke  wrote:

>
>
>
> 2015-12-17 20:49:36ERR[566] Error running RPC method verify_networks:
> Network verification not avaliable because nodes ["1"] not avaliable via
> mcollective, trace:
> ["/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/orchestrator.rb:196:in
> `validate_nodes_access'",
> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/orchestrator.rb:148:in
> `check_dhcp'",
> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/dispatcher.rb:121:in
> `check_dhcp'",
> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/dispatcher.rb:109:in
> `block in verify_networks'",
> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/dispatcher.rb:107:in
> `each'",
> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/dispatcher.rb:107:in
> `verify_networks'",
> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/server.rb:146:in
> `dispatch_message'",
> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/server.rb:107:in
> `block in dispatch'",
> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/task_queue.rb:64:in
> `call'",
> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/task_queue.rb:64:in
> `block in each'",
> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/task_queue.rb:56:in
> `each'",
> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/task_queue.rb:56:in
> `each'",
> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/server.rb:105:in
> `each_with_index'",
> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/server.rb:105:in
> `dispatch'",
> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/server.rb:89:in
> `block in perform_main_job'"]
> I have a new Fuel 7.0 and I am experiencing this issue when i try to run
> verify network from the UI.
>
> Steps to recreate:
>
> 1. Install Fuel 7 via USB - verify it has access to public internet via
> eth1
> 2. PXE boot my servers and they connect and get ips from fuel server over
> eth0
> 3. Login to Fuel UI and create a new Environment - accept all defaults
> 4. Provision nodes (all nodes found) using Add Node
> 5. Click Verify Networks on the Network Tab
>
> The above message appears.
>
> I have checked dockerctl list -l to make sure all the docker instances are
> running.  Have been searching through the log files, but this is the only
> thing i can find so far.
>
>
What is the output of 'mco ping' from the fuel master?  The verification
process attempts to launch commands on the remote nodes via mcollective. So
if they aren't responding it will fail like this.  You may also want to
check the mcollective logs on node that is failing to see if it's having
issues communicating with the master.

Also if you pop in to #fuel on freenode we can help troubleshoot further in
realtime.

Thanks,
-Alex


> John
>
> __
> 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

Re: [openstack-dev] [Fuel] Error running RPC method verify_networks: Network verification not avaliable because nodes ["1"] not avaliable via mcollective

[Alex Schultz]

On Fri, Dec 18, 2015 at 12:52 PM, John Menke <jmj...@gmail.com> wrote:

> Alex,
>
> Thanks for the reply.  i was able to get around the issue.  I rebooted all
> my instances and the mcollective error went away.
>
>
Yes rebooting the node will restart mcollective and cause it to reconnect.
So that's one way to fix it.


> mco ping from fuel now returns
>
> 11 time ...
> 12 time ...
> 13 time...
> master tim...
>
> Now it's complaining that it can't hit some repos from the compute node.
> I logged into the compute node and can ping the
> repo domains...checking the nailgun and astute logs as it's asking now.
>
>
So do your compute nodes have public access to the internet with your
network configuration? If not you may need to use fuel-createmirror to
create a local repository mirrors.
https://docs.mirantis.com/openstack/fuel/fuel-7.0/operations.html#setting-up-local-mirrors

Thanks,
-Alex


> On Fri, Dec 18, 2015 at 1:29 PM, Alex Schultz <aschu...@mirantis.com>
> wrote:
>
>> Hey John,
>>
>>
>> On Fri, Dec 18, 2015 at 11:15 AM, John Menke <jmj...@gmail.com> wrote:
>>
>>>
>>>
>>>
>>> 2015-12-17 20:49:36ERR[566] Error running RPC method verify_networks:
>>> Network verification not avaliable because nodes ["1"] not avaliable via
>>> mcollective, trace:
>>> ["/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/orchestrator.rb:196:in
>>> `validate_nodes_access'",
>>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/orchestrator.rb:148:in
>>> `check_dhcp'",
>>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/dispatcher.rb:121:in
>>> `check_dhcp'",
>>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/dispatcher.rb:109:in
>>> `block in verify_networks'",
>>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/dispatcher.rb:107:in
>>> `each'",
>>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/dispatcher.rb:107:in
>>> `verify_networks'",
>>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/server.rb:146:in
>>> `dispatch_message'",
>>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/server.rb:107:in
>>> `block in dispatch'",
>>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/task_queue.rb:64:in
>>> `call'",
>>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/task_queue.rb:64:in
>>> `block in each'",
>>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/task_queue.rb:56:in
>>> `each'",
>>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/task_queue.rb:56:in
>>> `each'",
>>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/server.rb:105:in
>>> `each_with_index'",
>>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/server.rb:105:in
>>> `dispatch'",
>>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/server.rb:89:in
>>> `block in perform_main_job'"]
>>> I have a new Fuel 7.0 and I am experiencing this issue when i try to run
>>> verify network from the UI.
>>>
>>> Steps to recreate:
>>>
>>> 1. Install Fuel 7 via USB - verify it has access to public internet via
>>> eth1
>>> 2. PXE boot my servers and they connect and get ips from fuel server
>>> over eth0
>>> 3. Login to Fuel UI and create a new Environment - accept all defaults
>>> 4. Provision nodes (all nodes found) using Add Node
>>> 5. Click Verify Networks on the Network Tab
>>>
>>> The above message appears.
>>>
>>> I have checked dockerctl list -l to make sure all the docker instances
>>> are running.  Have been searching through the log files, but this is the
>>> only thing i can find so far.
>>>
>>>
>> What is the output of 'mco ping' from the fuel master?  The verification
>> process attempts to launch commands on the remote nodes via mcollective. So
>> if they aren't responding it will fail like this.  You may also want to
>> check the mcollective logs on node that is failing to see if it's having
>> issues communicating with the master.
>>
>> Also if you pop in to #fuel on freenode we can help troubleshoot further
>> in realtime.
>>
>> Thanks,
>> -Alex
>>
>>
>>> John
>>>
>>>
>>>

Re: [openstack-dev] [Fuel] Disable 3.[3-7] gates for master?

[Alex Schultz]

On Wed, Dec 16, 2015 at 3:33 AM, Bartłomiej Piotrowski
 wrote:
> Fuelers,
>
> with the switch to CentOS 7, we also started using Puppet 3.8 in place
> of 3.4. Is there any reason to run entire range of
> gate-fuel-library-puppet-unit-3.*-dsvm-centos7 tests?
>
> I suppose we could leave only 3.8 and 4.0 there (at least for master).
> For stable branches we could keep just 3.4, 3.8 and 4.0 and disable the
> rest.
>
> What do you think?
>

We should probably figure out what versions are supported by the
distributions and target those. I would say we need to keep 3.4 since
that's what ships with Ubuntu.  That being said as we move to
supporting Fuel being installed via packages and not relying on the
existing packages being provided by MOS, the end user could use any
version of puppet they so desire via the puppetlabs repositories.
We're just using the same set of tests that the Puppet OpenStack folks
are using so it would continue to benefit us to support the same set
of tests if there is no compelling reason not to.  Are we running into
a particular issue with the other jobs?

Thanks,
-Alex


> Bartłomiej
>
> __
> 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

Re: [openstack-dev] [Fuel] HA cluster disk monitoring, failover and recovery

[Alex Schultz]

On Tue, Nov 17, 2015 at 9:01 AM, Vladimir Kuklin <vkuk...@mirantis.com> wrote:
> Folks
>
> Is not it possible for an OCF script to clear this attribute after a
> sufficient period of successful monitoring of node health? It could be a
> better approach in this case then restarting the node.
>

So this leverages the pacemaker provided sysinfo and leverages core
pacemaker/corosync functionality.  We'd have to look into the core of
that to see if it would be possible to have it automatically mark the
node cleared if the space gets cleared up. (essentially clearing the
health_disk status attribute)  You do not have to reboot/restart the
node. You simply clear the alarm and the services automatically start
back up.  As I have previously mentioned about this change, it is not
a replacement for proper system monitoring and ensuring node health.
This is simply a minor improvement to ensure that the cluster doesn't
crash itself when it runs out of space. The goal of change was to
ensure that rabbitmq/mysql/etc are cleanly shutdown prior to a
critical lack of disk space which can lead to the systems melting
down.

Thanks,
-Alex

> On Tue, Nov 17, 2015 at 5:41 PM, Alex Schultz <aschu...@mirantis.com> wrote:
>>
>> Hey Kyrylo,
>>
>>
>> On Tue, Nov 17, 2015 at 8:28 AM, Kyrylo Galanov <kgala...@mirantis.com>
>> wrote:
>> > Hi Team,
>> >
>> > I have been testing fail-over after free disk space is less than 512 mb.
>> > (https://review.openstack.org/#/c/240951/)
>> > Affected node is stopped correctly and services migrate to a healthy
>> > node.
>> >
>> > However, after free disk space is more than 512 mb again the node does
>> > not
>> > recover it's state to operating. Moreover, starting the resources
>> > manually
>> > would rather fail. In a nutshell, the pacemaker service / node should be
>> > restarted. Detailed information is available here:
>> >
>> > https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_configuration_basics_monitor_health.html
>> >
>> > How do we address this issue?
>> >
>>
>> So the original change for this was
>> https://review.openstack.org/#/c/226062/. As indicated by the commit
>> message, the only way pacemaker will recover is that the operator must
>> run a pacemaker command to clear the disk alert.
>>
>> crm node status-attr  delete "#health_disk"
>>
>> Once the operator has cleared up the diskspace issue and run the above
>> command, pacemaker will rejoin the cluster and start services again.
>> The documentation bug for this is
>> https://bugs.launchpad.net/fuel/+bug/1500422.
>>
>> Thanks,
>> -Alex
>>
>> >
>> > Best regards,
>> > Kyrylo
>> >
>> >
>> > __
>> > 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
>
>
>
>
> --
> 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
> www.mirantis.ru
> vkuk...@mirantis.com
>
> __
> 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

Re: [openstack-dev] [Fuel] HA cluster disk monitoring, failover and recovery

[Alex Schultz]

Hey Kyrylo,


On Tue, Nov 17, 2015 at 8:28 AM, Kyrylo Galanov  wrote:
> Hi Team,
>
> I have been testing fail-over after free disk space is less than 512 mb.
> (https://review.openstack.org/#/c/240951/)
> Affected node is stopped correctly and services migrate to a healthy node.
>
> However, after free disk space is more than 512 mb again the node does not
> recover it's state to operating. Moreover, starting the resources manually
> would rather fail. In a nutshell, the pacemaker service / node should be
> restarted. Detailed information is available here:
> https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_configuration_basics_monitor_health.html
>
> How do we address this issue?
>

So the original change for this was
https://review.openstack.org/#/c/226062/. As indicated by the commit
message, the only way pacemaker will recover is that the operator must
run a pacemaker command to clear the disk alert.

crm node status-attr  delete "#health_disk"

Once the operator has cleared up the diskspace issue and run the above
command, pacemaker will rejoin the cluster and start services again.
The documentation bug for this is
https://bugs.launchpad.net/fuel/+bug/1500422.

Thanks,
-Alex

>
> Best regards,
> Kyrylo
>
> __
> 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

Re: [openstack-dev] [Fuel] HA cluster disk monitoring, failover and recovery

[Alex Schultz]

On Tue, Nov 17, 2015 at 11:12 AM, Vladimir Kuklin  wrote:
> Bogdan
>
> I think we should firstly check whether attribute deletion leads to node
> starting its services or not. From what I read in the official Pacemaker
> documentation, it should work out of the box without the need to restart the
> node.

It does start up the services when the attribute is cleared. QA has a
test to validate this as part of this change.

> And by the way the quote above mentions 'use ONE of the following methods'
> meaning that we could actually use attribute deletion. The 2nd and the 3rd
> options do the same - they clear short-living node attribute. So we need to
> figure out why OCF script does not update the corresponding attribute by
> itself.
>

https://github.com/ClusterLabs/pacemaker/blob/master/extra/resources/SysInfo#L215-L227

It doesn't have something that updates it to green because essentially
when this condition hits, the sysinfo service is also stopped. It has
no way of knowing when it is cleared because all the resources are
stopped and there is no longer a service running to reset the
attribute.  We would need something outside of pacemaker to mark it OK
or perhaps write a custom health strategy[0][1] that would not stop
the sysinfo task and update the ocf script to update the status to
green if all disks are OK.

-Alex

[0] 
https://github.com/openstack/fuel-library/blob/master/deployment/puppet/cluster/manifests/sysinfo.pp#L50-L55
[1] http://clusterlabs.org/wiki/SystemHealth

>
>
> On Tue, Nov 17, 2015 at 7:03 PM, Bogdan Dobrelya 
> wrote:
>>
>> On 17.11.2015 15:28, Kyrylo Galanov wrote:
>> > Hi Team,
>>
>> Hello
>>
>> >
>> > I have been testing fail-over after free disk space is less than 512 mb.
>> > (https://review.openstack.org/#/c/240951/)
>> > Affected node is stopped correctly and services migrate to a healthy
>> > node.
>> >
>> > However, after free disk space is more than 512 mb again the node does
>> > not recover it's state to operating. Moreover, starting the resources
>> > manually would rather fail. In a nutshell, the pacemaker service / node
>> > should be restarted. Detailed information is available
>> > here:
>> > https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_configuration_basics_monitor_health.html
>> >
>> > How do we address this issue?
>>
>> According to the docs you provided,
>> " After a node's health status has turned to red, solve the issue that
>> led to the problem. Then clear the red status to make the node eligible
>> again for running resources. Log in to the cluster node and use one of
>> the following methods:
>>
>> Execute the following command:
>>
>> crm node status-attr NODE delete #health_disk
>>
>> Restart OpenAIS on that node.
>>
>> Reboot the node.
>>
>> The node will be returned to service and can run resources again. "
>>
>> So this looks like an expected behaviour!
>>
>> What else could be done:
>> - We should check if we have this nuance documented, and submit a bug to
>> fuel-docs team, if not yet there.
>> - Submitting a bug and inspecting logs would be nice to do as well.
>> I believe some optimizations may be done, bearing in mind this pacemaker
>> cluster-recheck-interval and failure-timeout story [0].
>>
>> [0]
>> http://blog.kennyrasschaert.be/blog/2013/12/18/pacemaker-high-failability/
>>
>> >
>> >
>> > Best regards,
>> > Kyrylo
>> >
>> >
>> >
>> > __
>> > 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
>> >
>>
>>
>> --
>> Best regards,
>> Bogdan Dobrelya,
>> Irc #bogdando
>>
>> __
>> 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
>
>
>
>
> --
> 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
> www.mirantis.ru
> vkuk...@mirantis.com
>
> __
> 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

Re: [openstack-dev] [fuel] Using upstream packages & modules

[Alex Schultz]

On Fri, Nov 13, 2015 at 10:17 AM, Alexander Kostrikov
<akostri...@mirantis.com> wrote:
> Hi, Alex!
> Good to know someone is doing that.
>
> One question about Your initiative:
> Are You going to reimplement all MOS HA features?
> Seems first implementation of 'upstream on Fuel' will be HA-less.
>

My first pass included the MOS HA features as we will still be
leveraging the MOS packages for these items (mysql/haproxy).  My PoC
allows for a different set of OpenStack packages to be set as the
preferred package to use over the current MOS packages which are the
Fuel default. I think eventually we'll need to reevaluate how we can
split out the MOS packages for these features and allow a user to
select which package set to use and still have it 'work'.


Thanks,
-Alex

>
> On Thu, Nov 12, 2015 at 1:51 AM, Alex Schultz <aschu...@mirantis.com> wrote:
>>
>> On Tue, Nov 10, 2015 at 11:10 AM, Vladimir Kuklin <vkuk...@mirantis.com>
>> wrote:
>> > Alex
>> >
>> > Thanks for your very detailed answer - it clarified things a bit. So, if
>> > you
>> > would allow me to rephrase it - you are actually conducting a research
>> > on
>> > what is the actual gap between our downstream/fork and upstream
>> > UCA/puppet-openstack. This seems to be a very promising initiative. Are
>> > you
>> > going to come up with some external-user readable report soon?
>> >
>> > Also, regarding multiple distros support.  I think, we need to come up
>> > with
>> > an approach of making 'release manager' piece of Nailgun data driven and
>> > just allow a user to run any distribution he or she wants. Just register
>> > a
>> > set of repos with packages and run it. Actually, we already have it - we
>> > need to make base-image generation for RPM more flexible and any RPM/DEB
>> > based distro should work ok with it.
>> >
>> > The remaining piece is to actually support distro-specific things, e.g.
>> > CentOS/RHEL networking configuration, e.g. l23 network stored config
>> > puppet
>> > providers. But this is a distro-supporter/community burden.
>> >
>> >
>>
>> Yes I hope to have something together by the end of the week.  I've
>> managed to get a controller and compute/cinder nodes up (and passing
>> basic OSTF tests) with what appears to be some minor adjustments to
>> the fuel-library code.  The one thing that gets dropped because of
>> lack of upstream support is nova floating network ranges. There's a
>> pending review that'll get that back in but I also don't know how
>> important it would be to support for this type of configuration.
>> Another issue is the upstream murano module is still a work in
>> progress so that won't work right now either. Hopefully that'll get
>> sorted out in time for the official release of the liberty puppet
>> modules.
>>
>> As I've been working through this, I've noticed that it would be
>> possible to use fuel-plugins to only apply UCA packages to specific
>> nodes via a plugin role. An interesting follow on to this effort would
>> be to use MOS packages for controllers and UCA for Compute or vice
>> versa.  But that should probably be more an academic exercise rather
>> than production one.
>>
>> -Alex
>>
>> >
>> > On Tue, Nov 10, 2015 at 6:25 PM, Alex Schultz <aschu...@mirantis.com>
>> > wrote:
>> >>
>> >> Hey Vladimir,
>> >>
>> >> On Tue, Nov 10, 2015 at 5:56 AM, Vladimir Kuklin <vkuk...@mirantis.com>
>> >> wrote:
>> >> > 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
>> >> > so

[openstack-dev] [fuel] Using alternative OpenStack packages with Fuel

[Alex Schultz]

Hey folks,

Based on my previous email, I promised to send out a note this week
about this topic.  My original email also included testing out the
development version of the upstream puppet modules. I was able to get
an environment working with the master branches of the OpenStack
Puppet modules but ran into further issues.  To simplify the
discussions, I've decided to split the topics into using upstream
packages and using upstream modules.  Below is the preliminary results
for the upstream package topic.  I plan on publicly posting (somewhere
TBD) both sets of results as well as additional instructions. I look
forward to comments.

Using alternative OpenStack packages with Fuel
--

Fuel[0] is an open source deployment and management tool for
OpenStack.  Current versions of Fuel provide the ability to deploy and
configure OpenStack clouds utilizing Debian based packages on Ubuntu
based systems.  But if you wanted to use a different set of packages
for your cloud?  Well Fuel can be configured to deploy those packages
instead of the packages currently used.

The Plugin
--

Fuel provides a plugin framework than can be used to inject additional
steps in the deployment process.  In addition to deployment tasks,
plugins can be used to create additional roles that can be assigned to
nodes.  With this framework, we were able to create a proof of concept
plugin[1] that can be used to configure specific nodes to use the
Ubuntu Cloud Archive[2] packages as their preferred OpenStack package
repository.

The plugin creates a new role that can be applied to specific nodes to
indicate that the UCA packages should be used.  The plugin sets a
puppet fact called os_package_type[3] which is will be consumed by the
upstream OpenStack Puppet modules to indicate which packages to
install and configure.  The Debian based packages which are the
default for Fuel have some minor differences from the UCA packages.
Our plugin overrides the default os_package_type to specify that we
want to use 'ubuntu' packages.

In addition to specifying the os_package_type, the plugin also pins a
specific set of packages that must be used with Fuel. Currently, the
haproxy package that is used with Fuel differs from a version provided
by Ubuntu based systems. At time of writing, this package needs to be
used so the plugin ensures this package set gets installed.  The last
configuration this plugin performs is to setup the UCA package
repository on the host system and sets the priority of this repository
to be higher than the default repository so that the UCA packages are
installed.

The plugin creates a role[4] that must be assigned the system(s) that
the user would like to use the UCA package set with.  Since a role is
provided, this would allow the end user fine grained control over
which packages are used for the node.  With this flexibility, a user
could use Debian based packages for Controller nodes and UCA based
packages for Compute nodes or vice versa.

Fuel Flexibility


With this proof of concept, Fuel shows its potential as a deployment
and management system for OpenStack. With the plugin, we are also able
to add additional configurations around what version of the packages
we would like to use. We are able to specify the Kilo or Liberty
packages[5] (and future Mikita, etc).  Since Fuel is leveraging
upstream OpenStack Puppet manifests, it should be able to support two
different packages versions for a given version of Fuel.  With the
plugin for a given environment, we would be able to test a future
version of the packages with the same version of fuel-library.

In addition to providing Ubuntu package installation support, as we
work on additional RedHat family support we would able to provide a
similar mechanism for RDO packages or another distribution's packages.
Because of the options provided by a plugin, we could even support
CentOS packages for Controllers and RDO packages for Compute nodes.

Issues
--

In order to get the plugin and alternate package set, a few items
needed to be addressed in fuel-library. A patch[6] was created to
address these issues.

 * The Debian based packages assume that python-mysqldb should be used
for the mysql driver. As such, we add an additional parameter to our
database connection string called read_timeout for our HA
configuration. Unfortunately the Ubuntu based packages assume that
python-pymysql should be used for the mysql drive.  In order to allow
for the Ubuntu based packages, we prepared a patch to remove the
read_timeout from the mysql database connection strings used.
 * The Debian based packages provide a heat-docker package which
provides docker files for Heat. Since there appears to be no such
package with the Ubuntu package set, we only install it when the
Debian based packages are installed.
 * During testing we found due to Bug 1499620[7] that there is a
version of the Ubuntu based packages have an issues with 

Re: [openstack-dev] [fuel] Using upstream packages & modules

[Alex Schultz]

On Tue, Nov 10, 2015 at 11:10 AM, Vladimir Kuklin <vkuk...@mirantis.com> wrote:
> Alex
>
> Thanks for your very detailed answer - it clarified things a bit. So, if you
> would allow me to rephrase it - you are actually conducting a research on
> what is the actual gap between our downstream/fork and upstream
> UCA/puppet-openstack. This seems to be a very promising initiative. Are you
> going to come up with some external-user readable report soon?
>
> Also, regarding multiple distros support.  I think, we need to come up with
> an approach of making 'release manager' piece of Nailgun data driven and
> just allow a user to run any distribution he or she wants. Just register a
> set of repos with packages and run it. Actually, we already have it - we
> need to make base-image generation for RPM more flexible and any RPM/DEB
> based distro should work ok with it.
>
> The remaining piece is to actually support distro-specific things, e.g.
> CentOS/RHEL networking configuration, e.g. l23 network stored config puppet
> providers. But this is a distro-supporter/community burden.
>
>

Yes I hope to have something together by the end of the week.  I've
managed to get a controller and compute/cinder nodes up (and passing
basic OSTF tests) with what appears to be some minor adjustments to
the fuel-library code.  The one thing that gets dropped because of
lack of upstream support is nova floating network ranges. There's a
pending review that'll get that back in but I also don't know how
important it would be to support for this type of configuration.
Another issue is the upstream murano module is still a work in
progress so that won't work right now either. Hopefully that'll get
sorted out in time for the official release of the liberty puppet
modules.

As I've been working through this, I've noticed that it would be
possible to use fuel-plugins to only apply UCA packages to specific
nodes via a plugin role. An interesting follow on to this effort would
be to use MOS packages for controllers and UCA for Compute or vice
versa.  But that should probably be more an academic exercise rather
than production one.

-Alex

>
> On Tue, Nov 10, 2015 at 6:25 PM, Alex Schultz <aschu...@mirantis.com> wrote:
>>
>> Hey Vladimir,
>>
>> On Tue, Nov 10, 2015 at 5:56 AM, Vladimir Kuklin <vkuk...@mirantis.com>
>> wrote:
>> > 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.
>> >
>>
>> Yes, I'm aware that it'll be an effort to make it work identically to
>> MOS.  Currently that's not my goal. My goal is to get it working at
>> all and be able to document the deficiencies when using upstream
>> packages/modules vs MOS provided ones.  Once we have documented these
>> differences we will be able to make decisions as to what efforts
>> should be made if we choose to address the differences.  The read
>> timeout thing seems to be an issue with what mysql python driver is
>> used so that could easily be configurable based on a packages or a
>> configuration option.
>>
>> > 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.
>> >
>>
>> So I think this is where we are currently backwards in the way we're
>> doings. As we hope to push Fuel as a community project, we need to be
>> more open 

Re: [openstack-dev] [fuel] Using upstream packages & modules

[Alex Schultz]

Hey Vladimir,

On Tue, Nov 10, 2015 at 5:56 AM, Vladimir Kuklin <vkuk...@mirantis.com> wrote:
> 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.
>

Yes, I'm aware that it'll be an effort to make it work identically to
MOS.  Currently that's not my goal. My goal is to get it working at
all and be able to document the deficiencies when using upstream
packages/modules vs MOS provided ones.  Once we have documented these
differences we will be able to make decisions as to what efforts
should be made if we choose to address the differences.  The read
timeout thing seems to be an issue with what mysql python driver is
used so that could easily be configurable based on a packages or a
configuration option.

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

So I think this is where we are currently backwards in the way we're
doings. As we hope to push Fuel as a community project, we need to be
more open to supporting the distributions versions of these packages
as being supported.  If we want to continue with specific versions of
things we need to be able to modularize them and apply them to a
downstream version of Fuel that we can promote with the MOS package
set.  I agree that right now it's highly unlikely that one would be
able to use Fuel without any MOS packages. Because I don't think it's
possible right now, what I'm attempting to do is be able to deploy an
alternate OpenStack package set but not all of the other pieces as
they relate to our reference architecture.  That seems to be a more
achievable goal right now and allows us to document the gaps where
Fuel/MOS are a head (or behind depending on your views) with upstream.

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

Unfortunately the haproxy fork that we're currently running with also
includes our forked version of the puppet haproxy module. I'm not sure
the includes configs patch is really worth carrying the additional
work/forks but I think that is a conversation for another day.
Personally I think it would better if fuel-library supported the
currently available upstream versions of haproxy & haproxy puppet
module and if we want to continue using our copies of haproxy & puppet
haproxy module that we turn that into a downstream that is applied for
the MOS specific version of Fuel.  That's the advantage of the
Puppetfile we've been working on. We can change out the modules with
our own version downstream.

Just to add some additional updates issues that I've run into.

- nova-vncproxy package names (nova-consoleproxy vs nova-novncproxy)
but that's easily solved with the proposed os_package_type fact.
- heat-docker package does not exist in UCA. Haven't looked at what
exactly is in this package yet.
- horizon UCA package runs into
https://bugs.launchpad.net/cloud-archive/+bug/1479340 (we solved this
for MOS but it's still broken in UCA)
- neutron UCA package seems to suffer from
https://bugs.launchpad.net/mos/+bug/1510844
- Need to solve for the url issues with the openstack command that are
showing up in the CI as I just hit it with my deployment.

Thanks,
-Alex

> On Tue, Nov 10, 2015 at 12:54 PM, Stanislaw Bogatkin
> <sbogat...@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 looong command line with all of them - and
>> it's really inconvenient.
&g

[openstack-dev] [fuel] Using upstream packages & modules

[Alex Schultz]

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.

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

Re: [openstack-dev] [fuel] What to do when a controller runs out of space

[Alex Schultz]

On Mon, Oct 5, 2015 at 5:56 AM, Eugene Nikanorov
 wrote:
> Ok,
>
> Project-wise:
> 1) Pacemaker is not under our company's control, we can't assure its quality
> 2) it has terrible UX
> 3) it is not reliable
>

I disagree with #1 as I do not agree that should be a criteria for an
open-source project.  Considering pacemaker is at the core of our
controller setup, I would argue that if these are in fact true we need
to be using something else.  I would agree that it is a terrible UX
but all the clustering software I've used fall in this category.  I'd
like more information on how it is not reliable. Do we have numbers to
backup these claims?

> (3) is not evaluation of the project itself, but just a logical consequence
> of (1) and (2).
> As a part of escalation team I can say that it has cost our team thousands
> of man hours of head-scratching, staring at pacemaker logs which value are
> usually slightly below zero.
>
> Most of openstack services (in fact, ALL api servers) are stateless, they
> don't require any cluster management (also, they don't need to be moved in
> case of lack of space).
> Statefull services like neutron agents have their states being a function of
> db state and are able to syncronize it with the server without external
> "help".
>

So it's not an issue with moving services so much as being able to
stop the services when a condition is met. Have we tested all OS
services to ensure they do function 100% when out of disk space?  I
would assume that glance might have issues with image uploads if there
is no space to handle a request.

> So now usage of pacemaker can be only justified for cases where service's
> clustering mechanism requires active monitoring (rabbitmq, galera)
> But even there, examples when we are better off without pacemaker are all
> around.
>
> Thanks,
> Eugene.
>

After I sent this email, I had further discussions around the issues
that I'm facing and it may not be completely related to disk space. I
think we might be relying on the expectation that the local rabbitmq
is always available but I need to look into that. Either way, I
believe we still should continue to discuss this issue as we are
managing services in multiple ways on a single host. Additionally I do
not believe that we really perform quality health checks on our
services.

Thanks,
-Alex


>
> On Mon, Oct 5, 2015 at 1:34 PM, Sergey Vasilenko 
> wrote:
>>
>>
>> On Mon, Oct 5, 2015 at 12:22 PM, Eugene Nikanorov
>>  wrote:
>>>
>>> No pacemaker for os services, please.
>>> We'll be moving out neutron agents from pacemaker control in 8.0, other
>>> os services don't need it too.
>>
>>
>> could you please provide your arguments.
>>
>>
>> /sv
>>
>> __
>> 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

Re: [openstack-dev] [puppet] Running Debian packages on top of Trusty

[Alex Schultz]

On Fri, Oct 2, 2015 at 7:43 AM, Ivan Udovichenko
 wrote:
> Hello,
>
> On 10/02/2015 03:15 PM, Emilien Macchi wrote:
>> Hey Thomas,
>>
>> On 10/02/2015 04:33 AM, Thomas Goirand wrote:
>> [...]
>>> We also may need, at some point, to add the type mosdebian and moscentos
>>> to the list of supported package suite, as there still will be some
>>> differences between the upstream Debian or CentOS packages. What is the
>>> best way to add this variable values?
>>>
>>> Could you Puppet experts explain to me and my Mirantis colleagues again?
>>
>> So we partially discussed about that during our last weekly meeting [1]
>> and it come out the best way to support both Debian & Ubuntu are Puppet
>> conditionals, like we already have in place.
>>
>> [1]
>> http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-09-29-15.00.html
>
> It does not solve the original problem. Let's say you want to install
> Debian packages on-top of Ubuntu, it will fail and you will have to use
> workarounds, for example in the params.pp [1] you have specified.
>
> [1]
> https://github.com/openstack/puppet-nova/blob/master/manifests/params.pp#L100-L107
>
>>
>> See the example with puppet-nova |2] where we use $::operatingsystem
>> fact [3] to detect if we're running Ubuntu or Debian.
>> If we're running Ubuntu, we take reference from UCA packaging. If
>> Debian, we take your work as reference.
>>
>> [2]
>> https://github.com/openstack/puppet-nova/blob/master/manifests/params.pp#L100-L107
>> [3] https://puppetlabs.com/facter
>>
>
> What we need is some variable which can override the decision which
> Operating System is used and thereby required packages will be
> installed. At least for Debian, that is what we really need.
> I'd be grateful if you look into it. Thank you.
>

There are a few alternatives for this issue.  The first one is that
the package names, etc can be overwritten in the code that pulls in
the OpenStack Puppet modules. We are already doing this today in our
openstack::nova::controler[0] code.  There is another alternative to
leverage a globals class that would allow for overriding params. I
know Ivan Berezovskiy is working on something[1] and I think he was
going to bring this up in the next irc meeting. His method would allow
for the overriding of the params where the current package & service
name calculations are being done.  Another alternative would be to
rework the params class to query hiera and default to the existing
params settings if not defined or something to that effect.

Basically I think the ask for OpenStack Puppet is allowing for
additional configuration options if a user does not want to leverage
the RDO or UCA packages or needs to specific alternative package &
service names.


Thanks,
-Alex


[0] 
https://github.com/stackforge/fuel-library/blob/deb63f09df23170207310f06ca4e12785d018dc2/deployment/puppet/openstack/manifests/nova/controller.pp#L399
[1] https://review.openstack.org/#/c/229918/


>>
>>> Sorry that I didn't take notes about it and couldn't explain,
>>> Cheers,
>>>
>>> Thomas Goirand (zigo)
>>>
>>> P.S: Where may I find the best tutorial to get up-to-speed about puppet,
>>> so that I know what I'm talking about next time?
>>>
>>
>> I personally learnt (and am still learning) by using official
>> documentation [4], that I suggest you to start with.
>>
>> [4] http://docs.puppetlabs.com/puppet/
>>
>> Hope it helps,
>>
>>
>>
>> __
>> 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

[openstack-dev] [fuel] What to do when a controller runs out of space

[Alex Schultz]

Hey All,

So I was working on Bug 1493520 which is about what happens when a
controller runs out of space. For this I came up with a solution[1] to
leverage pacemaker to migrate services away from the controller when
it runs out of space.  This works great for rabbitmq/mysql where if
they run out of space "Bad Things Happen"™. But there is a problem
that I didn't realize until QA got ahold of it. We run services
(neutron-server,heat,nova-api,etc) on our controllers that are not
managed via corosync so they still run and will attempt to serve
requests via the haproxy that was conveniently moved off of the bad
controller node.

So my question is, what should we do in this case? Should we be
managing the start/stop of these services via Pacemaker? We would get
additional benefits of having these services restarted if they crash
and they would get stopped when the node health goes red like the rest
of the services.  But this will add additional complexity if anyone
want to extract these services off of the controller to run on their
own.

Another solution would be to try and figure out some haproxy solution
for the node.  I'm not sure if haproxy has the concept of a node
health check like some other load-balancing solutions do. If it did,
we could just create a node health check that would down all the
services with a single check that could query the cluster health
status.

Thoughts?

Thanks,
-Alex


[0] https://bugs.launchpad.net/fuel/+bug/1493520
[1] https://review.openstack.org/#/c/226062/

__
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-dev] [fuel][fuel-library] librarian workflows

[Alex Schultz]

Hey Fuel folks,

We have recently had some concerns around the librarian workflows and
custom patches to upstream modules.  I have updated the Fuel wiki[0]
with additional information to try and clarify how librarian is used
within fuel-library and what the rules are around the use of custom
upstream patches.

Additionally, I have created a script[1] to be used as part of Fuel
CI[2] to validate the Puppetfile based on the policies laid out on the
wiki page. Please take some time to review the wiki and the script and
provide feedback.

Thanks,
-Alex

[0] https://wiki.openstack.org/wiki/Fuel/Library_and_Upstream_Modules
[1] https://review.openstack.org/#/c/229605/
[2] https://review.fuel-infra.org/#/c/12344/

__
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

Re: [openstack-dev] [puppet] use zuul-cloner when running rspec

[Alex Schultz]

On Wed, Sep 23, 2015 at 4:56 PM, Emilien Macchi  wrote:
> Background
> ==
>
> Current rspec tests are tested with modules mentioned in .fixtures.yaml
> file of each module.
>
> * the file is not consistent across all modules
> * it hardcodes module names & versions
> * this way does not allow to use "Depend-On" feature, that would allow
> to test cross-modules patches
>
> Proposal
> 
>
> * Like we do in beaker & integration jobs, use zuul-cloner to clone
> modules in our CI jobs.
> * Use r10k to prepare fixtures modules.
> * Use Puppetfile hosted by openstack/puppet-openstack-integration
>
> In that way:
> * we will have modules name + versions testing consistency across all
> modules
> * the same Puppetfile would be used by unit/beaker/integration testing.
> * the patch that pass tests on your laptop would pass tests in upstream CI
> * if you don't have zuul-cloner on your laptop, don't worry it will use
> git clone. Though you won't have Depends-On feature working on your
> laptop (technically not possible).
> * Though your patch will support Depends-On in OpenStack Infra for unit
> tests. If you submit a patch in puppet-openstacklib that drop something
> wrong, you can send a patch in puppet-nova that will test it, and unit
> tests will fail.
>
> Drawbacks
> =
> * cloning from .fixtures.yaml takes ~ 10 seconds
> * using r10k + zuul-clone takes ~50 seconds (more modules to clone).
>
> I think 40 seconds is something accept regarding the benefit.
>

As someone who consumes these modules downstream and has our own CI
setup to run the rspec items, this ties it too closely to the
openstack infrastructure. If we replace the .fixtures.yml with
zuul-cloner, it assumes I always want the openstack version of the
modules. This is not necessarily true. I like being able to replace
items within fixtures.yml when doing dev work. For example If i want
to test upgrading another module not related to openstack, like
inifile, how does that work with the proposed solution?  This is also
moving away from general puppet module conventions for testing. My
preference would be that this be a different task and we have both
.fixtures.yml (for general use/development) and the zuul method of
cloning (for CI).  You have to also think about this from a consumer
standpoint and this is adding an external dependency on the OpenStack
infrastructure for anyone trying to run rspec or trying to consume the
published versions from the forge.  Would I be able to run these tests
in an offline mode with this change? With the .fixures.yml it's a
minor edit to switch to local versions. Is the same true for the
zuul-cloner version?

>
> Next steps
> ==
>
> * PoC in puppet-nova: https://review.openstack.org/#/c/226830/
> * Patch openstack/puppet-modulesync-config to be consistent across all
> our modules.
>
> Bonus
> =
> we might need (asap) a canary job for puppet-openstack-integration
> repository, that would run tests on a puppet-* module (since we're using
> install_modules.sh & Puppetfile files in puppet-* modules).
> Nothing has been done yet for this work.
>
>
> Thoughts?
> --
> Emilien Macchi
>
>

I think we need this functionality, I just don't think it's a
replacement for the .fixures.yml.

Thanks,
-Alex

__
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

Re: [openstack-dev] [puppet] use zuul-cloner when running rspec

[Alex Schultz]

On Thu, Sep 24, 2015 at 1:58 PM, Emilien Macchi <emil...@redhat.com> wrote:
>
>
> On 09/24/2015 02:19 PM, Alex Schultz wrote:
>> On Thu, Sep 24, 2015 at 11:54 AM, Emilien Macchi <emil...@redhat.com> wrote:
>>>
>>>
>>> On 09/24/2015 10:14 AM, Alex Schultz wrote:
>>>> On Wed, Sep 23, 2015 at 4:56 PM, Emilien Macchi <emil...@redhat.com> wrote:
>>>>> Background
>>>>> ==
>>>>>
>>>>> Current rspec tests are tested with modules mentioned in .fixtures.yaml
>>>>> file of each module.
>>>>>
>>>>> * the file is not consistent across all modules
>>>>> * it hardcodes module names & versions
>>>>> * this way does not allow to use "Depend-On" feature, that would allow
>>>>> to test cross-modules patches
>>>>>
>>>>> Proposal
>>>>> 
>>>>>
>>>>> * Like we do in beaker & integration jobs, use zuul-cloner to clone
>>>>> modules in our CI jobs.
>>>>> * Use r10k to prepare fixtures modules.
>>>>> * Use Puppetfile hosted by openstack/puppet-openstack-integration
>>>>>
>>>>> In that way:
>>>>> * we will have modules name + versions testing consistency across all
>>>>> modules
>>>>> * the same Puppetfile would be used by unit/beaker/integration testing.
>>>>> * the patch that pass tests on your laptop would pass tests in upstream CI
>>>>> * if you don't have zuul-cloner on your laptop, don't worry it will use
>>>>> git clone. Though you won't have Depends-On feature working on your
>>>>> laptop (technically not possible).
>>>>> * Though your patch will support Depends-On in OpenStack Infra for unit
>>>>> tests. If you submit a patch in puppet-openstacklib that drop something
>>>>> wrong, you can send a patch in puppet-nova that will test it, and unit
>>>>> tests will fail.
>>>>>
>>>>> Drawbacks
>>>>> =
>>>>> * cloning from .fixtures.yaml takes ~ 10 seconds
>>>>> * using r10k + zuul-clone takes ~50 seconds (more modules to clone).
>>>>>
>>>>> I think 40 seconds is something accept regarding the benefit.
>>>>>
>>>>
>>>> As someone who consumes these modules downstream and has our own CI
>>>> setup to run the rspec items, this ties it too closely to the
>>>> openstack infrastructure. If we replace the .fixtures.yml with
>>>> zuul-cloner, it assumes I always want the openstack version of the
>>>> modules. This is not necessarily true. I like being able to replace
>>>> items within fixtures.yml when doing dev work. For example If i want
>>>> to test upgrading another module not related to openstack, like
>>>> inifile, how does that work with the proposed solution?  This is also
>>>> moving away from general puppet module conventions for testing. My
>>>> preference would be that this be a different task and we have both
>>>> .fixtures.yml (for general use/development) and the zuul method of
>>>> cloning (for CI).  You have to also think about this from a consumer
>>>> standpoint and this is adding an external dependency on the OpenStack
>>>> infrastructure for anyone trying to run rspec or trying to consume the
>>>> published versions from the forge.  Would I be able to run these tests
>>>> in an offline mode with this change? With the .fixures.yml it's a
>>>> minor edit to switch to local versions. Is the same true for the
>>>> zuul-cloner version?
>>>
>>> What you did before:
>>> * Edit .fixtures.yaml and put the version you like.
>>>
>>> What you would do this the current proposal:
>>> * Edit openstack/puppet-openstack-integration/Puppetfile and put the
>>> version you like.
>>>
>>
>> So I have to edit a file in another module to test changes in
>> puppet-neutron, puppet-nova, etc? With the zuul-cloner version, for
>> local testing what does that workflow look like?
>
> If you need to test your code with cross-project dependencies, having
> current .fixtures.yaml or the proposal won't change anything regarding
> that, you'll still have to trick the YAML file that define the modules
> name/versions.
>
>>
>>> What you're suggesting has a huge downside:
>>> People will still use fixtures by 

Re: [openstack-dev] [puppet] use zuul-cloner when running rspec

[Alex Schultz]

On Thu, Sep 24, 2015 at 11:54 AM, Emilien Macchi <emil...@redhat.com> wrote:
>
>
> On 09/24/2015 10:14 AM, Alex Schultz wrote:
>> On Wed, Sep 23, 2015 at 4:56 PM, Emilien Macchi <emil...@redhat.com> wrote:
>>> Background
>>> ==
>>>
>>> Current rspec tests are tested with modules mentioned in .fixtures.yaml
>>> file of each module.
>>>
>>> * the file is not consistent across all modules
>>> * it hardcodes module names & versions
>>> * this way does not allow to use "Depend-On" feature, that would allow
>>> to test cross-modules patches
>>>
>>> Proposal
>>> 
>>>
>>> * Like we do in beaker & integration jobs, use zuul-cloner to clone
>>> modules in our CI jobs.
>>> * Use r10k to prepare fixtures modules.
>>> * Use Puppetfile hosted by openstack/puppet-openstack-integration
>>>
>>> In that way:
>>> * we will have modules name + versions testing consistency across all
>>> modules
>>> * the same Puppetfile would be used by unit/beaker/integration testing.
>>> * the patch that pass tests on your laptop would pass tests in upstream CI
>>> * if you don't have zuul-cloner on your laptop, don't worry it will use
>>> git clone. Though you won't have Depends-On feature working on your
>>> laptop (technically not possible).
>>> * Though your patch will support Depends-On in OpenStack Infra for unit
>>> tests. If you submit a patch in puppet-openstacklib that drop something
>>> wrong, you can send a patch in puppet-nova that will test it, and unit
>>> tests will fail.
>>>
>>> Drawbacks
>>> =
>>> * cloning from .fixtures.yaml takes ~ 10 seconds
>>> * using r10k + zuul-clone takes ~50 seconds (more modules to clone).
>>>
>>> I think 40 seconds is something accept regarding the benefit.
>>>
>>
>> As someone who consumes these modules downstream and has our own CI
>> setup to run the rspec items, this ties it too closely to the
>> openstack infrastructure. If we replace the .fixtures.yml with
>> zuul-cloner, it assumes I always want the openstack version of the
>> modules. This is not necessarily true. I like being able to replace
>> items within fixtures.yml when doing dev work. For example If i want
>> to test upgrading another module not related to openstack, like
>> inifile, how does that work with the proposed solution?  This is also
>> moving away from general puppet module conventions for testing. My
>> preference would be that this be a different task and we have both
>> .fixtures.yml (for general use/development) and the zuul method of
>> cloning (for CI).  You have to also think about this from a consumer
>> standpoint and this is adding an external dependency on the OpenStack
>> infrastructure for anyone trying to run rspec or trying to consume the
>> published versions from the forge.  Would I be able to run these tests
>> in an offline mode with this change? With the .fixures.yml it's a
>> minor edit to switch to local versions. Is the same true for the
>> zuul-cloner version?
>
> What you did before:
> * Edit .fixtures.yaml and put the version you like.
>
> What you would do this the current proposal:
> * Edit openstack/puppet-openstack-integration/Puppetfile and put the
> version you like.
>

So I have to edit a file in another module to test changes in
puppet-neutron, puppet-nova, etc? With the zuul-cloner version, for
local testing what does that workflow look like?

> What you're suggesting has a huge downside:
> People will still use fixtures by default and not test what is actually
> tested by our CI.
> A few people will know about the specific Rake task so a few people will
> test exactly what upstream does. That will cause frustration to the most
> of people who will see tests failing in our CI and not on their laptop.
> I'm not sure we want that.

You're right that the specific rake task may not be ideal. But that
was one option, another option could be use fixtures first then
replace with zuul-cloner provided versions but provide me the ability
to turn of the zuul cloner part? I'm just saying as it is today, this
change adds more complexity and hard ties into the OpenStack
infrastructure with non-trival work arounds. I would love to solve the
Depends-On issue, but I don't think that should include a deviation
from generally accepted testing practices of puppet modules.

>
> I think more than most of people that run tests on their laptops want to
> see them passing in upstream CI.
> The few people that want to trick vers

Re: [openstack-dev] [puppet] service default value functions

[Alex Schultz]

>
> I've been mulling this over the last several days and I just can't
> accept an entire ruby function which would be ran for every parameter
> with the desired static value of "" when the class is
> declared and parsed.  I am not generally against using functions as a
> parameter default just not a fan in this case because running ruby just
> to return a static string seems inappropriate and not optimal.
>
> In this specific case I think the params pattern and inheritance can
> obtain us the same goals.  I also find this a valid us of inheritance
> cross module namespaces but...only because all our modules must depend
> on puppet-openstacklib.
>
> http://paste.openstack.org/show/473655
>

Yes after thinking it over, I agree that the function for a parameter
is probably not the best route.  I think going the inheritance route
is a much more established pattern and would make more sense.

Just throwing this out there, another option could be using a fact in
puppet-openstacklib. We could create an os_service_default fact or
something named similarly that would be a static constant that could
be used for a parameter default and we could leverage it as part of
the is_service_default() function.  We would still require
puppet-openstacklib be included but we wouldn't need to do all the
inherits in the classes.  Just a thought.

Thanks,
-Alex


>
>
> --
> Cody
>
>
> __
> 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

Re: [openstack-dev] [puppet] service default value functions

[Alex Schultz]

On Wed, Sep 23, 2015 at 11:46 AM, Cody Herriges <c...@puppetlabs.com> wrote:
> Alex Schultz wrote:
>>> I've been mulling this over the last several days and I just can't
>>> accept an entire ruby function which would be ran for every parameter
>>> with the desired static value of "" when the class is
>>> declared and parsed.  I am not generally against using functions as a
>>> parameter default just not a fan in this case because running ruby just
>>> to return a static string seems inappropriate and not optimal.
>>>
>>> In this specific case I think the params pattern and inheritance can
>>> obtain us the same goals.  I also find this a valid us of inheritance
>>> cross module namespaces but...only because all our modules must depend
>>> on puppet-openstacklib.
>>>
>>> http://paste.openstack.org/show/473655
>>>
>>
>> Yes after thinking it over, I agree that the function for a parameter
>> is probably not the best route.  I think going the inheritance route
>> is a much more established pattern and would make more sense.
>>
>> Just throwing this out there, another option could be using a fact in
>> puppet-openstacklib. We could create an os_service_default fact or
>> something named similarly that would be a static constant that could
>> be used for a parameter default and we could leverage it as part of
>> the is_service_default() function.  We would still require
>> puppet-openstacklib be included but we wouldn't need to do all the
>> inherits in the classes.  Just a thought.
>>
>
> That is a viable option.  I can't recall which versions of puppet
> support facts.d but if all that we support do we could even make it 100%
> static and just put a file on disk with the contents
> "servicedefault=''.
>


I think it was 3.3 or 3.4 which are our minimums I believe.

-Alex

> --
> Cody
>
>
> __
> 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-dev] [puppet][swift] Applying security recommendations within puppet-swift

[Alex Schultz]

Hey all,

So as part of the Puppet mid-cycle, we did bug triage.  One of the
bugs that was looked into was bug 1289631[0].  This bug is about
applying the recommendations from the security guide[1] within the
puppet-swift module.  So I'm sending a note out to get other feedback
on if this is a good idea or not.  Should we be applying this type of
security items within the puppet modules by default? Should we make
this optional?  Thoughts?


Thanks,
-Alex


[0] https://bugs.launchpad.net/puppet-swift/+bug/1289631
[1] 
http://docs.openstack.org/security-guide/object-storage.html#securing-services-general

__
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

Re: [openstack-dev] [puppet][swift] Applying security recommendations within puppet-swift

[Alex Schultz]

On Wed, Sep 23, 2015 at 2:32 PM, Alex Schultz <aschu...@mirantis.com> wrote:
> Hey all,
>
> So as part of the Puppet mid-cycle, we did bug triage.  One of the
> bugs that was looked into was bug 1289631[0].  This bug is about
> applying the recommendations from the security guide[1] within the
> puppet-swift module.  So I'm sending a note out to get other feedback
> on if this is a good idea or not.  Should we be applying this type of
> security items within the puppet modules by default? Should we make
> this optional?  Thoughts?
>
>
> Thanks,
> -Alex
>
>
> [0] https://bugs.launchpad.net/puppet-swift/+bug/1289631
> [1] 
> http://docs.openstack.org/security-guide/object-storage.html#securing-services-general

Also for the puppet side of this conversation, the change for the
security items[0] also seems to conflict with bug 1458915[1] which is
about removing the posix users/groups/file modes.  So which direction
should we go?

[0] https://review.openstack.org/#/c/219883/
[1] https://bugs.launchpad.net/puppet-swift/+bug/1458915

__
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

Re: [openstack-dev] [fuel][swift] Separate roles for Swift nodes

[Alex Schultz]

Hey Daniel,

So that patch is the one I was referring to about supporting swift being
located elsewhere. That change would allow you to create a plugin with a
swift role and be able to override where swift is currently deployed.  We
had similar changes to support splitting off keystone/database/rabbitmq as
well. If you look at the plugins, we are creating hiera override data to
flip the switches within the existing fuel code to disable functionality on
the existing controller role. That change lists the hiera values you could
set in a plugin to override the values for a deployment.  You cannot use
the 'base-os' role as no additional puppet gets run for the 'base-os' role
and we don't do any network setup.

Thanks,
-Alex

On Wed, Sep 16, 2015 at 7:42 AM, Daniel Depaoli <
daniel.depa...@create-net.org> wrote:

> Alex, what about this patch https://review.openstack.org/#/c/188599/?
> Does it work? Is it possible to install swift in a 'base-os' role node?
>
> On Fri, Sep 11, 2015 at 4:11 PM, Alex Schultz <aschu...@mirantis.com>
> wrote:
>
>> Hey Daniel,
>>
>> So as part of the 7.0 work we added support in plugins to be able to
>> create roles and being able to separate roles from the existing system. I
>> think swift would be a good candidate for this.  I know we also added in
>> some support for an external swift configuration that will be helpful if
>> you choose to go down the plugin route.  As an example of a plugin where
>> we've separated roles from the controller (I believe swift currently lives
>> as part of the controller role), you can take a look at our keystone,
>> database and rabbitmq plugins:
>>
>> https://github.com/stackforge/fuel-plugin-detach-keystone
>> https://github.com/stackforge/fuel-plugin-detach-database
>> https://github.com/stackforge/fuel-plugin-detach-rabbitmq
>>
>> -Alex
>>
>> On Fri, Sep 11, 2015 at 2:24 AM, Daniel Depaoli <
>> daniel.depa...@create-net.org> wrote:
>>
>>> Hi all!
>>> I'm starting to investigate some improvements for swift installation in
>>> fuel, in paticular a way to dedicate a node for it. I found this blueprint
>>> https://blueprints.launchpad.net/fuel/+spec/swift-separate-role that
>>> seems to be what i'm looking for.
>>> The blueprint was accepted but not yet started. So, can someone tell me
>>> more about this blueprint? I'm interested in working for it.
>>>
>>> Best regards,
>>>
>>> --
>>> 
>>> Daniel Depaoli
>>> CREATE-NET Research Center
>>> Smart Infrastructures Area
>>> Junior Research Engineer
>>> 
>>>
>>>
>>> __
>>> 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
>>
>>
>
>
> --
> 
> Daniel Depaoli
> CREATE-NET Research Center
> Smart Infrastructures Area
> Junior Research Engineer
> 
>
> __
> 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-dev] [puppet] service default value functions

[Alex Schultz]

Hey puppet folks,

Based on the meeting yesterday[0], I had proposed creating a parser
function called is_service_default[1] to validate if a variable matched our
agreed upon value of ''.  This got me thinking about how
can we maybe not use the arbitrary string throughout the puppet that can
not easily be validated.  So I tested creating another puppet function
named service_default[2] to replace the use of ''
throughout all the puppet modules.  My tests seemed to indicate that you
can use a parser function as parameter default for classes.

I wanted to send a note to gather comments around the second function.
When we originally discussed what to use to designate for a service's
default configuration, I really didn't like using an arbitrary string since
it's hard to parse and validate. I think leveraging a function might be
better since it is something that can be validated via tests and a syntax
checker.  Thoughts?


Thanks,
-Alex

[0]
http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-09-15-15.00.html
[1] https://review.openstack.org/#/c/223672
[2] https://review.openstack.org/#/c/224187
__
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-dev] [fuel][fuel-library] modules managed with librarian round 2

[Alex Schultz]

Hello!

So after our first round of librarian changes for 7.0, it is time to start
switching to upstream for more changes.  We've had a few updates during the
fuel meetings over the last month[0][1].  I have begun to prepare
additional reviews to move modules.

The current modules available for migration are:

memcached - https://review.openstack.org/#/c/217383/
sysctl - https://review.openstack.org/#/c/221945/
staging - https://review.openstack.org/#/c/222350/
vcsrepo - https://review.openstack.org/#/c/222355/
postgresql - https://review.openstack.org/#/c/222368/


Just as an FYI in addition to these modules, I have started work on the
rsyslog module which was a very old version of the module with only a few
minor customizations. Since we leverage the rsyslog module within our
openstack composition layer module, I have also taken some time to put
together a patch[2] with some unit tests for the openstack module in fuel
library since what was there has been disabled[3] for some time and doesn't
function.  The patch[4] with the move to an upstream version of rsyslog is
out there as well if anyone is interested in taking a look. I'm going to do
some additional testing around these two patches to ensure we don't break
any syslog functionality by switching before they should be merged.

Thanks,
-Alex

[0]
http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-08-27-16.00.html
[1]
http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-09-03-16.00.html
[2] https://review.openstack.org/#/c/223395/
[3]
https://github.com/stackforge/fuel-library/blob/master/utils/jenkins/modules.disable_rspec#L29
[4] https://review.openstack.org/#/c/222758/
__
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

Re: [openstack-dev] [fuel][swift] Separate roles for Swift nodes

[Alex Schultz]

Hey Daniel,

So as part of the 7.0 work we added support in plugins to be able to create
roles and being able to separate roles from the existing system. I think
swift would be a good candidate for this.  I know we also added in some
support for an external swift configuration that will be helpful if you
choose to go down the plugin route.  As an example of a plugin where we've
separated roles from the controller (I believe swift currently lives as
part of the controller role), you can take a look at our keystone, database
and rabbitmq plugins:

https://github.com/stackforge/fuel-plugin-detach-keystone
https://github.com/stackforge/fuel-plugin-detach-database
https://github.com/stackforge/fuel-plugin-detach-rabbitmq

-Alex

On Fri, Sep 11, 2015 at 2:24 AM, Daniel Depaoli <
daniel.depa...@create-net.org> wrote:

> Hi all!
> I'm starting to investigate some improvements for swift installation in
> fuel, in paticular a way to dedicate a node for it. I found this blueprint
> https://blueprints.launchpad.net/fuel/+spec/swift-separate-role that
> seems to be what i'm looking for.
> The blueprint was accepted but not yet started. So, can someone tell me
> more about this blueprint? I'm interested in working for it.
>
> Best regards,
>
> --
> 
> Daniel Depaoli
> CREATE-NET Research Center
> Smart Infrastructures Area
> Junior Research Engineer
> 
>
> __
> 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

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

[Alex Schultz]

I agree that we shouldn't need to sync as we should be able to just update
the fuel-library package. That being said, I think there might be a few
issues with this method. The first issue is with plugins and how to
properly handle the distribution of the plugins as they may also include
puppet code that needs to be installed on the other nodes for a deployment.
Currently I do not believe we install the plugin packages anywhere except
the master and when they do get installed there may be some post-install
actions that are only valid for the master.  Another issue is being
flexible enough to allow for deployment engineers to make custom changes
for a given environment.  Unless we can provide an improved process to
allow for people to provide in place modifications for an environment, we
can't do away with the rsync.

If we want to go completely down the package route (and we probably
should), we need to make sure that all of the other pieces that currently
go together to make a complete fuel deployment can be updated in the same
way.

-Alex

On Wed, Sep 9, 2015 at 8:15 AM, Andrey Danin  wrote:

> I don't think juggling with repos and pull requests is easier than direct
> editing of files on Fuel node. Do we have Perestorika installed on Fuel
> node in 7.0?
>
> On Wed, Sep 9, 2015 at 3:47 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Andrey,
>>
>> This change is going to make things even easier. Currently you don't need
>> to build fuel-library package manually, Perestroika is going to do it for
>> you. It builds necessary packages during minutes for every review request
>> and packaging ci even tests it for you. You just need to make necessary
>> changes not on master node but on your MACBOOK using your favorite editor.
>> Then you need to commit this change and send this patch on review. If you
>> want to test this patch manually, you just need to append this CR repo
>> (example is here [1]) to the list of repos you define for your cluster and
>> start deployment. Anyway, you still have rsync, mcollective and other old
>> plain tools to run deployment manually.
>>
>> [1] http://perestroika-repo-tst.infra.mirantis.net/review/CR-221719/
>>
>>
>>
>> Vladimir Kozhukalov
>>
>> On Wed, Sep 9, 2015 at 2:48 PM, Dmitry Pyzhov 
>> wrote:
>>
>>> Vladimir,
>>>
>>> thanks for bringing this up. It greatly correlates with the idea of
>>> modularity. Everything related to an openstack release should be put in one
>>> place and should be managed as a solid bundle on the master node. Package
>>> repository is the first solution that comes to the mind and it looks pretty
>>> good. Puppet modules, openstack.yaml and maybe even serialisers should be
>>> stored in packages in the openstack release repository. And eventually
>>> every other piece of our software should get rid of release-specific logic.
>>>
>>> On Tue, Sep 8, 2015 at 11:41 PM, Vladimir Kozhukalov <
>>> vkozhuka...@mirantis.com> wrote:
>>>
 Dear colleagues,

 Currently, we install fuel-libraryX.Y package(s) on the master node and
 then right before starting actual deployment we rsync [1] puppet modules
 (one of installed versions) from the master node to slave nodes. Such a
 flow makes things much more complicated than they could be if we installed
 puppet modules on slave nodes as rpm/deb packages. Deployment itself is
 parameterized by repo urls (upstream + mos) and this pre-deployment task
 could be nothing more than just installing fuel-library package from mos
 repo defined for a cluster. We would not have several versions of
 fuel-library on the master node, we would not need that complicated upgrade
 stuff like we currently have for puppet modules.

 Please give your opinions on this.


 [1]
 https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/tasks_serializer.py#L205-L218

 Vladimir Kozhukalov


 __
 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
>>
>>
>
>
> --
> Andrey Danin
> ada...@mirantis.com
> skype: gcon.monolake
>
> 

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

[Alex Schultz]

Hey Vladimir,



> Regarding plugins: plugins are welcome to install specific additional
> DEB/RPM repos on the master node, or just configure cluster to use
> additional onl?ne repos, where all necessary packages (including plugin
> specific puppet manifests) are to be available. Current granular deployment
> approach makes it easy to append specific pre-deployment tasks
> (master/slave does not matter). Correct me if I am wrong.
>
>
Don't get me wrong, I think it would be good to move to a fuel-library
distributed via package only.  I'm bringing these points up to indicate
that there is many other things that live in the fuel library puppet path
than just the fuel-library package.  The plugin example is just one place
that we will need to invest in further design and work to move to the
package only distribution.  What I don't want is some partially executed
work that only works for one type of deployment and creates headaches for
the people actually having to use fuel.  The deployment engineers and
customers who actually perform these actions should be asked about
packaging and their comfort level with this type of requirements.  I don't
have a complete understanding of the all the things supported today by the
fuel plugin system so it would be nice to get someone who is more familiar
to weigh in on this idea. Currently plugins are only rpms (no debs) and I
don't think we are building fuel-library debs at this time either.  So
without some work on both sides, we cannot move to just packages.


> Regarding flexibility: having several versioned directories with puppet
> modules on the master node, having several fuel-libraryX.Y packages
> installed on the master node makes things "exquisitely convoluted" rather
> than flexible. Like I said, it is flexible enough to use mcollective, plain
> rsync, etc. if you really need to do things manually. But we have
> convenient service (Perestroika) which builds packages in minutes if you
> need. Moreover, In the nearest future (by 8.0) Perestroika will be
> available as an application independent from CI. So, what is wrong with
> building fuel-library package? What if you want to troubleshoot nova (we
> install it using packages)? Should we also use rsync for everything else
> like nova, mysql, etc.?
>
>
Yes, we do have a service like Perestroika to build packages for us.  That
doesn't mean everyone else does or has access to do that today.  Setting up
a build system is a major undertaking and making that a hard requirement to
interact with our product may be a bit much for some customers.  In
speaking with some support folks, there are times when files have to be
munged to get around issues because there is no package or things are on
fire so they can't wait for a package to become available for a fix.  We
need to be careful not to impose limits without proper justification and
due diligence.  We already build the fuel-library package, so there's no
reason you couldn't try switching the rsync to install the package if it's
available on a mirror.  I just think you're going to run into the issues I
mentioned which need to be solved before we could just mark it done.

-Alex



> Vladimir Kozhukalov
>
> On Wed, Sep 9, 2015 at 4:39 PM, Alex Schultz <aschu...@mirantis.com>
> wrote:
>
>> I agree that we shouldn't need to sync as we should be able to just
>> update the fuel-library package. That being said, I think there might be a
>> few issues with this method. The first issue is with plugins and how to
>> properly handle the distribution of the plugins as they may also include
>> puppet code that needs to be installed on the other nodes for a deployment.
>> Currently I do not believe we install the plugin packages anywhere except
>> the master and when they do get installed there may be some post-install
>> actions that are only valid for the master.  Another issue is being
>> flexible enough to allow for deployment engineers to make custom changes
>> for a given environment.  Unless we can provide an improved process to
>> allow for people to provide in place modifications for an environment, we
>> can't do away with the rsync.
>>
>> If we want to go completely down the package route (and we probably
>> should), we need to make sure that all of the other pieces that currently
>> go together to make a complete fuel deployment can be updated in the same
>> way.
>>
>> -Alex
>>
>>
__
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

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Alex Schultz]

Hey Vladimir,


>
> The idea is to remove MOS DEB repo from the Fuel master node by default
> and use online MOS repo instead. Pros of such an approach are:
>
> 0) Reduced requirement for the master node minimal disk space
>

Is this a problem? How much disk space is saved If I have to go create a
local mirror via fuel-createmirror?


> 1) There won't be such things in like [1] and [2], thus less complicated
> flow, less errors, easier to maintain, easier to understand, easier to
> troubleshoot
> 2) If one wants to have local mirror, the flow is the same as in case of
> upstream repos (fuel-createmirror), which is clrear for a user to
> understand.
>

>From the issues I've seen,  fuel-createmirror isn't very straight forward
and has some issues making it a bad UX.


>
> Many people still associate ISO with MOS, but it is not true when using
> package based delivery approach.
>
> It is easy to define necessary repos during deployment and thus it is easy
> to control what exactly is going to be installed on slave nodes.
>
> What do you guys think of it?
>
>
>
Reliance on internet connectivity has been an issue since 6.1. For many
large users, complete access to the internet is not available or not
desired.  If we want to continue down this path, we need to improve the
tools to setup the local mirror and properly document what urls/ports/etc
need to be available for the installation of openstack and any mirror
creation process.  The ideal thing is to have an all-in-one CD similar to a
live cd that allows a user to completely try out fuel wherever they want
with out further requirements of internet access.  If we don't want to
continue with that, we need to do a better job around providing the tools
for a user to get up and running in a timely fashion.  Perhaps providing an
net-only iso and an all-included iso would be a better solution so people
will have their expectations properly set up front?

-Alex


>
> Vladimir Kozhukalov
>
> On Tue, Sep 8, 2015 at 4:53 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> The idea is to remove MOS DEB repo from the Fuel master node by default
>> and use online MOS repo instead. Pros of such an approach are:
>>
>> 0) Reduced requirement for the master node minimal disk space
>> 1) There won't be such things in like [1] and [2], thus less complicated
>> flow, less errors, easier to maintain, easier to understand, easier to
>> troubleshoot
>> 2) If one wants to have local mirror, the flow is the same as in case of
>> upstream repos (fuel-createmirror), which is clrear for a user to
>> understand.
>>
>> Many people still associate ISO with MOS
>>
>>
>>
>>
>>
>> [1]
>> https://github.com/stackforge/fuel-main/blob/master/iso/ks.template#L416-L419
>> [2]
>> https://github.com/stackforge/fuel-web/blob/master/fuel_upgrade_system/fuel_upgrade/fuel_upgrade/engines/host_system.py#L109-L115
>>
>>
>> Vladimir Kozhukalov
>>
>
>
> __
> 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

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Alex Schultz]

Hey Vladimir,


>
>
>> 1) There won't be such things in like [1] and [2], thus less complicated
>>> flow, less errors, easier to maintain, easier to understand, easier to
>>> troubleshoot
>>> 2) If one wants to have local mirror, the flow is the same as in case of
>>> upstream repos (fuel-createmirror), which is clrear for a user to
>>> understand.
>>>
>>
>> From the issues I've seen,  fuel-createmirror isn't very straight forward
>> and has some issues making it a bad UX.
>>
>
> I'd say the whole approach of having such tool as fuel-createmirror is a
> way too naive. Reliable internet connection is totally up to network
> engineering rather than deployment. Even using proxy is much better that
> creating local mirror. But this discussion is totally out of the scope of
> this letter. Currently,  we have fuel-createmirror and it is pretty
> straightforward (installed as rpm, has just a couple of command line
> options). The quality of this script is also out of the scope of this
> thread. BTW we have plans to improve it.
>


Fair enough, I just wanted to raise the UX issues around these types of
things as they should go into the decision making process.



>
>>
>>> Many people still associate ISO with MOS, but it is not true when using
>>> package based delivery approach.
>>>
>>> It is easy to define necessary repos during deployment and thus it is
>>> easy to control what exactly is going to be installed on slave nodes.
>>>
>>> What do you guys think of it?
>>>
>>>
>>>
>> Reliance on internet connectivity has been an issue since 6.1. For many
>> large users, complete access to the internet is not available or not
>> desired.  If we want to continue down this path, we need to improve the
>> tools to setup the local mirror and properly document what urls/ports/etc
>> need to be available for the installation of openstack and any mirror
>> creation process.  The ideal thing is to have an all-in-one CD similar to a
>> live cd that allows a user to completely try out fuel wherever they want
>> with out further requirements of internet access.  If we don't want to
>> continue with that, we need to do a better job around providing the tools
>> for a user to get up and running in a timely fashion.  Perhaps providing an
>> net-only iso and an all-included iso would be a better solution so people
>> will have their expectations properly set up front?
>>
>
> Let me explain why I think having local MOS mirror by default is bad:
> 1) I don't see any reason why we should treat MOS  repo other way than all
> other online repos. A user sees on the settings tab the list of repos one
> of which is local by default while others are online. It can make user a
> little bit confused, can't it? A user can be also confused by the fact,
> that some of the repos can be cloned locally by fuel-createmirror while
> others can't. That is not straightforward, NOT fuel-createmirror UX.
>


I agree. The process should be the same and it should be just another repo.
It doesn't mean we can't include a version on an ISO as part of a release.
Would it be better to provide the mirror on the ISO but not have it enabled
by default for a release so that we can gather user feedback on this? This
would include improved documentation and possibly allowing a user to choose
their preference so we can collect metrics?


2) Having local MOS mirror by default makes things much more convoluted. We
> are forced to have several directories with predefined names and we are
> forced to manage these directories in nailgun, in upgrade script, etc. Why?
> 3) When putting MOS mirror on ISO, we make people think that ISO is equal
> to MOS, which is not true. It is possible to implement really flexible
> delivery scheme, but we need to think of these things as they are
> independent.
>


I'm not sure what you mean by this. Including a point in time copy on an
ISO as a release is a common method of distributing software. Is this a
messaging thing that needs to be addressed? Perhaps I'm not familiar with
people referring to the ISO as being MOS.


For large users it is easy to build custom ISO and put there what they need
> but first we need to have simple working scheme clear for everyone. I think
> dealing with all repos the same way is what is gonna makes things simpler.
>
>

Who is going to build a custom ISO? How does one request that? What
resources are consumed by custom ISO creation process/request? Does this
scale?



> This thread is not about internet connectivity, it is about aligning
> things.
>
>
You are correct in that this thread is not explicitly about internet
connectivity, but they are related. Any changes to remove a local
repository and only provide an internet based solution makes internet
connectivity something that needs to be included in the discussion.  I just
want to make sure that we properly evaluate this decision based on end user
feedback not because we don't want to manage this from a developer
standpoint.

-Alex

Re: [openstack-dev] [ec2api][puppet] EC2 api puppet module

[Alex Schultz]

Hey Marcos,

On Tue, Sep 1, 2015 at 7:50 AM, Marcos Fermin Lobo <
marcos.fermin.l...@cern.ch> wrote:

> Hi all,
>
> The standalone EC2 api project https://github.com/stackforge/ec2-api does
> not have puppet module yet. I want to develop this puppet module and my
> idea is start in a public Github repo and get feedback from the community.
> All feedback and collaborations will be very welcome.
>
> I would like to start requesting your suggestions about the Github
> repository name. I would suggest: puppet-ec2-api
>
>

Just a note I don't think dashes are allowed in the puppet module name or
if they are it may lead to some weirdness[0][1]. So puppet-ec2api might be
better.




> Sounds good for you people?, more suggestions?.
>
> Thank you.
>
> Regards,
> Marcos.
>
>

Thanks,
-Alex



[0] https://projects.puppetlabs.com/issues/5268
[1] https://tickets.puppetlabs.com/browse/PUP-1397
__
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

Re: [openstack-dev] [Fuel] Console messages in Mirantis 6.1

[Alex Schultz]

Hey Evgeniya,



On Tue, Aug 4, 2015 at 8:59 AM, Evgeniya Shumakher eshumak...@mirantis.com
wrote:


 Fuel team,

 One of Fuel 6.1 users found a very annoying bug:

 I’ve installed new Mirantis 6.1 a couple of weeks ago and I’m seeing the
 following message on both Controller and Compute node consoles.

 “netlink: 20 bytes leftover after parsing attributes”

 There are several references to this bug:
 -  https://bugs.launchpad.net/fuel/+bug/1447543
 -  https://bugs.launchpad.net/fuel/+bug/1449914

 This messages don’t show in the SSH consoles, so I was able to configure
 all nodes for SSH access and sort of bypass this issue.

 So, it’s not critical to resolve it, but I have not seen any officially
 posted resolutions… Would you happen to know the status of this resolution?

 Thanks in advance!


 Do I understand that the bug is medium and might not be fixed?
 What would be the recommended response to this user?
 Can we add information about this feature to Fuel documentation?


The bug for this issue is https://bugs.launchpad.net/fuel/+bug/180.  It
is unfortunately an upstream (centos 6) issue that I don't believe we will
be fixing.  The messages themselves are not an issue but they do take up
space in logs so if that is a problem, we would need to fix that via proper
log rotation.  Do we have reports of excessive logs due to netlink error
messages?



 Thank you.

 --
 Evgeniya



 __
 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


Thanks,
-Alex
__
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

Re: [openstack-dev] [fuel][fuel-library] Librarian changes

[Alex Schultz]

To follow up on the merge schedule as we've merged some items and the apt
mirror issue has been resolved.

Friday 7/31 (COMPLETE)
librarian - https://review.openstack.org/#/c/202763/
stdlib - https://review.openstack.org/#/c/203386/

Monday 8/3 (COMPLETE)
concat - https://review.openstack.org/#/c/203387/
inifile - https://review.openstack.org/#/c/203395/

Tuesday 8/4 (COMPLETE)
xinetd - https://review.openstack.org/#/c/203393/
ssh - https://review.openstack.org/#/c/203392/

Wednesday 8/5 (On target)
ntp - https://review.openstack.org/#/c/203390/

Thursday 8/6
apache - https://review.openstack.org/#/c/203388/
apt - https://review.openstack.org/#/c/203389/

Monday 8/10
firewall - https://review.openstack.org/#/c/203396/

I have reached out to those responsible for the cinder module and they are
OK with merging this provided QA signs off on a custom iso with this
change.  I plan on getting the iso together today and hopefully can get a
QA resource to test cinder out thoroughly.  If QA is ok, this should be
merged on Tuesday 8/11.
cinder - https://review.openstack.org/#/c/203394/


Thanks,
-Alex

On Fri, Jul 31, 2015 at 12:11 PM, Alex Schultz aschu...@mirantis.com
wrote:

 Here is the proposed schedule and adjusted ordering based on risk due to
 code changes. Please let me know if you would like any of these dates
 changed.  You will see that I have bumped modules that were upgrades to
 later so that we can stop prior to this changes if we feel they are too
 risky.  We should be safe due to zero puppet code changes up until the ssh
 module.

 Today 7/31
 librarian - https://review.openstack.org/#/c/202763/
 stdlib - https://review.openstack.org/#/c/203386/

 Monday 8/3
 concat - https://review.openstack.org/#/c/203387/
 inifile - https://review.openstack.org/#/c/203395/

 Tuesday 8/4
 xinetd - https://review.openstack.org/#/c/203393/
 ssh - https://review.openstack.org/#/c/203392/

 Wednesday 8/5
 ntp - https://review.openstack.org/#/c/203390/

 Thursday 8/6
 apache - https://review.openstack.org/#/c/203388/

 Monday 8/10
 firewall - https://review.openstack.org/#/c/203396/

 This commit should be signed off by the teams who will ultimately be
 responsible for it to ensure they are familiar with the workflows
 involved[0]. It has no code changes, but may impact bug fixing so we may
 want to wait until 8.0 for this. If not, it should be done last.
 cinder - https://review.openstack.org/#/c/203394/

 This cannot be merged until we get a fuel-infra mirror, but is a change
 with no code changes so can be done whenever the mirror gets resolved.
 apt - https://review.openstack.org/#/c/203389/

 If at any point there are issues and we decide to revert back, they
 commits just need to be reverted in reverse order and we can use the webui
 to do so.  I will finish re-ordering the patches today, but we should be OK
 through the ntp module at this time.

 Thanks,
 -Alex

 [0] https://wiki.openstack.org/wiki/Fuel/Library_and_Upstream_Modules

 On Fri, Jul 31, 2015 at 11:39 AM, Vladimir Kuklin vkuk...@mirantis.com
 wrote:

 Okay, folks, we had a short meeting to synchronize our vision of how it
 should happen.

 We will start by merging least-invasive modules like stdlib today and
 then continue doing merges one by one in discrete manner and revert things
 immediately if something goes wrong.

 So there is a list of action items:

 Alex Schultz will send a schedule of which modules will be merged on
 which week and ensure that core reviewers know which commits they should
 merge when either by keeping W-1 on particular commits or by sharing the
 schedule in commit message so that noone can forget about it or maybe some
 other conveinent method that he can invent.

 I will remove my -2 for the inital librarian commit.


 Thanks everyone for the collaboration and not calling me a selfish
 lunatic :-)


 On Fri, Jul 31, 2015 at 6:29 PM, Mike Scherbakov 
 mscherba...@mirantis.com wrote:

 Vladimir,
 can you please elaborate on such invasive changes?

 There was a plan developed, including risk mitigation, etc. - like do
 'grep -r' to check, and revert the change all together right away if we see
 regression. So far, everyone was aligned with the plan. It was discussed
 yesterday during IRC meeting [1]. Again, no one had objections.

 Please provide your concerns, explain your opinion in more details. I'd
 like other core reviewers to jump in here and reply. If you need details of
 the approach, please jump in a call with Alex Schultz.

 Thank you,

 [1]
 http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-07-30-16.00.html

 On Fri, Jul 31, 2015 at 5:52 AM Vladimir Kuklin vkuk...@mirantis.com
 wrote:

 Folks

 I do actively support our initiative to use librarian to be as close as
 possible to upstream, but let's not merge such invasive changes until we
 announce Hard Code Freeze and create stable/7.0 branch. So far I put my -2
 onto the first commit in the chain. Let's get through 7.0 and then land
 this code

Re: [openstack-dev] [fuel][fuel-library] Librarian changes

[Alex Schultz]

Here is the proposed schedule and adjusted ordering based on risk due to
code changes. Please let me know if you would like any of these dates
changed.  You will see that I have bumped modules that were upgrades to
later so that we can stop prior to this changes if we feel they are too
risky.  We should be safe due to zero puppet code changes up until the ssh
module.

Today 7/31
librarian - https://review.openstack.org/#/c/202763/
stdlib - https://review.openstack.org/#/c/203386/

Monday 8/3
concat - https://review.openstack.org/#/c/203387/
inifile - https://review.openstack.org/#/c/203395/

Tuesday 8/4
xinetd - https://review.openstack.org/#/c/203393/
ssh - https://review.openstack.org/#/c/203392/

Wednesday 8/5
ntp - https://review.openstack.org/#/c/203390/

Thursday 8/6
apache - https://review.openstack.org/#/c/203388/

Monday 8/10
firewall - https://review.openstack.org/#/c/203396/

This commit should be signed off by the teams who will ultimately be
responsible for it to ensure they are familiar with the workflows
involved[0]. It has no code changes, but may impact bug fixing so we may
want to wait until 8.0 for this. If not, it should be done last.
cinder - https://review.openstack.org/#/c/203394/

This cannot be merged until we get a fuel-infra mirror, but is a change
with no code changes so can be done whenever the mirror gets resolved.
apt - https://review.openstack.org/#/c/203389/

If at any point there are issues and we decide to revert back, they commits
just need to be reverted in reverse order and we can use the webui to do
so.  I will finish re-ordering the patches today, but we should be OK
through the ntp module at this time.

Thanks,
-Alex

[0] https://wiki.openstack.org/wiki/Fuel/Library_and_Upstream_Modules

On Fri, Jul 31, 2015 at 11:39 AM, Vladimir Kuklin vkuk...@mirantis.com
wrote:

 Okay, folks, we had a short meeting to synchronize our vision of how it
 should happen.

 We will start by merging least-invasive modules like stdlib today and then
 continue doing merges one by one in discrete manner and revert things
 immediately if something goes wrong.

 So there is a list of action items:

 Alex Schultz will send a schedule of which modules will be merged on which
 week and ensure that core reviewers know which commits they should merge
 when either by keeping W-1 on particular commits or by sharing the schedule
 in commit message so that noone can forget about it or maybe some other
 conveinent method that he can invent.

 I will remove my -2 for the inital librarian commit.


 Thanks everyone for the collaboration and not calling me a selfish lunatic
 :-)


 On Fri, Jul 31, 2015 at 6:29 PM, Mike Scherbakov mscherba...@mirantis.com
  wrote:

 Vladimir,
 can you please elaborate on such invasive changes?

 There was a plan developed, including risk mitigation, etc. - like do
 'grep -r' to check, and revert the change all together right away if we see
 regression. So far, everyone was aligned with the plan. It was discussed
 yesterday during IRC meeting [1]. Again, no one had objections.

 Please provide your concerns, explain your opinion in more details. I'd
 like other core reviewers to jump in here and reply. If you need details of
 the approach, please jump in a call with Alex Schultz.

 Thank you,

 [1]
 http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-07-30-16.00.html

 On Fri, Jul 31, 2015 at 5:52 AM Vladimir Kuklin vkuk...@mirantis.com
 wrote:

 Folks

 I do actively support our initiative to use librarian to be as close as
 possible to upstream, but let's not merge such invasive changes until we
 announce Hard Code Freeze and create stable/7.0 branch. So far I put my -2
 onto the first commit in the chain. Let's get through 7.0 and then land
 this code in the master as early as possible after HCF.


 On Fri, Jul 31, 2015 at 3:21 PM, Aleksandra Fedorova 
 afedor...@mirantis.com wrote:

  So far CI has been successful on all of these
 changes, and bvt is currently running.

 Small update - BVT test passed.

 On Fri, Jul 31, 2015 at 6:27 AM, Alex Schultz aschu...@mirantis.com
 wrote:
  Hey everyone,
 
  During on the fuel meeting today we discussed the librarian changes
 and
  their status.
  As part of this work, the wiki page was updated and a first attempt at
  migrating the
  following modules has been completed pending merge:
 
  stdlib
  concat
  inifile
  ssh
  ntp
  apache
  firewall
  xinetd
  cinder
  apt*
 
  It should be noted that apt is currently blocked by the lack of a
 mirror so
  while it has
  been prepared, it should not be merged at this time.
 
  As part of this migration we are doing two things. The first is an
 update to
  the build
  process that is included as part of the initial librarian[0] patch.
 The
  other patches
  consist of the actual module code changes.
 
  Here is the list of the diffs for each change so that it can be
 reviewed and
  people can
  raise concerns if there are any with this change. As part of the
 migration,
  I

Re: [openstack-dev] [fuel][puppet] Fuel Library and upstream modules

[Alex Schultz]

Hey Emilien,

On Wed, Jul 29, 2015 at 5:16 PM, Emilien Macchi emil...@redhat.com wrote:



 This is a very good initiative and I'm happy to see that happening. It
 reflects what I was asking in our collaboration request.

 Though I have one suggestion for Custom Upstream Module Changes section.
 I suggest you:

 1/ first submit the change in the upstream module
 2/ cherry-pick the commit in Fuel custom branch
 3/ keep track of upstream patch (address reviews, etc), and establish a
 sort of scoring to evaluate the debt [1] between downstream (Fuel) and
 upstream (OpenStack). It will make sure a maximum of code is upstream
 and downstream patches won't be forgotten.
 4/ when an upstream patch is merged, drop the cherry-pick by rebasing.


Thanks, I have updated the page to reference using the cherry-pick option.
I think this sounds better than what was there previously.



 This is the workflow I try to push at Red Hat (in RDO) and to me, this
 is the way to go for having Puppet modules the closest as possible from
 upstream with the freedom to have custom patches downstream.

 Best,

 [1] https://github.com/redhat-cip/debtor
 --
 Emilien Macchi


 __
 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



Thanks,
-Alex
__
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-dev] [fuel][fuel-library] Librarian changes

[Alex Schultz]

Hey everyone,

During on the fuel meeting today we discussed the librarian changes and
their status.
As part of this work, the wiki page was updated and a first attempt at
migrating the
following modules has been completed pending merge:

stdlib
concat
inifile
ssh
ntp
apache
firewall
xinetd
cinder
apt*

It should be noted that apt is currently blocked by the lack of a mirror so
while it has
been prepared, it should not be merged at this time.

As part of this migration we are doing two things. The first is an update
to the build
process that is included as part of the initial librarian[0] patch.  The
other patches
consist of the actual module code changes.

Here is the list of the diffs for each change so that it can be reviewed
and people can
raise concerns if there are any with this change. As part of the migration,
I inspected
the code and file differences for each module to determine how much impact
they might
have.  I chose the list of modules based on their minimal differences from
the upstream
or if they already had our forked differences rolled into a newer version
of the module.
For this list, I took the current stable iso (#110) and rebased the changes
on top of this
to create a custom iso with just the librarian changes. We have kicked off
a bvt_2 test for
the custom iso as well. From this iso I have extracted the fuel-library
package from both
of these isos and exploded the fuel-library folder structure to do the
diffs.

Code Changes:

For stdlib, the only differences are related to git, travis or
fixtures[1].  There are no
puppet code changes as part of the librarian migration.

For concat, the only differences were a git folder and in a custom change
to the spec tests[2].
The test difference[3], was a change we made because it was failing our
syntax checker.
This change has been included in a newer version of concat (1.2.4) but are
not necessary
when the module gets moved to be included via librarian.

For inifile, the only difference is the addition of git and metadata
files[4].

For ssh, the only difference is a single line to have the config notify
service[5]. This
difference is already covered by another file and is not needed[6].

For ntp, this change introduces more code changes[7] because we are
updating the module
to the 4.0.0 version because of previous extending of functionality that is
now covered by
4.0.0 vs 3.3.0[8]. The changes in our fork were upstreamed and are include
in 4.0.0.

For apache, this change includes an upgrade from 1.2.0 to 1.3.0[9][10]. Our
fork had a
customization made which was contributed upstream.
(apache::mod::proxy_connect)

For firewall, this change also includes an upgrade from 1.0.2 to 1.2.0[11]
as our fork had
mac supported added[12] in which is now covered upstream.

For xinetd, the only change was the addition of a .git folder and a
.gitignore with librarian.

For cinder, the only change was the addition of .git, .gitignore, and
.gitreview.

Once we can get the apt mirror created, the only change for that is also
the addition of
.git.


If there are any of these upgrades/changes that we do not want to tackle
right now, I can
adjust the review order such that it can be skipped for now.  Please take
some time to
review these changes and raise concerns.  So far CI has been successful on
all of these
changes, and bvt is currently running.

Also please take some time to review the changes themselves:
https://review.openstack.org/#/q/status:open+project:stackforge/fuel-library+branch:master+topic:bp/fuel-puppet-librarian,n,z

Please raise any concerns as quickly as possible as this is the last call
for objections
for these reviews.  This has been talked about extensively and these
reviews have
been available for several weeks now.

Thanks,
-Alex


[0] https://review.openstack.org/#/c/202763/
[1] http://paste.openstack.org/show/406523/
[2] http://paste.openstack.org/show/406524/
[3] http://paste.openstack.org/show/406525/
[4] http://paste.openstack.org/show/406526/
[5] http://paste.openstack.org/show/406527/
[6]
https://github.com/saz/puppet-ssh/blob/v2.4.0/manifests/server/config.pp#L9
[7] http://paste.openstack.org/show/406536/
[8] https://github.com/puppetlabs/puppetlabs-ntp/compare/3.3.0...4.0.0
[9] http://paste.openstack.org/show/406538/
[10] https://github.com/puppetlabs/puppetlabs-apache/compare/1.2.0...1.3.0
[11] https://github.com/puppetlabs/puppetlabs-firewall/compare/1.0.2...1.2.0
[12] https://review.openstack.org/#/c/92167/
__
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-dev] [fuel][puppet] Fuel Library and upstream modules

[Alex Schultz]

Hello everyone,

I have put together a wiki describing the proposed interactions between
fuel-library and upstream modules based on previous talks around
librarian-puppet[0].  Please take some time to review
https://wiki.openstack.org/wiki/Fuel/Library_and_Upstream_Modules.  This
page provides a brief history of this change, details of the changes, best
practices, and workflows for dealing with upstream modules.

I have updated this page based on the feedback previously solicited around
my suggestion to use librarian-puppet to manage the inclusion of upstream
modules into fuel-library. During the implementation, we found that
packaging librarian-puppet and the dependency management became burdensome.
As a substitute, we have packaged librarian-puppet-simple and will only be
using git repository references for inclusion of upstream modules.  Also
based on our build requirements, we are also leveraging a fuel-infra mirror
of upstream repositories to allow for local builds and CI to not have to
fetch modules continuously from upstream github repositories.

I have also taken the time to update the proposed patches[1] with the
librarian-puppet-simple configurations so they they are ready to merge if
there is an agreement on this process.

Thanks,
-Alex

[0] http://lists.openstack.org/pipermail/openstack-dev/2015-June/067806.html
[1]
https://review.openstack.org/#/q/topic:bp/fuel-puppet-librarian+project:stackforge/fuel-library,n,z
__
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

Re: [openstack-dev] Which is the correct way to set ha queues in RabbitMQ

[Alex Schultz]

https://www.rabbitmq.com/ha.html

Both?  I think ha_all/HA is just the policy name and so it can be whatever
you want.

-Alex

On Tue, Jul 28, 2015 at 2:17 AM, Alvise Dorigo alvise.dor...@pd.infn.it
wrote:

  Hi,
 I read these two documents:


 http://docs.openstack.org/high-availability-guide/content/_configure_rabbitmq.html

 https://www.rdoproject.org/RabbitMQ

 To configure the queues in HA mode, the two docs suggests two slightly
 different commands;

 The first one says:

 rabbitmqctl set_policy ha-all '^(?!amq\.).*' '{ha-mode: all}'


 while the second one says:

 rabbitmqctl set_policy HA '^(?!amq\.).*' '{ha-mode: all}'


 ha_all vs. HA.

 which one is correct ?

 thanks,

 Alvise

 __
 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

Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library

[Alex Schultz]

Just to followup since the required packages are finally available, the
patches have been updated and are passing CI now.

https://review.openstack.org/#/c/202763/

-Alex

On Fri, Jul 24, 2015 at 8:32 AM, Alex Schultz aschu...@mirantis.com wrote:

 Unfortunately we got stuck with package availability issues. It was
 successful without using librarian packages for building, but since we need
 to leverage packages the work to get packaged versions of the code has
 unfortunately blocked this. I've got the packages built, but the time to
 get them to an publicly available mirror has killed this effort. Since it's
 now past FF, I don't think this will be for 7.0 but we should be in a good
 spot to start early for 8.0.  Also I've switched to librarian-puppet-simple
 since it has far fewer dependencies and we only want to support git
 references for packages.  Once that makes it to the mirror and can pass CI,
 this change would in theory be ready.  I'm continuing to keep an eye on the
 changes so that we'll be ready to start running with them when the time
 comes.

 -Alex

 On Fri, Jul 24, 2015 at 1:41 AM, Mike Scherbakov mscherba...@mirantis.com
  wrote:

 Do we have any success here.. ?

 On Mon, Jul 20, 2015 at 8:32 AM Alex Schultz aschu...@mirantis.com
 wrote:

 Vladimir,

 Thanks.  Can you point me to the error for perestroika? I'd be happy to
 take a look as well. I spent most of Friday throwing various options at the
 CI system to try and figure out how to get the spec to work with the CI
 fuel-library package building so perhaps there's a different way to handle
 this in the spec.

 -Alex

 On Mon, Jul 20, 2015 at 10:02 AM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Alex,

 As I've just found out this package available here [1] is not actually
 build with your patch (instead it is from previous successful build). Looks
 like perestroika can not build this package due to some environment
 related issues. I've poked Dmitry Burmistrov to check it out.
 However, your patch is OK, make system can build this package and ISO
 passes BVT tests.


 [1]
 http://172.18.160.74/osci/review/CR-202763/mos/7.0/fuel/base/centos6/Packages/fuel-library7.0-7.0.0-1.mos6888.git.bac86fe.noarch.rpm

 Vladimir Kozhukalov

 On Mon, Jul 20, 2015 at 4:04 PM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Alex,

 Yes, spec is much better place to introduce this. BTW, perestroika
 builds new package for every commit and patch set and publishes them via
 HTTP. Please check here
 http://172.18.160.74/osci/review/CR-202763/mos/7.0/fuel/base/centos6/Packages/fuel-library7.0-7.0.0-1.mos6888.git.bac86fe.noarch.rpm
 if the package contains all necessary upstream modules.

 Vladimir Kozhukalov

 On Sat, Jul 18, 2015 at 3:28 AM, Alex Schultz aschu...@mirantis.com
 wrote:

 Not until we start using it then any ci that tests with that module
 will validate the modules inclusion. You can check the output of the jobs
 as we are printing what modules are managed by librarian.

 -Alex
 On Jul 17, 2015 6:17 PM, Andrew Woodward xar...@gmail.com wrote:

 Fantastic, do we have some way to validate that the module was
 pulled in properly as part of fuel-library CI?

 On Fri, Jul 17, 2015 at 2:48 PM Alex Schultz aschu...@mirantis.com
 wrote:

 Hey All,

 I've figured it out without having to modify the fuel-main build
 code. I've updated the fuel-library spec with a build action that 
 invokes
 the script to pull down external modules.  Please take some time to 
 review
 the two reviews out there for this change to see if there are any 
 issues
 with the way it is implemented.

 https://review.openstack.org/#/c/202763/
 https://review.openstack.org/#/c/202767/

 This is a first step towards being able to pull in unmodified
 external puppet modules.

 Thanks,
 -Alex

 On Fri, Jul 17, 2015 at 4:23 PM, Andrew Woodward 
 awoodw...@mirantis.com wrote:



 On Fri, Jul 17, 2015 at 12:24 PM Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Alex,

 Great that you did this. Now I think I can prepare fuel-main
 patch to invoke this script right before building fuel-library 
 package.
 I'll add you to review it. Is it ok if I do this monday morning?


 Keep in minde we agreeded to a deadline to get this sorted and in
 shape to land by EOD monday or we will have to retain the old, and 
 crappy
 fork method. If possible please work out how this needs to work as 
 early as
 possible so Alex can continue.


 Vladimir Kozhukalov

 On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz 
 aschu...@mirantis.com wrote:

 Hey Vladimir,

 On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Alex,

 Gathering upstream modules certainly should be implemented as a
 separate script so as to make it possible to use it wherever we 
 need this
 (tests, builds, etc.) According to builds there are two things

 1) We have so called perestroika package build system (Dmitry
 Burmistrov is a main contributor here). By the end of next

Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library

[Alex Schultz]

Unfortunately we got stuck with package availability issues. It was
successful without using librarian packages for building, but since we need
to leverage packages the work to get packaged versions of the code has
unfortunately blocked this. I've got the packages built, but the time to
get them to an publicly available mirror has killed this effort. Since it's
now past FF, I don't think this will be for 7.0 but we should be in a good
spot to start early for 8.0.  Also I've switched to librarian-puppet-simple
since it has far fewer dependencies and we only want to support git
references for packages.  Once that makes it to the mirror and can pass CI,
this change would in theory be ready.  I'm continuing to keep an eye on the
changes so that we'll be ready to start running with them when the time
comes.

-Alex

On Fri, Jul 24, 2015 at 1:41 AM, Mike Scherbakov mscherba...@mirantis.com
wrote:

 Do we have any success here.. ?

 On Mon, Jul 20, 2015 at 8:32 AM Alex Schultz aschu...@mirantis.com
 wrote:

 Vladimir,

 Thanks.  Can you point me to the error for perestroika? I'd be happy to
 take a look as well. I spent most of Friday throwing various options at the
 CI system to try and figure out how to get the spec to work with the CI
 fuel-library package building so perhaps there's a different way to handle
 this in the spec.

 -Alex

 On Mon, Jul 20, 2015 at 10:02 AM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Alex,

 As I've just found out this package available here [1] is not actually
 build with your patch (instead it is from previous successful build). Looks
 like perestroika can not build this package due to some environment
 related issues. I've poked Dmitry Burmistrov to check it out.
 However, your patch is OK, make system can build this package and ISO
 passes BVT tests.


 [1]
 http://172.18.160.74/osci/review/CR-202763/mos/7.0/fuel/base/centos6/Packages/fuel-library7.0-7.0.0-1.mos6888.git.bac86fe.noarch.rpm

 Vladimir Kozhukalov

 On Mon, Jul 20, 2015 at 4:04 PM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Alex,

 Yes, spec is much better place to introduce this. BTW, perestroika
 builds new package for every commit and patch set and publishes them via
 HTTP. Please check here
 http://172.18.160.74/osci/review/CR-202763/mos/7.0/fuel/base/centos6/Packages/fuel-library7.0-7.0.0-1.mos6888.git.bac86fe.noarch.rpm
 if the package contains all necessary upstream modules.

 Vladimir Kozhukalov

 On Sat, Jul 18, 2015 at 3:28 AM, Alex Schultz aschu...@mirantis.com
 wrote:

 Not until we start using it then any ci that tests with that module
 will validate the modules inclusion. You can check the output of the jobs
 as we are printing what modules are managed by librarian.

 -Alex
 On Jul 17, 2015 6:17 PM, Andrew Woodward xar...@gmail.com wrote:

 Fantastic, do we have some way to validate that the module was pulled
 in properly as part of fuel-library CI?

 On Fri, Jul 17, 2015 at 2:48 PM Alex Schultz aschu...@mirantis.com
 wrote:

 Hey All,

 I've figured it out without having to modify the fuel-main build
 code. I've updated the fuel-library spec with a build action that 
 invokes
 the script to pull down external modules.  Please take some time to 
 review
 the two reviews out there for this change to see if there are any issues
 with the way it is implemented.

 https://review.openstack.org/#/c/202763/
 https://review.openstack.org/#/c/202767/

 This is a first step towards being able to pull in unmodified
 external puppet modules.

 Thanks,
 -Alex

 On Fri, Jul 17, 2015 at 4:23 PM, Andrew Woodward 
 awoodw...@mirantis.com wrote:



 On Fri, Jul 17, 2015 at 12:24 PM Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Alex,

 Great that you did this. Now I think I can prepare fuel-main patch
 to invoke this script right before building fuel-library package. 
 I'll add
 you to review it. Is it ok if I do this monday morning?


 Keep in minde we agreeded to a deadline to get this sorted and in
 shape to land by EOD monday or we will have to retain the old, and 
 crappy
 fork method. If possible please work out how this needs to work as 
 early as
 possible so Alex can continue.


 Vladimir Kozhukalov

 On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz 
 aschu...@mirantis.com wrote:

 Hey Vladimir,

 On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Alex,

 Gathering upstream modules certainly should be implemented as a
 separate script so as to make it possible to use it wherever we 
 need this
 (tests, builds, etc.) According to builds there are two things

 1) We have so called perestroika package build system (Dmitry
 Burmistrov is a main contributor here). By the end of next week we 
 are
 going to switch building all the packages to perestroika. And in 
 order to
 gather upstream modules right before building fuel-library package, 
 we need
 to change perestroika build scripts.

 2) Currently we build packages using make system and you

Re: [openstack-dev] [Fuel] Get rid of fuelmenu

[Alex Schultz]

For this to be consumable by end-users, a config file and editor (vim
seriously?) is terrible UX.  We need to remember who we are targeting to
consume this functionality as it may not be an expert or even someone
absolutely familiar with the linux tool set.  While the existing thing may
be awkward, it is going to be less error prone to someone accidentally
deleteing half of a config file and not being able to recover.  If you want
to ditch ncurses, then sure why don't we switch to an answer file and
question/answer wizard for configuration?  This would allow both validation
and the ability to override it with a config file.

-Alex

On Thu, Jul 23, 2015 at 11:49 AM, Vladimir Kozhukalov 
vkozhuka...@mirantis.com wrote:

 The topic is NOT 'get rid of validation' but rather 'get rid of
 semi-graphical ncurses based interface'. It is not so hard to adopt every
 piece of validation we currently have in fuelmenu and implement even more
 including syntax validation using, for example, PLY and logic validation.
 My idea is to switch from ncurses to plain text file (thoroughly
 commented), because it so easy to add new parameters or remove those we
 don't need any more.




 Vladimir Kozhukalov

 On Thu, Jul 23, 2015 at 6:17 PM, Nick Chase nch...@mirantis.com wrote:



  On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn 
 mmoses...@mirantis.commmoses...@mirantis.com wrote:

 Here's a relic of what users used to have to configure by
 hand:

 https://github.com/stackforge/fuel-library/blob/b015ed975b58dddff3b8da0ce34d9a638c22d032/deployment/puppet/openstack/examples/site_simple.pp

 Am I alone in thinking it's not the best use of our development
 resources to throw it away and replace it with a text file that is
 edited by hand?


 Please, please, please, I'm having PTSD just remembering that @#$%@#%$
 file.  I think I was able to successfully deploy without major engineering
 help about 2% of the time.  We absolutely, positively, MUST maintain the
 validation.

 Just because the people installing OpenStack are generally not afraid to
 edit config files doesn't mean that we should be making them do it.

  Nick

 __
 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

Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library

[Alex Schultz]

Vladimir,

Thanks.  Can you point me to the error for perestroika? I'd be happy to
take a look as well. I spent most of Friday throwing various options at the
CI system to try and figure out how to get the spec to work with the CI
fuel-library package building so perhaps there's a different way to handle
this in the spec.

-Alex

On Mon, Jul 20, 2015 at 10:02 AM, Vladimir Kozhukalov 
vkozhuka...@mirantis.com wrote:

 Alex,

 As I've just found out this package available here [1] is not actually
 build with your patch (instead it is from previous successful build). Looks
 like perestroika can not build this package due to some environment
 related issues. I've poked Dmitry Burmistrov to check it out.
 However, your patch is OK, make system can build this package and ISO
 passes BVT tests.


 [1]
 http://172.18.160.74/osci/review/CR-202763/mos/7.0/fuel/base/centos6/Packages/fuel-library7.0-7.0.0-1.mos6888.git.bac86fe.noarch.rpm

 Vladimir Kozhukalov

 On Mon, Jul 20, 2015 at 4:04 PM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Alex,

 Yes, spec is much better place to introduce this. BTW, perestroika
 builds new package for every commit and patch set and publishes them via
 HTTP. Please check here
 http://172.18.160.74/osci/review/CR-202763/mos/7.0/fuel/base/centos6/Packages/fuel-library7.0-7.0.0-1.mos6888.git.bac86fe.noarch.rpm
 if the package contains all necessary upstream modules.

 Vladimir Kozhukalov

 On Sat, Jul 18, 2015 at 3:28 AM, Alex Schultz aschu...@mirantis.com
 wrote:

 Not until we start using it then any ci that tests with that module will
 validate the modules inclusion. You can check the output of the jobs as we
 are printing what modules are managed by librarian.

 -Alex
 On Jul 17, 2015 6:17 PM, Andrew Woodward xar...@gmail.com wrote:

 Fantastic, do we have some way to validate that the module was pulled
 in properly as part of fuel-library CI?

 On Fri, Jul 17, 2015 at 2:48 PM Alex Schultz aschu...@mirantis.com
 wrote:

 Hey All,

 I've figured it out without having to modify the fuel-main build code.
 I've updated the fuel-library spec with a build action that invokes the
 script to pull down external modules.  Please take some time to review the
 two reviews out there for this change to see if there are any issues with
 the way it is implemented.

 https://review.openstack.org/#/c/202763/
 https://review.openstack.org/#/c/202767/

 This is a first step towards being able to pull in unmodified external
 puppet modules.

 Thanks,
 -Alex

 On Fri, Jul 17, 2015 at 4:23 PM, Andrew Woodward 
 awoodw...@mirantis.com wrote:



 On Fri, Jul 17, 2015 at 12:24 PM Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Alex,

 Great that you did this. Now I think I can prepare fuel-main patch
 to invoke this script right before building fuel-library package. I'll 
 add
 you to review it. Is it ok if I do this monday morning?


 Keep in minde we agreeded to a deadline to get this sorted and in
 shape to land by EOD monday or we will have to retain the old, and crappy
 fork method. If possible please work out how this needs to work as early 
 as
 possible so Alex can continue.


 Vladimir Kozhukalov

 On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz aschu...@mirantis.com
  wrote:

 Hey Vladimir,

 On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Alex,

 Gathering upstream modules certainly should be implemented as a
 separate script so as to make it possible to use it wherever we need 
 this
 (tests, builds, etc.) According to builds there are two things

 1) We have so called perestroika package build system (Dmitry
 Burmistrov is a main contributor here). By the end of next week we are
 going to switch building all the packages to perestroika. And in 
 order to
 gather upstream modules right before building fuel-library package, 
 we need
 to change perestroika build scripts.

 2) Currently we build packages using make system and you are right
 about the place where you need to make changes.
 https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82
 If you create shell script, I'll help you to add it to make code.




 I have updated my review[0] to extract the update logic to it's own
 bash script that can be invoked by the build scripts.  Let me know what
 would be the best way to wedge this in there.  I think for the
 perestroika this would also be needed for the fuel-library build, so 
 if
 you point me at that I can see if I can help make that change as well.

 Thanks,
 -Alex

 [0] https://review.openstack.org/#/c/202763/



 Vladimir Kozhukalov

 On Fri, Jul 17, 2015 at 2:56 PM, Aleksandr Didenko 
 adide...@mirantis.com wrote:

 I believe build_repo function is the best way to do this [0]. So
 for fuel-library we'll need to run a shell script right from the repo
 before 'touch $$@'. We can make it either conditional ( test -f
 ./path/additional_build_script.sh  bash 
 ./path/additional_build_script.sh

Re: [openstack-dev] [fuel][puppet] The state of collaboration: 5 weeks

[Alex Schultz]

 As a new contributor to any openstack project, this is the first thing I
 do.  Find out when the weekly meetings is, attend and monitor the
 conversion.  Almost always there is an open discussion at the end of the
 weekly business.

 Going back through the last 5 weeks of irclogs[1], I couldn't find any
 references to 'fuel'.  I'm not trying to lay fault or blame, but perhaps a
 something can be added to the agenda[2] each week giving a status update on
 the puppet-fuel progress.

 Over in openstack-infra we have a downstream-puppet effort that has been
 spanning more then 6months now. Each week downstream developers raise any
 new issues or code reviews that need eyes, for the most part I think it has
 worked very well.

 I think Mirantis / Fuel could do the same, a weekly update to give an
 update on the effort. Any issues that need more eyes on, and patchsets that
 have stalled.

 Thoughts?

 [1] http://eavesdrop.openstack.org/meetings/puppet_openstack/
 [2] https://wiki.openstack.org/wiki/Meetings/PuppetOpenStack



So I know we had fuel members as a part of the meetings over the last few
weeks[0][1]. I think there is some mis-understanding of how fuel uses the
upstream modules.  Honestly, fuel is more like an operator in the way we
are consuming these modules.   The fuel-library repository is not a normal
puppet module, it's more of an environment role/profile setup specifically
to act in concert with the other fuel projects.  At least from my view
point, the fuel team isn't necessarily trying to make large sweeping
changes in many of the core upstream modules.  There are a few instances
where I would say there have been some larger changes, but overall I think
the effort is to try and introduce additional ways to utilize the modules.
Overall we're just trying to get them to work in our reference
architecture[2].  Much of the issue with the upstream code being in the
fuel-library repository is being worked on but it takes time to address all
the issues by getting changes upstreamed, adjusting the usage, and being
able to switch. I have personally made a large push[3] to start this
endeavor. But as I mentioned early on in the previous email thread[4], help
from others would be welcomed as this effort requires people from both
sides to be successful.  I know for a fact that I personally have been
trying to push from the fuel-library side to make sure that we can consume
upstream modules as much as possible.  I feel saddened by this thread
because I know I'm investing effort and pushing to correct the things being
brought up but they aren't being seen or acknowledged as actually
happening. I don't think anyone disagrees that we need to fix the state of
fuel-library, but there needs to be some understanding that this will take
time and we are in the process of making the requested changes.  An effort
is being made from the fuel side, and I feel that the original email in
this thread was sent to make sure that it is being recognized and make sure
we are all working towards the previously discussed expectations.

Thanks,
-Alex

[0]
http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-07-14-15.00.txt
- xarses
[1]
http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-07-07-15.00.txt
- xarses, mwhahaha
[2]
https://docs.mirantis.com/openstack/fuel/fuel-6.1/reference-architecture.html#ref-arch
[3] https://blueprints.launchpad.net/fuel/+spec/fuel-puppet-librarian
[4] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066675.html
__
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

Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library

[Alex Schultz]

Hey Alex,

On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com wrote:

 Hi,

 I think that we should provide a separate script that will fetch the
upstream modules into fuel-library/deployment/puppet/ directory. It will
allow us to have everything in a single place and use this script in ISO
build process and CI jobs.


Right. That is what I'm going for. The issue I need help with is the best
way to execute this as part of the build process.  From what i understand
of the build process is that we are using git archive for all pieces so I'm
not sure how to wedge in an extra script execution to do the module fetch.
The creation of the script isn't the issue, the issue is how can I properly
run it as part of the build process.


 Regards,
 Alex


Thanks,
-Alex

 On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz aschu...@mirantis.com
wrote:

 Hello everyone,

 I have committed the initial configuration required to start leveraging
librarian-puppet as part of the way we pull in upstream puppet modules[0].
Additionally, I have also committed a change that would pull in the
openstack-ironic module[1].  The one piece that is missing from this being
a complete solution is the ability to run librarian-puppet as part of our
build process for the fuel-library.  I've looked into the fuel-main build
scripts and I think it's over my head to figure this out just by looking.
Can anyone explain to me or assist me in how I could go about modifying the
existing build system to be able to run librarian-puppet to prepare the
source for the package?  In my initial investigation, it looks like it
would be a modification of the fuel-main/packages/module.mk[3] file.  I
basically need to do the prepare_library[3] function from the 202763
review[0] after we've pulled all the sources together to fetch the upstream
modules.


 Thanks,
 -Alex

 [0] https://review.openstack.org/202763
 [1] https://review.openstack.org/202767
 [2]
https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82
 [3]
https://review.openstack.org/#/c/202763/1/utils/jenkins/fuel_noop_tests.rb


__
 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

Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library

[Alex Schultz]

Hey Vladimir,

On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov 
vkozhuka...@mirantis.com wrote:

 Alex,

 Gathering upstream modules certainly should be implemented as a separate
 script so as to make it possible to use it wherever we need this (tests,
 builds, etc.) According to builds there are two things

 1) We have so called perestroika package build system (Dmitry Burmistrov
 is a main contributor here). By the end of next week we are going to switch
 building all the packages to perestroika. And in order to gather upstream
 modules right before building fuel-library package, we need to change
 perestroika build scripts.

 2) Currently we build packages using make system and you are right about
 the place where you need to make changes.
 https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82
 If you create shell script, I'll help you to add it to make code.




I have updated my review[0] to extract the update logic to it's own bash
script that can be invoked by the build scripts.  Let me know what would be
the best way to wedge this in there.  I think for the perestroika this
would also be needed for the fuel-library build, so if you point me at that
I can see if I can help make that change as well.

Thanks,
-Alex

[0] https://review.openstack.org/#/c/202763/



 Vladimir Kozhukalov

 On Fri, Jul 17, 2015 at 2:56 PM, Aleksandr Didenko adide...@mirantis.com
 wrote:

 I believe build_repo function is the best way to do this [0]. So for
 fuel-library we'll need to run a shell script right from the repo before
 'touch $$@'. We can make it either conditional ( test -f
 ./path/additional_build_script.sh  bash ./path/additional_build_script.sh
 ) or as additional parameter to function and add it in fuel-library call [1]

 Regards,
 Alex

 [0] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L16-L37
 [1] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L45


 On Fri, Jul 17, 2015 at 2:37 PM, Alex Schultz aschu...@mirantis.com
 wrote:

 Hey Alex,

 On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com
 wrote:
 
  Hi,
 
  I think that we should provide a separate script that will fetch the
 upstream modules into fuel-library/deployment/puppet/ directory. It will
 allow us to have everything in a single place and use this script in ISO
 build process and CI jobs.
 

 Right. That is what I'm going for. The issue I need help with is the
 best way to execute this as part of the build process.  From what i
 understand of the build process is that we are using git archive for all
 pieces so I'm not sure how to wedge in an extra script execution to do the
 module fetch.  The creation of the script isn't the issue, the issue is how
 can I properly run it as part of the build process.


  Regards,
  Alex
 

 Thanks,
 -Alex

  On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz aschu...@mirantis.com
 wrote:
 
  Hello everyone,
 
  I have committed the initial configuration required to start
 leveraging librarian-puppet as part of the way we pull in upstream puppet
 modules[0]. Additionally, I have also committed a change that would pull in
 the openstack-ironic module[1].  The one piece that is missing from this
 being a complete solution is the ability to run librarian-puppet as part of
 our build process for the fuel-library.  I've looked into the fuel-main
 build scripts and I think it's over my head to figure this out just by
 looking. Can anyone explain to me or assist me in how I could go about
 modifying the existing build system to be able to run librarian-puppet to
 prepare the source for the package?  In my initial investigation, it looks
 like it would be a modification of the fuel-main/packages/module.mk[3]
 file.  I basically need to do the prepare_library[3] function from the
 202763 review[0] after we've pulled all the sources together to fetch the
 upstream modules.
 
 
  Thanks,
  -Alex
 
  [0] https://review.openstack.org/202763
  [1] https://review.openstack.org/202767
  [2]
 https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82
  [3]
 https://review.openstack.org/#/c/202763/1/utils/jenkins/fuel_noop_tests.rb
 
 
 __
  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

Re: [openstack-dev] [puppet] Parameters possible default value

[Alex Schultz]

Hey Yanis,


On Fri, Jul 17, 2015 at 3:56 AM, Yanis Guenane yguen...@redhat.com wrote:

 Hello everyone,

 Based on the conversation we had during last meeting I went ahead and
 created an
 ini_setting provider[1] that will act as a proxy between our provider
 and the
 upstream one, this way we don't have to fork, only overload the method
 we want.

 The second step towards parameter default management was to provide a
 way that
 means if 'X' is specified as the value for the provider then ensure it
 is absent.

 This way we could move from the following pattern :

   if $myvar {
 keystone_config {'DEFAULT/foo': value = $myvar,
   } else {
 keystone_config {'DEFAULT/foo': ensure = absent,
   }

 to a more readable one that would have been

   keystone_config {'DEFAULT/foo': value = $myvar, }

 that based on the value of $myvar would have ensure absent the parameter.

 In a first time the empty string seemed to have been a good idea, so we
 could
 have default all the parameters to '' (empty string) and live happily
 ever after,
 if set the value would have been set else it would default to upstream
 default.

 But Mathieu raised a fair point here[2] is that an empty string for some
 settings is a valid value, and hence we can't rely on
 it.


Does it make sense for undef to be the 'magic' string for this? As '' or
false may be valid settings, but undef currently is basically ignored (or
so I've been told). Would we want to use undef to indicate the removal of
an option from a configuration?




 Since the beginning we are trying to avoid the use of a magic string, but
 I am starting to run out of idea here.

 Does someone has an idea on which sane value the default could be ?

 Thanks in advance,

 [1] https://review.openstack.org/#/c/202488
 [2] https://review.openstack.org/#/c/202574
 --
 Yanis Guenane

 __
 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



Thanks,
-Alex
__
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

Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library

[Alex Schultz]

Not until we start using it then any ci that tests with that module will
validate the modules inclusion. You can check the output of the jobs as we
are printing what modules are managed by librarian.

-Alex
On Jul 17, 2015 6:17 PM, Andrew Woodward xar...@gmail.com wrote:

 Fantastic, do we have some way to validate that the module was pulled in
 properly as part of fuel-library CI?

 On Fri, Jul 17, 2015 at 2:48 PM Alex Schultz aschu...@mirantis.com
 wrote:

 Hey All,

 I've figured it out without having to modify the fuel-main build code.
 I've updated the fuel-library spec with a build action that invokes the
 script to pull down external modules.  Please take some time to review the
 two reviews out there for this change to see if there are any issues with
 the way it is implemented.

 https://review.openstack.org/#/c/202763/
 https://review.openstack.org/#/c/202767/

 This is a first step towards being able to pull in unmodified external
 puppet modules.

 Thanks,
 -Alex

 On Fri, Jul 17, 2015 at 4:23 PM, Andrew Woodward awoodw...@mirantis.com
 wrote:



 On Fri, Jul 17, 2015 at 12:24 PM Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Alex,

 Great that you did this. Now I think I can prepare fuel-main patch to
 invoke this script right before building fuel-library package. I'll add you
 to review it. Is it ok if I do this monday morning?


 Keep in minde we agreeded to a deadline to get this sorted and in shape
 to land by EOD monday or we will have to retain the old, and crappy fork
 method. If possible please work out how this needs to work as early as
 possible so Alex can continue.


 Vladimir Kozhukalov

 On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz aschu...@mirantis.com
 wrote:

 Hey Vladimir,

 On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Alex,

 Gathering upstream modules certainly should be implemented as a
 separate script so as to make it possible to use it wherever we need this
 (tests, builds, etc.) According to builds there are two things

 1) We have so called perestroika package build system (Dmitry
 Burmistrov is a main contributor here). By the end of next week we are
 going to switch building all the packages to perestroika. And in order 
 to
 gather upstream modules right before building fuel-library package, we 
 need
 to change perestroika build scripts.

 2) Currently we build packages using make system and you are right
 about the place where you need to make changes.
 https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82
 If you create shell script, I'll help you to add it to make code.




 I have updated my review[0] to extract the update logic to it's own
 bash script that can be invoked by the build scripts.  Let me know what
 would be the best way to wedge this in there.  I think for the
 perestroika this would also be needed for the fuel-library build, so if
 you point me at that I can see if I can help make that change as well.

 Thanks,
 -Alex

 [0] https://review.openstack.org/#/c/202763/



 Vladimir Kozhukalov

 On Fri, Jul 17, 2015 at 2:56 PM, Aleksandr Didenko 
 adide...@mirantis.com wrote:

 I believe build_repo function is the best way to do this [0]. So for
 fuel-library we'll need to run a shell script right from the repo before
 'touch $$@'. We can make it either conditional ( test -f
 ./path/additional_build_script.sh  bash 
 ./path/additional_build_script.sh
 ) or as additional parameter to function and add it in fuel-library 
 call [1]

 Regards,
 Alex

 [0]
 https://github.com/stackforge/fuel-main/blob/master/repos.mk#L16-L37
 [1] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L45


 On Fri, Jul 17, 2015 at 2:37 PM, Alex Schultz aschu...@mirantis.com
  wrote:

 Hey Alex,

 On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com
 wrote:
 
  Hi,
 
  I think that we should provide a separate script that will fetch
 the upstream modules into fuel-library/deployment/puppet/ directory. It
 will allow us to have everything in a single place and use this script 
 in
 ISO build process and CI jobs.
 

 Right. That is what I'm going for. The issue I need help with is
 the best way to execute this as part of the build process.  From what i
 understand of the build process is that we are using git archive for 
 all
 pieces so I'm not sure how to wedge in an extra script execution to do 
 the
 module fetch.  The creation of the script isn't the issue, the issue 
 is how
 can I properly run it as part of the build process.


  Regards,
  Alex
 

 Thanks,
 -Alex

  On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz 
 aschu...@mirantis.com wrote:
 
  Hello everyone,
 
  I have committed the initial configuration required to start
 leveraging librarian-puppet as part of the way we pull in upstream 
 puppet
 modules[0]. Additionally, I have also committed a change that would 
 pull in
 the openstack-ironic module[1].  The one piece that is missing from 
 this
 being a complete

Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library

[Alex Schultz]

Hey Vladimir,

So I've been playing with it at the moment because I think the better place
to do the script execution is as part of the build process controlled by
the fuel-library7.0 spec file[0].  It seems to be a valid way to do it (and
would work for our CI jobs to) but the issue i'm running into is the use of
ruby/bundler to pull in these packages.  Any thoughts on the best way to
try and provide the required build environment tools since it appears we
build on Centos 6.5 at the moment so I'm running into ruby 1.8.7 issues.

-Alex

[0] https://review.openstack.org/#/c/202763/9/specs/fuel-library7.0.spec

On Fri, Jul 17, 2015 at 2:24 PM, Vladimir Kozhukalov 
vkozhuka...@mirantis.com wrote:

 Alex,

 Great that you did this. Now I think I can prepare fuel-main patch to
 invoke this script right before building fuel-library package. I'll add you
 to review it. Is it ok if I do this monday morning?

 Vladimir Kozhukalov

 On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz aschu...@mirantis.com
 wrote:

 Hey Vladimir,

 On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Alex,

 Gathering upstream modules certainly should be implemented as a separate
 script so as to make it possible to use it wherever we need this (tests,
 builds, etc.) According to builds there are two things

 1) We have so called perestroika package build system (Dmitry
 Burmistrov is a main contributor here). By the end of next week we are
 going to switch building all the packages to perestroika. And in order to
 gather upstream modules right before building fuel-library package, we need
 to change perestroika build scripts.

 2) Currently we build packages using make system and you are right about
 the place where you need to make changes.
 https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82
 If you create shell script, I'll help you to add it to make code.




 I have updated my review[0] to extract the update logic to it's own bash
 script that can be invoked by the build scripts.  Let me know what would be
 the best way to wedge this in there.  I think for the perestroika this
 would also be needed for the fuel-library build, so if you point me at that
 I can see if I can help make that change as well.

 Thanks,
 -Alex

 [0] https://review.openstack.org/#/c/202763/



 Vladimir Kozhukalov

 On Fri, Jul 17, 2015 at 2:56 PM, Aleksandr Didenko 
 adide...@mirantis.com wrote:

 I believe build_repo function is the best way to do this [0]. So for
 fuel-library we'll need to run a shell script right from the repo before
 'touch $$@'. We can make it either conditional ( test -f
 ./path/additional_build_script.sh  bash ./path/additional_build_script.sh
 ) or as additional parameter to function and add it in fuel-library call 
 [1]

 Regards,
 Alex

 [0]
 https://github.com/stackforge/fuel-main/blob/master/repos.mk#L16-L37
 [1] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L45


 On Fri, Jul 17, 2015 at 2:37 PM, Alex Schultz aschu...@mirantis.com
 wrote:

 Hey Alex,

 On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com
 wrote:
 
  Hi,
 
  I think that we should provide a separate script that will fetch the
 upstream modules into fuel-library/deployment/puppet/ directory. It will
 allow us to have everything in a single place and use this script in ISO
 build process and CI jobs.
 

 Right. That is what I'm going for. The issue I need help with is the
 best way to execute this as part of the build process.  From what i
 understand of the build process is that we are using git archive for all
 pieces so I'm not sure how to wedge in an extra script execution to do the
 module fetch.  The creation of the script isn't the issue, the issue is 
 how
 can I properly run it as part of the build process.


  Regards,
  Alex
 

 Thanks,
 -Alex

  On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz 
 aschu...@mirantis.com wrote:
 
  Hello everyone,
 
  I have committed the initial configuration required to start
 leveraging librarian-puppet as part of the way we pull in upstream puppet
 modules[0]. Additionally, I have also committed a change that would pull 
 in
 the openstack-ironic module[1].  The one piece that is missing from this
 being a complete solution is the ability to run librarian-puppet as part 
 of
 our build process for the fuel-library.  I've looked into the fuel-main
 build scripts and I think it's over my head to figure this out just by
 looking. Can anyone explain to me or assist me in how I could go about
 modifying the existing build system to be able to run librarian-puppet to
 prepare the source for the package?  In my initial investigation, it looks
 like it would be a modification of the fuel-main/packages/module.mk[3]
 file.  I basically need to do the prepare_library[3] function from the
 202763 review[0] after we've pulled all the sources together to fetch the
 upstream modules.
 
 
  Thanks,
  -Alex
 
  [0] https://review.openstack.org

Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library

[Alex Schultz]

Hey All,

I've figured it out without having to modify the fuel-main build code. I've
updated the fuel-library spec with a build action that invokes the script
to pull down external modules.  Please take some time to review the two
reviews out there for this change to see if there are any issues with the
way it is implemented.

https://review.openstack.org/#/c/202763/
https://review.openstack.org/#/c/202767/

This is a first step towards being able to pull in unmodified external
puppet modules.

Thanks,
-Alex

On Fri, Jul 17, 2015 at 4:23 PM, Andrew Woodward awoodw...@mirantis.com
wrote:



 On Fri, Jul 17, 2015 at 12:24 PM Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Alex,

 Great that you did this. Now I think I can prepare fuel-main patch to
 invoke this script right before building fuel-library package. I'll add you
 to review it. Is it ok if I do this monday morning?


 Keep in minde we agreeded to a deadline to get this sorted and in shape to
 land by EOD monday or we will have to retain the old, and crappy fork
 method. If possible please work out how this needs to work as early as
 possible so Alex can continue.


 Vladimir Kozhukalov

 On Fri, Jul 17, 2015 at 5:51 PM, Alex Schultz aschu...@mirantis.com
 wrote:

 Hey Vladimir,

 On Fri, Jul 17, 2015 at 7:33 AM, Vladimir Kozhukalov 
 vkozhuka...@mirantis.com wrote:

 Alex,

 Gathering upstream modules certainly should be implemented as a
 separate script so as to make it possible to use it wherever we need this
 (tests, builds, etc.) According to builds there are two things

 1) We have so called perestroika package build system (Dmitry
 Burmistrov is a main contributor here). By the end of next week we are
 going to switch building all the packages to perestroika. And in order to
 gather upstream modules right before building fuel-library package, we need
 to change perestroika build scripts.

 2) Currently we build packages using make system and you are right
 about the place where you need to make changes.
 https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82
 If you create shell script, I'll help you to add it to make code.




 I have updated my review[0] to extract the update logic to it's own bash
 script that can be invoked by the build scripts.  Let me know what would be
 the best way to wedge this in there.  I think for the perestroika this
 would also be needed for the fuel-library build, so if you point me at that
 I can see if I can help make that change as well.

 Thanks,
 -Alex

 [0] https://review.openstack.org/#/c/202763/



 Vladimir Kozhukalov

 On Fri, Jul 17, 2015 at 2:56 PM, Aleksandr Didenko 
 adide...@mirantis.com wrote:

 I believe build_repo function is the best way to do this [0]. So for
 fuel-library we'll need to run a shell script right from the repo before
 'touch $$@'. We can make it either conditional ( test -f
 ./path/additional_build_script.sh  bash 
 ./path/additional_build_script.sh
 ) or as additional parameter to function and add it in fuel-library call 
 [1]

 Regards,
 Alex

 [0]
 https://github.com/stackforge/fuel-main/blob/master/repos.mk#L16-L37
 [1] https://github.com/stackforge/fuel-main/blob/master/repos.mk#L45


 On Fri, Jul 17, 2015 at 2:37 PM, Alex Schultz aschu...@mirantis.com
 wrote:

 Hey Alex,

 On Jul 17, 2015 4:32 AM, Aleksandr Didenko adide...@mirantis.com
 wrote:
 
  Hi,
 
  I think that we should provide a separate script that will fetch
 the upstream modules into fuel-library/deployment/puppet/ directory. It
 will allow us to have everything in a single place and use this script in
 ISO build process and CI jobs.
 

 Right. That is what I'm going for. The issue I need help with is the
 best way to execute this as part of the build process.  From what i
 understand of the build process is that we are using git archive for all
 pieces so I'm not sure how to wedge in an extra script execution to do 
 the
 module fetch.  The creation of the script isn't the issue, the issue is 
 how
 can I properly run it as part of the build process.


  Regards,
  Alex
 

 Thanks,
 -Alex

  On Thu, Jul 16, 2015 at 11:17 PM, Alex Schultz 
 aschu...@mirantis.com wrote:
 
  Hello everyone,
 
  I have committed the initial configuration required to start
 leveraging librarian-puppet as part of the way we pull in upstream puppet
 modules[0]. Additionally, I have also committed a change that would pull 
 in
 the openstack-ironic module[1].  The one piece that is missing from this
 being a complete solution is the ability to run librarian-puppet as part 
 of
 our build process for the fuel-library.  I've looked into the fuel-main
 build scripts and I think it's over my head to figure this out just by
 looking. Can anyone explain to me or assist me in how I could go about
 modifying the existing build system to be able to run librarian-puppet to
 prepare the source for the package?  In my initial investigation, it 
 looks
 like it would be a modification of the fuel-main/packages

[openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library

[Alex Schultz]

Hello everyone,

I have committed the initial configuration required to start leveraging
librarian-puppet as part of the way we pull in upstream puppet modules[0].
Additionally, I have also committed a change that would pull in the
openstack-ironic module[1].  The one piece that is missing from this being
a complete solution is the ability to run librarian-puppet as part of our
build process for the fuel-library.  I've looked into the fuel-main build
scripts and I think it's over my head to figure this out just by looking.
Can anyone explain to me or assist me in how I could go about modifying the
existing build system to be able to run librarian-puppet to prepare the
source for the package?  In my initial investigation, it looks like it
would be a modification of the fuel-main/packages/module.mk[3] file.  I
basically need to do the prepare_library[3] function from the 202763
review[0] after we've pulled all the sources together to fetch the upstream
modules.


Thanks,
-Alex

[0] https://review.openstack.org/202763
[1] https://review.openstack.org/202767
[2]
https://github.com/stackforge/fuel-main/blob/master/packages/module.mk#L63-L82
[3]
https://review.openstack.org/#/c/202763/1/utils/jenkins/fuel_noop_tests.rb
__
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

Re: [openstack-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules

[Alex Schultz]

Done. Sorry about that.

-Alex

On Fri, Jul 10, 2015 at 9:22 AM, Simon Pasquier spasqu...@mirantis.com
wrote:

 Alex, could you enable the comments for all on your document?
 Thanks!
 Simon

 On Thu, Jul 9, 2015 at 11:07 AM, Bogdan Dobrelya bdobre...@mirantis.com
 wrote:

  Hello everyone,
 
  I took some time this morning to write out a document[0] that outlines
  one possible ways for us to manage our upstream modules in a more
  consistent fashion. I know we've had a few emails bouncing around
  lately around this topic of our use of upstream modules and how can we
  improve this. I thought I would throw out my idea of leveraging
  librarian-puppet to manage the upstream modules within our
  fuel-library repository. Ideally, all upstream modules should come
  from upstream sources and be removed from the fuel-library itself.
  Unfortunately because of the way our repository sits today, this is a
  very large undertaking and we do not currently have a way to manage
  the inclusion of the modules in an automated way. I believe this is
  where librarian-puppet can come in handy and provide a way to manage
  the modules. Please take a look at my document[0] and let me know if
  there are any questions.
 
  Thanks,
  -Alex
 
  [0]
 https://docs.google.com/document/d/13aK1QOujp2leuHmbGMwNeZIRDr1bFgJi88nxE642xLA/edit?usp=sharing

 The document is great, Alex!
 I'm fully support the idea to start adapting fuel-library by
 the suggested scheme. The monitoring feature of ibrarian looks not
 intrusive and we have no blockers to start using the librarian just
 immediately.

 --
 Best regards,
 Bogdan Dobrelya,
 Irc #bogdando

 __
 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-dev] [Fuel][Fuel-library] Using librarian-puppet to manage upstream fuel-library modules

[Alex Schultz]

Hello everyone,

I took some time this morning to write out a document[0] that outlines
one possible ways for us to manage our upstream modules in a more
consistent fashion. I know we've had a few emails bouncing around
lately around this topic of our use of upstream modules and how can we
improve this. I thought I would throw out my idea of leveraging
librarian-puppet to manage the upstream modules within our
fuel-library repository. Ideally, all upstream modules should come
from upstream sources and be removed from the fuel-library itself.
Unfortunately because of the way our repository sits today, this is a
very large undertaking and we do not currently have a way to manage
the inclusion of the modules in an automated way. I believe this is
where librarian-puppet can come in handy and provide a way to manage
the modules. Please take a look at my document[0] and let me know if
there are any questions.

Thanks,
-Alex

[0] 
https://docs.google.com/document/d/13aK1QOujp2leuHmbGMwNeZIRDr1bFgJi88nxE642xLA/edit?usp=sharing

__
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

Re: [openstack-dev] [puppet] [fuel] more collaboration request

[Alex Schultz]

Hey Matt  other OpenStack folks,

I agree that pinging #fuel-dev would not be scalable for every
request. But I think it was more of if someone notices something is
fixed in fuel-library but not in an OpenStack puppet library, then by
all means come and poke someone so we can try and get it in to
upstream if we failed to do so.  As for the inclusion of the OpenStack
puppet modules within fuel-library, I also am not a fan of the way it
is done today, but I'm new here so I can't speak for previous
decisions.  It would be nice if it followed a similar model to how the
OpenStack python libraries are consumed. Leveraging something like
Librarian where we can just increment version numbers or swap out
repositories would be a nice option.  That being said, there's a lot
more tooling that is required in order to get to that and it's hard to
prioritize things like that.  Puppet modules aren't traditionally
packaged via rpms/debs/etc so it's kinda of hard to do that dependency
checking like we do for all the OpenStack services.  I, personally and
I'm sure there are others, would welcome any assistance or ideas on
the best way to do something like that.  I think this is where some
community help would be much appreciated so that we can get to that
point.  I'd be happy to help with trying to push some of these ideas
forward.  I think there are probably others who detest having to
manually pull in module updates every few months and battle test and
merge issues, so anything to make everyones' lives easier would be
welcomed.

Thanks,
-Alex Schultz

On Thu, Jun 11, 2015 at 4:03 PM, Matt Fischer m...@mattfischer.com wrote:
 We as a community don't do a great job watching bugs, so personally I'd
 prefer that fuel developers just push patches, filing a bug too if you want.
 (Note: we do need to improve our bug tracking!) However, I don't think that
 asking puppet openstack devs to ask in the fuel channel if a given bug is
 fixed in fuel is a very sustainable model. I'm not sure of many projects
 where the upstream polls downstream to ask whether they've fixed bugs. Can
 we come up with a way to collaborate more that everyone likes? I think
 there's a lot of value in it for everyone, we all get a better product out
 of it.


 On Thu, Jun 11, 2015 at 8:36 AM, Matthew Mosesohn mmoses...@mirantis.com
 wrote:

 Hi Emilien,

 I can see why you might be unhappy with Fuel's actions with regards to
 the OpenStack Puppet modules. You could make this argument about many
 components in Fuel. The heart of the matter is that we bundle the
 upstream OpenStack Puppet modules with all the other modules,
 developed both upstream and by Fuel's developers in one single git
 repository. This decision, along with all the other decisions to put
 Fuel's components under its own repositories, was intended to add
 stability and granular control to the product. I'm not saying it's the
 most community-oriented approach, but Fuel would have never evolved
 and matured without it. The attribution in commits is lost because our
 directory namespace differs such that it can't just be merged cleanly.
 Revisiting submodules is an option, but it led to maintenance problems
 in the past.


 Secondly, I'd like to point out that Fuel is not so different from
 what other teams are doing. At the Summit, I heard from others who all
 maintain internal Gerrits and internal forks of the modules. The
 difference is that Fuel is being worked on in the open in StackForge.
 Anyone is free to contribute to Fuel as he or she wishes, take our
 patches, or review changesets.



 Starting in October 2014, the Fuel team has adopted a policy that we
 cannot merge any patches into the core Puppet OpenStack modules of
 Fuel without submitting a patch or at least a bug upstream. Our
 reviewers block patches consistently. The truth is that the upstream
 modules are quite excellent and we don't need to make changes so
 often. Our goal is to work with upstream modules or in the issue where
 upstream integration is impossible, we place that config in our own
 separate modules.

 The point you raised about fixing bugs in Fuel and not in Puppet
 OpenStack is definitely valid and something we need to collaborate on.
 The first and easiest option when a bug is applicable to both, we
 could use Launchpad to assign bugs to both Fuel project and
 puppet-$project so it gains visibility. If a bug is discovered in
 Puppet OpenStack after it's been reported and/or fixed in Fuel, then
 it would be best to ping someone in #fuel-dev on IRC and we can try to
 figure out how to get this applied upstream correctly. Our best
 results come from fixing upstream and I want to make sure that is
 clear.

 If you have specific bugs or commits you'd like to discuss, let's work
 them out. I believe I can get the Fuel Library team to agree to do a
 walk through all the open bugs in Puppet OpenStack and see if we have
 any related fixes or bug reports.

 Best Regards,
 Matthew Mosesohn

 On Thu, Jun 11, 2015