17:03:27 #startmeeting XenAPI 17:03:28 Meeting started Wed Jan 23 17:03:27 2013 UTC. The chair is johngarbutt. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:03:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:03:31 The meeting name has been set to 'xenapi' 17:03:40 hello all 17:03:47 hi 17:03:47 hi 17:03:48 hey hey 17:04:03 hola 17:04:16 #topic agenda 17:04:23 what do people want to cover? 17:04:29 there was the swift upload stuff 17:04:33 anything else? 17:05:01 ideas: blueprints, docs, QA, Bugs 17:05:24 I would like to have some xenapi lib code pulled to oslo. 17:05:36 But that's far away from being ready. 17:06:18 right, Cinder now contacts XenAPi 17:06:22 as does Nova 17:06:29 lets not get into more cut and paste 17:06:37 OK 17:06:41 :) 17:06:46 lets move on to swift 17:07:03 #topic swift client in dom0 17:07:38 let me find the link 17:07:47 should we ans any concerns? 17:08:03 #link https://review.openstack.org/#/c/17803/ 17:08:19 so, what was the issue getting the swift CLI working in Dom0 again? 17:08:28 I haven't been following this properly - what's the current proposal? a python 2.4 compatible client in dom0? 17:08:34 nope 17:08:39 install python 2.6 17:08:45 then use a custom swift client 17:08:51 with some chunking code from glance 17:08:55 as plugins 17:08:56 good for the first bit! I was a little worried :D 17:08:59 I think that is right? 17:09:08 that's what is in the patch atm 17:09:29 * notmyname is lurking because you mentioned swift 17:09:30 so I just wondered, why don't we install all of the swift client, unmodified 17:10:04 so I thought maybe packaging swiftclient code into the rpm for dom0 would work 17:10:21 but turns out that it also has a dependency of keystoneclient 17:10:26 when using auth v2 17:10:39 OK 17:10:47 which has a few other dependencies 17:10:48 is keystone a problem? 17:10:58 hmm, true 17:11:26 I understand we want to minimize the changes to dom0 17:11:36 do we run yum on dom0, is that something advised? 17:11:38 but it seems better to use the standard swift client, 17:11:55 virtualenv? 17:12:03 good idea 17:12:24 please just quantify here, why would consider it better john? 17:12:24 the only issue is on non python stuff like lxml 17:12:30 sure 17:12:41 basically we have much less code to maintain 17:12:50 matelakat: how much memory do you think it will take additionally? 17:13:29 nikhil: I don't think a virtualenv would cause memory overhead. 17:13:44 so XCP/XenServer doesn't use python 2.6 17:14:01 so installing pure python 2.6 dependencies should be no issue right? 17:14:09 its the extra bits I fear 17:14:18 let me check out the pip requires for keystone client... 17:14:33 johngarbutt: pure python 26 screws up a yum and stuff on dom0 17:14:42 ouch, really? 17:14:50 what happens? 17:14:57 we could not run yum after installing py26 17:15:15 hmm, that sucs, I see your yum question before 17:15:26 what package did you use? the one from EPEL? 17:15:38 right 17:15:46 can we compile stuff within dom0? 17:15:50 I guess the key thing is not to change the default python to 2.6, leave that at 2.4 17:15:58 yes 17:16:00 presumably anyway 17:16:15 So can we compile a python26, and use it separately? 17:16:23 I didn't spot they when I tried it 17:16:39 I was thinking an extra rpm to switch the default back to python 2.4 17:16:42 without disturbing yum? 17:16:53 The epel packages just sit as new pythons - don't replace the 2.4 at all 17:17:03 that is what I remembered 17:17:14 maybe something deeper is breaking yum 17:17:31 OK, well that is a problem for any of the approaches here 17:17:34 doh 17:17:51 #action johngarbutt: ask about yum and python 2.6 packages 17:18:11 the minimal py26 works for the swiftclient 17:18:21 yeah, we just need to see if getting keystone client and things is more trouble than it's worth 17:18:33 spot on 17:18:39 right, again, better than writing our own keystone client though? 17:18:42 #link https://github.com/openstack/python-keystoneclient/blob/master/tools/pip-requires 17:19:06 looks quite small 17:19:08 The effort wouldn't be wasted, if anyone would try to run compute in dom0. 17:19:24 all the more, we were advised against having to install a package on dom0 17:19:33 its a big No No from the Ops 17:19:51 agreed, because of the risk of Citrix saying its not supported, and security risks I guess 17:20:06 right 17:20:16 virtual env could be the answer, and adding permissions and users etc 17:20:31 but it seems overkill 17:20:53 matelakat: don't think dom0 could handle running entire compute on it (from the current experience) 17:21:01 yeah seems like a possibility but really heavy handed 17:21:23 These keystoneclient deps does not seem to be too serious. 17:21:24 another dev had mentioned virtualenv 17:21:30 I think the security risk of bad code due to copy and paste would be bigger than most of the others 17:21:39 johngarbutt +1 17:21:46 but that is just my view, willing to be corrected! 17:21:54 but hw backed from that opinion as some of them were concerned about small memory on dom0 17:22:13 johngarbutt: think keystone is quite fragile 17:22:28 having keystone client would make it worse 17:22:35 the process is very short lived, so it should be OK, but testing is the only well to tell I guess 17:22:44 not sure if can expect security changes from swift anytime soon 17:22:55 you can increase dom0 memory, but obviously that reduces what is left for VMs 17:22:55 right you are 17:23:02 yes 17:23:13 its not just changes right, we have new code that might have its own issues 17:23:30 guess as a Citrix person you would suggest against increasing dom0 memory? 17:24:06 I know Citrix recommends it for XenDeskop customers, for certain density reasons. Newer versions actually have higher defaults 17:24:08 but not sure 17:24:12 for the general case 17:24:12 We're quite happy for dom0 memory to be increased now - in fact it's going to be the default in some scenarios. The only downside is there is a reduction in some blk performances 17:24:53 BobBall: was that only over 2GB of RAM though? or something? 17:25:03 anyway 17:25:07 we got side tracked 17:25:24 well to have to increase the dom0 memory for 1000s of servers might just do some trick in the deployment, i would guess? 17:25:28 yes yes 17:25:34 swift client 17:26:30 can we try and see if that installs OK? 17:26:34 using pip is easiest 17:26:47 pip-2.6 or something like that I gues 17:27:05 if its really bad, then I guess we need to look at something else? 17:27:20 yeah i think this is something to look into 17:27:21 we should be able to run it and see how much memory that process uses 17:27:28 is there another option we aren't considering? 17:27:46 currently the glance plugin just does communication through httplib 17:27:51 so, there was some code from glance in there for chunking, could the swift client not do that for us now? 17:27:58 ah, I guess that answers my question! 17:28:17 I don't understand why glance does that? I guess someone will know 17:28:40 dom0 streams images to glance 17:28:54 so there is an open connection for doing that 17:29:00 yes, it just uses wget I think 17:29:19 I would have to check 17:29:54 I think we could look at using the official glance client if this other stuff goes well 17:30:21 if Dom0 had python 2.6 by default, I am guessing we would not even worry about this 17:30:42 sorry I see httplib 17:30:45 for the upload 17:31:00 yes, however at the same time we would like to avoid installing anything on dom0 17:31:26 are we out of time? 17:31:30 versioning would be another pain, I guess. 17:31:31 if the swift code could be as simple, I guess I would be OK with it. its the chunking stuff that seems working sharing 17:32:01 yeah it would have to be much simpler for me to feel comfortable too 17:32:02 ameade_: we have till 18:00 UTC as normal this week I think 17:32:10 kk 17:32:17 but we should wrap this up 17:32:19 yes, glance is flexible to handle that 17:32:34 off the top of my head i'm not sure how much simpler we can make that code 17:32:38 is there some vote function on here 17:32:43 what are the next steps we have considered then? 17:32:49 #vote 17:32:57 unless a decision has been made, seem unlikely 17:33:01 yeah i dont know how to do it 17:33:09 vote i mean 17:33:28 #startvote 17:33:29 Unable to parse vote topic and options. 17:34:12 what we try to install swift client, and see how bad it is first 17:34:20 please +1 or -1 that 17:34:28 +1 17:34:29 yeah i feel like we should look deeper into both options 17:34:35 starting with installing 17:34:40 +1 17:34:42 so +1 17:34:50 +1 17:34:52 +1 17:34:53 +1 17:35:04 OK 17:35:06 :-) 17:35:19 #agreed try install swiftclient (and keystone client) into dom0 17:35:40 I think that is best 17:35:46 we can then see how bad stuff is 17:35:48 agree 17:35:53 cool 17:36:15 any other concerns with this stuff? it looks good to me really 17:36:35 well another collegue just pointed out 17:37:03 the httplib connection seems insecure, although not in consideration just wanted to put it on the table 17:37:21 insecure for dom0 17:37:52 for glance or swift or both? 17:37:57 anyways, guessing we have our TODOs, do we meet again next Wed? 17:38:07 yes, lets meet every wednesday 17:38:08 in general 17:38:16 you would like https? 17:38:23 however glance is supposed to be an internal deployment and hidden behind nova 17:38:34 I assumed that was internal network 17:38:37 at the moment 17:38:40 https would be too slow if you want to upload 30G image 17:38:42 glance can be external 17:38:55 you'r right 17:39:04 but that usecase for security hasn't come yet 17:39:05 I guess its defence in depth 17:39:11 right 17:39:17 the checksums are probably worth checking 17:39:23 to make sure it didn't get tampered with 17:39:25 I would just like to rewrite a lot of stuff 17:39:35 I can understand that! 17:39:38 story of my life 17:39:39 those are checked in glance and swift 17:39:47 checksums 17:39:52 I like the boy scout rule 17:40:06 make sure stuff is better after every checkin 17:40:08 :-) 17:40:12 anyway 17:40:13 me too but people dont like random improvments in merge props 17:40:14 lol 17:40:16 I guess we are finished 17:40:24 thanks 17:40:26 thanks! 17:40:26 #topic aob 17:40:37 anything else? 17:40:48 ameade_: feel free to submit "random improvements" into python-swiftclient :-) 17:40:59 ameade_: yes, but you can impove stuff in separate checkins 17:41:03 +1 17:41:29 definitely, just find me some time! 17:41:46 OK, some extra love for the OVS reviews seems worth bringing up again, I guess 17:41:55 but looks like that is getting closer now 17:41:59 see you all next week 17:42:02 thanks for your time 17:42:06 I hope it helped! 17:42:09 #endmeeting