Thursday, 2014-06-19

*** rakhmerov has joined #murano00:19
*** rakhmerov has quit IRC00:23
*** sjmc7 has quit IRC00:57
*** TravT has quit IRC01:01
*** rakhmerov has joined #murano01:19
*** rakhmerov has quit IRC01:24
*** gokrokve has quit IRC01:25
*** gokrokve has joined #murano01:25
*** gokrokve has quit IRC01:30
*** gokrokve has joined #murano01:59
*** rakhmerov has joined #murano02:20
*** rakhmerov has quit IRC02:25
*** gokrokve has quit IRC03:00
*** rakhmerov has joined #murano03:21
*** rakhmerov has quit IRC03:25
*** gokrokve has joined #murano03:33
*** gokrokve_ has joined #murano03:36
*** gokrokve has quit IRC03:39
*** rakhmerov has joined #murano04:07
*** sab has joined #murano04:09
*** rakhmerov_ has joined #murano04:34
*** rakhmerov has quit IRC04:45
*** rakhmerov_ is now known as rakhmerov04:46
*** rakhmerov has quit IRC05:22
*** rakhmerov has joined #murano05:22
*** rakhmerov has quit IRC06:13
*** rakhmerov has joined #murano06:13
*** rakhmerov has quit IRC06:16
*** rakhmerov has joined #murano06:16
openstackgerritEkaterina Fedorova proposed a change to stackforge/python-muranoclient: Infrastructure update  https://review.openstack.org/10095406:29
*** rakhmerov has quit IRC06:37
*** rakhmerov has joined #murano06:37
iyozhikovtest 4 renat06:39
iyozhikovtest 4 renat06:40
*** rakhmerov has quit IRC06:43
*** rakhmerov has joined #murano06:43
iyozhikovtest 4 renat06:44
iyozhikovtest 4 renat206:44
sergmelikyaniyozhikov, testing bouncer? )06:47
rakhmerovsergmelikyan, yes06:57
rakhmeroveverything's ok now06:57
openstackgerritEkaterina Fedorova proposed a change to stackforge/python-muranoclient: Infrastructure update  https://review.openstack.org/10095406:59
*** gokrokve_ has quit IRC07:05
*** gokrokve has joined #murano07:15
openstackgerritEkaterina Fedorova proposed a change to stackforge/python-muranoclient: Infrastructure update  https://review.openstack.org/10095407:19
*** gokrokve has quit IRC07:19
*** igormarnat has quit IRC07:27
*** tsufiev has quit IRC07:27
*** dteselkin has quit IRC07:27
*** ogelbukh has quit IRC07:27
*** dteselkin has joined #murano07:28
*** tsufiev has joined #murano07:28
*** ogelbukh has joined #murano07:29
*** igormarnat has joined #murano07:29
*** gokrokve has joined #murano07:35
*** gokrokve has quit IRC07:40
*** chandan_kumar has quit IRC08:01
openstackgerritAnastasia Kuznetsova proposed a change to stackforge/murano-dashboard: Add Test package, remove uploding of extra apps  https://review.openstack.org/10084608:03
*** slagun has joined #murano08:07
*** stan_lagun has quit IRC08:10
*** gokrokve has joined #murano08:27
*** gokrokve has quit IRC08:32
openstackgerritRuslan Kamaldinov proposed a change to stackforge/murano-dashboard: Refactor web UI tests  https://review.openstack.org/10049909:06
*** openstackgerrit has quit IRC09:14
*** gokrokve has joined #murano09:28
*** gokrokve has quit IRC09:33
*** gokrokve has joined #murano10:29
*** gokrokve_ has joined #murano10:31
*** gokrokve has quit IRC10:33
*** gokrokve_ has quit IRC10:35
*** _ruhe_ has joined #murano11:11
*** gokrokve has joined #murano11:32
*** gokrokve has quit IRC11:37
sergmelikyanslagun, https://review.openstack.org/96471 I think this patch can be merged after rebase11:42
sergmelikyanativelkov ?11:42
slagun-111:46
sergmelikyanwhy?11:53
*** sab has quit IRC11:53
slaguncolumn lengths. I'm in the  middle of writing comments in gerrit11:53
sergmelikyanok11:55
*** _ruhe_ has quit IRC11:58
*** gokrokve has joined #murano12:32
*** gokrokve has quit IRC12:37
*** asalkeld has quit IRC12:37
ruheslagun: i don't see any reason to increase id field length. we're using uuid for id in most places. there was a debate about some fileds, but it isn't resolved yet13:05
slagunIt doesn't matter what we use. If ID is generated by API user that is out of our control we should not assume it is UUID. Where ID is generated by API we can assume it is UUID, but lets make it 36 chars length so that if we decide to use UUID with dashes nothing will break. I don't see a problem to have larger value. Bigger is not smaller13:15
ruhedo you have any particular use case where a user wouldn't be able to use uuid?13:16
ruheand i'm afraid my patch will become too big if i try to update some of the fields to length=36. i suggest the following: keep all the lengths as is in this patch. create a new patch which updates all IDs to length=3613:18
slagunBy specification ID is unique string, not UUID. We have no need to enforce it to be UUID. API users may consider having something other identity system, for example URN scheme to simplify automation. We should not care. For us ID is a string and there is no need to have so tight restrictions for this string13:19
slagunFor example IDs of *some* object may be equal to ID in external system if objects are related13:20
sergmelikyanruhe, I don't think that increasing size of fields may make you patch bigger, since whole this file is a new and no new strings are added to the file :)13:21
slagunhow it can be big if its just a matter of changing one number to another?13:21
ruhei would start thinking about that when we see some real examples13:21
ruhesergmelikyan: i think that i'll need to update code which generates IDs to produce a string of 36 characters in the same patch where i update db schema13:23
ruhesergmelikyan: just to keep things consistent13:23
slagunIt is much easier to do now a(nd it costs nothing) than later to write migration to enlarge columns. I don't even sure it can be done on all supported DBMSes13:23
slagunI see no reason for such restrictions. Why do you want to restrict by default?13:23
ruhebecause it'll be easier to work with. whenever we need to work with ID we'll know what the exact length is13:25
sergmelikyanruhe, not necessary, there is no reason to update IDs generation logic, since we enlarging fields and there is no requirement to fill whole field by id. Id may be smaller than corresponding fields. So if we need, we can upgrade generation logic letter13:25
slagunruhe, when object model is not auto-generated (like in UT or hand-made environments) it would be much more convenient to have human-readable IDs than GUID. And in that case it can be longer than 3213:25
slagunruhe, there is no use case for knowing len(ID).13:26
sergmelikyanPlus, I agree with automation use-case13:26
ruheslagun: what about printing id in the command line client?13:26
slagunprint function accepts string of any length13:27
ruheit does, but it'll look messy. what i like about other clients and projects is that they operate with uuid. that's a behavior you expect from an openstack project13:29
slagunI don't suggest to change ID generation algorithm. It would still be UUID13:30
slagunBut if some customer would like to have something else than it is his wish and he will see something else. Because IDs in OM is a customer-facing thing, not implementation detail13:31
ruhewe haven't seen such requests yet13:31
slagunFor cases when ID is generated by ID it sill be 3613:32
slagunruhe, we haven't seen requests for 32 either. I don't understand why make things wrong and then wait for a bug report if we can do right from the beginning and it costs nothing13:33
*** gokrokve has joined #murano13:33
*** gokrokve has quit IRC13:37
ruheso, we all agree that we'll use 36 charecter uuid string everywhere. right? also, you say there might be cases where user might need to use something other than uuid. right?13:40
slagun1) We use what is currently used (32 or 36). Personally I like 32 more and both are used in OS. There is no need to change currently working code for that but lets make maximum length for auto-generated IDs be 36 to fit both formats. 2) Not necessary need, but want. Spec is saying it is unique string not that it is UUID of a fixed length and there is no need to change spec13:44
ruheok. i'll update the patch right now13:47
ruhebtw13:47
ruheyou left a comment about instance_stats. i agree that we need to get rid of this hand-made stats counting, but i think that it should be done outside of this patch13:48
slagunagree. But if we do this before this patch than there will be no need to recreate that table with Alembic13:49
ruhebecause, there is API, there is StatsCollectingService13:49
slagunand then remove it with another migration13:49
slagunI understand13:50
ruheremoving a table shouldn't be a big problem13:50
slagunMaybe it would be better to remove all of this and then switch to Alembic. Thus we will eliminate unneeded migration13:51
slagunbut it is up to you13:51
*** TravT has joined #murano13:59
*** gokrokve has joined #murano14:04
*** sjmc7 has joined #murano14:14
ruheeveryone interest in dashboard tests, please take a look at https://blueprints.launchpad.net/murano/+spec/refactor-ui-tests14:54
ruhe*interested14:54
*** TravT has quit IRC15:26
*** TravT has joined #murano15:35
*** katyafervent is now known as katyafervent_awa15:37
*** gokrokve has quit IRC16:49
*** gokrokve has joined #murano17:18
*** sab has joined #murano17:50
*** sab has quit IRC17:54
*** slagun has quit IRC18:08
*** rakhmerov has quit IRC18:08
*** gokrokve has quit IRC18:08
*** tsufiev has quit IRC18:08
*** tnurlygayanov has quit IRC18:08
*** smurashov has quit IRC18:08
*** gokrokve has joined #murano18:10
*** slagun has joined #murano18:10
*** tsufiev has joined #murano18:10
*** rakhmerov has joined #murano18:10
*** tnurlygayanov has joined #murano18:10
*** smurashov has joined #murano18:10
*** slagun has quit IRC18:14
*** rakhmerov has quit IRC18:14
*** gokrokve has quit IRC18:14
*** tsufiev has quit IRC18:14
*** tnurlygayanov has quit IRC18:14
*** smurashov has quit IRC18:14
*** gokrokve has joined #murano18:16
*** slagun has joined #murano18:16
*** tsufiev has joined #murano18:16
*** rakhmerov has joined #murano18:16
*** tnurlygayanov has joined #murano18:16
*** smurashov has joined #murano18:16
*** slagun has quit IRC18:33
*** slagun has joined #murano18:33
*** btully has joined #murano19:31
*** asalkeld has joined #murano20:58
*** openstackgerrit has joined #murano21:34
openstackgerritBrian Tully proposed a change to stackforge/murano-dashboard: Disable all buttons and links until AppCatalog page is loaded  https://review.openstack.org/9905022:32
*** openstackgerrit has quit IRC22:34
*** 20WAAHXAJ has joined #murano22:35
*** btully has quit IRC22:48
*** openstack has joined #murano22:50
-dickson.freenode.net- [freenode-info] if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp22:50
*** 20WAAHXAJ has quit IRC23:29
*** openstackgerrit has joined #murano23:30
openstackgerritStan Lagun proposed a change to stackforge/murano: MuranoPL testing mini-framework  https://review.openstack.org/10137023:50

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!