Commits on May 7, 2024

1. RFC: tweak the way customization are done …

   This is a complex RFC, sorry, I can try to break it into smaller
   discussion points but it's tricky. Let me try to break it down:
   
   1. Simplify the way customization inputs are read. it seems we
   are already doing yaml everywhere so let's just read an input
   file (just like a blueprint today with composer). Passing the
   values via `-Ckey=value` seems cumbersome and we (or our users)
   will run into quoting issues. Or is there a benefit of doing it
   that I'm missing? Note that we could simply support `-C -` to
   read the data from stdin if scriptability is the goal.
   
   2. Describe why `otk.define` and `otk.customization` are distinct.
   I don't have a good answer here but I think it's quite important
   that we have clarify why we need a different mechanism. On the
   surface it looks like another way to define a variable (which we
   can do today) and some `if/default` which we could add to
   `otk.define`d variables (fwiw, I'm not fully clear why we need
   two but my gut-feeling is that it's the right approach so having
   it slightly more formal/well defined "why" would be nice).
   
   3. Tweak how the customizations recieve their data. The existing
   strawman was `this.` which is a reasonable choice, this commit
   uses `$customizationname` now directly, I'm not sure what is the
   best but it looks nice in the examples so maybe it's a reasonable
   starting point.
   
   4. Tweak the example - this is a tricky one. So far in our actual
   examples we have very simple cases (hostname, timezone) etc which
   are just strings (and which we could support without a `otk.customization`
   by just defining a default `otk.define.hostname` and then letting
   the user `override` it via a `otk.include "user-customizations"`.
   When trying to build a complex example with the `user` customization
   or the `container` customization I ran into the issue that both
   have multiple entries so writing them directly in the yaml is
   tricky. It seems `users` would become a `otk.external.users` so
   that we can use python to generate the required stages. But I
   think it would be good to find examples of complex customizations
   so that we nail the concept a bit more down.

   

   mvo5 committed May 7, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 5341946
   • Browse repository at this point

   Copy the full SHA

   5341946 View commit details

   Browse the repository at this point in the history