14:03:11 <mvollmer> #startmeeting meeting
14:03:11 <zodbot> Meeting started Mon Jan  9 14:03:11 2017 UTC.  The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:03:11 <zodbot> The meeting name has been set to 'meeting'
14:03:27 <mvollmer> #topic Agenda
14:03:31 <andreasn> mvollmer: sorry, just got back from lunch
14:03:34 <andreasn> .hello andreasn
14:03:35 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
14:03:40 <dperpeet> .hello dperpeet
14:03:41 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com>
14:03:47 <mvollmer> .hello mvo
14:03:48 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
14:04:15 <mvollmer> * virt-buil vs virt-install
14:04:28 <mvollmer> "virt-build"
14:05:37 <andreasn> is Firewall a good topic? bhakti?
14:06:08 <dperpeet> andreasn, yes
14:06:10 <dperpeet> * firewall
14:06:22 <bhakti> yes
14:06:44 <mvollmer> * nfs server config
14:06:52 <andreasn> *
14:06:59 <andreasn> hups, was about to add nfs
14:07:38 <mvollmer> okay, I guess we can start, right?
14:07:52 <andreasn> sounds good
14:07:55 <mvollmer> #topic virt-build vs virt-install
14:08:11 <mvollmer> so the rule used to be "virt-build when we can, virt-install when we have to"
14:08:28 <mvollmer> because virt-build was so easy and quite reliable
14:08:31 <dperpeet> mvollmer, I assume you mean virt-builder?
14:08:35 <dperpeet> or was that renamed?
14:08:39 <mvollmer> and virt-install was a bit magic
14:08:48 <mvollmer> yeah, virt-builder
14:08:56 <dperpeet> ok, thanks
14:09:18 <dperpeet> I think we had virt-install for when there wasn't a ready-made image to consume
14:09:37 <mvollmer> but we forgot to switch fedora-25 over to virt-build when f25 was released, I guess
14:10:07 <mvollmer> yeah, we start out with virt-install until the OS is released and virt-builder has a template for it
14:10:29 <mvollmer> anyway, the point is: I think we should prefer virt-install now
14:10:37 <mvollmer> it works well enough
14:10:37 <dperpeet> why is that?
14:10:54 <mvollmer> and it gives us a image with / in a volume group
14:11:10 <mvollmer> which does matter for one test at least
14:11:19 <mvollmer> and is closer to what people actually install
14:11:32 <mvollmer> and in any case it allows us to control the installation much more
14:11:53 <dperpeet> hm
14:11:57 <mvollmer> i think virt-builder is restricted in its storage layout
14:12:00 <pitti> sorry for no-ob question, but doesn't Fedora have some official cloud images?
14:12:02 <mvollmer> by why virt-resize supports
14:12:07 <dperpeet> the argument about being closer to what people install is a good one
14:12:22 <dperpeet> the virt-builder scripts are very readable
14:12:27 <dperpeet> and a lot more succinct
14:12:51 <mvollmer> pitti, I guess so but is that close enough to what we want to test?
14:13:12 <dperpeet> pitti, the setup scripts pull an official image
14:13:17 <dperpeet> and base changes on top of those
14:13:18 <mvollmer> pitti, and I don't think they are more convenient that virt-builder, no?
14:13:31 <pitti> ah, ok; it sounded like these rebuild a VM from scratch
14:14:10 <mvollmer> some images are from scratch (via virt-install), others less so (via virt-builder)
14:14:19 <pitti> I mostly know cloud-init, as that's what pretty much every cloud except perhaps AWS has standardized on, so it's a common tool to set up a VM  with what one wants
14:15:03 <mvollmer> yes, we use that for fedora-atomic, I think
14:15:07 <mvollmer> which is a cloud image
14:15:09 <dperpeet> we support cloud-init, but that's horrible to debug
14:16:25 <mvollmer> the action point I am looking for is: should we abandon https://github.com/cockpit-project/cockpit/pull/5654
14:16:35 <mvollmer> I say yes.
14:16:41 <mvollmer> no other changes right now
14:16:57 <dperpeet> hm
14:17:21 <dperpeet> I'm fine with abandoning 5654
14:17:29 <dperpeet> i.e. we can drop the "prefer virt-builder"
14:17:59 <mvollmer> okay
14:18:04 <dperpeet> I know that our install scripts were a lot more verbose
14:18:12 <dperpeet> than the virt-builder equivalent
14:18:16 <mvollmer> yes
14:18:29 <mvollmer> but the bots don't care
14:18:38 <mvollmer> do we still make a lot of images manually?
14:18:48 <dperpeet> well, when changing the scripts
14:18:59 <dperpeet> but let's see how we do while keeping the install script for f25
14:19:09 <mvollmer> yep
14:19:18 <dperpeet> and table the other discussion
14:19:27 <dperpeet> since it's not worth changing existing scripts anyway
14:19:41 <dperpeet> I think virt-builder setup is quicker
14:19:47 <dperpeet> virt-install is bare
14:20:45 <mvollmer> it's more magic, but we have it under control, I'd say
14:21:16 <dperpeet> ok
14:21:23 <dperpeet> I'll keep an eye on it
14:21:25 <dperpeet> :)
14:21:31 <mvollmer> #topic firewall
14:21:53 <andreasn> https://github.com/cockpit-project/cockpit/wiki/Feature:-Firewall
14:22:31 <andreasn> the page has some mockups by bhakti now
14:22:38 <andreasn> what's the current status, bhakti?
14:23:25 <bhakti> I have started coding some parts of the mockups as of now. But I need more feedback on the mockups to make any changes that need to be made.
14:24:11 <dperpeet> should we comment on the wiki page?
14:24:25 <dperpeet> they look good overall, but I have a few comments
14:24:29 <bhakti> Yep.
14:24:41 <dperpeet> I think it's great that there are individual mockups for different aspects
14:25:14 <bhakti> thank you :)
14:25:30 <andreasn> yeah, great stuff!
14:26:14 <bhakti> the 'troubleshooting' feature mockup might need more changes.
14:26:52 <andreasn> what kind of changes are you thinking?
14:27:39 <bhakti> I have added the mockup of the use case if there are multiple errors. But using the checkboxes might not be as feasible to apply changes individually
14:28:28 <bhakti> So,for that changes can be made to all errors at a time instead of "troubleshooting" or "deleting" the error one at a time.
14:29:13 <andreasn> right
14:29:21 <bhakti> In case of single errors it is easy to troubleshoot
14:29:27 <bhakti> *error
14:30:47 <bhakti> but if there are multiple errors,the user will be directed to each "possible solution" page and then select back to return to the main page of "troubleshooting"
14:31:34 <andreasn> so what does the Troubleshoot action do exactly?
14:31:50 <andreasn> it pops up a dialog with a possible solution?
14:32:11 <bhakti> it gives the user the "possible solution" dialog
14:32:12 <bhakti> yep
14:32:21 <dperpeet> I think top-down we might want to discuss the tabbed layout
14:32:30 <dperpeet> but this might not be the best place for that discussion
14:32:36 <dperpeet> or rather not the right time
14:32:55 <andreasn> makes sense. OK, eot then
14:32:59 <dperpeet> well
14:33:05 <dperpeet> we can decide on a priority here
14:33:13 <bhakti> okay
14:33:14 <famicom> sup all
14:33:16 <dperpeet> I think making sure we can see what's exposed
14:33:25 <dperpeet> is a good first goal
14:33:45 <dperpeet> and a way to see what was blocked (optionally)
14:34:06 <dperpeet> on a live system it could kill the connection to see all traffic
14:34:24 <famicom> which means you get locked out of the system if you're a remote admin
14:34:31 <famicom> which is a bad thing(tm)
14:35:13 <dperpeet> yes, but those are details, I think the progress is good and we can have another session on the overall layout and what "troubleshooting" means in this context
14:35:25 <dperpeet> I think that can be derived from the user stories
14:35:34 <dperpeet> end of topic on my end
14:35:47 <famicom> speaking of user stories
14:35:52 <famicom> is there any update on the nfs role?
14:36:46 <andreasn> is that the next topic maybe
14:36:50 <andreasn> mvollmer: ?
14:36:53 <mvollmer> #topic NFS Server config
14:36:54 <mvollmer> :)
14:37:04 <famicom> i
14:37:20 <mvollmer> no real progress on my part yet, but a question
14:37:24 <famicom> shoot
14:37:40 <mvollmer> i was thinking whether I should do this out-of-tree...
14:37:58 <mvollmer> as a proof-of-concept maybe and extended example
14:38:16 <mvollmer> what do people think?
14:38:29 <famicom> well what kind of scenarios did you have in mind./
14:39:30 <mvollmer> famicom, so I want to start with running a simple ansible playbook via Cockpit
14:39:46 <famicom> hmmm
14:39:57 <mvollmer> there will be some UI to write out the playbook, which references a role, and then we run that
14:40:24 <mvollmer> I still have to find/contact the people who will write the real NFS Server role
14:40:40 <famicom> does this involve a directory server?
14:40:50 <mvollmer> no, not initially
14:40:58 <famicom> praise be
14:41:20 <mvollmer> famicom, can you say a bit why you are interested in this?
14:41:25 <andreasn> didn't it have to? Or am I mixing things up?
14:41:35 <famicom> you dont really need any ansible then, just have cockpit-nfs depend on nfs-kernel
14:42:12 <famicom> mvollmer because i need a *simple* way to admin a file server
14:42:56 <famicom> and preferably something that runs on a distro that is officially certified by my vendor
14:43:13 <mvollmer> ohh, a user! :-)
14:43:16 <famicom> :D
14:43:32 * mvollmer thought you might be involved in the Fedora Server side of this
14:43:43 <famicom> well, fedora is RHEL testing ;)
14:44:13 <dperpeet> the idea here is that we don't want to have a cockpit-specific solution
14:44:32 <famicom> yeah, it would violate the principles of the project
14:44:33 <dperpeet> if we have an ansible playbook, then people are more flexible
14:44:37 <mvollmer> famicom, this is the entry point to the topic: https://github.com/cockpit-project/cockpit/wiki/Feature:-NFS-Server
14:44:47 <famicom> already reviewed that
14:45:00 <dperpeet> also, if we can support ansible playbooks, we cover more than just nfs server
14:45:12 <mvollmer> so someone write the ansible role, and Cockpit runs it
14:45:18 <famicom> yeah, but i just need it to serve files
14:45:22 <mvollmer> i think that division makes a lot of sense
14:45:30 <famicom> set it up once, put it in a rack, forget about it
14:45:46 <mvollmer> don't worry about the implementation then
14:46:18 <mvollmer> so, should I do this out-of-tree?
14:46:37 <dperpeet> I think we should keep it in tree for now
14:46:45 <dperpeet> and move out if it makes sense
14:47:03 <dperpeet> if you like, you can move the actual playbook out of tree
14:47:15 <dperpeet> to make sure our testing works with that
14:47:24 <famicom> BTW
14:47:30 <dperpeet> but I would be happy with a proof of concept in-tree
14:47:31 <mvollmer> dperpeet, alright, makes sense
14:47:37 <famicom> did anyone consider SMB with user level authentication?
14:47:37 <dperpeet> just to have fewer steps at a time
14:48:29 <andreasn> famicom: we decided to tackle NFS first, but SMB could come later
14:48:41 <mvollmer> famicom, I think it is best to talk to sgallagh about the bigger picture
14:48:45 <andreasn> as a separate role
14:48:52 <mvollmer> or to andreasn :)
14:49:04 <dperpeet> or to me :)
14:49:04 <mvollmer> andreasn, do you have some updates from your side?
14:49:12 <famicom> smart move, but what i read you're edging slowly towards kerberized nfs
14:49:21 <mvollmer> yes
14:49:28 <dperpeet> famicom, we'll probably go for a freeipa version first
14:49:32 <famicom> yeah
14:49:36 <dperpeet> because then we don't need to worry about user sync
14:49:43 <famicom> you dont have to
14:49:53 <andreasn> so a domain server became a requirement
14:50:15 <famicom> because the truth is, on my current network all UIDs sync up anyway
14:50:19 <sgallagh> /me perks up
14:50:21 <sgallagh> You rang?
14:50:33 <dperpeet> famicom, that is a special case, I would say
14:50:48 <dperpeet> sgallagh, we're talking about NFS server role in Cockpit
14:51:23 <sgallagh> /me reads the scrollback
14:51:26 <famicom> you know, i've never actually got FreeIPA to work correctly on my homenet
14:51:51 <famicom> so what about thsoe that use active directory, are you going to support that too?
14:52:19 <sgallagh> famicom: user-level shares are pretty much Samba-only.
14:52:26 <famicom> sadly yes
14:52:27 <sgallagh> NFS really isn't built well for that.
14:52:46 <sgallagh> We're only discussing NFS for now. Samba is on the road-map, but this is our PoC
14:52:47 <famicom> yeah, hence i suggested SMB with user level auth
14:53:05 <sgallagh> famicom: That's out of scope for this discussion.
14:53:09 <dperpeet> we're getting off-topic a bit for cockpit - famicom this is an overview of goals: https://kolinahr.fedorainfracloud.org/edit/57ff81347b76717eefcbc44b
14:53:13 <famicom> so what's wrong with simple ip based exports
14:53:15 <sgallagh> famicom: Active Directory should also work if we do this the right way.
14:53:25 <sgallagh> We only rely on hosts being enrolled with Kerberos.
14:54:25 <famicom> right, which would require a seperate FreeIPA install ?
14:54:36 <sgallagh> famicom: As for getting FreeIPA setup working easily, that's also on the near-term goals.
14:54:43 <sgallagh> Inside 2017, I hope
14:54:56 <sgallagh> famicom: No, AD also uses Kerberos.
14:55:19 <sgallagh> The requirement on our first-pass NFS share system would be that you were enrolled with either FreeIPA or Active Directory.
14:55:28 <famicom> let me rephraise this, can i run all these services reliably in a single system without any kind of virtualization?
14:55:35 <famicom> ah thanks
14:56:50 <andreasn> mvollmer: for your earlier question, I didn't touch this since before xmas, and that was adapting the user stories and workflows to use a domain server
14:57:06 <mvollmer> right
14:57:15 <andreasn> mvollmer: and I'll take a look at the wireframes again and make sure they are all right, but I think it should be good
14:57:26 <mvollmer> okay
14:57:29 <sgallagh> andreasn: I'd love to see those
14:57:31 <famicom> andreas can i see them
14:58:08 <mvollmer> sgallagh, is there already some code for the ansible role?
14:58:30 <andreasn> https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/roles/nfs-server.png
14:58:31 <sgallagh> You mean an example playbook?
14:58:36 <mvollmer> sgallagh, yes
14:58:41 <andreasn> very work-in-progress though
14:58:47 <mvollmer> I assume that the playbook references a role, right?
14:58:52 <sgallagh> Not yet; I've been trying to get ovasik to share the new module API with me so I can write one
14:58:54 <famicom> andreasn looks neat
14:59:08 <sgallagh> mvollmer: OK, so there are three terms:
14:59:13 <sgallagh> Modules, roles and playbooks.
14:59:14 <mvollmer> sgallagh, okay, cool, let me know when you have something that I should look at
14:59:32 <sgallagh> A playbook executes one or more roles and provides an answer file for variable substitutions
14:59:41 <andreasn> famicom: thanks! needs more work on how it looks during editing, how the error states work etc
14:59:50 <sgallagh> a role is a predefined set of actions, usually with variables for tweaking.
15:00:11 <famicom> andreasn it does more or less exactly what it needs to do, nothing more, nothing less
15:00:15 <sgallagh> A module is a piece of python code that gets pushed onto the remote system into a tempdir and executed in order to effect the changes specified in the role.
15:00:46 <mvollmer> (or a task directly in the playbook, right?)
15:00:46 <sgallagh> actually, that was a bad description of a role, since it's declarative rather than a set of changes, but conceptually that's what it means
15:01:16 <mvollmer> it's up to each module to be properly declarative and idem-potent, right?
15:01:31 <mvollmer> the "shell" module isn't, for exmaple, no?
15:01:31 <sgallagh> Yes
15:01:45 <sgallagh> Right, neither is the "raw" module
15:02:09 <mvollmer> so we need a new module to write the nfs server role?
15:02:14 <sgallagh> But actually you can *make* them idempotent.
15:02:21 <mvollmer> or even a new module API?
15:02:23 <sgallagh> There are hooks for things like "don't run if file X exists"
15:02:42 <sgallagh> mvollmer: A module is being written already. I'm not sure of its status.
15:02:50 <dperpeet> andreasn, I added the wireframe to the wiki page
15:02:57 <sgallagh> It's intended to be cross-distro and cross-version compatible.
15:02:59 <andreasn> thanks!
15:03:14 <sgallagh> So we wouldn't need to make custom roles for individual Fedora releases.
15:03:33 <sgallagh> Though if that's all that blocks us, I can make a placeholder role for us to use.
15:03:42 <mvollmer> that would be nice
15:03:45 <sgallagh> Using existing hacks
15:04:00 <mvollmer> i was thinking to write a simple role that just dumps a file into /etc/exports.d/
15:04:05 <sgallagh> But I'm trying to find out if the new modules are ready for testing yet
15:04:21 <mvollmer> sgallagh, since you are here
15:04:22 <sgallagh> Yeah, that would be the easy hack
15:04:24 <famicom> mvollmer yeah
15:04:32 <mvollmer> how would you retrieve the old parameters?
15:04:32 <famicom> but you should be able to read what is already in there
15:04:46 <sgallagh> mvollmer: What old parameters?
15:04:47 <famicom> mvollmer Augeias/
15:04:50 <mvollmer> sgallagh, i.e., when people come back to cockpit after a while and want to tweak their setup?
15:05:19 <sgallagh> mvollmer: Good question.
15:05:27 <mvollmer> i was thinking we store the playbook and just read it.
15:05:38 <mvollmer> (it would best be in JSON for that, not yaml.)
15:05:42 <famicom> id say, enumerate existing config, great an in memory model and work from that
15:05:49 <sgallagh> I'm not sure that's the right approach.
15:06:05 <sgallagh> I need to think about that a bit. Can we discuss it post-meeting?
15:06:19 <mvollmer> yes, tomorrow is best
15:06:36 <mvollmer> larsu also has something to say about that, I guess
15:06:44 <famicom> and then for each share dump every unsupported directive into a field called  "other"
15:06:58 <mvollmer> alright, I think we need to wrap up
15:07:02 <famicom> have it editable through a textfield
15:07:03 <sgallagh> mvollmer: OK, please book some time then
15:07:06 <mvollmer> #topic Any other business
15:07:55 <famicom> please next time change the topic during meetings
15:08:12 <mvollmer> of the channel?
15:08:13 <famicom> since i think i inadvertently barged in
15:08:15 <famicom> yeah
15:08:27 <mvollmer> yeah, no idea how to do that, though
15:08:53 <mvollmer> famicom, np, you stayed on-topic :-)
15:09:58 <mvollmer> upps, in the meeting logs oh well
15:10:08 <mvollmer> thanks!
15:10:10 <mvollmer> #endmeeting