20:00:21 <sgallagh> #startmeeting Server Working Group Weekly Meeting (2016-10-18)
20:00:21 <zodbot> Meeting started Tue Oct 18 20:00:21 2016 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:21 <zodbot> The meeting name has been set to 'server_working_group_weekly_meeting_(2016-10-18)'
20:00:21 <sgallagh> #chair nirik sgallagh mhayden dperpeet smooge jds2001 vvaldez adamw mjwolf
20:00:21 <zodbot> Current chairs: adamw dperpeet jds2001 mhayden mjwolf nirik sgallagh smooge vvaldez
20:00:21 <sgallagh> #topic roll call
20:00:21 <sgallagh> .hello sgallagh
20:00:22 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
20:00:29 <mhayden> .hello mhayden
20:00:30 <zodbot> mhayden: mhayden 'Major Hayden' <major@mhtx.net>
20:00:30 <dperpeet> .hello dperpeet
20:00:32 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com>
20:00:33 <jds2001_> .hello jstanley
20:00:33 <vvaldez> .hello vvaldez
20:00:35 <zodbot> jds2001_: jstanley 'Jon Stanley' <jonstanley@gmail.com>
20:00:38 <zodbot> vvaldez: vvaldez 'Vinny Valdez' <vvaldez@redhat.com>
20:00:53 <sgallagh> That may be the fastest we've ever hit quorum o_O
20:01:07 <mhayden> sgallagh: jds2001 said there would be punch and snacks
20:01:17 * nirik is dealing with an outage, but sort of here
20:01:32 <sgallagh> mhayden: You misheard.. he said "a punch in the sack"...
20:01:39 <jds2001> lol
20:01:51 <mhayden> hahaha
20:02:07 <sgallagh> (Today on "things I probably shouldn't say into the recording...")
20:02:07 * jds2001 catches next flight to san antonio :D
20:03:52 <sgallagh> Has anyone heard from mjwolf lately?
20:04:09 <dustymabe> .hello dustymabe
20:04:10 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dustymabe@redhat.com>
20:04:11 <vvaldez_> .hello vvaldez
20:04:12 <zodbot> vvaldez_: vvaldez 'Vinny Valdez' <vvaldez@redhat.com>
20:04:19 * vvaldez_ has connection issues
20:05:00 <vvaldez_> sgallagh: I have not
20:05:00 * langdon lurks
20:05:10 <adamw> .hello adamwill
20:05:11 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
20:05:22 <sgallagh> Let's get started
20:05:24 <sgallagh> #topic Agenda
20:05:40 <sgallagh> #info Agenda Item: Logic Model: Threat or Menace?
20:06:04 <sgallagh> #info Agenda Item: AnsibleFest Report-Out
20:06:40 <sgallagh> Anyone have other topics for today?
20:07:23 * mhayden hears that this ansible thing is catching on ;)
20:07:36 <smooge> here. apologies was sitting in #fedora-meeting1
20:07:51 <dustymabe> smooge: :)
20:08:09 <sgallagh> smooge: Welcome
20:08:18 <sgallagh> #topic Logic Model: Threat or Menace?
20:08:22 <sgallagh> #link https://kolinahr.fedorainfracloud.org/edit/57ff81347b76717eefcbc44b
20:08:41 <sgallagh> So, we spent several weeks generating that. Is it ready?
20:09:16 <sgallagh> Otherwise, it's probably time to try translating into an actual requirements document
20:09:23 <smooge> its pretty
20:09:35 <mhayden> wow, colors
20:09:42 * jds2001 has just one concern - what if some of the stuff on there turns out to be technically impossible?
20:09:51 <jds2001> (thiknking more of the ostree stuff)
20:10:19 <jds2001> but I think as an aspirational document it looks great!
20:10:21 <sgallagh> jds2001: Well, software development is always iterative.
20:10:32 <mhayden> i'm 100% good with the impact column
20:10:38 * jds2001 too
20:10:43 <sgallagh> If something is truly unachievable, I suppose we'll revisit
20:11:08 <mhayden> actually, i think the outcomes/impact are quite reasonable
20:11:09 * jds2001 is good with the whole thing, actually.
20:11:11 <nirik> looks pretty good to me.
20:11:40 <jds2001> some of the outputs conflict with each other, but I suspect that's OK?
20:11:51 <sgallagh> jds2001: Conflict how?
20:12:42 <jds2001> the highly restrictive default firewall, combined with an NFS role, could be interpreted to mean that you couldn't use your shiny new NFS server out of the box.
20:12:56 <jds2001> i dont think that's the intent, but someone could read it that way.
20:13:11 <vvaldez> is cobbler the preferred deployment system over foreman? I do prefer cobbler myself, just wasn’t sure in terms of the community
20:13:39 <sgallagh> vvaldez: I wasn't actually aware that the Foreman had PXE installation capability.
20:13:45 <sgallagh> I'll add that as a potential Input
20:13:52 <jds2001> (NFS just being an example, insert $other_role to substitute)
20:13:57 <dustymabe> for the record - i don't think we would do the firewall part on the "cloud image" in the future
20:14:31 <vvaldez> sgallagh: makes sense, it does similar tftp/dhcp/dns service management as cobbler
20:14:42 <sgallagh> Added (refresh to see it)
20:14:48 <sgallagh> vvaldez: Thanks for the feedback.
20:15:15 <sgallagh> I know the Foreman has some RHT resources working on it, so we might be able to share those
20:15:28 <jds2001> Foreman == Satellite :)
20:15:39 <jds2001> or rather the basis of it.
20:15:58 <jds2001> Katello puts a lot on top of Foreman, but that's the base.
20:16:17 <vvaldez> jds2001: well, sat 6, but sat 5 is cobbler based
20:16:48 <jds2001> sat 5 is hot mess based :D
20:16:56 <jds2001> but we'll leave that there :)
20:17:21 <sgallagh> OK, so lazy consensus time: does anyone have any reason we should not be wed to this plan? :)
20:18:01 <dperpeet> I think it's time to start moving forward
20:18:06 <vvaldez> sgallagh: I like what is there, do we have chances to interate in the future?
20:18:14 <vvaldez> as needed?
20:18:39 <sgallagh> vvaldez: The answer is certainly yes, but do we want to formalize it in some way?
20:19:37 <sgallagh> Do we want to have a check-in once a Fedora cycle? Once a year at Flock? Something else?
20:19:45 <sgallagh> Ad hoc as the situation dictates?
20:20:01 <jds2001> well, a combination
20:20:03 <dperpeet> ad hoc + minimum fedora cycle?
20:20:09 <jds2001> we should have a formal checkin at flock
20:20:12 <jds2001> and ad hoc :)
20:20:25 <jds2001> dperpeet: is once a cycle too often?
20:20:47 <vvaldez> sgallagh: that makes sense
20:21:01 <jds2001> i think a lot of this stuff is longer than a single cycle can accommodate
20:21:16 <vvaldez> i meant what dperpeet said
20:21:31 <dperpeet> I don't think it's too often
20:21:33 <smooge> i have no reason for this plan not to be used
20:21:41 <dperpeet> at the very minimum you can say "we are working on it"
20:21:42 <sgallagh> Yeah, I think a basic "is this still correct?" around Flock makes sense and then ad hoc any time someone wants to bring up a concern.
20:22:11 <dperpeet> time flies, so it's good to have regular check-ups
20:22:16 <dperpeet> I wouldn't want to formalize them overmuch
20:22:17 <nirik> I think we should change inputs and stuff on that side as needed...
20:22:29 <nirik> but stuff on the far side much less so
20:22:49 <nirik> (if that makes sense)
20:23:13 <sgallagh> /me nods
20:23:37 <vvaldez> it would be nice to somehow tie/track any open/completed issues with activities/outputs? or am I jumping ahead?
20:23:44 <sgallagh> I think every Fedora release would be just a bit too often. We'd be likely to just handwave and ignore it
20:24:14 <sgallagh> vvaldez: Once we have a breakdown into a real PRD, I think we want to look at tracking progress on individual activities somewhere.
20:24:23 <vvaldez> ack
20:25:12 <sgallagh> The way I'd like to do that is to have someone assume ownership of each Output and run it like a project of their own.
20:25:47 <dperpeet> looking at Agile, I think once a release isn't too much
20:25:47 <sgallagh> In Scrum terminology, I think the Activities are basically "Epics"
20:26:06 <dperpeet> it doesn't have to take long, but can be a good refresher
20:26:07 <sgallagh> dperpeet: Well, the other side of that is that as Modularity grows, the release boundary gets fuzzy :)
20:26:33 <dperpeet> well, what about flock and flock+6months?
20:26:33 <sgallagh> We may actually get to a point where the base runtime on which we build is revving quite fast (while remaining API/ABI stable)
20:26:37 * vvaldez raises hands for any ansible role outputs. deployment looks fun
20:26:58 * jds2001 raises his hand for the same
20:27:01 <dperpeet> it shouldn't be a big deal: is there anything that's not valid anymore, do we need something no
20:27:01 <sgallagh> vvaldez: Sold! You are now the proud owner of the deployment role :)
20:27:05 <dperpeet> *something new
20:27:09 <vvaldez> awesome
20:27:11 <sgallagh> jds2001: Did you have one in mind?
20:27:17 <mhayden> vvaldez: you win! :)
20:27:25 <jds2001> NFS :)
20:27:40 <sgallagh> dperpeet: I'm kind of leaning towards "the people on this WG are pretty communicative; if something comes up that requires a change, they'll probably say so"
20:27:50 <vvaldez> I’m not afraid of windows, so happy to contribute there soo
20:28:02 <sgallagh> #action vvaldez to "own" the creation of the Deployment Role for Fedora Server
20:28:12 <dperpeet> sgallagh, I'd settle on every flock
20:28:22 <sgallagh> #action jds2001 to own the creation of an NFS role for Fedora Server
20:28:40 <sgallagh> vvaldez: Windows?
20:28:49 <sgallagh> Or did you mean the Samba role?
20:29:18 <vvaldez> yes exactly and depending on what “domain controller” means
20:29:35 <sgallagh> As it is directly in my day-job responsibilities, I'll take over the "minimal install set content" and "firewall" outputs
20:29:45 <dperpeet> I am up for helping others develop Cockpit plugins
20:29:46 <sgallagh> vvaldez: FreeIPA, really
20:29:51 <vvaldez> though domain controller might be ipa. got it
20:30:19 <jds2001> vvaldez: though making sure windows clients can join a freeipa domain is valuable
20:30:40 <vvaldez> jds2001: very true. I’ll help as possible when we get there
20:30:45 <sgallagh> vvaldez: You make me think of another point, though. Our current charter includes being a good citizen in a heterogeneous network (meaning Windows and Linux)
20:31:00 <sgallagh> We don't capture that here, but is that something we want to focus on or leave that to our downstream?
20:31:25 <sgallagh> jds2001: Uhh... windows clients into FreeIPA? That's not supported today, nor planned as far as I know.
20:32:07 <sgallagh> Windows clients into a Samba DC might be of interest, but I'd put that firmly under "long-term goals", myself
20:32:50 <sgallagh> #action sgallagh to take ownership of "Minimal viable install set content" and "Highly-restrictive default firewall" outputs
20:33:07 <vvaldez> sgallagh: sure, do we want to test that as part of role validation somehow? e.g. windows/linux connecting to smb, apple clients connecting to sfp, etc
20:33:09 <sgallagh> vvaldez: I'll co-own Domain Controller with you if you like (as I have considerable past experience there)
20:33:20 <vvaldez> sgallagh: sure
20:33:21 <jds2001> yeah, i didnt know that wasnt supported - i thought it was a goal???
20:33:25 <jds2001> i could be crazy
20:33:40 <sgallagh> vvaldez: Yes, writing and maintaining role tests would be a critical part of this process.
20:34:02 <sgallagh> No more dumping things on adamw and expecting him to mutate more hands to juggle it.
20:34:23 <dperpeet> like I said, I'll help with putting this all into Cockpit
20:34:25 <sgallagh> #action vvaldez and sgallagh to co-own creation of a Domain Controller role
20:34:26 <dperpeet> help, mind
20:34:35 <dperpeet> I can't own all of that
20:34:41 <sgallagh> #action dperpeet to oversee creation of Cockpit modules.
20:35:25 <sgallagh> #info Ownership here means overseeing and responsible for an Output. It explicitly does not mean "must do all the work".
20:35:35 <dperpeet> :)
20:35:42 <dperpeet> we all know how it works
20:35:51 <sgallagh> *sadface*
20:36:25 <sgallagh> jds2001: FreeIPA does not support Windows clients. If you thought it did, then yes. Yes you are crazy and this has all been a hallucination
20:37:23 <sgallagh> jds2001: There's been a fuzzy, perpetually 5-10 years away idea of having FreeIPA embed Samba DC, but...
20:37:33 <sgallagh> Anyway, this is getting off-topic.
20:37:52 <sgallagh> Anyone here want to claim ownership of the various install media?
20:38:11 <sgallagh> This would entail working with rel-eng to make sure the proper artifacts are produced
20:38:43 <sgallagh> dustymabe: Want to help with the cloud image production?
20:38:58 <sgallagh> nirik: ^^ ?
20:39:14 <dustymabe> sgallagh: yes - i'll be able to work on it more next month
20:39:18 <nirik> I am not sure how much time I have, but I guess I can work on that some
20:39:58 <sgallagh> nirik: You could always claim ownership of the traditional artifacts, since most of that work is just maintenance :)
20:40:02 <sgallagh> dustymabe: Thanks
20:40:17 * nirik nods
20:40:20 <sgallagh> #action dustymabe to oversee the OpenStack and AMI images.
20:40:38 <sgallagh> nirik: Can I put you down there?
20:40:53 <nirik> sure.
20:40:55 <sgallagh> Thanks
20:41:00 <nirik> this is the netinstall and dvd?
20:41:17 <sgallagh> #action nirik will oversee production of the traditional netinstall and DVD media for Fedora Server
20:41:28 <nirik> fine
20:41:44 <sgallagh> Much obliged.
20:42:18 <sgallagh> I think I forgot to add the samba role to the minutes...
20:42:27 <vvaldez> I already have an OSTree playbook, needs work to convert to a role and other things: https://github.com/vvaldez/ostree-compose-server
20:42:33 <sgallagh> #action vvaldez to oversee the creation of the Samba file sharing role
20:42:55 <vvaldez> but, I also don’t want to overcommit and underdeliver
20:42:59 <vvaldez> sgallagh: sure
20:42:59 <sgallagh> ack
20:43:13 <sgallagh> vvaldez: Well, we're not committing to having all of this done necessarily in time for F26 either.
20:44:03 <sgallagh> Mostly I just want to make sure someone is going to step up and assume responsibility for pushing things forward (and explaining when they stall)
20:44:32 <sgallagh> OK, the remainder of the outputs I think we can hold off on trying to assign to people just yet.
20:44:45 <sgallagh> Let's see how far we get on these pieces for now.
20:45:32 <sgallagh> Unless anyone else wants to chime in here, I was hoping to leave a bit of time for jds2001 and I to field questions about the Ansible Galaxy discussions we had last week.
20:45:56 <dperpeet> sounds good
20:46:20 <sgallagh> #topic AnsibleFest Report-Out
20:46:45 <sgallagh> I posted it to the mailing list, but in case anyone hasn't seen it, I wrote up a brief overview at https://sgallagh.wordpress.com/2016/10/13/fedora-server-expanding-throughout-the-galaxy/
20:47:54 * nirik thinks signing should be very possible now given that puiterwijk has whipped our signing infra into shape...
20:48:07 <sgallagh> #info nirik thinks signing should be very possible now given that puiterwijk has whipped our signing infra into shape
20:48:10 <sgallagh> nirik++
20:48:20 <nirik> well, more puiterwijk++ but yeah. ;)
20:48:21 <jds2001> nirik: yeah, but getting those signatures somewhere is another thing....
20:48:29 <jds2001> and what do we sign? how?
20:48:41 <sgallagh> nirik: I gave puiterwijk a ++ earlier today, no need to enlarge his head too much ;-)
20:48:42 <jds2001> that's what needs to be answered yet I think.
20:49:00 * nirik hasn't looked at how galaxy does stuff...
20:49:08 <nirik> do you upload a tar/bundle? or ?
20:49:13 <jds2001> github
20:49:19 <jds2001> it doesnt  actually host anything
20:49:23 <sgallagh> jds2001: The short answer is that Galaxy is basically going to let us just detatch-sign the git commit
20:49:32 <jds2001> we were thinking about a signed tag
20:49:38 <jds2001> yeah, exactly.
20:49:56 * nirik nods
20:50:34 <sgallagh> We requested that signatures had to be at the version level rather than the "repo" level, so we could assert that specific commits were approved
20:50:47 <jds2001> there is an existing API, FWIW - for cockpit integration
20:50:55 <sgallagh> With an eye to adding automation to auto-sign updates if they pass CI
20:51:05 <jds2001> https://galaxy.ansible.com/api/v1/
20:51:24 <sgallagh> To clarify, there's an existing API for browsing and retrieving the roles, but not for actually executing them.
20:51:41 <sgallagh> If we want to have Cockpit perform the execution, we need to do a little work there.
20:51:43 <jds2001> ahh yes, important distinction
20:52:30 <jds2001> so for execution, we just need to use ansible-galaxy CLI to get them, write a skeleton playbook to invoke them with the variables that we collect.
20:52:41 <jds2001> And the collection of the variables is going to be one of the hard parts.
20:52:53 <sgallagh> nirik: Galaxy is basically just a front-end to Github; you can designate any of your github repos that are structured correctly as ansible roles and it will add them to its database where you can set tags on it and things for search
20:52:56 <jds2001> How to determine what to prompt the user for and how.
20:53:05 <sgallagh> And it can be retrieved by the ansible-galaxy CLI or API
20:53:09 <nirik> ok
20:53:22 <sgallagh> After which it behaves exactly like a standard Ansible role (a playbook import)
20:53:29 <jds2001> for example, if i used a var allowed_clients in my role, I probably don't want that exact text in the UI
20:53:49 <jds2001> but the playbook needs to give it to me like that.
20:53:54 <jds2001> so the UI is hard.
20:54:03 <vvaldez> so typically role variables are provided in either hot files (ini-style key=value) or yaml files. can cockpit provide the UI to write these out?
20:54:37 <sgallagh> vvaldez: Let's avoid discussing implementation right now.
20:54:38 <jds2001> vvaldez: probably, someone needs to teach it how.
20:54:58 <vvaldez> sgallagh: ack
20:55:11 <sgallagh> I'm planning to schedule a follow-up meeting with Chris Houseknecht to discuss things further.
20:55:29 <sgallagh> I plan to invite dperpeet and andreasn if they are willing.
20:55:46 <dperpeet> I think that makes sense
20:55:59 <dperpeet> the follow-up, that is
20:56:04 <vvaldez> and FYI earlier in my statement: s/hot/host/
20:56:25 <sgallagh> vvaldez: Ah, I was wondering if we needed to let them cool before running them
20:56:33 <vvaldez> ;)
20:58:07 <sgallagh> One open question I forgot to ask Chris about previously is this: can we and should we make it possible to interrogate a system to see if a role has been deployed there (and with what configuration)?
20:58:23 <sgallagh> Ansible's inherent nature is to be idempotent and "pushy".
20:59:12 <sgallagh> #info Open Question: Can we and should we make it possible to interrogate a system to see if a role has been deployed there (and with what configuration)?
20:59:32 <sgallagh> (no need for an answer right this minute, I just want to get it in the notes so I don't forget later)
21:00:11 <dperpeet> I think that would be valuable
21:01:09 <sgallagh> dperpeet: I think it's great to have in the long-term, assuming it's actually possible.
21:01:10 <vvaldez> sgallagh: it seems it would be very difficult being agentless and idempotent/pushy as you say. However, we could leave bread crumbs around e.g. comments in config files “# added by Fedora Ansible Galaxy role XYZ v0.1
21:01:10 <jds2001> yeah, i could think of a few implementation details there. But we can talk about that later
21:01:28 <vvaldez> and check for those later via interogation
21:01:34 <jds2001> vvaldez: exactly what i was thinking
21:01:55 <sgallagh> Well, the problem with the breadcrumb approach is that it limits us to using only our own created Ansible scripts (or third-parties that follow some guidelines we write)
21:02:13 <jds2001> /etc/ansible_deployed_roles or something of that nature as well.
21:02:15 * vvaldez tries to stop t
21:02:15 <sgallagh> That actively limits the value we gain by integrating with Galaxy, where we theoretically can pull from a wide range of available roles.
21:02:32 * vvaldez tries to stop thiking about implementation details
21:02:36 <jds2001> sgallagh: but we're validating these roles
21:02:49 <sgallagh> jds2001: Well, it depends on what level of validation we want to do.
21:02:50 <jds2001> sgallagh: so they have to follow what we say to do.....
21:03:18 <sgallagh> Our validation could simply be: "Someone on the Server WG looked at this role and approves that it's not introducing a security issue"
21:03:38 <sgallagh> Or it could be "this role meets all of these guidelines" *unrolls fifty feet of papyrus*
21:03:42 * jds2001 was thinking about something more prescriptive than that....
21:03:57 <sgallagh> (Or obviously somewhere in the middle)
21:04:34 <sgallagh> Anyway, yes these are implementation details. I'll put a call out for a one-off meeting to discuss them. Not everyone needs to attend.
21:04:55 <vvaldez> or possibly apply a role with —check (dry-run) and see if it would need to change anything
21:04:55 <puiterwijk> (going back to when I got pinged: someone needs to tell me what we need to get signed and how/when sometime please, would be great, especially if you need new types ot content)
21:04:56 <vvaldez> got it
21:05:01 <sgallagh> I'll send a whenisgood request to server@. If you reply to it, I'll assume you want to attend. If you do not, I'll schedule it without you.
21:05:52 <nirik> puiterwijk: we don't know all the details yet... but ansible galaxy roles, probibly git commits.
21:06:01 <nirik> but we should figure out more details before we ping you
21:06:16 <sgallagh> puiterwijk: What nirik said. We don't have that info yet.
21:06:20 <puiterwijk> nirik: ah, git tag signing is in Sigul 0.202.
21:06:27 <sgallagh> We'll involve you the moment that starts to come together.
21:06:32 <puiterwijk> Okay, sounds good.
21:06:40 <sgallagh> It won't actually be git tagging, I think
21:06:52 <puiterwijk> Right. Just let me know what content you want, and I'll see about adding it
21:07:01 <puiterwijk> Sorry for derailing the meeting
21:07:04 <sgallagh> It'll probably be a detached signature of the git hash, because we won't necessarily have commit privilege to the github repo
21:07:13 <sgallagh> Anyway, that's an impl. detail and I'll stop now
21:09:04 <sgallagh> OK, if there are no further questions, I'll close out the meeting in two minutes
21:09:27 <vvaldez> awesome, as always thanks for herding cats sgallagh
21:11:11 <sgallagh> Thank you all for coming
21:11:13 <sgallagh> #endmeeting