Container only update

[toganlabs]

I would like oryxcmd (bash) to be able to update just the containers via mender. We looked at this before, let's get this into the new oryxcmd.

Mender update and non-mender

[johntoomey]

@toganlabs @kprosise - there is a discussion to be had here about our container update strategy and the differences between mender and non-mender systems.

• on non-mender systems we will probably need to consider updates using oryxcmd, which currently has no concept of versioning and no security at all. ideally the system should act more like a package manager by pulling metadata from the sources and performing the update (and rollback?) of containers. need to consider how other systems such as docker and rkt do this as this is a paradigm that users may be used to.
• on mender systems we can look at leaving the container on one of the a/b root filesystems and updating them when the system gets updated (kind of defeats the purpose of containers) or storing them on the data partition using the mender update modules which has the advantage of managing all of the security stuff for us..
• finally, if we have both of the above implementations, how are we going to make sure that they don't conflict?

this needs to be decided pretty soon as @kprosise is currently working on oryxcmd and this is the kind of stuff that should be thought of now rather than trying to bolt it on later and hope it works..

[johntoomey]

In order to significantly narrow the scope of this in the limited time we have left I propose that we implement an upgrade path for the POC using the (limited) available oryxcmd functionality:

• oryxcmd stop my_guest_v1.0
• oryxcmd add my_guest_v2.0
• oryxcmd start my_guest_v2.0
• oryxcmd remove my_guest_v1.0

This assumes that the guest has no data/config that needs to be retained. After a brief discussion with Andy H it appears that we usually have either a 128GB SSD or a 32GB eUSB (yup, apparently thats a real thing) for the main disk on the switches we are working with.

This upgrade path must be tested and working with the oryxcmd rewrite (#2)

@toganlabs, @kprosise speak up now if you have a problem with this approach!!!

[toganlabs]

on non-mender systems we will probably need to consider updates using oryxcmd, which currently has no concept of versioning and no security at all. ideally the system should act more like a package manager by pulling metadata from the sources and performing the update (and rollback?) of containers. need to consider how other systems such as docker and rkt do this as this is a paradigm that users may be used to.

On non-mender systems, updates using should do just this. Act as a package manager. This is lowest priority IMHO however.

on mender systems we can look at leaving the container on one of the a/b root filesystems and updating them when the system gets updated (kind of defeats the purpose of containers) or storing them on the data partition using the mender update modules which has the advantage of managing all of the security stuff for us..

I like the data partition solution.

finally, if we have both of the above implementations, how are we going to make sure that they don't conflict? this needs to be decided pretty soon as @kprosise is currently working on oryxcmd and this is the kind of stuff that should be thought of now rather than trying to bolt it on later and hope it works..

ONIE systems are non-mender. No real upgrading (at least not over the wire, they can use ONIE for that) or first boot provisioning. Non-ONIE are mender. The two streams should never be crossed.

In order to significantly narrow the scope of this in the limited time we have left I propose that we implement an upgrade path for the POC using the (limited) available oryxcmd functionality:

oryxcmd stop my_guest_v1.0 oryxcmd add my_guest_v2.0 oryxcmd start my_guest_v2.0 oryxcmd remove my_guest_v1.0

Agreed.