Hi, Milan. Thanks for the clarifications! More below. On Tue, Feb 04, 2014 at 01:33:01PM +0100, Milan Zázrivec wrote: > 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?
Yes, I hear you. Although I am wondering is it really important here, as long as the package finds its end point server and installs desired package? In any case this is the *same* server, right? Maybe I am missing something here, but the task is to install package from specific channel on specific machine, as long as the package *in general* is available to the machine, regardless profile. Can we actually have in the database the same servers with the same IPs but different physical boxes? Even so, MAC address can resolve this (the MAC you know right away). I am more talking about the case, where you have nice access to the host info (RPM db, ifconfig data etc) and want to "toss up" a little short almost-oneliner script that would do something, generally do as few as possible network calls. Of course, a complex dedicated software (like our Android app for the SUSE Manager/Spacewalk) does it differently. > Sure, these packages would have different checksums. But that's not the > point. Right. But they are in the different channels. So if you can specify the channel name, shouldn't it prevent the clash? But that's also pretty extreme, because if you have 100 VMs somewhere in the cloud, the management is pretty straight-forward, as they are "raw images" that you manage in pretty simple way. These parameters for package clarification can be simply optional and can be omitted, in case you have that simpler layout. > 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. This is flexible, I agree. Still I see here that the script needs to have filtering logic, in order to find the required ID. Right now the UI gives you a system with listed packages, ready to get installed. In that list, you can get clashes? > > 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. That's exactly what I would like to avoid. :-) -- Bo Maryniuk SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer The number one problem in our country is apathy, but who cares! _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
