17:01:16 #startmeeting app-catalog 17:01:17 Meeting started Thu Aug 4 17:01:16 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:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:21 The meeting name has been set to 'app_catalog' 17:01:25 o/ 17:01:26 #link https://wiki.openstack.org/wiki/Meetings/app-catalog#Proposed_Agenda_for_August_4th.2C_2016_.281700_UTC.29 17:01:53 o/ 17:02:07 We usually start with status updates, but I'll start a small/easy (maybe?) topic real quick, since the rest of the meeting is mostly going to be status updates and talking about them 17:02:11 sskripnick is sick 17:02:49 mfedosin: unacceptable! app-catalog has no sick days! 17:02:55 #topic Review and merge policies (docaedo) 17:03:17 I brought this up because I realize we've never (as a team) formally talked about this 17:03:43 and the way I review and merge additions to assets is different from how I consider anything that could actually break the web site 17:04:17 so just wanted to state how I'm doing it, and see if there's agreement or if anyone thinks I'm being too crazy with the +W 17:04:23 Basically: 17:05:13 if it's just adding or updating assets (touching assets.yaml) I do not think we need to sit on those updates, and I feel like it's safe for me (or other cores, which really now is just kzaitsev_mb) to merge if it looks good 17:05:42 but if it's a schema change or something that impacts the web site, there should be at least one other reviewer, and generally should sit for 24 hours to give anyone who cares a chance to look at it 17:05:51 thoughts/opinions on that? 17:06:46 so you basically suggest a single +2+A policy for changes, that only affect assets.yaml 17:07:04 kzaitsev_mb: yes, well said 17:07:40 sounds reasonable to me, since it shouldn't break anything, and many projects have very similar rules, say for i18n commits or proposal bot commits 17:08:03 +1. I see nothing bad in it 17:09:27 cool thanks - I wanted to make sure everyone was OK with that just in case I was being too much of a cowboy 17:09:59 #topic Status updates 17:10:05 sounds like a plan 17:10:30 we have a big update today 17:10:31 #agreed a single +2+A policy for changes, that only affect assets.yaml 17:10:34 =) 17:10:35 for me, I'm planning to continue going through bugs and blueprints, just to try to do some grooming 17:10:37 Glare leaves Glance project 17:10:43 kzaitsev_mb: thanks 17:11:01 there is a mail in ML 17:11:26 I think it'll help us to move forward faster 17:11:30 mfedosin: yeah I saw that .. it makes sense, is a little unfortunate that it's come to that, but I can see why. If just talking about storing a disk image leads to so much confusion, I don't see how glare can continue as is 17:12:55 #link http://lists.openstack.org/pipermail/openstack-dev/2016-August/100862.html 17:12:56 so, we'll spend next week moving our code to the new repo 17:12:56 mfedosin: as asked by SpamapS it would be good to put together a clear retrospective on this to also share, so people can see why you felt the split was the best step forward 17:12:58 this one? ^^ 17:13:16 kzaitsev_mb: thats the one 17:13:18 kzaitsev_mb: correct 17:14:03 tim and clint asked good question on the thread and are making good points, that this will hurt adoption, but from what I saw it sounded like glance project had said there would be very long term restrictions on what "glare" would be allowed to do while under glance, is that right? 17:15:11 docaedo: unfortunately yes 17:15:53 there were no specs merged in Glance during Newton cycle 17:16:26 no new features had been added since Juno cycle 17:16:50 and I'm afraid that the same may happen with Glare 17:17:46 We may wallow in useless discussions if we stay in Glance 17:17:49 understandable 17:18:29 so, have you seen what sskripnick did? 17:18:29 I think everything else to talk about today falls under this topic: 17:18:34 #topic Next steps for Glare integration 17:18:51 Sounds like you will have some work this next week to move the repo 17:18:53 #link http://r-ci.tk:8100/#/ 17:19:10 I was wondering if I could get the deployment information for that test environment? 17:19:31 I'd like to recreate it on a different machine and start working through the puppet manifest we'll need to deploy it to production 17:19:56 and once I have a "close enough" version (even if it's not complete), I can commit a review for infra to look at 17:19:57 yes, but for sure code will be merged before the week after 17:20:18 then we'll get that up on a staging VM to work through integration with swift, DB, etc 17:20:34 he added auth with OpenID, adding new artifacts, and so on 17:20:35 maybe we should catch sskripnick and demand some (answers) instructions? =) 17:21:08 Sergey will be available tomorrow 17:21:14 and we can chat with him 17:21:19 kzaitsev_mb: good plan, hopefully he'll be feeling better 17:21:38 also he pushed all code on review 17:21:39 tomorrow will be a really good day for me to work on that too, if we have a chance any way 17:22:19 gotta ping him anyway on the fate of our commits with v0.1 17:22:45 probably we would abandon them 17:22:51 kzaitsev_mb: they should be abandoned :) 17:23:01 just need a confirmation from his side, then 17:23:18 He agrees with that, I know 17:24:04 kzaitsev_mb: okay, let's wait for tomorrow and get his confirmation 17:24:21 sounds like there's not much more on this then, until we get more details tomorrow? and of course the big news of glare splitting out 17:24:43 docaedo: I have several questions about storing images... 17:25:11 first of all, is there any storage for binary assets in App-Catalog? 17:25:13 ok great, ask away, let's talk! 17:25:25 like swift or ceph or anything else? 17:25:30 mfedosin: binary assets will be stored in swift 17:25:39 swift will not run on that node, we'll get credentials to it 17:25:44 docaedo: cool, swift is good 17:26:10 what about images? 17:26:28 do we have any plans to store them in our local swift? 17:26:48 or we just want provide link to some external sources 17:27:48 mfedosin: images could be store the same way in swift (as they are in the CDN now), but maybe the question is do we provide a direct link to swift, or proxy everything through glare? 17:28:18 I don't know how glare handles versions with respect to the object itself? I assume because of versions, we'll need glare to proxy everything 17:28:34 if we add image to glare directly, then it will be proxied 17:28:40 (and I'm not sure what you mean when you say "local swift", because we won't run swift on the app-catalog VM) 17:29:13 yeah, by "local swift" I mean swift we have credentials for 17:29:47 mfedosin: ah right, ok - then yes, plan will be to store things in local swift if the user wants, otherwise they can just put in an entry that has a pointer to something external (like with heat templates) 17:30:27 that's great, glare supports both ways - with internal and external locations 17:30:30 we will need both types, some users will want to just point (like pointing at a coreos weekly image or something) vs. I know murano wants the images to be stored in the app catalog 17:30:55 great, I know that was the plan we discussed long ago, so happy it's still the plan 17:31:56 I just wanted to understand what to do with images 17:32:06 also, there is another topic 17:32:09 thank you for asking and making sure we're on the same page 17:32:36 I think we have to make glare to provide public api 17:33:10 so, there will be a web site (app-catalog) and near there will be genereic glare api 17:33:20 for glare-to-glare communication 17:33:25 sure, I think it's just going to be a route so apps.openstack.org/api/v2 -> glare 17:33:28 and for Horizon plugin 17:34:12 that should work, right? 17:34:21 absolutely 17:34:49 imarnat asked to write docs about app-catalog/glare integration 17:35:54 oops, kzaitsev_mb corrected me 17:37:04 we decided, that it will be just new domain 17:37:11 that's a good point, to make sure we are covering everything on the docs 17:37:30 like glare.apps.openstack.org/ -> glare 17:37:32 new domain? what do you mean? 17:38:01 oh for direct glare access, I don't remember that but I do not object and it seems reasonable 17:38:38 as long as glare is protected via the same auth 17:38:39 yes, for direct glare access 17:39:19 mfedosin: docaedo: it would be trivial to route glare.apps.openstack.org/ to apps.openstack.org/api/v2 actually =) 17:39:38 so the direct access can still be proxied with not-so-direct access ) 17:40:27 and for sure there will be apps.openstack.org/api/v2 -> glare 17:41:10 nice - so how should we tackle the documentation? 17:43:49 17:44:00 *cough* 17:44:04 I am sure we all agree SOMEONE should write the documentation :) 17:44:07 I hope to start the documentation next week 17:44:21 #action mfedosin foolishly agrees to start the documentation 17:44:25 :P 17:44:36 I'll be on vacation, but I'll be able to find some time 17:44:49 oh wait! don't do that on vacation! 17:46:07 mfedosin: but if you start an outline on an etherpad and share it on #openstack-app-catalog I can help, and hopefully others as well 17:47:45 I don't like write docs in etherpad 17:47:54 I prefer google docs 17:48:28 mfedosin: sure, that can work for collaborating, then ultimately it would need to go into probably app-catalog/docs repo 17:48:34 I'll add as a reviewer 17:48:47 that works for me 17:50:09 #topic Open discussion 17:50:19 Anyone have anything for open discussion today? 17:51:07 not I 17:51:44 I learned everything I wanted. 17:51:48 not me, I've just returned from vacations and trying to deal with the ammount of mail I have to read/respond to ) 17:52:20 kzaitsev_mb: just declare unread email bankruptcy and mark it all as read! 17:52:56 OK I think we are done then, thanks everyone, and looking forward to talking hopefully more on glare stuff tomorrow! 17:53:37 #endmeeting