Hi Dave,
Thank you yet again. My comments in line. And the webrev is now
http://cr.opensolaris.org/~clayb/AI_server/webrev_final_rc7/
Thank you,
Clay
On Fri, 17 Oct 2008, Dave Miner wrote:
> Getting close. Trimmed to issues I think still need resolution, I'm
> satisfied with the others.
>
>
> >>>> So what's the AI.db file, and what's in it? Is it something we should
> >>>> be generating in the build rather than checking in as binary?
> >>>>
> >
> > The AI.db file is just a prepopulated database (it has the columns
> > necessary for the database to be wellformed in the mind of
> > AI_database.py's validateDB routine. However, it is something which could
> > be easily recreated by setup_service.sh using just a big honkin' echo(1)
> > to sqlite3(1).
> >
>
> Either that, or the Makefile needs to do it. What we can't have is a
> binary file in the gate with no clue of how to recreate it.
I think the Makefile would be the best place for now. I've added the
appropriate echos there, let me know if I got the structure correct
please.
> >>>> 95 et al: 744 is a most unusual mode. 755 for executables, please,
> >>>> though in general we just don't bother with setting modes in these rules
> >>>> and do so on the install phase.
> >>> This has been fixed
> >>>
> >> Looks like it's still off to me.
> >
> > Hrm, I'm not seeing any instance of 744 in the prototype_com; I did have
> > the wrong webrev up for a few minutes perhaps you saw that, or am I
> > confused?
> >
>
> The comment was against the ai-webserver Makefile, not the package's
> prototype_com.
Ah yes forgot about those chmods, they're 755 now too.
> >>>> default.xml
> >>>> why do we set swap size in the default manifest? Can't we use the
> >>>> algorithms in the orchestrator to compute this automatically in the
> >>>> default case?
> >>> I don't have much knowledge about the A/I client side I think Sundar or
> >>> Alok would be the one to ask
> >>>
> >> Let's get that answered.
> >
> > I've sent an e-mail off to Alok with you and caiman-discuss CC'd. Also, I
> > believe that Alok has a new default manifest to populate with shortly.
> >
>
> Need to resolve this.
Okay, I've removed the swap tag, and filed 4044 - "Need to determine
fields for default.xml for November" to see that we find the best minimal
install possible. Alok also suggested I remove the
target_device_overwrite_root_zfs_pool element.
> >>>> SUNWinstalladm-tools/prototype_com:
> >>>> I don't think the schema files belong in /var; something in /usr/share,
> >>>> perhaps, seems more appropriate. This would affect Makefile.cmd and
> >>>> Targetdirs.
> >>> Yes, there is /usr/share/xml/rng however, there's the possibility of A/I
> >>> service specific versioning of the manifests. Perhaps
> >>> /usr/share/xml/rng/osol-install/auto-install/<version>? This is more
> >>> Sundar's call likely too.
> >>>
> >> /var is wrong, though, see filesystem(5) for guidance on what should be
> >> in /var.
> >
> > I've moved the schema location to
> > /usr/share/lib/xml/rng/auto_install/2008.11.
> >
> > I've updated publish_manifest, prototype_com, and Makefil.targ to reflect
> > the new location too. Thank you for the pointer to filesystems(5) too. Did
> > I do the right thing in the Manifest.targ.
> >
>
> I don't see any actual declaration of
> ROOTUSRSHARELIBXMLRNGAUTOINSTALL200811 in Makefile.cmd, but please don't
> create a Makefile reference with a name that's release-specific.
I've changed the make tag to be ROOTUSRSHARELIBXMLRNGAUTOINSTALLVERSION
but still think versioning the schema off the first version needing that
schema would make life easier for admins (i.e. this may not change for a
long time, but when it does it'd be
/usr/share/lib/xml/rng/auto-install/201108 or some such).
> Dave
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>
