17:00:14 <docaedo> #startmeeting app-catalog
17:00:19 <openstack> Meeting started Thu Jul  7 17:00:14 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:22 <openstack> The meeting name has been set to 'app_catalog'
17:00:28 <docaedo> courtesy ping: kzaitsev_mb mfedosin olaph sskripnick1 igormarnat_ ddovbii__
17:01:09 <docaedo> I figure we should have a *few* people today considering all the work that's been going on during the last week :)
17:01:56 <kzaitsev_mb> o/
17:01:59 <mfedosin> o/
17:02:07 <sskripnick1> ршнщ
17:02:11 <sskripnick1> hiyo =)
17:02:38 <docaedo> Hello!  Looks like we have enough folks today
17:02:43 <docaedo> #topic Status updates
17:03:02 <docaedo> I'll give a quick one
17:03:12 <docaedo> I had an action item to talk to infra about swift
17:03:49 <docaedo> It will not be a problem, they will manually create the swift bucket (or whatever the proper term is) and the access secrets will be kept in hiera
17:04:23 <docaedo> the puppet manifest to deploy glare on the app catalog server will have a spot for auth in the config template and puppet will make it all work right
17:04:40 <docaedo> same goes for DB via trove, so we'll get access credentials and it'll just be plugged into the template
17:05:20 <docaedo> OK that's it for my updates, kzaitsev_mb do you want to go next?
17:06:03 <kzaitsev_mb> I don't have much apart from the letter I've written yesterday on the layout of dahsboards
17:06:27 <kzaitsev_mb> #link http://lists.openstack.org/pipermail/openstack-dev/2016-July/098907.html
17:06:32 <docaedo> saw that letter, looked really good - I'll respond today as well to hopefully keep some attention on it
17:06:46 <kzaitsev_mb> #link https://etherpad.openstack.org/p/apps-dashboard-structure
17:07:01 <kzaitsev_mb> I'm planning to continue working on the patches, to make them green
17:07:07 <docaedo> excellent
17:07:27 <kzaitsev_mb> meanwhile we can start throwing some ideas about the layout
17:08:02 <kzaitsev_mb> planning to do so myself too =)
17:08:33 <kzaitsev_mb> I still have an AI to go ask around the infra team about possibility to reuse gerrit groups though
17:08:58 <docaedo> yep, that could have an impact on sskripnick1 work (which is also the next topic)
17:09:30 <sskripnick1> I started working on glare 1.0 api #link https://review.openstack.org/#/c/337633/
17:09:41 <docaedo> #topic Glare 0.1 API status (sskripnick)
17:09:50 <docaedo> all yours sskripnick1
17:10:15 <sskripnick1> And I'd like to ask about experimental 0.1 glare API
17:10:28 <mfedosin> sskripnick1: shoot
17:11:10 <sskripnick1> mfedosin: what do you mean? =)
17:11:35 <sskripnick1> so are we going to merge it? or we about to wait for 1.0?
17:11:43 <mfedosin> sskripnick1: it means "go ahead"
17:11:56 <sskripnick1> mfedosin: oh, ok)
17:12:20 <sskripnick1> I mean we can skip glare 0.1 at all
17:12:24 <mfedosin> one unpleasant thing I want to mention after today glance community meeting...
17:12:51 <mfedosin> glance ptl wants to postpone code merging
17:13:04 <mfedosin> because he has no time for review
17:13:34 <docaedo> that's unfortunate, but not a huge deal I think for us
17:13:51 <sskripnick1> does it mean that we should finish 0.1?
17:13:53 <mfedosin> I think there are 2 possibilities
17:14:16 <mfedosin> to take unmerged code
17:14:26 <mfedosin> and use it in app-catalog
17:14:41 <mfedosin> now it's pretty stable and code coverage is good
17:15:13 <mfedosin> or wait till it's merged, but I can't predict now when it happens
17:15:28 <mfedosin> also we can discuss moving glare to separate project
17:16:25 <sskripnick1> so we have 3 options: use 1.0 right now, finish 0.1, or do nothing =)
17:16:38 <docaedo> I think for our purposes, we can start my putting the glare code right in app-catalog as long as it's sitting in a way that will be easy to replace with upstream repo at a later date
17:16:41 <mfedosin> I choose first
17:17:25 <docaedo> we would have to have a ML conversation to get consensus on that decision
17:17:28 <mfedosin> docaedo: do you want to merge the whole glare's code in app-catalog?
17:18:12 <docaedo> mfedosin: I am just thinking about it :)  Maybe it'd be better to have a new repo to hold a fork of glance just for the glare stuff
17:18:30 <docaedo> mfedosin: then when glare is merged, we only have to chance the origin
17:19:21 <mfedosin> docaedo: frankly speaking it's the best suggestion
17:19:22 <docaedo> mfedosin: best idea though is to start a mailing list thread about this, and I would say (considering the history of glare resistance we sometimes see) we make it clear that we're talking about a fork just for the purposes of running it for the app catalog
17:19:34 <docaedo> mfedosin: I agree too
17:19:56 <sskripnick1> I like it more then working on 0.1 and then migrating to 1.0
17:20:06 <mfedosin> sskripnick1: ++
17:20:10 <sskripnick1> we need to implement 1.0 anyways
17:20:17 <kzaitsev_mb> sskripnick1: sounds fair =)
17:20:42 <mfedosin> and in this case we don't need to think about migrations
17:21:53 <sskripnick1> ok. so I will be working on 1.0
17:21:53 <docaedo> my only question is how to do this in a way that keeps all the work and reviews in glance, but gives us a stable commit to point at for the app-catalog deployment?
17:23:00 <sskripnick1> just keep glare 1.0 patches on review, and "backport" changes to fork
17:23:59 <mfedosin> sskripnick1: correct
17:24:14 <mfedosin> and we'll be able to use glance ci
17:24:15 * olaph forgot to wave
17:24:22 <docaedo> ok that makes sense - I also have an expectation that we only backport critical/security changes
17:25:04 <docaedo> the way the app-catalog server works right now is that it watches the app-catalog repo for changes, and if/when it finds something new in the repo it's checked out and immediately live
17:25:11 <mfedosin> seems so, v1 api won't change anyway
17:25:43 <docaedo> It would be best to follow that same continuous delivery approach for the glare work, just means we have to be thoughtful about anything that impacts existing data, etc.
17:26:02 <docaedo> but if we can do that, we'll be able to keep it up to date without having to schedule downtime or service interruptions with the infra team
17:28:40 <mfedosin> do we have some time on testing app-catalog+glare v1?
17:29:00 <sskripnick1> we need some time to implement it first =)
17:29:13 <docaedo> mfedosin: do you mean will with have time to test? We can set our own schedule so we can do lots of testing
17:29:17 <mfedosin> for example a week, when we'll test it and everything
17:29:43 <docaedo> mfedosin: yeah I think we'll have to do this in two phases
17:30:20 <docaedo> I would suggest phase 1) we test on a VM that is prepared to act like an infra node managed by puppet, but the puppet runs are triggered by cron to happen locally every 15 minutes
17:30:34 <docaedo> That would copy the way things work when managed by infra's puppet-master
17:30:51 <docaedo> and would be happening in a VM that we can get into to fix things/reset things when they break
17:31:20 <docaedo> when we are comfortable with that, we can request phase 2 - infra setting up a testing VM (test.apps.openstack.org or something)
17:31:32 <sskripnick1> Actual infra resources may be used. Like staging.apps.openstack.org
17:31:42 <docaedo> and we validate that works properly for a week or however long before switching DNS
17:32:01 <docaedo> sskripnick1: yes that's true, but the problem is when something goes wrong with that, we can't SSH into it to look at what went wrong
17:32:31 <docaedo> sskripnick1: if you guys are confident it'll be solid and not require much trouble-shooting or debugging, we can jump right to asking infra to set up a staging instance for us
17:34:01 <sskripnick1> docaedo: setting own vm is good,but im not sure how much time we need to this
17:34:46 <mfedosin> docaedo: vm is good
17:34:49 <sskripnick1> docaedo: I hope it will not take much time
17:35:28 <mfedosin> sskripnick1: we'll work together to make it done asap
17:35:41 <mfedosin> afaik v0.1 code is almost done
17:35:45 <docaedo> sskripnick1: I have a feeling we will need some more work once there's a full instance running - like making sure previous asset owners can still modify their entries (if possible)
17:35:58 <mfedosin> so we just need rewrite it to v1
17:36:16 <docaedo> and the admin interface for app-catalog cores to be the only ones who can enable assets (but maybe that's done and I missed it?)
17:37:00 <sskripnick1> docaedo: it is done, I can launch a demo instance
17:37:00 <kzaitsev_mb> docaedo the auth part has that partially
17:37:24 <kzaitsev_mb> we have some UI things, but those would need some refining I guess
17:37:40 <docaedo> kzaitsev_mb: the partially part has to do with where the group information comes from right? (i.e.launchpad or gerrit)
17:37:54 <kzaitsev_mb> sskripnick1: I think docaedo was asking for the UI available for some group of users )
17:37:54 <sskripnick1> launchpad
17:38:33 <docaedo> right that's the part :)
17:38:34 <sskripnick1> kzaitsev_mb: "drafts list" available only for admin groups
17:38:54 <kzaitsev_mb> sskripnick1: the UI you mean?
17:38:58 <sskripnick1> yes
17:39:10 <kzaitsev_mb> ok, I might have missed that commit then )
17:39:25 <mfedosin> what's "drafts list"?
17:39:35 <mfedosin> a list of queued artifacts?
17:39:36 <sskripnick1> there is a tab like "drafted assets"
17:39:53 <sskripnick1> this tab isn't available to non admin user
17:40:33 <mfedosin> asset is an artifact type in terms of glare, right?
17:41:07 <sskripnick1> asset is artifact, not type
17:41:23 <mfedosin> ah, okay
17:41:40 <sskripnick1> https://review.openstack.org/#/c/332911/8/openstack_catalog/templates/index.html
17:41:44 <sskripnick1> display:none
17:42:03 <sskripnick1> it becomes display:block if user is member of admin group
17:42:09 <mfedosin> docaedo: btw, Igor Marnat told me that app-catalog needs data validation and conversion
17:42:41 <mfedosin> for example, if user upload some Heat template, glare should check if this template is valid
17:42:53 <mfedosin> the same story for images
17:43:02 <docaedo> mfedosin: oh that would be nice but that is definitely not a requirement for switching to glare
17:43:09 <kzaitsev_mb> I see =) cool. We would probably give it a round of UI testing. Like see how well does it go from uploading a draft, to editing, to approving. To see if we missed anything in the UI flow
17:43:10 <sskripnick1> mfedosin: so this should be done at app-catalog level? no validation done by glare itself?
17:43:13 <docaedo> that's a slightly different longer term plan
17:43:48 <sskripnick1> kzaitsev_mb: about editing: it seems it not done at all...
17:43:53 <docaedo> mfedosin sskripnick1 that's a thread he started around the last summit time, to consider how the app catalog could help with a sort of CI check for assets
17:44:10 <mfedosin> sskripnick1: it will be done in glare - now glare supports this functionality on artifact type level
17:44:21 <kzaitsev_mb> sskripnick1: the very last commit in the queue attemted at that
17:44:30 <kzaitsev_mb> s/last/top/
17:45:18 <mfedosin> docaedo: so, if data validation is required we can add it easily
17:45:51 <docaedo> mfedosin: ok good to hear, I think that's something that will need more conversation before implementation
17:46:16 <docaedo> but definitely if it's really easy for glare to validate whether or not a heat template is syntactically correct, that's great
17:46:17 <mfedosin> docaedo: agree, just wanted to clarify it :)
17:46:47 <docaedo> how would it validate a glance image though? It's pretty easy to make an image that works on some hypervisor architecture but does not boot on others
17:47:00 <docaedo> s/glance/machine image/
17:47:21 <sskripnick1> same question
17:47:49 <mfedosin> I think there are some validators for this
17:48:16 <kzaitsev_mb> going to run now, really happy to see new faces from the glare helping us with the, well glare stuff =)
17:48:51 <sskripnick1> have fun)
17:48:57 <docaedo> kzaitsev_mb: sounds good, thanks for the updates
17:49:13 <sskripnick1> we can check if image is valid qcow2 or iso etc
17:49:22 <docaedo> ah that makes sense
17:49:32 <sskripnick1> but we need to actually boot in on hypervisor if we want to be sure
17:49:40 <mfedosin> and convert them to required format if it's needed
17:49:58 <docaedo> oh that I would object to
17:50:26 <docaedo> unless the user has an option - because the user sharing should be able to compare/validate the hash
17:51:07 <docaedo> and if the app catalog does things to the images after a user submits, it's impossible for the user to know whether or not someone elses SSH key was injected, etc.
17:51:16 <docaedo> but not somethign we have to debate today :)
17:51:31 <docaedo> I think I have an action here, just let me verify with you guys first-
17:51:44 <mfedosin> we can start with heat template first
17:52:13 <docaedo> should I request a new repository as a clone of glare?
17:52:23 <docaedo> actually now that I type this out, I realize I have a better action item
17:53:02 <docaedo> #action Aedo to discuss with infra best way forward for us to carry a fork of glare or else deploy with a squashed patch chain from glance repo
17:53:25 <docaedo> I've had some conversation with other people around this kind of stuff (olaph you know what I'm saying)
17:54:00 <docaedo> and it might be possible for us to specify a chain of reviews we want to carry, and use them together - without having to fork glance and backport stuff
17:54:27 <docaedo> I even think we might be able to manage that list of reviews/commits in a single file in app-catalog which we could review and maintain that way
17:54:36 <sskripnick1> cool
17:55:07 <docaedo> so I'll discuss more and share details next week - I *think* that might be the best. It sounds complicated, but it will probably be less complicated than trying to manage our own new fork/repo and set of reviews there
17:55:29 <mfedosin> docaedo: you're right
17:56:06 <docaedo> oh my we're almost out of time!
17:56:18 <docaedo> this was a good discussion and meeting you guys, thanks for it!
17:56:37 <mfedosin> thank you for your proposal
17:56:50 <mfedosin> it absolutely makes sense
17:57:20 <docaedo> no prob - I'm excited to make this happen and still (after allllll this time!) I think it will be a nice showcase for glare and all the work you and ativelkov and everyone else has put into it
17:58:40 <docaedo> talk to you next week (probably - though I might be on a plane? I need to check my schedule...)
17:58:45 <docaedo> #endmeeting