15:59:30 <sgallagh> #startmeeting Server Working Group Weekly Meeting (2013-12-03)
15:59:30 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:59:34 <sgallagh> #topic roll call
15:59:42 <sgallagh> #chair sgallagh mizmo nirik davidstrauss Evolution simo tuanta mitr
15:59:42 <zodbot> Current chairs: Evolution davidstrauss mitr mizmo nirik sgallagh simo tuanta
15:59:52 <sgallagh> .hellomynameis sgallagh
15:59:53 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:00:01 <nirik> .hellomynameis kevin
16:00:05 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
16:00:06 <mizmo> .hellomynameis duffy
16:00:08 <zodbot> mizmo: duffy 'Máirín Duffy' <fedora@linuxgrrl.com>
16:00:22 <simo> .hellomynameis simo
16:00:24 <zodbot> simo: simo 'Simo Sorce' <ssorce@redhat.com>
16:00:34 <tflink> .hellomynameis tflink
16:00:36 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
16:00:38 <adamw> morning
16:01:18 <stefw> .hellomynameis stefw
16:01:22 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com>
16:02:46 <mitr> Hello
16:03:21 <mizmo> tuanta just sent regrets, he's on a train
16:04:11 <sgallagh> That leaves davidstrauss and Evolution.
16:04:21 <sgallagh> I pinged the latter elsewhere, but he seems not to be around right now.
16:04:43 <sgallagh> We have quorum (if just barely)
16:05:29 <sgallagh> Let's proceed.
16:05:36 <sgallagh> #topic Adam Williamson Confirmation
16:05:52 <sgallagh> 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 <nirik> :)
16:07:22 <nirik> anyhow, +1 from me.
16:07:27 <simo> +1
16:07:29 <sgallagh> +1 from me as well
16:08:00 <davidstrauss> +1
16:08:01 <mitr> +1
16:08:23 <sgallagh> Evolution: Since you just arrived, we're voting to confirm adamw as the newest member of our cabal.
16:08:27 <adamw> 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 <mizmo> +1
16:09:46 <Evolution> adamw: have I offended you previously in any way?
16:10:23 <Evolution> if not, I'll correct that and then +1 you.
16:10:52 <davidstrauss> Just posted the persona I worked on: https://fedoraproject.org/wiki/Server/Personas#Persona_.235:_Decision-Maker
16:11:03 <davidstrauss> (Editing took longer than I had expected this morning)
16:11:07 <sgallagh> #agreed Adam Williamson is confirmed as a voting member of the Server Working Group (+6, 0, -0)
16:11:11 <mizmo> davidstrauss, !!!! awesome, thank you so much!!!
16:11:27 <mizmo> welcome adamw :)
16:11:41 <sgallagh> Welcome aboard, adamw
16:11:41 <mizmo> the latest character in as the server wg turns weekly blog novella :-p
16:12:12 <davidstrauss> mizmo: :-)
16:12:12 <sgallagh> davidstrauss: Do you want to cast a vote as well?
16:12:40 <davidstrauss> sgallagh: On Adam?
16:12:41 <davidstrauss> yes
16:12:42 <sgallagh> yes
16:12:45 <davidstrauss> .hellomynameis davidstrauss
16:12:46 <sgallagh> #undo
16:12:46 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x4b4ab90>
16:12:47 <zodbot> davidstrauss: davidstrauss 'David Strauss' <david@davidstrauss.net>
16:12:52 <sgallagh> #agreed Adam Williamson is confirmed as a voting member of the Server Working Group (+7, 0, -0)
16:13:11 <sgallagh> #topic Discuss role implementation
16:13:23 <sgallagh> stefw: You had some thoughts on this that you wanted to bring up?
16:13:48 <stefw> i was interested to hear about the server roles discussion
16:13:54 <stefw> coming from the perspective of cockpit
16:14:01 <andreasn> same for me
16:14:04 <stefw> which is a server UI, that I imagine most here have heard of
16:14:26 <stefw> because we've been thinking about ways to make more advanced server roles (sorta like some of the wizards in windows)
16:14:34 <stefw> discoverable and accessible via cockpit
16:14:45 * mizmo doesnt know much about cockpit or know where to learn more
16:14:52 <stefw> http://cockpit-project.org
16:14:55 <mizmo> thanks :)
16:15:00 <stefw> sure
16:15:00 <sgallagh> #link http://cockpit-project.org
16:15:13 <stefw> 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 <stefw> or to have a way to configure a server as a monitoring server
16:15:32 <andreasn> or a file or web server
16:15:33 <stefw> or maybe even a simple way to setup a puppet master
16:15:36 <stefw> andreasn, right
16:15:44 <Viking-Ice> and here the push becomes clear...
16:15:58 <sgallagh> 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 <stefw> yeah, pretty much, hence the interest
16:16:15 <stefw> one thing i did want to caution against though...
16:16:22 <stefw> is trying to design a generic server role API from the bottom up
16:16:41 <simo> my interest is not so much in designing APIs
16:16:43 <stefw> especially a generic one
16:16:46 <stefw> imo, we should probably look at how we want people to interact with it
16:16:55 <simo> but in polishing software to be able to act in a role
16:16:55 <stefw> and then how we're going to implement it
16:17:14 <stefw> simo, indeed, that's a necessity
16:17:29 <simo> I do not think we have the means to change software to respond to any abstract API right now
16:17:37 <simo> I would rather let some upstream try that first
16:17:47 <simo> so if you want to try in cockpit be my guest :)
16:18:06 <sgallagh> simo: Well, there is some possibility that we might try to use something like OpenLMI to meet that need.
16:18:24 <simo> sgallagh: I'll let someone ealse deal with that
16:18:26 <davidstrauss> I'm not so sure it's a generic server API. A lot of the GUI clearly maps to systemd.
16:18:27 <stefw> it's more likely that we'd consume software specific APIs, and setup scripts, for building a UI
16:18:32 <sgallagh> And have Cockpit as [one of] the consumer for that.
16:18:38 <stefw> rather than a generic api initially
16:18:47 <stefw> 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 <mitr> 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 <simo> personally I think I want to enable cockpit and OpenLMI, but not necessarily rely on it/them
16:19:44 <simo> at least not initially
16:19:52 <mitr> 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 <mitr> (not expressing any opinion on any of the APIs/interfaces being discussed, for now)
16:20:33 <sgallagh> 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 <stefw> simo, fair enough, this stuff should be usable without cockpit for sure
16:20:48 <simo> mitr: I know, but before committing to anything I want to see the results of an effort
16:20:57 <stefw> just wanted to caution against designing a PAM or debconf style api, and expecting ui's like cockpit to consume it :)
16:21:09 <davidstrauss> 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 <mitr> 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 <nirik> there's also deciding how much config we will do too.
16:21:36 <stefw> mitr, makes sense
16:21:39 <simo> sgallagh: we need to define roles first
16:21:49 <simo> sgallagh: then choose a way to install the stuff in a reasonable way
16:22:01 <sgallagh> nirik: In my opinion, the answer is "As little as possible by default, with the option for "advanced" knobs post-deployment"
16:22:06 <simo> and by install I guess I mean configure here
16:22:18 <sgallagh> simo: I don't disagree with that
16:22:22 <simo> because the install is done by anaconda/yum/rpm
16:22:54 <nirik> 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 <sgallagh> 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 <simo> 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 <sgallagh> The way that most boxed server vendors work.
16:24:04 <simo> sgallagh: a lot of software can't be correctly tweaked after install easily
16:24:17 <simo> see freeipa if you installed it with a random name
16:24:20 <nirik> right, without a lot of info from the user up front.
16:24:33 <sgallagh> Right, when I say "standard config", I'm not talking static.
16:24:33 <adamw> sgallagh: yeah, my vision of a 'default install' for a server OS would be basically fedora's current minimal.
16:24:43 <sgallagh> I mean "ask for the minimum information necessary to reasonably install"
16:25:06 <simo> sgallagh: should you ask it at OS install time or as a "firstboot" configuration step ?
16:25:07 <sgallagh> adamw: I'm talking about assigning roles to that OS
16:25:16 <sgallagh> I agree about the default being very minima
16:25:21 <nirik> 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 <Evolution> I would like to se minimum be truly minimal though.
16:25:27 <sgallagh> simo: That's the part we need to figure out :)
16:25:28 <davidstrauss> 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 <Evolution> not minimal for basic. but absolute bare-bones
16:25:38 <sgallagh> And the part that I was talking about having an "API" for
16:25:59 <simo> sgallagh: so you want an API to configure the software ?
16:26:06 <nirik> 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 <sgallagh> simo: To configure it for "default" use.
16:26:26 <sgallagh> I'm not committing to a complete configuration API right now
16:26:35 <simo> so basic configuration
16:26:54 <simo> something that can be used by an installer to do the minimum configuration necessary
16:27:01 <davidstrauss> The systemd goal is for services to install with nothing in /etc and start with a sane, basic configuration.
16:27:11 <sgallagh> An installer or management console like Cockpit, yes.
16:27:13 <simo> the problem with such API, is that they are neither basic not minimum :)
16:27:19 <davidstrauss> And then allow admins to drop config to override as necessary.
16:27:20 <mizmo> 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 <sgallagh> simo: Well, going into details, such things are possible with e.g. ansible scripts
16:27:57 <simo> sgallagh: scripts are very complex beasts though
16:27:59 <sgallagh> As long as we ask questions first
16:28:04 <simo> I am not opposed to scripts
16:28:05 <stefw> mizmo, looking at them now ...
16:28:05 <sgallagh> Of course
16:28:19 <simo> it just all sounds like debconf
16:28:32 <simo> which is sorta ok for simple things but ...
16:28:46 <mizmo> 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 <simo> the main issue is that you have to maintain that stuff
16:29:11 <davidstrauss> I really despise debconf.
16:29:17 <simo> stefw: are you going to have scripting ability to cockpit ?
16:29:18 <sgallagh> nirik: Yes, of course. But the point of the PRD is to be that long-term roadmap
16:29:22 <sgallagh> Not just a one-release plan
16:29:25 <simo> davidstrauss: I do not like it
16:29:36 <simo> especially the crappy diffing options on updates
16:29:38 <davidstrauss> It breaks all sorts of automated config tools with its approach to interactive config.
16:29:42 <stefw> simo, hoping that openlmi will provide the scripting and cockpit the ui
16:29:48 <mitr> 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 <stefw> simo, and cockpit uses openlmi as appropriate
16:30:02 <davidstrauss> 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 <sgallagh> stefw: That's something I'd very much like to see as well
16:30:08 <simo> mitr: define minimal please
16:30:37 <simo> davidstrauss: well the problem with debconf is that it is integrated with the packaging system
16:30:45 <simo> I hope *we* do not want to go there
16:30:57 <mitr> 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 <simo> I see package installation and configuration as 2 very separate steps
16:31:04 <sgallagh> 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 <simo> they can be combined but should not be by default
16:31:13 <sgallagh> It's a bit more complicated than that, but that should be the gist of it.
16:31:24 <davidstrauss> I used to be a BCFG2 maintainer. Preventing debconf from breaking config runs was really hard.
16:31:26 <simo> mitr: well I speak from experience
16:31:28 <mizmo> oh okay thanks folks :)
16:31:49 <simo> mitr: if I think of FreeIPA for example the minimum set exists but depends on what "subroles" you want to install
16:32:06 <nirik> simo: +1
16:32:09 <davidstrauss> This is why systemd supports it from a perspective of packaging standards for files for where to install default config.
16:32:12 <mizmo> 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 <simo> 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 <simo> mitr: ^^
16:32:33 <simo> autocomplete ...
16:32:40 <davidstrauss> mizmo: Yes, preferably not in /etc.
16:32:50 <mitr> 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 <mizmo> davidstrauss, what's problematic about /etc?
16:33:14 <sgallagh> I'd like to point out that we may be getting too deep into the implementation here.
16:33:33 <simo> mitr: not sure what you mean
16:33:35 <sgallagh> 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 <simo> mitr: what I am telling yuou is that to install freeipa we have a very large python application
16:33:57 <simo> with modules and so on
16:34:11 <simo> it is not a small thing for that specific case
16:34:18 <simo> but of course we'd reuse it
16:34:27 <mizmo> sgallagh, so the vision so far is....
16:34:42 <simo> what I am trying to understand is what people want to do
16:34:50 <sgallagh> mizmo: Was that a "fill in the blank", or "to be continued"?
16:34:54 <adamw> simo: whew, not just me then :)
16:34:54 <simo> do you want to get in the business of creating very complex installers ?
16:35:03 <mizmo> 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 <mizmo> 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 <simo> 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 <davidstrauss> mizmo: I think we can agree on that.
16:35:47 <adamw> 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 <simo> adamw: yes we've been too vague
16:35:51 <davidstrauss> mizmo: That's 95% already the case.
16:35:51 * nirik thinks the sane defaults should come in the package
16:36:02 <simo> and depending on how you read things we swing across the whole spectrum :)
16:36:11 <mizmo> 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 <mitr> 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 <sgallagh> 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 <mizmo> nirik, do the sane defaults not come in the package today?
16:36:49 <stefw> mizmo, not in many packages
16:37:00 <nirik> mizmo: I guess it might depend on the packages... hard to say in abstract
16:37:13 <adamw> 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 <simo> sgallagh: well that's where the problem is
16:37:15 <stefw> fixing up software and packages so that they're 'roleable' is a big part of this
16:37:17 <mizmo> 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 <sgallagh> That varies wildly between different upstreams
16:37:24 <simo> sgallagh: either you install the domain Controller or you don't
16:37:26 <davidstrauss> We use a lot of the Fedora package ecosystem, and I've been quite happy with most configs.
16:37:29 <mitr> 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 <simo> there is very little "tweaking" after it is fully installed
16:37:46 <sgallagh> 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 <mizmo> mitr, yep setting up an email server is a nightmare right now (for me at least)
16:38:01 <sgallagh> From a user perspective, rather than a technical one
16:38:11 <davidstrauss> I dislike setup tools that only allow configuring things during setup, though.
16:38:20 <simo> mitr: and you cannot solve that problem w/o building something like kolab
16:38:26 <davidstrauss> It can be a mystery where it put the functional configuration based on your choices.
16:38:30 <simo> this is the main issue
16:38:33 <adamw> sgallagh: fair enough. as a goal it seems reasonable.
16:38:45 <mizmo> 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 <simo> I do not want to get Fedora in the busyness of buildingin tightly integrated roles, because we will fail
16:38:57 <mizmo> sgallagh, and later on you could bring up the questions again (or even more config) and modify it?
16:39:03 <simo> it requires a dedicated project to do that
16:39:14 <mitr> simo: Yes.  Or without packaging something like kolab.  Some desirable roles may not be available for years.
16:39:18 <simo> at least for some cases where you need to tie together multiple base projects
16:39:25 <sgallagh> mizmo: That's what I'd want to see, yes
16:39:33 <nirik> simo: +1
16:39:39 <davidstrauss> 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 <mizmo> 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 <simo> mitr: sgallagh: so can we agree on the fact we will only package simple roles or existing integrated roles
16:40:07 <simo> but will not try to integrate non-existing roles ?
16:40:15 <sgallagh> mizmo: That would be an example of an upstream that "gets it"
16:40:23 <davidstrauss> 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 <mitr> 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 <sgallagh> 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 <mitr> 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 <sgallagh> Ideally by approaching upstreams and getting them to work together.
16:41:02 <davidstrauss> 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 <mizmo> sgallagh, another example i guess would be the dreamhost app installer web wizard thingy, or even openshift
16:41:26 <simo> sgallagh: are you ready to set up freeipa/sssd like projects ?
16:41:29 <simo> :)
16:41:43 <sgallagh> davidstrauss: So do SCLs; but let's talk concepts rather than technologies.
16:42:05 <sgallagh> simo: A lot of what we want to do might be possible with OpenShift gear recipes as well
16:42:16 <sgallagh> I wouldn't want to rule such things out
16:42:26 <sgallagh> (Or docker, etc.)
16:42:38 <simo> sgallagh: sure but that is all complex scripting that needs to be maintained every time upstream changes something
16:42:44 <davidstrauss> sgallagh: AFAIK, SCLs merely provide a diversity of binaries and libraries, not daemon instances
16:42:49 <simo> it is very high maintenance burden and breakage
16:42:50 <sgallagh> And yes, I at least would be willing to help kick off and manage more "glue" projects
16:42:57 <davidstrauss> sgallagh: OpenShift is moving to Docker as its container format
16:43:06 <simo> sgallagh: just want to make sure people understand what we get into that way
16:43:21 <sgallagh> davidstrauss: True, you can't reuse the same ports, but you can isolate from conflicts on the system
16:43:27 <simo> it requires dedicated people, cannot be dumped on current maintainers
16:43:34 <simo> (unless they volunteer of course)
16:43:39 * sgallagh nods
16:43:50 <davidstrauss> I'm actually saying with the container stance that we should punt on the problem. :-)
16:44:07 <davidstrauss> I don't think we're equipped either to do the integrated recipes
16:44:33 <simo> 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 <mizmo> 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 <davidstrauss> With some exceptions like FreeIPA, where Fedora somewhat owns the work
16:45:09 <mizmo> Another part of the role vision is that roles should be integrated with deployment/backup/monitoring/etc.
16:45:16 <simo> davidstrauss: we are actually trying to get on debian too :)
16:45:16 <sgallagh> 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 <davidstrauss> 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 <mizmo> We have concerns about manpower / ability to maintain whatever magic glue that makes the installation of roles work?
16:45:52 <sgallagh> mizmo: Yes
16:45:52 <nirik> 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 <mizmo> sgallagh, wizard isn't necessarily gui... but you mean it would be a conf file rather than interactive?
16:46:46 <davidstrauss> 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 <mitr> mizmo: We definitely need a non-interactive method for mass deployment; obviously the two should share underlying infrastructure
16:47:00 <davidstrauss> Docker will be in F21, I think.
16:47:11 <mizmo> mitr, non-interactive would maybe have an answer file?
16:47:28 <nirik> davidstrauss: I suppose, but then we only support that and not bare metal installs?
16:47:31 <mitr> mizmo: possibly; unknown implementation detail ATM
16:47:32 <mizmo> sgallagh, (is it okay if i info some of this as it's being cleared up?)
16:47:41 <sgallagh> mizmo: Please do
16:48:08 <davidstrauss> nirik: For roles, sure.
16:48:28 <davidstrauss> I'm very anti-NIH. Proudly invented elsewhere should be a goal of ours.
16:48:28 <mizmo> #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 <simo> ok
16:49:02 <mizmo> #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 <mizmo> #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 <mizmo> #info One major concern is manpower / ability to maintain framework / configs for this role installation vision
16:50:12 <mizmo> davidstrauss +1
16:50:16 <simo> sgallagh: do we need to provide tools to create these "answer" files ?
16:50:29 <mizmo> davidstrauss, can docker install to baremetal too?
16:50:30 <nirik> davidstrauss: agreed. I really don't want us building and maintaining this 'wizard' layer either. ;)
16:50:31 <simo> what is our role in making automation easier ?
16:50:40 <sgallagh> simo: I'm going to suggest that this is not a strict goal in the short term
16:50:46 <davidstrauss> mizmo: Docker does not care about cloud at all.
16:51:09 <sgallagh> nirik: That "wizard" layer may end up being Cockpit
16:51:20 <davidstrauss> The problem in the OpenShift/Docker world is about QA and maintenance of the role recipes people make.
16:51:24 <mizmo> does everyone agree we'd ideally find something NIH rather than rolling our own thing and struggling to get maintainers?
16:51:29 <adamw> oh god yes.
16:51:32 <sgallagh> There exists a project interested in taking this on, at least. We should take advantage of it
16:51:37 <nirik> davidstrauss: thats a problem with all things like that
16:51:42 <sgallagh> mizmo: Yes, vehemently.
16:51:50 <Evolution> mizmo: very yes.
16:51:56 <nirik> +∞
16:52:00 <simo> mizmo: I am strongly against IH :)
16:52:18 <mizmo> #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 <davidstrauss> 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 <mitr> 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 <davidstrauss> mizmo: It will also allow more reuse on and from Ubuntu, Debian, etc.
16:52:52 <sgallagh> That's one of the reasons why I keep coming back to potentially using FreeIPA Domain Controller as our flagship role.
16:52:54 <nirik> davidstrauss: right, with guidelines, review, qa, etc.
16:53:02 <mizmo> #info We will need maintainers for the roles, which is much less load than rolling our own
16:53:37 <davidstrauss> mizmo: +1
16:53:41 <mizmo> davidstrauss, the repo would have the roles in it?
16:54:18 <davidstrauss> mizmo: That would be my dream. Someone maintaining coherent, integrated roles for things like email server, groupware, etc.
16:54:23 <adamw> okay, that sounds like a sane thing to be doing at the distribution layer.
16:54:31 * sgallagh nods
16:54:46 <mizmo> davidstrauss, seems reasonable to add to the vision for roles, everyone okay with this?
16:54:53 <davidstrauss> mizmo: Cockpit can browse and install the available options, maybe with some interaction or answer file supported by upstream's model.
16:55:00 <sgallagh> mizmo: +1
16:55:08 <simo> ok I can agree on role as mainatinable objects
16:55:25 <simo> now the question are many
16:55:30 <sgallagh> davidstrauss: While I agree that would be a nice interface, let's not get too deep into that just yet.
16:55:32 <simo> 1. how do you package a role
16:55:37 <davidstrauss> sgallagh: Sure.
16:55:38 <simo> 2. how do you handle dependencies
16:55:39 * mitr has a hard stop in a few minutes
16:55:47 <mizmo> #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 <davidstrauss> simo: This is all handled by how OpenShift and Docker do containers.
16:56:02 <simo> 3. who gets to resolve dependency or configuration issues that arise from conflicting defaults in the used packages
16:56:20 <simo> davidstrauss: do we want to tie roles to containers?
16:56:26 <simo> I do not think so
16:56:32 <mitr> simo, davidstrauss: We don't
16:56:35 <mizmo> stefw, is this helpful? are we missing any points you were hoping would come up?
16:56:53 <stefw> yup helpful, likely cockpit will need to work with upstream openshift and docker with ui requirements
16:56:53 <mitr> 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> stefw, if that's the technology that ends up being used
16:57:15 <stefw> er, that was for mizmo
16:57:16 <davidstrauss> 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 <mizmo> i feel like chef/puppet is there be dragons
16:57:40 <simo> mitr: I am not sure you properly understood the breadth of my questions
16:57:42 <davidstrauss> mizmo: I agree
16:57:45 <mizmo> what about ansible?
16:57:46 <mitr> davidstrauss: OpenShift/Docker don't give us any kind of common config tool
16:57:56 <sgallagh> mizmo: Same dragons
16:57:58 <simo> mitr: my q.'s all come from the experience of getting freeipa in fedora
16:58:04 <nirik> the problem with any of those is that we are back to matining our own scripts.
16:58:09 <davidstrauss> mitr: But that may be solvable upsteam.
16:58:21 <simo> mitr: due to lack of the coordination my questions are inquiring Freeipa *NEVER* once shipped working at GA :)
16:58:27 <sgallagh> simo: The answer there might be "A FreeIPA gear gets to pick the exact deps it works with"
16:58:32 <simo> and I think F20 may not be an exception :)
16:58:36 <mizmo> 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 <mizmo> nirik, are they more like images?
16:58:52 <nirik> mizmo: well, we still would there too...
16:58:59 <nirik> they are git repos.
16:59:07 <simo> sgallagh: so is a role a rpm package in the end ?
16:59:11 <simo> with strict dependencies ?
16:59:15 <mitr> 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 <simo> with suggest dependencies ?
16:59:21 <davidstrauss> mizmo: It means we'd be able to leverage the repo and service integration/config model someone else hashed out
16:59:33 <simo> mitr: well, it is not so simple
16:59:41 <sgallagh> 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 <simo> mitr: there are things like conditionals that are not solvable with rpm for example
16:59:51 <davidstrauss> https://www.openshift.com/application-gallery
16:59:56 <nirik> 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 <mitr> mizmo: docker has its own "image build config" varuely similar in role to .spec , same for OpenShift gears
17:00:02 <sgallagh> I'm even willing to entertain "A role is a single statically-linked binary" (but not really)
17:00:03 <simo> sgallagh: ok should we vote on what we want ?
17:00:27 <mizmo> i think we have a lot of non controversial vision statements about roles we agree on
17:00:27 <davidstrauss> sgallagh: Wow, very Go.
17:00:40 <simo> sgallagh: "A role is a single statically-linked binary" .. I think it makes no sense
17:00:42 <mizmo> isn't that what OS X does too?
17:00:51 <davidstrauss> mizmo: I think we can at least agree to find an option that doesn't require us to go NIH.
17:00:56 <sgallagh> 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 <sgallagh> Which is an option to explore.
17:01:20 <mizmo> sgallagh, what else is on the agenda?
17:01:22 <sgallagh> How many people have a hard stop?
17:01:22 <mizmo> mitr had to leave
17:01:35 <simo> adamw: what is your qa pov on testing "roles" whatever they are ?
17:01:38 <sgallagh> mizmo: "PRD", but we're covering that here too, to a great extent
17:01:42 <davidstrauss> Here's the Docker one: https://index.docker.io/
17:01:42 <simo> adamw: what would help you out ?
17:01:51 <mizmo> sgallagh, i could go for 15 more minutes
17:02:03 <simo> I have 5min. max
17:02:09 <adamw> 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 <simo> adamw: yeah I think that is still the general sentiment
17:02:34 <mizmo> adamw, it seems to me like it's a layer between RPM/package groups and the OS itself
17:02:35 <nirik> yeah, there's a lot of distant shining city talk....
17:02:38 <adamw> 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 <simo> sgallagh: you seem to have the more advanced view on what you think roles should ne
17:02:45 <simo> *be
17:03:06 <simo> 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 <sgallagh> 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 <simo> or we will be debating on vague sstuff for the next 4 meetings
17:03:28 <sgallagh> simo: I think you just volunteered me, didn't you? :-P
17:03:28 <mizmo> simo +1
17:03:29 <nirik> take some role, show how the thing works.
17:03:37 <simo> sgallagh: I tried at least :)
17:03:40 <sgallagh> I'll try to write up an example and send it to the list.
17:03:42 <adamw> 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 <mizmo> 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 <sgallagh> Any problems with me using FreeIPA as that example, given that it gives us a head-start?
17:04:07 <simo> adamw: can you very briefly tell what that workload is ?
17:04:17 <sgallagh> mizmo: That would, yes.
17:04:18 <simo> in very general terms
17:04:20 <nirik> sgallagh: sounds fine to me.
17:04:21 <adamw> 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 <davidstrauss> sgallagh: As long as it's a source for consideration rather than an example of what we want.
17:04:31 <nirik> mizmo: sounds good...
17:04:52 <sgallagh> davidstrauss: I'm not a dictator :)
17:05:10 <simo> 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 <adamw> 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 <simo> 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 <adamw> simo: again, hard to answer without specifics
17:06:11 <simo> it gives me a somewhat unfair advantage and may make me blind to some other things
17:06:21 <davidstrauss> sgallagh: :-)
17:06:24 <adamw> the 'installation of the OS' bit particularly depends on exactly how we wind up implementing stuff
17:06:29 <simo> hopefully others will clearly send alarms if we give something for granted
17:06:35 * sgallagh nods
17:06:40 <adamw> whether there'd be a likelihood of variance in that step depending on what role(s) you were deploying or not
17:07:06 <simo> adamw: ok, personally, I think our role is to make automation possible
17:07:18 <sgallagh> 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 <simo> so I "think" we end up making your work easier
17:07:40 <simo> 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 <adamw> 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 <mizmo> can automated testing be part of the vision
17:08:01 <adamw> but that's another Big Topic, and this meeting's been going on for 1:10
17:08:08 <simo> adamw: indeed
17:08:12 * nirik nods
17:08:19 <simo> right
17:08:24 <simo> I am out of time too
17:08:28 * davidstrauss is out.
17:08:28 <adamw> i mean, is this even a group that exists once the 'plan' is finished?
17:08:35 <davidstrauss> adamw: yes
17:08:37 <adamw> okay
17:08:50 <simo> adamw: w/o a group the plan would die
17:08:53 <nirik> adding new roles, retiring old ones, improving process, etc
17:09:09 <adamw> so, the qa concern would be that if you broaden that out
17:09:41 <adamw> 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 <adamw> and one QA group which is somehow responsible for making sure they all produce viable deliverables.
17:10:06 <nirik> and one releng for making it, etc.
17:10:07 <sgallagh> adamw: That's why we wanted a QA rep on this team
17:10:07 <adamw> whereas right now we can barely pretend that we ship two desktops and a minimal install that work.
17:10:13 <sgallagh> To keep us grounded
17:10:14 <nirik> right.
17:10:19 <adamw> i'm not sure how you fix that, but it seems like a problem.
17:10:22 <nirik> 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 <jwb> i don't think it's unreasonable to have the products start staffing QA more.
17:10:55 <sgallagh> 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 <nirik> tflink: we have to know what the heck we are making first I suspect. ;)
17:11:05 <jwb> because automation is only going to scale and help things that are common between them all
17:11:19 <jwb> unless you're doing product specific automation, which would be cool, but is then... product specific
17:11:25 <nirik> jwb: yeah.
17:11:35 * jwb goes back to not paying attention
17:11:48 <tflink> 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 <sgallagh> Ok, we're over time and we're likely under quorum at this point.
17:12:08 <Viking-Ice> 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 <nirik> tflink: totally agreed. That kind of thing shouldn't happen.
17:12:14 <sgallagh> tflink: I'd like for such dependencies to be codified into future plans so that doesn't happen
17:12:30 <sgallagh> i.e. "Exiting devel phase requires the following automation tasks to be complete"
17:13:27 <sgallagh> #action sgallagh to write up a high-level role example using FreeIPA as a straw-man and send to the list.
17:13:44 <nirik> "The second deliverable should be a list of necessary changes from existing Fedora procedures needed to release the product."
17:13:46 <sgallagh> Let's close out the meeting for now. Plenty to think about.
17:14:00 <nirik> That should include any qa changes or automation needs.
17:14:41 <sgallagh> Thanks for coming, everyone. Further discussion can continue in #fedora-server or on the mailing list.
17:14:42 <tflink> ok, I assume that's planned after the PRD is due in January?
17:14:42 <sgallagh> #endmeeting