15:00:53 #startmeeting XenAPI 15:00:54 Meeting started Wed May 8 15:00:53 2013 UTC. The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:58 The meeting name has been set to 'xenapi' 15:01:06 hello, everyone 15:01:13 who is around for the meeting? 15:01:28 * BobBall is 15:01:45 hi 15:01:46 Not sure if Mate can join us tod... hi Mate 15:01:53 cool 15:02:03 I will be here, just in case :-) 15:02:10 * johnthetubaguy will be back in 30 seconds 15:02:21 anyone got things they want to add to the agenda in the wiki? 15:02:33 #link https://wiki.openstack.org/wiki/Meetings/XenAPI 15:02:53 i'm here 15:02:55 also note the additional info about how we organise the group, will bring that up in the open disscussion 15:03:04 toanster: hey! 15:03:09 I think it's worth mentioning, that I created a blueprint to clean-up xenapi code in devstack. 15:03:23 I added you guys to that bp. 15:03:24 Could wait until the blueprints section for that Mate ;) 15:03:29 Sorry. 15:03:33 But that's fine! 15:04:22 I guess the Agenda needs updating - it's still got some stuff from the last meeting hasn't it? 15:04:36 yup, my bad 15:04:51 well, lets get cracking 15:05:02 #agenda blueprints 15:05:16 #topic blueprints 15:05:25 so, we had a good summit session 15:05:37 #link https://etherpad.openstack.org/HavanaXenAPIRoadmap 15:05:54 I skipped stuff from the last meeting, it was too long again 15:06:10 agreed 15:06:17 There are lots of blueprints 15:06:33 BobBall and matelakat recently signed up to quite a few 15:06:55 are the any more that people don't see as target for havana, but really should be? 15:07:22 I think the main issue for Havana is getting the quantum+OVS integration working 15:07:27 let me see if the devstack one is targeted properly 15:07:32 which isn't a blueprint(?) but is something that we're looking at too 15:07:52 should it be a blueprint? 15:07:55 #link https://blueprints.launchpad.net/devstack/+spec/xenapi-devstack-cleanup 15:08:04 I guess it is in quantum? 15:08:14 Not just quantum. 15:08:35 Probably not. The Quantum integration is more of a bug than a blueprint-needed? I thought blueprints were for things that needed tracking+discussion on implementation? 15:08:51 well, it probably needs docs and stuff 15:09:01 Sorry Mate - I guess we're talking at cross purposes atm! 15:09:07 and it is a feature to be mentioned when the release goes out 15:09:11 oh, not a nova blueprint 15:09:16 *nod* 15:09:16 Could you guys fire up a browser, and see if that bp is targeted or not? 15:09:23 it is not targeted 15:09:23 its not 15:09:30 I can't see Havana anywhere 15:09:41 Which field needs to be set? 15:09:42 not sure devstack use blueprints like you would hope 15:09:56 series goal should be havana, but its quite project specific 15:10:06 I wouldn't worry for now 15:10:24 Ok… so back to quantum support 15:10:32 how it that looking? 15:10:38 Yes, I am looking at it. 15:10:47 any update worth sharing? 15:11:15 Probably just that the instructions don't seem to work :) 15:11:31 OK, I guess stuff changed, or its broken 15:11:38 A rebase will be needed. 15:11:46 Probably some setup that Maru had that doesn't match our setup 15:11:53 I am on it, expecting to have something this week. 15:11:53 OK 15:11:56 Mate hasn't got to the bottom of it yet though 15:12:00 no worries 15:12:13 It's again the exotic network setup. 15:12:19 so, I wanted to raise the blueprints we are tracking for Havana 15:12:23 However, I am just getting rid of that. 15:12:36 OK 15:12:37 He's not allowed to eat until he's figured it out though, so I'm sure we'll get the answer soon. 15:12:46 I am starving. 15:12:54 lol 15:13:07 your new wife is very harsh... 15:13:10 anyway... 15:13:17 #link https://blueprints.launchpad.net/nova/+spec/xenapi-move-driver-to-oslo 15:13:23 ok - drive away John. I guess we should look at https://blueprints.launchpad.net/devstack/+spec/xenapi-devstack-cleanup to make sure we all agree with the plan too - even though it's not a nova blueprint :) 15:13:26 mate has taken this one 15:13:42 OK, lets have a quick look at devstack 15:13:46 we didn't cover that in the summit 15:13:57 I can do that, the issue is the review speed 15:14:06 That kills me. 15:14:43 yup, I hear you 15:14:44 yeah... takes ages to get people to review and there are far too many minor -1's! 15:14:59 too many cooks, coding by compromise and all of that ;) 15:15:01 well, I am for clean code, but yes, I hear you 15:15:22 the problem is that code is such a mess its hard to concentrate 15:15:25 but anyway 15:15:27 the approach 15:15:39 not sure I understand where the blueprint is talking 15:15:45 separate stuff out? 15:16:09 The expected output is a usable devstack 15:16:15 indeed - so Mate want's to simplify the XenAPI devstack process - but it'll probably contain some ugly bits of code too, even though it'll be an improvement on what's there at the moment. 15:16:31 OK, but whats the approach? 15:16:53 Isn't it on the bp? 15:16:57 I see you list the steps 15:16:58 Do we need to discuss it? 15:17:08 do you mean the steps or the work items? 15:17:12 just want to make sure expectations are good 15:17:26 It's like you touch here, and you see soo many things, that you just can't resist cleaning it up. 15:17:38 so you pulling it out into a separate file? 15:17:55 the hypervisor bit vs VM creation, etc 15:18:15 Separate files/ functions, doesn't matter. 15:18:22 Make those steps visible 15:18:23 its just devstack was meant to be a very simple single script people can read as an example way to set things up 15:18:30 Make the code readable. 15:18:34 any clearly things have moved a bit since then 15:18:59 OK, that all good, just its was designed as lightweight scripts, not super DRY code 15:19:11 I agree there is lots to do 15:19:20 was just wondering what you planned to focus on 15:19:28 you mention the variables and the settings 15:19:45 it would be good to shake those into something more sensible 15:20:17 I think as you suggested: more visible data flow 15:20:30 OK 15:20:36 I don't want to over-architect the stuff. 15:20:43 maybe we should just see code, I will review the change you posted 15:20:50 lets move on 15:20:54 So at the moment kicking the tyres, and doing the tidy-up. 15:20:56 ok, thanks. 15:21:12 we mentioned oslo split out 15:21:19 mate was taking that H-2 timeframe 15:21:26 we discussed that at the summit 15:21:28 all seems 15:21:29 good 15:21:33 moving on... 15:21:46 #link https://blueprints.launchpad.net/nova/+spec/xenapi-compute-driver-events 15:21:59 using events to help update db and parent cell quicker 15:22:13 bobball took that one, for H-2 15:22:22 again, that all seems good? 15:22:31 I did - but my understanding is it's a nice-to-have 15:22:38 Priorities might push it to H-3 15:22:59 Indeed, I think so 15:23:06 maybe move it to H-3 15:23:15 OK, next... 15:23:20 I'd like to leave it at H-2 for now though 15:23:23 OK 15:23:28 #link https://blueprints.launchpad.net/nova/+spec/xenapi-guest-agent-cloud-init-interop 15:23:47 Rick harris and I are trying to get cloud-init and config drive working better with XenAPI 15:23:54 basically making the agent more optional 15:24:01 like per VM or per image optional 15:24:04 Brilliant - did you see the email thread on -dev about config drive? 15:24:21 probably not yet… if it was recent 15:24:28 subject "making file injection optional / removing it" 15:24:46 Started talking about baremetal - but now moved onto config drive and fun things like that 15:24:47 Yeah, that could be related. 15:25:06 oh, OK, its related 15:25:09 just thought you'd probably want to reply, given what you're doing, so bringing it to your attention :) 15:25:25 cool, thanks, not read through that all yet today 15:25:30 bug day fun 15:25:31 file inject/agent/configdrive trinity 15:25:40 indeed, its a fun thing 15:25:47 my view is cloud-init and cloudbase-init 15:26:00 then make an extra agent for password without reboot if really needed 15:26:15 maybe extend cloud-init to do licence stuff 15:26:17 etc etc 15:26:29 anyways, we are on the case 15:26:32 :-) 15:27:02 … so stuff that is on the maybe list 15:27:12 #link https://blueprints.launchpad.net/nova/+spec/xenapi-server-log 15:27:24 we need to decide if we want the server log in XenAPI 15:27:39 I am tempted to kill it, or at least make the client discover if it is available 15:28:02 client discover? 15:28:03 but it looks like there is a xenstore key + logrotate that could make it all work 15:28:14 nova-client can find out if the feature is enabled in the cloud 15:28:24 part of the nova v3 API work 15:28:30 well it could be, anyway 15:28:32 Oh right - because we just return a dummy console log atm 15:28:41 yup 15:29:03 it could be an extention that is enabled or not 15:29:06 anyways 15:29:23 I don't like the idea of filling up dom0 disk if a guest gets very chatty 15:29:31 and there are some funky ways around that 15:29:40 Do you know how that works in the KVM world? 15:29:59 ... or A.N.Other hypervisor's world that supports console log :) 15:30:21 libvirt manages most of it, but I need to look closer 15:30:30 libvirt may have code for xen anyways 15:30:44 ah - so perhaps libvirt treats it as a ring and only returns those lines directly. 15:30:44 I have put it on my pile, but not targeted it for H 15:30:50 so if others want it, ping me! 15:30:56 lets move on... 15:31:07 #link https://blueprints.launchpad.net/nova/+spec/xenapi-vif-hotplug 15:31:22 #action we need a volunteer for xenapi-vif-hotplug 15:31:32 if we want it done in H 15:31:40 its a gap we have vs libvirt 15:31:56 its seems more important / useful than some of the other gaps 15:31:56 shoudl use #help for this one :) *been reading the meetbot commands* 15:32:03 #help need a volunteer for xenapi-vif-hotplug 15:32:09 oh cool, I forgot about that one 15:32:49 no one fancies it here I guess? 15:33:04 It's not that I don't like it. 15:33:07 It's the tome. 15:33:09 time 15:33:13 well according to the current plans, there will be loads of us free in H-3 15:33:17 lol 15:33:25 OK, lets move on from blueprint 15:33:32 indeed 15:33:32 unless people have something else? 15:33:43 we should have time by H-3 but it's impossible to commit atm 15:34:07 so, going forward I would love to see progress reports in this meeting 15:34:11 but code is good too... 15:34:24 #topic docs 15:34:24 *continues to read meetbot logs* 15:34:26 #chair BobBall 15:34:32 mean 15:34:38 no - you're permanent chair 15:34:49 I guess I could probably transfer 15:34:51 I was testing if we could then use this when someone's nick goes 15:34:52 no 15:34:56 I don't want it :) 15:35:01 #chair matelakat 15:35:03 hehe 15:35:10 so, docs 15:35:10 doesn't seem to work anyway 15:35:10 wow 15:35:13 maybe you have to do it john 15:35:14 yes - docs 15:35:16 any updates? 15:35:21 I suspect it has to be me 15:35:30 No updates on docs side 15:35:38 me neigther 15:35:42 the docs don't say so http://meetbot.debian.net/Manual.html - so maybe we need an action to update the meetbot docs! 15:35:49 #topic Bugs and QA 15:35:58 so its bug day 15:36:03 but smokestack 15:36:07 any news on how that is going? 15:36:17 I haven't poked Dan or Ant on it 15:36:27 I've got a timed action to poke Dan by the end of this week for his backup task 15:36:32 #action BobBall to poke Dan and Ant 15:36:39 cool 15:36:53 I guess it is post quantum work? 15:37:12 We're blocked on Ant re-installing with 6.1 (which is blocked by Dan backing up the VM) - but yes, it's post-quantum, which is why I haven't been pushing uber hard 15:37:29 gotcha 15:37:33 its bug day 15:37:37 I did some triage 15:37:43 working on a few little fellas 15:37:44 Happy Bug Day! 15:37:59 I was not doing bugs today. 15:37:59 matelakat: what does your magic bug finder tell us? 15:38:07 I must confess. 15:38:12 can we have the URL again? 15:38:22 you can, but it's outdated. 15:38:55 I also helped John with a couple of them, and worked on some potential bugs that haven't been reported yet - in XenAPI but reported by rackspace and trying to identify whether they are XenAPI or OpenStack "bugs" 15:39:08 #link https://github.com/citrix-openstack/bugstat/blob/master/bugreport/main_report.md 15:39:24 I will update it for the next time. 15:39:48 +1 thanks for your help on those 15:40:09 cool, so I just used the tagged bugs 15:40:15 #action matelakat to update https://github.com/citrix-openstack/bugstat/blob/master/bugreport/main_report.md :) 15:40:15 tagged with xenserver 15:40:24 I will take a look at the others sometime 15:40:39 #action matelakat to document bug finder in XenAPI team wiki 15:40:45 cool 15:40:50 any more for any more? 15:40:58 * johnthetubaguy checking bug list... 15:41:27 Thanks for the actions. 15:41:30 OK, no more news for me 15:41:39 hey, what are friends for :-P 15:41:50 You were looking bored Mate. 15:41:57 And if you have such friends, you don't need enemies. 15:42:09 :) 15:42:09 you took the works out of my… keyboard 15:42:19 so, moving on 15:42:39 #topic AOB 15:42:44 any other bussiness... 15:42:52 I think the silly english term 15:42:56 like^ 15:42:57 lol 15:43:00 bad keyboard 15:43:12 so, sub team, it turns out we are sub team 15:43:19 no need to panic... 15:43:22 nothing changes 15:43:38 I tried to document what we do in the wiki 15:43:41 except other people are now copying us :( haha 15:43:45 hehe 15:44:06 Next meeting? 15:44:12 you mean like people who sell non-opensource hypervisors 15:44:22 bi weekly? 15:44:36 well I would be keen on keeping it weekly for the rest of May 15:44:43 and see if there is any content in the meeting 15:44:48 then move to bi weekly? 15:44:48 I didn't realise there were other non-opensource hypervisors ;) 15:45:15 BobBall: you must have the Citrix goggles on 15:45:36 we can try next week, and see how it goes? 15:45:41 I have, indeed, dunk the kool-aid. 15:46:06 I am keen there is somewhere for users to drop in an annoy the dev team 15:46:09 I think next week we'll talk through the bugs and probably have a decent amount to talk about on Quantum? 15:46:15 so next week should be fine. 15:46:19 that seems fair 15:46:25 OK 15:46:31 well, I good doing it week by week 15:46:53 okiedokie 15:46:53 I am good with us voting at the beginning of the meeting to not have the meeting 15:47:00 it only takes 2 mins 15:47:06 Damn. Wish I knew that at the start of this meeting. 15:47:09 should not be too disruptive 15:47:09 Please, don't. 15:47:18 don't what? 15:47:25 the voting. 15:47:29 why? 15:47:45 I mean, OK, if you want it, OK. 15:47:55 I was just joking. 15:47:58 simple check to see if the agent is empty, and one has anything 15:48:06 lol 15:48:14 are we all good? 15:48:16 y 15:48:22 I'm better than good 15:48:26 I have a question... > 2TB disk.. is it just a limitation with xenserver or kvm and others as well ? 15:48:36 VHD limitation I think 15:48:39 the >2TB disk is a VHD limitation 15:48:40 indeed 15:48:42 other may have it too 15:48:44 isn't it the partition table? 15:48:47 do you know the qcow2 limitation? 15:48:52 nope 15:48:56 partition table can be fixed using gpt 15:48:57 * johnthetubaguy googles... 15:49:07 ok cool thanks guys 15:49:24 looks like qcow2 uses a 64-bit integer for the size 15:49:30 has anyone thought about creating > 2TB disk on vms.. ephemeral or otherwise 15:49:54 yes rnirmal - but the only way to do that if you're using VHD-backed storage is to use raid in-guest 15:50:00 not seen anyone try 15:50:14 what about raw LVM? 15:50:21 hmm 15:50:32 you could use that for ephemeral I guess, or PCI passthrough 15:50:43 but that will have to be done outside of nova provisioning right ? 15:50:49 but obviously you need to do things like scrub disks when passing between tenants 15:50:57 indeed 15:50:57 well one could change nova to cope with it 15:51:15 ephemeral are just empty, so that bit is easy ish 15:51:35 so we are using ephemeral disk.. and want to create more than 2 TB 15:51:46 you could do raw files (loop back) inside the EXT SR 15:51:54 and create them inside nova 15:52:01 but it is a code change 15:52:06 how would I do that.. ah ok 15:52:23 * johnthetubaguy looking for git hub link... 15:52:52 https://github.com/openstack/nova/blob/master/nova/virt/xenapi/vm_utils.py#L867 15:52:57 for my usecase.. even if I can get multiple disks attached amounting to the total size is acceptable as well 15:53:13 I think you can use dd to create a raw file of the correct size (could take some time) 15:53:20 then call it .raw, or something like that 15:53:29 then it gets picked up by xapi, I think 15:53:41 but not 100% sure, never tried it 15:53:56 johnthetubaguy: hmm ok let me explore that option. 15:54:01 I know that it's possible to have multiple disks attached to get to the total size. "Support limits" say you can only attached 7 disks (should be 15) - but actually you can attach more as long as you've got PV drivers installed and specify the device number 15:54:19 well, you can do a big raw file though? 15:54:25 not VHD limit on that 15:54:28 no^ 15:54:37 Sorry, yes. Probably. 15:54:45 although how does that get mounted? 15:54:48 would the performance be the same 15:54:54 or more or less same 15:55:01 no idea, I have to admit, it could be better 15:55:07 you would have to try it 15:55:11 FileSR is VHD backed 15:55:38 it is, but I was told of an easter egg in those file types that detect .raw files, or something like that 15:55:39 raw (if we have the SR for it) would be faster than VHD because it would have to skip some of the overhead. 15:55:43 ahhh okay 15:56:00 yep, who knows what else might break 15:56:13 but it should just about meet the ephemeral use case 15:56:22 cause it is created blank 15:56:22 johnthetubaguy, you're right - FileSR does identify a "raw" file extension 15:56:33 I thought I read that in there 15:56:38 its "special" 15:56:46 so create the file, copy in, sr scan 15:56:49 and booom 15:57:19 Agreed. 15:57:35 booom being possible success and possible hose your whole system 15:57:36 ok cool.. thanks everyone this has been helpful.. I'll try some of the mentioned options and get back 15:57:51 cool, catch us on IRC 15:57:57 openstack-nova 15:58:14 so, sounds like everything? 15:58:18 or next week during the normal xenapi surgery hours! 15:58:23 lol 15:58:25 yes 15:58:41 actually rnirmal, some of us are more likely to be around on #xen-api and there are other funky people there who can help too 15:58:49 good point 15:58:56 BobBall: thanks I'll hop in there as well 15:58:58 that is probably better for that kind of hacking 15:59:26 #action johnthetubaguy to mention #xen-api on the team wiki 15:59:31 #endmeeting