Joseph J. VLcek wrote: > Dave Miner wrote: >> Joseph J VLcek wrote: >>> Jan Damborsky wrote: >>>> Hi Glenn, >>>> >>>> >>>> Glenn Lagasse wrote: >>>>> Hi Jan, >>>>> >>>>> * Jan Damborsky (jan.damborsky at devcom.cz) wrote: >>>>>> Hey Glenn, >>>>>> >>>>>> I have read through the spec - good work ! >>>>> >>>>> Thanks! I appreciate that. >>>>> >>>>>> Please see my comments below. >>>>>> >>>>>> Thank you, >>>>>> Jan >>>>>> >>>>>> >>>>>> I have couple of general questions - I am not sure if they should >>>>>> be reflected in functional spec or should be captured somewhere else, >>>>>> I think that knowing that information might help to verify if >>>>>> problem statement and project scope have been correctly identified: >>>>>> >>>>>> * what is the main target audience we would like to focus on and >>>>>> satisfy >>>>>> their needs by this project ? >>>>> >>>>> The target audience are people that want to create preconfigured >>>>> virtual >>>>> machines using the distribution constructor. >>>> >>>> Do we happen to know, what their requirements and expectations are with >>>> respect to what they can install into virtual image and what level of >>>> post install configuration will be supported ? >>>> For instance, I am thinking that some people would be interested in >>>> creating OpenSolaris based virtual appliances with application stack >>>> which might be available in different than IPS format - is it something >>>> we might want to consider ? >>> >>> >>> It is interesting you point this out. Glenn and Keith and I were >>> talking about how folks could get bits into the VM image. The current >>> way would be to get the bits into an IPS repo. >>> >>> but I was thinking it could be valuable to have the AI engine, in >>> addition to pulling bits from IPS also have exra bits built into it >>> by DC. >>> >>> This way if a customer would like to do a custom AI install, or VMC, >>> with bits they develop, they would not have to push there bits to an >>> IPS for AI to pull from. >>> >>> We could provide some, as yet to be defined, method of adding some >>> bits to an AI image that could be copied from the image via CPIO >>> after the IPS transfer. >>> >>> This would provide an easy way for folks to add custom bits to am AI >>> image. >>> >> >> I'd think that the most common need for additional, non-IPS content, >> would be SVR4 packages. Beyond that, I'd expect to see requests to >> support tarballs, debian-format packages from the Nexenta repositories >> perhaps, RPM's since there have been Solaris RPM packages used in some >> communities. > I hadn't thought of these other formats but it would be a good idea. Thanks > >> >> Note that these requirements are not specific to the VM constructor, >> but apply to automated installation in general... > > > Yes that is what I envision. The intent would be to make it easier to > add content to an image and not require a user to put it in or set up
This is not advisable. IPS needs to be aware of the files on the system so that it can effectively manage the system. If you start laying bits down in arbitrary places, then when packaging operations are performed, those bits may be deleted, moved to another location, etc. If the issue is with the difficulty in creating packages, the correct answer is to improve the publication process. Note this only applies if you're talking about OpenSolaris-based images that use IPS, etc. Cheers, -- Shawn Walker
