17:00:24 #startmeeting vmwareapi 17:00:25 Meeting started Wed Jan 8 17:00:24 2014 UTC and is due to finish in 60 minutes. The chair is hartsocks. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:29 The meeting name has been set to 'vmwareapi' 17:00:32 \o 17:00:53 greetings from the depths of the arctic vortex 17:00:58 who's around? 17:01:05 hi 17:01:10 y0 17:01:38 present 17:02:13 Hi 17:02:33 Its 54 here :-) 17:03:13 t'was 8° F here… will be 65° F by the end of the week 17:03:24 'crazy arctic vortex! 17:03:36 :-) 17:04:03 middle of winter here and everyone is out in the sun! 17:04:15 same in sofia :) 17:04:22 * hartsocks hides looks of jealousy 17:04:32 happy new year everyone! 17:04:53 Happy new year! 17:05:15 I hope everyone had a good 2 week break. 17:05:36 personally I broke a lot of things... 17:05:44 :-) 17:06:15 We're around 2 weeks out from icehouse-2 feature freeze... 17:06:51 so.. 17:06:52 #link https://wiki.openstack.org/wiki/Meetings/VMwareAPI#Agenda 17:07:00 #topic blueprints 17:07:15 #link https://etherpad.openstack.org/p/vmware-subteam-icehouse-2 17:07:36 I'm grooving on the etherpad. So I thought I would just put this up for the team. 17:07:45 That's our BP priorities based on last time. 17:08:18 If your BP didn't make "approved" by around last meeting it's probably not going to get into i-2 17:08:44 btw: be nice and name yourself in etherpad. 17:08:52 i added 2 missing BP's - approved, implemented and require some tlc from reviewers 17:08:59 good. 17:09:38 anyone feel we need to discuss one of these? 17:10:53 it would be nice to add the cinder BP's too 17:11:05 I am actually registering one bp right now for enhancing the logger to include vsphere session information 17:11:10 there is the spbm support. i'll post the link in asec 17:11:30 ssurana: can you please elaborate 17:12:12 sure, the idea is to enhance the context of the logger in nova to also include the vsphere session id 17:12:44 so that in the logs we could also see the associated session id used on the vsphere 17:12:44 ok. will that be done in oslo? 17:13:07 #link https://blueprints.launchpad.net/oslo/+spec/vmware-api 17:13:15 we probably should all pay attention to that one. 17:13:26 It's not until icehouse-3 however. 17:13:49 no that would be done in nova, primarily because the session is only relevanct for the nova 17:14:26 hrm… I don't know. I think setting up property collectors, property filters, etc. is pretty universal. 17:14:31 in cinder and glance there will also be the session 17:14:59 however I am also thinking if we can implment this in a more generic way in OSLO 17:15:21 ssurana: maybe it is worthwhile to interface with vipin about the porting of the code to oslo and see if can be based on his code 17:15:29 sure 17:15:47 i guess for the vmware parts. not sure if the oslo logging needs to be changed for the support that you wish to add 17:16:23 no I have a current poc code that does not need any change in the oslo logging and that does the job 17:16:47 but i am still working on this, so havent settled on a particular approach yet 17:17:09 ok 17:17:48 I'll ask for some indulgence… I posted https://blueprints.launchpad.net/nova/+spec/vmware-soap-session-management 17:17:57 the second review there... 17:18:05 is up for general reactions. 17:18:33 part of that involves the logging changes. 17:18:47 I may have stepped a bit on what ssurana was doing. That wasn't intentional. 17:19:26 no thats fine, we will collaborate to come up with the most appropriate implementation 17:19:32 I'll just ask for general reactions to this now. I don't expect this can make i-2 17:20:11 I'm not even sure this is the right direction entirely. But I did want to try and do some advanced mocking to show simulating interactions with SUDS. 17:20:16 would these not be best done on and above the oslo code that we are proposing? 17:20:26 that is a very good question. 17:20:40 I posted them here because it was easiest. 17:21:00 Do we have anyone working on the Oslo code in this meeting? 17:21:05 registered the bp https://blueprints.launchpad.net/nova/+spec/session-aware-logging-vsphere 17:21:44 ssurana, the logging changes weren't my focus. I was focused on changing how sessions were handled. 17:21:58 i will ask vipin to try and join next week. it may be a little late for him though 17:22:40 #action set up BP discussion time with vipin, garyk, ssurana, hartsocks 17:22:55 okay. 17:23:07 We need to get a little more coordination around that set of changes. 17:23:35 Part of the problem I see is we could end up saying "everything will be fixed when vipin is done" 17:23:47 … and we wait to address problems forever. 17:24:10 i think that we can do three things: 17:24:25 sorry - can you remind me who vipin is? 17:24:38 Vipin is from the Cinder team 17:24:40 1. make sure that we are all helping and reviewing with the oslo common code 17:25:01 now i remember thanks 17:25:10 2. give our inputs now to ensure that we are able to add enahncements like you guys have mentioned above 17:25:48 garyk: for the common code review - do we have review links (yet)? 17:25:53 3. continue with the session improvements - we may decide to try and land it in nova until we swap it with the oslo code - it is just working in "paraelll: 17:25:55 BTW: the Cinder team was tasked with "forklift" of the driver code to oslo because their driver was newer and ostensibly "cleaner" so the job for them would be easier. 17:26:18 we have some links... 17:26:21 * hartsocks digging 17:26:38 #link https://blueprints.launchpad.net/oslo/+spec/vmware-api 17:26:49 #link https://review.openstack.org/#/c/65075/ 17:27:06 I have been a bit critical… but I think the Oslo port is an important opportunity to get right. 17:27:45 In general, I personally *never* want to see the lines... 17:27:55 except Exception: 17:27:57 again. 17:28:03 hartsocks: agreed 17:28:38 It might not be 100% realistic … but we can at least make it hard to commit that w/o serious explanation. 17:29:40 okay, so I think we need some special off line discussion around sessions, session logging, and the Oslo forklift. 17:30:44 #action hartsocks, get people talking about sessions, session logging, and the Oslo code -> get recorded somewhere 17:30:46 question on the oslo code commit, is there anything stopping us from using pyvmomi with oslo 17:30:56 technically no. 17:31:00 practically yes. 17:31:08 so this is anyways new code 17:31:16 right. 17:31:30 IMHO we should give that a try 17:31:48 but, one long term goal of doing an oslo commit is to get all the drivers rewritten based on the oslo lib. 17:32:00 otherwise we are never going to ge the pyvmomi in 17:32:08 if you make it pyvmomi versus the existing suds stuff we don't know how complex that is. 17:32:21 *never* is such a strong word. 17:32:26 sure. we inside oslo we coudl still have pyvmomi and the rest of the driver code could still be the same 17:32:31 I think we really need to tackle this in phases. 17:32:38 sure 17:32:43 We *could* propose an Oslo lib based on pyvmomi… 17:32:53 a good question is... 17:32:59 we need to make sure that the api that are provide to nova/cinder and glance are not aware ot eh transport/interface - so it could be suds/pyvmomi/even a guy with a spoon carry the data to the vc 17:33:15 garyk: bingo! 17:33:32 garyk: that's the argument I was about to make. 17:33:39 garyk: LOL 17:33:42 btw the guy with the spoon will shour Exception if something drops 17:33:48 exactly 17:33:58 raise SpoonTransportFault() 17:34:02 heh 17:34:25 so my question for all these Oslo commits was: 17:34:28 we just need to understand that it is a process. 17:34:37 can we make these OpenStack specific? 17:35:06 i think that they are openstack specific as we are using a subset of what is offered 17:35:14 garyk: I actually managed to post something for Oslo that will need to be pulled into Nova later so I'll get a tour of that. 17:35:52 garyk: I think that's the argument that serves us best. If we make these tailored libs that cover precisely what OpenStack cares about ... 17:36:00 the process is pretty simple. once it is approved in oslo you run a script which ports it to the relevant project. you need to add a commit message witht he git refs and then it is the same review process 17:36:08 that well be tighter, smaller, faster, etc. 17:36:26 so we burned a lot of time on BP 17:36:31 no, it is pretty much more of the same. it goes through the same nova review process 17:36:56 garyk: my last comment was not about the process it was about the oslo libs. Our comments are interleaving. 17:37:28 okay 17:37:31 so 17:37:32 bugs? 17:37:36 yes? 17:37:47 #topic bugs 17:38:02 #link https://review.openstack.org/64598 17:38:13 I personally feel this is our highest priority bug right now. 17:39:50 I managed to mangle the patch while trying to be clever. 17:40:19 On the plus side I understand git-review a *lot* better. 17:40:44 i spend my days rebasing :) 17:41:12 gotta love rebasing 17:41:16 well, I now know that you are fine with submitting two changes from one git-review 17:41:25 you just have to watch those git hashes. 17:42:13 I've posted a bug priority order report in the etherpad from earlier. 17:42:24 #link https://etherpad.openstack.org/p/vmware-subteam-icehouse-2 17:42:29 for the lazy. 17:42:36 thanks 17:43:01 if it's on that list… and you attend this meeting… and you've *not* reviewed it... 17:43:05 frowny face for you. 17:44:07 BTW: the priorities are pulled from launchpad so if you disagree with the priorities there don't edit the ehterpad w/o editing launchpad. 17:44:24 There are *rules* we have to follow on the priorities so … follow those. 17:44:44 when in doubt poll me and I'll help out. 17:45:02 i have split the reviews into icehouse and hava 17:45:14 sure. 17:45:41 #link https://review.openstack.org/62587 <- this one makes me sad. 17:45:52 it's been so well behaved.. so patient. 17:45:57 so neglected. 17:46:35 any bugs on there we need to discuss? 17:46:39 sadly it missed the last havana version. hopefully we will get it in by the next one 17:46:41 it has no reviewers but jenkins 17:46:54 he is such a nice chap 17:47:01 heh 17:47:28 imagine these are puppies … they need attention. 17:47:45 well, this is the internet… imagine cats if you prefer. 17:48:22 open discussion? 17:48:45 * hartsocks listens 17:49:05 #topic open discussion 17:49:15 one of the reasons i miss reviewing something is if it is not on my important review list i do not see it. Is there a better way other than manually adding stuff mentioned at this meeting? 17:50:06 I just spend a lot of time adding my username to reviews I want to spend time with later. 17:50:19 It makes for a huge backlog. 17:50:23 i just use the link - https://review.openstack.org/#/q/message:vmware+OR+message:vcenter+OR+message:vsphere+OR+message:esx+OR+message:vcdriver,n,z 17:50:56 which works as long as they mention one of those words in the message… we have rules about that now. 17:51:36 The script I use every Wednesday actually reads *every patch* in review and looks for 'vmware' in the paths changed. 17:51:54 i was thinking about an idea 17:51:56 so between those two I think you'd get everything. 17:52:07 i was wondering if that report could be enhanced to add a name to the review list? 17:52:07 * hartsocks motions to go on 17:52:24 tjones1, yeah I think so. 17:52:41 we have a few bp's for i-2. how about we choose 2 a week to all focus our reviews on. if everyone on this meeting gives their thumbs up then it should be a little helpful to get a code 17:52:45 i was rthinking that too but didn't get further than thinking 17:52:48 core not code 17:53:14 having 6 or 7 pople spend a week on a bp or 2 should really cover all bases 17:53:47 I like it. 17:53:52 me too 17:54:13 I spend a *lot* less time pulling patches for manual testing now. 17:54:38 i still do it if the patch is large (i.e. image cache) which i am doing now and it is WORKING 17:54:44 so how about we do the following. keep the modus operandi this week. 17:54:59 next week we select 2 bps for i2 and have people accountable for the reviews 17:56:33 Okay. How about we use that etherpad and put our username next to the BP we're committing to review. How's that for accountability? 17:57:43 On the topic of the Minesweeper... 17:58:17 how long before we see vote −0 with a link to logs? 17:58:45 I think it helps a lot if we can see when Minesweeper didn't +1 and get a look at what happened. 17:59:19 we're out of time. 17:59:50 It should happen soon by end of this week 18:00:00 cool! 18:00:05 We're over on #openstack-vmware if you need to chat (and you're not 100% it belongs on #openstack-nova) 18:00:16 Otherwise see you next week. 18:00:21 Same Bat-time 18:00:25 Same Bat-channel. 18:00:28 #endmeeting