17:00:28 <kzaitsev_mb> #startmeeting murano
17:00:29 <openstack> Meeting started Tue Jul 14 17:00:28 2015 UTC and is due to finish in 60 minutes.  The chair is kzaitsev_mb. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:33 <openstack> The meeting name has been set to 'murano'
17:00:37 <sergmelikyan> o/
17:00:40 <ativelkov> o/
17:00:42 <slagun> o/
17:00:42 <kzaitsev_mb> hi all.
17:00:43 <freerunner> o/
17:00:53 <Nikolay_St> o/
17:00:59 <ativelkov> hi folks
17:01:08 <DmytroDovbii> o/
17:01:15 <mgershen> hi all
17:01:35 <kzaitsev_mb> Serg asked me to have the chair from now on. I hope that's ok with everyone. =)
17:01:51 <kzaitsev_mb> todays agenda #link https://wiki.openstack.org/wiki/Meetings/MuranoAgenda/Archive/2015-07-14/
17:01:53 <aderyugin> gi!
17:01:58 <FilipBlaha> hi
17:02:00 <aderyugin> *hi!
17:02:01 <katyafervent2> o/
17:02:43 <kzaitsev_mb> let's review action items from prev meeting
17:03:05 <kzaitsev_mb> kzaitsev start spec-freeze discussion in ML: I've done that and only got a responce from dims
17:03:11 <kzaitsev_mb> shame on you guys! =)
17:03:42 <kzaitsev_mb> pls take a look at the letter and speak of your concerns =)
17:03:51 <Nikolay_St> kzaitsev_mb: ok
17:04:04 <sergmelikyan> Sure, I completely agree with this proposal
17:04:20 <kzaitsev_mb> kzaitsev look for a way to run periodic nightly builds of stable branches — done https://review.openstack.org/#/c/201233/ here is the commit to infra
17:04:32 <sergmelikyan> We even should start writing specs for the next cycle in U2 of previous
17:05:16 <sergmelikyan> kzaitsev_mb: great!
17:05:27 <kzaitsev_mb> These jobs should test stable/kilo stable/juno branches daily and report errors to a separate ML.
17:05:29 <sergmelikyan> Can you elaborate a little bit how we would be notified?
17:06:03 <kzaitsev_mb> pls chip in with +1s or even better review the commit, cause I might have missed somethig there. =)
17:06:15 <sergmelikyan> To which e-mail list we should subscribe to receive notifications?
17:07:23 <kzaitsev_mb> sergmelikyan: can't find it right now, will find it in a few moments =)
17:08:05 <kzaitsev_mb> meanwhile — let's strart discussing our 1st topic for toady — migrating to yaql 1.0
17:08:14 <kzaitsev_mb> #topic yaql1.0
17:08:29 <sergmelikyan> kzaitsev_mb: I think this staff worse a e-mail annoucement
17:09:12 <kzaitsev_mb> sergmelikyan: will do, as soon as the commit will be merged. or maybe even before that.
17:09:16 <kzaitsev_mb> so yaql1.0
17:09:46 <kzaitsev_mb> slagun: can you pls share the difficulties we have with it and how we can migrate to it?
17:10:41 <slagun> the main dificulty is that by design doesn't have the integration mechanism we used before
17:11:02 <slagun> previously there were like 2 different words - MuranoPL and yaql bridged with a hack
17:11:16 <slagun> now I'm trying to bring them to a common denominator
17:11:32 <slagun> by offloading all method resolution and registration logic to yaql
17:11:51 <slagun> so now everything including Python and MuranoPL classes/methods will be yaql methods
17:12:08 <slagun> and they can talk to each other like normal functions do
17:12:28 <slagun> this involves major refactoring of how dsl works with contextes
17:12:46 <slagun> and fixes bugs in MuranoPL
17:12:59 <sergmelikyan> slagun: but will it affect language?
17:13:11 <sergmelikyan> I mean will be previously written applications compatible?
17:13:48 <slagun> 95% compatibility. Apps can break but most apps won't break
17:14:02 <kzaitsev_mb> slagun: sounds awesome
17:14:07 <slagun> This is with yaql1.0 compatibility mode
17:14:31 <slagun> with introduction of versioning newer classes will run without that additional layer
17:14:32 <kzaitsev_mb> but one of the main concerns I have with this process is the fact, that mos tests would break, right?
17:14:44 <slagun> why?
17:14:50 <kzaitsev_mb> Since we use yaql in every project
17:15:04 <kzaitsev_mb> I mean — integration tests and murano-ci
17:15:17 <sergmelikyan> kzaitsev_mb: why?
17:15:28 <sergmelikyan> I mean I still don't get why they would break
17:15:29 <slagun> yes, we will need to update yaql in all of them. Likely for us dashboard and client use yaql very lightly and trivial to migrate
17:15:47 <slagun> But we will need to find out how to merge this
17:15:53 <sergmelikyan> they all working based on requirements.txt
17:16:05 <slagun> also my fixes include several improvements to yaql itself which also need to be released
17:16:32 <katyafervent2> what's the status of dashboard migration to yaql?
17:16:52 <kzaitsev_mb> sergmelikyan: well, earlier this week we had a discussion about the integration tests and the fact, that releasing new yaql and using it in murano would most likely break integration tests. I might be wrong here though.
17:17:20 <kzaitsev_mb> it's awesome, if everything would go as smooth as you guys say!
17:17:40 <slagun> katyafervent2, I haven't started it yet but I expect it to be really easy and fast to do. I'd be happy if you help me with that
17:18:19 <kzaitsev_mb> slagun: katyafervent2: do we track this activity somewhere? like in a BP?
17:19:42 <slagun> there is a BP to migrate to yaql 1.0 but it lacks details. I'm gonna write spec as soon as implementation be ready just to make sure everything work as I expect it. You may not merge until spec is ready though :)
17:20:19 <katyafervent2> stan shoud create a bp and a spec for this activity
17:20:59 <kzaitsev_mb> nice. so we can update the BP with specific work items for client and dashboard and offload that work from slagun then
17:21:20 <kzaitsev_mb> I'll do that, then
17:21:49 <kzaitsev_mb> I suggest we would track progress on yaql weekly, since it's the core of murano =)
17:22:21 <slagun> I really hope it will be done by the next community meeting
17:22:27 <kzaitsev_mb> #action kzaitsev update yaql1.0 BP with client and dashboard tasks to offload them from slagun
17:22:39 <katyafervent2> will we update the dynamic ui version since yaql is used in form definitions?
17:22:52 <slagun> and will open a door for a long list of new futures
17:23:10 <slagun> katyafervent2, no since the syntax is the same
17:23:21 <kzaitsev_mb> slagun: would be sweet. Also we'll try to help you with the task. )
17:23:40 <kzaitsev_mb> ok. let's move to the next topic then.
17:23:49 <kzaitsev_mb> #topic Returning import order checks
17:23:55 <Nikolay_St> oh nice
17:24:20 <Nikolay_St> IMHO we should until migration to py3 will be ended
17:24:36 <kzaitsev_mb> Nikolay_St suggested the idea, I initially supported it, but as I dived deeper into the reasons they were removed — I decided we should discuss it
17:24:57 <Nikolay_St> and then write a new checks related to py3 libs
17:25:09 <Nikolay_St> *we should wait
17:25:14 <slagun> I though it will take years for OpenStack to switch to py3 if they will ever do so. Am I was wring?
17:25:37 <kzaitsev_mb> 1 of the main reasons they were removed is because the check could give 2 different results on py2 and py3 due to different stdlibs
17:25:43 <Nikolay_St> slagun: in reality they do they're best for it
17:26:11 <slagun> what OS release is going to run on py3?
17:26:24 <sergmelikyan> U
17:26:30 <slagun> :)
17:26:41 <kzaitsev_mb> slagun: well, https://wiki.openstack.org/wiki/Python3#Python_3 OS aims at py3
17:26:58 <sergmelikyan> I expect another 2 years at least, but who knows
17:27:24 <kzaitsev_mb> Nikolay_St: so you basically suggest we abandon the idea, right?
17:27:52 <Nikolay_St> kzaitsev_mb: for sure
17:28:19 <Nikolay_St> I'll need to check logs of #murano for some links
17:28:29 <kzaitsev_mb> I'm ok with that, since adding a bunch of foreign code doesn't feel right to me. any objections?
17:28:50 <slagun> +1
17:29:27 <katyafervent2> ok
17:29:37 <sergmelikyan> But I all for py3 compatibilitie
17:29:41 <sergmelikyan> *I am
17:29:43 <FilipBlaha> no objections
17:30:33 <kzaitsev_mb> ok. so Nikolay_St would you abandon the commit then, pls =)
17:30:51 <Nikolay_St> kzaitsev_mb: ok
17:30:55 <kzaitsev_mb> #agreed to not resore import order checks
17:30:58 <slagun> yaql1 is already py3 compatible. Small step for a man... :)
17:31:38 <kzaitsev_mb> sergmelikyan: well we have a BP for that. Sometime someone would take the job and make everything run on py3 =)
17:31:44 <kzaitsev_mb> just not today. =)
17:32:05 <kzaitsev_mb> #topic JS linting jobs
17:32:11 <kzaitsev_mb> ok this is a small one
17:32:33 <kzaitsev_mb> I've added a BP for shellcheck and everyone on ML agreed with it
17:32:45 <kzaitsev_mb> later I added a note about JS linting
17:32:55 <kzaitsev_mb> but I feel, that it was not properly discussed
17:33:33 <kzaitsev_mb> So I split the BP in 2 (would be awkward to target bp 'shelcheck' in a commit, that alters js code)
17:34:08 <kzaitsev_mb> And copied js linting code from horizon (with a couple of simplifications) to dashboard
17:34:32 <sergmelikyan> sounds nice :)
17:34:39 <kzaitsev_mb> here is the commit https://review.openstack.org/#/c/200780/
17:35:00 <kzaitsev_mb> it currently fails with 200 something errors =)
17:35:18 <kzaitsev_mb> as soon as we merge this — I'll add a non-voting jslint job to infra
17:35:49 <kzaitsev_mb> that's all I wanted to say, hope everyone's ok with this side activity of mine =)
17:36:30 <FilipBlaha> how does it work? does it report only new errors added in given patchset?
17:37:21 <kzaitsev_mb> FilipBlaha: ok, it uses eslint, which reports both style checks and errors. it runs eslint against a directory, so it's more like pep8, checks the whole codebase
17:38:52 <kzaitsev_mb> It also has plugins, that can be installed from npm, so as soon as we switch to angular — we would be able to check that too
17:39:52 <FilipBlaha> kzaitsev_mb: thanks
17:40:31 <kzaitsev_mb> we actually have some weird js code. (= hope to fix it someday, cause our dashboard is pretty complicated.
17:40:53 <FilipBlaha> I added pylint job a few weeks/moths ago but I am not sure whether it improved anything
17:41:53 <kzaitsev_mb> FilipBlaha: well I'm intending to actually fix most of the errors as part of this side-activity and turn the job voting as soon as we're ready. =)
17:42:11 <FilipBlaha> problem of this tools is that they report many false positives
17:42:22 <kzaitsev_mb> FilipBlaha: the errors reported by eslint are a lot easier to fix, than those of pylint ;)
17:42:25 <sergmelikyan> FilipBlaha: +1
17:43:05 <kzaitsev_mb> sergmelikyan: FilipBlaha: you can take a look at the list of errors and we can disable those, that seem not worthy of noting
17:43:13 <sergmelikyan> though usually you can skip false-positive from report by adding specific comment in code
17:43:19 <kzaitsev_mb> like " against ' — it's disabled in commit.
17:43:47 <sergmelikyan> I prefer to mark false-positive in the code, instead of disabling rules
17:43:59 <kzaitsev_mb> sergmelikyan: correct, eslint supports disabling specific rules for a block of code
17:44:25 <sergmelikyan> https://github.com/openstack/murano/blob/master/murano/engine/system/net_explorer.py#L41
17:44:27 <FilipBlaha> ok, +1 for eslint job
17:44:30 <sergmelikyan> example ^
17:45:24 <katyafervent2> will we keep pylint job then?
17:45:35 <Nikolay_St> katyafervent2: yeap
17:45:45 <kzaitsev_mb> katyafervent2: I think pylint doesn't hurt =)
17:45:50 <Nikolay_St> katyafervent2: pylint is for python isn't it?
17:45:54 <slagun> sergmelikyan, btw after we migrate to yaql1 there won't be functions with non-pythonic names
17:46:05 <kzaitsev_mb> my commit aims at js code, not python code =)
17:46:32 <katyafervent2> ok,  got it
17:47:08 <kzaitsev_mb> ok, let's move to the final topic then, won't we?
17:47:23 <kzaitsev_mb> #topic Murano CLI versioning
17:47:31 <freerunner> ;)
17:47:39 <kzaitsev_mb> freerunner: had a suggestion about versioning of our client
17:47:44 <sergmelikyan> Yeah :) I was waiting for that
17:47:51 <kzaitsev_mb> #link https://etherpad.openstack.org/p/murano-cli-ver
17:47:59 <sergmelikyan> So let me explain how it works now
17:48:00 <kzaitsev_mb> freerunner: can you elaborate pls?
17:48:06 <kzaitsev_mb> oh right
17:48:09 <kzaitsev_mb> sergmelikyan: pls do
17:48:42 <sergmelikyan> https://launchpad.net/python-muranoclient/+series <- please take a look here
17:48:54 <sergmelikyan> starting from Kilo we have new versioning scheme for libraries
17:49:27 <sergmelikyan> we have stable/kilo with latest release 0.5.9, and 0.6.0 as starting for Liberty
17:49:48 <sergmelikyan> since stable kilo is already release - we expect there only security and critical bug-fixes
17:50:02 <sergmelikyan> therefore only minor version incrementals
17:50:12 <kzaitsev_mb> sergmelikyan: new versioning of OpenStack projects doesn't affect client, does it?
17:50:18 <sergmelikyan> 0.5.xxxxxxx < 0.6
17:50:24 <sergmelikyan> kzaitsev_mb: affects
17:50:43 <kzaitsev_mb> so liberty would be 1.0.0 ?
17:50:49 <sergmelikyan> nope
17:50:56 <sergmelikyan> this is not change that I am talking about
17:51:04 <sergmelikyan> Liberty is in development and we can have any number of version for client as we like
17:52:08 <sergmelikyan> let's imagine that we have 2.3.19 version of client at the end of Liberty, then for M we will start with 2.4, and in stable/liberty will have >=2.3.19, <2.3
17:52:12 <sergmelikyan> *<2.4
17:52:17 <katyafervent2> liberty should be < 0.7
17:52:23 <sergmelikyan> katyafervent2: nope
17:52:34 <kzaitsev_mb> sergmelikyan: is this a standard for OS-clients?
17:52:42 <sergmelikyan> we can have 0.7 and 0.8 released for Liberty
17:52:45 <sergmelikyan> kzaitsev_mb: yep
17:52:50 <sergmelikyan> as well as oother libraries
17:53:03 <kzaitsev_mb> is there a write-up somewhere, that we can refer to?
17:53:10 <sergmelikyan> kzaitsev_mb: trying to find
17:53:49 <sergmelikyan> kzaitsev_mb: http://specs.openstack.org/openstack/openstack-specs/specs/library-stable-branches.html
17:54:29 <kzaitsev_mb> #link http://specs.openstack.org/openstack/openstack-specs/specs/library-stable-branches.html
17:54:53 <kzaitsev_mb> ok so, unfortunately freerunner's suggestion would not be implemented =)
17:55:31 <sergmelikyan> nope ;)
17:55:40 <sergmelikyan> I think this one is working perfectly fun
17:55:43 <sergmelikyan> *fine
17:55:51 * sergmelikyan todays is lame typer
17:56:02 <freerunner> Okay =)
17:56:29 <sergmelikyan> Open Discussion?
17:56:32 <kzaitsev_mb> #topic Open Discussion
17:56:41 <kzaitsev_mb> ok we have a couple of minutes
17:57:01 <kzaitsev_mb> I'd like to remind, that there will would be a stable point release this Thursday
17:57:28 <sergmelikyan> kzaitsev_mb: do you have a link?
17:58:29 <kzaitsev_mb> sergmelikyan: I think we should join other OS projects
17:58:35 <kzaitsev_mb> #link http://lists.openstack.org/pipermail/openstack-dev/2015-July/069110.html
17:58:48 <sergmelikyan> freerunner: ^
17:58:59 <sergmelikyan> we need to check out gates :)
18:00:09 <freerunner> sergmelikyan: Our gates is well, excluding congress-gate =(
18:00:10 <kzaitsev_mb> ok. this felt like a productive meeting =)
18:00:30 <kzaitsev_mb> lets move to #murano if you have any ore concerns
18:00:36 <kzaitsev_mb> #endmeeting