I'm currently trying to set-up some an Rspec testing framework for some of
our in-house modules using Puppetlabs_spec_helper and librarian-puppet.
However I'm hitting issues with some of the Foreman modules…
I've got the following set my 'Puppetfile':
forge 'http://forge.puppetlabs.com'
>
…
>
mod 'theforeman/puppet', '>=1.3.0'
> mod 'theforeman/concat_native', '>=1.3.0'
> mod 'theforeman/apache', '>=1.3.0'
> mod 'theforeman/passenger', '>=1.3.0'
> mod 'theforeman/foreman', '>=1.3.0'
> …
>
However whenever I try and run 'rake spec', or 'librarian-puppet install
–path=spec/fixtures/modules/' I get:
> librarian-puppet install --path=spec/fixtures/modules/
> /usr/lib/ruby/1.8/tsort.rb:152:in tsort_each': topological sort failed: > ["theforeman/apache", "theforeman/passenger"] (TSort::Cyclic) > from /usr/lib/ruby/1.8/tsort.rb:183:in >each_strongly_connected_component'
> from /usr/lib/ruby/1.8/tsort.rb:210:in
> each_strongly_connected_component_from' > from /usr/lib/ruby/1.8/tsort.rb:219:in >each_strongly_connected_component_from'
> from /usr/lib/ruby/1.8/tsort.rb:209:in
> each_strongly_connected_component_from' > from > /usr/lib/ruby/gems/1.8/gems/librarian-puppet-0.9.10/vendor/librarian/lib/librarian/manifest_set.rb:11:in >each'
> from
> /usr/lib/ruby/gems/1.8/gems/librarian-puppet-0.9.10/vendor/librarian/lib/librarian/manifest_set.rb:11:in
> tsort_each_child' > from /usr/lib/ruby/1.8/tsort.rb:203:in >each_strongly_connected_component_from'
> from /usr/lib/ruby/1.8/tsort.rb:182:in
> each_strongly_connected_component' > from /usr/lib/ruby/1.8/tsort.rb:180:intsort_each_node'
> from /usr/lib/ruby/1.8/tsort.rb:180:in
> each_strongly_connected_component' > from /usr/lib/ruby/1.8/tsort.rb:148:intsort_each'
> from /usr/lib/ruby/1.8/tsort.rb:135:in tsort' > from > /usr/lib/ruby/gems/1.8/gems/librarian-puppet-0.9.10/vendor/librarian/lib/librarian/manifest_set.rb:31:in >sort'
> from
> /usr/lib/ruby/gems/1.8/gems/librarian-puppet-0.9.10/vendor/librarian/lib/librarian/resolver.rb:68:in
> sort' > from > /usr/lib/ruby/gems/1.8/gems/librarian-puppet-0.9.10/vendor/librarian/lib/librarian/resolver.rb:20:in >resolve'
> from
> /usr/lib/ruby/gems/1.8/gems/librarian-puppet-0.9.10/vendor/librarian/lib/librarian/action/resolve.rb:25:in
> run' > from > /usr/lib/ruby/gems/1.8/gems/librarian-puppet-0.9.10/vendor/librarian/lib/librarian/cli.rb:161:in >resolve!'
> from
> /usr/lib/ruby/gems/1.8/gems/librarian-puppet-0.9.10/lib/librarian/puppet/cli.rb:63:in
> install' > from > /usr/lib/ruby/gems/1.8/gems/thor-0.18.1/lib/thor/command.rb:27:insend'
> from
> /usr/lib/ruby/gems/1.8/gems/thor-0.18.1/lib/thor/command.rb:27:in run' > from > /usr/lib/ruby/gems/1.8/gems/thor-0.18.1/lib/thor/invocation.rb:120:in >invoke_command'
> from /usr/lib/ruby/gems/1.8/gems/thor-0.18.1/lib/thor.rb:363:in
> dispatch' > from > /usr/lib/ruby/gems/1.8/gems/thor-0.18.1/lib/thor/base.rb:439:instart'
> from
> /usr/lib/ruby/gems/1.8/gems/librarian-puppet-0.9.10/vendor/librarian/lib/librarian/cli.rb:29:in
> bin!' > from > /usr/lib/ruby/gems/1.8/gems/librarian-puppet-0.9.10/bin/librarian-puppet:9 > from /usr/bin/librarian-puppet:19:inload'
> from /usr/bin/librarian-puppet:19
> rake aborted!
>
Now from the errors being returned, it suggests a cyclical dependency
issue…
When looking at the deps for theforeman/apache and *theforeman/passenger,
*it does appear that they depend on each-other.
Is this intended behaviour? Or can it be simplified so that only one
depends on the other?
We can lose the dependency in "apache" on "passenger" I believe, could
you submit a PR please?
···
On 02/12/13 14:57, Gavin Williams wrote:
> Now from the errors being returned, it suggests a cyclical dependency
> issue...
> When looking at the deps for /theforeman/apache/ and
> /theforeman/passenger, /it does appear that they depend on each-other.
> Is this intended behaviour? Or can it be simplified so that only one
> depends on the other?
···
On Monday, 2 December 2013 15:00:30 UTC, Dominic Cleal wrote:
>
> On 02/12/13 14:57, Gavin Williams wrote:
> > Now from the errors being returned, it suggests a cyclical dependency
> > issue...
> > When looking at the deps for /theforeman/apache/ and
> > /theforeman/passenger, /it does appear that they depend on each-other.
> > Is this intended behaviour? Or can it be simplified so that only one
> > depends on the other?
>
> We can lose the dependency in "apache" on "passenger" I believe, could
> you submit a PR please?
>
> --
> Dominic Cleal
> Red Hat Engineering
>
···
On Monday, 2 December 2013 15:21:40 UTC, Gavin Williams wrote:
>
> Dominic
>
> Makes sense to me...
>
> Will get a PR submitted shortly...
>
> Cheers
> Gav
>
> On Monday, 2 December 2013 15:00:30 UTC, Dominic Cleal wrote:
>>
>> On 02/12/13 14:57, Gavin Williams wrote:
>> > Now from the errors being returned, it suggests a cyclical dependency
>> > issue...
>> > When looking at the deps for /theforeman/apache/ and
>> > /theforeman/passenger, /it does appear that they depend on each-other.
>> > Is this intended behaviour? Or can it be simplified so that only one
>> > depends on the other?
>>
>> We can lose the dependency in "apache" on "passenger" I believe, could
>> you submit a PR please?
>>
>> --
>> Dominic Cleal
>> Red Hat Engineering
>>
>
For the benefit of the mailing list, PR has been merged, and
theforeman/apache module up-versioned to v1.4.0 and pushed to the forge by
Dominic and ekohl.
Can confirm that this has resolved my cyclical dependency issue, and I can
now successfully manage theforeman modules using librarian puppet.
For reference, my Puppetfile looks like:
mod 'theforeman/puppet', '>=1.3.0'
> mod 'theforeman/concat_native', '>=1.3.0'
> mod 'theforeman/apache', '>=1.4.0'
> mod 'theforeman/passenger', '>=1.3.0'
> mod 'theforeman/foreman', '>=1.3.0'
>
Cheers again for the swift turn-around.
Regards
Gavin
···
On Monday, 2 December 2013 15:30:16 UTC, Gavin Williams wrote:
>
> PR in - https://github.com/theforeman/puppet-apache/pull/14
>
> Cheers
> Gavin
>
> On Monday, 2 December 2013 15:21:40 UTC, Gavin Williams wrote:
>>
>> Dominic
>>
>> Makes sense to me...
>>
>> Will get a PR submitted shortly...
>>
>> Cheers
>> Gav
>>
>> On Monday, 2 December 2013 15:00:30 UTC, Dominic Cleal wrote:
>>>
>>> On 02/12/13 14:57, Gavin Williams wrote:
>>> > Now from the errors being returned, it suggests a cyclical dependency
>>> > issue...
>>> > When looking at the deps for /theforeman/apache/ and
>>> > /theforeman/passenger, /it does appear that they depend on each-other.
>>> > Is this intended behaviour? Or can it be simplified so that only one
>>> > depends on the other?
>>>
>>> We can lose the dependency in "apache" on "passenger" I believe, could
>>> you submit a PR please?
>>>
>>> --
>>> Dominic Cleal
>>> Red Hat Engineering
>>>
>>
> For the benefit of the mailing list, PR has been merged, and
> theforeman/apache module up-versioned to v1.4.0 and pushed to the forge by
> Dominic and ekohl.
>
> Can confirm that this has resolved my cyclical dependency issue, and I can
> now successfully manage theforeman modules using librarian puppet.
Good news! I tried this some time ago and I realized that librarian-puppet was
not able to handle 'pre' or '1.2.3-4' versions properly. I'll give it another
try so maybe it could be used in foreman-installer. This would make it much
easier to manage installer modules.
···
On Monday 02 of December 2013 09:38:31 Gavin Williams wrote:
For reference, my Puppetfile looks like:
mod ‘theforeman/puppet’, ‘>=1.3.0’
mod ‘theforeman/concat_native’, '>=1.3.0’
mod ‘theforeman/apache’, '>=1.4.0’
mod ‘theforeman/passenger’, '>=1.3.0’
mod ‘theforeman/foreman’, ‘>=1.3.0’
Cheers again for the swift turn-around.
Regards
Gavin
On Monday, 2 December 2013 15:30:16 UTC, Gavin Williams wrote:
On Monday, 2 December 2013 15:21:40 UTC, Gavin Williams wrote:
Dominic
Makes sense to me…
Will get a PR submitted shortly…
Cheers
Gav
On Monday, 2 December 2013 15:00:30 UTC, Dominic Cleal wrote:
On 02/12/13 14:57, Gavin Williams wrote:
Now from the errors being returned, it suggests a cyclical dependency
issue…
When looking at the deps for /theforeman/apache/ and
/theforeman/passenger, /it does appear that they depend on each-other.
Is this intended behaviour? Or can it be simplified so that only one
depends on the other?
We can lose the dependency in “apache” on “passenger” I believe, could
you submit a PR please?
Yeah, I'm coming round to this idea too - I remember you suggesting it a
while back.
Now we've started releasing installer modules asynchronously, we could
just use version specifications instead of submodules. My question
though would be how we build packages?
I'm wondering if we first do a "release" process to generate the tarball
for a given foreman-installer version, which pulls down the versioned
modules from the Forge or our repos (we can add git tags where they're
currently missing), then feed this tarball into RPMs/debs.
···
On 03/12/13 07:55, Marek Hulan wrote:
> On Monday 02 of December 2013 09:38:31 Gavin Williams wrote:
>> For the benefit of the mailing list, PR has been merged, and
>> theforeman/apache module up-versioned to v1.4.0 and pushed to the forge by
>> Dominic and ekohl.
>>
>> Can confirm that this has resolved my cyclical dependency issue, and I can
>> now successfully manage theforeman modules using librarian puppet.
>
> Good news! I tried this some time ago and I realized that librarian-puppet was
> not able to handle 'pre' or '1.2.3-4' versions properly. I'll give it another
> try so maybe it could be used in foreman-installer. This would make it much
> easier to manage installer modules.
So there are two ways I think - either keep all modules in git repo and use
librarian just to update sources. Then the release process remains the same.
We'd get rid of submodules/subtree but on the other hand we'd lost the ability
to easily edit and update modules within foreman-installer itself.
Second way is what you suggest, make a script that will pull modules and
create some tar which will be used for packaging (having modules path in
.gitignore).
Somehow I find your (second way) better.
···
On Tuesday 03 of December 2013 10:25:09 Dominic Cleal wrote:
> On 03/12/13 07:55, Marek Hulan wrote:
> > On Monday 02 of December 2013 09:38:31 Gavin Williams wrote:
> >> For the benefit of the mailing list, PR has been merged, and
> >> theforeman/apache module up-versioned to v1.4.0 and pushed to the forge
> >> by
> >> Dominic and ekohl.
> >>
> >> Can confirm that this has resolved my cyclical dependency issue, and I
> >> can
> >> now successfully manage theforeman modules using librarian puppet.
> >
> > Good news! I tried this some time ago and I realized that librarian-puppet
> > was not able to handle 'pre' or '1.2.3-4' versions properly. I'll give it
> > another try so maybe it could be used in foreman-installer. This would
> > make it much easier to manage installer modules.
>
> Yeah, I'm coming round to this idea too - I remember you suggesting it a
> while back.
>
> Now we've started releasing installer modules asynchronously, we could
> just use version specifications instead of submodules. My question
> though would be how we build packages?
>
> I'm wondering if we first do a "release" process to generate the tarball
> for a given foreman-installer version, which pulls down the versioned
> modules from the Forge or our repos (we can add git tags where they're
> currently missing), then feed this tarball into RPMs/debs.
Not sure if this is option 1, 2 or even 3 but here's my solution:
We create a Puppetfile in foreman-installer git master and point it to
the git versions of our modules. When we do a release for 1.4.0, we make
a 1.4 branch of the installer and change the git URLs to released
version numbers.
On a related note; I strongly advocate is managing foreman with the
foreman installer modules. Currently it's easy to fork the
foreman-installer repo and users can add their own modules easily. This
workflow is also made easier by the git_repo parameter in puppet-puppet.
Now I don't want to enforce the git based workflow, but if we stop using
that we should improve support for puppet-librarian / r10k based
workflows. I think there have been recent patches that made this easier,
but we should document this or even include support in our commit hook.
Managing foreman using our modules is also the basis for a talk I've
submitted for cfgmgmtcamp.eu and I'm working on some blog posts to
document the workflow. Maybe that's a nice place to demo these
workflows.
···
On Tue, Dec 03, 2013 at 12:08:26PM +0100, Marek Hulan wrote:
> On Tuesday 03 of December 2013 10:25:09 Dominic Cleal wrote:
> > On 03/12/13 07:55, Marek Hulan wrote:
> > > On Monday 02 of December 2013 09:38:31 Gavin Williams wrote:
> > >> For the benefit of the mailing list, PR has been merged, and
> > >> theforeman/apache module up-versioned to v1.4.0 and pushed to the forge
> > >> by
> > >> Dominic and ekohl.
> > >>
> > >> Can confirm that this has resolved my cyclical dependency issue, and I
> > >> can
> > >> now successfully manage theforeman modules using librarian puppet.
> > >
> > > Good news! I tried this some time ago and I realized that librarian-puppet
> > > was not able to handle 'pre' or '1.2.3-4' versions properly. I'll give it
> > > another try so maybe it could be used in foreman-installer. This would
> > > make it much easier to manage installer modules.
> >
> > Yeah, I'm coming round to this idea too - I remember you suggesting it a
> > while back.
> >
> > Now we've started releasing installer modules asynchronously, we could
> > just use version specifications instead of submodules. My question
> > though would be how we build packages?
> >
> > I'm wondering if we first do a "release" process to generate the tarball
> > for a given foreman-installer version, which pulls down the versioned
> > modules from the Forge or our repos (we can add git tags where they're
> > currently missing), then feed this tarball into RPMs/debs.
>
> So there are two ways I think - either keep all modules in git repo and use
> librarian just to update sources. Then the release process remains the same.
> We'd get rid of submodules/subtree but on the other hand we'd lost the ability
> to easily edit and update modules within foreman-installer itself.
>
> Second way is what you suggest, make a script that will pull modules and
> create some tar which will be used for packaging (having modules path in
> .gitignore).
>
> Somehow I find your (second way) better.
