On 12/14/2009 1:55 AM, Clay Baenziger wrote: > Hi Frank, > Thank you for giving this some more thought! I'm still confused > and included some reasoning based off my casual reading of Edward > Tufte's books and just my understanding of a table being a > higher-order display mechanism than a list. Perhaps, you (or someone) > can explain what I'm mis-understanding as to the intentions of this > data, however. > > Thank you, > Clay > > On Fri, 11 Dec 2009, Frank Ludolph wrote: > >> If a user wants to know "what manifest will a machine get?", they >> shouldn't have to review a list of manifest-and-criterias - it is >> very tedious and error-prone. Rather there should be a query command >> with, manually providing the criteria values of interest (multiple >> manifests might match), or alternatively a "no-install" boot. > > There is a command already available. One can go to http://<install > server>:<service port>/manifest.html and enter a machine's criteria to > see what manifest is returned. However, this interface could use some > sprucing up (see bug 13316) and further provides no logic path as to > why a manifest is selected. This isn't exactly a CLIP-compliant command and it doesn't appear to be on the man page, but I'm looking at the 09.06 docs. > > (A simple approach to do so, would be to provide a table like > list-manifest(1) does today and simply show which criteria hits on > which manifest with the leading -- returned -- manifest being first in > the sort order, followed by all lesser matches descending.) There is a problem in that the various manifests might/will have differing criteria as well as criteria values. The user must enter the values for all criteria used in all the manifests to get a valid result. > > Otherwise, I don't believe there is any need to have a > list-manifest(1) command without this question and the question of, > "gee what criteria do I have configured [which is pretty open ended > and may still call for the ability to compare between manifests]." > (Or, what's the envisioned use case for this data)? I think there is a valid use case for "What are the criteria for this specific manifest". The "gee..." question is also has some valid use cases though probably more along the line of "familiarization" rather than "validation." So I think there is reason to include a list-manifest command. > >> As for the output of installadm -m -n <svcname> it would be good to >> group the criteria by their selectiveness, unique criteria (mac, IP) >> first followed by generic criteria (arch, memory, platform, ...) > > So, should the list include all in-use criteria service wide for all > manifests akin to the following example to keep the output records > similar? > > # installadm list -m -n<svcname> > Manifest Criteria > -------- -------- > Manifest1 arch = SPARC > platform = > mac = C0:FF:EE:C0:FF:EE > ipv4 = > mem = > Manifest2 arch = > platform = > mac = C0:FF:EE:C0:FF:E0 - C0:FF:EE:C0:FF:ED > ipv4 = > mem = > Manifest3 arch = AMD64 > platform = > mac = > ipv4 = 172.20.48.190 - 172.20.48.255 > mem = > Manifest4 platform = SUNW,Sun-Fire-880 > ipv4 = 172.20.24.0 - 172.20.48.0 > mem = 1024 > > In particular, a few sections of Edward Tufte's book Envisioning > Information call out to me: > (p. 53): "Confusion and clutter are failures of design, not attributes > of information. And so the point is to find design strategies that > reveal detail and complexity [...] Among the most powerful devices for > reducing noise and enriching the content of displays is the technique > of layering and separations, visually stratifying various aspects of > the data." > > It seems to me we are moving from a structured and textured order (a > 3D output of the data in the form of a table whereby the table can be > column sorted for easier human searching and is in row-manifest, > column-criteria form) to a list where the data is no longer > row/column-wise comparable and there is no separation of data other > than by the manifest. (Perhaps this is intended depending on the > envisioned use case?) > > Otherwise, another part of Tufte which struck me was (p. 65): "Failure > to differentiate among layers of reading leads to cluttered and > incoherent displays filed with disinformation, generated by the > unrelenting interactive visual arithmetic of flatland, 1 + 1 = 3 or > more [interaction affects of presentation and data to cause a > non-existent apparent data to form]." > > This all combines for what I always remember most about Tufte as his > tirade(s) against "chartjunk" and in p. 33 he points out: "By giving > the focus over to data rather than data-containers, [...] design > strategies are transparent and self-effacing in character." > > The repeated criteria names are chartjunk and increase linearly with > the number of manifests (opposed to the tabular form when they > increase with the number of used criteria -- something I believe to > likely be smaller and the bare minimum necessary). It is this > repetition of chartjunk which can also require a reader's mind to > context-switch causing confusion and pain reading this data when > making any comparison. > > I bet I'm missing something though; I'm pretty good at that... There should be a distinction as to the basic task, whether the user is trying to find a bit of data,or whether he is looking to see a pattern, to grok the information hidden in the a see of data. The first involves making it easy to scan through the structure, the second is structuring to enhance visualization and understanding. I believe that all of the use cases are of the former which is about scanning.
I prefer the tabular output for its compactness, sense of order, and ease of scanning in several ways, but it is virtually impossible to use in terminal windows that are not wide enough where logical lines are folded into multiple physical lines. It is so bad that is should be avoided at all costs. Users will usually widen the window, if possible, and reissue the command in order to see the lines unfolded. The output for list-manifest can easily exceed the terminal window width so a tabular format isn't reasonable. So for a list-manifest, where *all* criteria are to be listed, the two level list shown above is probably the best that can be done in a terminal window. But insure that the criteria are always listed in the same order and suppress the null criteria. If there is a form of list-manifest where the user specifies the criteria to be listed, then a tabular format would be better. In this case the user will likely limit the number of criteria entered and adjust the number to better work with the available width. Frank > > Thank you, > Clay > >> Frank >> >> >> On 12/9/2009 7:39 PM, Clay Baenziger wrote: >>> Hi John, >>> I'm really happy you pointed me to the AI design doc update as I >>> hadn't noticed the installadm list difference! On big concern I have >>> is that if an admin is trying to understand why a machine is getting >>> a particular manifest there's no means for comparison in the >>> proposed output: >>> >>> # installadm list -m -n<svcname> >>> Manifest Criteria >>> -------- -------- >>> Manifest1 arch = SPARC >>> mac = C0:FF:EE:C0:FF:EE >>> Manifest2 mac = C0:FF:EE:C0:FF:E0 - C0:FF:EE:C0:FF:ED >>> Manifest3 arch = AMD64 >>> ipv4 = 172.20.48.190 - 172.20.48.255 >>> Manifest4 platform = SUNW,Sun-Fire-880 >>> ipv4 = 172.20.24.0 - 172.20.48.0 >>> mem = 1024 >>> >>> So my question (which I think is the most likely question for this >>> view) is what manifest will a machine get? For example, with only 4 >>> manifests can one ascertain what manifest a Sun Fire V880 with 2GB >>> of RAM and MAC address C0:FF:EE:C0:FF:EE and IP address of >>> 172.20.48.251 get? (How about if the criteria have a priority; for >>> example what if a manifest has a machine's exact MAC address and >>> another manifest has its exact IP address?) >>> >>> Versus the old output (which always concerned me as it could grow >>> unwieldly wide but would provide criterion priority, manifest >>> instances and a means to compare by each criterion): >>> >>> root at jumprope:/tmp# installadm list -cn install_test_ai_x86 >>> manifest instance arch mac ipv4 >>> platform mem manufacturer model >>> -------------- -------- ----- ----------------- --------------- >>> ---------------- ------- ------------ ------ >>> manifest1.xml: >>> 0 sparc C0:FF:EE:C0:FF:EE >>> - - - - - >>> C0:FF:EE:C0:FF:EE - - >>> manifest2.xml: >>> 0 - C0:FF:EE:C0:FF:E0 >>> - - - - - >>> C0:FF:EE:C0:FF:ED - - >>> manifest3.xml: >>> 0 amd64 - >>> 172.020.048.190 - - - - >>> - 172.020.048.255 - >>> manifest4.xml: >>> 0 - - 172.020.024.000 >>> sunwsun-fire-880 1024 MB - - >>> - 172.020.048.000 1024 MB >>> 1 - - >>> 172.020.024.000 - 1025 MB apple ibook >>> - 172.020.048.000 2048 MB >>> >>> >>> Also, I think we'd need to think how we want to handle multiple >>> criteria sets per manifest (referred to as instances by the current >>> installadm list, delete-service and the AI database)? (See my >>> example with an Apple iBook as a machine in the criteria for >>> manifest4 which has instances 0 and 1.) >>> >>> Thank you, >>> Clay >>> >>> On Wed, 9 Dec 2009, John Fischer wrote: >>> >>>> Clay, >>>> >>>> Thanks for the help. I appreciate you taking the time to type this >>>> up. I'll update the webrev tomorrow morning. >>>> >>>> Thanks, >>>> >>>> John >>>> >>>> Clay Baenziger wrote: >>>>> Hi John, >>>>> As we talked about in IRC and some high level thoughts: >>>>> *Please update your code to be in sync with slim_source (based >>>>> off >>>>> the Python 2.6 Python files) >>>> >>>> Will do. >>>> >>>>> *Please move findTFTProot() from delete_service to >>>>> installadm_common so that it's more obvious there are multiple >>>>> consumers. Further it seems, which_arch would be a general >>>>> function well provided through installadm_common. >>>> >>>> Already moved. >>>> >>>>> *I'm rather concerned that you're rewriting list-manifest opposed >>>>> to simply using what's already written. The only bug I see >>>>> affecting list-manifest is pretty trivial: >>>>> 4298 installadm list -n should give different output if there is >>>>> no custom manifest >>>>> Further, I think this bug: >>>>> 4646 list: showing added manifest for a non running service. >>>>> Would probably better be: >>>>> 4646 list: Should provide warning manifests listed are for a >>>>> non-running service >>>>> (as we want to allow publication/deletion/listing of manifests >>>>> when the service is offline since there's no requirement for >>>>> the >>>>> service to be online and this is how one can setup a service to >>>>> "go live" without affecting other things) >>>> >>>> Don't recall why I decided not to mess with list-manifest. I'll >>>> see if I can find my notes. >>>> >>>>> *I think you should take bug 4320 - installadm list -n should use >>>>> the -c option as default. And you should actually take ownership >>>>> (and mark as FIXINPROGRESS 4298 - installadm list -n should give >>>>> different output if there is no custom manifest. >>>> >>>> Defect 4320 does not match the design specification for list. >>>> I'll talk to Ethan about it. The design specification is located >>>> at: >>>> >>>> >>>> http://hub.opensolaris.org/bin/download/Project+caiman/auto_install/DesigndocdeltaforAISpring2009.2.pdf >>>> >>>> >>>> Defect 4298 should report an error if installadm list -m -n >>>> service_name >>>> does not have a custom manifest. This is currently what the list >>>> subcommand does. >>>> >>>>> *Do you have any example output as I can't visualize what this >>>>> looks like? (Also, have you run the output past Frank as he'd >>>>> given feedback on list-manifest?) >>>> >>>> OK. See the design specification for more detailed output: >>>> >>>> Manifest Criteria >>>> -------- -------- >>>> devpublisher.xml arch = i86pc >>>> mac = 01:C2:52:E6:4B:E0 >>>> ipv4 = 010.000.002.015 >>>> devpublisher3.xml arch = i86pc >>>> mac = 01:C2:52:E6:4B:E6 - 01:C2:52:E6:4B:E9 >>>> devpublisher4.xml arch = i86pc >>>> ipv4 = 192.168.168.151 >>>> devpublisher5.xml arch = i86pc >>>> ipv4 = 192.168.168.251 >>>> mac = 01:C4:52:E6:4B:E6 - 01:C4:52:E6:4B:E9 >>>> devpublisher6.xml arch = i86pc >>>> ipv4 = 192.168.168.012 >>>> mac = 01:C4:51:E6:4B:E6 - 01:C4:51:E6:4B:E9 >>>> mem = 2048 MB >>>> somethingelse.xml arch = i86pc >>>> mac = 01:C2:E2:E6:4B:E9 >>>> >>>> >>>>> Code bits: >>>>> list.py: >>>>> line 189 find_sparc_clients >>>>> line 337 find_x86_clients >>>>> I like the layout of these functions, however, couldn't >>>>> this data be rolled up into a x86_client and sparc_client >>>>> class to allow caching and easier reuse across all AI >>>>> components? (This would be very useful for the delete*.py >>>>> bits) >>>> >>>> Hmm... OK. This will take me a little while longer. May not make >>>> tomorrow's new webrev. >>>> >>>>> line 364 get_menu_info >>>>> Please use the GrubMenu class in installadm_common, unless >>>>> I'm missing what's special here? >>>> >>>> Already saw that one when you asked about moving findTFTPboot() into >>>> installadm_common.py and have a working list using it. >>>> >>>>> line 311 (and elsewhere) >>>>> Instead of concatenating two paths with a '/' please use >>>>> os.path.join(). >>>> >>>> Will do. >>>> >>>>> line 569 >>>>> "no local service\n" or "no local services\n"? Also (in >>>>> other places too), please follow PEP8's recommendation to >>>>> leave operators on the upper line when a line wrap is >>>>> encountered. And lastly I think you should be lined up >>>>> with the underscore from above. I think the lines would >>>>> be: >>>>> estr = _('%s: error: no local services\n') %\ >>>>> os.path.basename(sys.argv[0]) >>>> >>>> Ah, OK. >>>> >>>>> line 628 >>>>> You're doing an assignment here so rdict and second are >>>>> the same object: >>>>> >>> def c(foo): >>>>> ... b=foo >>>>> ... del(b[1]) >>>>> ... >>>>> >>> a >>>>> {1: 1, 2: 2, 3: 3} >>>>> >>> c(a) >>>>> >>> a >>>>> {2: 2, 3: 3} >>>>> You might want to see: >>>>> http://docs.python.org/library/copy.html >>>> >>>> Ah. I see. OK will do. >>>> >>>>> line 633: this line assumes that rdict has list objects as its >>>>> values. Otherwise, one will get an AttributeError likely. >>>>> If you're assuming that each dictionary only contains lists it >>>>> could be written for quicker execution, I believe, as: >>>>> >>> a={1: ['a'], 2: [2], 3: [3]} >>>>> >>> b={1: ['b'], 'c': [4]} >>>>> >>> def merge(foo, bar): >>>>> ... c={} >>>>> ... c.update(foo) >>>>> ... c.update(bar) >>>>> ... for key in set(foo.keys()) & set(bar.keys()): >>>>> ... c[key]=foo[key]+bar[key] >>>>> ... return c >>>>> >>> merge(a,b) >>>>> >>> {1: ['a', 'b'], 2: [2], 3: [3], 'c': [4]} >>>> >>>> OK >>>> >>>>> line 809: get_criteria_info: >>>>> Please use more descriptive variable names, I can't parse >>>>> what's going on here >>>> >>>> Changed criteria to mancriteria, crit to key, tk to tkey, tv dropped >>>> using svalue. Also modified the function as MAX/MIN code was >>>> essentially the same. See below: >>>> >>>> def get_criteria_info(mancriteria): >>>> """ >>>> Iterates over the criteria which consists of a dictionary with >>>> possibly arch, min memory, max memory, min ipv4, max ipv4, >>>> min mac, >>>> max mac, cpu, platform, min network and max network >>>> converting it >>>> into a dictionary with on arch, mem, ipv4, mac, cpu, platform, >>>> network. Any min/max attributes are stored as a range >>>> within the >>>> new dictionary. >>>> >>>> Args >>>> criteria = dictionary of the criteria >>>> >>>> Returns >>>> dictionary of combinded min/max and other criteria >>>> >>>> Raises >>>> None >>>> """ >>>> >>>> tdict = {'arch':'', 'mem':'', 'ipv4':'', 'mac':'', >>>> 'platform':'', 'network':'', 'cpu':''} >>>> >>>> for key in mancriteria.keys(): >>>> if not mancriteria[key] or mancriteria[key] == '': >>>> continue # no criteria for instance key >>>> >>>> svalue = AIdb.formatValue(key, mancriteria[key]) >>>> >>>> if key.find('MAX') == 0 or key.find('MIN') == 0: >>>> tkey = key[3:] # strip off the MAX or MIN for a new >>>> keyname >>>> if tdict[tkey] != '': # dealing with range >>>> if tdict[tkey] != svalue: >>>> if max(svalue, tdict[tkey]) == svalue: >>>> tdict[tkey] = tdict[tkey]+' - '+svalue >>>> else: >>>> tdict[tkey] = svalue+' - '+tdict[tkey] >>>> else: # first value, not range yet >>>> tdict[tkey] = svalue >>>> else: # not a range manifest criteria >>>> tdict[key] = svalue >>>> >>>> return tdict >>>> >>>> Hopefully, these changes help. >>>> >>>>> line 891: ensure >>>> >>>> Several corrected. >>>> >>>>> >>>>> Thank you, >>>>> Clay >>>>> >>>>> >>>>> On Tue, 1 Dec 2009, John Fischer wrote: >>>>> >>>>>> All, >>>>>> >>>>>> Updated webrev for this set of changes at: >>>>>> >>>>>> http://cr.opensolaris.org/~johnfisc/list >>>>>> >>>>>> These changes include feedback during a phone conversation from >>>>>> Ethan >>>>>> as well as the installadm man page change to document the list >>>>>> subcommand. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> John >>>>>> >>>>>> John Fischer wrote: >>>>>>> Ethan, Clay and Sundar, >>>>>>> >>>>>>> When you get a chance can you review my webrev at: >>>>>>> >>>>>>> http://cr.opensolaris.org/~johnfisc/list >>>>>>> >>>>>>> These changes are for the installadm list subcommand fix and >>>>>>> will address: >>>>>>> >>>>>>> 4330 - installadm list should show which server provide the >>>>>>> install >>>>>>> services. >>>>>>> 4113 - nice to have an option to show what service the >>>>>>> client is >>>>>>> using >>>>>>> 4298 - installadm list -n should give different output if >>>>>>> there is >>>>>>> no custom manifest >>>>>>> 4597 - installadm list: expect usage statement when giving >>>>>>> service >>>>>>> name without "-n" flag. >>>>>>> 4646 - list: showing added manifest for a non running service. >>>>>>> 5300 - list: does not show informational message for non >>>>>>> running >>>>>>> service. >>>>>>> 8496 - list: no verbiage indicating that a service does not >>>>>>> exist >>>>>>> when a non-existent service is given. >>>>>>> 8529 - 'installadm list' command lists same service three times >>>>>>> 6811 - list: should have similar output between list and >>>>>>> list -n >>>>>>> 8015 - list-manifests output is hard to read >>>>>>> 9094 - installadm list: prints colons for empty MAC fields, and >>>>>>> doesn't account for colons or periods in MAC field's >>>>>>> width >>>>>>> 4175 - install list error slips out >>>>>>> >>>>>>> The changed and added files are: >>>>>>> >>>>>>> usr/src/cmd/installadm/Makefile >>>>>>> usr/src/pkgdefs/SUNWinstalladm-tools/prototype_com >>>>>>> usr/src/cmd/installadm/installadm.c >>>>>>> usr/src/cmd/installadm/installadm.h >>>>>>> usr/src/cmd/installadm/list.py >>>>>>> >>>>>>> These changes also include a change to the Makefile and >>>>>>> prototype_com >>>>>>> file for the delete_service and delete_client to be consistent with >>>>>>> the other python scripts within the /usr/lib/installadm directory. >>>>>>> >>>>>>> The remote service listing is being postponed due to a timing issue >>>>>>> with multiple remote services that grows with the number of >>>>>>> services >>>>>>> within the domain. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> John >>>>>>> _______________________________________________ >>>>>>> caiman-discuss mailing list >>>>>>> caiman-discuss at opensolaris.org >>>>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>>>>> _______________________________________________ >>>>>> caiman-discuss mailing list >>>>>> caiman-discuss at opensolaris.org >>>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>>>>> >>>> >> >>
