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