18:01:27 <sputnik13> #startmeeting cue 18:01:28 <openstack> Meeting started Tue Aug 4 18:01:27 2015 UTC and is due to finish in 60 minutes. The chair is sputnik13. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:31 <openstack> The meeting name has been set to 'cue' 18:01:42 <sputnik13> role call 18:01:45 <davideagnello> here 18:01:46 <sputnik13> o/ 18:01:48 <vipul> o/ 18:01:50 <dkalleg> o/ 18:01:52 <davideagnello> o/ 18:02:15 <esmute_> hey 18:02:46 * sputnik13 pokes abitha 18:03:13 <abitha> hihi 18:03:35 <sputnik13> actions 18:03:41 <sputnik13> #topic Action Items 18:03:58 <sputnik13> oh yay, they're all for me 18:04:06 <sputnik13> #link http://eavesdrop.openstack.org/meetings/cue/2015/cue.2015-07-21-18.01.html 18:04:42 <sputnik13> #info AI #1 sputnik13 to fill in details for https://blueprints.launchpad.net/cue/+spec/kafka 18:04:53 <sputnik13> kicking that can a little further down the road 18:04:57 <sputnik13> #action sputnik13 to fill in details for https://blueprints.launchpad.net/cue/+spec/kafka 18:05:09 <sputnik13> #info AI #2 sputnik13 to follow up on confirming https://bugs.launchpad.net/cue/+bug/1429304 18:05:09 <openstack> Launchpad bug 1429304 in Cue "Error 400 Bad Request when adding a limit to the cluster list URL" [Medium,Incomplete] - Assigned to Steve Leon (steve-leon) 18:05:09 <uvirtbot> Launchpad bug 1429304 in cue "Error 400 Bad Request when adding a limit to the cluster list URL" [Medium,Incomplete] 18:05:11 <uvirtbot> Launchpad bug 1429304 in cue "Error 400 Bad Request when adding a limit to the cluster list URL" [Medium,Incomplete] https://launchpad.net/bugs/1429304 18:05:31 <sputnik13> kicking this one down the road too... 18:05:34 <sputnik13> #action sputnik13 to follow up on confirming https://bugs.launchpad.net/cue/+bug/1429304 18:05:51 <sputnik13> #info AI #3 sputnik13 to file a BP for user defined credentials for brokers 18:06:11 <esmute_> sputnik13: i have to fix this bug :P 18:06:36 <sputnik13> BP was filed 18:06:37 <sputnik13> #link https://blueprints.launchpad.net/cue/+spec/custom-default-user 18:06:47 <vipul> esmute_: so it's indeed a bug? 18:06:52 <sputnik13> esmute_: the action was for me to verify it... I was actually just going to talk to you :) 18:06:54 <vipul> how does the dashboard work 18:07:04 <davideagnello> looks more like a feature of the api 18:08:09 <esmute_> the dashboard has the ability to send filter parameters 18:08:16 <sputnik13> davideagnello it's a bug if the dashboard breaks 18:08:24 <vipul> are we just hacking the dashbaord to remove those? 18:08:36 <esmute_> so when there is no filter, it sends an empty parameters.. and i think cue api doesnt handle that 18:09:07 * esmute_ is looking at the code 18:09:37 <vipul> esmute_: i think the main quesiton is if this is actually a bug breaking the dashboard today or not 18:09:51 <esmute_> it is not breaking the dashboard 18:09:51 <vipul> esmute_: if it's not breaking.. then the real fix is to implement pagination to our api 18:10:02 <sputnik13> which is then a feature no longer a bug 18:10:07 <esmute_> i need to see what i did to circumvent this issue 18:10:24 <vipul> ok.. can you add that as a comment to the issue 18:10:25 <sputnik13> so you're saying there is a fix right now 18:10:35 <sputnik13> and things are not broken 18:10:59 <esmute_> sputnik13: more like a subclass/override in horizon 18:11:30 <sputnik13> esmute_: however graceful or hacky the fix is, dashboard is not broken at this time? 18:11:45 <esmute_> but it is not the right way to do this... the right way is for cue api to handle these filters params, which are typically handled in all openstack api 18:11:55 <esmute_> sputnik13: no.. dashboard is not broken 18:12:08 <esmute_> i found this bug when i was working on the dashboard a few months back 18:12:10 <vipul> yea we need a blueprint for adding pagination.. 18:12:12 <sputnik13> ok, then this should be a feature for the api 18:12:22 <davideagnello> exactly 18:13:07 <sputnik13> I will reclasiffy it as wishlist... please add a blueprint and add a link to it in the bug 18:13:09 <esmute_> it could be a bug because horizon assumes the api handles filter params 18:13:22 <esmute_> i am ok labelling a bug but a really low priority one 18:13:36 <esmute_> at least for the case to handle these params from horizon 18:14:20 <vipul> we have a workaround.. and it likely could be solved more completely by a feature 18:14:21 <sputnik13> it's not a bug if there isn't a defect 18:14:36 <esmute_> after looking at the code, the workaround im using is importing keystone client directly 18:14:55 <esmute_> and not use the provided client frameworok/library within horizon 18:15:53 <vipul> ok moving on? 18:15:59 <davideagnello> so a bug in our panel and feature in our api? 18:16:07 <esmute_> oopps not keystoneclient... cueclient 18:16:12 <sputnik13> it's not a bug in the panel, the panel works 18:16:34 <sputnik13> yes let's move on, we're talking this to death 18:16:46 <sputnik13> next on the agenda is discussion topics... 18:16:48 <esmute_> the panel works because im using the client directly rather than the using the provided framework 18:16:50 <esmute_> but year.. 18:16:53 <esmute_> yeah.. 18:16:53 <sputnik13> #topic Discussion Topics 18:17:02 <sputnik13> do we have any topics to discuss? 18:17:35 <sputnik13> we have 4 or 5 talks submitted specifically for Cue, anyone know when we find out the results? 18:17:51 <sputnik13> seems like tallying the votes should be automatic, why don't they have result pretty much the same day? 18:18:03 <vipul> i'm sure it'll be a while 18:18:06 <vipul> like every other time 18:18:22 <sputnik13> and like every other time people are probably wondering why it takes so long 18:19:04 <sputnik13> meh... 18:19:13 <sputnik13> no topics? 18:19:27 <sputnik13> let's move on to bugs then 18:19:39 <sputnik13> #info no topics this week 18:19:39 <esmute_> dkalleg is working on changing the status check for rabbitmq 18:20:05 <esmute_> dkalleg: do you want to talk a bit about it? 18:20:13 <dkalleg> Yup, I believe its working, just looking into an integration test failure. 18:20:33 <sputnik13> doh, how do you redact items from the log 18:20:47 <vipul> dkalleg: what user are we checking the status with 18:20:59 <vipul> didn't we talk about creating a monitoring user at some point 18:21:03 <esmute_> dkalleg: do you have a bug associated to this work? 18:21:17 <sputnik13> it's not a bug 18:21:28 <esmute_> sputnik13: is there a BP then? 18:21:50 <esmute_> i just want something with some information to understand the problem and the fix 18:21:52 <sputnik13> https://blueprints.launchpad.net/cue/+spec/status 18:22:08 <dkalleg> So while taskflow is creating a cluster, I've added a task that will use RMQs rest api to use its management plugin to run an aliveness test. 18:22:23 <sputnik13> dkalleg: can you fill in some information in https://blueprints.launchpad.net/cue/+spec/status 18:22:31 <sputnik13> and link your patch to that 18:22:37 <sputnik13> make sure it's a partial-implement 18:22:59 <davideagnello> we would need to add the periodic checks 18:23:02 <sputnik13> since the BP is for ongoing status, a more accurate status for initial boot is related 18:23:13 <dkalleg> esmute_: its not a bug, the feature isn't ready yet 18:23:13 <sputnik13> since we'd likely use the same checks except on a periodic basis 18:23:33 <davideagnello> yes 18:23:40 <vipul> yea we need to get better about filing BPs and actually filling them out :D 18:23:52 <sputnik13> right we're doing the filing 18:23:56 <sputnik13> not so much on the filling 18:24:14 <sputnik13> it's a one letter difference how hard could it be?! ;) 18:24:38 <vipul> dkalleg: you got this? 18:24:56 <dkalleg> vipul: Yes 18:25:26 <sputnik13> #action dkalleg to provide details in https://blueprints.launchpad.net/cue/+spec/status regarding more accurate rabbitmq status check 18:25:36 <sputnik13> other topics? 18:25:45 <vipul> what's going on with Rally gate 18:25:56 <sputnik13> #topic Rally gate 18:26:02 <sputnik13> davideagnello? 18:26:22 <sputnik13> err doh, that should have been info, meh whatever 18:26:41 <vipul> topic is correct 18:26:44 <davideagnello> yes, there is a patch in openstack infra that is currently out. it's failing a layout test. need to find out why my changes are causing this issue 18:27:03 <davideagnello> #link https://review.openstack.org/#/c/201285/2 18:27:15 <esmute_> ill work with davideagnelloto to help him with this layout issue 18:27:16 <sputnik13> vipul: too bad you can't do nested topics, we're in the "discussion topic" portion of the meeting, this is arguably a sub-topic :) 18:27:45 <davideagnello> ok, thanks esmute_ 18:27:49 <vipul> http://logs.openstack.org/85/201285/8/check/gate-project-config-layout/5dfef14/console.html#_2015-07-31_20_23_09_659 18:28:16 <vipul> it's probably because we use a job template.. and maybe need to name the job corectly in layout.yml 18:28:33 <vipul> esmute_: thanks.. 18:28:41 <vipul> davideagnello: esmute_ let's try to get this working asap 18:28:44 <vipul> it's been a while 18:28:45 <davideagnello> it is named correctly 18:28:58 <sputnik13> why is it gate-rally-dsvm-cue-cue? 18:29:10 <sputnik13> should be gate-rally-dsvm-{name} 18:29:32 <davideagnello> that's what the name in template, name is replaced with cue, like other services use the same pattern 18:29:40 <esmute_> actually should be should be gate-rally-dsvm-cue-{name} 18:29:50 <esmute_> name=<broker> 18:30:12 <esmute_> so we can run this job with different broker in the future 18:30:15 <vipul> hmm.. in layout.yml you don't parameterize things 18:30:23 <sputnik13> that seems silly to have cue-cue 18:30:38 <vipul> then the job template needs to change 18:31:23 <esmute_> davideagnello: look at https://review.openstack.org/#/c/180774/ 18:31:29 <sputnik13> cue-<broker> makes sense 18:31:32 <esmute_> this is how i configured it for the tempest test 18:31:53 <vipul> esmute_: i agree with that.. 18:32:00 <vipul> we may need to rename our scenarios then 18:32:19 <vipul> if we want to use the {name} for the scenario file too 18:32:28 <davideagnello> our scenario test file, which conforms to the rest of the services naming is service-rally.yaml 18:32:55 <esmute_> looking at https://review.openstack.org/#/c/180774/3/zuul/layout.yaml,cm, im appending the broker name in the job 18:32:55 <vipul> davideagnello: couldn't we have rabbitmq-scenarios.yml? 18:33:25 <vipul> so that we can have kafka-scenarios.yaml in the future? 18:33:39 <davideagnello> we can 18:34:26 <vipul> esmute_, davideagnello: can you guys sync up and fix this..? 18:34:40 <davideagnello> yes 18:34:43 <esmute_> yep 18:35:32 <sputnik13> #action davideagnello and esmute_ to resolve issues with https://review.openstack.org/#/c/201285 18:35:48 <sputnik13> other topics? 18:36:14 <sputnik13> bugs? 18:36:22 <vipul> python3? 18:36:32 <vipul> anyone want to take a stab at getting things working with python3? 18:36:41 <davideagnello> what working? 18:36:49 <davideagnello> cue? 18:36:51 <vipul> cue.. tests.. 18:36:56 <sputnik13> is that a trick question? :) 18:37:10 <sputnik13> "want" :) 18:37:15 <vipul> everyone's doing it ;) 18:37:44 <vipul> think of it as a side pet-project ;) 18:37:49 <sputnik13> the silence is deafening 18:37:52 <esmute_> haha 18:38:18 <vipul> next person to say something takes it 18:38:26 <esmute_> vipul: is openstack pushing this on us? 18:38:32 <esmute_> crap 18:38:32 <vipul> esmute_: it is! 18:38:33 <sputnik13> can we add python 3 as a tox env and make it none-voting? 18:38:45 <sputnik13> esmute_ just volunteered didn't he 18:38:50 <vipul> esmute_: openstack is going this way.. 18:38:53 <vipul> he did 18:39:02 <esmute_> haha ok 18:39:02 <sputnik13> esmute_ you rock 18:39:04 <sputnik13> :) 18:39:18 <sputnik13> we should just add python 3 as a tox environment and make it non-voting (if that's possible) 18:39:26 <vipul> esmute_: not critical path.. it might be as simple as adding a new tox env 18:39:33 <vipul> sputnik13: yep 18:39:35 <sputnik13> then the gate jobs will just tell us if/when it's broken 18:39:39 <sputnik13> and we can fix things as we go 18:39:41 <esmute_> yeah.. probably going start there 18:40:00 <vipul> it's possible the python-jobs job template already makes py3 non-voting/ 18:40:01 <vipul> not sure 18:40:02 <sputnik13> #topic python3 18:40:36 <sputnik13> #action esmute_ to add a non-voting python3 check to CI 18:41:37 <sputnik13> other topics 18:41:39 <sputnik13> ? 18:41:50 <vipul> esmute_: https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L307 18:41:56 <sputnik13> I'd say Kafka but someone keeps slipping on that action :) 18:42:30 <esmute_> ok 18:42:46 <vipul> esmute_: lots of projects already gating on it 18:42:52 <vipul> so just look at waht they did 18:43:12 <sputnik13> all of oslo is doing it, but it's voting in oslo 18:43:30 <sputnik13> moving on to bugs then? 18:43:36 <vipul> if we get it working.. i don't mind making it voting 18:43:39 <vipul> not reason not to 18:43:48 <sputnik13> right, once we get it working 18:43:50 <esmute_> yeah. 18:43:59 <esmute_> i wont check it in until it works anyways 18:44:27 <vipul> ok sounds like we have a plan 18:44:36 <sputnik13> we should just add it and make it non-voting until it works 18:44:47 <sputnik13> we shouldn't have a single outstanding patch that tries to make everything work 18:44:54 <sputnik13> it'll get stuck in rebase hell 18:45:05 <sputnik13> well, maybe 18:45:06 <sputnik13> :) 18:45:22 <vipul> maybe add a patch to the experimental pipeline now.. 18:45:36 <sputnik13> the what pipeline? 18:45:38 <vipul> and when you submit your patch.. you can check it 18:45:59 <esmute_> ok 18:46:03 <esmute_> that is good too 18:46:15 <sputnik13> ok, you mean add the python 3 check to the experimental pipeline so that it runs with every subsequent patch to cue, yes? 18:46:25 <vipul> right.. sputnik13 18:46:29 <vipul> i didn't say that well 18:46:40 <sputnik13> ok, good plan, let's move on to bugs, we have 14 minutes left 18:46:52 <sputnik13> #topic Bugs 18:47:02 <sputnik13> https://bugs.launchpad.net/cue/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.importance%3Alist=CRITICAL&field.importance%3Alist=HIGH&field.importance%3Alist=MEDIUM&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator 18:47:04 <sputnik13> =ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search 18:47:04 <sputnik13> wow, big link :) 18:47:28 <sputnik13> http://bit.ly/1MChDwJ 18:48:03 <sputnik13> #link https://bugs.launchpad.net/cue/+bug/1438939 18:48:04 <openstack> Launchpad bug 1438939 in Cue "Cue CLI cluster list fields should show cluster size" [Medium,New] 18:48:04 <uvirtbot> Launchpad bug 1438939 in cue "Cue CLI cluster list fields should show cluster size" [Medium,New] 18:48:05 <uvirtbot> Launchpad bug 1438939 in cue "Cue CLI cluster list fields should show cluster size" [Medium,New] https://launchpad.net/bugs/1438939 18:48:29 <vipul> agree with showing as much as possilbe on a list 18:48:33 <sputnik13> that's annoying, why is uvirbot doing the same thing as openstack 18:48:34 <vipul> network_id maybe not 18:49:02 <sputnik13> agree on the enhancements, but this is not a bug 18:49:45 <sputnik13> reclassify to wishlist, and add blueprint? 18:49:46 <vipul> wishlist is fine.. i would say high priority 18:50:02 <vipul> it's kind of a usability issue right now 18:50:02 <sputnik13> wishlist is a "priority" 18:50:13 <vipul> ugh 18:50:16 <sputnik13> :) 18:50:33 <davideagnello> I have resolved a cluster delete bug over a month ago, it's still in review (https://review.openstack.org/#/c/196332/) should we drop it or are we looking to merge this work? 18:50:39 <sputnik13> it is what it is... I don't feel like submitting enhancements to launchpad ;) 18:51:13 <vipul> ok.. wishlist and file a BP.. 18:51:36 <sputnik13> davideagnello can you turn that in to a BP and link the bug? 18:51:39 <sputnik13> https://bugs.launchpad.net/cue/+bug/1438939 18:51:39 <uvirtbot> Launchpad bug 1438939 in cue "Cue CLI cluster list fields should show cluster size" [Medium,New] 18:51:40 <openstack> Launchpad bug 1438939 in Cue "Cue CLI cluster list fields should show cluster size" [Wishlist,New] 18:51:42 <uvirtbot> Launchpad bug 1438939 in cue "Cue CLI cluster list fields should show cluster size" [Medium,New] https://launchpad.net/bugs/1438939 18:51:44 <vipul> davideagnello: sounds like we are looking to merge it.. it was rebased recently 18:51:54 <davideagnello> ok 18:52:08 <sputnik13> yes I think I rebased it during the liberty 2 day 18:52:12 <davideagnello> sputnik13: turn bug into BP? 18:52:17 <sputnik13> yes, it's not a bug 18:52:32 <davideagnello> it is a bug 18:52:41 <vipul> are we talking about the same bug? 18:52:48 <sputnik13> we're talking about https://bugs.launchpad.net/cue/+bug/1438939 18:52:48 <openstack> Launchpad bug 1438939 in Cue "Cue CLI cluster list fields should show cluster size" [Wishlist,New] 18:52:48 <uvirtbot> Launchpad bug 1438939 in cue "Cue CLI cluster list fields should show cluster size" [Medium,New] 18:52:50 <uvirtbot> Launchpad bug 1438939 in cue "Cue CLI cluster list fields should show cluster size" [Medium,New] https://launchpad.net/bugs/1438939 18:52:54 <davideagnello> https://bugs.launchpad.net/cue/+bug/1469823 18:52:54 <openstack> Launchpad bug 1469823 in Cue "Delete Cluster fails when Cluster contains VM's which have already been deleted" [High,Confirmed] - Assigned to Davide Agnello (dagnello) 18:52:55 <uvirtbot> Launchpad bug 1469823 in cue "Delete Cluster fails when Cluster contains VM's which have already been deleted" [High,Confirmed] 18:52:56 <uvirtbot> Launchpad bug 1469823 in cue "Delete Cluster fails when Cluster contains VM's which have already been deleted" [High,Confirmed] https://launchpad.net/bugs/1469823 18:53:05 <sputnik13> davideagnello please stay with one bug at a time 18:53:26 <vipul> sputnik13's link shoudl be a BP.. 18:53:34 <vipul> your link is a bug 18:53:47 <davideagnello> ok 18:54:07 <abitha> why is it a BP and not a bug? 18:54:31 <vipul> abitha: it's kind of a feature.. because we want to expose more in our CLI 18:54:32 <sputnik13> abitha it's not a defect, a poor design choice is not a defect 18:54:36 <sputnik13> :) 18:54:53 <sputnik13> nothing is "broken", although I guess UX might argue the experience is broken 18:54:54 <sputnik13> :) 18:55:04 <abitha> so lot of bugs classified as wishlist seems to be features then. 18:55:28 <abitha> so should we create BPs for those? 18:55:34 <vipul> yea that's what wishlist is for.. 18:55:45 <vipul> create BPs.. and start pushing fixes for those BPs 18:55:49 <sputnik13> right, anything we make wishlist is a feature, priority of the feature needs to be considered separately from priority of defects 18:56:09 <abitha> oh ok 18:56:20 <sputnik13> #action davideagnello to file a BP for https://bugs.launchpad.net/cue/+bug/1438939 18:56:20 <openstack> Launchpad bug 1438939 in Cue "Cue CLI cluster list fields should show cluster size" [Wishlist,New] 18:56:23 <uvirtbot> Launchpad bug 1438939 in cue "Cue CLI cluster list fields should show cluster size" [Medium,New] 18:56:24 <vipul> if it's low-hanging fruit.. just fix it and push it up 18:56:25 <uvirtbot> Launchpad bug 1438939 in cue "Cue CLI cluster list fields should show cluster size" [Medium,New] https://launchpad.net/bugs/1438939 18:56:43 <sputnik13> right, as long as it actually takes only a little time 18:56:53 <sputnik13> ok, next bug 18:56:55 <sputnik13> we have 4 minutes 18:56:56 <vipul> we need to start looking at these during planning 18:57:04 <sputnik13> vipul agreed 18:57:07 <sputnik13> https://bugs.launchpad.net/cue/+bug/1444140 18:57:07 <openstack> Launchpad bug 1444140 in Cue "Add unit/function tests for DB Mixin classes" [Medium,New] 18:57:08 <uvirtbot> Launchpad bug 1444140 in cue "Add unit/function tests for DB Mixin classes" [Medium,New] https://launchpad.net/bugs/1444140 18:57:09 <uvirtbot> Launchpad bug 1444140 in cue "Add unit/function tests for DB Mixin classes" [Medium,New] 18:57:18 <davideagnello> we should 18:57:30 <sputnik13> this one is also not a bug 18:57:39 <sputnik13> changing to wishlist 18:57:41 <esmute_> why not use cue-show for these extra info? 18:57:58 <vipul> wait.. missing tests is a bug 18:58:07 <sputnik13> is it? 18:58:16 <vipul> this is python ;) 18:58:23 <vipul> if there is no test for it.. it doesn't work 18:58:37 <sputnik13> meh 18:58:37 <vipul> if it aint tested.. it's broken 18:59:02 <sputnik13> fine I will concede that point 18:59:04 <vipul> esmute_: that's the workaround.. but it would be nice to have more info in the cue-list call 18:59:05 <sputnik13> however, the product is not broken 18:59:05 <davideagnello> about 10% cue is broken then 18:59:10 <sputnik13> so it's low priority 18:59:22 <vipul> davideagnello: yep.. that is correct :D 18:59:45 <sputnik13> if cue does not use the 10% of code that is "broken" then the product isn't broken 18:59:46 <vipul> if it's indirectly tested.. then we cna discuss it 18:59:52 <esmute_> just 105? 18:59:55 <esmute_> 10%? 19:00:03 <sputnik13> esmute_ we have 90% coverage 19:00:08 <vipul> coverage is one thing.. 19:00:16 <vipul> not all the tests we run report coverage 19:00:19 <esmute_> so generous 19:00:22 <vipul> tempest and rally are the examples 19:00:22 <sputnik13> ok we're out of time 19:00:30 <vipul> the only coverage report we get is via unit tests 19:00:50 <sputnik13> vipul: while true I think the tempest tests we have are actually covered by our unit/functional tests 19:01:03 <sputnik13> reclassify this to low, agreed? https://bugs.launchpad.net/cue/+bug/1460208 19:01:03 <openstack> Launchpad bug 1460208 in Cue "cue-manage broker add command does not return new broker id" [Medium,New] 19:01:08 <vipul> yep 19:01:18 <uvirtbot> Launchpad bug 1460208 in cue "cue-manage broker add command does not return new broker id" [Medium,New] https://launchpad.net/bugs/1460208 19:01:19 <uvirtbot> Launchpad bug 1460208 in cue "cue-manage broker add command does not return new broker id" [Medium,New] 19:01:20 <sputnik13> there's no functional/observable failure in the product itself 19:01:40 <vipul> let's move to #openstack-cue 19:01:44 <sputnik13> ok 19:01:47 <sputnik13> #endmeeting