17:01:29 <docaedo> #startmeeting app-catalog
17:01:29 <openstack> Meeting started Thu Aug 11 17:01:29 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:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:32 <openstack> The meeting name has been set to 'app_catalog'
17:01:37 <olaph> o/
17:01:43 <docaedo> #link https://wiki.openstack.org/wiki/Meetings/app-catalog#Proposed_Agenda_for_August_11th.2C_2016_.281700_UTC.29
17:01:49 <docaedo> ^^ todays agenda
17:02:07 * docaedo thinks maybe "status updates" should be removed since that's often the whole meeting :)
17:02:14 <kzaitsev_mb> o/
17:02:31 <docaedo> #topic Status updates
17:02:49 <sskripnick> I have a little update
17:02:51 <sskripnick> http://r-ci.tk:8100/
17:02:54 <docaedo> I don't have any status updates that don't relate to things we have for later in the agenda (ie. glare stuff)
17:03:18 <sskripnick> Here you can login/logout and if you are member of app-catalog-core team (on launchpad) you can approve drafts
17:03:38 <sskripnick> app-catalog-core is open group, anyone can join
17:03:49 <docaedo> sskripnick: nice! I'll check that out later today
17:04:04 <docaedo> Oh I do have an update - I am on leave starting tomorrow, will return 8/22
17:04:22 <docaedo> We can have a meeting next week, would just need kzaitsev_mb to volunteer to chair it :)
17:04:49 <kzaitsev_mb> sure, have no problem with that =)
17:05:02 <sskripnick> so have a nice ... almost two weeks =)
17:05:19 <docaedo> oh just one week plus a day :) but yes, will be a nice break
17:06:36 <docaedo> OK we can move on to...
17:06:36 <docaedo> #topic App Catalog API v2.0 spec and framework (flask+sqlalchemy, django, something else?)(sskripnick)
17:07:07 <sskripnick> so if we are going to have own backend, we need some framework
17:07:20 <sskripnick> we have already django and flask in codebase
17:07:29 <sskripnick> i think we should chose one of them
17:07:54 <sskripnick> I not big fan of alchemy, so I prefer to use django
17:08:06 <docaedo> I am confused a little - glare is the backend piece, and the front end (web UI) should talk to glare via the API
17:08:39 <docaedo> I'm just not sure here what has to change other then augmenting what already exists on the web UI piece
17:08:45 <sskripnick> glare is not enough. we need to store some additional info like user comments
17:09:20 <sskripnick> btw we had a discussion with you and kzaitsev_mb %)
17:09:35 <docaedo> sskripnick: ah right, that's the part, thanks - in tokyo it sounded like the rating parts could be stored as metadata with each individual asset, but that is not going to be possible I think
17:10:17 <sskripnick> yes. also we need to be able to perform fulltext search
17:10:27 <sskripnick> and display only latest versions of artifacts
17:10:36 <sskripnick> currently glare cant do this
17:10:37 <docaedo> sskripnick: I like django too
17:10:52 <docaedo> how does/will glare handle versioning?
17:11:06 <docaedo> because that was a major reason for starting with glare instead of just writing our own to handle that
17:11:26 <kzaitsev_mb> +1 on django (I actually like it's orm a bit more that sqlalchemy, but that's just a matter of tast I suppose)
17:11:31 <sskripnick> glare does handle versioning, but it show all artifact versions when listing
17:12:03 <docaedo> sskripnick: but that's easy - the UI can ask for all versions but only display the newest
17:12:20 <sskripnick> glare cant handle this
17:12:28 <sskripnick> it always show everything
17:12:32 <docaedo> and what I'm getting at is that we can implement glare without having to do EVERYTHING at once (i.e. we do not need user comments, rating, etc. from the beginning)
17:12:40 <sskripnick> btw we can just unpublish old versions
17:12:55 <docaedo> sskripnick: I understand - I am saying the web UI can ask glare for everything, but only expose the newest
17:13:15 <kzaitsev_mb> however I would opt to move as much logic to frontend (i.e. angular code). This way it should b easy to reuse parts (controllers, static html, etc) in a form of XStatic packages between site and app-catalog-ui
17:13:15 <docaedo> and I don't think we want to unpublish old versions, we should have a way for a user to get at an older version if they want
17:13:22 <sskripnick> there will be issues with pagination
17:13:35 <docaedo> kzaitsev_mb: yes that's what I'm saying, put that logic in angular
17:14:34 <sskripnick> so we are going to speak with glare directly, and implement some additional features later?
17:15:14 <sskripnick> please take a look: https://review.openstack.org/#/c/354133/
17:15:27 <docaedo> why not follow the same pattern we use today? the web UI when it loads hit's the API to get the asset list, so as it is the web UI only interfaces with the API
17:16:31 <sskripnick> we have two options: communicate with glare directly for basic data, and communicate with app-catalog-own-api for some extended data like comments or full text search
17:16:48 <sskripnick> and second option -- develop single consistent api
17:16:59 <sskripnick> not be tied to glare backend
17:17:43 <docaedo> sskripnick: ok I think I understand
17:18:22 <docaedo> I would say for now, we go with first option for this work - communicate with glare directly for basic data
17:18:33 <kzaitsev_mb> I'm having a small déjà vu =)
17:18:36 <docaedo> then we iterate from there to add extended data
17:18:40 <sskripnick> btw we have to expose glare anyways. we need it for glare-to-glare syndication
17:18:58 <docaedo> but for switch to glare the goal should be basic feature compatability with current "api" of app catalog
17:19:15 <sskripnick> docaedo: ok, I like it
17:20:11 <sskripnick> so we need to emulate old api? but how we a going to create/edit assets?
17:20:27 <sskripnick> there is no yaml file anymore
17:20:36 <kzaitsev_mb> the issue here is that glare api != app-catalog api, although certain calls would be identical
17:20:37 <docaedo> no not exactly, sorry I'm probably not being clear
17:20:44 <kzaitsev_mb> sskripnick: old api only had get )
17:20:51 <docaedo> also I was looking at the conversation on the channel earlier, and noting this image: https://dl.dropboxusercontent.com/u/13626875/app-catalog.png
17:21:05 <docaedo> kfox1111 had a point that made good sense
17:21:24 <docaedo> "if we go with the top one, and glare looses all its steam, but we want to support our v2 api for a long time, we will have many more options with the bottom one."
17:21:45 <docaedo> "if glare's a huge success and we never need to add any new stuff, we can make a v3 that just removes the proxy and wait for v2 to die off."
17:22:28 <docaedo> so that was the conversation where we agreed it would make sense for app catalog to have it's own API, which is what sskripnick started with (and then I argued against, silly me!)
17:23:03 <docaedo> (I have to apologize, have been involved in a lot of other stuff lately so took me a while to remember all the app-catalog stuff this morning!)
17:23:28 <sskripnick> :)
17:24:16 <sskripnick> okay. so I can just finish current implementation and we can merge it? (with glare only. no own database)
17:24:17 <docaedo> sskripnick: just to answer also regarding emulating old API, I do not think that's a critical goal - if it turns out to be possible without much effort (and if we are already writing a shim in front of glare API that might not be hard), we could try
17:24:49 <docaedo> sskripnick: yes, I tihnk you can continue with current implementation, no need to create additional database
17:25:13 <docaedo> I think it makes sense to make glare work with minimal features, and adding on user comments, rating, etc. can come later
17:25:47 <sskripnick> ok. so django will be waiting %)
17:26:07 <kzaitsev_mb> sskripnick docaedo I'm 95% sure that it would be easy to implemenvt v1 api with glare v1 api
17:26:22 <kzaitsev_mb> and I'd like to disagree that it's not criticall
17:26:32 <kzaitsev_mb> it would break (or at least stall) app-catalog-ui
17:26:33 <sskripnick> it is easy, but why we need this? and how to use it?
17:26:37 <docaedo> sskripnick: I think django can wait - kzaitsev_mb what do you think about that?
17:26:56 <sskripnick> if we use glare we should have a UI for adding/approving
17:27:16 <docaedo> kzaitsev_mb: yes you are right about that breaking app-catalog-ui - I guess you are right that it's critical
17:27:28 <kzaitsev_mb> sskripnick: app-catalog-ui is a dashboard for a.o.o. It has been out for a while and breaking it doesn't sound good to me
17:27:34 <sskripnick> oh i understand. its all about app-catalog-ui horizon
17:27:43 <kzaitsev_mb> horizon-dashboard for a.o.o
17:27:44 <sskripnick> yes, sure we should implement it
17:29:12 <docaedo> kzaitsev_mb: do you agree that the additional functionality (rating, comments - basically stuff glare can't handle) can happen later?
17:29:30 <kzaitsev_mb> if it ever becomes a problem (after all there is a huge jon file dump) — it can be optimised(cached) and deprecated gracefully.
17:29:49 <kzaitsev_mb> docaedo: sure
17:30:12 <docaedo> kzaitsev_mb: yes I agree, creating that json from what is in glare should be really easy, and caching it and serving from api/v1 would keep us backwards compatible
17:31:14 <sskripnick> so for now we just need to finish the UI and deploy glare on subdomain and swift storage and memcached
17:31:47 <docaedo> "swift storage"?  you mean just connect to external swift somewhere right?
17:31:55 <sskripnick> yes
17:31:58 <docaedo> cool :)
17:32:15 <docaedo> ready for next argument?
17:32:22 <sskripnick> yep
17:32:32 <docaedo> #topic App Catalog API v2.0 spec and framework (flask+sqlalchemy, django, something else?)(sskripnick)
17:32:36 <docaedo> oops
17:32:46 <docaedo> #topic Artifacts verification (https://blueprints.launchpad.net/app-catalog/+spec/artifacts-verification )(sskripnick)
17:33:01 <sskripnick> the idea it to be able to verify artifacts
17:33:07 <sskripnick> like change requests in gerrit
17:33:19 <sskripnick> +v/-v from jenkins on every proposed artifact
17:33:38 <docaedo> I appreciate the idea behind this, but it's going to require a HUGE effort, and can't work easily with the existing infra gate
17:34:24 <docaedo> consider that we need a "reference" cloud to start with, otherwise to test a simple application the gate would need to first deploy devstack, then fetch a huge image (some are over 2gb)
17:34:40 <docaedo> then use murano for instance to build the heat stack
17:34:43 <docaedo> use heat to deploy it
17:34:51 <docaedo> and then eventually, somehow, "test" that
17:35:11 <sskripnick> there is some work-in-progress in murano team
17:35:13 <docaedo> That's the workflow we would follow right now if we were going to use the existing test infrastructure
17:35:34 <docaedo> if we're just talking about third-party, and these things happening on some other cloud that already exists, I think it's great :)
17:35:46 <docaedo> and basically I am in agreement that this will be a really useful thing to add
17:36:08 <sskripnick> it may be third party, or existing infra, or both
17:36:09 <docaedo> but I don't think this is tied to the app-catalog
17:36:37 <kzaitsev_mb> I'm thinking of examples and do not see any =) I mean pypi doesn't test python packages uploaded, does it? nor does docker hub or deb repos
17:36:37 <sskripnick> we need to support it to make it possible
17:36:48 <docaedo> It COULD be part of the app-catalog, but it's something next to it in a way, "providing the community a CI infrastructure for murano things"
17:37:09 <kzaitsev_mb> yep, resonates well with what imarnat is driving
17:37:28 <docaedo> I do get it, but I'm saying it does not need to start being tightly coupled to the app-catalog
17:37:37 <kzaitsev_mb> (he has just returned from vacation AFAIK btw, just sharing =))
17:37:39 <docaedo> for instance the repository split for murano that was talked about
17:37:52 <docaedo> testing the apps that get added into the murano-apps repository - that's where the focus on this CI should be
17:38:32 <sskripnick> we can make possible to do the same for other artifact types
17:38:37 <kzaitsev_mb> sskripnick: is the bp part of the ongoing work by imarnat on CI for murano-apps and other assets?
17:38:59 <sskripnick> kzaitsev_mb: no
17:39:07 <sskripnick> oh wait
17:39:10 <docaedo> honestly I think that blueprint as it stands belongs under murano, not app-catalog
17:39:19 <sskripnick> kzaitsev_mb: yes it is
17:39:36 <kzaitsev_mb> you got me confused
17:39:38 <kzaitsev_mb> =)
17:39:40 <sskripnick> -_-
17:40:31 <sskripnick> ok lets return to this later. we have enough work for today
17:40:37 <docaedo> my point is that the app catalog can't test everything that comes into it, and the way different asset types will be tested will be very different :)
17:40:56 <docaedo> I'll add my comments to the blueprint anyway, and we can at least discuss that way
17:41:05 <docaedo> though I agree, definitely not something we need to cover today :)
17:42:28 <docaedo> #topic Next steps for Glare integration
17:42:57 <docaedo> Just want to know what sskripnick wants others to do to help out with the effort at this point :)
17:43:00 <kzaitsev_mb> sskripnick: I'm not sure if the code should live in app-catalog =) it might be a separate project (at least a separate repo.) if murano is going to be one of the first asset types tested by this CI — I see little problem adding the repo under murano project
17:43:10 <kzaitsev_mb> needs to be discussed a bit =)
17:43:14 <kzaitsev_mb> ok, moving on )
17:44:11 <kzaitsev_mb> sskripnick: any demands, things we can help you with?
17:44:18 <docaedo> #action docaedo to play with login/logout/validate on http://r-ci.tk:8100/
17:44:19 <sskripnick> I need some help with puppet. Everything else almost finished
17:44:40 <sskripnick> Oh, also I need some help with html/css
17:44:55 <sskripnick> Currently UI looks a bit ugly
17:45:06 <sskripnick> and I can't make it better >_<
17:45:31 <docaedo> sskripnick: any specifics, be sure to ask on #openstack-app-catalog (might get a surprise help from kfox, never know!)
17:46:18 <sskripnick> sounds good :)
17:46:19 <docaedo> I will see what I can do about puppet deployment piece when I get back from leave
17:46:31 <sskripnick> ok thanks
17:46:57 <docaedo> #action docaedo to look at "install glare with puppet" week of 8/22
17:47:25 <docaedo> I think we are good :)  Anyone have anything else for today?
17:48:58 * docaedo will wait at least another minute or two...
17:49:52 <igormarnat_> docaedo: Hi!
17:50:01 <igormarnat_> Sorry, I'm a little bit late:)
17:50:02 <docaedo> igormarnat_: hey there!
17:50:11 <docaedo> haha yeah we were about to endmeeting :P
17:50:31 <igormarnat_> Not sure if you had a chance to discuss what exactly needs to be done to switch to new implementation which we have now in Beta
17:50:46 <igormarnat_> Do we have etherpad about it, or smth like that?
17:51:28 <docaedo> no etherpad at the moment, next step is for me to write the puppet deployment bits, and then work with infra to get it testing with their trove and swift
17:51:36 <docaedo> so we'd have a staging/test version up on openstack infra
17:52:11 <docaedo> and there's some work to do on an API shim so the API endpoint exposed is not tied to glare but exposes same functionality (as well as duplicates v1 API)
17:52:14 <igormarnat_> docaedo: got it. Do you need help with puppet?
17:52:53 <docaedo> well I'm on leave next week so I won't get to it for a week and a half, if someone else wants to pick it up in the mean time and ping folks on #openstack-infra for help that would be fine
17:53:45 <docaedo> existing deploying stuff is at https://git.openstack.org/cgit/openstack-infra/puppet-apps_site - future changes should be patches to that repo
17:55:05 <docaedo> (5 minutes left)
17:56:36 <docaedo> OK I think we're good now folks, thanks!
17:57:21 <sskripnick> thanks. bye
17:57:26 <docaedo> #endmeeting