On 11/07/11 16:59, kristina tripp wrote:
On 11/7/2011 2:15 AM, Jan Damborsky wrote:
Hi Kristina,
please see my response in line.
Thank you,
Jan
On 11/04/11 16:53, kristina tripp wrote:
Thanks for taking the time to review this Jan. Comments follow
On 11/4/2011 3:31 AM, Jan Damborsky wrote:
Hi Kristina,
My apologies for the delay.
I have one general comment. I believe it would be useful to capture
at one place how particular sysid configuration scenarios map to new
sysconfig ones as well as which combinations are considered invalid
by js2ai tool. Perhaps pushing some short doc into caiman-doc
gate may help.
Having such document, it would be easier to validate if the code
accomplishes what it is supposed to do :-)
Agreed. There was functional doc that Evan and I did initially to
outline what values we would convert in js2ai and what those
conversions looked liked but I gave upon trying maintain. Instead
I opted to output the xml code that we would output in a code block
in conversion routine being executed. In a perfect world I would
like to spend the cycles and to have a general design doc but since
I'm technically suppose to be working on another project now I don't
see this happening anytime soon. But one never knows, js2ai just
keeps pulling me back for more tweaks as I keep learning about
little things that need to be addressed in the conversion process
that have gone undiscovered due to lack of hardware resources and
testing resources.
What keywords we support for conversions however is documented in
the js2ai man page.
Yep, I am aware of that. Now I am wondering if we could also try to
clarify
those more complex scenarios in js2ai man page. If you think that
might be
reasonable thing to do, would you mind to file CR against that man page ?
Some yes. I've always worked closely with Alta to make sure things
are documented. It only makes sense to document some of this stuff
is a limited scope. The keyword network_interface is simple documented as
network_interface Only a single interface is supported.
Limited support for PRIMARY. Only the
first interface encountered in the
sysidcfg file is processed.
Conversion errors is the primary way that we tried to gide the
customer during the conversion process on the actions required. I
don't think saying we do this for primary has any real purpose in the
man page.
By scenarios I assume you mean something along the lines of when
name_service=x and net_interface=y we do z.
Yes, that's what I was referring to.
There seems to be more such scenarios, though.
From taking a quick look at the code, it may be perhaps worth
to elaborate more on
* how PRIMARY keyword is dealt with
* when DefaultFixed versus Automatic NCP is chosen.
Are you asking me to expand the documentation within the code as it
stands now?
As we discussed off-line, enriching the code with more comments
will address the documentation issue for purposes of this fix.
I am satisfied with the updated webrev you provided off-line.
You may also want to make it public just in case somebody else
would be interested in what's changed.
For sysidcfg conversions hat was never in the plan because
originally we never envisioned that there was an interdependency
between tags in sysidcfg. This has only recently changed when you
or William pointed out that if a name service was configured the
network could not be Automatic and DefaultFixed was required. This
information will eventually need to get documented in the js2ai man
page.
That would be nice indeed.
[...]
conv.py
=======
197 if values[0] in ["sun4c", "sun4d", "sun4m"]:
To make code more robust, I am wondering if it may be better
to check for supported architectures instead of trying to
cover all non-supported ones (which seems more fragile) -
e.g. the check may then look like:
197 if not values[0] in ["sun4u", "sun4v"]:
I'm going to leave this alone as the unsupported architectures are a
known entity at this point in time.
You are right. Though I am wondering what happens if user supplies
invalid architecture (e.g. due to user's error). Is that even possible ?
That would technically be possible but there is an implied assumption
that the jumpstart configuration we are converting is valid. The
worst that would happen is that we'd create a criteria file against
that arch. In general we don't validate all values that we are
converting. There is some minimal validation that we do at various
parts but arch is not one of them.
ok. Thank you for clarifying that.
Jan
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
