20:03:33 <sgallagh> #startmeeting Server SIG Weekly Meeting (2016-10-04)
20:03:34 <zodbot> Meeting started Tue Oct  4 20:03:33 2016 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:03:34 <zodbot> The meeting name has been set to 'server_sig_weekly_meeting_(2016-10-04)'
20:03:34 <sgallagh> #meetingname ServerSIG
20:03:34 <zodbot> The meeting name has been set to 'serversig'
20:03:34 <sgallagh> #chair sgallagh nirik adamw  mhayden jds2001 vvaldez dperpeet smooge mjwolf
20:03:34 <zodbot> Current chairs: adamw dperpeet jds2001 mhayden mjwolf nirik sgallagh smooge vvaldez
20:03:34 <sgallagh> #topic roll call
20:03:41 <vvaldez> .hello vvaldez
20:03:42 <zodbot> vvaldez: vvaldez 'Vinny Valdez' <vvaldez@redhat.com>
20:03:45 <sgallagh> .hello sgallagh
20:03:46 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
20:03:47 <dperpeet> .hello dperpeet
20:03:49 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com>
20:03:49 <dustymabe> .hellomynameis dustymabe
20:03:52 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dustymabe@redhat.com>
20:04:11 <nirik> .hello kevin
20:04:12 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
20:04:40 <mhayden> .hello mhayden
20:04:41 <zodbot> mhayden: mhayden 'Major Hayden' <major@mhtx.net>
20:06:20 <adamw> .hello adamwill
20:06:21 <zodbot> adamw: adamwill 'Adam Williamson' <awilliam@redhat.com>
20:06:22 * adamw about 15% here
20:06:27 <sgallagh> Understood
20:06:33 <sgallagh> #topic Agenda
20:06:45 <smooge> .hello smooge
20:06:46 <zodbot> smooge: smooge 'Stephen J Smoogen' <smooge@gmail.com>
20:06:47 * adamw will vote for pings
20:07:10 <sgallagh> #info Agenda Item: Finalize Logic Model
20:07:20 <sgallagh> adamw: EPARSE
20:07:58 * mhayden sends adamw some ICMP traffic
20:08:05 <sgallagh> Anyone have other items for the agenda this week?
20:08:39 <sgallagh> #info Agenda Item: Openstack and AMI images
20:08:46 <sgallagh> Let's get started.
20:08:49 <adamw> sgallagh: as in, ping me and i'll vote. :P
20:08:58 <sgallagh> #topic Finalize Logic Model
20:09:09 <sgallagh> #link http://kolinahr.herokuapp.com/edit/57d05a6984338834000515c9
20:09:26 <sgallagh> I've updated the model with (I hope) the stuff we talked about these last two weeks.
20:09:30 <sgallagh> (Also, pretty colors)
20:10:06 <mhayden> chrome seems to be spinning while trying to load it
20:10:09 <sgallagh> That page should be visible without a login now, too
20:10:17 <dustymabe> yeah - i can't access it
20:10:35 <sgallagh> Give it a minute. I haven't gotten the official Fedora instance up yet, so this is still running in the free Heroku tier
20:10:49 <mhayden> all squirrels at full speed!
20:10:53 <sgallagh> It may take a minute to load back up, since it has a ten minute timeout
20:11:03 <sgallagh> mhayden: More like turtles
20:11:31 <smooge> slightly serious question.. should this be a F24 deliverable?
20:11:36 <sgallagh> Which?
20:11:37 <smooge> s/F24/F25/
20:11:49 <smooge> a working lokinahr
20:12:36 <sgallagh> Crap, the site seems like it's down.
20:12:43 <sgallagh> /me really wishes he took a screenshot...
20:13:30 * mhayden redirects to zombo.com :)
20:13:37 <sgallagh> huh?
20:13:44 <mhayden> sgallagh: just kidding :)
20:14:29 <sgallagh> Just a moment. The author is looking at the problem.
20:14:36 <sgallagh> I guess we can switch to the other topic for the moment
20:14:46 <sgallagh> #topic Openstack and AMI images
20:15:20 <sgallagh> OK, so there's been a lot of discussion about what to do WRT the OpenStack and AMIs, with the Cloud WG changing its focus to Atomic WG
20:15:41 <sgallagh> I think pretty much everyone is in agreement that there should be some sort of offering in this space.
20:16:10 <sgallagh> It has been floated that these should be rolled into Fedora Server as part of our output deliverables
20:16:13 <mhayden> i talked to sgallagh a little earlier about this in #fedora-server
20:16:31 <mhayden> it would be a time-saver to have the server image available as as qcow (or similar format) like the cloud image
20:16:40 <mhayden> it would make prototyping, CI testing, and deployments a little easier
20:16:47 * nirik nods.
20:16:56 <vvaldez> definitely makes sense
20:16:57 <mhayden> at the moment, i just make my own and capture it with glance
20:17:01 <sgallagh> So we need to decide two things, as I see it.
20:17:17 <nirik> mhayden: I would be doing that if I had time to do that. ;) I just use the existing cloud one
20:17:31 <sgallagh> 1) What do we want in these images?
20:17:31 <sgallagh> 2) What images do we want to produce?
20:18:18 <nirik> 1) I'd be happy with the existing cloud one + ansible bits
20:18:42 * dustymabe comes back
20:18:44 <nirik> 2) for me, just the qcow2... but there's also all the vagrant ones?
20:18:47 <sgallagh> On 1), I'd actually like to see us not differ from the Server content at all
20:18:48 <smooge> I would say as 'few' images as possible
20:19:00 <nirik> sgallagh: how would cockpit work on a cloud instance?
20:19:13 <sgallagh> (This does not preclude reducing the standard server content)
20:19:21 <sgallagh> nirik: Quite well, thanks for asking ;-)
20:19:29 <nirik> well, I mean how do you login?
20:19:37 <sgallagh> nirik: How do you login otherwise?
20:20:01 <mhayden> for me, it would be nice to have the standard server install as it comes off the DVD
20:20:01 <nirik> well, for kickstart or manual installs I set a root pw.
20:20:06 <mhayden> but that may be too heavy for some folks
20:20:23 <vvaldez> response from dustymabe to my question about vagrant is asking how different the server vagrant box would be from cloud box
20:20:25 <nirik> for cloud... there isn't one
20:20:28 <dperpeet> there's work being done on atomic systems to have a visual boot and set passwords
20:20:42 <sgallagh> mhayden: Today, perhaps. But I'm getting tired of everyone expecting that the cloud image is a kernel+systemd+bash.
20:20:55 <dustymabe> sgallagh: can you elaborate
20:20:56 <mhayden> haha point taken
20:21:13 <dustymabe> i.e. you are tired of everyone assuming it is minimal?
20:21:22 * nirik would also be ok with it being server... thats not too much more and would work as well really.
20:21:23 <sgallagh> If that's all it is, there are literally dozens of equivalent AMIs out there.
20:21:36 <sgallagh> dustymabe: Well, everyone's "minimal" is different
20:21:56 <sgallagh> And we're not offering anyone something of value if we're telling them to build their own
20:22:01 <dustymabe> that is true, but I think we should keep it reasonably close to what it is today, something we had discussed previously
20:22:34 <sgallagh> dustymabe: What I'd prefer is that we have effectively the same deliverable on all media. That way the same tests can be run.
20:22:51 <nirik> if we want to be radical, I'd love to kill the 'fedora' user. :) But I suppose that ship has long sailed.
20:23:05 <dustymabe> i think the key for cloud is that you provide people everything they need in order to build what they want
20:23:05 <sgallagh> nirik: "fedora" user?
20:23:24 <nirik> sgallagh: yes, by default you login as the fedora user and sudo to root
20:23:25 <dustymabe> and you don't do much more than that
20:23:34 <sgallagh> dustymabe: If that's what you think people want, I don't think that's a good fit for the Server SIG, honestly.
20:23:46 <sgallagh> Our charter is basically about providing people solutions-in-a-box.
20:23:55 <sgallagh> Not lego pieces
20:23:55 <dustymabe> yeah - hence the questioning around moving it to the server group
20:24:10 <sgallagh> dustymabe: Sure... but no one seems to be maintaining it elsewhere.
20:24:30 <dustymabe> the thing about "cloud" is that these are "cattle"
20:24:42 <dustymabe> you hopefully never log in to these machines
20:24:53 <dustymabe> and just provision them using cloud-init or some other mechanism
20:25:11 <dperpeet> dustymabe, in production that's true, not for dev
20:25:19 <dustymabe> sometimes you decide to build your own image for this, sometimes you pull the one off the shelf (i.e. from fedora)
20:25:36 <sgallagh> dustymabe: But again, I don't see any value in offering a generic cloud image, then.
20:25:37 * nirik uses ansible against them
20:25:54 <sgallagh> That seems like the Atomic WG has that under control and we should just get out of the business of producing other, more generic images.
20:26:10 <sgallagh> nirik: That sounds like you're describing a weapon, rather than a tool...
20:26:19 <nirik> en guarde!
20:26:26 <smooge> sgallagh, dustymabe looking at download numbers.. I am not sure most other people are seeing an urge to get a cloud image
20:26:44 <nirik> well, download numbers are extra horrible for there.
20:26:46 <nirik> these.
20:26:54 <mhayden> once i download a cloud image, i don't need to download it again though
20:26:57 <smooge> understood but we are down in arm numbers
20:27:05 <nirik> we download it once into openstack and it's used 11 gigillion times there
20:27:06 <mhayden> if i bring up an openstack environment, i'll download the fedora image once
20:27:50 <smooge> but here is the thing.. how does anyone know that you ever really used it or just made your own from parts because you needed to anyway?
20:27:55 <nirik> so, perhaps we still should have a cloud sig that makes these if they aren't a fit for server's goals...
20:28:35 <smooge> but no one wants to make them in the cloud sig
20:28:39 <sgallagh> I'm not convinced that they *aren't* a fit... just that the arguments being provided for them is not in line.
20:29:05 <dustymabe> smooge: I don't think that's accurate, I think there are people that want them (like myself)
20:29:16 <dustymabe> but don't necessarily have the time to contribute all the time
20:29:23 <smooge> dustymabe, there is a difference between wanting them.. and contributing to them
20:29:29 <sgallagh> I think there's value in having an offering for OpenStack and Amazon, but I think I'd rather see it be the same thing we're delivering elsewhere.
20:29:30 <dustymabe> agreed
20:29:59 <smooge> dustymabe, I know that people want cloud images and they want flying cars.
20:30:14 <nirik> well, there would still be some differences...
20:30:15 <smooge> sorry I am not helping here
20:30:15 <dustymabe> sgallagh: I think what I'd rather see is the cloud base as a building block for "server"
20:30:27 <nirik> ie, we wouldn't want cloud-init in all the media would we?
20:30:29 <dustymabe> so it's really easy to get to "server"
20:30:33 <vvaldez> agree, it would be nice to automate creation of any additional images so they are all based in the same "profile"
20:30:51 <sgallagh> nirik: I mean that the user-visible services should be the same, plus anything necessary for a functional install
20:31:00 <sgallagh> In my mind, cloud-init == anaconda for AMI
20:31:06 <vvaldez> nirik: that's what I was thinking, if cloud-init is enabled by default, it is likely to came timeouts on non-cloud-init environments when starting up
20:31:18 <vvaldez> s/came/cause/
20:31:40 <nirik> sgallagh: ok. You would still have to ssh in and set a password to be able to use cockpit, but sure.
20:31:41 <sgallagh> BTW, http://kolinahr.herokuapp.com/edit/57d05a6984338834000515c9 is back now
20:31:46 <dustymabe> vvaldez: right - so you have to provide some sort of user-data ISO for non cloud environments
20:31:56 * vvaldez nods
20:34:21 <dustymabe> anyone with any more input on this?
20:34:54 <sgallagh> So, let's take Cockpit out of the picture for the moment.
20:34:57 <dustymabe> dperpeet: btw, for dev, why can't you just bootstrap and get to your dev environment from the cloud base image?
20:35:06 <dustymabe> this is what we did at a previous company i was at
20:35:21 <dustymabe> everything was just a cloud-init script that basically provisioned the whole machine exactly how you wanted it
20:35:31 <dperpeet> dustymabe, I'm just saying that to debug and develop you'll probably want to log in, too
20:35:41 <sgallagh> I am kind of envisioning Fedora Server 26 as being Base Runtime + firewalld, NetworkManager, ansible support and Cockpit.
20:35:43 <dustymabe> dperpeet: sure
20:36:09 <sgallagh> Is there any reason that we couldn't ship that same set of things for a Fedora Server cloud image?
20:36:42 <dustymabe> sgallagh | So, let's take Cockpit out of the picture for the moment.
20:36:42 <sgallagh> Oh, and storaged
20:36:47 <dustymabe> ^^ you still listed cockpit
20:36:54 <sgallagh> dustymabe: Sorry, I meant the Cockpit UI
20:37:06 <sgallagh> Cockpit still has a remote access protocol that can be used via SSH keys
20:37:11 <dperpeet> I would expect any image to support running containers
20:37:20 <sgallagh> So we wouldn't necessarily need to provide a direct login
20:37:37 <dperpeet> cockpit's ui is happy running as a container, also
20:37:57 <sgallagh> dperpeet: OK, that's worth its own topic, maybe. (Docker? nspawn? rkt?...)
20:38:01 <dustymabe> dperpeet: yeah that is true
20:38:14 <dperpeet> I don't care much which one
20:38:24 <dperpeet> but that's the easiest way to add functionality
20:38:35 <sgallagh> But in the case of Server, we previously asserted that we wanted there to be a usable interface guaranteed to be available
20:38:56 <sgallagh> So I don't care if it is there via container or native, but I want it there by default. (my personal opinion)
20:39:12 <dustymabe> sgallagh: right
20:39:13 <dperpeet> cockpit would be good - but leave out the ui, just as on atomic
20:39:28 <dperpeet> sgallagh, this is also part of having a limited attack surface
20:39:34 <sgallagh> /me nods
20:39:54 * nirik is fine with that personally
20:40:18 <dperpeet> the standard server should include the most important essentials that can't run as a container
20:40:49 <sgallagh> To take a page out of MS's book, we could opt for two "install profiles" (basically Anaconda environment groups): "Fedora Server Edition" and "Fedora Server Edition with GUI"
20:41:13 <dustymabe> I guess a question is: "with Base Runtime + firewalld, NetworkManager, ansible support, could we not get to every other use case" ?
20:41:30 <sgallagh> dustymabe: Could you rephrase the question?
20:41:55 <dustymabe> i.e. if the image can do ansible - then we can use ansible to do anything we want to it
20:41:57 <sgallagh> It's ambiguous whether you're asking for use-cases that wouldn't serve, being sarcastic about it being too broad, etc.
20:42:09 <sgallagh> dustymabe: That's kind of the point, yes.
20:42:35 <sgallagh> We're also in talks with Ansible to use Ansible Galaxy as a tool for building approved, trusted server roles
20:42:42 <dustymabe> then why not deliver that? and then to the user it's basically an "option" that they have to set to get to any other supported use case they want
20:42:50 <dperpeet> dustymabe, you're right in theory, but good default choices aren't always easy to come by if there are too many options
20:43:09 <sgallagh> dustymabe: I'm trying to figure out what you're asking for, because I think I just offered exactly that...
20:43:21 <dperpeet> sgallagh, why not reduce that to the non-ui variant
20:43:22 <smooge> sgallagh, he is wanting no cockpit I think
20:43:23 <dperpeet> for simplicity
20:43:31 <dperpeet> with an easy way to add ui
20:43:47 <dperpeet> e.g. http://www.projectatomic.io/blog/2016/03/introducing-atomic-devmode/
20:43:52 <dustymabe> smooge: yeah, just trying to understand why it helps to have cockpit non-ui parts installed by itself
20:44:07 <sgallagh> dustymabe: Right, I'm suggesting that the cloud image would just be the same as the non-GUI version of Server
20:44:25 <sgallagh> But the bare-metal install would default to having the Cockpit GUI as well
20:44:34 <dustymabe> ahh, yeah that is fine
20:44:41 <dperpeet> dustymabe, because the non ui parts are very small footprint and add a lot of options and discoverability
20:44:47 <sgallagh> dustymabe: Because the non-UI parts can be connected to from another Cockpit instance and worked with remotely
20:44:55 <sgallagh> So you don't need to have the UI on every system, just a bastion host
20:45:34 <vvaldez> and that's easily selected/added via a role it would seem
20:45:50 <dperpeet> vvaldez, the question is how to set such a role
20:45:56 <dperpeet> with cockpit you have a remote api with a nice ui
20:47:07 <dperpeet> the threshold is a lot higher with ansible
20:47:13 <sgallagh> dperpeet: I don't understand the question
20:47:24 <sgallagh> How to set *what* role?
20:47:34 <smooge> I think people are trying to figure out if you can have cockpit without ansible or ansible without cockpit
20:47:50 <smooge> so that you just have the thing that gets you to the other if you need it
20:47:52 <dperpeet> sgallagh, I thought that vvaldez said that cockpit could be easily added via ansible and didn't need to be installed by default
20:47:57 <dustymabe> TBH anything "cloud" uses "cloud-init" as the standard for provisioning https://cloudinit.readthedocs.io/en/latest/
20:48:19 <dustymabe> people do use ansible/etc on top of that
20:48:29 <dustymabe> could cockpit be another option?
20:48:29 <sgallagh> dperpeet, vvaldez: I disagree with that statement
20:48:31 <dustymabe> maybe
20:48:45 <dperpeet> it's a question of scale, maybe
20:48:48 <sgallagh> We want Cockpit to be available from the start. It goes directly to ease-of-use.
20:49:03 <dperpeet> sgallagh, exactly my point
20:49:10 <vvaldez> sgallagh: I was only referring to the GUI part, we could define ansible based roles to enable things like "server with gui" so it could be enabled after install
20:49:21 <dustymabe> vvaldez++
20:49:21 <zodbot> dustymabe: Karma for vvaldez changed to 2 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
20:49:51 <sgallagh> vvaldez: Oh, you mean for cloud images or if someone selects the non-GUI version in anaconda and later changes their mind?
20:50:01 <vvaldez> sgallagh: yes
20:50:06 <sgallagh> I definitely still want anaconda to default to having it, though.
20:50:18 <dustymabe> sgallagh yeah, I'm perfectly fine with that
20:51:07 <sgallagh> OK, so let me formulate a proposal and see if we have a general consensus.
20:52:51 <sgallagh> Proposal: Server SIG will produce install media for AMI and OpenStack. These will all be build from the "Fedora Server Edition (without GUI)" profile. Server SIG will also produce Anaconda install media that will provide both that and a "Fedora Server Edition (with GUI)" profile, which will be the default.
20:53:30 <dustymabe> "With GUI" can you be more specific?
20:53:39 <dustymabe> is this cockpit or is it X11 ?
20:53:40 <dperpeet> and build->built
20:54:00 <sgallagh> Proposal: Server SIG will produce install media for AMI and OpenStack. These will all be built from the "Fedora Server Edition (without GUI)" profile. Server SIG will also produce Anaconda install media that will provide both that and a "Fedora Server Edition (with Web GUI)" profile, which will be the default.
20:54:02 <sgallagh> Clearer?
20:54:45 * nirik is fine with that.
20:54:50 <dperpeet> yes
20:55:19 <dustymabe> yeah that looks better - "install media for AMI and Openstack" might could use some work
20:55:27 <dustymabe> if we are being very literal then that is true
20:55:37 <vvaldez> what about just "images for"
20:55:38 <dustymabe> but we are essentially targeting more pub clouds
20:55:47 <dustymabe> if we can ever get legal to come around
20:55:49 <sgallagh> dustymabe: For now, it's only important that the people doing the work understand what it means
20:55:54 <dustymabe> sgallagh: ok
20:55:56 <dustymabe> that is fine
20:56:04 <dustymabe> just didn't know how literal it was going to be taken
20:56:11 <vvaldez> otherwise looks good. X11 shouldn't be epxected with "Web GUI"
20:56:17 <sgallagh> dustymabe: Well, for now I think very literally.
20:56:38 <sgallagh> Any public cloud beyond Amazon will probably have to be treated as a new feature request, ideally with resources to implement it
20:57:34 <dustymabe> I already do work with Digital Ocean
20:57:44 <dustymabe> so there is that
20:58:01 <sgallagh> dustymabe: For the moment, I'm not willing to commit us to anything more (even this might be a stretch).
20:58:07 <dustymabe> we basically take the existing raw image that comes from releng and put it in there system
20:58:28 <sgallagh> To be clear, we're talking about treating these images as blocking for the release
20:58:42 <dustymabe> sgallagh: right
20:58:42 <sgallagh> I'm not prepared to accept others under that provision without serious discussion
20:58:52 <dustymabe> yeah that is fine
20:59:07 <dustymabe> so it would be easier to add more that were not release blocking?
20:59:13 <nirik> does DO need a different format/changes?
20:59:15 <sgallagh> dustymabe: TBD
20:59:18 <dustymabe> i.e. best effort from contributors
20:59:54 <sgallagh> dustymabe: If we could manage it, I'd rather see this happen outside of normal rel-eng channels and avoid situations where non-blocking media breaks the compose
21:00:06 <sgallagh> And therefore becomes *effectively* blocking under certain circumstances
21:00:07 <dustymabe> nirik initially they needed a few changes. those have gotten fewer over time
21:00:08 <dustymabe> https://github.com/dustymabe/public-cloud-img-prep/tree/master/DigitalOcean/Fedora
21:00:46 <dustymabe> sgallagh: that sounds fine
21:00:47 <nirik> dustymabe: cool. Hopefully we can have just one image and many providers could use it.
21:01:19 <dustymabe> nirik: yeah
21:01:37 <sgallagh> OK, if there are no objections to the above proposal, I'll #agree it here.
21:02:30 <sgallagh> (When looking at the Server pages to clean them up recently, I was reminded that we have a lazy consensus policy to avoid getting bogged down in administrivia)
21:02:46 <sgallagh> #agreed Server SIG will produce install media for AMI and OpenStack. These will all be built from the "Fedora Server Edition (without GUI)" profile. Server SIG will also produce Anaconda install media that will provide both that and a "Fedora Server Edition (with Web GUI)" profile, which will be the default.
21:03:32 <sgallagh> #info The "Server SIG (without GUI)" profile will be comprised primarily of a kernel, systemd, a shell, SSH, NetworkManager, storaged, firewalld and the GUI-less portions of Cockpit
21:04:01 <sgallagh> #info The "Server SIG (with Web GUI)" profile will be comprised of the set of packages in the "Server SIG (without GUI)" profile, plus the web-based interface to Cockpit.
21:04:03 <smooge> sorry kid needed some help. I am ok iwith the above agreed
21:04:27 <dustymabe> geez storaged provides a daemon?
21:04:43 <dustymabe> tangent, nvm
21:04:44 <sgallagh> dustymabe: that would be the  "d" at the end, yes
21:04:51 <smooge> :)
21:04:58 <sgallagh> OK, I don't think we're going to get back to the logic model today.
21:05:08 <sgallagh> #topic Logic Model (redux)
21:05:22 <sgallagh> #info please express your opinions about the logic model on the mailing list
21:05:28 <smooge> ok so I was ok with the outcomes you and major hayden
21:05:28 <sgallagh> #topic Open Floor
21:05:39 <smooge> outlined in #fedora-server
21:06:00 <sgallagh> (Sorry to rush, but we're over time and my kids are hungry for dinner)
21:06:05 <sgallagh> Anything for Open Floor?
21:06:18 <smooge> understood same here
21:06:24 <smooge> nothing from me
21:06:43 <smooge> end it when you want to
21:07:14 <sgallagh> Anyone else?
21:08:02 <sgallagh> #endmeeting