17:01:20 #startmeeting murano 17:01:20 Meeting started Tue Nov 10 17:01:20 2015 UTC and is due to finish in 60 minutes. The chair is sergmelikyan. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:24 The meeting name has been set to 'murano' 17:01:25 Hi folks :/ 17:01:28 o/ 17:01:33 o/ 17:01:34 hi 17:02:09 o/ 17:02:35 hi 17:03:19 I've left this channel at some point =) the number of #openstack-meeting channels is getting out of hand =) 17:03:33 I've heard the're planning to add -4 sometime soon ) 17:03:47 omg :) 17:05:50 Let's get started :) 17:06:01 #topic Image and package visibility concerns 17:06:29 http://lists.openstack.org/pipermail/openstack-dev/2015-November/079041.html 17:06:37 ok, so there was a letter from Oliver 17:06:44 yep #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/079041.html 17:06:57 oh, no, that's my response =) 17:07:09 o/ 17:07:14 anyway. the situation is the following: 17:07:53 we've already merged commits to CLI and dashboard(earlier toady), that attempt to set visibility of the images 17:08:04 to the same value as the one of the packages at upload time 17:08:12 so basically the bug is solved. 17:08:47 one other question Oliver raised was that after the packages is uploaded — visibility of an image might be changed. 17:09:00 which basically breaks murano package, that depends on it. 17:09:36 (meaning you can't use the public package from other project, after that) 17:10:02 So the first half of the bug is solved and merged, while the 2d one... 17:10:45 Currently it seems to be very difficult to implement that, but we might be able to do so, as part of our migration towards glare. 17:11:56 I believe we should file a BP for that, and probably consult with ativelkov and other glare guys whether it would be possible at some point to maintin dependecny graph (with respect to visibility and probably other properties) 17:12:03 Am I typing too much? =) 17:12:07 This situation looks good to me. 17:12:22 * sergmelikyan still reading :) 17:12:42 #link https://review.openstack.org/#/c/236830/ 17:12:48 CLI commit 17:12:52 That's good, that we fixed some issues and we should make should everything works as expected in glare 17:12:58 dashboard commit: #link https://review.openstack.org/#/c/236834/ 17:13:16 And now we can concentrate on other issues 17:13:17 do not be alarmed by -1 from ativelkov, if you read the comment — he's actually ok with the patch 17:13:32 I agree with creating BP for the future 17:13:56 I'll try to ping Oliver (shame he's not here today =/) 17:14:02 if he doesn't — I'll file it 17:14:23 regarding changing visibility - it's hard to guard against actions like that - user can delete VM for deployed applications at any point of time 17:14:27 #action kzaitsev_mb file a BP for maintaining visiblity of dependencies (or have Oliver do it) 17:14:30 or even complete stack 17:14:57 sergmelikyan: well, it's not about VM, but about glance image, that murano package depends on 17:15:22 i.e: can we forbid deleting an image that public packages depend upon? 17:15:28 I believe currently not 17:15:42 kzaitsev_mb: I understand, but I am saying that user who has access to the cloud - can basically break working application at any point of time - or even remove dependencies 17:15:52 including images and packages 17:15:54 but can we do something, with that, when we move to glare, not sure =) 17:16:23 well, it might turn out, that the task is impossible in the end =) 17:16:41 I guess GLARE can help us here, not prevent, but at least warn about things like that BEFORE deployment 17:16:55 at best we might warn somehow, that the user is breaking stuff 17:17:02 yep 17:17:20 oh, you're right, glare might help perform a pre-flight check 17:17:44 so that the user would get an early meaningfull error in case dependencies are missing 17:19:41 yep - that's what I am thinking about - will you reflect that? 17:20:07 yep, in a BP (I've already added action ) 17:20:15 #topic Juno EOL (kzaitsev) 17:20:29 kzaitsev_mb: today you are men of the meeting :) 17:20:35 So this is another thing I wanted to highlight 17:21:12 #link https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Fjuno_releases_.2812_months.29 17:21:43 I've pinged apevec today, and he is planning to release last juno release this week 17:21:47 unless something happens 17:22:33 and that something is happening in this #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/078630.html ML thread =) 17:23:07 So what I wanted to say is that most likely We'll release the last release of juno this week. 17:23:12 marking its EOL 17:23:36 kzaitsev_mb: agree :) 17:23:54 we need to verify that everything is merged there first 17:23:55 oh yeah, if someone doesn't know it yet — I'm the one who's going to carry out release duties during M cycle =) 17:24:16 Yep - sorry forgot to announce that :) 17:24:28 kzaitsev_mb: thank you so much for agreeing to help me with that :) 17:26:58 kzaitsev_mb: congrats with the new duties) 17:27:44 well, I actually do not have anything to add on the topic =) 17:28:08 Nikolay_St: as if new duties is something we all want =)))) 17:28:54 #topic Open Discussion 17:30:04 I want to discuss our docs 17:30:33 sergmelikyan: Open Discussion? :) So, we have at least one more item in agenda, or I'm wrong? 17:30:39 We still have no automatic build on RTD. And I agreed, that duplicating docs are confusing 17:30:51 katyafervent: know what you did there ;) 17:30:59 We can add link to murano docs from the official openstack page 17:31:31 well, it should be done anyway :) 17:31:58 katyafervent: looks like you added that item after I've checked the page, sorry 17:31:58 I will talk to the documentation team about it. but building on rtd is still actual question 17:32:09 katyafervent: on good idea fungi did mentions — is that we can ask folks from the doc-team. ML or attend their meeting 17:32:17 It was not me :) 17:32:21 katyafervent: true, I thought that would happen automatically once a day - but this is not working 17:32:38 right, check with the docs team about getting the main index updated 17:32:53 well, one thing that is bad right now: you can't google official documentation =( 17:32:54 that's where official projects' documentation resides 17:33:16 I can't google it anyway. google points me to readthedocs =( 17:33:29 fungi: http://docs.openstack.org/developer/openstack-projects.html - you are talking about this? 17:33:32 also, there is a way to get different versions of the docs in a better way that we don't know about :) 17:34:03 sergmelikyan, http://www.openstack.org/software/project-navigator/ 17:34:19 I'd like to see murano here ^^^ 17:34:28 katyafervent: oh, that' 17:34:33 s handled by the foundation staff 17:34:37 not the community 17:34:49 www.openstack.org is not a community maintained site 17:35:02 it's the foundation's marketing portal, basically 17:35:04 katyafervent: there was mailing thread about project navigator 17:36:23 sergmelikyan: katyafervent: Am I understanding this correctly, that we've agreed to deprecated readthedocs? 17:37:07 I think we should start working on that. At least update links everywhere to openstack docs 17:37:09 kzaitsev_mb: no, we still want them to be available and up to date, but we can't use OpenStack Infra for that like before 17:38:12 sergmelikyan: hm. so how would we update the docs then? 17:39:08 I don't find the way of automatic update, may be somebody else should look up 17:39:42 Folks, we missed one important topic... kzaitsev_mb sergmelikyan 17:40:08 I wonder if Sahara guys are having the same issue.. 17:40:20 kzaitsev_mb, they do 17:40:36 but it doesn't bother them :) 17:41:13 lol =) 17:41:28 then probably it shouldn't bother us too? 17:42:05 kzaitsev_mb: I would still prefer to have them in two places :) Doesn't hurt 17:42:31 I wonder what was the issue in the first place.. 17:43:03 sergmelikyan, it's extra headache to manage 17:43:16 well I'm ok with it as long as everyone is ok with it. Seems like doc-team and infra team are not that ok with it ) 17:43:40 gotta investigate more 17:44:08 I'm also voting for rtd deprecation 17:45:43 well, unless there would be an easy way to sync rtd 17:46:03 let's check what other projects use rtd? 17:47:21 #action: Investigate and find out way of managing RTD 17:48:06 let's discuss docs on ML or in murano later 17:49:48 freerunner: has something to talk about 17:52:44 Nikolay_St: Thanks for notification ;) 17:53:37 So, I would like to inform you guys, that today or tomorrow I will make a commit, which will enable py34 jobs for muranoclient. 17:53:46 (great) 17:53:48 ofc, it will non-voting 17:54:06 awesome =) 17:54:18 So, we have a bp for py34 support, and me and kzaitsev_mb will work on it ;) 17:54:30 isn't it py35 already? 17:54:56 When muranoclient will start support py34, rally team will move muranoclient from optional-requirements to main 17:54:57 I've done some preliminary work to see if our client is py3 ready. it isn't, but doesn't seem that bad 17:55:33 StanLagun: the jobs as of now use py34 AFAIK 17:55:44 StanLagun: I think, we should make py34 support first. 17:55:53 StanLagun: I suppose that OpenStack infrastructure is ready only for py33 and py34 17:56:22 py33 jobs alredy deprecated, so currently only py34 job is available 17:56:41 since we cannot use any of py3 features I guess it is not important anyway 17:57:06 sergmelikyan: #link https://review.openstack.org/#/c/234336/ 17:57:08 So 17:57:13 FYI https://review.openstack.org/#/c/243748/ murano link is added 17:57:24 I believe we should deprecate rtfd 17:57:45 StanLagun: It is important in case, that most of OpenStack clients have py34 support. 17:57:58 StanLagun: if muranoclient will not support py3, some project can remove support for murano or something else 17:58:45 freerunner: I meen the difference between 3.4 and 3.5 is not important for us as we can't make use of 3.5 features anyway 17:58:55 :) 17:59:38 StanLagun: AFAIK, infra heve no py35 jobs yet. 18:00:14 thank you folks for the meeting! 18:00:18 #endmeeting