On 02/23/10 03:01 PM, Clay Baenziger wrote: > Hi Dave, > Thank you for sending this out! It's got all sorts of great things > to think about. To understand where we're going, I have a few questions on > the proposal: > > 1) Why do you prefer lofs(7FS) rather than leaving images as ISOs > and using lofi(7FS) to simplify directory structure for admins in the > section starting: > "For both SPARC and x86 services, the service image will be mounted using > lofs(7FS) at the path /etc/netboot/<service-name>." > I do appreciate using directory structured images for IPS managed > services as this allows image-update to do delta only updates. (Which > I'm not sure it'd be able to do were it updating a monolithic ISO?) >
As noted in the document, in order to support running the services within zones, where lofi is not currently supported. > 2) With regards to the any-i386-service proposal, if we use checksums > then we can tell if an image is new to the system when a new service is > created. This can prevent image duplication and also recommend (perhaps > require) that the user use the already existing identical service image > reducing disk clutter and GRUB menu length by breaking out to submenus > (does our GRUB support submenus though) per image, if length requires? > As noted during discussion with Jan in the first round of review, this design does not support multiple services from a single image. Aliasing provides similar functionality, but explicitly. > 3) I'm not sure what you mean a service must be named in the section about > update-service? You must provide the name of the service to be updated. From the section: > "Additionally, as noted in the Provisioning section, update-service will > not act on a service image provisioned from an ISO image. If -s is > specified, the srcimage must be a package specification in the form of a > pkg FMRI or URI to a .p5i package info file." > I'm not sure what this quote has to do with your question... > 4) Why not allow us to replace an ISO provisioned service? Replacing a > directory or an ISO file isn't hard and we could update it with an IPS > provisioned image easily enough too, bringing legacy images into the > fold? (Though I do appreciate that hopefully folks will use the IPS > based images; I suspect a number of developers would find overwriting > their ISO useful for testing though.) > See my responses to Karen in the prior discussion. With respect to developers, we will trivially be able to set up pkg repo's locally as part of the conversion to generating IPS packages directly, see the work in on-ips-dev around this. Developers should primarily be using the same experience as customers. > 5) What happens if -s is not specified to update-service? Is the latest > IPS boot image related used for the update, from the system's default > publisher? > The latest version of the package from the image's publisher. In essence, "pkg image-update". > 6) If multiple services can use the same image, what do you envision for > the behavior of remove-service on a shared image? Right now, we simply > leave the shared components alone and remove anything which will be > defunct after service removal. > As noted earlier, there are not multiple services configured from the same image. Services are either directly associated with an image, or aliased against another service, hence there is no shared ambiguity to resolve. > 7) I see in your 172.0.0.1 service creation example that you envision a -a > <arch> create-service argument. Do you feel the idea of a fat service > which can install either SPARC or X86 to be not-useful? (I.e. not many > customers are heterogeneous?) It seems at least a good portion of folks > would be heterogeneous and would want a build FOO service for both SPARC > and X86 while managing two separate services is a bit cumbersome -- > especially if we support automatic updates for it, etc. > A single boot image that covers both services is not possible due to overlap of namespace within the image. > 8) I'm curious as to why we should use arbitrary property group names > (e.g. AI_1) opposed to AI<service name> since I think the service name > will need to follow roughly the same naming restrictions as SMF > property groups impose for DHCP macros, etc.? To my view, this slows > down lookup on a big AI server having to scan all SMF property groups > for a service named "service_foo" opposed to AIservice_foo and simply > doing away with the redundant service_name property. > The scalability is a potential issue, but otherwise complicates a rename to also include creating new property groups and deleting them. If that turns out to be a problem we can revisit, but I don't expect it to be a significant one. > 9) Should an alias be able to be turned on or off? What will be changed in > a state change? I only see removal from global_menu (if included) as > the only change. What else might be involved? > As with any other service, enable and disable are supported. > 10)In your Example 1, should os-dev-131-i386 have a boot_file and > boot_menu SMF property or will these be assumed to exist in > /etc/netboot under the standard convention and not be tracked like the > any-i386 service? > They are under the standard convention. > 11)In your Example 2, you mean creating an AI_5 property group not > recreating an AI_2 property group right? Yes, that is a typo. > Short of symmetry, is there > any reason to have the global_menu property for SPARC services? > (Otherwise, it seems to just be a dangling artifact?) > Symmetry for now, a possibility for later. Dave
