On Tuesday 04 February 2014 12:57:39 Bo Maryniuk wrote:
> On Tue, Feb 04, 2014 at 11:54:13AM +0100, Milan Zázrivec wrote:
> > Using "myfantasticserver" and {"name" : "alsa-lib", "version" : "1.0.22",}
> > to identify server and package? Please no.
>
> How do you remove an orphan package that is not on the channels from the
> particular machine? The UI allows to do that, but the package is identified
> by NEVRA (well, by a combo, which it is).
>
> Having this API already working, logically you would like to extend that
> elsewhere, even if it is an additional API.
As long as we're speaking of 'extra packages' -- then yes. These packages
may not have a package id, so we need to identify them by their nevras,
but only for that one particular system. We cannot extend this concept
to an arbitrary system and to an arbitrary package removal.
Say you have several "myfantasticserver" systems (i.e. the same profile
name / hostname / ip address) and add a package installation action
to an existing action chain. Which of those many "myfantasticserver" systems
will this action be scheduled for? All of them? First one? Last one? Random
picks? There's no reliable way to decide, is it?
> > It's not uncommon to have the same machine registered with Spacewalk
> > multiple times and use the same profile name / hostname / IP address for
> > all these registrations. "myfantasticserver" simply won't be enough to
> > uniquely identify the desired server -- only server id will be.
> >
> > Similarly, it's perfectly OK to have two packages with the same NEVRA
> > pushed into one organization (for example RHEL + CentOS). In these
> > situations, your concept would not be able to realiably identify desired
> > packages -- only package id would be.
>
> But I would expect two packages would either have different checksum and/or
> in different channels?
Sure, these packages would have different checksums. But that's not the point.
> > While I understand that the thought of operating with human-compatible
> > data
> > seems appealing, I'm afraid it won't work with API, where we need to model
> > functions in an orthogonal manner -- i.e. one function will give you
> > system
> > id(s), another one will give you package id(s) and a third one will take
> > these two ids and instruct a specific chain to remove packages from a
> > specific system.
>
> This are three calls. Fine with the software, like we've built for Android
> for example, but quite bad if this is your admin script.
I wouldn't say it's bad. That admin script would simply use one api call to
get the package ids and we'd let the author of the script / the person
executing the script make the decision on which of those packages ids
are supposed to be installed / removed, etc.
> Leaving the "by ID" still available, isn't it better to have a convenience
> layer by name?
I'm all for making things easier to use. But not at the costs of making
the behavior ambiguous.
-MZ
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
