TRITON-1947: install-platform needs ability to skip copy to usb key


Issue Type:New Feature
Priority:4 - Normal
Created at:2019-10-18T15:00:39.937Z
Updated at:2020-03-02T01:27:10.417Z


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)

Fix Versions

2020-02-27 Muffin Tops (Release Date: 2020-02-27)

Related Issues

Related Links




Currently /usbkey/scripts/ 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:

A better approach would be:

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 install-platform.


Comment by Pedro Palazón Candel
Created at 2020-02-03T16:16:32.207Z

@accountid:6248927d45ece00069cb9db5 assigning this one to myself before I go ahead with OS aware sdcadm platform if that's Ok with you.

Comment by Former user
Created at 2020-02-03T18:52:28.845Z

Sounds good, @accountid:557058:8e9a30b7-b0e0-4093-927b-6497faf34a80

Comment by Pedro Palazón Candel
Created at 2020-02-20T17:11:16.886Z

This should affect sdcadm platform subcommand too.

Comment by Former user
Created at 2020-02-20T21:26:43.996Z

If there is a possibility or intent to deprecate operators using `/usbkey/scripts/` 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 `` before using it for a LinuxCN platform.
2. Having one clear operator tool (`sdcadm platform ...`) rather than the additional `` would probably be clearer to operators.

I think the "" script would probably remain useful for devs of Triton.


I think the new approach basically sounds fine. I'm not sure I would change 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.

Comment by Pedro Palazón Candel
Created at 2020-02-21T10:46:15.957Z

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:

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.
Regarding deprecating ... 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.

Comment by Former user
Created at 2020-02-21T14:14:02.800Z

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.

Comment by Jira Bot
Created at 2020-02-25T17:22:53.033Z

sdc-headnode commit 9f1bc614669af240e334d794ee491a75c3f2a867 (branch master, by Pedro Palazón Candel)

TRITON-1947 install-platform needs ability to skip copy to usb key (#29)

Comment by Pedro Palazón Candel
Created at 2020-02-25T17:39:47.355Z

Ok, for now resolved for the scope of sdc-headnode scripts. I'm gonna implement some of the changes discussed here regarding sdcadm as part of TRITON-1946