18:02:05 <sputnik13> #startmeeting cue 18:02:06 <openstack> Meeting started Tue Sep 15 18:02:05 2015 UTC and is due to finish in 60 minutes. The chair is sputnik13. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:10 <openstack> The meeting name has been set to 'cue' 18:02:15 <sputnik13> role call 18:02:18 <sputnik13> o/ 18:02:20 <dkalleg> o/ 18:02:23 <abitha> o/ 18:02:37 <davideag_> o/ 18:03:07 <esmute> \o/ 18:03:07 * sputnik13 pokes esmute and vipul 18:03:41 <sputnik13> ok vipul will join us when he can, we have quorum let's start 18:04:04 <sputnik13> usual agenda, action items, open discussion, bug list 18:04:12 <sputnik13> #topic Action Items 18:04:35 <sputnik13> #note AI #1 dkalleg to provide details in https://blueprints.launchpad.net/cue/+spec/status regarding more accurate rabbitmq status check 18:04:55 <dkalleg> Haven't looked into this yet 18:05:40 <sputnik13> ok, we'll probably want to start implementation soon so we should get that documented sooner than later 18:05:48 <sputnik13> not like next week sooner but maybe this month sooner :) 18:05:53 <dkalleg> Sounds good 18:06:14 <dkalleg> Will try to give it some time soon 18:06:18 <sputnik13> ok 18:06:37 <sputnik13> we'd already talked about it some, so I think it's a matter of getting it written down 18:06:50 <sputnik13> it was like a couple weeks ago though, when we last talked about it 18:07:01 <sputnik13> if you need a refresher let's talk about it after the meeting 18:07:21 <dkalleg> Sure. We just need the prioritization stars to align :) 18:07:33 <dkalleg> but, soon for sure 18:07:34 <esmute> we will start this feature soon.. in the next week or so... so perhaps the first thing would be to get a BP in place 18:08:30 <sputnik13> yup there are higher priorities right now but if we don't do this soon then implementation could be delayed so... this month 18:08:31 <sputnik13> :) 18:08:49 <sputnik13> ok moving on... 18:08:53 <sputnik13> #note AI #2 sputnik13 to fill in details for https://blueprints.launchpad.net/cue/+spec/kafka 18:09:02 <sputnik13> yeah, that didn't get done 18:09:03 <sputnik13> :) 18:09:18 <sputnik13> oh we need to reassign the actions, doh 18:09:28 <sputnik13> #action dkalleg to provide details in https://blueprints.launchpad.net/cue/+spec/status regarding more accurate rabbitmq status check 18:09:30 <ekarlso> +10 to kafka ! 18:09:40 <dkalleg> hm.. 18:09:40 <sputnik13> #action sputnik13 to fill in details for https://blueprints.launchpad.net/cue/+spec/kafka 18:09:49 <sputnik13> woah, isn't it bed time or something ekarlso 18:09:52 <sputnik13> :) 18:09:59 <ekarlso> haha, 8 pm :p 18:10:05 <sputnik13> nevermind then 18:10:06 <sputnik13> :) 18:10:14 <sputnik13> next action 18:10:20 <sputnik13> #note AI #3 davideagnello to file a BP for https://bugs.launchpad.net/cue/+bug/1438939 18:10:21 <openstack> Launchpad bug 1438939 in Cue "Cue CLI cluster list fields should show cluster size" [Wishlist,New] 18:10:56 * sputnik13 pokes davideag_ 18:11:03 <davideag_> yup, thats done 18:11:35 <sputnik13> can you add a link to the BP to the bug? 18:11:37 <davideag_> see #link https://blueprints.launchpad.net/cue/+spec/cluster-list 18:11:44 <davideag_> ok 18:11:45 <sputnik13> ok, I'll add it 18:12:07 <sputnik13> done, yay we closed one action :) 18:12:23 <esmute> do we want network_id or network name? 18:12:37 <davideag_> id? 18:12:47 <esmute> because im not sure a bunch of guid would be presentable for the user 18:12:50 <davideag_> to be consistent with what we accept as input 18:13:03 <davideag_> esmute: ok 18:13:31 <sputnik13> network_id 18:13:44 <sputnik13> as a convenience we can provide network name as well but network name is not unique 18:14:01 <esmute> sputnik13: this is for listing... 18:14:02 <sputnik13> the difference may have to be a --short vs --long or something of the sort 18:14:31 <esmute> im thinking about listing it in CLI or horizon... 18:14:36 <sputnik13> esmute: I know, but it wouldn't be odd for the listing to be used in a script 18:14:58 <esmute> if i see a bunch of GUID as my network, i would have to make a different call to neutron to tell me that that guid mean 18:15:57 <esmute> for example, nova list gives you the network name.... 18:16:24 <sputnik13> sold, network name 18:16:27 <esmute> ok.. we can discuss this in the BP or inthe cue channel 18:16:46 <sputnik13> yeah, it's a BP, we should actually be capturing these comments in the BP 18:17:31 <sputnik13> but I agree in principle that there is precedence for using network name (nova) and we should do the same 18:17:34 <esmute> ok.. ill drop a comment there 18:17:36 <sputnik13> at least in this instance 18:17:52 <esmute> and we can discuss whether we want network/flavor or network_id/flavor_id 18:17:56 <sputnik13> yup yup 18:18:19 <sputnik13> next item... 18:18:32 <sputnik13> #note AI #4 vipul sputnik13 to file cross-project summit discussion on service VMs 18:18:46 <davideag_> updated bp to include network name as possible option 18:19:01 <sputnik13> so... I was out the past week and half... I don't know whether vipul had a chance to do this, I will follow up with him today 18:19:10 <sputnik13> #action vipul sputnik13 to file cross-project summit discussion on service VMs 18:19:15 <sputnik13> davideag_: k 18:19:35 <sputnik13> that's it for actions 18:19:40 <sputnik13> #topic Open Discussion 18:19:50 <sputnik13> since we have no topics on the agenda 18:21:19 <davideag_> last meeting we touched on extending Cue to accept additional brokers, I started looking into this but do not have a design yet. we are looking to have this available for discussion/talk for summit 18:22:00 <sputnik13> ok 18:22:17 <sputnik13> davideag_ can you start a BP to kick off this discussion? 18:22:18 <davideag_> there was two parts to this, the first being how the api will be affected and looking at different strategies 18:22:28 <esmute> looks like some new features are coming up.. i see lots of action items about BP creation :) 18:22:32 <sputnik13> oh wait there already is a BP 18:22:40 <sputnik13> https://blueprints.launchpad.net/cue/+spec/multi-broker-support 18:22:45 <davideag_> the second, being how the design of our python codebase will look like 18:23:17 <sputnik13> what mean you by python codebase 18:23:18 <davideag_> sputnik13: yup, created one 18:23:28 <sputnik13> I do not know this python thing 18:23:32 <davideag_> how our current code will change 18:23:38 <davideag_> hahaha 18:24:11 <sputnik13> that's implementation, too soon to be thinking about code 18:24:41 <sputnik13> unless you mean the structure/architecture like plugin vs something something something 18:25:34 <sputnik13> software architecture would be a valid discussion topic, plugin is just one approach, we should give at least cursory consideration to other approaches 18:26:00 <esmute> Yeah.. we need to think on how to refactor/restructure our code in order to make it more like a plugging/strategy design 18:27:52 <davideag_> sputnik13: yes, design architecture. 18:28:50 <sputnik13> it would probably be useful if someone would provide a writeup on the broker differences huh 18:29:05 <sputnik13> I could swear someone had the action to do that, hmmm 18:30:06 <davideag_> hmmm 18:30:11 <davideag_> who was that? 18:30:29 <sputnik13> no idea, some lazy slacker 18:30:30 <davideag_> it would be helpful for me 18:30:40 <sputnik13> that keeps kicking things down the road 18:30:41 <davideag_> haha 18:31:27 <sputnik13> can we do some research on how the plugin or driver models look in other projects? 18:32:36 <sputnik13> is that even the right approach... I suspect it is... I think cinder and neutron both use a similar approach, trove does as well I believe 18:32:53 <davideag_> sputnik13: so this is part of my work, I am looking into plugins in Neutron 18:33:00 <sputnik13> ok 18:33:19 <sputnik13> #action davideag_ to continue developing https://blueprints.launchpad.net/cue/+spec/multi-broker-support 18:33:31 <davideag_> it looks like it's the ideal strategy 18:33:41 <sputnik13> just so we have it on the notes and we can keep addressing it during meetings 18:33:55 <davideag_> sounds good 18:33:59 <sputnik13> ok, anything further on this? 18:34:03 <sputnik13> if not, any other topics? 18:34:28 * sputnik13 pokes dkalleg and abitha 18:34:37 <dkalleg> negative 18:34:51 <abitha> no 18:35:05 <sputnik13> move on to bug list? 18:35:09 <davideag_> yes 18:35:24 <sputnik13> we have only 1 bug that needs to be triaged 18:35:24 <abitha> yes 18:35:47 <sputnik13> after we talk about that we should start looking at triaged unresolved bugs 18:35:55 <esmute> nop 18:36:01 <sputnik13> no? 18:36:29 <esmute> sorry.. that was the answer for your previous question 18:36:39 <esmute> anything further on this? 18:36:40 <sputnik13> don't move on to bug list? 18:36:45 <sputnik13> :) 18:36:54 <esmute> yes 18:36:58 <esmute> :p 18:37:05 <sputnik13> action for esmute to get faster keyboard 18:37:10 <sputnik13> :-P 18:37:21 <sputnik13> #topic Bugs 18:37:29 <sputnik13> #link https://bugs.launchpad.net/cue/+bug/1467045 18:37:30 <openstack> Launchpad bug 1467045 in Cue "Rabbitmq cluster dont become active because of error 'tables_not_present'" [Medium,New] 18:37:50 <esmute> :plol 18:38:46 <sputnik13> esmute this is from almost 3 months ago 18:38:58 <sputnik13> do you know whether this is still happening? 18:39:19 <esmute> i havent seen it 18:39:36 <esmute> we used to see it a lot during the int test result 18:39:37 <sputnik13> isn't this an error related to the older rabbitmq we were previously using? 18:39:58 <sputnik13> I think this is no longer an issue 18:40:11 <sputnik13> there was also an issue with cloud-config restarting rabbit 18:40:19 <sputnik13> also resolved since this bug was filed 18:40:48 <sputnik13> so... we should close this for now... please reopen if you see it again 18:40:55 <esmute> yeah lets close it 18:41:03 <esmute> i havent see it and it has been probably fix by the new version 18:42:00 <sputnik13> hmm... it's kind of a "fix committed" 18:42:10 <sputnik13> but we didn't do anything specifically targeting this bug 18:42:10 <sputnik13> :( 18:42:22 <sputnik13> I'll just mark it as "won't fix" for now 18:42:41 <sputnik13> we need to get better at looking at and addressing bugs in a more timely manner so we can take credit for things like these :) 18:44:00 <esmute> got it :) 18:44:16 <esmute> you can have all the credits for now :) 18:44:33 <sputnik13> done, we have 15 minutes left, let's look at bugs that have been triaged but are unresolved 18:44:59 <sputnik13> I need to create a new filter for that 18:46:00 <sputnik13> http://bit.ly/1QDxCNl 18:46:27 <sputnik13> 2 bugs unresolved but not new, and medium or higher 18:46:40 <sputnik13> https://bugs.launchpad.net/cue/+bug/1466609 18:46:41 <openstack> Launchpad bug 1466609 in Cue "user supplied network is not validated before attaching" [High,Triaged] 18:46:46 <sputnik13> that is a high priority bug and still open 18:47:30 <esmute> so what was it decided here? 18:47:33 <sputnik13> we should try and get this closed this week 18:47:42 <sputnik13> esmute what do you mean 18:47:49 <esmute> to fix the bug 18:48:05 <sputnik13> the user needs to have access to the network 18:48:19 <sputnik13> I think we qualified that as the tenant of the user owning the network 18:48:19 <esmute> does cue validate and ensures the network belong to the tenant that is requesting the cluster creation? 18:48:26 <sputnik13> yes 18:48:29 <esmute> ok 18:48:46 <sputnik13> it's an or condition 18:48:49 <sputnik13> the user owns the network 18:48:50 <sputnik13> or 18:48:51 <sputnik13> it's public 18:48:58 <sputnik13> s/user/tenant 18:49:22 <sputnik13> public is an attribute on the network, so it should be something we can check 18:49:23 <esmute> ok 18:50:01 <sputnik13> I think the attribute is called "public" 18:50:03 <sputnik13> need to confirm 18:50:26 <sputnik13> oh, no, it's "shared" 18:50:52 <esmute> ok.. i would say the prio is medium since we dont have multiple network support yet 18:51:05 <sputnik13> no, priority was already agreed on 18:51:33 <sputnik13> we shouldn't keep changing things unless there's a really good reason to do so or new information since the decision 18:51:44 <esmute> ok.. are we trying to assign bugs to fixer? 18:51:44 <sputnik13> should have said "keep changing" 18:51:49 <sputnik13> err shouldn't 18:51:50 <sputnik13> :) 18:52:00 <sputnik13> action for sputnik13 to slow down typing 18:52:01 <sputnik13> :) 18:52:13 <sputnik13> esmute: right now yes 18:52:16 <esmute> give it to vipul 18:52:19 <sputnik13> heheh 18:52:20 <esmute> just because he is not here 18:52:22 <sputnik13> we want it done soon :) 18:52:41 <sputnik13> fearless leader has too many other things on his plate :) 18:53:41 <sputnik13> is this a difficult fix? 18:54:00 <sputnik13> it would be good to have it fixed this week, especially given how long it's been open 18:54:42 <esmute> i dont think it would be... there are are ways to check the owner of networks 18:54:46 <sputnik13> I'll take the bug, if I can't get it done I'll come and talk to one of you :) 18:55:12 <sputnik13> cool? 18:55:18 <sputnik13> we have 5 minutes and 1 bug left 18:55:20 <esmute> cool 18:55:24 <sputnik13> #link https://bugs.launchpad.net/cue/+bug/1426103 18:55:24 <openstack> Launchpad bug 1426103 in Cue "Validate UUID API parameter's at API layer instead of DB interface" [Medium,Confirmed] 18:55:40 <sputnik13> this is a medium bug and it has been open since february 18:56:13 <esmute> so this should be a validation in the api to see if this cluster exist 18:56:37 <esmute> and not let the DB blow up 18:56:41 <sputnik13> yes 18:56:42 <davideag_> abitha: was this fixed when you added additional wsme checks in api? 18:56:58 <sputnik13> so, do a lookup on the ID prior to creating the job 18:57:08 <abitha> no i dont think so. still the id type is string 18:57:19 <davideag_> ok 18:57:25 <sputnik13> is this something wsme can validate for us? 18:57:34 <sputnik13> I thought wsme would do type checking only 18:57:41 <sputnik13> not do database lookups 18:57:55 <abitha> we can modify that to uuid type if they have and fix this. 18:58:00 <sputnik13> I guess there's two aspects to this, the ID could just not be a UUID, which would be a type error 18:58:10 <davideag_> yes, there is a uuidtype in wsme 18:58:27 <sputnik13> there's a second aspect where the ID does not exist at all 18:58:36 <abitha> isnt this bug just for validating the type? 18:58:37 <sputnik13> the first can be caught by wsme 18:58:51 <davideag_> it's currently a string, therefore wsme will not complain 18:59:01 <davideag_> abitha: yes 18:59:20 <sputnik13> I don't know, the bug doesn't say whether it's just about a type check or a check on whether it even exists 18:59:38 <davideag_> the id not exisiting at all is already covered 18:59:40 <sputnik13> regardless, if the ID doesn't exist a job shouldn't get created 18:59:51 <sputnik13> davideag_: by the API? 18:59:56 <sputnik13> or the worker 18:59:59 <davideag_> sputnik13: never mind 19:00:09 <esmute> if its by the worker, then it would be too late 19:00:20 <esmute> should be done in the API... 19:00:20 <sputnik13> yes, it should be caught by the API 19:01:09 <davideag_> this affects cluster get and delete 19:01:12 <davideag_> nothing else 19:01:40 <esmute> we are out of time 19:01:45 <esmute> who wants to take this bug? 19:01:47 <sputnik13> davideag_: correct, but it should still be caught by the API 19:01:54 <abitha> I can 19:01:55 <sputnik13> I added a note about the 2 issues 19:01:55 <davideag_> sputnik13: yes 19:02:02 <esmute> abitha!!! 19:02:16 <sputnik13> ok time's up 19:02:20 <sputnik13> #endmeeting