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