17:01:01 #startmeeting XenAPI 17:01:02 Meeting started Wed Jan 9 17:01:01 2013 UTC. The chair is johngarbutt. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:05 The meeting name has been set to 'xenapi' 17:01:23 #topic Blueprints 17:01:31 Hi everyone! 17:01:38 hello 17:01:40 hello 17:02:05 morning! 17:02:15 cool, so before we start 17:02:25 has anyone got things they would like to cover? 17:02:39 lets build an agenda 17:02:48 Hi 17:03:04 Okay, so cinder - xenapinfs - copy from image. 17:03:34 idea: use the same code as in iscsi. 17:03:44 Just attach the volume to the cinder box. 17:03:47 I had a few questions (not really agenda items) that I wanted to ask at the end 17:03:48 OK, lets start with that blueprint 17:03:54 pvo: cool 17:04:43 hello 17:05:03 I amended the xenapi-storage-manager-nfs blueprint to include that idea. #link https://blueprints.launchpad.net/cinder/+spec/xenapi-storage-manager-nfs 17:05:28 After that, we'll have a really complete volume driver for xenapi. 17:05:41 matelakat: that one is marked as finished, might want a new one for the rest 17:05:52 pvo, thanks for reminder 17:06:00 Oh, ok. 17:06:08 Do #link's need to be put at the start of the text for the bot to recognise them? 17:06:19 will start a new one. 17:06:20 hello 17:06:27 matelakat: any major questions? 17:06:35 pending reviews etc 17:06:42 oh, yes. 17:07:10 #link snapshot-support-for-xenapinfs https://review.openstack.org/#/c/18780/ 17:07:47 OK 17:08:10 any more blueprint updates or pending reviews or burning questions about that kind of thing? 17:08:26 no. 17:08:44 I know there is Quantum OVS, if anyone feels they could take a look 17:09:13 #link https://review.openstack.org/#/c/15022/ 17:09:57 johngarbutt: got your note. Will take a peek. 17:10:09 pvo: thank you ! 17:10:47 any more blueprint things? I saw config drive was coming along 17:10:52 hi, I have a quick update on the blueprint hbase-storage-backend 17:11:23 shengjie: fireway have you got a link? 17:11:53 https://blueprints.launchpad.net/ceilometer/+spec/hbase-storage-backend 17:12:15 we've pretty much finished the 1st phase implementation, will have it committed for review soon. 17:12:31 but to have better performance, hbase will need extra 2ndary indices 17:12:42 hang on, sorry, I am probably missing something 17:12:53 does that affect the XenAPI support in Ceilometer? 17:13:10 The Ceilometer meeting is meant to be at 15:00 UTC 17:13:14 on Thursday 17:13:36 the ceilometer xenapi blueprint link is https://blueprints.launchpad.net/ceilometer/+spec/xenapi-support 17:13:45 my bad, I meant XenAPI related blueprints in previous bit 17:14:13 sorry, my bad 17:14:26 thanks, no progress reported there :-( 17:14:44 one other change I noticed, text console support for XenAPI from Internap 17:14:59 #link https://review.openstack.org/#/c/17959/ 17:15:29 might interest people using horizon, it looks bad without this support 17:15:53 OK, shall we move to docs? 17:16:30 y 17:16:37 #topic docs 17:16:50 #link http://wiki.openstack.org/HypervisorSupportMatrix 17:16:55 I have updated this 17:17:01 any more ideas welcome 17:17:29 we have quite a lot of pending doc bugs, is there anyone with a bit of time for those? 17:18:28 #link https://bugs.launchpad.net/openstack-manuals/+bugs?field.searchtext=xenapi 17:18:45 OK, just wanted to raise that 17:18:59 #topic qa 17:19:25 we have spoken about getting some tests, above and beyond smokestack, reporting into gerrit 17:19:43 is that still on anyones roadmap? 17:20:13 update from Citrix: internal CI is almost back up, based on DevStack 17:20:31 johngarbutt: our QA folks are looking at that now. 17:20:35 Not sure about their timeline though. 17:20:41 #link https://github.com/citrix-openstack/qa 17:20:44 I can point you to the right folks, if you're interested. 17:21:07 pvo: cool, might be good, just to make sure no one else tries the same think 17:21:19 I know internap were interested at one point too 17:21:58 Citrix have tempest running against XenServer using DevStack using jenkins plus the above scripts, if that helps people 17:22:23 #topic bugs 17:22:33 OK any major bugs for people? 17:23:22 #topic Open Discussion 17:23:30 pvo: fire way 17:23:39 away^ 17:24:15 it was a quick question really,… I was wondering if anyone using XenServer/XCP uses the metadata service or xenstore? 17:24:21 to pass data to instances. 17:24:21 also, any other questions or issues people would like to raise? 17:24:49 i've got a question, but i think pvo might be beating me to it 17:24:49 We have tested the metadata service with nova-network and flatdhcp 17:24:55 it seemed to be working 17:25:09 with cloud-init picking up things 17:25:12 johngarbutt: ya, the dhcp part is always the sticking point for us. 17:25:20 we don't use DHCP, so there is the chicken-egg thing 17:25:26 right 17:25:36 link local address any good? 17:26:06 Could you briefly explain the chicken+egg thing for my benefit? 17:26:06 johngarbutt: ya, that is where our conversations usually drift to. We'd talked some time ago about an ipv6 link local, but got some pushback here for that. 17:26:26 BobBall: well, assumign we're not using linklocal addresses, we need a valid ip to talk to a metadata service. 17:26:30 config drive could be helpful alternative, but again, no metadata service at that point 17:26:39 ah of course 17:26:47 so we use xenstore to inject the ips, but if we're already halfway there with some data, we end up putting it all there. 17:26:50 BobBall: metadata service is on an IP address, so you need the vif up 17:26:52 I think the general direction is configdrive + metadata service 17:27:07 westmaas: ya, i was hoping to just copy someone's config : ) 17:27:07 config drive for ip address? 17:27:22 configdrive for boot time data, metadata service for ongoing data that you need access to from the instance 17:27:28 johngarbutt: I'm not so clear on that, sorry :) 17:27:38 johngarbutt: how about root password setting with windows? 17:27:40 hmm, metadata is fairly one shot at the moment with cloud init 17:27:47 thats always ends up killing the config drive convo 17:27:54 and I more meant not xen specifically, but OS wide 17:28:06 agreed 17:28:17 I think most people think about a reboot to reset the password 17:28:27 cloud-init could re-read on reboot 17:28:31 in v3 of the api you can't set the password 17:28:33 I believe. 17:28:38 extension time 17:28:40 :-( 17:28:47 johngarbutt: yea, that is what I proposed back in the Bexar timeframe…. 17:28:55 got some resistance to that idea then 17:28:58 or abandon that feature 17:29:09 just windows becomes a problem 17:29:11 vish seemed more keen in that summit XenAPI session on reset on reboot 17:29:20 we have cloud-init in windows now I think 17:29:23 I think its reasonable to reboot an instance to reset a root password, but since people are used to not rebooting it may be a harder sell. 17:29:23 or very close 17:29:30 so weve been trying to figure out a way around it 17:29:41 we could have xenstore kick cloud-init? 17:29:55 xen specific but not changing the core functionality 17:29:58 johngarbutt: ah, hadn't seen cloud-init in windows yet 17:30:00 that would be helpful. 17:30:13 hyper-v guys mentioned somehting about that 17:30:22 not sure if it is ready for prime time yet though 17:30:22 is that in openstace github or just on the internets somewhere? 17:30:31 openstack… that would have been 17:30:34 ok 17:30:37 will check that out 17:30:42 pvo: not sure, would have to google 17:31:11 I guess there meeting might be a good place, if peter is not around 17:31:13 johngarbutt: ya, doing that now. will find 17:31:18 pvo: cheers 17:31:38 oh yeah mikal mentioned that to me too 17:31:46 so xen specific extension to cloud-init, does that sound bad? 17:32:10 to kick the standard on reboot password system 17:32:22 http://www.cloudbase.it/cloud-init-for-windows-instances/ 17:32:29 the key requirment from HP was around ensuring they were never in a position to decrypt the password 17:33:03 johngarbutt: yea, that part I was trying to figure out too. 17:33:07 I meant alexp not peter, oops 17:33:09 #link https://github.com/alexpilotti/cloudbase-init 17:33:11 yeah thats why we stopped storing it a while ago, but still there is the time its in transit 17:33:13 curious to how they're solving it 17:33:20 pvo: it was ssh keys I think 17:33:25 on windows? 17:33:28 but not for windows :) 17:33:28 haha 17:33:29 yea 17:33:31 they injected key used to encrypt a generated password 17:33:51 if msft would just embrace openssh… 17:33:54 well, any key will do I guess, just make sure the user is the only one with the private bit 17:34:18 any symetric key thingy I guess 17:34:34 DH works, but you need to bounce the messages back and forth. 17:34:45 which is what we were looking at the metadata service *could* do. 17:34:45 that is what you do now right? 17:34:49 but felt the wrong way. 17:34:51 ya, thats all. 17:34:53 right 17:34:59 the gentleman yields the floor 17:35:11 can we not use the keypair, like an ssh key somehow 17:35:30 user creates key, adds key to instance 17:35:37 I'm sure we could with something custom in windows 17:35:38 normally crazy becuase it is windows 17:35:40 for linux, its all solved. 17:35:47 right 17:36:04 trying to think about kerberos and ssl apis they have already 17:36:15 .NET includes the tools for this I think 17:36:28 I'm wintarded, so I have no idea. 17:37:08 pvo: cloud-base may have done this already 17:37:14 reading the readme for windows cloud init 17:37:21 looking through it now 17:37:27 uses ssh key and password 17:37:40 time to xen extend it maybe 17:39:06 hmm 17:39:12 they don't encrpyt it yet 17:39:13 https://github.com/alexpilotti/cloudbase-init/blob/master/cloudbaseinit/plugins/windows/createuser.py#L47 17:39:21 they optionally generate it though 17:39:46 sounds like they have installed openssh or something 17:39:49 #link https://github.com/alexpilotti/cloudbase-init/blob/master/cloudbaseinit/plugins/windows/sshpublickeys.py 17:39:52 they inject the keys 17:40:05 heh. that would be a fun fight to have again. 17:40:29 I see a fun summit session coming up 17:40:40 we have that talk twice a year : ) 17:41:00 ah, hello 17:41:27 alexpilotti: how does the change password work in cloudbase-init? 17:42:15 johngarbutt: hi! 17:42:30 johngarbutt: you mean the admin_pass in the metadata? 17:42:38 alexpillotti: sorry to drag you into an XenAPI meeting 17:42:42 yes that is the one 17:43:06 are there plans for encrypting that password? 17:43:16 johngarbutt: there's also anew patch from vishy to push the patch from the guest to the metadata 17:43:31 johngarbutt: that's the way we want to take 17:43:47 johngarbutt: to push the password, sorry, lapsus :-) 17:44:01 OK, push an encrypted one? 17:44:07 johngarbutt: yes 17:44:20 using the SSH key, or something else? 17:44:26 johngarbutt: yes 17:44:32 cool 17:44:40 johngarbutt: basically you encrypt it on the guest with the public key 17:44:42 alexpilotti: this is assuming ssh is installed on teh windows machien? 17:44:44 does it reset on every reboot? 17:44:46 17:44:55 pvo: no, you just need OpenSSL 17:45:02 alexpilotti: gotcha 17:45:13 johngarbutt: no, unless you confige it to do so 17:45:20 *configure 17:45:31 OK, so you set the password, then reboot, and it picks it up? 17:45:49 johngarbutt: even w/o reboot 17:45:50 or just on new machine create? 17:45:57 johngarbutt: at the first boot 17:46:33 so we were wondering about without the need for a reboot, are you polling the metadata service or something? 17:46:42 johngarbutt: yes 17:46:58 johngarbutt: we are mainly supporting DriveInit 17:47:28 johngarbutt: BTW did you guys implement ConfigDrive? 17:47:31 driveinit? sorry for all these questions! 17:47:45 johngarbutt: ConfigDrive, sorry :-) 17:47:46 mike still is taking that: 17:48:19 johngarbutt: I try to avoid the metadata service as much as possible 17:48:20 matelakat: you got the link for that? 17:48:30 johngarbutt: and ConfigDrive is the perfect solution 17:48:45 johngarbutt: one huge problem with vishy's approach to the password problem 17:48:59 is that it requires posting to the metadata service 17:49:00 right 17:49:00 #link https://review.openstack.org/#/c/18370/ 17:49:18 matelakat: cool! 17:49:40 pvo: is that sounding better now? 17:49:50 I think that is starting to join up 17:49:52 johngarbutt: much. Thanks. 17:49:56 which means that the guest needs to have write access to the metadata service *cough* 17:50:07 hmm, yes... 17:50:15 with all the security issues that you can immagine 17:50:23 we found a solution: 17:50:24 hence push into the guest, I see 17:50:42 alexpilotti: do tell 17:50:47 the guest passes the encrypted password to the host on an internal channel 17:50:57 and the host writes to the metadata 17:51:06 this is hypervisor specific 17:51:08 oh right, which is where XenAPI has been using xenstore 17:51:09 right 17:51:24 Hyper-V has a technology called KVP exchange for that 17:51:36 I wantedt to ask what is available on Xen 17:51:42 I wondered about, user pushes password, nova cli helps encrypt with key 17:51:42 *wanted 17:51:44 alexpilotti: this is how we do it now 17:52:02 a diffie-hellman exchange to pass it back and forth. 17:52:07 pvo: cool. Do you have a blueprint or a reference patch? 17:52:16 alexpilotti: I can find one. 17:52:23 we've been using it for some time now 17:52:47 because IMHO having the guest writing directly to the metadata service is a huge risk of DOS and scalability problems 17:53:04 alexpilotti: if you're running one monolithic, sure. 17:53:11 #link https://github.com/openstack/nova/blob/master/nova/virt/xenapi/agent.py#L166 17:53:12 if youre running one per compute on loopback, less so 17:53:15 while passing the info to the host and having the driver doing it via nova api is IMO way safer 17:53:18 yea, that link 17:53:54 johngarbutt pvo: tx, I'm going to take a look at it 17:54:21 if we don't catch each other, fancy same time next week to just follow up? 17:54:34 sure 17:54:38 Note that XS does have some KVP equivalent which is needed by SCVMM - although this isn't currently suitable for wider distribution I believe 17:54:41 sure 17:55:09 would you guys like to schedule a meeting next week? 17:55:32 maybe we should fetch somebody from KVM as well 17:55:37 Mr_T: your question? 17:55:48 oh, thanks - i was curious if anyone happened to know the size limit of files ("personalities") injected to instances via xenstore? 17:55:49 alexpilotti: sure 17:56:16 i've heard it's somewhere around 2k, but wasn't able to find a more specific answer 17:56:22 not sure myself, smaller is better, that I remember 17:56:39 is that a nova or a XenAPI limit? 17:56:48 its a limitation in how much data you can put into a xenstore value 17:56:56 its a xenapi limit 17:57:00 right 17:57:12 #link https://github.com/openstack/nova/blob/master/nova/virt/xenapi/agent.py#L219 17:57:15 k guys, let's sync on -dev after the meeting ends? 17:57:27 alexpilotti: sure, thank you! 17:57:31 alexpilotti: I gotta run to my next meeting, but I'll follow up there later. 17:57:33 tx! 17:57:44 That is time for us 17:57:46 Believe the limit is 4k but I'd have to check up on that 17:58:05 #action BobBall: check xenstore limit 17:58:12 that does ring a bell 17:58:18 many thanks all 17:58:25 same time next week hopefully 17:58:26 thank you 17:58:35 #endmeeting