Proposal for adding to the blueprint customizations

[bcl]

The goal here is to do the minimum needed to get the images setup for
use so they can have more complex customizations applied later.
I think this list is a pretty good minimal set of features without going
full kickstart.

[wgwoods]

I like what's going on here - definitely feels like the right set of customizations - but I have a couple thoughts about config syntax/schema to make sure we retain flexibility, but still without going Full Kickstart

First: I feel like it's generally a good idea if values under [customizations.*] are container types - right now some are strings (language, timezone) and I worry about what happens if we need to extend the string-value ones, since we can't just add new keys like with tables..

Looking at Ansible's timezone role, though, the only thing it really uses is name, and timezone = "name" is just as good. So I think that's fine.

But language is trickier, because there's definitely other related things you might want to twiddle (other locale variables, keymaps, etc.) So maybe we want a block for locale, even if the only setting we handle (for now) is "lang":

[customizations.locale]
lang="en_US.utf8"

As for service, the only thing from the service role that makes sense in Composer is enabled, and enabled = ["service", ...] is equivalent, so I'm good with that.. but can we use "enabled" instead of "enable"? We're describing the intended final state of the system, and I want to avoid anything that sounds imperative or script-y.

Lastly, firewall - I'm pumped that you've basically got a nice, limited subset of linux-system-roles/firewall, except we've lost the explicit state/enable bit, which means you can't disable things. Might need to accept multiple blocks:

[[customizations.firewall]]
port = "4222/tcp"
state = "enabled"

[[customizations.firewall]]
port = "22/tcp"
state = "disabled"

Or, following the enabled = ["item", ...] pattern from service:

[customizations.firewall.ports]
enabled = ["4022/tcp"]
disabled = ["22/tcp"]

But I'm worried about firewall.services - the list of valid service names can vary depending on which packages you install. Is there a documented/supported way to list valid services without running firewall-cmd inside the system being built?

[bcl]

First: I feel like it's generally a good idea if values under [customizations.*] are container types - right now some are strings (language, timezone) and I worry about what happens if we need to extend the string-value ones, since we can't just add new keys like with tables..

That helps keep things limited :) ButI see your point.

But language is trickier, because there's definitely other related things you might want to twiddle (other locale variables, keymaps, etc.) So maybe we want a block for locale, even if the only setting we handle (for now) is "lang":

[customizations.locale]
lang="en_US.utf8"

Yeah, that makes sense if we want to allow setting multiple locales, etc. My plan for that was to give them just enough to get the system setup so they can use it in their native language and apply customizations later.

As for service, the only thing from the service role that makes sense in Composer is enabled, and enabled = ["service", ...] is equivalent, so I'm good with that.. but can we use "enabled" instead of "enable"? We're describing the intended final state of the system, and I want to avoid anything that sounds imperative or script-y.

Yeah, that's fine.

Lastly, firewall - I'm pumped that you've basically got a nice, limited subset of linux-system-roles/firewall, except we've lost the explicit state/enable bit, which means you can't disable things. Might need to accept multiple blocks:

[[customizations.firewall]]
port = "4222/tcp"
state = "enabled"

[[customizations.firewall]]
port = "22/tcp"
state = "disabled"

The thought process there is that everything is disabled by default, other than things like ssh that enable themselves. I suppose there may be cases where you want to disable things opened by a service (eg. 3rd party package that doesn't meet your security requirements)

Or, following the enabled = ["item", ...] pattern from service:

[customizations.firewall.ports]
enabled = ["4022/tcp"]
disabled = ["22/tcp"]

I like this form better, keeps it consistent with service.

But I'm worried about firewall.services - the list of valid service names can vary depending on which packages you install. Is there a documented/supported way to list valid services without running firewall-cmd inside the system being built?

Not that I know of. The list doesn't match /etc/services, and I tried reading the firewalld code to see where it gets the list but it was 4 layers of abstraction before I gave up. I'd lean towards just having ports available, but I think some of the services support dynamic port assignment so it's probably a good idea to keep that in there and direct them to the distribution's firewalld documentation.

[coveralls]

Pull Request Test Coverage Report for Build 1520

• 104 of 105 (99.05%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+3.007%) to 60.43%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/pylorax/api/compose.py	102	103	99.03%

Totals
Change from base Build 1485:	3.007%
Covered Lines:	3259
Relevant Lines:	5269

---

💛 - Coveralls

[bcl]

I need someone who understands Anaconda's use of keyboard to check the locale commit, I wrote it thinking I could use the same values for --vckeymap and --xlayouts but I'm not sure. And I was surprised to discover I cannot use us-dvorak even though it is listed by localectl list-keymaps

[atodorov]

@bcl what is the status here? is this ready for merge?

OTOH should we go ahead and merge #690 with failing Travis CI if this isn't ready ?

[bcl]

I think it's ready, but it needs to be reviewed in detail. Lots of new code added.

[bcl]

Updated with locale keyboard feedback from mkolman.