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