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