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 ?
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.
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 ?
What will be supported in the future is an unknown.
Yep. Though since legacy sysid is EOLed, its future is certainly
not going to cross S10 boundary.
As I understand it not all sun4u platforms are supported in Solaris 11
Yep, that's correct. And you address that by displaying warning
for sun4u on lines 202-207.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
