Migrating to a new Ick: tooling
by Lars Wirzenius
Consider this scenario: you are using an Ick instance and have some
projects and pipelines configured, and have run a number of builds,
and have some artifacts. You'd like to move all of that to a new
instance. You might want to move because of cost, or better
reliability, or because you want to start using a new version of Ick.
The last one is relevant to me, as I'm contemplating changing how Ick
stores data and to use Muck for that in the future. This will be
necessity requires setting up a new instance and moving all data to
that. (I'm not willing to consider migrating an existing Ick instance
in place to use Muck. There's too much risk of that going wrong.)
The basic approach I'm thinking is to have icktool be able to dump all
data from an Ick instance to a file, and then "undump" from that file
to another Ick instance. This will also give users a way to backup and
restore their Ick data.
The commands would be something like:
icktool dump > dump.yaml
icktool undump < dump.yaml
The data in an Ick instance is:
* projects
* pipelines
* information about builds and their logs
* artifacts
Projects and pipelines are reasonably easy, and can already be done
with the current controller API. The only niggle will be setting
ownerships of resources, and that's something that isn't even relevant
yet, and will have to wait until Muck is used, because there isn't any
ownership yet.
Builds and build logs are tricky: currently the controller API does
not allow creating such resources. I'm not sure if it's worth allowing
migration of that.
Artifacts can be handled with the current API, but are not nearly as
important as projects and pipelines.
To keep things simple, I'm thinking that we should start with just
projects and pipelines, and see how it goes. We can add the rest
later, if and when needed.
My immediate need is to have something to allow me to replace the
current Ick demo instance, and my personal instance, with a new
version that uses Muck to data managed by the controller. For this,
projects and pipelines should be enough.
Thus, for the next iteration, I am suggesting we implement "icktool
dump" to produce a YAML file in a format that "icktool make-it-so" can
read. Thus "make-it-so" is the implementation of the "undump" sketched
above.
Opinions?
--
I want to build worthwhile things that might last. --joeyh
4 years, 3 months