17:01:40 <docaedo> #startmeeting app-catalog
17:01:41 <openstack> Meeting started Thu May 26 17:01:40 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:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:44 <openstack> The meeting name has been set to 'app_catalog'
17:01:52 <docaedo> #link https://wiki.openstack.org/wiki/Meetings/app-catalog Agenda
17:02:21 <igormarnat_> Just in case, we're out of electricity in the office, so I can drop offline any minute. Will try to switch to mobile network then
17:02:31 <docaedo> #topic Glare status update
17:02:34 <docaedo> Can anyone give an update on glare status?
17:02:49 <docaedo> igormarnat_: thanks for the heads up, hope the electricity comes back quick
17:03:00 <kraynevs> o/
17:03:14 <igormarnat_> kzaitsev_mb: you had news about glare in app catalog, there was some progress, right?
17:04:04 <kzaitsev_mb> Well, I've finished all the work I wanted to do with the UI side of the things
17:04:31 <kzaitsev_mb> I blieve at the summit we've agreed to fill in how we can proceed with merging, but I still haven't done that %)
17:04:51 <docaedo> I have faith you'll get to it :)
17:05:02 <mfedosin> hey!
17:05:06 <igormarnat_> kzaitsev_mb: When do you think we'll be able to switch catalog to glare backend, what else needs to be done?
17:05:09 <kzaitsev_mb> The basic idea was that we can start merging the commits and turn glare code off by default
17:05:25 <mfedosin> so, there is a spec
17:05:29 <mfedosin> #link https://review.openstack.org/#/c/283136/
17:05:44 <kzaitsev_mb> next step would be to install glare on a.o.o and turn it on
17:05:54 <mfedosin> it's about Glare v1 API and general use cases
17:06:22 <kzaitsev_mb> And after doing so — we would need to make the API private, since it's going to change once we get to v1 API from GLARE team
17:06:25 <docaedo> I think there's a bunch of testing before we turn it on
17:07:02 <mfedosin> current plan in glance team - to have 'core' code done by the 10th of June
17:07:04 <docaedo> have to validate we have an automated method to add/remove assets based on whats in assets.yaml because we don't have user auth yet, so only way to adjust the catalog is still going to be through assets.yaml
17:07:09 <kzaitsev_mb> And in between those two — we still need to work on auth middleware.
17:07:18 <mfedosin> and merge it on 15th
17:08:33 <khivin> o/
17:08:38 <kzaitsev_mb> So my next steps from here are to update the patches, so that glare is turned off by default. I'll make a list of those patches (an etherpad maybe) with explanation of the impact, maybe.
17:08:40 <docaedo> somewhere along the way we can start working on puppetizing the installation of glare (assuming access to DB via trove)
17:08:51 <igormarnat_> mfedosin: thanks for update, merge by June, 15 sounds good
17:08:52 <kzaitsev_mb> docaedo: kfox1111: does that sound ok? =)
17:09:07 <docaedo> kzaitsev_mb: that sounds good, once we can safely merge that stuff it'll give us a safe path forward
17:09:19 <docaedo> also means it becomes a little easier to test/validate locally
17:09:54 <mfedosin> here's the log from todays glance meeting http://eavesdrop.openstack.org/meetings/glance/2016/glance.2016-05-26-14.03.log.html
17:10:05 <kzaitsev_mb> oh and I should definitely get my hands on the auth stuff.
17:10:24 <kzaitsev_mb> mfedosin: feel free to use #link ;)
17:10:34 <kzaitsev_mb> #link http://eavesdrop.openstack.org/meetings/glance/2016/glance.2016-05-26-14.03.log.html
17:10:55 <igormarnat_> kzaitsev_mb docaedo folks, I'm not in context here, sorry. Is there a plan in place for auth implementation?
17:10:58 <mfedosin> nikhil designated several items about Glare
17:11:20 <docaedo> igormarnat_: no exact plan, only that it's a known issue
17:11:42 <docaedo> igormarnat_: needs to auth people against their openstack ID, and let folks update their assets
17:11:44 <kzaitsev_mb> igormarnat_: the plan is to delegate auth to ubuntu one, the same way review.openstack.org does
17:11:45 <mfedosin> I think they should clarify some things
17:11:54 * nikhil lurks
17:12:02 <docaedo> igormarnat_: and the people listed as cores for app-catalog can change status of a recently added/updated app
17:12:47 <kzaitsev_mb> exactly
17:12:57 <igormarnat_> docaedo: ok, but I mean - it's some functionality which needs to be implemented, do we know who'll implement this part?
17:13:45 <docaedo> my understanding based on previous conversations is that mfedosin or someone else working on glare would take the lead on the auth middleware
17:13:56 <igormarnat_> ah, ok
17:14:24 <mfedosin> docaedo: correct
17:15:45 <kzaitsev_mb> cool =) I thought I would be the one to do the heavylifting =) Well anyways, I'll offer mfedosin my help on that =)
17:15:53 <docaedo> kzaitsev_mb: OK if I add an action for you like "execute plan to disable glare by default and start merging the pieces"?
17:16:07 <kzaitsev_mb> docaedo: please do =)
17:16:24 <docaedo> #action kzaitsev_mb to execute plan to disable glare by default and start merging those bits into app-catalog repo
17:16:53 <docaedo> Thanks for the glare update, I think we have a good picture on where it stands - moving on?
17:17:06 <igormarnat_> let's wait for a bit for comment from Mike
17:17:27 <igormarnat_> mfedosin: so please confirm you're ready to work on this auth middleware
17:18:02 <mfedosin> so, the idea is to implement another auth middleware and use instead of current keystone middleware
17:18:24 <mfedosin> I think they can already be written
17:18:49 <igormarnat_> ok, this is more or less clear. Not clear to me is who's gonna be doing it if it's not done. If it's done - where is the repository with the code? :)
17:18:59 * mfedosin is googling
17:19:29 <kraynevs> kzaitsev_mb: do I understand correctly, that you plan to implement some Glare integration before the official release of v1 API ? I'm just wondering about estimates, and when we can start using it?
17:21:25 <kzaitsev_mb> kraynevs: yes, if the v1 gets merged before we deploy glare — well, we would just be able to switch to using it, otherwise we would probably have to do some porting work
17:22:12 <kzaitsev_mb> kraynevs: but the a.o.o API based on glare would stay private until V1 is there
17:22:35 <kzaitsev_mb> and v1 a.o.o api wouldn't change anyway
17:23:00 <mfedosin> #link http://stackoverflow.com/questions/4648838/wsgi-middleware-for-oauth-authentication
17:23:20 <docaedo> I was just going to say that - v1 API for a.o.o will not be v1 API for glare, but we're not advertising app.openstack.org as the canonical glare example anyway
17:23:22 <kraynevs> kzaitsev_mb: ok
17:24:59 <igormarnat_> so this way or another kzaitsev_mb and mfedosin will figure it out with auth middleware
17:25:17 <kzaitsev_mb> igormarnat_: we'll do =)
17:25:36 <igormarnat_> great, let's proceed than:)
17:25:56 <docaedo> #topic App Dev Community Discussion (Igor)
17:26:22 <docaedo> #link https://etherpad.openstack.org/p/OpenStackAppsCommunity
17:26:39 <docaedo> and two email threads on the subject:
17:26:42 <docaedo> #link http://lists.openstack.org/pipermail/user-committee/2016-May/000854.html
17:26:44 <docaedo> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/095917.html
17:26:53 <igormarnat_> docaedo: thank you, Chris!
17:27:00 <docaedo> There's a LOT in this message, but I'm glad Igor kicked off this conversation
17:27:21 <docaedo> igormarnat_: what piece of this do you want to start discussing?
17:27:28 <igormarnat_> so what do you think about the plan? Do you want to discuss it in general in some more details or just to switch to the very first item from the plan?
17:27:33 <igormarnat_> I'd discuss about repositories
17:27:50 <igormarnat_> This part
17:28:01 <igormarnat_> - Introduce label openstack-apps, put repositories with source code of OpenStack Apps under it, i.e.:
17:28:01 <igormarnat_> * http://git.openstack.org/cgit/openstack-apps/murano-apps
17:28:01 <igormarnat_> * http://git.openstack.org/cgit/openstack-apps/heat-templates
17:28:01 <igormarnat_> * http://git.openstack.org/cgit/openstack-apps/tosca-workflows
17:28:26 <docaedo> I would say before repositories we need to work out what the testing would look like - otherwise there's not a lot of reason for the repositories to exist, or at least no reason to use those over your own github repo
17:28:38 <igormarnat_> there are people coming and asking how and where to put source code of their apps, besides Murano team would also like to split the repos
17:28:53 <docaedo> I'm +1 for Murano then, especially if people are already asking for it
17:29:11 <igormarnat_> Well, the testing depends on project. For murano we started working on CI for apps
17:29:23 <docaedo> I haven't seen anyone ask for it from Heat side - in fact I even suggested this over a year ago and basically heat team said "no way, we already have examples!"
17:29:40 <kzaitsev_mb> I'm +1 for the openstack-apps, but I'm not 100% sold on the single repository for all the murano-apps in the openstack
17:29:47 <igormarnat_> final goal is to have automated pipeline which allows to automatically publish apps to the catalog
17:30:04 <igormarnat_> but for now - just non-voting jobs based on third-party CI
17:30:12 <igormarnat_> So yeah, getting back to repositories
17:30:36 <igormarnat_> there are many apps in openstack/murano-apps which are now part of responsibility of core murano team
17:31:00 <docaedo> whos responsibility will they be in openstack-apps/murano-apps?
17:31:20 <igormarnat_> and we'd like to move existing murano-apps to somewhere else (ideally - under openstack-apps label) and to leave it up to murano team to deal with their examples, they'll figure it out
17:31:34 <igormarnat_> we are ready to introduce murano-apps team:)
17:31:39 <kzaitsev_mb> exactly this — it doesn't solve the problem of ownership
17:31:53 <igormarnat_> murano-apps is gonna be the owner
17:32:11 <docaedo> who will be the members for murano-apps?
17:32:40 <kzaitsev_mb> igormarnat_: my question is — how would it scale when you would have, say 100 apps in that repository?
17:32:44 <igormarnat_> for now several core members of murano team and several new folks from our team who works on CI/CD app for murano, gerrit app, jenkins, ...
17:33:19 <igormarnat_> kzaitsev_mb: the thing is that however it will scale, it will scale better than now when it's responsibility of murano team, right?
17:34:21 <kzaitsev_mb> igormarnat_: why not allow a repository per-app, to allow every app developer have their own team, speed, etc?
17:34:34 <kzaitsev_mb> We should just make it easy to register this kind of teams
17:34:59 <docaedo> I think it's good to be clear at this point what this represents - it's a new repository to host murano apps (i.e. the gating/CI/CD stuff is for later, and will be dealt with separately)
17:35:01 <igormarnat_> kzaitsev_mb: docaedo nothing prevent us just to copy all the murano team to murano-apps team for beginning and then membership will be polished/elaborated using usual openstack approach based on their activity
17:35:21 <docaedo> igormarnat_: I'm basically on board and in support of this plan
17:35:35 <docaedo> just want to be really specific as we step through this, and start getting to the more complicated things later
17:35:46 <docaedo> kzaitsev_mb: you make a good point about separate repos -
17:36:04 <igormarnat_> it's a new repository to host murano apps, right. Owner can be newly created murano-apps team, who'll consist from the very beginning from exact copy of murano team + several new members
17:36:09 <docaedo> kzaitsev_mb: if I create an app, I'd prefer it to live in my own github repo where users can report issues, see updates, etc.
17:36:41 <kzaitsev_mb> agree with the github example
17:36:46 <igormarnat_> kzaitsev_mb: docaedo ah, yes, this is what I meant, sorry, folks
17:37:32 <docaedo> igormarnat_: no need to apologize :) I'm just also anticipating the parts we'll have to be really clear about with the repo request, etc., expecting some similar questions
17:37:34 <igormarnat_> kzaitsev_mb: docaedo well, probably I'm confused now, yep. From one side it's good to have murano-apps team who owns several repositories they work on
17:38:02 <igormarnat_> docaedo: kzaitsev_mb on the other hand repo per app is good thing to have, some apps are very complicated
17:38:03 <kzaitsev_mb> I understand that it is currently super-hard to add a new repo to openstack-space, and a single repo for all the murano-apps is a workaround
17:38:16 <docaedo> BTW maybe Murano team should think about this again?
17:38:19 <docaedo> #link https://blueprints.launchpad.net/murano/+spec/download-package-from-git
17:38:55 <kzaitsev_mb> but let's at least take a look at the root problem and see if we can fix that (i.e. allow adding new repositories in a click or two)?
17:39:31 * olaph likes the git idea
17:39:38 <igormarnat_> docaedo: kzaitsev_mb I think I now understand it. We might want to copy all the existing repositories under label openstack-apps/murano-apps which is just the label, assign newly created murano-apps team as an owner for each of them (as they are owned by murano team anyways)
17:39:40 <docaedo> kzaitsev_mb: I don't think that adding dozens or hundreds of new repos is a thing the infra team wants to own
17:39:52 <kraynevs> docaedo: I suppose, that have one core team - murano-apps make sense on the start, because we need to give users normal review from guys with expertise in this area
17:40:07 <kraynevs> and this group may have right for +2 on all repos
17:40:12 <kraynevs> but then..
17:40:12 <igormarnat_> And then to add new repositories under openstack-apps/murano-apps on per project basis and discuss each time which team owns new repo
17:40:15 <kzaitsev_mb> kraynevs: good point
17:40:32 <kraynevs> you are right it should be separate teams with same rules like in main Openstack community
17:40:43 <kraynevs> when we nominate new guys to core-team
17:40:47 <kzaitsev_mb> docaedo: I think the git thing could be done on the client-side more or less easily =)
17:40:50 <docaedo> I'm not so much in support of endless repositories, most of which will eventually be abandoned...
17:40:54 <kraynevs> but on the start we need support new comers
17:41:10 <docaedo> but that is an important question we'd need to get support from the infra team and/or TC
17:41:36 <docaedo> ("that" being "as many repos as anyone wants, so every app gets its own repo")
17:42:08 <kzaitsev_mb> docaedo: well, github/bitbucket are more or less ok with hundreds of abandoned repositories, but those are commercial projects after all
17:42:16 <kraynevs> docaedo: excuse me, but what do you meant by "supporting endless repositories"?
17:42:44 <igormarnat_> nothing prevent people from using their repositories if they want, but if they'll create them under openstack-apps/murano-apps, they'll be part of some community. They'll get support from it but in return they should contribute back by reviewing and writing code. Again, if someone want to create his repo outside - it's ok, but he'll not be reviewed than
17:42:44 <kraynevs> I suppose, that in community nobody except core-team do not support repo.....
17:43:06 <kraynevs> docaedo: I just try to understand what kind of supporting do you mean
17:43:29 <kzaitsev_mb> I think I'm ok with agreeing to have single repo as step1, but we should probably get infra folks involved, they might have some insight
17:43:36 <docaedo> kraynevs: I mean that every new repository comes with some administrative cost from the openstack-infra team
17:44:00 <docaedo> kraynevs: and this proposal is "1 repo for now, many many repos later - as many repos as we have devs or apps"
17:44:01 <igormarnat_> kzaitsev_mb: docaedo why not to suggest single repo/single team for beginning
17:44:18 <igormarnat_> and then we'll figure it out with infra team as well
17:44:25 <kzaitsev_mb> docaedo: kraynevs: exactly, after all they "own" the metadata about the repos
17:44:34 <docaedo> igormarnat_: I'm fine with one repo, but if the longer term intention is more repos under that, we need to be clear at the beginning that that's the long term expectation
17:45:46 <igormarnat_> so, guys, are you ok with requesting tc/infra team to move existing openstack/murano-apps to openstack-apps/murano-apps, create new team murano-apps and assign it as an owner of this repo?
17:46:03 <docaedo> I'm +1 on that
17:46:24 <igormarnat_> long term approach is to be discussed further with Infra team, tc and openstack-dev community (if anyone is interested:) )
17:46:33 <kzaitsev_mb> igormarnat_: I'm not ok with moving all the apps there
17:46:47 <igormarnat_> kzaitsev_mb: do your corrections than
17:47:00 <clarkb> fwiw I think we don't want any new "namespaces" on the gerrit server
17:47:07 <kzaitsev_mb> igormarnat_: I'd rather have murano-apps renamed into murano-examples and transfer apps on per-app basis
17:47:18 <clarkb> if it were easier to remove openstack-dev it would be gone already
17:47:19 <kzaitsev_mb> i.e. there is a number of apps, that have little value really
17:47:36 <kraynevs> docaedo: oh. you talk about supporting it as it do infra team... yeah. it's pain.
17:47:56 <igormarnat_> kzaitsev_mb: I don't see much difference in move all the murano-apps first and then to recreate murano-examples in Murano by Murano team, but ... I don't have strong opinion here
17:48:49 <igormarnat_> clarkb: but it would be good to separate code which constitutes core openstack services from the code which is not openstack code but is openstack applications, isn't it?
17:49:11 <docaedo> kraynevs: correct - that's what I'm sensitive to, our infra team is small and overworked :)
17:49:12 <clarkb> no, that namespacing has no real purpose
17:49:15 <igormarnat_> clarkb: labels openstack and openstack-apps would allow to do it, but other ideas are welcome
17:49:29 <clarkb> it only causes confusion and special casing in tooling and so on
17:50:26 <igormarnat_> well, than we just can move murano-apps outside of murano, w/o introducing openstack-apps label, as an option. Key thing for me is to move it outside of responsibility of core murano team
17:51:32 <docaedo> it sounds like kzaitsev_mb is not entirely in support of moving all the apps out though?
17:51:42 <kzaitsev_mb> igormarnat_: well, I'm ok with moving apps (and thus shifting some of the responsibility from myself and the team =)), just want to be a bit carefull here. you might be right and just moving all the apps is ok
17:51:47 <igormarnat_> Here is the suggestion then: move murano-apps outside of murano, make it top-level repository, assign newly created murano-apps team an owner, ask murano team to figure out exact way they want to transfer source code from murano/murano-apps to murano-apps outside of it. Would they work?
17:52:18 <docaedo> also sounds like we're talking about two things at the same time - 1) getting apps out of the main murano repo and 2) making a space where new murano app developers can work on stuff ..
17:52:20 <kzaitsev_mb> docaedo: I just have to give it a bit of thought =) We've been wanting to clean-up some of the example apps, that have little value
17:52:21 <igormarnat_> kzaitsev_mb: docaedo clarkb ?
17:53:11 <docaedo> igormarnat_: I would support that if it's got buy in from murano - but in this case, really has nothing to do with me since I'm not a murano core or anything
17:54:05 <igormarnat_> docaedo: we can agree on it between ourselves as initial suggestion and then get agreement with infra team and murano team by email
17:54:47 <docaedo> igormarnat_: sure - from the "clean place to work on murano apps" perspective, it makes sense to me
17:55:39 <igormarnat_> Ok, let's agree on this suggestion, I can shoot an email with it to infra team and murano afterwards
17:56:12 <docaedo> #action igormarnat_ to send an email to infra and murano teams re: moving apps in murano repo to new top level repo
17:56:16 <docaedo> now it's official!
17:56:27 <igormarnat_> docaedo: thank you, sir! :)
17:57:30 <igormarnat_> docaedo: we are running out of time, let's make the first step with murano apps
17:57:32 <docaedo> and we're almost out of time - but thanks igormarnat_ for bringing this up, and looking forward to carrying this conversation forward in the weeks to come
17:57:37 <docaedo> hah yes
17:57:46 <igormarnat_> docaedo: and meanwhile hopefully heat team and other teams will say something in email
17:58:08 <igormarnat_> thanks all!
17:58:12 <docaedo> that would be nice - we can talk some next week (or else on #openstack-app-catalog) about what we would need for testing
17:58:31 <docaedo> because it basically needs a stable cloud without access to admin control plane, to test any of these things
17:58:48 <docaedo> or else SLOW path, stand up all in one devstack node for the test
17:59:07 <docaedo> I am out next week, but will work through agenda and stuff on the mailing list
17:59:09 <docaedo> thanks everyone!
17:59:20 <docaedo> #endmeeting