17:03:02 <ruhe> #startmeeting murano
17:03:04 <openstack> Meeting started Tue Jun  3 17:03:02 2014 UTC and is due to finish in 60 minutes.  The chair is ruhe. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:03:08 <openstack> The meeting name has been set to 'murano'
17:03:22 <ruhe> #link https://wiki.openstack.org/wiki/Meetings/MuranoAgenda#Agenda
17:03:36 <ruhe> roll call: done :)
17:04:02 <ruhe> one moment, need to invite more peopel
17:04:37 <ruhe> #topic action items review
17:04:54 <ruhe> 1. btully to create blueprints extracted from generic
17:05:14 <dteselkin> Hi
17:05:14 <ruhe> #info btully created blueprints extracted from generic https://blueprints.launchpad.net/murano/+spec/murano-ui-horizon-patterns
17:05:25 <ruhe> those BPs are scheduled for juno-1
17:05:34 <ruhe> 2. ruhe create blueprint for external repositories
17:06:14 <ruhe> #info ruhe created BP for online repo: https://blueprints.launchpad.net/murano/+spec/online-app-repository design is still drafting
17:06:32 <ruhe> also, there was an AI on me - mark murano-dsvm job as voting
17:06:43 <ruhe> here is a patch to infra https://review.openstack.org/#/c/97462/
17:06:58 <ruhe> once it is merged we will not be able to merge changes in Murano which breake murano-dsvm job in Jenkins. which is good
17:07:26 <ruhe> i don't see any other action items from previous meetings
17:08:01 <ruhe> #topic juno-1 status review
17:08:11 <ruhe> #link https://launchpad.net/murano/+milestone/juno-1
17:08:20 <ruhe> overall we're doing good
17:08:50 <ruhe> i'm a bit concerned about a bunch of UI blueprints in "Unknown" state. btully: do you have any update on those?
17:10:05 <btully> which ones? i'm not clear on "state" is that something that gets set on the blueprint?
17:10:22 <tsufiev> btully, he means 'Delivery' status
17:10:32 <ruhe> btully: ah. i should've tell you about that :)
17:11:08 <ruhe> btully: when you look at the list of blueprints at https://launchpad.net/murano/+milestone/juno-1 there is "Delivery" column
17:11:40 <ruhe> btully: common practice is to set the "delivery" field in "Started" once you started working on a blueprint
17:11:52 <ruhe> even if there are no patches on review
17:11:52 <btully> ok, how do i do that?
17:12:17 <btully> i don't see a "delivery" field
17:12:19 <ruhe> btully: just open the blueprint and update field "Implementation" to "Started"
17:12:27 <btully> ahh ok
17:12:29 <ruhe> that's launchpad, it's messy :)
17:12:30 <btully> thanks
17:13:08 <ruhe> anything else to discuss on the current topic?
17:13:35 <tsufiev> btully, also gerrit updates status automatically, if you write the appropriate line in commit message and send it to review
17:13:56 <tsufiev> line is 'Implements: blueprint name-of-blueprint'
17:14:50 <ativelkov> "Targets blueprint: name-of-blueprint" is better
17:15:09 <ativelkov> If the checking does not address the BP completely
17:15:15 <ativelkov> check-in*
17:15:25 <btully> thanks, good to know
17:15:39 <tsufiev> anyways, you can read those tips at https://wiki.openstack.org/wiki/Gerrit_Workflow
17:16:03 <ruhe> #topic ID and GUID usage discussion
17:16:12 <ruhe> katyafervent: that's your topic. please go ahead
17:16:22 <btully> so for those items I haven't looked at yet, do i leave them as Unknown or do i need to change them to "Not Started"
17:16:29 <katyafervent> here is the etherpad https://etherpad.openstack.org/p/murano-quid-discussion
17:16:59 <ruhe> btully: either is ok. i'd suggest "Not Started"
17:17:30 <btully> k
17:17:35 <katyafervent> this topic brought from bug scrub and here is a bug https://bugs.launchpad.net/murano/+bug/1319677
17:17:46 <sjmc7> i don't think database performance is much of a consideration with UUIDs - being similar to other openstack services has some advantages though
17:18:14 <katyafervent> what do you think, should we make our ids in guid format?
17:18:31 <tsufiev> sjmc7, there was one issue related directly to uuid length - so that question arised
17:18:33 <sjmc7> i think if we're going to use uuids, we should format them as guids
17:18:35 <ativelkov> what was the reason behind our own id generator?
17:18:56 <ativelkov> stan_lagun: sergmelikyan: do you rmemeber?
17:19:02 <sjmc7> there are openstack utility functions for handling them (heat tests if a stack id is a guid or a stack name, for instance)
17:19:18 <stan_lagun> why should we care? IDs are not GUIDs. They are just unique strings. Therir format should not be constraint in any way
17:19:34 <sjmc7> they'rein URLs
17:19:38 <sjmc7> they must be constrained in some ways
17:19:49 <katyafervent> sorry this is a valid link https://bugs.launchpad.net/murano/+bug/1292009
17:20:00 <gokrokve> There was a discussion in Solum and TripleO about using UUIDs as a primary key
17:20:12 <gokrokve> te reason to use int ID was the performance
17:20:40 <ruhe> stan_lagun: imho consistency across openstack projects is a constraint. thus i'd prefer to go with UUID, unless there is a strong argument not to use them
17:21:02 <sjmc7> did anyone measure the performance impact? i would wager than UUID lookups are not the bottleneck for most services
17:21:40 <tnurlygayanov__> sjmc7, for uids?
17:21:45 <gokrokve> Clint from TripleO had some reasons to propose integer IDs.
17:21:55 <stan_lagun> I don't suggest not to use UUIDs. I'm just saying that exact format (with or without dashes) is not important. Another implementation can generate random string or sequence numbers converted to string and that should be fine
17:22:02 <gokrokve> Indexing performance was among these reasons
17:22:09 <sergmelikyan> I think what to use as pkey  in the database - is does not matter. But ID for entities should not be bound to UUID
17:22:25 <stan_lagun> We should not REQUIRE dashes or any particular ID format
17:22:31 <tnurlygayanov__> I think the uids will not affect perofrmance itself
17:22:43 <sjmc7> are names unique?
17:22:56 <stan_lagun> what names?
17:23:10 <sjmc7> do all entities have unique names?
17:23:16 <stan_lagun> no
17:23:31 <stan_lagun> just unique ID
17:23:32 <sergmelikyan> I am against using UUID as ID for Object Model entities
17:23:55 <tsufiev> sergmelikyan, why?
17:23:56 <ruhe> sergmelikyan: stan_lagun: what are the arguments not to use UUID?
17:24:11 <stan_lagun> ID can be any string if that string is relatively short and unique within that object model
17:24:50 <sergmelikyan> tsufiev, because object model may be written manually? Because shorten IDs may be much easily consumed in demos?
17:24:58 <stan_lagun> ruhe, again, I'm not saying not to use UUID. You can use anything that is unique including UUID. We shouldn't care
17:25:04 <ativelkov> For readability we can define some human-readable IDs
17:25:15 <tsufiev> sergmelikyan, nobody forces us to use genuine UUIDs in demos :)
17:25:27 <ativelkov> it's up to the API users to generate them
17:25:50 <stan_lagun> for example for tests it is better to use ids like 'postgreSql1' instead of GUID
17:25:54 <sergmelikyan> yep, so why constrain them with UUID?
17:26:43 <tsufiev> simple IDs are fine as long as you can guarantee that they are limited to the scope of one Application
17:26:55 <sjmc7> the API is generating IDs, right?
17:26:57 <sjmc7> not users
17:27:03 <stan_lagun> we do use UUIDs. But there is no need to enforce it or require some particular formatting
17:27:14 <sergmelikyan> sjmc7, no, IDs are generated by users
17:27:27 <stan_lagun> IDs are generated by dashboard :)
17:27:34 <stan_lagun> not by end user
17:27:49 <tsufiev> stan_lagun, and it uses dashless UUIDs
17:27:51 <stan_lagun> maybe someday API will generate them
17:29:03 <stan_lagun> tsufiev And if you make it just random string everything will still work
17:29:09 <sjmc7> the reasons i see for using GUIDs is that it's easy to identify them in logs, URLs etc. other than that, i don't really care, but i think that since they're going to be generated by the dashboard or muranoclient they will have some predfined format
17:29:34 <ruhe> i haven't seen any argument not to use UUID as id in Murano. i suggest we proceed and let katyafervent to do what she planned to do
17:29:52 <tsufiev> sjmc7, yes, kind of a convention
17:31:06 <ruhe> let's move on. this discussion doesn't move to something constructive
17:31:23 <sergmelikyan> ruhe +1
17:31:58 <ruhe> everyone please state your thoughts in that document https://etherpad.openstack.org/p/murano-quid-discussion
17:32:12 <ruhe> #topic Open Discussion
17:33:12 <ruhe> i can give an update on alembic migrations. patch is finished basically, but for some reason it works everywhere except the gate
17:33:32 <ruhe> so, i'm blocked on https://review.openstack.org/#/c/97251/ which would let me to debug the problem
17:34:00 <ruhe> i'll continue with setting up unit-testing infrastructure for DB layer
17:34:08 <tsufiev> ruhe, it seems it's not the only problem with the gate (at least today) :)
17:34:59 <ruhe> tsufiev: yeah. another important topic for us is the state of murano-ci
17:35:14 <ruhe> tnurlygayanov__: can you give an update on murano-ci?
17:35:29 <tnurlygayanov__> yes
17:35:38 <tsufiev> ruhe, actually i meant Jenkins zuul, but you're also right :)
17:35:43 <tnurlygayanov__> so, right now we have some problems and we work on it
17:36:13 <ruhe> tnurlygayanov__: any estimates? when will it become stable?
17:36:20 <tnurlygayanov__> I see now some new commits for dashboard tests with fixes
17:37:07 <tnurlygayanov__> yes, 1-2 days and murano-ci will works for all commits
17:37:14 <ruhe> tnurlygayanov__: so, the idea is - we ask developers to update selenium tests whenever their patch breaks the tests?
17:37:45 <tnurlygayanov__> today we fix big problem with RabbitMQ connectivity and started to create CI job for tests with deployment in new CI
17:38:07 <tnurlygayanov__> ruhe, yes, and QA team will help to update tests
17:38:19 <tnurlygayanov__> in the same patch set
17:38:32 <ruhe> tnurlygayanov__: ok. thank you
17:38:53 <tnurlygayanov__> because it is only one way to save our CI tests green
17:40:14 <sjmc7> i have something for open discussion if we're done with CI
17:40:45 <ruhe> sjmc7: yes, please go ahead
17:41:07 <sjmc7> regarding testing also - i'd like some base classes to make it easier to run unit tests on the API
17:41:20 <sjmc7> i can do them unless someone else is desperate to
17:41:58 <sjmc7> currently we don't really have any test functions for the API other than the integration tests
17:42:46 <sjmc7> just stuff like faking context, setting up an inmemory database
17:43:23 <sjmc7> if anyone has thoughts or input i'll maybe create a blueprint or etherpad or something
17:43:56 <sjmc7> i can tell by the stunned silence everyone is very keen
17:44:14 <ruhe> sjmc7: i support this idea. the only thing i'd like to discuss is DB mocking vs using in-memory sqlite for API tests
17:44:21 <tsufiev> sjmc7, we're not yet recovered from uuid vs. guid quarrel :)
17:44:28 <sjmc7> yeah - i'm not sure about that either. ha, tsufiev :)
17:45:17 <sjmc7> i sort of prefer an in-memory because it means it's testing it more like it will actually be run; otherwise changes to the DB often do not get mirrored in mocks
17:45:31 <tsufiev> sjmc7, unit tests for api are good, though i don't know how long current api will remain the same
17:45:34 <sjmc7> but i'm ok with either way
17:45:37 <sjmc7> ah :)
17:45:38 <ruhe> sjmc7: my experience from other projects shows that mocking DB usually ends up with tests which tests mocks. i'd like to hear what other folks think about that
17:46:08 <sjmc7> yeah, that's my experience, ruhe - which is why i think i prefer using an in-memory sqllite db with migrations applied
17:46:09 <tsufiev> afaik, sergmelikyan is currently investigating the possibilities of rewriting api
17:46:23 <sjmc7> ah. to what end?
17:46:27 <sergmelikyan> sjmc7, +1 for in-memory database
17:46:31 <sjmc7> i think that's even more reason to be able to write good unit tests
17:46:35 <sergmelikyan> tsufiev, it is not quite right statement :)
17:46:40 <sjmc7> if the API is changing sgnificantly
17:46:43 <ruhe> tsufiev: rewriting API is not just something you can do in a month or two. it'll take a lot of time
17:47:19 <sergmelikyan> sjmc7, definitely
17:47:22 <ruhe> so, unit-tests are needed very much (this sounds like ruglish)
17:47:28 <sjmc7> :D
17:47:43 <sjmc7> your ruglish is way better than my engsian
17:48:08 <ruhe> :)
17:48:08 <sjmc7> ok. i'll take a look at what other projects have done. i think glance and heat both use an in-memory DB and create fake contexts
17:48:49 <ruhe> sjmc7: thank you for starting this
17:48:59 <sjmc7> thank me when i've actually started it :)
17:49:41 <tsufiev> sjmc7,  btw, api is not the only component that cries for unit tests
17:49:57 <tsufiev> dashboard does it even more
17:50:05 <ruhe> yes, i think we need to get back to muranopl tests
17:50:24 <ruhe> tsufiev: is dashboard code unit-test-coverable?
17:51:07 <sjmc7> django has a test framework
17:51:34 <tsufiev> ruhe, to some extent. that's s complicated question - not only server part needs to be tested, but also client code
17:51:38 <sjmc7> but since horizon mostly makes calls to outside services i'm not sure how much there is to test
17:52:15 <ruhe> maybe selenium tests would be enough?
17:52:26 <ruhe> * existing selenium tests
17:52:45 <tsufiev> ruhe, maybe, once they start working :)
17:53:04 <tsufiev> the problem with selenium tests is that can't keep the pace with changes in code
17:53:32 <tsufiev> ideally, one person should write the code and tests for it - which is not true for selenium tests in murano
17:54:06 <ruhe> tsufiev: would you personally be willing to write/update selenium tests whenever you change dashboard code?
17:54:24 <sjmc7> :)
17:54:53 <tsufiev> ruhe, first I will need at least 2 weeks to dig into this and study all the existing good practices
17:55:44 <tsufiev> ok, maybe a bit less...
17:56:10 <ruhe> that's my concern with these tests. we only have two options - 1. enforce developers to maintain these tests in their patches to dashboard 2. turn off these tests on commits and run them on a regular (nightly?) basis
17:56:31 <sjmc7> how does horizon do it?
17:56:42 <tsufiev> ruhe, i mean, at this moment i don't know enough about them and cannot give a conscious answer :)
17:57:20 <tsufiev> sjmc7, horizon consists of 2 parts - horizon and openstack_dashboard
17:57:35 <ruhe> sjmc7: horizon has a very-very basic tests. afaik they only test that login panel is available
17:57:40 <tsufiev> afaik, there unit tests for horizon
17:57:58 <sjmc7> but they do it with the django test framework?
17:58:31 <tsufiev> https://github.com/openstack/horizon/tree/master/horizon/test/tests
17:59:05 <tsufiev> i wouldn't say there is only one test, but still not many
17:59:55 <tsufiev> so, muranodashboard can follow this way - unittest library part, use webtest for dashboard business logic
17:59:57 <ruhe> we're running out of the time. tsufiev: it would be great if you and tnurlygayanov__ research existing approaches with dashboard testing and conduct some kind of a report and possible solutions/directions for us
18:00:12 <tsufiev> ruhe, ok
18:00:21 <ruhe> thanks everyone
18:00:28 <sjmc7> thanks ruhe
18:00:33 <tsufiev> thank you
18:00:37 <ruhe> #endmeeting