17:01:16 <docaedo> #startmeeting app-catalog
17:01:17 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:21 <openstack> The meeting name has been set to 'app_catalog'
17:01:25 <mfedosin> o/
17:01:26 <docaedo> #link https://wiki.openstack.org/wiki/Meetings/app-catalog#Proposed_Agenda_for_August_4th.2C_2016_.281700_UTC.29
17:01:53 <kzaitsev_mb> o/
17:02:07 <docaedo> 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 <mfedosin> sskripnick is sick
17:02:49 <docaedo> mfedosin: unacceptable! app-catalog has no sick days!
17:02:55 <docaedo> #topic Review and merge policies (docaedo)
17:03:17 <docaedo> I brought this up because I realize we've never (as a team) formally talked about this
17:03:43 <docaedo> 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 <docaedo> 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 <docaedo> Basically:
17:05:13 <docaedo> 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 <docaedo> 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 <docaedo> thoughts/opinions on that?
17:06:46 <kzaitsev_mb> so you basically suggest a single +2+A policy for changes, that only affect assets.yaml
17:07:04 <docaedo> kzaitsev_mb: yes, well said
17:07:40 <kzaitsev_mb> 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 <mfedosin> +1. I see nothing bad in it
17:09:27 <docaedo> 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 <docaedo> #topic Status updates
17:10:05 <olaph> sounds like a plan
17:10:30 <mfedosin> we have a big update today
17:10:31 <kzaitsev_mb> #agreed a single +2+A policy for changes, that only affect assets.yaml
17:10:34 <kzaitsev_mb> =)
17:10:35 <docaedo> for me, I'm planning to continue going through bugs and blueprints, just to try to do some grooming
17:10:37 <mfedosin> Glare leaves Glance project
17:10:43 <docaedo> kzaitsev_mb: thanks
17:11:01 <mfedosin> there is a mail in ML
17:11:26 <mfedosin> I think it'll help us to move forward faster
17:11:30 <docaedo> 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 <kzaitsev_mb> #link http://lists.openstack.org/pipermail/openstack-dev/2016-August/100862.html
17:12:56 <mfedosin> so, we'll spend next week moving our code to the new repo
17:12:56 <docaedo> 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 <kzaitsev_mb> this one? ^^
17:13:16 <docaedo> kzaitsev_mb: thats the one
17:13:18 <mfedosin> kzaitsev_mb: correct
17:14:03 <docaedo> 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 <mfedosin> docaedo: unfortunately yes
17:15:53 <mfedosin> there were no specs merged in Glance during Newton cycle
17:16:26 <mfedosin> no new features had been added since Juno cycle
17:16:50 <mfedosin> and I'm afraid that the same may happen with Glare
17:17:46 <mfedosin> We may wallow in useless discussions if we stay in Glance
17:17:49 <docaedo> understandable
17:18:29 <mfedosin> so, have you seen what sskripnick did?
17:18:29 <docaedo> I think everything else to talk about today falls under this topic:
17:18:34 <docaedo> #topic Next steps for Glare integration
17:18:51 <docaedo> Sounds like you will have some work this next week to move the repo
17:18:53 <mfedosin> #link http://r-ci.tk:8100/#/
17:19:10 <docaedo> I was wondering if I could get the deployment information for that test environment?
17:19:31 <docaedo> 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 <docaedo> 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 <mfedosin> yes, but for sure code will be merged before the week after
17:20:18 <docaedo> then we'll get that up on a staging VM to work through integration with swift, DB, etc
17:20:34 <mfedosin> he added auth with OpenID, adding new artifacts, and so on
17:20:35 <kzaitsev_mb> maybe we should catch sskripnick and demand some (answers) instructions? =)
17:21:08 <mfedosin> Sergey will be available tomorrow
17:21:14 <mfedosin> and we can chat with him
17:21:19 <docaedo> kzaitsev_mb: good plan, hopefully he'll be feeling better
17:21:38 <mfedosin> also he pushed all code on review
17:21:39 <docaedo> tomorrow will be a really good day for me to work on that too, if we have a chance any way
17:22:19 <kzaitsev_mb> gotta ping him anyway on the fate of our commits with v0.1
17:22:45 <kzaitsev_mb> probably we would abandon them
17:22:51 <mfedosin> kzaitsev_mb: they should be abandoned :)
17:23:01 <kzaitsev_mb> just need a confirmation from his side, then
17:23:18 <mfedosin> He agrees with that, I know
17:24:04 <mfedosin> kzaitsev_mb: okay, let's wait for tomorrow and get his confirmation
17:24:21 <docaedo> 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 <mfedosin> docaedo: I have several questions about storing images...
17:25:11 <mfedosin> first of all, is there any storage for binary assets in App-Catalog?
17:25:13 <docaedo> ok great, ask away, let's talk!
17:25:25 <mfedosin> like swift or ceph or anything else?
17:25:30 <docaedo> mfedosin: binary assets will be stored in swift
17:25:39 <docaedo> swift will not run on that node, we'll get credentials to it
17:25:44 <mfedosin> docaedo: cool, swift is good
17:26:10 <mfedosin> what about images?
17:26:28 <mfedosin> do we have any plans to store them in our local swift?
17:26:48 <mfedosin> or we just want provide link to some external sources
17:27:48 <docaedo> 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 <docaedo> 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 <mfedosin> if we add image to glare directly, then it will be proxied
17:28:40 <docaedo> (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 <mfedosin> yeah, by "local swift" I mean swift we have credentials for
17:29:47 <docaedo> 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 <mfedosin> that's great, glare supports both ways - with internal and external locations
17:30:30 <docaedo> 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 <docaedo> great, I know that was the plan we discussed long ago, so happy it's still the plan
17:31:56 <mfedosin> I just wanted to understand what to do with images
17:32:06 <mfedosin> also, there is another topic
17:32:09 <docaedo> thank you for asking and making sure we're on the same page
17:32:36 <mfedosin> I think we have to make glare to provide public api
17:33:10 <mfedosin> so, there will be a web site (app-catalog) and near there will be genereic glare api
17:33:20 <mfedosin> for glare-to-glare communication
17:33:25 <docaedo> sure, I think it's just going to be a route so apps.openstack.org/api/v2 -> glare
17:33:28 <mfedosin> and for Horizon plugin
17:34:12 <docaedo> that should work, right?
17:34:21 <mfedosin> absolutely
17:34:49 <mfedosin> imarnat asked to write docs about app-catalog/glare integration
17:35:54 <mfedosin> oops, kzaitsev_mb corrected me
17:37:04 <mfedosin> we decided, that it will be just new domain
17:37:11 <docaedo> that's a good point, to make sure we are covering everything on the docs
17:37:30 <mfedosin> like glare.apps.openstack.org/ -> glare
17:37:32 <docaedo> new domain? what do you mean?
17:38:01 <docaedo> oh for direct glare access, I don't remember that but I do not object and it seems reasonable
17:38:38 <kzaitsev_mb> as long as glare is protected via the same auth
17:38:39 <mfedosin> yes, for direct glare access
17:39:19 <kzaitsev_mb> mfedosin: docaedo: it would be trivial to route glare.apps.openstack.org/ to apps.openstack.org/api/v2 actually =)
17:39:38 <kzaitsev_mb> so the direct access can still be proxied with not-so-direct access )
17:40:27 <mfedosin> and for sure there will be apps.openstack.org/api/v2 -> glare
17:41:10 <docaedo> nice - so how should we tackle the documentation?
17:43:49 <docaedo> <crickets>
17:44:00 <olaph> *cough*
17:44:04 <docaedo> I am sure we all agree SOMEONE should write the documentation :)
17:44:07 <mfedosin> I hope to start the documentation next week
17:44:21 <docaedo> #action mfedosin foolishly agrees to start the documentation
17:44:25 <docaedo> :P
17:44:36 <mfedosin> I'll be on vacation, but I'll be able to find some time
17:44:49 <docaedo> oh wait! don't do that on vacation!
17:46:07 <docaedo> 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 <mfedosin> I don't like write docs in etherpad
17:47:54 <mfedosin> I prefer google docs
17:48:28 <docaedo> mfedosin: sure, that can work for collaborating, then ultimately it would need to go into probably app-catalog/docs repo
17:48:34 <mfedosin> I'll add as a reviewer
17:48:47 <docaedo> that works for me
17:50:09 <docaedo> #topic Open discussion
17:50:19 <docaedo> Anyone have anything for open discussion today?
17:51:07 <olaph> not I
17:51:44 <mfedosin> I learned everything I wanted.
17:51:48 <kzaitsev_mb> 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 <docaedo> kzaitsev_mb: just declare unread email bankruptcy and mark it all as read!
17:52:56 <docaedo> OK I think we are done then, thanks everyone, and looking forward to talking hopefully more on glare stuff tomorrow!
17:53:37 <docaedo> #endmeeting