17:08:14 <ruhe> #startmeeting murano
17:08:14 <openstack> Meeting started Tue Aug  5 17:08:14 2014 UTC and is due to finish in 60 minutes.  The chair is ruhe. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:08:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:08:17 <openstack> The meeting name has been set to 'murano'
17:08:17 <adrian_otto> jeblair, I did a #endmeeitng three times, but the openstack bot did not respond with links to the transcript
17:08:21 <jeblair> the bot died at 1617
17:08:34 <ruhe> ah, thanks jeblair! probably meeting ended, but didn't reply on that
17:08:34 <adrian_otto> oh, damn
17:08:57 <jeblair> followup in #openstack-infra
17:09:08 <ruhe> murano team, are you still here?
17:09:23 <sjmc7> hello
17:09:41 <slagun> hi
17:09:55 * tsufiev doesn't know to which degree he's still in murano team, but yes )
17:10:27 <katyafervent> Hello
17:10:29 <ruhe> tsufiev: you're driving rich UI which we need in Murano. you're part of the team!
17:10:44 <ruhe> #topic Action Items Review
17:10:52 <ruhe> katyafervent Extend the description of https://blueprints.launchpad.net/murano/+spec/murano-api-exception-handling
17:11:14 <ruhe> imho this BP still needs more details. thoughts?
17:11:17 <tsufiev> ruhe, ok )
17:11:24 <katyafervent> Right
17:11:37 <katyafervent> What exactly need to be provided?
17:11:42 <katyafervent> List of all exceptions?
17:11:54 <katyafervent> Or anything else?
17:11:58 <sjmc7> before we do that, i'd like to define what we expect to see
17:12:05 <sjmc7> currently if an error happens, as a user, it's really hard to tell
17:13:25 <ruhe> should we handle error handling and reporting as part of this BP? (i guess so). but then it becomes much bigger
17:14:09 <sjmc7> maybe it's different, but technical decisions should come from what we want to see happen where possible
17:14:28 <katyafervent> https://bugs.launchpad.net/murano/+bug/1328662 we also have this bug
17:14:31 <uvirtbot> Launchpad bug 1328662 in murano "[api] Should return JSON/XML error response bodies" [High,Confirmed]
17:14:36 <sjmc7> we have LOTS of exception modules
17:16:19 <ruhe> i agree that we need to spend more time on desing of error handling. let's put this BP on hold and take this discussion to other appropriate channel
17:16:55 <ruhe> ok?
17:17:09 <katyafervent> ok
17:17:28 <katyafervent> we can left it as part of design of new APi
17:17:42 <ruhe> #topic Juno-3 and release schedule
17:17:58 <ruhe> i've added this topic just to make sure that everyone's aware of the release schedule
17:18:08 <ruhe> #link https://launchpad.net/murano/+milestone/juno-3
17:18:14 <ruhe> #link https://wiki.openstack.org/wiki/Juno_Release_Schedule
17:18:29 <sjmc7> unfortauntely our internal release schedule is a bit off that
17:18:53 <ruhe> sjmc7: what's the official date?
17:19:20 <sjmc7> depends when i ask :)  i think dashboard code is frozen end of august, api sometime in september
17:19:58 <ruhe> so, it's almost the same as release of juno-3
17:20:17 <ruhe> but doesn't catch the time for bug fix window
17:20:51 <sjmc7> yeah. i'm not sure why we've ended up offset. most stuff is based of juno.2
17:20:55 <sjmc7> we'll deal with it somehow
17:22:11 <ruhe> ok. that was just a reminder. blueprints we have assigned for juno-3 are the only blueprints we'll be able to merge in juno. the rest of the time is dedicated for bug fixes and release candidates
17:22:23 <ruhe> let's move on
17:22:40 <ruhe> #topic defer https://blueprints.launchpad.net/murano/+spec/engine-test-based-on-murano-pythonclient
17:23:34 <ruhe> this blueprint suggest to use python-muranoclient in murano integration tests. initially it was written with custom REST client in the spirit of similar tests in Tempest
17:24:11 <ruhe> but from our practise running integration tests with actual python client helps to catch integration issues and make sure the client is compatible with the API
17:24:14 <ruhe> but
17:24:56 <ruhe> due recent (or long running) issues in murano-ci, i'd like to defer this BP for at least 2 weeks and make sure murano-ci is stable
17:25:20 <ruhe> thoughts?
17:26:13 <ruhe> i'll take that as a silent agreement :)
17:26:33 <ruhe> #agreed to defer https://blueprints.launchpad.net/murano/+spec/engine-test-based-on-murano-pythonclient to let murano-ci to become stable
17:26:52 <ruhe> #topic discuss new BP for juno-3 - migrate to oslo.db
17:27:30 <ruhe> most of core projects have done the migration or are in the process of migration to oslo.db
17:28:26 <ruhe> i think it'll help downstream deployments. i there is a bug found in the openstack/common/db, there is no need to patch every project, we'll only need to patch oslo.db
17:28:49 <sjmc7> and it's definitely going to be maintained?
17:29:00 <sjmc7> there's stuff in some oslo projects that seems to get written then abandoned
17:29:27 <ruhe> sjmc7: yes, i think so. what i definetely can say is - openstack/common/db is not going to be maintained
17:29:39 <ruhe> * in the long term
17:31:13 <ruhe> one of examples is oslo.messaging. it was a part of osloincubator for some time and was named rpc (afair), but it graduated to oslo.messaging and now all the projects are using it
17:31:24 <sjmc7> ok. yeah, we should keep up with other projects
17:33:39 <ruhe> anyone else?
17:33:58 <ruhe> i'll file a blueprint and approve it if there are no objections?
17:34:15 <sjmc7> do it!
17:35:06 <ruhe> i know that serge supports this BP too :)
17:35:08 <ruhe> ok
17:35:20 <ruhe> #agreed to migrate to oslo.db in juno-3
17:36:06 <ruhe> #topic Open discussion
17:37:19 <ruhe> unfortunately Serge and Stan were occupied with an internal product activities for a few days. I hope they'll get back in a day or two
17:38:35 <sjmc7> for open discussion.. we have some UI tweaks i got asked about last week. i listed them on the agenda (but only 2 minutes before the meeting, sorry)
17:39:26 <ruhe> ok. let's walk through each of them
17:39:36 <ruhe> 1. Dashboard rename
17:39:59 <ruhe> BP is approved and i think that we'll merge it as soon as pep8 issues are addressed
17:40:05 <sjmc7> ok
17:40:12 <ruhe> 2. Removing/hiding stats panel, at least for non-admins
17:40:44 <ruhe> i don't have any objections towards this feature. katyafervent, tsufiev what about you?
17:40:55 <sjmc7> not a huge deal, but it was felt it's a bit distracting in its current form, and needs some more thought
17:41:07 <katyafervent> No
17:41:12 <tsufiev> no objections
17:41:35 <tsufiev> is gokrokve_ fine with removing it?
17:41:37 <sjmc7> is this something best done at a settings level for now?
17:41:44 <sjmc7> assuming other people are using it
17:41:58 <ruhe> tsufiev: it's not about removing. it's about an option to hide statistics from users
17:42:29 <tsufiev> ruhe, and showing it to admins?
17:42:41 <gokrokve_> We need a way to provide these stats
17:42:57 <sjmc7> can we make it an admin-level thing?
17:43:09 <gokrokve_> The reason of hiding is not because it is not valuable but because API works nasty
17:43:39 <sjmc7> the reason we've been asked to hide it is that we don't see it as being useful to us right now
17:43:44 <gokrokve_> I am ok with showing it to admins only
17:43:48 <sjmc7> though i accept it is of use to others, so i'm not suggestng removal
17:44:18 <ruhe> config option to hide/show stats panel for users would be a nice solution
17:44:28 <tsufiev> gokrokve_, ruhe, sjmc7: 'API works nasty' sounds to me like a bug
17:44:38 <sjmc7> where did i say 'api works nasty'?
17:44:46 <ruhe> gokrokve_: said that :)
17:44:53 <gokrokve_> I told this
17:45:04 <gokrokve_> It works nasty because of sessions.
17:45:21 <sjmc7> personally i don't think it should be in the murano API at all, best left to ceilometer, but that's not an argument  i want to have
17:45:30 <tsufiev> sjmc7, i just wanted to point that it's not ok as it may seem
17:45:33 <ruhe> sjmc7: +1
17:45:48 <sjmc7> the session stuff also is something i don't like, but again, another day
17:46:07 <ruhe> now i feel that we shouldn't let statistics to land in their current form
17:46:11 <slagun> Don't blame session until you have a better idea how to implement or avoid them :)
17:46:26 <sjmc7> right slagun, that's why i said another day :)   so if people are ok in principle with either always limitign to admins, or making it configurable, we cna do either
17:46:34 <tsufiev> my opinion: is there is serious bug which cannot be fixed soon, it should be removed
17:46:41 <ruhe> did we agree to introduce a cofnig option to hide/show stats panel to users?
17:46:47 <ruhe> sjmc7: gokrokve_: tsufiev ^^
17:47:02 <gokrokve_> +1 hide it for now
17:47:11 <gokrokve_> allow only admin to see it
17:47:11 <ruhe> gokrokve_: hide it by default?
17:47:27 <gokrokve_> To non admin user - yes
17:47:31 <slagun> +1 for hiding, +100500 for API feature freeze
17:47:42 <tsufiev> gokrokve_, will showing it only for admins help to live with that bug?
17:47:43 <sjmc7> ok
17:47:52 <ruhe> gokrokve_: do you need a config option to show it for non admin users?
17:48:11 <gokrokve_> No
17:48:15 <ruhe> cool
17:48:21 <gokrokve_> Let's keep it bound to admins only
17:48:27 <ruhe> #agreed to hide stats panel from non-admin users by default
17:48:49 <gokrokve_> Eventually we just need to send these stats data to Ceilometer
17:48:49 <ruhe> 3. Mark images - can do it via glance CLI so not urgent, but it needs to be more flexible (email thread, no conclusion)
17:49:17 <sjmc7> there was some email discussion on this. stan had some good suggestions but they're beyond the scope of what we can do in the next few weeks
17:49:19 <gokrokve_> As there is no Ceilometer integration page for all OpenStack compoennts we need to show these stats by outselfes
17:49:22 <ruhe> that discussion didn't end with a conclusion
17:49:38 <sjmc7> so i think we may just limit ourselves to doing it via the glance CLI for now
17:49:45 <sjmc7> but i do think that it needs improvement
17:50:23 <gokrokve_> sjmc7: As you are using image based deployment we probably need more effectve image filtering in UI
17:51:07 <ruhe> graffiti might be what we need for image filtering
17:51:10 <sjmc7> yeah.. even if it was just free text it'd be easier
17:51:22 <sjmc7> yes, could be. so for now i think we can agree we'll just do it with the glance cli
17:51:31 <ruhe> sjmc7: ok
17:51:39 <ruhe> 4. Moving to Projects panel
17:51:43 <ruhe> i support that
17:52:20 <ruhe> just because we need to comform with the rest of the dashboard
17:52:43 <sjmc7> yeah. but it probably needs some more thought; packages, for example, don't belong to a project
17:52:46 <ruhe> i'm not sure about the amount of work, but i'd like this to be done at least early in K
17:52:50 <sjmc7> yeah
17:53:12 <ruhe> tsufiev: what do you think about this?
17:53:40 <sjmc7> i need to discuss it more with our prodct people. they may want to keep it separate
17:54:15 <tsufiev> ruhe, I know that the same thing was done for Sahara when it became integrated project
17:54:35 <ruhe> sahara had a separte dashboard. but once they became integrated and started to integrate sahara dashboard into horizon, they were told to move it under projects panel
17:55:03 <katyafervent> so we could be prepared
17:55:03 <sjmc7> right. so likely we will need to
17:55:04 <tsufiev> ruhe, the short answer is 'yes, we can' )
17:55:06 <gokrokve_> True, but after they are incubated, not before
17:55:33 <sjmc7> so let's agree to start thinking about it, get a plan during the summit if not before
17:56:39 <sjmc7> ok. that's me done
17:56:56 <ruhe> yeah, on one side we have the common layout of openstack dashboard on the other hand we have input from our product owners. we need to balance between both :)
17:57:27 <sjmc7> yup
17:57:32 <ruhe> anything else to discuss today?
17:57:53 <sjmc7> not from me
17:59:50 <ruhe> thanks everyone!
17:59:56 <ruhe> #endmeeting