[Spacewalk-list] API. Merge single new errata and packages

Thu Sep 26 00:11:05 UTC 2013

Matt
Thanks for the analysis.  It certainly answers my question about how Errata
is cloned to a given channel.  I can certainly use this to improve what I
already have in place for mass-merging of new Errata.

I'll have to monkey w/ individual Advisories to make sure it does what I
want.  It's not a requirement as we usually just do a clone-by-date for the
entire channel, but I foresee requirements coming for more granular control
of Errata that is merged to Production so I'm trying to get in front of
that.

Thanks again!

Will

On Wed, Sep 25, 2013 at 2:29 PM, Matt Micene <matt.micene at dlt.com> wrote:

>  The source should always be the “upstream” of the Errata, Red Hat for
> any clones from Red Hat, your channel if it’s locally sourced and managed
> errata.  Errata are just documents that have links to updated packages with
> descriptions.  Clones don’t physically copy RPMs from sources, they get
> pointers to the same RPMs.  Same with Cloned errata, the package links in
> the clone point to the same updated packages as the source errata.****
>
> ** **
>
> So I created a new clone channel (RHEL 6 Client) with no errata in it and
> found an as yet uncloned RHT Errata****
>
> ** **
>
> RHSA-2013:1142<https://ep-sat01.lab.dlt.com/rhn/errata/details/Details.do?eid=20084>
> ****
>
> (none)****
>
> Important: thunderbird security update****
>
>   ****
>
> ** **
>
> We want to watch what happens to this errata as we run our script.****
>
> ** **
>
> ** 88 Errata to clone from source****
>
> Waiting to continue...****
>
> ['RHSA-2013:1282', 'RHBA-2013:1276', 'RHBA-2013:1278', 'RHBA-2013:1271',
> <SNIP>****
>
> 'RHSA-2013:1140', *'RHSA-2013:1142',* 'RHSA-2013:1144', 'RHBA-2013:1132',
> <SNIP>****
>
> 'RHBA-2013:0901', 'RHBA-2013:0893', 'RHSA-2013:0896', 'RHSA-2013:0897']***
> *
>
> ** 88 Advisories added to clone list for target****
>
> ** **
>
> Ok so it was in the original list from the source of
> "rhel-x86_64-client-6" and we added args for errata.cloneAsOriginal.
> Here’s the output from that call.****
>
> ** **
>
> ['CLA-2013:1282', 'CLA-2013:1276', 'CLA-2013:1278', 'CLA-2013:1271',
> 'CLA-2013:1270', <SNIP>****
>
> 'CLA-2013:1146', 'CLA-2013:1140',* 'CLA-2013:1142',* 'CLA-2013:1144',
> 'CLA-2013:1132', <SNIP>****
>
> 'CLA-2013:0893', 'CLA-2013:0896', 'CLA-2013:0897']****
>
> ** 88 Cloned advisories pushed to the target channel****
>
> ** **
>
> ** **
>
> So it looks like the APIs can skip the publish step and clone straight to
> the channel.  There’s a way to do this via the GUI under Manage Software
> Channels -> Channel Name -> Errata tab.  This is a different workflow than
> from the Errata top level tab and Clone Errata.****
>
> ** **
>
> So my script really probably only needs the first two calls: build the
> list from channel A and clone to channel B, which will create new cloned
> errata where needed and merge with existing.  If that’s not your workflow
> .. then you probably want to create a few clones and play around.****
>
> ** **
>
> I may have gone far afield with this answer … let me know if I didn’t get
> you what you needed.****
>
> ** **
>
> HTH,****
>
> Matt****
>
> ** **
>
> *From:* spacewalk-list-bounces at redhat.com [mailto:
> spacewalk-list-bounces at redhat.com] *On Behalf Of *wm-lists
> *Sent:* Wednesday, September 25, 2013 12:55 PM
>
> *To:* spacewalk-list at redhat.com
> *Subject:* Re: [Spacewalk-list] API. Merge single new errata and packages*
> ***
>
>  ** **
>
> Thanks for the script.  I'll have to give that a try and see what the
> results are..
>
> My use case would be if, say, httpd is updated by Red Hat for a specific
> vulnerability and I wanted to progress only that advisory and associated
> packages through to my dev channels and on to the production channels in
> order to quickly implement it.  My errata flow is Red Hat --> DEV Channel
> -->PROD Channel
>
> So knowing that, where does the errata.clone call use as it's source?  If
> my prod channel's original channel is the dev channel, would it use that?
>
> Will****
>
> ** **
>
> On Wed, Sep 25, 2013 at 11:23 AM, Matt Micene <matt.micene at dlt.com> wrote:
> ****
>
> I knocked together this python script to look at the behavior of the API
> around cloning errata.  It looks to me like once you've published an
> errata, cloning it to the channel takes care of linking the package.
>
> So the script will wants a source, target and date range then lists all
> the available errata in the source, clones them to the target and then
> publishes anything that's left.
>
> This probably isn't the right workflow by a long shot (off the top of my
> head I think you'd probably want to get the unpublished list first maybe?),
> and there's no error checking but it may prove interesting just for the
> behavior.
>
> HTH,
> Matt
>
>
> > -----Original Message-----
> > From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-
> > bounces at redhat.com] On Behalf Of Matt Micene
> > Sent: Wednesday, September 25, 2013 9:09 AM
> > To: spacewalk-list at redhat.com
> > Subject: Re: [Spacewalk-list] API. Merge single new errata and packages
> >
> > Will,
> >
> > I haven't looked at the Errata workflow in a while but I believe the
> > next step isn't to mergePackages but to use the errata.publish call.
> >
> > If you look at the UI after your clone step, the errata should show up
> > in the clone as unpublished.  The next step is publish, which moves the
> > package into the channel.  You can also use
> > errata.listUnpublishedErrata to make sure the errata you are trying to
> > merge are ready.
> >
> > One thing to note, you say you are trying to merge a single errata.
> > errata.mergeErrata will merge all errata from the source channel
> > constrained by the date range or list.  While you are probably passing
> > a single value in that list, it may have odd side effects.  You may
> > want to look at the errata.clone* methods which only operate on the
> > provided list rather than using that list as a constraint.
> >
> > HTH,
> > Matt****
>
> >
> > > -----Original Message-----
> > > From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-
> > > bounces at redhat.com] On Behalf Of wm-lists
> > > Sent: Tuesday, September 24, 2013 8:45 PM
> > > To: spacewalk-list at redhat.com
> > > Subject: [Spacewalk-list] API. Merge single new errata and packages
> > >
> > > I'm sure there's a simple way to do this, but I'm probably over-
> > > complicating it.
> > > I'm looking to write a python script, that, given an Errata Advisory
> > > Name, will merge the Errata and associated package from one channel
> > > (say Red Hat source) to another channel (say our development
> > channel).
> > >
> > > I've got the Errata merge fine with the mergeErrata api call,
> > >
> > lient.channel.software.mergeErrata(key,channelinfo.get('clone_original'
> > > ), mychannel.get('label'),[errata])
> > >
> > > But there isn't a mergePackage that only merges one package.
> > >
> > > Any help or guidance?
> > >
> > > Thanks
> > > Will
> > >
> > > Sent from my iPhone
> > > Sent from my iPhone
> > >
> > > _______________________________________________
> > > Spacewalk-list mailing list
> > > Spacewalk-list at redhat.com
> > > https://www.redhat.com/mailman/listinfo/spacewalk-list
> >
> > _______________________________________________
> > Spacewalk-list mailing list
> > Spacewalk-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/spacewalk-list****
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list****
>
> ** **
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20130925/5942139c/attachment.htm>