17:00:52 #startmeeting app-catalog 17:00:52 Meeting started Thu Jun 30 17:00:52 2016 UTC and is due to finish in 60 minutes. The chair is docaedo. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:56 The meeting name has been set to 'app_catalog' 17:01:06 #topic Status updates 17:01:23 Might as well dive right in, kzaitsev_mb and mfedosin probably have much to share :) 17:01:48 yeah, we have something :) 17:02:04 ok, so I would like to revive the discussion we had back in Austin about our dashboards and OSC CLIs 17:02:43 ping me when it's glare related topic 17:02:45 I've pushed a couple of commits on review, that show how we can make it so, that muranodashboard and app-catalog-ui would share the same Dashboard in horizon 17:03:00 I looked at the code a bit today, and have a devstack environment I'll try it in 17:03:11 docaedo: I can share a gif of the recording 17:03:23 kzaitsev_mb: that would be great for others to see, thanks 17:03:28 don't think, that the commits are devstack ready yet 17:03:44 https://www.dropbox.com/s/26sfxpoc9hd8gi7/shared_dashboard.gif?dl=0 17:04:23 they involve changing the horizon config files, i.e. that change has to be made in devstack config 17:04:28 of horizon 17:04:40 #link https://www.dropbox.com/s/26sfxpoc9hd8gi7/shared_dashboard.gif?dl=0 17:04:44 ah ok 17:05:42 Does it work even if you don't have murano installed? I think that was the hard part to figure out, guessing you figured it out 17:05:45 And they're all red because of than =) tests fail to run roperly since horizon is not configured properly by devstack plugins %) 17:05:54 docaedo: yes! that was the goal 17:06:17 awesome! 17:06:25 so if you have either murano or app-catalog you would get only relevan panels, but both would spawn an 'Applications' dashboard 17:06:46 watching the gif now, looks great! 17:06:53 we would have 2 identical files in our repos, but they're like 3 lines long 17:07:11 * olaph apologies for being late... 17:07:45 #link https://review.openstack.org/#/c/335725/4/app_catalog/enabled/_50_dashboard_applications.py 17:07:48 welcome olaph :) dig that link to the dropbox gif, looks sweet 17:07:57 this one actually initialises the Applications dashboard 17:08:20 and all the rest of the configs are decoupled into smaller chunks 17:09:05 that's great stuff 17:09:06 so. I would like to revive the discussion about the names of the panels =) The hardest thing in programming ) 17:09:52 docaedo: what do you think — should we create an etherpad and advertise it on ML, to get some ideas brainstormed 17:10:01 and also get some of kfox1111's attention =) 17:11:08 sure .. I don't even remember what the debate was to be honest but best to lay it out 17:11:45 docaedo: If my memorey serves me right — we agreed to agree later on the layot =) 17:11:49 mostly I don't think anyone will care - there's murano team that has strong opinions and a history, and from the app catalog side I have some opinions, and kfox1111 does as well though he's pretty busy on other fronts these days 17:12:15 I think the idea of combining things under "applications" in general makes sense (like we agreed for the CLI piece) 17:12:48 and there are no other projects that I'm aware of who would lay claim to using "applications" in this context :) 17:12:59 but laying it out clear on an etherpad is the best plan 17:13:44 I've got to dig out those etherpads and see how exactly we've wanted to name it in the CLI ) 17:14:48 (I'll look for it in a second, I think I can find quick) .. my memory though was that we would put app-catalog and murano stuff under same "applications" name space 17:15:07 so, ok. I can take that action item. Wanted to do it like this Tuesday, but figuring out the dashboards prooved to be more difficult than I thought %) 17:15:11 then have clear distinctions on when something is available locally, or in the remote catalog 17:15:34 yeah dashboards are never as easy as you expect right? 17:15:39 in fact there's going to be a giant commit, that just does a renaming of the urls in muranodashboard =) 17:16:01 busting .pyc left from renamed configs is the worst! 17:16:12 ok then 17:16:49 haha yeah true - doesn't have to break though, can be compatible so old users don't get grump 17:17:00 *grumpy 17:17:37 #action kzaitsev_mb file an etherpad with potential 'Applications' dashboard layouts and advertise it on ML 17:18:25 #link https://etherpad.openstack.org/p/AUS-app-catalog 17:18:35 That's from the Austin summit 17:18:49 * docaedo is scared to look, suspects he's got a stack of action items that need some action... 17:19:39 yeah. and the deadline for Barcelona's talks is like a couple of weeks away... 17:19:43 but the very bottom of that etherpad is what I was remembering with panels, and I think we basically agreed then - good to start a ML thread to confirm 17:20:06 yep, basically two weeks left for talk submissions 17:20:08 And I remember having an AI to verify that it's possible/feasible =) 17:20:19 nice work, you did it! 17:20:25 kind of ) 17:21:25 ok, I think we're done with this part then 17:21:38 cool 17:21:53 any other updates from things you've been working on? 17:22:18 I think we have a few things to say about glare 17:22:28 1st — the auth part 17:22:55 #link https://review.openstack.org/#/c/332911/ 17:23:18 sskripnik (sad he's not here) did it a bit differently than I thought, but still feasible 17:23:23 oh yeah, I had a question about needing memcache running on the app-catalog server 17:23:54 for other work I've also been looking at http://openid.net/specs/openid-authentication-2_0.html lately 17:23:55 since we have v2 as a proxy for glare — he just add auth to v2 17:24:17 instead of making it a middleware before glare 17:24:27 that makes sense 17:24:43 From the first glance (I'm not shure if the pun is intended) the approach looks ok 17:25:07 woop woop 17:25:45 haha yeah I have not dug through it deeply but I liked it also when I poked at it 17:26:10 also there is a problem, that there seems to be no way to pull gerrit groups from review.openstack.org so instead he suggested using launchpad groups 17:26:24 for admin access I mean 17:27:52 technically that seems like 2 almost equal solutions. private groups, that only members have access/can add new members =) 17:27:53 hmm - I think that would be fine, but it would I think make sense to get help from infra regarding gerrit groups, because I am pretty sure they use those groups for other stuff 17:28:12 because launchpad will go away in the future, almost for sure 17:28:49 well, lets ask them if they know a way, then 17:29:48 #action kzaitsev_mb and sskripnik ask infra if they know a way to reuse gerrit groups for/with ubuntu one openid 17:30:10 excellent plan :) 17:30:52 memcache. I believe it's used/required to store session info 17:31:21 feels pretty sane to me 17:31:22 I guess memcache is not a big deal, I just want to be clear about scope creep 17:31:34 although I love redis a lot more %) 17:32:15 since with redis — restarting it doesn't log everyone out magically 17:32:41 true, but don't think we need to worry too much about that happening now 17:32:57 like logged in sessions shouldn't be all that long I think 17:33:15 and pretty sure that machine never gets rebooted :) 17:33:45 but I'm good with things the way they are looking so I'm not going to be fighting any of it 17:35:02 I think that's all I have about auth stuff and we're only left with the glare itself ) 17:35:22 great 17:35:41 we've been kicking it for long enough to have glare v1 almost baked, right mfedosin? =) 17:36:20 hello again 17:36:37 so, we consider glare v1 is production ready at this moment 17:36:50 all required features are implemented 17:37:04 and glare is pretty stable now 17:37:26 * docaedo cheers 17:37:38 for this reason we're going to start implementing artifact type for various openstack services 17:37:48 and the first on is Murano 17:37:57 because they are the closest to me :) 17:38:05 makes sense 17:38:23 tomorrow we will be sitting with ativelkov to make it done 17:38:30 mfedosin: can we count on your help on adopting https://review.openstack.org/#/c/276857/13 this commit to V1 then? 17:38:44 and next one is Heat 17:38:57 thanks kzaitsev_mb that's one thing I was going to asl 17:39:00 *ask 17:39:16 we've already created user story for adding Glare integration in Heat 17:39:39 also glare can be told to use swift for backend storage right? 17:40:02 kzaitsev_mb: I think Sergey should take care of this 17:40:11 dobson: sure 17:40:20 docaedo: 17:40:24 ^ 17:40:32 haha yeah I figured bad tab-complete ;) 17:40:52 sskripnik you mean? =) ok, will ping him 17:41:02 #action docaedo to confirm with infra that we'll have access to a swift somewhere for glare storage 17:41:03 one thing that disappoints me is glance community 17:41:55 it's really slow to push things to glance 17:42:12 and glare is not an exception, unfortunately 17:42:55 and because N-2 is close we have to think on plan B 17:43:40 for us, glare components do not have to be released 17:43:52 if it's not merged till 15th of July we would have no option rather then moving to new project 17:43:55 it doesn't have to interact with anything else - so we can have a branch just for app-catalog or something 17:44:25 kind of... 17:44:43 basically if there's a stable stack of commits, we can use that as a public PoC for glare 17:44:51 but I believe that it will be merged next week when our ptl comes back from PTO 17:45:48 great 17:46:18 yeah :) I cross my fingers 17:48:05 cool :) 17:48:13 we have 12 minutes left, any other updates? 17:48:34 none from my side =) got a bunch of AI's to do ) 17:48:40 +1 :) 17:48:51 cool, I have at least one this week 17:49:36 cool, I think we are done - thanks a ton guys and looking forward to starting to actually implement this soon! 17:50:19 #endmeeting