On 02/16/10 05:56 PM, Karen Tung wrote: > Hi Dave, > > Please see my further comments/questions to your response inline. > I removed the items that I have no further comments. > > On 02/15/10 15:18, Dave Miner wrote: >> >>> - what will happen in update-service to a service that's created via an >>> ISO file? >>> >> >> My initial assertion is that we wouldn't allow it (the note in >> Provisioning that a service provisioned using the ISO can't be >> converted to packaging; perhaps I should repeat it here). The problem >> that's raised if you allow this is how to ensure that the resulting >> image is "clean" and not containing possibly harmful debris that >> wouldn't appear in a pkg-provisioned image. I suppose a brute-force >> move aside and effectively re-create the image could get around this, >> but wasn't quite sure whether to go there yet. > > In the "Provisioning" section of the document, it says that the "The > existing -s option to select a > source ISO file will continue to be supported to allow servicing of > earlier boot images > that were not published into pkg(5), or for convenience when an ISO has > already been downloaded.". > > I certainly understand that earlier images not published into pkg(5) can > not be updated. > However, since this option is provided also for the convenience of not > having to download > content of ISO that's already been downloaded, I feel that if we don't > allow update at all > for such images, we are penalizing the user for "saving bandwidth". > Perhaps we can build > some checksum or something into the images to detect whether they are > actually the > same as the one that's available from pkg(5), and associate them somehow? >
The problem that's faced here is that, rather than doing a "pkg image-update", we'd be doing a "pkg install" into an already-populated image. The results of those two operations aren't likely to be the same. We'll take a look at the issue as we get into implementation, but this was primarily provided as a compatibility aid for serving existing images as we're not planning to go back and publish them as packages. I don't feel that badly about this particular limitation as it primarily applies to the hobbyist types. > >> >>> - in "rename-service", will there check to make sure that a user does >>> not >>> rename a x86 service to be default-sparc? Or we assume the user knows >>> what they are doing? >>> >> >> They're merely naming conventions, so no, I wasn't expecting that >> would be limited. >> >>> >>> Removal Section: >>> ------------------------------- >>> - If the service to be deleted is the default, what will the "new" >>> default be? >>> >> >> There won't be one. You have to designate it using alias-service. >> > > From your answer to the above 2 comments, it sounds like the > default-xxxx service is just > a name. My understanding from reading the document is that they are > actually significant > in the sense that the default-x86 is the service that will be used for > all the x86 clients that > doesn't have a specific create-client done for them, and the same for sparc. > If things work as I assumed, then, doesn't rename/alias a x86 service to > be default-sparc create a problem? > > Also, if the default service is deleted and there's no new default, what > service will the clients > use when they boot if that client doesn't have an explicit create-client > done for it? > If the configuration points a client at a service that doesn't exist or is of the wrong architecture, it will fail to boot. Troubleshooting those failures is a core problem that administrators have to be somewhat skilled at since there are a variety of reasons why network booting fails and the average BIOS doesn't give you all that much information to work with when it does fail. > On the other hand, if the name default-xxxx is not significant, why have > this special name? > Establishing a naming convention allows the software to do some automatic setup that creates a more complete and manageable environment. I've reserved one service name, "any-i386", because it allows the server to provide a value-added service (automatic assembly of the GRUB menu); I don't see any comparable value-add that reserving "default-i386" or "default-sparc" would provide. It's clear there are environments (where installation activities are heavily controlled) that will want neither one to exist, at least in the form proposed here. As I think about this further, I'm not even sure we'll reserve the "any-i386" name, but instead make it a convention. This is because I can see use cases for having multiple distinct "any-" style composite services and it's a small change to the implementation to make that possible. Dave
