This is what I get with the above, slightly adapted to take care of an edge
case:
Apt::Source<| |> -> Exec['apt_update'] -> Package<| title !=
'ubuntu-cloud-keyring' |>
The ubuntu-cloud-keyring is a prerequisite for adding the ubuntu cloud
archive (for openstack debs). Without this exception, it leads to a cycle
since Sources -> packages otherwise.
Dependency Cycle.
(Anchor[apt::source::puppetlabs] => Apt::Source[puppetlabs] =>
Exec[apt_update] => Class[Apt::Update] => Anchor[apt::source::puppetlabs])
Now, the problem I'm trying to solve is I constantly see these package
errors:
0 upgraded, 17 newly installed, 0 to remove and 12 not upgraded.
Need to get 5504 kB/6061 kB of archives.
After this operation, 20.8 MB of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
libvirt0 libvirt-bin
E: There are problems and -y was used without --force-yes
I'm sure this has to do with getting updates to run after adding sources
because if I hop on the host and do this:
/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install
libvirt-bin
It reproduces the error. But if I then run 'apt-get update' and rerun it,
no errors.
On Fri, May 10, 2013 at 7:25 AM, jcbollinger <john.bollin...@stjude.org>wrote:
>
>
> On Thursday, May 9, 2013 10:23:25 PM UTC-5, Nan Liu wrote:
>
>> On Thu, May 9, 2013 at 11:52 AM, James Kyle <li...@jameskyle.org> wrote:
>>
>>> I've run into several incidences where a module attempts to install a
>>> package before the apt::source is added or an update is run. Result is a
>>> bunch apt errors and explosions.
>>>
>>> Basically what should be done is all the apt::sources are added and and
>>> an update run _before_ any packages are installed to ensure you're pulling
>>> from the repos you want.
>>>
>>> I've gone through several iterations in my attempt to achieve that
>>> behavior. The one that works best so far is stages and wrapper classes.
>>> Here's a terse example of what it looks like:
>>>
>>> class myorg::common {
>>> include stdlib
>>>
>>> Apt::Source {stage => "setup"}
>>>
>>> apt::source { 'puppetlabs':
>>> location => 'http://apt.puppetlabs.com',
>>> repos => 'main',
>>> key => '4BD6EC30',
>>> key_server => 'pgp.mit.edu',
>>> }
>>>
>>> Exec['apt_update'] -> Package<| title != 'ubuntu-cloud-keyring' |>
>>> }
>>>
>>> node 'foo.bar.com' {
>>> include stdlib
>>>
>>> class {'myorg::common': stage => "setup"}
>>> }
>>>
>>>
>>> One thing that bothers me is you have to declare the stage for
>>> myorg::common in every node that uses it. And as the name implies, that's
>>> every node.
>>>
>>> Is there a way to get rid of that duplication? I've thought of node
>>> inheritance, but the docs seem to strongly steer you away from that pattern.
>>>
>>
>> Doesn't the relationship do the right thing without stages?
>>
>
>
> It would depend on whether and how stages are used elsewhere in the
> manifest set. With stages it's often "in for a penny, in for a pound."
> Generally speaking, though, it should be possible to do this sort of thing
> (or anything, actually) without stages.
>
>
>
>> Does this work?
>>
>> class myorg::common (
>> $staging = 'setup',
>> ) { ...
>>
>> Nan
>>
>
>
> Provided that all of the relevant Apt sources are managed via Apt:::Source
> resources, and that no virtual Apt::Source or Package resources are
> declared without elsewhere being realized, this declaration should work:
>
> Apt::Source<| |> -> Exec['apt_update'] -> Package<| |>
>
> That declaration is not itself affected by or dependent on stages, but it
> is possible for the referenced resources to be assigned to stages in such a
> way that the chain closes one or more dependency cycles. Such cycles would
> reflect an error in the stage assignments, however, for the chain
> expression succinctly and precisely describes the requested resource
> application order; as long as it does so, it *defines* the correct
> orders. It would be sufficient to make that declaration once, in some
> central place, but not harmful to make it multiple times.
>
> There are all manner of tweaks and accommodations that could be applied to
> handle special cases, such as when there are virtual Apt::Source or Package
> resources must remain unrealized, but the chain above captures the
> essential essence of the required declaration.
>
>
> John
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
