17:01:27 #startmeeting Murano 17:01:29 Meeting started Tue Aug 18 17:01:27 2015 UTC and is due to finish in 60 minutes. The chair is Nikolay_St. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:33 The meeting name has been set to 'murano' 17:01:39 o/ 17:01:42 o/ 17:01:47 hi folks 17:01:48 0/ 17:01:52 hi 17:02:02 hi 17:02:03 today Serg asked me to be a chair :) 17:02:05 hi 17:02:10 hi 17:02:34 here is agenda of the meeting: https://wiki.openstack.org/wiki/Meetings/MuranoAgenda#Agenda 17:02:45 let's start with action items review 17:02:55 #topic Action Items Review 17:03:12 #link https://wiki.openstack.org/wiki/Meetings/MuranoAgenda/Archive/2015-08-18/#Agenda 17:03:14 o/ 17:03:19 a more permanent link for agenda ) 17:03:26 more or less 17:03:42 oh, sorry. I'm new with it :) 17:04:16 don't worry, seems that nobody really maintains it, I just like to have a bit more consistent logs =) 17:04:43 kzaitsev_mb: please. You was able to write a email to openstack-dev about new yaql 17:04:55 yep, done that 17:05:03 ok 17:05:19 also freerunner added a valuable comment with devstack rc 17:05:40 next action was about "pin yaql requirements to RC2" 17:06:08 who is responsible for it? 17:06:15 #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/071980.html 17:06:16 rc2 is pinned in migration commit 17:06:28 #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/071991.html 17:06:49 the problem is that as it just have discovered seems that we are going to release rc3 17:07:20 should we pin it as the new action item? 17:07:23 bummer... 17:07:30 let's discuss it a bit more 17:07:44 we have a topic about yaql 1.0 17:07:53 so, I think we can move to it 17:07:57 yup 17:08:15 #topic Migrating to yaql 1.0 status 17:08:20 slagle: please 17:08:24 so, there are a couple of breaking changes between 0.2.x and 1.0 which are not yet reflected in "legacy mode" 17:08:35 StanLagun: please 17:08:46 we may add them to that mode, but that would require us to release a rc3 17:08:59 OR we may address them in Murano engine 17:09:06 I stand for the former 17:09:22 but this may be discussed and other options may be considered 17:10:12 Fixing YAQL behaviour seems like a better idea to me. Otherwise we would be adding a workaround, won't we? 17:10:29 I agree that it is better to fix in yaql itself because legacy mode was intended to emulate yaql 0.2 behavior and we see several constructs that do not work any more (though for a good reason) 17:10:37 I agreee with kzaitsev_mb 17:10:49 just note this is not fixing yaql but yaql legacy mode 17:11:32 So it's more like a bug in the way we support old 0.2 apps 17:11:32 it may be worth it to discuss if the decision to drop that behavior was a correct one 17:11:51 yup 17:12:06 StanLagun: could you please elaboreate more on that decision? 17:12:34 there are 2 breaking changes that were not addressed: 17:13:32 1) in yaql 0.2 you could say $key in $dict (as in Python). In yaql 1.0 you can say $key in $dict.keys(), $key in $dict.values() etc. $dict itself is not iterable 17:14:24 2) In yaql 0.2 foo() != true would be true if foo would return string, integer, whatever. In yaql 1.0 if foo would return non-boolean value that would cause exception to be thrown 17:14:38 the same for = 17:15:02 I truly believe this is better behavior 17:15:18 but old behavior need to be restored in legacy mode 17:16:24 so yaql 1.0 is not strongly typed? =) 17:16:35 s/not/now/ 17:16:49 kind of 17:17:14 is it really a good idea for non-compiled language? 17:17:15 explicit is better then implicit 17:17:17 I like the change of 1): iterating the dict is a bad idea anyway 17:17:29 but I don't like 2) 17:18:13 I kind of thought, that strong typing allows better code analysis tools to be written and helps developer to find errors before the programm is even run 17:18:57 the motivation for 2 is that comparing non-comparible values is usualy a sign of a program bug. Usual real-life bug is foo != true instead of $foo != true 17:19:05 so this is a way not to mask bug 17:19:59 btw this was a bug discovered in k8s implementation and thats how I discovered it 17:20:58 so, to "fix" that in code one would need to do something like "bool($foo) != true? 17:21:17 I mean in a non-legacy mode? 17:22:28 yes. But for yaql you will not often use such constructions. And for MuranoPL you don't need them at all since If macro will evaluate similar to Python 17:23:27 but in reality you nearly always will write $foo != 0 or != '' 17:23:55 because most of the time you know the type 17:24:06 well, like I said, I really think Stan should grow a beard =) 17:25:30 :) 17:25:31 Count me as a python guy here, so I like my objects comparable no matter what, but my '+'s raising Runtime Errors if the language does not know how to add 17:26:27 kzaitsev_mb: important difference here with python is that arbitrary character combination counts as a string in yaql 17:26:47 i.e. "abc != true" will always be true 17:27:00 but I believe, that I do not know if this is a good thing to have or a bad thing to have, so you can safely disregard my opinion ))) 17:27:00 as it evaluates to "'abc' != true" 17:27:15 and that is really often error that I even make myself 17:27:42 So, Stan's point is that the developer is likely to forget about writing $ before variable name, thus making this variable just a string instead 17:28:25 Personally, I don't think it is a reason to require explicit booleans 17:28:46 But, well.. I am ok with either solution 17:28:49 ativelkov: require explicit var declaration then? =))) 17:29:07 kzaitsev_mb: blasphemy! 17:29:15 let's summ it up, won't we? 17:29:24 there is another reason for that 17:29:44 StanLagun: which is? 17:29:52 We have to fix yaql legacy support, before we can release 1.0, right? 17:30:22 kzaitsev_mb: yup, at least for dict iteration part 17:30:36 (as it seems like we are in an agreement on it) 17:30:36 And there is going to be rc3, which is sad, but inevitable, heh 17:30:56 looks like you are right 17:31:55 no, there is no other reason 17:32:34 can we just releaze 1.0 with all the fixrs? 17:32:47 katyafervent2: well.. it's a bit bad practice 17:32:50 *fixes 17:33:19 RC should become an RTM without any changes 17:33:30 there might be other compatibility issues. There are no unit tests for yaql 0.2 that could be used to ensure compatibility 17:33:34 At least in my understanding 17:33:51 StanLagun: right, and in this case we will release 1.0.x's 17:33:53 why? openstack rc2 and release itself may be different 17:34:14 but if we already know about an issue, we may fix it 17:34:38 katyafervent2: not unless you are ok without releasing it without a proper testing 17:34:55 ok with* releasing it 17:35:46 If we make this change and wnat to test it before the release, we'll need to tag the changed binary somehow. rc3 is a good tag ) 17:36:17 ok) 17:36:24 so 17:36:30 we need a final decision 17:36:38 or we can run out of time 17:37:18 StanLagun: please 17:37:33 I suggest to fix it in rc3. But do not release rc3 until we have successfully deployed one really complex env with k8s etc 17:37:56 to maximize our chances to find other errors of that kind 17:38:08 should we marked it as action item? 17:38:35 Nikolay_St: I believe we should ) 17:38:37 i will submit fixes today. Please review ASAP 17:38:47 ok 17:38:56 StanLagun: ping me directly for faster review 17:39:06 how may we test it without releasing rc3? 17:39:24 by installing yaql from gerrit 17:39:41 #actionitem fix yaql legacy mode and release yaql rc3 after successful deployment 17:39:49 oh, so you mean manual verification 17:39:50 ok 17:39:57 This is a matter of 1 day 17:40:04 #action fix yaql legacy mode and release yaql rc3 after successful deployment 17:40:48 This AI should go to akuznetsova, shouldn't it? 17:41:18 so we can move to the next topic, I guess 17:41:41 #topic Artifact (glance v3) transition status update 17:42:16 I am working to fix the remaining issues about artifact filtering in glance 17:42:36 fixed two of them since the last update, one more relate 17:42:51 ok, good to know 17:42:51 Also, I've found an issue in python-glanceclient 17:43:12 (as I expected we may start facing issues there as nobody before has ever used the v3 part of it) 17:43:37 I've asked mfedosin for help with that 17:45:07 probably more help will be needed :) 17:45:10 #info 2 issues was fixed, one more to go. issue in glanceclient will be fixed by mfedoshin 17:45:45 any other updates on this topic? 17:46:01 or any questions? 17:46:09 nope 17:46:16 ok, let's move further 17:46:27 #topic Allow (or not) public packages in package definitions-view in dashboard (kzaitsev) 17:46:33 kzaitsev_mb: please 17:46:37 #link https://review.openstack.org/#/c/213682/ 17:46:44 ok so there is this review 17:46:57 I suppose zhu.rong is not here 17:47:08 well. I still think we might discuss it anyway 17:47:14 I'll try to be quick 17:47:33 We've intentionally removed public packages from Pakcage Definitions view 17:47:58 But now we've added (copied from glance dashboard) a filter with public,project, other packages 17:48:11 do you mean for non admin? 17:48:13 so this creates a rather wierd UX experience 17:48:14 yep 17:48:39 exactly — non-admin user can't see public packages on package-definitions, cause he can't edit them. 17:49:08 kzaitsev_mb: I run through your comments on review 17:49:13 package-definitions view is intended for edit only 17:49:13 Now we have a "Public" filter for him, which makes him think, that there should be public packages there, but there are not =/ 17:49:29 thats expected behaviour 17:49:38 why would anybody list non-editable things in the editor? 17:49:46 I guess we should remove "public" filter 17:49:48 ativelkov: katyafervent2: agree, but I feel that it creates negative UX 17:49:56 Nikolay_St: that's one option 17:49:56 we can rename it. Public -> My Public 17:50:14 other would be to list everything and forbid editing 17:50:23 kzaitsev_mb: imho, the "public,project, other" filter should not be part of package editor 17:50:30 it should be in catalog view 17:50:41 I can summ it up in a letter, since we're almos out of time 17:50:50 what do you think of that idea? 17:51:08 I feel the PREASSURE +))) 17:51:09 +1 17:51:30 mgershenzon: yep, I really want to allow you to have some time with your item ) 17:51:43 =) 17:51:52 +1 17:52:13 agree 17:52:16 +1 to list all but grey out those that I don't own. But!!! I want to be able to export them since I can deploy them 17:52:38 +1 17:52:45 #action kzaitsev_mb summ up the UX concerns about the public/non-public packages on Package Definitions in ML 17:53:00 ok, next topic 17:53:10 phew ) 17:53:13 #topic Add support for heat environments 17:53:23 The API works well, you can review here #link https://review.openstack.org/#/c/211608/ 17:53:23 The main risk is about the UI... 17:53:23 When the spec was approved we agreed someone with more UI experience will find the time to help with the UI. I still think this is necessary. 17:54:01 mgershenzon: for sure. any volunteers? 17:54:26 The API works well, you can review here #link https://review.openstack.org/#/c/211608/ 17:54:26 The main risk is about the UI... 17:54:27 When the spec was approved we agreed someone with more UI experience will find the time to help with the UI. I still think this is necessary. 17:54:27 There are 3 main issues with current implementation: 17:54:27 - when the hot template parameters has no defaults, the UI user must enter parameter values, even if there is an environment that already contains them. 17:54:27 - when the hot template parameters has defaults and the user clear the defaults and leaves the fields empty, the UI still sends the parameters with null values. 17:54:27 - the current implementation effects values validation. I believe slagun and ativelkov know the issue. 17:54:45 *StanLagun 17:55:20 Yup 17:55:25 I was looking at that 17:55:31 =) 17:56:00 ativelkov, I thought we had a solution for this 17:56:12 but this requires dedicated BP/spec 17:56:14 Sorry about the flood, I have written it in my phone in advance 17:56:23 :) 17:56:33 StanLagun: yup, but let's proceed step-by-step 17:57:09 So, let's ensure that mgershenzon's patch does not break the current UI behavior 17:57:33 I mean the one for HOT-based apps without the envs 17:57:36 and land the patch 17:57:43 yes 17:57:55 Then we may think about ways to improve it so env's may be selected in UI 17:58:13 I'm already doing changes in the HOt processor. So we better hurry with this 17:58:26 StanLagun: which changes? 17:58:50 https://review.openstack.org/#/c/214163/ 17:58:59 https://review.openstack.org/#/c/214163/3/murano/packages/hot_package.py 17:59:06 #action verify that https://review.openstack.org/#/c/211608/ don't break anything then produce next steps with UI 17:59:11 guys, time 17:59:12 Ah, I see 17:59:40 Ok, so we are agreed on that 17:59:43 good 17:59:48 ok, good 17:59:55 time is up 17:59:57 who will do it? 18:00:07 I'll do the reviews 18:00:08 we can continue on #murano 18:00:28 time is up 18:00:36 thanks all 18:00:38 let's continue on #murano 18:00:44 #endmeeting