09:59:51 #startmeeting climate 09:59:52 Meeting started Mon Nov 25 09:59:51 2013 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:59:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:59:56 The meeting name has been set to 'climate' 10:00:05 morning all 10:00:14 who's there ? 10:00:24 \o/ 10:00:36 o/ 10:00:43 hello, guys 10:00:48 Hi 10:00:53 Hi Dina 10:01:12 I had no news about Francois, he's probably still ooo 10:01:28 as he was at the SC 2013 expo 10:01:46 hi Nikolay_St 10:01:48 ok, see it 10:02:01 #link https://wiki.openstack.org/wiki/Meetings/Climate#Agenda_for_November.2C_25 10:02:17 today I'll host the chair 10:02:29 and we have no special agenda, I suppose 10:02:35 today, I mean 10:02:36 nope, reviewed it 10:02:56 ok, see it in our chanel 10:03:00 as said, any other concerns should be raised during the "open" topic 10:03:02 so 10:03:15 #topic action items from last meeting 10:03:25 http://eavesdrop.openstack.org/meetings/climate/2013/climate.2013-11-18-10.04.html 10:03:25 #link http://eavesdrop.openstack.org/meetings/climate/2013/climate.2013-11-18-10.04.html 10:03:34 was faster than you :) 10:03:50 mmm, I see otherwise :D 10:03:54 let's go by action item/person 10:04:04 ok 10:04:20 so, I made a few comments on https://review.openstack.org/#/c/52296 10:04:35 Nikolay_St also had action for rebasing it 10:04:39 he did 10:04:41 I see Nikolay has only rebased it 10:04:43 yes 10:04:55 yup, Nikolay_St, had you time to review my comments ? 10:04:58 Nikolay, will you please fix comments? 10:05:30 o/ 10:05:37 Ok, I suppose we may create action item for Nikolay 10:05:42 SergeyLukjanov, hello 10:06:08 I'm sorry, we have terrible Internet connection at our office in Grenoble 10:06:15 sure 10:06:30 so I won't be able to quickly glance at the reviews 10:06:31 bauzas, yes, that's always a problem 10:06:36 bauzas: yeap 10:06:57 I'll do it in few days 10:06:59 #action Nikolay_St Review comments from bauzas on https://review.openstack.org/#/c/52296 and amend patch 10:07:12 I'm close to end with tests 10:07:24 cool 10:07:37 DinaBelova: your actions ? 10:07:44 POC using shelved instances ? 10:07:45 yes, let's go to them 10:08:00 had you time for looking at it ? 10:08:09 there was no time to it... 10:08:23 so other two action items are done/in progress 10:08:28 ok 10:08:51 as for POC, I will do it after oslo.messaging intergation 10:09:08 ok 10:09:17 or Nikolay will do it himself in case he will end up with his current tasks quicker 10:09:23 ok 10:09:38 yeap 10:09:51 I think I'll end soon 10:09:57 #agreed POC on shelved instances to be done after oslo.messaging BP 10:10:04 Nikolay_St, as for your action atimes 10:10:13 items*** 10:10:26 wow, keyboard wants to kill me 10:10:45 well, Nikolay_St only had action to rebase previous patch 10:10:54 yes, and that's it 10:10:58 yup 10:11:11 yeap 10:11:13 let's talk about proc/cons 10:11:23 of triggering Openstack releases for Climate 10:11:38 I think that's a bit early for discussing that 10:11:49 we need to see our velocity 10:12:16 ie. we can agree to aim to deliver for icehouse-2 10:12:33 I suppose we have already started using them (while BPs assignment and time management) - at least in terms of bugs and BPs 10:12:41 and target blueprints accordingly 10:12:42 i1 will be 1.5 weeks, i2 is in 2 months 10:13:03 i1 is impossible for something really working 10:13:13 bauzas, agreed, i2 looks ok to have first release 10:13:16 yup, but all, please keep in mind that should be a temptative attempt 10:13:19 i2 is better 10:13:23 yup 10:13:33 +1 to Dina 10:13:37 we have a few iteams for i-1 10:13:51 we have several i1 dates 10:13:54 yup, 10:13:55 in launchpad 10:14:05 do we agree to postpone them to i2 ? 10:14:14 just for clarification ? 10:14:20 but all of them are about critical bugs/bps for critical discussion 10:14:38 DinaBelova: as said, that doesn't mean we can't deliver for i1 10:14:59 I would say let's see what happens with the deliverables 10:15:15 target i2 for Climate v0.1 10:15:25 bauzas, what's the profit to keep i1 w/o releasing it? 10:15:41 that's a good question 10:15:51 I think first we won't have release on i1 10:16:09 I target i1 for a few BPs just saying these ones should be delivered to trunk during i1 10:16:21 but there are several things that should be merged, etc. for i1 date 10:16:22 yes 10:16:25 the same thing 10:16:37 to me, there are 2 things to consider : 10:16:48 1/ we have a rolling delivery about BPs and bugfixes to trunk 10:16:57 2/ we tag a special release for Climate 10:17:04 It seems to me we may leave these already created i1 things as is 10:17:12 Cannot catch 2/ 10:17:17 May you explain? 10:17:25 that's what I would call Climate v0.1 10:17:29 not i1, i2, but 0.1 for example 10:17:33 in the middle of iX 10:17:55 SergeyLukjanov: you mean between i1 and i2? 10:18:03 yep 10:18:05 bauzas, do you want v0.1 for i2? Or just separated line of releases? 10:18:12 Like SergeyLukjanov said? 10:18:14 0.1 for i2 yes 10:18:26 ie. having a special tag release 10:18:31 and so 0.x for i3? 10:18:45 possibly yes, possible not 10:18:58 I suppose, Sylvain, that's ok 10:19:04 but Sergey meant something else 10:19:07 i think 10:19:09 bauzas, I've proposed it on prev meeting and you was on the side of following OpenStack release process ;) 10:19:24 there are several options I see now 10:19:31 and several input params for it 10:19:32 SergeyLukjanov: that's exactly why we're discussing now :D 10:19:44 first of all the scope for "0.1" 10:20:01 it should be at least one working "reference" plugin excluding fake one 10:20:20 if we consider 0.1, we would need to tag BPs accordingly 10:20:36 one cons for using iX as some first release - tarballs will not be uploaded to pypi 10:20:37 ie. saying for 0.1, you will find all of these features 10:20:58 SergeyLukjanov: interesting 10:21:20 One quick moment, I'm ready to manage releases for every decided point 10:21:33 whatever we'll decide here now 10:21:39 IMO 0.1, 0.1.X, [0.2,] Icehouse is the best option for climate 10:21:51 to have some tarballs published to pypi 10:21:51 SergeyLukjanov, agree 10:22:02 agree 10:22:05 agree 10:22:06 and make releases when something will be ready 10:22:09 +1 10:22:16 scroiset: ? 10:22:22 +1 10:22:26 I've had a look on how Savanna is working with releases and this way seems to be nicest one 10:22:44 we used it before the incubation 10:22:57 to be much more flexible to release new features 10:23:00 #agreed Climate releases 0.1, .., 0.X to be considered during Icehouse release 10:23:00 we can discuss dates and probably adjust them with iX 10:23:02 release 10:23:04 and I think that's comfortable for un-incubated projects, yes 10:23:11 ok, great 10:23:11 yup 10:23:27 so now we have only open discussions left 10:23:30 we just need to scope Climate 0.1 10:23:37 yep 10:23:38 DinaBelova: nope 10:24:00 #action Scope Climate 0.1 10:24:35 Is that for now or for further discussions? 10:24:45 the best option is to have one virt and one hardware reservation plugins 10:24:45 let's just review 2nd topic 10:25:00 #topic high priority issues 10:25:20 https://review.openstack.org/#/c/57650/ is just rebased 10:25:24 oops 10:25:36 s/rebased/patchsett'd 10:25:40 and tests added, yes 10:25:56 #action bauzas Review https://review.openstack.org/#/c/57650/ by this week 10:26:02 ok, I think this context staff we may merge soon 10:26:15 in case there will be nothing to add 10:26:24 sure 10:26:31 there was only a typo 10:26:33 to me 10:26:42 should be merged by today if no objections 10:26:47 https://review.openstack.org/#/c/57200/ 10:26:53 policy management 10:27:00 I'm nearly done with it 10:27:08 I'm going to take a look on it today 10:27:12 there is still a typo in the policy.json I delivered 10:27:24 and leave comments if find something 10:27:27 and I also need to add an extra method get_admin_roles() 10:27:44 for implementing the elevated() method in the context 10:28:10 Ok, I see that in the commit message 10:28:14 that's not hard work 10:28:22 btw, masterofuniverse is nice role 10:28:25 so we don't need an is_admin flag 10:28:34 I had much fun reading it 10:28:49 ok, i think 10:29:06 we should also review/merge that by the end of this week 10:29:18 because policies are quite important 10:29:44 #action bauzas Deliver last patchset for https://review.openstack.org/#/c/57200/ by eob today 10:30:11 never say last for patchsets :D 10:30:19 any other high priority issues to discuss ? 10:30:26 I suppose no 10:30:29 that's it 10:30:32 if not, let's move to open discussion 10:30:38 #topic open discussion 10:30:59 I have nothing to add 10:31:08 if we speak about extra topics 10:31:09 well, I'll open a bug for the exceptions management 10:31:21 to discuss 10:31:27 bauzas, ok 10:31:41 bauzas: Unfortunately we don't have some final words from Duncan on that ML thread. So I still don't think it's wise to purge is_admin just because. 10:31:46 #action bauzas Open a bug for exception handling with code 10:31:55 #info https://review.openstack.org/#/c/58152/ auto updates for requirements 10:32:04 bauzas: Oh, not Duncan, but Dolph. 10:32:08 #info https://review.openstack.org/#/c/57675/ climate channel logging 10:32:23 YorikSar: what I can propose is to add a get_admin_roles() from policies management 10:33:02 so we could put all the admin roles in the roles[] list if elevated() 10:33:23 the policy.json file I will propose won't make use of the is_admin flag 10:33:25 bauzas: The point is that we don't have a way to get all roles that can be treated as admin roles because it can even be one separate admin role for every call. 10:33:35 but still they have different meanings 10:33:36 yes 10:33:44 yup 10:34:10 what I can say is that the policy handler will provide if necessary a list of roles given by policy.json 10:34:12 that's it 10:34:41 based on the context_is_admin rule in policy.json 10:35:00 SergeyLukjanov: good initiative for logging :) 10:35:07 bauzas: Oh... That sounds hacky... 10:35:08 YorikSar, what do you think about it? 10:35:10 SergeyLukjanov: I gave a +1 10:35:27 bauzas: Ok, let's move this discussion out of this meeting. 10:35:43 well, as Dolph said, we need to define a rule in policy.json saying which roles do have admin rights 10:35:44 we all did it i think :D for Sergey's commits :) 10:36:07 ok, do we something else to discuss? 10:36:12 YorikSar: ok, let's discuss that on the regular channel 10:36:17 DinaBelova: I don't think so 10:36:22 thanks all 10:36:30 ok, bye! 10:36:35 DinaBelova: I'll send the email about minutes 10:36:46 you ok ? 10:36:53 ok, sure 10:36:57 cool thanks 10:37:00 thanks buddies 10:37:05 #endmeeting