17:00:54 <docaedo> #startmeeting app-catalog
17:00:56 <openstack> Meeting started Thu Aug 25 17:00:54 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:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:59 <openstack> The meeting name has been set to 'app_catalog'
17:01:09 <docaedo> #link https://wiki.openstack.org/wiki/Meetings/app-catalog#Proposed_Agenda_for_August_25th.2C_2016_.281700_UTC.29
17:01:41 <docaedo> That's the agenda, but really I think today is all about glare (and that's what things will be all about likely until we transition :) )
17:02:06 <redixin> hi all
17:02:15 <docaedo> hello redixin!
17:02:56 <redixin> as you may know, glare has disconnected from glance. we have new repository git://git.openstack.org/openstack/glare.git
17:03:22 <redixin> I've switched http://r-ci.tk:8100/ to new glare
17:03:38 <docaedo> oh great, thanks for that update
17:03:39 <redixin> also I've finished UI
17:04:01 <redixin> and now working on "old api emulation" (for horizon plugin)
17:04:19 <redixin> http://r-ci.tk:8100/api/v1/assets
17:04:26 <docaedo> redixin: excellent - it's looking really good
17:04:27 <redixin> it almost done
17:05:00 <redixin> if you want to test admin UI, you need to be member of app-catalog-core team on launchpad
17:05:20 <redixin> this team is open, so you may join or leave this team at any time
17:05:52 <kzaitsev_mb> o/
17:05:57 <redixin> hiyo
17:06:00 <IgorYozhikov> o/
17:06:09 <kzaitsev_mb> on other meeting right now, would get back soon I guess
17:06:13 <docaedo> redixin: cool - is that a different launchpad group than current app catalog core?
17:06:43 <redixin> current app catalog core? O_O
17:07:02 <redixin> I've created team 'app-catalog-core' like one week ago
17:07:13 <docaedo> sorry, I confused it with app catalog drivers group
17:07:14 <redixin> I dont know other teams
17:07:20 <redixin> oh, ok
17:07:57 <docaedo> #link https://launchpad.net/~app-catalog-core
17:08:08 <redixin> also few people from mirantis are helping us with packages/puppets
17:08:31 <docaedo> yep, I've been talking to zynzel this last week and saw some of the work he's done
17:08:37 <redixin> but I dont know much about their progress
17:08:50 <docaedo> one quick question before we move on to that
17:09:08 <zynzel> not only me :) im assigned for app-catalog automation, also we have Pether Zhurba - he will deliver glare automation
17:09:19 <docaedo> redixin: is there a URL for an admin interface for people to approve/disable assets?
17:09:36 <docaedo> great to have so many resources working on this :)
17:09:54 <redixin> docaedo: admin UI is part of user UI. you will see some additional buttons if you are member of app-catalog-core team
17:10:21 <docaedo> redixin: awesome, yep I see now after logging out and back in
17:11:33 <docaedo> as an admin, I should be able to edit any artifact, but I don't see a button for that?
17:11:55 <redixin> not you are not. only owner can edit own artifact
17:12:21 <igormarnat_> I also think so, why would you edit assets uploaded by others?
17:12:35 <redixin> because you admin? =)
17:12:59 <igormarnat_> Need to have an approach similar to code review - you can comment, but it's up to patch owner to edit
17:13:28 <docaedo> sure, but that's not the same as what we have right now
17:13:34 <docaedo> cores can modify any asset and merge it
17:14:08 <docaedo> ie to fix something that has been abandoned by an owner (like someone adds something useful, but does not respond to comments to fix typos or a broken link)
17:14:35 <redixin> It would be nice if admin can edit any asset. This sounds reasonable. I can fix it.
17:14:37 <docaedo> from the earlier design conversations, there was an agreement that core members of app catalog would have full admin rights to edit/modify anything in the catalog
17:14:45 <igormarnat_> Probably this needs to be discussed as a new upload workflow
17:15:38 <docaedo> possibly - at a minimum core members need to be able to disable any asset
17:15:57 <igormarnat_> docaedo: May be it's appropriate for the first stage to allow to switch to new backend asap, but for the future IMO we need to separate development team of app catalog and their rights and team managing the content of app catalog and their rights
17:16:13 <docaedo> also we should think about how to prevent this from being overrun by a spambot, like what has happened to the wiki
17:17:11 <redixin> captcha?
17:17:12 <docaedo> igormarnat_: well I am not sure the app catalog project is big enough to be split into two project groups is it?
17:17:35 <docaedo> redixin: yep, I was just going to type captcha might be all we need for now, and we can address if it becomes a problem
17:17:45 <igormarnat_> docaedo: redixin actually having thought about it again I don't understand at all - why would admin edit any asset? What for?
17:18:17 <docaedo> I've fixed assets that people have added, when a link changes or breaks
17:18:40 <igormarnat_> docaedo: what if you make a mistake and break something?
17:18:41 <docaedo> if nobody can update anything except the original asset owner, everything will eventually get staile
17:18:43 <docaedo> stale
17:19:01 <docaedo> igormarnat_: if I break something from a mistake, the owner or another admin can fix it
17:19:15 <igormarnat_> at least this should be very visible and transparent
17:19:16 <redixin> You actually cannot fix any blobs (including links to external resources) because of glare. You need to create new asset (new version) with new blob
17:19:27 <redixin> blobs are immutable
17:19:50 <docaedo> igormarnat_: I completely agree it shoudl be transparent and clear who is doing what, but I'm also saying if only the owner can ever manage his/her own assets, many assets will be stale
17:19:51 <zynzel> maybe instead of modyfing smth silently, we should own 'abbandoned' apps
17:19:59 <igormarnat_> Yep, new version or something like that.Assets are versioned, operations are to be logged, right?
17:20:01 <zynzel> change owner from 'user A' to 'openstack infra' or smth.
17:20:14 <docaedo> much of the content has been added by people who no longer pay attention to it (like debian stuff, coreos stuff), sometimes it gets updated
17:21:07 <redixin> Abandoned assets, or new versions of old asset are just completely new assets. Same name but other version. So there is no need to edit. Just create a copy
17:21:08 <igormarnat_> Again, this is probably ok but needs to be very transparent, versioned, logged
17:21:21 <docaedo> +1
17:21:49 <docaedo> I hoped we would be able to see previous versions of an asset, since everythign is versioned anyway - couldn't that be in a dropdown or something, to see previous versions of an asset?
17:22:34 <redixin> older versions are available via glare, but not implemented in UI
17:22:40 <redixin> so i'll add it to my TODO list
17:23:00 <igormarnat_> Good
17:23:40 <docaedo> sounds good :) to be clear I am not trying to asset editorial control over the catalog, but I do want to make sure the core of us (that's all of us who are working on this) can take care of it and keep things in shape
17:24:17 <docaedo> redixin: one thing, for "recently added apps", do you have a way to easily pull the 15 most recently modified assets, and then randomly choosing 5?
17:24:22 <redixin> we need a "copy" button to add new versions or continue abandoned assets
17:24:33 <docaedo> that sounds good
17:25:01 <redixin> docaedo: its hard to do with glare. probably searchlight can help
17:25:26 <kzaitsev_mb> redixin: maybe you can fetch 5 latest things from each of the asset types?
17:25:27 <docaedo> redixin: oh right, I remember that conversation :/
17:25:52 <docaedo> kzaitsev_mb: that sounds like an easy approach, but to be honest, we can skip that and remove it for the time being
17:26:00 <kzaitsev_mb> and then mix and shape =) it's not like we need a cryptographically strong shuffle algorithm for those )
17:26:04 <docaedo> I don't think it's essential, and I would say that's a nice to have, but not a show stopper
17:26:27 <kzaitsev_mb> true, definitelly not a show stopper
17:26:32 <docaedo> kzaitsev_mb: yep -- if it's not too much work, great, but at least for me, I will not cry if that gets put on hold until searchlight is part of the picture
17:29:43 * redixin is removing "admin can edit any asset" and adding "copy button for UI" in TODO
17:29:49 <docaedo> so zynzel - want to talk about packages and stuff?
17:30:17 <zynzel> yep, sure
17:30:26 <zynzel> so guys, im working on automation for app-catalog
17:30:27 <redixin> we have a package contrib/glare in app-catalog
17:30:33 <igormarnat_> packaging and automation of deployment is the last thing preventing us from switching to new backend, right?
17:30:42 <zynzel> i prepared short etherpad, with things which should (imho) be fixed
17:30:49 <zynzel> before we can create good quality automation
17:30:52 <zynzel> #link https://etherpad.openstack.org/p/app-catalog_automation
17:31:11 <zynzel> here is change [wip] for that
17:31:13 <zynzel> #link https://review.openstack.org/#/c/359029/
17:31:58 <zynzel> so, long story short, we need packages for app-catalog, and we need cli wrapper over manage.py and all other tasks which should be executed after app-catalog deployment
17:33:56 <docaedo> I mostly agree, though the package does not have to be perfect for the transition - i.e. if there is a manual step infra has to perform on the box, that's OK
17:34:35 <docaedo> just talking about the things that happen only one time - like importing assets.yaml into glare
17:35:00 <zynzel> docaedo: and what happend when you break glare?
17:35:13 <redixin> it can be imported manually
17:35:13 <zynzel> we will need to reinstall glare from scratch+import assets one more time
17:35:20 <zynzel> so this can be easly added to this cli wrapper :)
17:35:43 <redixin> assets.yaml will be outdated just after switch to glare
17:35:44 <zynzel> redixin: everything can be done manually...
17:35:49 <zynzel> but we want to have automation
17:36:18 <docaedo> also remember the puppet manifest is run every 15 minutes, so have to make sure it's smart enough to only do the import when we want
17:36:38 <zynzel> docaedo: yep sure, this is why we need packages and other 'good puppet stuff'
17:36:46 <docaedo> that's the part that I think will be difficult, distinguishing between initial deployment, fix deployment, and regular run
17:36:47 <zynzel> manifests should be indepotent
17:37:11 <zynzel> docaedo: we have some experience with creating manifests which can be run multiple times without any issue
17:37:24 <redixin> guys, we can run import only once. after this any changes will not be saved in assets.yaml
17:37:25 <zynzel> imho this should be doable for app-catalog
17:37:41 <redixin> so assets.yaml will be outdated immediately
17:37:59 <zynzel> redixin: so maybe glare should allow to generate assets.yaml
17:38:03 <docaedo> yep, once we implement glare, assets.yaml (after import) becomes meaningless
17:38:03 <zynzel> from current data?
17:38:07 <zynzel> for some kind of backup?
17:38:42 <zynzel> (im not glare guy, i dont know how difficult this can be)
17:39:05 <redixin> we can just backup database (postgres?)
17:39:28 <docaedo> database will be hosted, it won't live on this machine (will be delivered via trove)
17:39:32 <redixin> currently glare have not any export/import or backup/restore things
17:40:19 <redixin> also assets.yaml may be not quite compatible with glare
17:40:34 <zynzel> understood, but do you think that glare should allow to export/import content via api?
17:40:53 <igormarnat_> It's an overkill to generate assets.yaml for backup purposes or any other purposes (provided that assets.yaml is current app catalog backend which I'm not sure in)
17:40:54 <redixin> We will discuss this with glare team tomorrow
17:41:00 <docaedo> also in looking at 359029, will need config file templates and a way to handle that - for instance access to mysql and swift will require secrets, those will be stored in heira by infra team (similar to how SSL cert is handled now)
17:41:01 <zynzel> it easier for anybody to use API calls, than dumping/importing database data :)
17:41:07 <zynzel> with encoding and stuff :)
17:41:45 <zynzel> docaedo: we can pass all credentials to app_site class as parameters
17:41:49 <redixin> btw binary data is not stored in database
17:41:53 <zynzel> and read them from hiera from examples/instal.pp
17:42:08 <docaedo> zynzel: cool just making sure you had that in mind
17:44:47 <zynzel> so anybody have anything against packages+appcatalog-manage?
17:45:04 <redixin> btw this should be deb packages? or just pypi?
17:45:18 <zynzel> redixin: any package, i can use pip or deb
17:45:34 <docaedo> I don't have anything against package plus manage
17:45:48 <kzaitsev_mb> well, I have a faint objection against pypi =)
17:45:57 <kzaitsev_mb> but am 100% for deb
17:46:02 <docaedo> and I like pypi more than debs :P
17:46:08 * redixin added "app-catalog manage" in TODO
17:46:13 <docaedo> thing is pypi is more transparent
17:46:34 <docaedo> deb packaging is not at all easy to see the background, where it came from, etc.
17:46:58 <kzaitsev_mb> docaedo: but why don't we have up to date nova on pypi? =)
17:46:59 <docaedo> also pypi is easier to pin to a version than a deb pulled from an external repo
17:47:19 <docaedo> haha don't try to drag nova into this conversation!
17:47:21 <kzaitsev_mb> (spoiler: I don't know the answer)
17:47:36 <kzaitsev_mb> yeah, like I said my objection is rather faint
17:47:45 <docaedo> actually to be fair
17:48:00 <docaedo> the best thing for us to do would be to use the packaging tooling offered by infra
17:48:02 <redixin> is it possible to publish two packages from one repository via openstack/infra?
17:48:16 <kzaitsev_mb> I just gotta ping infra — why none of the services like glance/nova has pypi jobs/packages
17:48:21 <docaedo> but I don't fully understand how to use it so I can't advocate too strongly
17:48:29 <zynzel> redixin: dunno, you are thinnking about contrib/glare?
17:48:37 <redixin> yep
17:48:58 <zynzel> redixin: if not, we can move contrib/glare to openstack-catalog/plugins/glare
17:49:01 <kzaitsev_mb> there's got to be some explanation, rationale. just gotta ping the right folks to dig that up
17:49:03 <zynzel> and deliver this inside single package
17:49:14 <zynzel> on glare node simply, we will not configure app-catalog
17:49:22 <kzaitsev_mb> redixin: you can, but not with current infra thing I suppose
17:49:23 <zynzel> only install this plugin for glare
17:49:25 <kzaitsev_mb> also tags
17:50:15 <redixin> sounds good (openstack_catalog.plugins.glare)
17:50:48 <kzaitsev_mb> well, you need a setup.cfg file for a package (if we're talking about pypi, deb/rpm are a completely different story)
17:51:07 <kzaitsev_mb> and if you follow post-versioning strategy of pbr — they would share version of the latest tag
17:51:31 <kzaitsev_mb> anyway — wasn't there a plan to get a separate repo for glare-plugins?
17:53:04 <kzaitsev_mb> we've hit that thing in murano with murano-glare-plugin. it's usually very hard to explain to packaging folks why they have tp build 2 packages from 1 repo. much cheaper to convince infra to make a new repo =)
17:53:17 <redixin> I like openstack-catalog/plugins/glare more
17:54:10 <redixin> pip install openstack_catalog but use only openstack_catalog.plugins.glare.(middlewares|artifacts|etc)
17:54:56 <zynzel> same as in the rest of openstack python-nova|neutron|glance
17:56:23 <docaedo> oh we are almost out of time (just looked at the clock)
17:57:48 * redixin added "merge contrib/glare into oenstack_catalog" in TODO
17:58:09 <docaedo> that makes sense to me ..
17:59:12 <docaedo> ok any other urgent topics before we end?
17:59:22 <redixin> btw how about assign glare-work blueprint to me? %)
17:59:40 <docaedo> redixin: sure, I can do that
17:59:48 <redixin> thanks
17:59:59 <docaedo> np
18:00:09 <docaedo> and we're out of time - thanks folks!
18:00:13 <docaedo> #endmeeting