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