|Issue Type:||New Feature|
|Priority:||4 - Normal|
|Created by:||Former user|
|Reported by:||Former user|
|Assigned to:||Pedro Palazón Candel|
Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2020-02-25T17:39:47.348Z)
2020-02-27 Muffin Tops (Release Date: 2020-02-27)
/usbkey/scripts/install-platform.sh assumes that the platform that you are installing will be booted on the head node. As Linux CNs are introduced, this is a broken assumption. Even without Linux CNs in the mix, it is quite reasonable to assume that many PIs may be installed for the purpose of debugging issues, testing upcoming versions, etc. Those PIs likely have no business being on the HN's USB key.
Also, the current logic in
install-platform is quite inefficient, given that USB drives are typically much less performant than the HN's zpool. The current code flow is:
/usbkey/os/tmp, which is in the zfs pool
A better approach would be:
/usbkey/os(this could be a pipeline with the download)
switch-platformto be able to rsync the image from
/usbkey/osto the USB key. This should only be allowed for SmartOS images.
Meta: The component on this ticket should really be "headnode", as the change needs to occur in sdc-headnode. The component was set to sdcadm, as
sdcadm is what invokes
@accountid:6248927d45ece00069cb9db5 assigning this one to myself before I go ahead with OS aware
sdcadm platform if that's Ok with you.
Sounds good, @accountid:557058:8e9a30b7-b0e0-4093-927b-6497faf34a80
This should affect
sdcadm platform subcommand too.
sdcadm platform installchecks for available disk space into the USB key before installing a new PI. With this approach, that's not necessary any more.
sdcadm platform remove --cleanup-cachetries to remove the given PI from the USB key and, only if the
--cleanup-cacheoption is given, it will also attempt to remove from
latestsymlink creation also list contents of the USB key, (but the symlink is created into the
usbcpy). That's not necessary any more.
latestsymlink in August, 2015 (CNAPI-518). Maybe it would be a good idea to just take advantage of this and remove all that code now?.
If there is a possibility or intent to deprecate operators using `/usbkey/scripts/install-platform.sh` it might be nice to do that and have `sdcadm platform install` do the work itself directly. Benefits of that:
1. You don't have to worry about `sdcadm platform install` ensuring that `/usbkey/scripts/...` have been updated with the new `install-platform.sh` before using it for a LinuxCN platform.
2. Having one clear operator tool (`sdcadm platform ...`) rather than the additional `install-platform.sh` would probably be clearer to operators.
I think the "install-platform.sh" script would probably remain useful for devs of Triton.
I think the new approach basically sounds fine. I'm not sure I would change switch-platform.sh to know how to rsync from the usbkey copy. What about just having it error out if the requested platform isn't already on the USB key?
Perhaps the concept could be whether the platform being "installed to the DC" (i.e. put in the USB key copy where it is used by booter and assets) should also be "installed to the headnode USB key" for use in live booting the headnode. That could be:
sdcadm platform install [--usb | --no-usb] ...
By default smartos platforms would be installed to the USB key (as is done currently). By default linuxcn platforms would not be installed to the USB.
Then change 'sdcadm platform assign' to error out in the case that (a) the target server is the headnode and (b) the platform is not installed on the USB key.
I agree with pretty much all of the above, with the exception of installing SmartOS PIs in the USB key by default. My point is that not every time you install a new PI you want to reboot the HN with it and, given the USB key space is limited, the approach of default installing into the HN leads to the following procedure in order to install new platforms:
sdcadm platform removew/o the
--cleanup-cacheoption, so the PI remains available for other servers.
sdcadm platform install, which means the new PI goes to the USB key, even if you don't wanna use it from the HN.
IMO, it would be better if
sdcadm platform assign could check for presence/absence of the given PI in the USB key when the headnode is included into the list of servers it's being assigned to. Only in such case, I would copy the PI to the USB key.
install-platform.sh ... isn't
sdcadm platform <subcommands> the right way to manage PIs nowadays?.
We can definitely get rid of those scripts when building
gz_tools and moving all the functionality to
sdcadm. I think that, specially for
sdcadm platform assign would have way more sense to handle everything from sdcadm, specially the places where it tries to post updated boot platform to CNAPI.
I strongly agree with Pedro on this point:
My point is that not every time you install a new PI you want to reboot the HN with it and, given the USB key space is limited
There have been several times when I have asked for a customer to try out a fix that is in a new PI that is not a support PI. I very specifically do not want that to accidentally be run on the HN. I'd say the frequency of needing a test PI for problem resolution is greater than the frequency of a customer qualifying a new PI for general use.
In addition to space being limited, copying to the USB drive is terribly slow.
In the future USB-less boot world, the HN may not even have a USB stick. As that feature set develops, I would hope that our bias would swing toward never copying the PIs to a USB stick and instead just loading them from
<syspool>/boot or perhaps
<syspool>/usbkey if we are stuck on legacy names. Details to emerge in RFD 176.
sdc-headnode commit 9f1bc614669af240e334d794ee491a75c3f2a867 (branch master, by Pedro Palazón Candel)
TRITON-1947 install-platform needs ability to skip copy to usb key (#29)