vic-machine: reconfigure appliance

[hickeng]

We require an ability to reconfigure the appliance in place - this is absolutely crucial to allow for credential update (#1879), and allows for very likely operational updates, such as adding volume stores, container networks, permitted registries, et al.

This overlaps directly with the upgrade path as upgrade is essentially a reconfigure with updated ISOs.

Addressing this issue is entirely in vic-machine and should:

• [ ] split current vic-machine create into create and configure (most of the create options are relevant to configure)
• [ ] add an installer mechanism to load the VCH config into a Data structure
• [ ] configure and upgrade should combine provided CLI options with the loaded Data (do not support removal of elements such as image stores, volume stores or container networks - that is significant extra complexity)
• [ ] configuration is validated using the full path used by create currently, not the shortcut that upgrade added (this shortcut should be removed).
• [ ] the configuration should be committed to the VCH in much the same manner on all paths (appliance powered off, snapshot taken, config applied, ....)

Creating this as an epic in the expectation that the main tasks be broken out where they can be done in standalone fashion.

Note Emma has identified some useful constraints that simplify the operation:

• do not allow change to bridge network unless it's to expand existing scope
• do not allow changing image store (unless PL supports multiple)
• do not allow removal of existing resources
  • this could be weakened eventually to 'existing resources that are in use by containers'

[mobla]

It will definitely be useful if we have an option to reconfigure VCH options esp. to configure with private registries (harbor) and also need a capability to show that it is configured to store images to a private registry in "docker -H info" command. Currently it shows "Registry: registry-1.docker.io"

[emlin]

Two things still need to be considered in this story:

• We didn't define the scope of update from user perspective. Not everything configured in vic-machine create can be updated. For example, the bridge network ip range. If one range is already there, and some containers created in that scope, we cannot simply remove the previous ip range and update to a separated new range. But we probably could add new range scope if we support multiple discontinuous ip ranges. And same for the image store, if there is already images persisted in existing image datastore, we might insert another image store, as long as we could support multiple image stores from portlayer. Right now, we still do not have this kind of function support from portlayer, and we might not need them immediately, so from story point of view, we still need a update scope.

• For load VCH configure back to create data, I still have some concern:

  • Create data is designed for easy user experience. For example, all vSphere element is using name, instead of mob-id. But VCH configure is using vSphere mob-id to make sure any rename post vic-machine create, does not impact VCH functionality. This well means if translate VCH configuration back to create data, will need vSphere object query. Given an example, if there is one nonfunctional VCH for some configuration is missing from vSphere, and user tends to update that item, but we'll fail for that malfunction configuration reload. Another case is that some encrypted items are not able to be reverted.

  • Even we reload the configuration back to user data without any error mentioned above, we could not simply compare the input value with the converted value to differentiate them. The simple example is the resource path, user is using short format, but we are using govmomi inventory path as default.

    So my personal understanding for this function to reload VCH configuration will definitely benefit vic-machine inspect, but might not for others, especially for reconfigure. But anyway this is one design approach, I'll need detail design to address these issues.

[mdubya66]

@emlin Regarding this comment https://github.com/vmware/vic/pull/4497#issuecomment-292029145

Let's get the manifest story written and included, and make sure that the PRD line items are captured then I think we can pull those out of this Epic and into a vic-machine reconfigure epic for 1.2.

[mhagen-vmware]

@emlin @chengwang86 Are we going to get estimates on the remaining 3 stories in the epic?

[emlin]

@mhagen-vmware As they are not part of 1.2 scope, didn't plan to estimate at this time, but if you think that's important at this time, we can do it

[mhagen-vmware]

yes please, they all look sufficient. You don't need to detail them out any more, but a rough estimation based on the effort for all the other work should be quite easy at this point. Of the 30 or so other stories you have already done, some of them should be generally similar.

[mhagen-vmware]

lgtm