09:31:44 #startmeeting XenAPI 09:31:45 Meeting started Wed Aug 5 09:31:44 2015 UTC and is due to finish in 60 minutes. The chair is BobBall. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:31:46 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:31:48 The meeting name has been set to 'xenapi' 09:31:56 Morning johnthetubaguy 09:32:08 hello 09:32:31 We can also say good morning to jianghuaw 09:32:48 And is John or Huan also here? 09:33:00 hello 09:33:20 Agenda at https://wiki.openstack.org/wiki/Meetings/XenAPI as usual 09:33:36 #topic Blueprints / Reviews 09:33:46 OK - so - johnthetubaguy the first is a question for you really 09:33:53 Welcome huazhihao 09:34:04 :bobball Thank you. 09:34:11 We've found there are some bugs running XenAPI in a HVM guest 09:34:16 and lots of people are trying to do this 09:34:44 Yes 09:34:45 We need to fix those - do we have to raise a BP or are these justifiable as bugs or 'features without BPs' since it's very clear what we're trying to do? 09:35:37 huazhihao / jianghuaw is Huan joining us? 09:36:13 johnthetubaguy: What are your thoughts on that? 09:36:26 johnthetubaguy: (the BP question - not Huan :) ) 09:36:36 sounds like a bug fix 09:36:44 OK, good. 09:36:57 it is bug triage day today, if that helps 09:37:00 bobball: She is disconnected because of some unknown reasons. 09:37:07 Can I also introduce jianghuawwho is the second team member in Nanjing 09:37:26 Huan is the third team member but she's not online at the moment 09:38:05 huazhihao / jianghuaw: johnthetubaguy is the current Nova PTL, ex Citrix employee and one of the largest contributors to the XenAPI driver 09:38:34 cool, good to meet you all, welcome to Nova! 09:38:44 OK, well if we don't need a BP then I'm happy. We'll add some bugs + fix them as we get to them. 09:38:47 Already have one bug raised 09:38:55 Speaking of nova bug triage day... 09:38:58 #topic Bugs 09:38:59 hi johnthetubaguy 09:39:08 #link https://bugs.launchpad.net/nova/+bug/1204631 09:39:08 Launchpad bug 1204631 in OpenStack Compute (nova) "Image created from boot from iso missing min_ram and min_disk" [Low,Confirmed] 09:39:08 the reviewers may think otherwise, but it feels like a bug fix to me 09:39:12 This bug is one that claims it may be fixed 09:39:18 Launchpad bug 1204631 in nova "Image created from boot from iso missing min_ram and min_disk" [Low,Confirmed] 09:39:19 Launchpad bug 1204631 in nova "Image created from boot from iso missing min_ram and min_disk" [Low,Confirmed] https://launchpad.net/bugs/1204631 09:39:21 I thought you might have some insight into whether you agree it's fixed 09:39:39 From looking at the code I suspect it has been fixed 09:39:45 so I'd be happy to just close it 09:39:55 but I know that RAX has been more involved in the boot from iso work 09:42:50 johnthetubaguy ? :) ping! 09:43:03 sorry, I am having lots of pings right now 09:43:32 I have no idea if thats fixed, we don't really use that feature much 09:43:45 I'll close it based on the code review then 09:43:56 OK 09:43:59 #topic Open Discussion 09:44:03 they can always reopen I guess 09:44:10 in stack.sh in devstack there are references to tty.gz 09:44:18 These are XenServer specific 09:44:25 but I have no idea what they are for or why they are there 09:44:29 Do you have any clue? 09:44:33 do you have a link? 09:44:45 They were added in the original commit to devstack by rackspace 09:45:19 10:43 < johnthetubaguy> sorry, I am having lots of pings right now 09:45:19 10:43 < johnthetubaguy> I have no idea if thats fixed, we don't really use that feature much 09:45:26 Sorry - wrong paste! 09:45:32 That was just from me clicking the screen out of habit 09:45:36 http://git.openstack.org/cgit/openstack-dev/devstack/tree/stack.sh#n1190 09:45:58 I have no idea what "UPLOAD_LEGACY_TTY" is for 09:46:19 isn't that the image file? 09:46:35 An image file for what though 09:46:44 We don't use it anywhere as far as I can tell 09:46:46 I thought for booting from 09:47:11 Yes - but why do we need a tty aki+ami image? 09:47:26 What's the purpose of the image in general 09:47:40 I think it was just the first one that was added, as the only image that worked 09:47:49 like the xenserver specific one 09:47:58 Ah ok 09:48:06 So we can remove it now we just use cirros? 09:48:20 I would have thought so 09:48:30 hi huanxie. johnthetubaguy - this is huan, the final team member in Nanjing 09:48:52 OK - I will raise a ticket to remove it then 09:48:56 huanxie, welcome to nova! 09:48:56 Next question... 09:48:56 hi 09:49:03 Separation of plugins 09:49:18 We have a vaguely useful plugin version identifier in nova now 09:49:33 How would you feel about separating the plugins from nova to a different repo on stackforge? 09:49:42 seems like a bad idea 09:49:55 The main reason I'd like to do this is to make a clear distinction for develpoment so we can rely on the plugin versioning information 09:49:57 they are required to run Nova, and basically Nova ocde 09:50:16 why not use the Nova versioning for the deployment? 09:50:46 You mean remocve the current plugin version? 09:50:50 no 09:51:00 just use the nova version for the deployment 09:51:25 the version is just an internal interface protection system really 09:51:43 we don't make nova-compute deploy using the manager RPC version right? 09:51:56 Right 09:52:08 Let me explain what I would ideally like 09:52:27 My ideal would be for Nova to install, over XenAPI, the correct version of the plugins 09:52:53 This would clearly need to work for dev versions, so the 'nova version' wouldn't cut it for that 09:53:07 the nova version has a dev version already 09:53:15 each commit has its own version, I believe 09:53:48 Uhhh how? If someone has downloaded the tgz (i.e. no git repository) then Nova can't know what its version is 09:53:51 can it? 09:54:01 not quite sure how that works 09:54:35 And I'm sure that using nova to query git would be rejected ;) 09:55:19 Is it worth raising a BP to discuss or are you dead set against separating the plugins out? 09:55:38 you could, it doesn't sound right to me 09:56:00 Ok - final topic. Sorry for taking so long huazhihao 09:56:05 we can add stuff to make packaging easier 09:56:07 #topic Mirantis Plugin 09:56:17 Can you give us a brief update on what's working with the fuel plugin 09:56:22 and what the next steps are? 09:56:54 SUre 09:56:58 Sorry 09:57:45 The automation has covered most of tasks 09:58:17 Great - btw johnthetubaguy - next meeting we hope to have an update on Neutron integration (not a working solution, just something to discuss!) 09:58:44 OK, cool 09:58:52 have you reached out to the rackspace folks about that? 09:59:24 Yes - at the last summit 09:59:33 who did you talk to? 09:59:48 Long story short, we can't use quark in the short term so will be focusing on ml2+ovs 10:00:01 Some of the quark devs + andy hill 10:01:00 OK, we should probably catch up about they why at some point, but snowed under right now 10:01:20 so huazhihao - the update I guess is that we have a workable user interface story and a plugin that will install; now we're focused on automating the xenserver customisation in the post-install tasks 10:01:24 is that right? 10:01:38 Exactly 10:01:59 Sorry my typing is slow. 10:02:06 OK 10:02:18 not sure what you mean by user interface story, but I guess thats for next time 10:02:21 Sure johnthetubaguy - short version is that there is a bunch of stuff that quark depends on in udev rules etc that are not open source and are highly custom to rackspace's environment. We might want to get those open + updated to work in other environments too. 10:02:47 The other issue is that Mirantis OpenStack already has good supprot for ml2+OVS so it's a lot easier to integrate with that point 10:02:48 yeah, that was my thinking, no reason for those to be closed 10:03:03 if it works, and is easier, thats cool 10:03:07 User interface story = it looks good :) 10:03:13 Anyway, we're 3 minutes over now 10:03:21 so we'll end the meeting here. 10:03:23 #endmeeting