15:00:37 <sgallagh> #startmeeting Server SIG Weekly Meeting (2015-06-30)
15:00:37 <zodbot> Meeting started Tue Jun 30 15:00:37 2015 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:37 <sgallagh> #chair sgallagh mizmo nirik stefw adamw simo tuanta mitr danofsatx
15:00:37 <zodbot> Current chairs: adamw danofsatx mitr mizmo nirik sgallagh simo stefw tuanta
15:00:38 <sgallagh> #topic roll call
15:00:53 <adamw> ahoy
15:01:01 <sgallagh> Greetings
15:01:08 <mizmo> hi
15:01:09 <mitr> Hello
15:01:35 <rkuska> hi all, hope you don't mind if I join the conversation
15:01:41 <sgallagh> rkuska: Not at all
15:01:47 <mstuchli> Same for me :)
15:02:03 <sgallagh> (We changed the name from Server WG Meeting to Server SIG Meeting for a reason)
15:02:21 <stefw> .hello stefw
15:02:22 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com>
15:02:57 <simo> .hello simo
15:02:58 <zodbot> simo: simo 'Simo Sorce' <ssorce@redhat.com>
15:03:11 <sgallagh> OK, that's at least quorum.
15:03:45 <sgallagh> #topic Agenda
15:04:03 <sgallagh> #info Agenda Item: Change Status Update
15:04:10 <sgallagh> Other agenda items?
15:04:19 <tuanta> .hello tuanta
15:04:20 <zodbot> tuanta: tuanta 'Truong Anh Tuan' <tuanta@iwayvietnam.com>
15:04:22 <sgallagh> rkuska, mstuchli: Do you have something you'd like to discuss today?
15:04:44 <rkuska> sgallagh: I would like to discuss removing some packages from Server DVD
15:05:10 <sgallagh> #info Agenda Item: Trimming the Server DVD
15:05:31 <stefw> how much do we need to get rid of?
15:05:34 <stefw> is there a goal?
15:05:42 <sgallagh> stefw: Wait for the topic.
15:06:00 <sgallagh> stefw: There are $REASONS here :)
15:06:07 <stefw> ah, ok, sorry for jumping the gun
15:06:17 <sgallagh> np
15:06:35 <sgallagh> If there's nothing else for now, we'll move on and catch any leftovers in Open Floor
15:06:41 <sgallagh> #topic Change Status Update
15:07:02 <sgallagh> So, first is the Bad News(TM)
15:07:29 <sgallagh> As indicated last week, the GSoC student we had working on the Cockpit Domain Controller setup is going to fail.
15:08:08 <sgallagh> Unless someone wants to step up and take over that effort, I think we're going to have to postpone the Change
15:08:43 <adamw> sorry, not gonna be me.
15:08:48 <sgallagh> (Short version: the student hasn't been treating GSoC like the full-time job it is and hasn't been devoting the necessary time. As a result, we're failing him at the midterm)
15:09:19 <sgallagh> adamw: Thank goodness. I've used relval ;-)
15:09:36 * adamw shakes fist at sgallagh
15:09:47 <adamw> why i oughta...
15:10:55 <sgallagh> Secondly, after discussions with the libabigail folks and taskotron, we're moving along nicely with the abi-check routines, but we are *not* going to be able to have them during the F23 cycle, since there are a lot of moving parts.
15:11:20 <sgallagh> We *are* dealing with all of the core plumbing, so we fully expect it to be available for the F24 cycle.
15:11:33 <sgallagh> /me catches up on #info
15:12:00 <sgallagh> #info Cockpit Domain Controller Change is going to be deferred due to insufficient resources
15:12:15 <sgallagh> #info Automatic ABI-break detection is moving along, but will not be ready in time for F23
15:13:26 <sgallagh> On to neutral news: I'm progressing (albeit slowly) on the containerization efforts. I don't have a lot of code written yet because there has been a number of conflicting planning meetings, but I think I have a reasonable handle on what needs to be done. As of now, I still plan to have this done for F23
15:13:49 <sgallagh> #info Containerization of Server Roles is proceeding mostly on schedule
15:14:22 <sgallagh> rolekit's conversion over to Python 3 is also nearly complete. Thanks, rkuska for the review on that.
15:14:41 <sgallagh> #info rolekit to transition to Python 3 soon
15:14:55 <sgallagh> Anyone else have any updates on progress of Server features?
15:15:37 <simo> still working on Domain Controller Replica Promotion code
15:15:54 <simo> one bug/mistep/error at a time
15:15:57 <sgallagh> heh
15:16:12 <sgallagh> #info Domain Controller Replica Promotion work is ongoing
15:17:09 <sgallagh> Anyone else?
15:17:36 <sgallagh> ok, let's move on to the next #topic, then
15:17:47 <sgallagh> #topic Trimming the Server DVD
15:18:01 <sgallagh> rkuska: Could you provide a little background for us, please?
15:18:14 <rkuska> yes, sure, I will firstly list my reasons
15:19:20 <rkuska> I would like to get the packages removed because of the Python3 as default change, all those packages which I will list dont support python && (upstream is dead || there is no reason to have them on dvd (my POV))
15:19:32 <rkuska> dont support python3*
15:20:35 <rkuska> does it sounds ok?
15:21:10 <rkuska> also, it is important to note that we would like to have only python3 on the server dvd
15:21:19 <rkuska> so all the packages which use python must run on python3
15:21:39 <mitr> rkuska: What about the argument that Ansible needs a Python 2 installed (even if nothing depends on it) to run scripts?
15:21:40 <sgallagh> rkuska: To be clear, that's not going to happen completely in F23
15:21:43 <simo> rkuska: all the domain controller packages are python2
15:21:52 <simo> and the DC is a supported Role
15:21:59 <sgallagh> simo: Right, I was just about to note that
15:21:59 <simo> so I do not see how we can do this in the short term
15:22:12 <rkuska> what are domain controller packages?
15:22:24 <simo> rkuska: a few hunderd python packages
15:22:34 <simo> use whatrequires on freeipa-server
15:22:41 <sgallagh> So, I think it's reasonable to work towards eliminating as many as possible, but we won't be removing all of them from the DVD
15:22:55 <simo> sgallagh: we won't eliminate necessarily even most of them
15:23:01 <rkuska> those are shipped by default on server dbvd?
15:23:10 <rkuska> dvd*
15:23:21 <simo> rkuska: the DC is a supported Role, so yes it is shipped on the DVD
15:23:26 <sgallagh> rkuska: They are on the DVD media, but are available as optional packages during install
15:23:57 <sgallagh> rkuska: As we discussed before; we should be talking about two different cases: eliminating Python 3 from the default install and eventually from the DVD media.
15:23:58 <rkuska> can I have an example of such package? I dont understand how that it wasn't found through kickstarter file
15:24:12 <stefw> rkuska, i'm interested in the goal here ... i applaud reducing size ... but is that the goal on its own ... or is there a specific size target?
15:24:14 <sgallagh> rkuska: 'freeipa-client'
15:24:21 <sgallagh> and its dependencies
15:24:36 <rkuska> we are planning to port freeipa to python3
15:24:39 <sgallagh> stefw: Reducing size is part of it; migrating off of Python 2 is another part
15:24:55 <sgallagh> rkuska: Who is "we" and why doesn't simo know this? :)
15:25:29 <rkuska> we are me and pviktori(=petr) he talks with some freeipa developers
15:25:51 <rkuska> I will let him know to include in those conversations also simo if he hasnt yet
15:26:13 <sgallagh> rkuska: I will caution you that a conversion of FreeIPA (and all its deps) to Python 3 is a very big effort.
15:26:27 <simo> rkuska: oh I know that petr (all of them :) want to do that
15:26:29 <sgallagh> And needs to be coordinated with upstream
15:26:31 <rkuska> sgallagh: we are aware, we have seen all those dead dependencies :-)
15:26:41 <simo> rkuska: but it will unlikely be possible by F23
15:27:07 <rkuska> if we fail we will stick in sgallagh plan of two cases
15:27:24 <rkuska> yet we will try also to go with freeipa
15:27:26 <simo> although on my side, my additions (custodia, jwcrypto) are already python 2 and 3 compatible
15:27:33 <simo> at least I am not adding to the pile :-)
15:27:33 <sgallagh> rkuska: I recommend that you focus on the default install first and then try the bigger stuff after that
15:27:45 <sgallagh> If you try for FreeIPA first, you probably won't have time to clean up the rest.
15:27:59 <rkuska> sgallagh: yes, thats what are we doing
15:28:00 <sgallagh> There's also mitr's valid comment about ansible
15:28:03 <rkuska> we currently work on samba
15:28:06 <simo> freeipa is going to be in the long tail out of necessaity
15:28:17 <simo> due to the huge amount of dependencies
15:28:27 <rkuska> yes, we count with ansible, there will be python2 interpreter, just nothing will depend on it
15:28:47 <simo> well is the interpreter enough ?
15:28:56 <sgallagh> rkuska: Well, we as the Server SIG need to decide if that's going to be default vs. optionally installed as well
15:28:56 <simo> ansible does not depend on any other package ?
15:29:02 <mitr> (I’m on parroting the ansible point; I haven’t checked and it’s not strictly obvious to me that Python needs to be in the default install as opposed to a part of ansible client enrollment)
15:29:05 <sgallagh> simo: SSHD
15:29:27 <rkuska> simo: I would expect that any ansible script should depend only on library included in core
15:29:30 <sgallagh> mitr: I thought the point of ansible was that no enrollment was needed
15:29:47 <sgallagh> mitr: That as long as sshd works, it requires no client component
15:29:55 <simo> sgallagh: but it depends on python2 being installed ?
15:29:59 <mitr> sgallagh: Don’t you need at least the ssh public keys set up?
15:30:16 <misc> it can use kerberos and/or password
15:30:33 * mitr shuts up to stop showcasing his ignorance
15:30:49 <sgallagh> I'm not sure that ansible *itself* has a strict python2 dependency though
15:31:00 <simo> ok
15:31:01 <misc> simo: most module requires python, yep, not sure if they work fine with python3
15:31:03 <sgallagh> But I think all of the common ansible playbooks that exist expect it to be present
15:31:09 <stefw> sgallagh, it's in the FAQ
15:31:16 <sgallagh> stefw: Link?
15:31:17 <stefw> "Python 3.0 support will likely be addressed at a later point in time when usage becomes more mainstream."
15:31:19 <misc> I suspect aht's "untested", aka "broken"
15:31:22 <stefw> http://docs.ansible.com/faq.html
15:31:25 <sgallagh> Thanks
15:31:29 <rkuska> but they need only python with stdlib right?
15:31:33 <misc> ( they are porting the ansible client to python 3 however )
15:31:43 <misc> rkuska: depend on the module, yum use yum module, etc, etc
15:31:57 <misc> most use stdlib, some specialized one do have special need ( mostly cloud stuff )
15:31:59 <rkuska> that good to hear, I guess fedora having python3 as default will count towards 'becomes more mainstream'
15:32:23 <misc> (there is also a restriction of being rhel 5 copatible )
15:32:26 <sgallagh> misc: Right, but those that have special needs usually install them
15:32:33 <rkuska> misc: but you can't cover all the ansible playbooks, right?
15:32:48 <misc> rkuska: well, it really depend on the usecase
15:33:24 <misc> personally, i tend to see "being able to use yum or dnf" as a important usecase to cover out of the box
15:33:52 <misc> I care less about having postgres work out of the box with ansible
15:33:55 <sgallagh> misc: Yes, as long as a playbook can be written to use dnf to install whatever other packages it needs, I think it stops being our problem
15:34:20 <rkuska> so we will ship python interpreter and dnf-python2 bindings right?
15:34:25 <simo> use dnf as in Popen('dnf') ?
15:34:25 <misc> sgallagh: technically, you can use raw to install python, then this to install dnf :)
15:34:55 <misc> so ansible could work with almost nothing, so that's mostly about surprising or not people
15:35:32 <sgallagh> I'd be in favor of carrying an ansible-support group of optional packages
15:35:33 <rkuska> as simo noted, those playbooks call dnf trough api or they use subprocess module?
15:35:44 <misc> rkuska: a mix...
15:35:48 <sgallagh> So users who expect to use ansible can just select it in the installer/add it to the kickstart
15:35:53 <misc> let me verify, since things changed a bit
15:36:05 <sgallagh> This group can contain the most commonly-used playbook helpers
15:36:23 <sgallagh> (Again, this likely gets us back to "the DVD carrying py2, but the default install not doing so"
15:36:48 <misc> rkuska: it use dnf python module and also the command line
15:37:02 <rkuska> misc: thanks
15:37:25 <rkuska> so I propose you add dnf python2 bindings to this python2 optional group
15:37:50 <sgallagh> So, I think we've focused on ansible for long enough
15:37:56 <misc> wouldn't dnf pull python binding, because it is in python ?
15:38:03 <rkuska> sgallagh: I agree :)
15:38:21 <sgallagh> misc: DNF moved to Python 3 in F23
15:38:22 <rkuska> misc: dnf will run on python3
15:38:32 <misc> rkuska: oh yeah, forgot about that
15:38:38 * misc will shut up about ansible
15:38:48 <misc> (but feel free to ping me i I can help on that side)
15:38:50 <sgallagh> rkuska: Do you have a list of Python 2 packages currently in the default installation?
15:39:22 <sgallagh> We should focus our efforts on reducing or eliminating those where possible.
15:39:32 <sgallagh> We can also start creating an ansible-support optional group, with help.
15:39:48 <rkuska> can I list all? I will note with every package if it is on default installation
15:39:50 <sgallagh> misc: Are you the right person to figure out what belongs in that group? You seem fairly knowledgeable
15:40:17 <sgallagh> rkuska: If they're clearly identified, sure.
15:40:46 <misc> sgallagh: for ansible ? I do use it a lot, so I could be the right person
15:40:55 <rkuska> ok, so I start with the bigger groups
15:41:09 <sgallagh> misc: Yes, for ansible. I'd appreciate the help if you can offer it.
15:41:11 <misc> (I also code on it on a irregular basis)
15:41:33 <misc> sgallagh: I have a small ackbar amiral telling me "it is a trap", but sure, I can help :)
15:41:45 <rkuska> lmi group - default installation, consist of following packages: cmpi-bindings, openlmi-{networking, providers, storage} and its dependency pywbem
15:42:12 <sgallagh> Right, so OpenLMI is pretty much a failed experiment.
15:42:17 <sgallagh> /me says, having worked on it
15:42:17 <rkuska> openlmi is only in maintance mode, I've talked with upstream, they are not developing it activly
15:42:41 <rkuska> and people run away from you when  you try to talk about it with them
15:42:46 <sgallagh> Our original hope was that we would be able to use it as a remoting API for rolekit and other system services, but it seems that it's not gaining any traction.
15:43:03 <rkuska> I also talked with the manager of the project
15:43:30 <rkuska> He said that he agree with dropping it from the dvd
15:43:47 <sgallagh> WG Vote: Proposal to drop OpenLMI and any exclusive dependencies from the Server DVD
15:43:59 <sgallagh> +1
15:44:11 <sgallagh> mizmo nirik stefw adamw simo tuanta mitr danofsatx: vote please
15:44:12 <mitr> +1
15:44:41 <adamw> +1
15:44:43 <tuanta> +1
15:44:45 <stefw> +1
15:46:21 <sgallagh> mizmo, simo, nirik, danofsatx-lt: votes/reservations
15:47:35 <sgallagh> OK, we have +5
15:48:04 <sgallagh> #agreed Fedora 23 Server DVD will no longer carry OpenLMI (+5, 0, -0)
15:48:22 <sgallagh> #action sgallagh to update comps.xml to remove OpenLMI packages
15:48:34 <sgallagh> rkuska: What's next?
15:48:52 <sgallagh> (Let's stick to the big stuff today; small stuff let's do on the list so we're not here forever)
15:49:18 <rkuska> The next is virt-manager, this is not on default installation, yet it is only the GUI and carries additional dependencies as fence-agents and python-ipaddress, I've talked with upstream and he doesn't understand why it is on ServerDVD
15:50:29 <adamw> the kickstart has the entire virtualization group
15:50:33 <sgallagh> rkuska: It's on the Server DVD mostly because we just carried the "Virtualization" group as it previously existed in comps.xml
15:50:46 <adamw> and virt-manager is part of that group
15:50:55 <sgallagh> Right, so we probably need a virt-headless group with a subset of packags
15:51:06 <sgallagh> I think this is an oversight and doesn't need a formal vote.
15:51:20 <rkuska> Who can I contact about groups?
15:51:20 <sgallagh> #action sgallagh to split the Virtualization group into virt and virt-headless
15:51:23 <adamw> well, i'm always a bit suspicious of that whole "# Infrastructure Server" section in the ks anyway
15:51:35 <adamw> but yeah, one way or another, drop the group or replace it.
15:51:53 <sgallagh> rkuska: I'm the primary manager of comps.xml for the Server SIG.
15:52:13 <rkuska> sgallagh: so I can count on you that you will look into it right? :)
15:52:23 <sgallagh> rkuska: See the #action above? :)
15:52:35 <rkuska> ye, thank you, I continue
15:52:39 <sgallagh> rkuska: But would you mind filing BZs so they don't get forgotten?
15:52:43 <rkuska> sure
15:52:46 <sgallagh> (Against the 'comps' component)
15:52:54 <mitr> sgallagh: Perhaps not as much an oversight as a legacy of the RHEL “manage via local GUI” approach, but yeah, let’s give up on that
15:53:26 <rkuska> another group is olpc, not default installation, this consist of bitfrost and dracut-modules-olpc
15:53:37 <sgallagh> Wait
15:53:37 <rkuska> this is one laptop per child project,
15:53:41 <sgallagh> OLPC is on the DVD?
15:53:47 <sgallagh> How did that happen?
15:53:52 * mitr seconds the amazement
15:53:55 <rkuska> no idea, I got it from kickstarter
15:54:12 <adamw> that can't be right.
15:54:20 * adamw looks
15:54:57 <sgallagh> Definitely not in the kickstart explicitly
15:55:32 <rkuska> we have a script to list all packages from groups mentioned in kickstarter, maybe the script failed us
15:55:50 <sgallagh> rkuska: That seems really suspect.
15:56:34 <rkuska> is there any quick way to check it out?
15:56:46 <adamw> sgallagh: dracut-modules-olpc and bitfrost are on the f22 beta TC6 server DVD indeed, that's the only one I have handy atm
15:56:50 <adamw> i can't immediately see why
15:57:18 <rkuska> group problems again?
15:57:18 <sgallagh> dracut-modules-olpc?
15:57:38 <sgallagh> It's on RC3 as well
15:57:41 <sgallagh> huh...
15:58:01 <adamw> it must be some kind of exotic dep thing
15:58:16 <rkuska> does the groups have something to do with specfiles groups?
15:58:22 <sgallagh> yeah, it's definitely not intentional
15:58:22 <rkuska> Group:System Environment/Base from dracut specfile
15:58:23 <adamw> rkuska: no, nothing at all
15:58:26 <rkuska> ok
15:58:26 <simo> I have to run
15:58:29 <simo> sorry ppl
15:58:31 <simo> bb
15:58:37 <adamw> rkuska: package groups are defined in comps. the rpm Group: tag is used for just about nothing any more
15:58:38 <adamw> cya simo
15:58:50 <rkuska> adamw: thank you for clarification
15:59:23 <sgallagh> Those aren't on the default install, FWIW
15:59:38 <sgallagh> So something in one of the optional groups must be pulling it in
15:59:42 <sgallagh> priority: low
15:59:52 <adamw> i can't find anything that requires dracut-modules-olpc with repoquery
15:59:53 <adamw> bizarre
16:00:37 <sgallagh> I'm guessing it has a virtual Provides of some sort
16:01:19 <adamw> repoquery should check all Provides:
16:01:24 <adamw> and i looked and it doesn't have anything special
16:01:32 <adamw> [root@adam temp]# rpm -qp --provides ./Packages/d/dracut-modules-olpc-0.7.6-5.fc22.x86_64.rpm
16:01:32 <adamw> config(dracut-modules-olpc) = 0.7.6-5.fc22
16:01:32 <adamw> dracut-modules-olpc = 0.7.6-5.fc22
16:01:32 <adamw> dracut-modules-olpc(x86-64) = 0.7.6-5.fc22
16:01:35 <sgallagh> OK, let's come back to this later
16:01:40 <adamw> yeah, we should file a bug or something
16:02:32 <rkuska> may I proceed?
16:02:32 <sgallagh> rkuska: Any other big ones?
16:02:50 <rkuska> from the big ones there are clufter,pacemaker and pcs
16:03:07 <rkuska> but they are not on the default installation
16:03:18 <sgallagh> I'm not sure what any of those are, actually
16:04:06 <rkuska> pcs is command line for pacemaker, and Pacemaker is an advanced, scalable High-Availability cluster resource manager
16:05:28 <sgallagh> Ah, must be the @ha group
16:05:46 <sgallagh> Do we have any idea how commonly-used that is?
16:05:46 <adamw> yeah, another of those 'infrastructure server' ones.
16:06:29 <mitr> HA clustering seems a generally useful functionality we should not be lightly throwing away
16:06:46 <mitr> Or perhaps someone can make a case that containers+kubernetes will replace the old stack?
16:07:36 <rkuska> I've tried to look into clufter, but it seems like it generates zero interest, no issues opened, no PRs, no stars on facebook
16:07:45 <misc> mitr: it will take some time before it does
16:08:52 <mitr> rkuska: Per http://pkgs.fedoraproject.org/cgit/clufter.git/tree/clufter.spec it seems to be alive
16:09:47 <rkuska> it is, yet I doubt it is masivly used
16:10:38 <misc> and seems like a one off migration tool
16:11:20 <sgallagh> adamw: I wonder if the dracut/bitfrost thing was a glitch in F22, because I just took my mock chroot for Rawhide and tried installing every comps package in the DVD kickstart on it, and those didn't show up
16:11:50 <sgallagh> /me guesses they may have been part of the @anaconda-tools group at some point
16:13:33 <mitr> rkuska: Perhaps we should ask the owners/experts instead of trying to guess here
16:14:00 <adamw> sgallagh: there are various black magicks to the DVD compose process which may be involved
16:14:07 <adamw> sgallagh: we'll have to wait for Alpha TC1 and see what happens
16:14:10 <sgallagh> ok
16:14:22 <sgallagh> mitr: +1
16:14:36 <sgallagh> rkuska: Would you mind querying the package owners and CCing server@lists.fp.o?
16:14:52 <rkuska> sure, will do, I will report back what I find out
16:14:56 <sgallagh> Thank you
16:15:43 <rkuska> for the end I have two gui (sub)packages
16:15:58 <rkuska> nmap-frontend and system-config-samba
16:16:31 <rkuska> and one pulled through group PyGreSQL from sql-server
16:16:37 <sgallagh> Again, given the Server WG PRD, I don't think we need to vote on that. GUIs shouldn't be shipped.
16:17:16 <sgallagh> #action sgallagh to remove nmap-frontend, system-config-samba and PyGreSQL from comps groups
16:17:40 <rkuska> I will also open the rhbz for tracking, can I list all the packages in one bug?
16:17:48 <rkuska> for comps component?
16:17:57 <sgallagh> rkuska: That's probably easiest.
16:18:02 <rkuska> will do
16:18:19 <rkuska> looking at my list we discussed all the packages
16:18:42 <sgallagh> rkuska: Sounds like we're good for today, then?
16:19:09 <rkuska> sgallagh: yes, I will contact you next week about the cluster things
16:19:11 <sgallagh> I'll make the changes we discussed here and we'll likely wait for Alpha TC1 to revisit. Good?
16:19:18 <sgallagh> Thanks
16:19:35 <adamw> sounds good
16:19:39 <rkuska> Thank you guys and sorry for the long topic.
16:20:27 <sgallagh> #topic Open Floor
16:20:35 <sgallagh> Anything for Open Floor before I close out the meeting? (W
16:20:40 <sgallagh> e're already over time)
16:21:24 <sgallagh> OK, thanks for hanging in this long, folks.
16:21:27 <sgallagh> #endmeeting