building an ON IPS repository

I've been working with the gracious help of Mark on making the ON consolidation create an pkg(5) repository as part of the build process. If you build the ON consolidation from source ever, this is probably interesting to you.

Our changes are destined to be integrated into the main ON gate, which should happen in November 2009 sometime (though that's subject to change and doesn't constitute a promise). We've tried to make it easy for folks to build their own ON IPS repositories for testing in advance of integration of our changes. You can access the latest instructions for building your own ON repository in the README which lives in our development mercurial repository.

If you do want to try this out, I strongly recommend subscribing to on-ips-dev@opensolaris.org, as that's where we're answering questions, giving heads-ups about important changes, and having development conversations. We've got some sizable changes coming over the next few weeks, including a protocmp which works on IPS manifests.

I'm really enjoying using the same tools as we expect our customers to use. It's now pkg image-update to update my ON development bits rather than the development-only tool bfu. pkg image-update is at least as fast, if not faster than bfu, especially over a slower link. That's because only the bits which have actually changed between versions are downloaded and updated by pkg(5). Nice. And nice that our normal upgrade experience is now as blindingly fast as ON developers have come to expect.

Comments:

I'd still rather have a Flash(TM) equivalent than update my production systems ad hoc like what you describe above.

A Flash(TM) like functionality would enable us to produce stable builds of the operating system, certified to work with other already certified software components, enabling us to deliver a whole stack (and blindingly fast, preconfigured systems).

It is my understanding that the "Automated installer" currently does not offer this functionality; and I haven't found any indications of it ever offering anything like Flash(TM).

Posted by UX-admin on October 11, 2009 at 11:21 PM PDT #

I'm not recommending the procedure I described above directly for production use. It is however, very convenient for ON developers, as we use the same underlying tools to upgrade as those who choose to upgrade -- that is, we test the image-update path as part of our every day development. Most people who want to upgrade shouldn't have to start from source. (Though obviously that avenue is available for someone who didn't need support from Sun.) And not everyone wants to upgrade -- plenty of shops work with an freshly installed 'golden image' instead of upgrading/patching.

I can't currently speak to the plans of the install team about meeting the market needs that Flash does today. I know they're aware of some of the requirements, and certainly have been willing to hear more about the requirements at caiman-discuss@opensolaris.org, and have mentioned Flash explicitly in a number of documents in the Caiman project. They're definitely not done yet. I will say I've been enjoying the Distro Constructor functionality a great deal, though don't personally know how use of it will play into supportable images (though expect that some uses of DC will create supportable images) nor do I know whether it will fill your specific operational need. Again, I recommend giving constructive commentary on requirements to the install team over at caiman-discuss@opensolaris.org.

Posted by Liane Praza on October 11, 2009 at 11:44 PM PDT #

UX-admin, one of the most awkward part about the current Flash implementation (besides being non-redistributable ;-/) is the sideband data store represented by its various configuration files. These mean that whenever a file anywhere in Solaris requires special handling by Flash, the project team needs to modify the Flash configuration files (and possibly Flash itself). This often gets forgotten, and bugs result.

The right way to re-implement Flash is at least partially in the pkg(5) subsystem itself; the necessary metadata for files that require special handling should be part of the package manifests, and thus can be specified (and tested readily!) by the team delivering that new software to OpenSolaris.

Flash is very popular; I anticipate its re-emergence in a sleeker, redistributable form.... Anyone interested in helping create such is encouraged to participate via pkg-discuss@opensolaris.org or caiman-discuss@opensolaris.org.

Posted by Bart Smaalders on October 12, 2009 at 01:26 AM PDT #

Ms Praza and Mr Smaalders, thank You both for taking the time to reply.

I would love to participate in the discussions taking place on discuss@opensolaris.org, unfortunately the short and long of it is that at the point in life where I'm at, time is very scarce, and discussion would involve significantly more time than is available to me right now.

The issue is that some sort of "compressed golden image" production tool is still very much needed, for various reasons, some of them being stability, no ad hoc updates from the internet, speed of deployment, guarantees, and control over the software stack delivery.

So what is someone who would very much like, but can't afford a lenghty discussion to do? Stuck between the choice of not making engineers aware of the issue, and "putting a bug in their ear" that Flash(TM) or Flash(TM)-like functionality is very much needed, I chose to do the latter; as it turns out, spending 2-3 minutes to write a comment to someone who might be very well working on this code anyway, or know the right person, is about the most effective (and only possible) way when one is out of time.

And just for the record, it is exactly the fact that Flash(TM) can distinguish what NOT to include that sets Flash(TM) apart from the competition, where he doesn't really have any. The process might be manual and complex now, but judging by past deeds, I'm pretty confident that engineers at Sun will find some way to implement a better Flash(TM) than Flash(TM).

So long as it enables the system engineer to build a compressed golden image like Flash(TM) did, it doesn't matter what it's called or how it's implemented.

Posted by UX-admin on October 14, 2009 at 12:54 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

Liane Praza

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today