17:00:37 <tjones> #startmeeting vmwareapi
17:00:38 <openstack> Meeting started Wed Apr 23 17:00:37 2014 UTC and is due to finish in 60 minutes.  The chair is tjones. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:42 <openstack> The meeting name has been set to 'vmwareapi'
17:00:52 <tjones> hi folks - who is here today?
17:01:23 * hartsocks waves
17:01:23 <tjones> *listens*
17:02:13 <tjones> *continuing to listen*
17:02:21 <tjones> hi hartsocks
17:02:28 <browne> hi
17:02:57 <tjones> ok im going to get started - assuming some lurkers are out there too.
17:03:20 <tjones> #topic change in chair for vmwareapi
17:03:28 <ssurana> hi
17:03:42 * mdbooth waves
17:04:45 <tjones> we are having a change in chair for this meeting.  hartsocks is going to be focusing his time fully on the care and feeding of the pyvmomi library.  He's done an awesome job chairing this meeting and i am going to take over as chair at least in the short term
17:05:19 <tjones> thanks hartsocks for all of the work you have done as chair and we are looking forward to being able to consume an awesome pyvmomi soon
17:05:37 * hartsocks bows
17:05:45 <tjones> *claps*
17:05:53 <hartsocks> We're just ramping up on pyVmomi dev right now.
17:06:05 <hartsocks> I've launched a couple IRC channels...
17:06:11 <hartsocks> #pyvmomi and #pyvmomi-dev
17:06:23 <hartsocks> So you folks are the first to hear about them.
17:06:28 <tjones> i hope you are the channel owner ;-)
17:06:36 <hartsocks> We'll be doing this as an open source effort.
17:06:56 <hartsocks> tjones: yeah… first thing I did with znc is do an autoop on myself.
17:07:32 <hartsocks> We will also have public mailing lists and all that.
17:07:52 <hartsocks> OpenStack will be our first big consumer for the lib you your input is vital.
17:08:05 <hartsocks> Anyway that's my plug for my new project.
17:08:34 <hartsocks> It will be a nice landing place for anything that comes out of OpenStack that belongs in a broader library.
17:08:43 * hartsocks steps back and waves
17:08:46 <tjones> thanks hartsocks feel free to continue to attend this meeting as a sync point between openstack and pyvmomi if you think that works
17:09:03 <tjones> ok moving to BP
17:09:10 <tjones> #topic blueprints
17:09:19 <tjones> #link https://review.openstack.org/#/q/status:open+project:openstack/nova-specs+message:vmware,n,z
17:09:33 <tjones> #undo
17:09:33 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x37459d0>
17:09:41 <tjones> I wanted to talk about approved BP first
17:10:28 <tjones> #link https://blueprints.launchpad.net/nova?searchtext=vmware
17:11:13 <tjones> so spawn refactor is approved and is moving along.  It has started partially moving upstreeam (yeah).  Please review if you have a chance https://blueprints.launchpad.net/nova/+spec/vmware-spawn-refactor
17:11:22 <tjones> any other approved BP that needs attention?
17:12:34 <tjones> i should have said phase 1 of spawn refactor.  hartsocks and vuil are working on phase 2 and 3.  how is that going guys?
17:13:02 <hartsocks> I've gotten some reviews for small changes. I'm sitting on a revision waiting for phase 1 to merge.
17:13:24 <hartsocks> vuil and I need to sync up on how phase 3 will have to change now that I've dropped part of the model.py we were building.
17:13:44 <vuil> I am semi-waiting for some phase-2 updates too.
17:13:54 <vuil> let's sync up after this, Shawn.
17:14:01 <hartsocks> vuil: sounds good.
17:14:16 <tjones> ok for non-approved BP we have #link https://review.openstack.org/#/q/status:open+project:openstack/nova-specs+message:vmware,n,z
17:14:44 <tjones> hartsocks: do you want me to take over epemeral disk or will you be able to continue on this?
17:14:59 <hartsocks> I was planning on continuing with ephemeral disk support.
17:15:05 <hartsocks> There isn't much to do.
17:15:18 <hartsocks> It has been ported now since Havana.
17:15:19 <tjones> ok i see you have a -1 now.  wll you be revising soon?
17:15:37 <hartsocks> oops… yeah. I'll catch that this afternoon then.
17:16:17 <tjones> next one is #link https://review.openstack.org/#/c/84629/
17:16:20 <vuil> https://review.openstack.org/#/c/85469/ is approved btw, and is one of the high priority items. Tracy can you update the bp link?
17:16:54 <vuil> that would be: https://blueprints.launchpad.net/nova/+spec/use-oslo-vmware
17:17:01 <tjones> #action update https://blueprints.launchpad.net/nova/+spec/use-oslo-vmware
17:17:32 <tjones> i suspect vincent hou does not attend this meeitng.  anyone know his irc name?
17:18:08 <tjones> i'll find it somewhere
17:18:14 <tjones> ok next 2 are yours vuil
17:18:23 <tjones> #link https://review.openstack.org/#/c/86395/
17:18:33 <tjones> #link https://review.openstack.org/#/c/85635/
17:18:50 <vuil> https://review.openstack.org/#/c/86395/ is waiting on a +2
17:18:55 <tjones> how are these going?  they are icehouse leftovers
17:19:17 <vuil> I need to update the spec for the other
17:19:39 <vuil> once approval, they will essentially be waiting on the refactor for refresh
17:19:40 <tjones> ok looks like johnthetubaguy reviewed it a few weeks ago.  probably ready for him to take another look
17:20:00 <tjones> by "it" i mean https://review.openstack.org/#/c/86395/
17:20:20 <tjones> last one #link https://review.openstack.org/#/c/84662/
17:20:34 <tjones> kiran does not attend this meeting either
17:20:49 <tjones> but it looks like it is ready for some +1 type reviews - so please take a look
17:21:05 <tjones> anything else on BP?
17:22:08 <tjones> #topic bugs
17:22:17 <tjones> we have 59 bugs currently and 17 are not assigned
17:22:18 <tjones> http://tinyurl.com/kamvt7b
17:22:23 <mdbooth> Is there a bp for ova in glance, btw?
17:22:49 <vuil> @mdbooth what in particular re: ova?
17:23:06 <vuil> support for the container type is merged
17:23:16 <vuil> in glance
17:23:30 <mdbooth> vuil: Ah, never mind. That *is* the bp :)
17:23:37 <tjones> lol
17:23:45 * mdbooth isn't used to the new format. yet
17:24:00 <browne> tjones: shouldn't https://bugs.launchpad.net/nova/+bug/1297998 be assigned to you?
17:24:02 <uvirtbot> Launchpad bug 1297998 in nova "VMWare: spawn refactor - _power_on_vm" [Undecided,New]
17:24:19 <tjones> ok so the unassigned bugs - there is 1 high prio one.  can someone grab that and work on it?  It's not super high prio but would be annoying to a customer
17:24:35 <tjones> browne: thanks i am going to close that.  i opened it in error since there is a bp we do not need it
17:25:46 <tjones> we also have 6 untriaged  bugs in that list
17:26:23 <tjones> i don't want to do it here - but please take a look at them.  I will triage fter this meeting
17:26:23 <browne> i can look into 1249519
17:26:31 <tjones> great thanks browne
17:26:38 <tjones> anything else on bugs?
17:27:33 <tjones> #topic summit
17:27:46 <tjones> ok anything we should discuss for the summit?
17:27:53 <mdbooth> Clustering
17:28:11 <mdbooth> Locking
17:28:34 <tjones> yes
17:28:46 <tjones> did anyone propose a talk around that?
17:29:02 <mdbooth> There's already a multi-project talk around clustering
17:29:19 * mdbooth doesn't know where to find the link
17:29:21 <tjones> is that the one vishy is running?
17:29:46 <tjones> no here it is
17:29:48 <tjones> #link http://summit.openstack.org/cfp/details/145
17:30:48 <tjones> not locking though
17:30:51 <mdbooth> tjones: Yes, that's the one
17:31:16 <mdbooth> So, locking might come out of HA, actually
17:31:36 <mdbooth> Which I would treat separately from clustering
17:31:41 <tjones> yes
17:31:45 <mdbooth> Although they're related in usage
17:31:58 <tjones> in our usage for sure
17:32:24 <tjones> i dont' really see anything appropriate in the propsals for this topic.  we should perhaps have an unconference on this?
17:32:35 <mdbooth> If we're going to have multiple nova nodes managing 1 cluster, we need to ensure that's safe
17:32:55 <mdbooth> And we need to decide if that's a good idea in the first place
17:33:03 <tjones> in our "best practices" we discourage that - but of couse it is not enforcable
17:33:11 <tjones> however you spell that
17:33:16 <mdbooth> I mean from an HA pov
17:33:24 <mdbooth> i.e. active backup
17:33:27 <tjones> right
17:33:39 <mdbooth> It keeps coming up
17:34:20 <tjones> so lets discuss at the summit somehow - unconference or whatever
17:34:43 <tjones> #action make sure to discuss > 1 n-cpu / cluster and locking
17:34:59 <tjones> any other summit topics?
17:35:45 <tjones> irc://ec2-54-209-130-42.compute-1.amazonaws.com:6666/#action make sure to discuss > 1 n-cpu / cluster and locking at the summit
17:35:50 <tjones> oops
17:35:55 <tjones> undo
17:35:58 <tjones> #undo
17:35:59 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x3800e90>
17:36:05 <tjones> anyway...
17:36:10 <tjones> #topic open discussion
17:36:27 <mdbooth> I've been looking at vnc ports today
17:36:46 <garyk> did you find them :)
17:36:50 <tjones> lol
17:36:57 <mdbooth> garyk: I did, thanks :)
17:37:16 <mdbooth> So, I was a bit surprised to discover that vsphere doesn't allocate them automatically
17:37:28 <garyk> mdbooth: i think that radoslav did a lot of work with them
17:37:42 <mdbooth> The most recent fix to vnc ports makes them vcenter-global
17:37:43 <garyk> i think that we are also waistful with the way in which we use them
17:37:57 <mdbooth> There's a code comment about making them host global
17:38:06 <mdbooth> However, I think they actually need to be cluster global
17:38:20 <mdbooth> because in an HA cluster, a VM can move between hosts
17:38:39 <mdbooth> I was considering knocking up a patch for that.
17:38:40 <mdbooth> Thoughts?
17:39:04 <garyk> i suggest may speaking with rado (he is the same tz as us). he may have some useful inputs
17:39:10 <tjones> mdbooth: good point.  i wonder what happens to the vnc port when it moves to a host that already has that in use…  does vc figure that out and reassign it ?
17:39:38 <hartsocks> IIRC things just break
17:39:42 <mdbooth> tjones: I'm planning on finding out, once I set my lab up so I can actually do that :)
17:39:50 <mdbooth> Then I was going to fix it
17:39:53 <tjones> mdbooth: cool
17:40:03 <mdbooth> incidentally, can I vmotion with no shared storage?
17:40:26 <hartsocks> There's a set of criteria for vMotion.
17:40:28 <mdbooth> I created a 2 host cluster earlier with no shared storage
17:40:47 <hartsocks> Shared storage works on 5.0 and earlier… but I don't recall about later.
17:40:53 <mdbooth> I put one of the hosts in maintenance mode, and was hoping the guest on it would magically end up on the other one
17:41:03 <tjones> i think it works storage vmotion should take care of it
17:41:06 <mdbooth> It didn't seem to be happening
17:41:18 <hartsocks> Thats SRS
17:41:21 <hartsocks> DRS
17:41:31 <tjones> yes
17:41:33 <hartsocks> auto placement… it's in the dev docs on the wiki
17:41:44 * mdbooth thinks DRS is enabled
17:41:55 <mdbooth> Anyway, will play more tomorrow
17:41:58 * hartsocks digs up docs
17:43:05 <hartsocks> https://wiki.openstack.org/wiki/NovaVMware/DeveloperGuide#vSphere_Environment_and_Inventory
17:43:16 <mdbooth> What does vsphere use for its native console, btw?
17:43:21 <mdbooth> Can we expose that to an appropritate client?
17:43:42 <browne> mdbooth: vmrc
17:43:51 <hartsocks> :-)
17:44:10 <hartsocks> It's conceptually the same as VNC but better compression / crypto
17:44:23 <browne> to expose it would require user access to vcenter.  and vcenter users are not the same set of users as openstack
17:44:39 <mdbooth> browne: It's not proxyable?
17:44:51 <mdbooth> We proxy vnc
17:45:04 <browne> mdbooth: not sure
17:45:08 <hartsocks> That's beyond my knowledge of vmrc.
17:45:27 <hartsocks> I know we have a vmrc plugin for the web client version of vCenter.
17:45:41 <hartsocks> Well, I seem to recall something about that anyhow.
17:45:54 * mdbooth only has the web client, and can access consoles
17:46:03 <browne> https://github.com/openstack/nova/blob/master/nova/console/vmrc.py
17:46:07 <ssurana> yeah you are right there are browser plugins for vmrc that are used to show the console
17:46:14 <browne> looks like someone has already done something with it
17:46:15 <hartsocks> … that leads me to believe you can proxy it anyhow...
17:46:38 <hartsocks> *nice*
17:47:25 <mdbooth> Anyway, it makes sense to me to expose the native interface
17:47:47 <mdbooth> presumably vcenter knows how to manage it as it moves about, for eg
17:47:47 <ssurana> there is a way from the api to get the vmrc console ticket that you can use to view the VM's console..
17:48:42 <hartsocks> I have no notes on vmrc connections breaking randomly so I would tend to believe that.
17:48:53 <browne> would be interesting to know performance impacts of using vmrc vs. vnc
17:48:54 <ssurana> need to look into the vmrc.py
17:49:41 <hartsocks> I've been told vmrc is faster / better / stronger … but I've not verified it.
17:50:26 <mdbooth> It occured to me that we don't use vnc passwords, btw
17:50:44 <mdbooth> So if the host is routable from the user network, that's a security problem
17:51:03 <hartsocks> yeah. That is.
17:51:13 <browne> mdbooth: yes.  openstack's use of vnc has always concerned me
17:51:14 <garyk> mdbooth: originally we used the passwords. but that was problematic and it was not needed
17:51:34 <mdbooth> garyk: not needed?
17:51:36 <garyk> ideally the creation of the vnc connection should provide a poassword to the user - but that would be higher in the stack
17:51:44 <mdbooth> because it's on a segrated network?
17:51:51 <garyk> mdbooth: libvirt does not have vnc password
17:52:10 <garyk> all of the vm's would also have the same password
17:52:11 * mdbooth has been learning that's no guarantee of correctness :)
17:52:20 <browne> vnc is typically tunneled over ssh for security
17:52:28 <hartsocks> At the moment we tell people to make a "hard and crunchy outside" around the gooey nougat that is the VNC addressable networkspace
17:52:39 <mdbooth> Right
17:52:46 <mdbooth> Security at the network level
17:52:55 <hartsocks> Which I term:
17:53:07 <hartsocks> "hard and crunchy outside, soft and chewy center"
17:53:18 <hartsocks> And it's a bit naive if you ask me.
17:53:46 <hartsocks> It presumes no tennant would ever attack another.
17:55:43 <tjones> ok folks - just a few more minutes here.  anything else we want to discuss?
17:57:45 <tjones> going to end now then.  feel free to continue discussing on openstack-dev or openstack-vmware.  we pretty much have moved to -dev for all of our discussions now.
17:57:54 <tjones> thanks and have a good week
17:58:04 * hartsocks waves a fond farewell
17:58:11 <browne> dev or -nova?
17:58:31 <tjones> duh  -nova
17:58:42 <tjones> #endmeeting