It sounds like you want one single script to run without modification on several hosts, and you want the list of available services to vary from one host to the next. So it seems like you should have a hash structure that is keyed by host name, and the hash value associated with each host name should be the list of services available on that host.

Of course, there might be other reasons for keeping a separate hash structure that is keyed by the various services that you are controlling across all hosts, and the values for each key (service name) in that structure would be the list of hostnames where that service can be run.

One of these two distinct hash structures can be considered as "primary", and can be used to derive/populate the other one. (Both structures are likely to be useful, and it probably doesn't matter which one is "primary".)

I don't know what benefit there is in having a "serviceid" value in addition to a "servicename" -- I wouldn't expect two distinct services to have the same name; likewise, the host names should all be different as well. So the two hash structures can simply use the service names and host names as hash keys, and the values can be arrays (or hashes) for the lists of hosts (running a given service) or services (runnable on a given host).

One minor point: I would also expect that some services might need to be started with different parameters or other minor differences in the command line, depending on which host is being used, so a hash of hashes, with the command line options/parameters as the sub-hash values, might be the way to go:

# let's suppose the list of services is the primary HoH structure: # -- top-level hash is keyed by service name # -- next-level hash is keyed by host name # -- $service{service_name}{host_name} = "command line"; my %service = ( servicea => { host1 => "/usr/local/bin/servicea -foo", host2 => "/usr/bin/servicea -bar", ... }, serviceb => { host2 => "/usr/bin/serviceb -baz", host3 => "/usr/local/bin/serviceb -boo" ... }, ... ); # now populate %host HoH to store the same information, but # with host names as top-level keys and service names as sub-keys: my %host; for my $srvc ( keys %service ) { for my $hst ( keys %{$service{$srvc}} ) { $host{$hst}{$srvc} = $service{$srvc}{$hst}; } } # to set up an option menu of services for a particular host, # use the %host hash: my $hostname = `hostname`; chomp $hostname; my @available_services = sort keys %{$host{$hostname}}; ... # to show which hosts are available to run a given service, # use the %service hash: my $servicename = ...; # assuming there's some service of interest my @available_hosts = sort keys %{$service{$servicename}};
Just an idea...

In reply to Re: Question about data structures by graff
in thread Question about data structures by wishartz

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.