17:01:21 #startmeeting app-catalog 17:01:22 Meeting started Thu Sep 15 17:01:21 2016 UTC and is due to finish in 60 minutes. The chair is docaedo. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:26 The meeting name has been set to 'app_catalog' 17:01:38 #link https://wiki.openstack.org/wiki/Meetings/app-catalog#Proposed_Agenda_for_September_15th.2C_2016_.281700_UTC.29 17:02:05 #topic Updates 17:02:24 I only have one update that does not relate to the glare work 17:02:48 I'm running for PTL again :) 17:03:11 When we switch to glare backend I think we're going to be able to get more attention around using the app-catalog regularly 17:03:34 and it will also pave the way towards some of the CI/CD stuff Igor has been talking about (which I look forward to helping with) 17:03:44 well, I guess we're going to postpone dashboard reorg to early ocata 17:03:47 so that's all for me - the rest of the meeting I think will be all things Glare transition 17:04:27 today's the deadline for rc1 releases and I'm only hours away from requesting those 17:04:46 kzaitsev_mb: sorry for not being able to get more time to review, and then yesterday I finally had a chance to make an environment work right, but since app-catalog-ui is essentially broken right now, need to fix that before we can validate anything else 17:05:31 I think dashboard re-org will be OK if it slips a little bit 17:05:52 really hard to tell how many people are using that plugin in their horizon also 17:06:23 docaedo: np, don't think it's that critical ) we have most of the work done and can land the changes early in ocata to give packagers some time to update deb/rpm ones 17:06:35 cool 17:06:39 since there would be config changes 17:07:50 yep 17:08:17 ok let's talk about glare stuff, and what we can accomplish for the next week 17:09:42 #link https://review.openstack.org/#/c/370295/ 17:09:45 #link https://review.openstack.org/#/c/370366/ 17:09:51 i start spliting my patch 17:10:08 any comments are welcome 17:10:29 o/ 17:10:33 cool, I will start poking through it now, trying to make time to focus on this work 17:10:39 theese two are python, and others are javascript 17:10:43 sskripnick: everything that is related to this is in https://review.openstack.org/#/q/topic:bp/glare-work right? 17:10:55 docaedo: yep 17:11:12 great 17:11:15 sskripnick: may I ask you to abandon the old commits? 17:11:36 the ones, that were related to v0_1 17:12:30 kzaitsev_mb: is it okay to abandon no my patches? =) 17:12:57 kill them with fire :) 17:13:03 sskripnick: yep, since we're anyway going to use v1.0 right away — there is no use to have them hanging around 17:13:04 -_- 17:13:12 okay 17:16:09 nice 17:16:53 sskripnick: other than needing review feedback, is there anything else we can do to support you? I saw from the glare meeting that packaging for glare is coming in a few days so that will solve most of the deployment questions 17:17:40 docaedo: correct 17:17:42 sskripnick: and it looked from the mailing list like Infra was on board with the transition plan (note latest message from fungi about needing to reference a specific commit in puppet since branches were not going to be an option) 17:18:34 docaedo: It seems I have missed last message from fungi 17:19:08 let me double-check where i got to on that 17:19:10 docaedo: does it mean that we age going to merge everyting in master? 17:19:18 #link http://lists.openstack.org/pipermail/openstack-infra/2016-September/004730.html 17:20:01 yeah, there's a feature/glare-support branch in app-catalog now, so you should be able to start safely merging non-backward-compatible behavior changes there 17:20:07 eventually everything will be merged in master, but pre-merge, the VCS-repo puppet lib can handle being pointed at a ref 17:20:15 ooh we have a fungi! 17:20:31 quick everyone, ask all your tough infra questions! :p 17:20:31 okay, seems good 17:20:42 =))))) 17:20:43 it's just the puppetry we can't branch 17:20:58 rather, we can't branch in git (but we can branch with logic) 17:21:08 makes sense to me 17:21:50 so make the puppet module capable of deploying from a parameterized branch or git refname, and then we can use different ones for teh dev and prod servers 17:22:20 giving you te ability to preview your feature branch on the dev site until you're ready to pull the switch for prod 17:23:02 so these puupets should be able to deploy from git right? so why we are waiting for .debs? 17:23:36 sskripnick: because Peter asked us about it 17:23:47 sskripnick: I thought you were the one who argued for packages rather than deploying from git? 17:24:10 (I'm +1 for deploying from git myself, but I saw the logic of having a package as well) 17:24:49 it allows to resolve dependencies much easier 17:25:14 packages is okay, but it seems we can use them for automation 17:25:19 cant* 17:25:34 hm. why? 17:26:05 well, you could but it adds an extra speedbump in the deployment automation if you need to have a custom package repository deploying packages built from two different branches 17:26:58 what sort of packages are you talking about? sdist/wheel? npm? deb? rpm? something else? 17:27:05 deb 17:27:51 do you have branch-tip build automation in place for making debs of the app-catalog repo? 17:28:00 nope 17:28:45 and I cant. deb should be signed, and it can be signed only manually 17:28:54 the pkg-deb team have some mostly working for a lot of projects, but i don't know if they're yet in a state where you could add a custom sources.list entry and apt-get install from them 17:29:46 we have the ability to automatically sign the releases files for deb repos, but you'd need to add an apt-key trust for our artifact signing key (and update it when we rotate it every cycle) 17:30:05 i see 17:30:33 btw current puppets are working with pypi, so maybe we just continue using it 17:31:14 pypi is good to 17:31:26 can we use pypi version instead of git ref? 17:31:27 too 17:31:36 yeah, we could always have a logical switch in the manifest that installs latest app-site from pypi or installs from an arbitrary git ref/refname from a local clone managed by a vcsrepo resource 17:32:45 so you could have your dev site currently pip install /opt/app-site which is cloned from the feature/glare-support branch of the app-site repo, and then the production server ensure=>latest from a pip package provider instead 17:33:17 and once you merge feature/glare-support back into master, you could switch the dev site to deploy from the tip of master in git while leaving production deploying from pypi 17:33:38 so it continues to give you a place to preview your master branch state before you tag new releases 17:33:54 cool 17:34:11 er, i meant /opt/app-catalog above, but you probably knew that 17:34:20 yup 17:34:32 okay, looks awesome. thank you 17:35:07 let me know if you hit any other confusion or snags. always happy to help if i have time 17:35:43 ok, thanks a lot 17:36:08 thanks fungi! 17:36:14 you're welcome 17:37:58 I don't have any other questions at this point, just know I need to get some review feedback going for sskripnick 17:38:41 any open discussion points from anyone? I could change the topic and we can chat, otherwise we might get 20 minutes back in our day! 17:40:08 nothing here 17:40:50 cool - then I think we are done? I'll wait another minute or two just in case kzaitsev_mb has something to say but has his keyboard on mute ;) 17:41:47 nope =) I'm half ready to make my rc1 commits =) 17:42:11 nice - well thanks a ton you guys! Who's going to be in Barcelona by the way? 17:44:18 * fungi obviously 17:44:34 * docaedo as well 17:45:18 hoping kzaitsev_mb mfedosin and sskripnick all got the green light from whoever makes that call these days at their J-O-B 17:45:35 ok gonna wrap it up - talk to you on #openstack-app-catalog! 17:45:40 #endmeeting