https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/INSTRM-43 Instrument control development <p>To be prepared of hardware delivery to Subaru assumed to be started from early 2017, we need to change current master to jhu (or something) and to have master as configuration on site.</p> INSTRM-43

[dnsmasq] Change branch from master to sites (LAM, JHU)

Task Major Won't Fix Won't Fix shimono shimono Fri, 16 Dec 2016 19:56:26 +0000 Wed, 28 Jun 2017 16:44:55 +0000 Wed, 28 Jun 2017 16:44:55 +0000 ics_dnsmasq 0 4 <p>-I shall file another ticket for above comment (and validation)...<br/> I'll file new epic for entire ics_dnsmasq organizing works.- (Added as <a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-71" title="organization of dnsmasq configuration files - both DHCP and DNS" class="issue-link" data-issue-key="INSTRM-71"><del>INSTRM-71</del></a>)</p> <p>I have pulled JHU-only files into a JHU branch.</p> <p>From slack conversation, what Craig is doing is not the one as ticket description targets.<br/> This ticket targets, moving existing all configuration into branch, and place 'production at Subaru' as master.</p> <p><a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=arnaud.lefur" class="user-hover" rel="arnaud.lefur">arnaud.lefur</a> <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=fmadec" class="user-hover" rel="fmadec">fmadec</a><br/> I've branched LAM from master now. Change your site to your branch when you are ready to work on facility reconfiguration.<br/> As in last ICS/SpS telecon, any content in master will be squashed following works on <a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-71" title="organization of dnsmasq configuration files - both DHCP and DNS" class="issue-link" data-issue-key="INSTRM-71"><del>INSTRM-71</del></a> at any time.</p> <p>In general, I don't think branches will need to have much content. </p> <p>One observation is that any given piece of networked hardware can only be at one site, so master can be (and I think should be) the sole branch for all flight hardware (hardware to be part of the final instrument at Subaru). Any hardware which is used with the expectation that it will eventually be delivered to Subaru should be on master.</p> <p>Except for machine.conf, any of the site branches should always be able to merge from master w/o conflicts. If we agree to keep our strange site and commissioning hosts in site-named files on site-named branches there should not be much trouble.</p> <p>I agree with Craig here. You can handle branches pretty easily with git (`git rebase master`), but there will be conflicts every time any one changes the config file on master, and I think that there is only marginal gain.</p> <p>How many site files are really involved? Why not put them in a <tt>sites</tt> subdirectory, and use a symbolic link as part of closing the package?</p> <p>I don't understand why you are commenting here but not <a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-71" title="organization of dnsmasq configuration files - both DHCP and DNS" class="issue-link" data-issue-key="INSTRM-71"><del>INSTRM-71</del></a>, and am not sure you read there.<br/> Also we (might be with <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a> and <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=arnaud.lefur" class="user-hover" rel="arnaud.lefur">arnaud.lefur</a> but not <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=rhl" class="user-hover" rel="rhl">rhl</a>?) have discussed several times, simple rebase based flow will not work for entire files but could work only on pair of mac and hostname. </p> <p>I think I like this site-named branches, that is may be a bit brutal and not very fancy but that's pragmatical, it's the configuration which has been used at a given time.<br/> We just have to keep in mind that if the config file has to be updated, which I suspect will not happen too often, it has to be done also in site's branches. <br/> That's the only inconvenient I see but in most cases it's simple and it went very smoothly when we have received the new r2 cryostat.</p> <p>In a ideal world, you just merge LAM branche with master, plug the SM1 in and "Voila" !</p> <p>We (Atsushi, Arnaud, and I) discussed this yesterday, and I believe that we agreed NOT to use branches. Instead, each site can have a site-specific directory, to which each of us makes a link. That directory should contain all and only the local and non-deliverable hosts, as well as any site-specific configuration (external DNS server, internal interface name, etc).</p> <p>This will probably require some tweaking of the slightly peculiar dnsmasqd options which tell the program which configuration files and directories to load.</p> <p>now we tend not to use branches for site management, so just closing this as WONTFIX and will have another ticket for work when we agreed on <a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-71" title="organization of dnsmasq configuration files - both DHCP and DNS" class="issue-link" data-issue-key="INSTRM-71"><del>INSTRM-71</del></a> for configurations.</p> Relates INSTRM-71 Development Epic Link INSTRM-70 Rank 0|ii01bb: