15:59:30 #startmeeting Server Working Group Weekly Meeting (2013-12-03) 15:59:30 Meeting started Tue Dec 3 15:59:30 2013 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:30 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:59:34 #topic roll call 15:59:42 #chair sgallagh mizmo nirik davidstrauss Evolution simo tuanta mitr 15:59:42 Current chairs: Evolution davidstrauss mitr mizmo nirik sgallagh simo tuanta 15:59:52 .hellomynameis sgallagh 15:59:53 sgallagh: sgallagh 'Stephen Gallagher' 16:00:01 .hellomynameis kevin 16:00:05 nirik: kevin 'Kevin Fenzi' 16:00:06 .hellomynameis duffy 16:00:08 mizmo: duffy 'Máirín Duffy' 16:00:22 .hellomynameis simo 16:00:24 simo: simo 'Simo Sorce' 16:00:34 .hellomynameis tflink 16:00:36 tflink: tflink 'Tim Flink' 16:00:38 morning 16:01:18 .hellomynameis stefw 16:01:22 stefw: stefw 'Stef Walter' 16:02:46 Hello 16:03:21 tuanta just sent regrets, he's on a train 16:04:11 That leaves davidstrauss and Evolution. 16:04:21 I pinged the latter elsewhere, but he seems not to be around right now. 16:04:43 We have quorum (if just barely) 16:05:29 Let's proceed. 16:05:36 #topic Adam Williamson Confirmation 16:05:52 Adam has volunteered to fill the seat vacated by Johann. 16:06:21 * adamw applies soothing cream to burn marks on forearm 16:06:34 :) 16:07:22 anyhow, +1 from me. 16:07:27 +1 16:07:29 +1 from me as well 16:08:00 +1 16:08:01 +1 16:08:23 Evolution: Since you just arrived, we're voting to confirm adamw as the newest member of our cabal. 16:08:27 qualifications: i am good at sounding like i know what i'm doing, and I run all of happyassassin.net on Fedora and if anyone's taken it over, they're being very polite about it. 16:08:38 * sgallagh grins 16:09:21 +1 16:09:46 adamw: have I offended you previously in any way? 16:10:23 if not, I'll correct that and then +1 you. 16:10:52 Just posted the persona I worked on: https://fedoraproject.org/wiki/Server/Personas#Persona_.235:_Decision-Maker 16:11:03 (Editing took longer than I had expected this morning) 16:11:07 #agreed Adam Williamson is confirmed as a voting member of the Server Working Group (+6, 0, -0) 16:11:11 davidstrauss, !!!! awesome, thank you so much!!! 16:11:27 welcome adamw :) 16:11:41 Welcome aboard, adamw 16:11:41 the latest character in as the server wg turns weekly blog novella :-p 16:12:12 mizmo: :-) 16:12:12 davidstrauss: Do you want to cast a vote as well? 16:12:40 sgallagh: On Adam? 16:12:41 yes 16:12:42 yes 16:12:45 .hellomynameis davidstrauss 16:12:46 #undo 16:12:46 Removing item from minutes: 16:12:47 davidstrauss: davidstrauss 'David Strauss' 16:12:52 #agreed Adam Williamson is confirmed as a voting member of the Server Working Group (+7, 0, -0) 16:13:11 #topic Discuss role implementation 16:13:23 stefw: You had some thoughts on this that you wanted to bring up? 16:13:48 i was interested to hear about the server roles discussion 16:13:54 coming from the perspective of cockpit 16:14:01 same for me 16:14:04 which is a server UI, that I imagine most here have heard of 16:14:26 because we've been thinking about ways to make more advanced server roles (sorta like some of the wizards in windows) 16:14:34 discoverable and accessible via cockpit 16:14:45 * mizmo doesnt know much about cockpit or know where to learn more 16:14:52 http://cockpit-project.org 16:14:55 thanks :) 16:15:00 sure 16:15:00 #link http://cockpit-project.org 16:15:13 so have a nice way to configure one of your servers as a freeipa server, for example, is a goal of ours 16:15:27 or to have a way to configure a server as a monitoring server 16:15:32 or a file or web server 16:15:33 or maybe even a simple way to setup a puppet master 16:15:36 andreasn, right 16:15:44 and here the push becomes clear... 16:15:58 In other words, it lines up very closely to some of the efforts we've been trying to initiate in the Server WG 16:16:10 yeah, pretty much, hence the interest 16:16:15 one thing i did want to caution against though... 16:16:22 is trying to design a generic server role API from the bottom up 16:16:41 my interest is not so much in designing APIs 16:16:43 especially a generic one 16:16:46 imo, we should probably look at how we want people to interact with it 16:16:55 but in polishing software to be able to act in a role 16:16:55 and then how we're going to implement it 16:17:14 simo, indeed, that's a necessity 16:17:29 I do not think we have the means to change software to respond to any abstract API right now 16:17:37 I would rather let some upstream try that first 16:17:47 so if you want to try in cockpit be my guest :) 16:18:06 simo: Well, there is some possibility that we might try to use something like OpenLMI to meet that need. 16:18:24 sgallagh: I'll let someone ealse deal with that 16:18:26 I'm not so sure it's a generic server API. A lot of the GUI clearly maps to systemd. 16:18:27 it's more likely that we'd consume software specific APIs, and setup scripts, for building a UI 16:18:32 And have Cockpit as [one of] the consumer for that. 16:18:38 rather than a generic api initially 16:18:47 there is probably room for a generic API somewhere in here 16:18:48 * davidstrauss has already joined the mailing list and IRC channel for it just now. 16:18:54 stefw: There were various discussions on the mailing list; so far it seems that UI is important, and automated installations are at least equally important. One possibility that was suggested is to have a single "configuration" for a role and to be able to "(re)apply it", i.e. not an API to change a value, but to remove/readd a role with a new configuration (retaining data, of course) 16:19:31 personally I think I want to enable cockpit and OpenLMI, but not necessarily rely on it/them 16:19:44 at least not initially 16:19:52 simo: There were a lot of upstream unifying APIs (e.g. elektra), but they aren't viable without a distribution committing to them 16:20:03 (not expressing any opinion on any of the APIs/interfaces being discussed, for now) 16:20:33 simo: What do you suggest as a path forwards? I was assuming that we'd do 1) Define what a reasonable default installation looked like and then 2) provide an interface to put that default on the system. 16:20:37 simo, fair enough, this stuff should be usable without cockpit for sure 16:20:48 mitr: I know, but before committing to anything I want to see the results of an effort 16:20:57 just wanted to caution against designing a PAM or debconf style api, and expecting ui's like cockpit to consume it :) 16:21:09 I'm a fan of moving most of the package and operational config to post-installation so we can better support remote tools like this. 16:21:26 simo: Sure. We really need to choose 1-2 roles for the first release, and view them as an opportunity to learn. 16:21:35 there's also deciding how much config we will do too. 16:21:36 mitr, makes sense 16:21:39 sgallagh: we need to define roles first 16:21:49 sgallagh: then choose a way to install the stuff in a reasonable way 16:22:01 nirik: In my opinion, the answer is "As little as possible by default, with the option for "advanced" knobs post-deployment" 16:22:06 and by install I guess I mean configure here 16:22:18 simo: I don't disagree with that 16:22:22 because the install is done by anaconda/yum/rpm 16:22:54 right, it's a spectrum from: just install the needed packages and user goes from there all the way to: install all packages, install config and bring up a 'standard' config of the service... 16:23:38 nirik: I may not have been clear, I'm proposing that we do "install all packages, install config and bring up a 'standard' config of the service" and then allow them to tweak after the fact. 16:23:39 nirik: for most networking services config generally needs to be delayed anyway because you need hostnames and sometime sIP addresses to be the final ones anyway 16:23:59 The way that most boxed server vendors work. 16:24:04 sgallagh: a lot of software can't be correctly tweaked after install easily 16:24:17 see freeipa if you installed it with a random name 16:24:20 right, without a lot of info from the user up front. 16:24:33 Right, when I say "standard config", I'm not talking static. 16:24:33 sgallagh: yeah, my vision of a 'default install' for a server OS would be basically fedora's current minimal. 16:24:43 I mean "ask for the minimum information necessary to reasonably install" 16:25:06 sgallagh: should you ask it at OS install time or as a "firstboot" configuration step ? 16:25:07 adamw: I'm talking about assigning roles to that OS 16:25:16 I agree about the default being very minima 16:25:21 in cases where there is a default 'standard' thing to tweak, perhaps we work with package matintainers to just have the package provide that out of the box? 16:25:22 I would like to se minimum be truly minimal though. 16:25:27 simo: That's the part we need to figure out :) 16:25:28 simo: That's true for Cassandra, too. It's super annoying to unwind the default startup config to be able to use your config. 16:25:35 not minimal for basic. but absolute bare-bones 16:25:38 And the part that I was talking about having an "API" for 16:25:59 sgallagh: so you want an API to configure the software ? 16:26:06 anyhow, I think some of this will become more clear if we pick 2-3 roles and see how we can best provide them to users. 16:26:18 simo: To configure it for "default" use. 16:26:26 I'm not committing to a complete configuration API right now 16:26:35 so basic configuration 16:26:54 something that can be used by an installer to do the minimum configuration necessary 16:27:01 The systemd goal is for services to install with nothing in /etc and start with a sane, basic configuration. 16:27:11 An installer or management console like Cockpit, yes. 16:27:13 the problem with such API, is that they are neither basic not minimum :) 16:27:19 And then allow admins to drop config to override as necessary. 16:27:20 stefw, it seems like we don't know yet how the roles would be implemented but have some ideas for specific roles (that still need to be refined). Have you seen the draft list of roles on our wiki? 16:27:43 simo: Well, going into details, such things are possible with e.g. ansible scripts 16:27:57 sgallagh: scripts are very complex beasts though 16:27:59 As long as we ask questions first 16:28:04 I am not opposed to scripts 16:28:05 mizmo, looking at them now ... 16:28:05 Of course 16:28:19 it just all sounds like debconf 16:28:32 which is sorta ok for simple things but ... 16:28:46 for someone not familiar with debconf, can you give me a one line explanation of how it isn't the kind of thing that would work here? 16:28:51 * nirik thinks it's good to have a roadmap/plan, but we also don't need to provide all things at once on first release. 16:28:53 the main issue is that you have to maintain that stuff 16:29:11 I really despise debconf. 16:29:17 stefw: are you going to have scripting ability to cockpit ? 16:29:18 nirik: Yes, of course. But the point of the PRD is to be that long-term roadmap 16:29:22 Not just a one-release plan 16:29:25 davidstrauss: I do not like it 16:29:36 especially the crappy diffing options on updates 16:29:38 It breaks all sorts of automated config tools with its approach to interactive config. 16:29:42 simo, hoping that openlmi will provide the scripting and cockpit the ui 16:29:48 simo: => the number of options should be minimal (which also happens to make it "easy to use" if we can choose wisely for the options that aren't available to the user) 16:29:58 simo, and cockpit uses openlmi as appropriate 16:30:02 It also insists on starting things after installation, even if debconf didn't allow using the config you actually want for initial startup. 16:30:05 stefw: That's something I'd very much like to see as well 16:30:08 mitr: define minimal please 16:30:37 davidstrauss: well the problem with debconf is that it is integrated with the packaging system 16:30:45 I hope *we* do not want to go there 16:30:57 simo: That's difficult? "the smallest set of options that allows fulfilling the role requirements", but that's just avoiding the answer 16:30:57 I see package installation and configuration as 2 very separate steps 16:31:04 mizmo: debconf (IIUC) is a script not dissimilar to RPM scripts that enables the installer to set defaults for non-interactive installation or prompt for questions on interactive installation. 16:31:06 they can be combined but should not be by default 16:31:13 It's a bit more complicated than that, but that should be the gist of it. 16:31:24 I used to be a BCFG2 maintainer. Preventing debconf from breaking config runs was really hard. 16:31:26 mitr: well I speak from experience 16:31:28 oh okay thanks folks :) 16:31:49 mitr: if I think of FreeIPA for example the minimum set exists but depends on what "subroles" you want to install 16:32:06 simo: +1 16:32:09 This is why systemd supports it from a perspective of packaging standards for files for where to install default config. 16:32:12 so are we suggesting as an alternative to debconf, something like more stringent packaging requirements so the packager of a service ships it with a reasonable, working default? 16:32:17 mizmo: and if you are goign to guess that from an external script you are going to redo part of what freeipa's install script does 16:32:25 mitr: ^^ 16:32:33 autocomplete ... 16:32:40 mizmo: Yes, preferably not in /etc. 16:32:50 simo: That's fine. Perhaps just the difference between FreeIPA options and Kerberos/*LDAP options is a good indication of the direction I'm thinking of? 16:32:57 davidstrauss, what's problematic about /etc? 16:33:14 I'd like to point out that we may be getting too deep into the implementation here. 16:33:33 mitr: not sure what you mean 16:33:35 For January, it would be enough for us to agree on a long-term vision of how this should eventually work and then set milestones to get there 16:33:45 * nirik nods. 16:33:49 mitr: what I am telling yuou is that to install freeipa we have a very large python application 16:33:57 with modules and so on 16:34:11 it is not a small thing for that specific case 16:34:18 but of course we'd reuse it 16:34:27 sgallagh, so the vision so far is.... 16:34:42 what I am trying to understand is what people want to do 16:34:50 mizmo: Was that a "fill in the blank", or "to be continued"? 16:34:54 simo: whew, not just me then :) 16:34:54 do you want to get in the business of creating very complex installers ? 16:35:03 sgallagh, i was going to be continued but reading the scrollback im a bit lost 16:35:03 * nirik isn't clear either, but I think once we pick some roles perhaps we could gain some more clarity 16:35:24 the vision so far is when you install a role, it comes prepackaged with a set of sane defaults which you can configure post-install? 16:35:27 or are we in the business of wrapping existing installers with a very thin layer that just makes them uniformely accessible by some uber-install interface ? 16:35:33 mizmo: I think we can agree on that. 16:35:47 it sounds like we're discussing some sort of distro-owned configuration/wizard/helper layer between the default configuration we set in packages and whatever configuration guides/tools the upstream software provides, which i thought was a business fedora had been trying to get out of. 16:35:49 adamw: yes we've been too vague 16:35:51 mizmo: That's 95% already the case. 16:35:51 * nirik thinks the sane defaults should come in the package 16:36:02 and depending on how you read things we swing across the whole spectrum :) 16:36:11 davidstrauss, that's why i'm lost :) i'm not sure why we are not doing htat already or what problem is being solved 16:36:11 simo: I think the latter, mostly. (OTOH we are fortunate that FreeIPA exists; if it didn't, we couldn't get a practical "domain server role" without essentially getting FreeIPA written.) 16:36:22 The short version of my view here is that we want to behave more like Windows Server does here: If someone tells Server Manager that "that machine over there is a domain controller", it gives you a wizard to set up the basic information and then later allows you to tweak it further. 16:36:38 nirik, do the sane defaults not come in the package today? 16:36:49 mizmo, not in many packages 16:37:00 mizmo: I guess it might depend on the packages... hard to say in abstract 16:37:13 sgallagh: so, how far do we need to go beyond package groups with carefully chosen default configurations to achieve that, in your view? 16:37:14 sgallagh: well that's where the problem is 16:37:15 fixing up software and packages so that they're 'roleable' is a big part of this 16:37:17 oh thats true, i tried to install postfix a while ago... o_O that was hard, but how would you come up with sane defaults for something like that 16:37:18 That varies wildly between different upstreams 16:37:24 sgallagh: either you install the domain Controller or you don't 16:37:26 We use a lot of the Fedora package ecosystem, and I've been quite happy with most configs. 16:37:29 mizmo: My favorite is the "email server" role - ask how to set up mail with antispam and you'll get hundreds of recipes, each of which involves at lest 4 components that don't talk to each other "by default" after a simple (yum install) 16:37:36 there is very little "tweaking" after it is fully installed 16:37:46 adamw: I've said above: I think we're oversolving this right now. Agreeing on where we want to get to is the first step. 16:37:48 mitr, yep setting up an email server is a nightmare right now (for me at least) 16:38:01 From a user perspective, rather than a technical one 16:38:11 I dislike setup tools that only allow configuring things during setup, though. 16:38:20 mitr: and you cannot solve that problem w/o building something like kolab 16:38:26 It can be a mystery where it put the functional configuration based on your choices. 16:38:30 this is the main issue 16:38:33 sgallagh: fair enough. as a goal it seems reasonable. 16:38:45 sgallagh, so the questions up front would be questions of the sort so you could get an actually functioning mail server rather than example.com blahblah that doesn't work out of the box by default? 16:38:54 I do not want to get Fedora in the busyness of buildingin tightly integrated roles, because we will fail 16:38:57 sgallagh, and later on you could bring up the questions again (or even more config) and modify it? 16:39:03 it requires a dedicated project to do that 16:39:14 simo: Yes. Or without packaging something like kolab. Some desirable roles may not be available for years. 16:39:18 at least for some cases where you need to tie together multiple base projects 16:39:25 mizmo: That's what I'd want to see, yes 16:39:33 simo: +1 16:39:39 We're better off supporting containers that allow running the necessary set of daemons and configs to do a tightly integrated set of daemons. 16:39:48 sgallagh, it makes me think about when you set up word press if that makes sense. it gives you that first run wizard thing for the name of your blog, admin password, etc., and then you have a working blog 16:39:54 mitr: sgallagh: so can we agree on the fact we will only package simple roles or existing integrated roles 16:40:07 but will not try to integrate non-existing roles ? 16:40:15 mizmo: That would be an example of an upstream that "gets it" 16:40:23 It gets really messy configuring it all on the base system. Easy to run into conflicts between how one "app" wants DNS configured and another one does. 16:40:25 davidstrauss: In my view, containers do pretty much nothing valuable to the user in this aspect - isolation is an aspect of reliability, not an end-user feature 16:40:52 simo: I'd be okay with that as a "F21 Plan", but I think long-term we should be trying to work our way into additional useful roles. 16:41:00 simo: Only for the first few years; not long-term. (And even for "simple roles" integrating deployment/backup/monitoring/whatever will be work.) 16:41:01 Ideally by approaching upstreams and getting them to work together. 16:41:02 mitr: It allows easy running on a daemon *instance* or instances for a role rather than shoehorning the integration into the base system 16:41:25 sgallagh, another example i guess would be the dreamhost app installer web wizard thingy, or even openshift 16:41:26 sgallagh: are you ready to set up freeipa/sssd like projects ? 16:41:29 :) 16:41:43 davidstrauss: So do SCLs; but let's talk concepts rather than technologies. 16:42:05 simo: A lot of what we want to do might be possible with OpenShift gear recipes as well 16:42:16 I wouldn't want to rule such things out 16:42:26 (Or docker, etc.) 16:42:38 sgallagh: sure but that is all complex scripting that needs to be maintained every time upstream changes something 16:42:44 sgallagh: AFAIK, SCLs merely provide a diversity of binaries and libraries, not daemon instances 16:42:49 it is very high maintenance burden and breakage 16:42:50 And yes, I at least would be willing to help kick off and manage more "glue" projects 16:42:57 sgallagh: OpenShift is moving to Docker as its container format 16:43:06 sgallagh: just want to make sure people understand what we get into that way 16:43:21 davidstrauss: True, you can't reuse the same ports, but you can isolate from conflicts on the system 16:43:27 it requires dedicated people, cannot be dumped on current maintainers 16:43:34 (unless they volunteer of course) 16:43:39 * sgallagh nods 16:43:50 I'm actually saying with the container stance that we should punt on the problem. :-) 16:44:07 I don't think we're equipped either to do the integrated recipes 16:44:33 davidstrauss: we should look at what happens in the FOSS world and then at some point make one of the solutions the preferred one and make it simple to install on Fedora 16:44:43 So the vision for role installation so far is that users can select a role to add to a system, and they would be provided with a (wordpress first-run like) wizard for some initial information and they'll be given a working server using sane defaults. They will be able to modify the config easily later (and recall the wizard or components of it if needed.) 16:44:45 With some exceptions like FreeIPA, where Fedora somewhat owns the work 16:45:09 Another part of the role vision is that roles should be integrated with deployment/backup/monitoring/etc. 16:45:16 davidstrauss: we are actually trying to get on debian too :) 16:45:16 mizmo: That last part is debatable. They'll be able to make modifications, but I'm not committing to it being GUI any time soon 16:45:32 simo: Both OpenShift and Docker have the concept of containers running a set of integrated daemons using a config from an official or community repo 16:45:41 We have concerns about manpower / ability to maintain whatever magic glue that makes the installation of roles work? 16:45:52 mizmo: Yes 16:45:52 mizmo: I suppose, can we add flying cars too? (ie, I think this is a pretty long term down the road thing) 16:46:01 sgallagh, wizard isn't necessarily gui... but you mean it would be a conf file rather than interactive? 16:46:46 nirik: This isn't far down the road if we decide to, say, allow installing Docker containers from a Fedora community repo. 16:46:57 mizmo: We definitely need a non-interactive method for mass deployment; obviously the two should share underlying infrastructure 16:47:00 Docker will be in F21, I think. 16:47:11 mitr, non-interactive would maybe have an answer file? 16:47:28 davidstrauss: I suppose, but then we only support that and not bare metal installs? 16:47:31 mizmo: possibly; unknown implementation detail ATM 16:47:32 sgallagh, (is it okay if i info some of this as it's being cleared up?) 16:47:41 mizmo: Please do 16:48:08 nirik: For roles, sure. 16:48:28 I'm very anti-NIH. Proudly invented elsewhere should be a goal of ours. 16:48:28 #info The vision for role installation so far is that users can select roles to add to a system, and would be provided with a (wordpress first-run like) wizard for some initial information and they'll be given a working server using sane defaults. 16:48:57 ok 16:49:02 #info Optionally, the user should also be able to deploy the role in a mass deployment without having to interact with the wizard. How to achieve this is an implementation detail (answer file possible) 16:49:42 #info The configuration should be able to be modified post-install, but not necessarily via GUI right away (hard to commit to this) 16:50:04 #info One major concern is manpower / ability to maintain framework / configs for this role installation vision 16:50:12 davidstrauss +1 16:50:16 sgallagh: do we need to provide tools to create these "answer" files ? 16:50:29 davidstrauss, can docker install to baremetal too? 16:50:30 davidstrauss: agreed. I really don't want us building and maintaining this 'wizard' layer either. ;) 16:50:31 what is our role in making automation easier ? 16:50:40 simo: I'm going to suggest that this is not a strict goal in the short term 16:50:46 mizmo: Docker does not care about cloud at all. 16:51:09 nirik: That "wizard" layer may end up being Cockpit 16:51:20 The problem in the OpenShift/Docker world is about QA and maintenance of the role recipes people make. 16:51:24 does everyone agree we'd ideally find something NIH rather than rolling our own thing and struggling to get maintainers? 16:51:29 oh god yes. 16:51:32 There exists a project interested in taking this on, at least. We should take advantage of it 16:51:37 davidstrauss: thats a problem with all things like that 16:51:42 mizmo: Yes, vehemently. 16:51:50 mizmo: very yes. 16:51:56 +∞ 16:52:00 mizmo: I am strongly against IH :) 16:52:18 #info We very much prefer to find pre-existing projects / technology to make role installation possible, which should help alleviate concerns about manpower 16:52:21 There's a mass proliferation of recipes. If we want to make our mark, I'd say a repo managed with Fedora maintainer standards would be a huge step forward. 16:52:21 mizmo: we'll need maintainers for the roles in any case (but then ~15 roles vs. 10k packages), but sure, let's not invent new things 16:52:45 mizmo: It will also allow more reuse on and from Ubuntu, Debian, etc. 16:52:52 That's one of the reasons why I keep coming back to potentially using FreeIPA Domain Controller as our flagship role. 16:52:54 davidstrauss: right, with guidelines, review, qa, etc. 16:53:02 #info We will need maintainers for the roles, which is much less load than rolling our own 16:53:37 mizmo: +1 16:53:41 davidstrauss, the repo would have the roles in it? 16:54:18 mizmo: That would be my dream. Someone maintaining coherent, integrated roles for things like email server, groupware, etc. 16:54:23 okay, that sounds like a sane thing to be doing at the distribution layer. 16:54:31 * sgallagh nods 16:54:46 davidstrauss, seems reasonable to add to the vision for roles, everyone okay with this? 16:54:53 mizmo: Cockpit can browse and install the available options, maybe with some interaction or answer file supported by upstream's model. 16:55:00 mizmo: +1 16:55:08 ok I can agree on role as mainatinable objects 16:55:25 now the question are many 16:55:30 davidstrauss: While I agree that would be a nice interface, let's not get too deep into that just yet. 16:55:32 1. how do you package a role 16:55:37 sgallagh: Sure. 16:55:38 2. how do you handle dependencies 16:55:39 * mitr has a hard stop in a few minutes 16:55:47 #info Another part of role vision: roles as maintainable objects in a repo managed with Fedora maintainer standards, integrated & coherent for things like email server, groupware, etc. 16:55:55 simo: This is all handled by how OpenShift and Docker do containers. 16:56:02 3. who gets to resolve dependency or configuration issues that arise from conflicting defaults in the used packages 16:56:20 davidstrauss: do we want to tie roles to containers? 16:56:26 I do not think so 16:56:32 simo, davidstrauss: We don't 16:56:35 stefw, is this helpful? are we missing any points you were hoping would come up? 16:56:53 yup helpful, likely cockpit will need to work with upstream openshift and docker with ui requirements 16:56:53 simo: 1. one of the least interesting aspects - putting files in place can always be done somehow, even if it were shar (shudder); 2. if possibly invisible; 3. the role setup mechanism. 16:57:06 stefw, if that's the technology that ends up being used 16:57:15 er, that was for mizmo 16:57:16 We either tie them to containers and use OpenShift/Docker work, tie to packaging and our own NIH config tool, or use something like Chef/Puppet on the base system. 16:57:37 i feel like chef/puppet is there be dragons 16:57:40 mitr: I am not sure you properly understood the breadth of my questions 16:57:42 mizmo: I agree 16:57:45 what about ansible? 16:57:46 davidstrauss: OpenShift/Docker don't give us any kind of common config tool 16:57:56 mizmo: Same dragons 16:57:58 mitr: my q.'s all come from the experience of getting freeipa in fedora 16:58:04 the problem with any of those is that we are back to matining our own scripts. 16:58:09 mitr: But that may be solvable upsteam. 16:58:21 mitr: due to lack of the coordination my questions are inquiring Freeipa *NEVER* once shipped working at GA :) 16:58:27 simo: The answer there might be "A FreeIPA gear gets to pick the exact deps it works with" 16:58:32 and I think F20 may not be an exception :) 16:58:36 nirik, can you explain to me (i don't know much about containers) how using something like docker would dodge needing to maintain scripts? 16:58:52 nirik, are they more like images? 16:58:52 mizmo: well, we still would there too... 16:58:59 they are git repos. 16:59:07 sgallagh: so is a role a rpm package in the end ? 16:59:11 with strict dependencies ? 16:59:15 simo: All the same, isn't getting the packaging to work an order of magnitude less work than getting the "complex Python installation software" to work? 16:59:16 with suggest dependencies ? 16:59:21 mizmo: It means we'd be able to leverage the repo and service integration/config model someone else hashed out 16:59:33 mitr: well, it is not so simple 16:59:41 simo: I'm not sure yet. I'm *really* trying to focus on what we want first and how we get it second. 16:59:48 mitr: there are things like conditionals that are not solvable with rpm for example 16:59:51 https://www.openshift.com/application-gallery 16:59:56 I guess docker has more of a framework already in place... since there's already git repos and etc... where puppet/ansible are all free form and can be anything anywhere. 16:59:59 mizmo: docker has its own "image build config" varuely similar in role to .spec , same for OpenShift gears 17:00:02 I'm even willing to entertain "A role is a single statically-linked binary" (but not really) 17:00:03 sgallagh: ok should we vote on what we want ? 17:00:27 i think we have a lot of non controversial vision statements about roles we agree on 17:00:27 sgallagh: Wow, very Go. 17:00:40 sgallagh: "A role is a single statically-linked binary" .. I think it makes no sense 17:00:42 isn't that what OS X does too? 17:00:51 mizmo: I think we can at least agree to find an option that doesn't require us to go NIH. 17:00:56 simo: It was mostly a joke, going to the far end of "bundle everything together" 17:01:01 * nirik notes we are over an hour now. 17:01:03 Which is an option to explore. 17:01:20 sgallagh, what else is on the agenda? 17:01:22 How many people have a hard stop? 17:01:22 mitr had to leave 17:01:35 adamw: what is your qa pov on testing "roles" whatever they are ? 17:01:38 mizmo: "PRD", but we're covering that here too, to a great extent 17:01:42 Here's the Docker one: https://index.docker.io/ 17:01:42 adamw: what would help you out ? 17:01:51 sgallagh, i could go for 15 more minutes 17:02:03 I have 5min. max 17:02:09 simo: this is all waaaaaaaay too vague. i mean, i'm having difficulting grokking what it is we are actually planning to build here. 17:02:29 adamw: yeah I think that is still the general sentiment 17:02:34 adamw, it seems to me like it's a layer between RPM/package groups and the OS itself 17:02:35 yeah, there's a lot of distant shining city talk.... 17:02:38 i'm afraid that's the problem QA has with this entire process: it all seems to be discussing things that seem to be very far in the future in a very vague and aspirational way, and it's really hard to get a grasp of the practical consequences. 17:02:43 sgallagh: you seem to have the more advanced view on what you think roles should ne 17:02:45 *be 17:03:06 at this point I think one person needs to take on trying to propose a more clear view and give a well thought out example 17:03:15 I have a view on how they should appear to the users, but there's a lot it takes to get there. 17:03:16 * nirik nods. simo +1 17:03:23 or we will be debating on vague sstuff for the next 4 meetings 17:03:28 simo: I think you just volunteered me, didn't you? :-P 17:03:28 simo +1 17:03:29 take some role, show how the thing works. 17:03:37 sgallagh: I tried at least :) 17:03:40 I'll try to write up an example and send it to the list. 17:03:42 but let's see, as near as I can guess, it sounds like there'd be a workload similar to the current 'desktop' test matrix for every 'role' 17:03:57 I can write up a draft vision statement based on the #infos from this meeting that we agreed on too if it helps. 17:03:57 Any problems with me using FreeIPA as that example, given that it gives us a head-start? 17:04:07 adamw: can you very briefly tell what that workload is ? 17:04:17 mizmo: That would, yes. 17:04:18 in very general terms 17:04:20 sgallagh: sounds fine to me. 17:04:21 we'd have to define a set of test cases that broadly answers the question 'is this role working properly?' - can you deploy it and does it give the result we intend - and run that set of tests for our deliverables, whatever the heck they turn out to be 17:04:21 sgallagh: As long as it's a source for consideration rather than an example of what we want. 17:04:31 mizmo: sounds good... 17:04:52 davidstrauss: I'm not a dictator :) 17:05:10 adamw: so this is from installation of the OS all the way up to running the config tool (whatever that is) and then testing basic functionality ? 17:05:49 simo: i mean, let's say for a 'mail server' role, you'd have a set of test cases like 'do all the expected services come up?', 'can it deliver a mail?', 'can it receive a mail?', blah blah. you'd want to have a definition of what each role is minimally required to achieve and a set of tests to enforce that. ideally, of course, automated...(he builds sky castles) 17:05:57 sgallagh: I won't disagree as I have a deep understanding of freeipa, how it works, and what is broken in fedora wrt it 17:06:04 simo: again, hard to answer without specifics 17:06:11 it gives me a somewhat unfair advantage and may make me blind to some other things 17:06:21 sgallagh: :-) 17:06:24 the 'installation of the OS' bit particularly depends on exactly how we wind up implementing stuff 17:06:29 hopefully others will clearly send alarms if we give something for granted 17:06:35 * sgallagh nods 17:06:40 whether there'd be a likelihood of variance in that step depending on what role(s) you were deploying or not 17:07:06 adamw: ok, personally, I think our role is to make automation possible 17:07:18 In case anyone is unaware, both simo and I have contributed significantly to FreeIPA, hence the bias we may express towards it. 17:07:22 so I "think" we end up making your work easier 17:07:40 adamw: if at any point we go in the other direction I think it is a clear indication we are offroad 17:07:46 * nirik has no knowledge of freeipa, happy to ask dumb questions on any example with it. ;) 17:07:50 simo: this is another very unclear area with this whole three-product proposal - what groups of people we're going to wind up with being responsible for what 17:07:57 can automated testing be part of the vision 17:08:01 but that's another Big Topic, and this meeting's been going on for 1:10 17:08:08 adamw: indeed 17:08:12 * nirik nods 17:08:19 right 17:08:24 I am out of time too 17:08:28 * davidstrauss is out. 17:08:28 i mean, is this even a group that exists once the 'plan' is finished? 17:08:35 adamw: yes 17:08:37 okay 17:08:50 adamw: w/o a group the plan would die 17:08:53 adding new roles, retiring old ones, improving process, etc 17:09:09 so, the qa concern would be that if you broaden that out 17:09:41 in three years we'll have a server group which is responsible for developing a dozen 'server roles', a workstation group producing some kind of workstation product (or products), a cloud group doing whatever it's doing.. 17:09:52 and one QA group which is somehow responsible for making sure they all produce viable deliverables. 17:10:06 and one releng for making it, etc. 17:10:07 adamw: That's why we wanted a QA rep on this team 17:10:07 whereas right now we can barely pretend that we ship two desktops and a minimal install that work. 17:10:13 To keep us grounded 17:10:14 right. 17:10:19 i'm not sure how you fix that, but it seems like a problem. 17:10:22 automation + involvement is key. 17:10:34 * tflink would appreciate being included in or notified of any plans/requests for testing-related automation 17:10:44 i don't think it's unreasonable to have the products start staffing QA more. 17:10:55 adamw: As nirik mentions, time allocated to automate stuff is going to be a major part of our request when we file the PRD 17:10:58 tflink: we have to know what the heck we are making first I suspect. ;) 17:11:05 because automation is only going to scale and help things that are common between them all 17:11:19 unless you're doing product specific automation, which would be cool, but is then... product specific 17:11:25 jwb: yeah. 17:11:35 * jwb goes back to not paying attention 17:11:48 nirik: sure, just hoping that we don't get caught off guard with any "X WG was expecting automation to do Y. why isn't that done?" 17:11:51 Ok, we're over time and we're likely under quorum at this point. 17:12:08 jwb, the community surrounding the products with the exception of the baseWG will have to staff themselves for whatever added QA work they need 17:12:14 tflink: totally agreed. That kind of thing shouldn't happen. 17:12:14 tflink: I'd like for such dependencies to be codified into future plans so that doesn't happen 17:12:30 i.e. "Exiting devel phase requires the following automation tasks to be complete" 17:13:27 #action sgallagh to write up a high-level role example using FreeIPA as a straw-man and send to the list. 17:13:44 "The second deliverable should be a list of necessary changes from existing Fedora procedures needed to release the product." 17:13:46 Let's close out the meeting for now. Plenty to think about. 17:14:00 That should include any qa changes or automation needs. 17:14:41 Thanks for coming, everyone. Further discussion can continue in #fedora-server or on the mailing list. 17:14:42 ok, I assume that's planned after the PRD is due in January? 17:14:42 #endmeeting