17:31:52 <mfedosin> #startmeeting glare
17:31:53 <openstack> Meeting started Mon Aug  1 17:31:52 2016 UTC and is due to finish in 60 minutes.  The chair is mfedosin. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:31:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:31:57 <openstack> The meeting name has been set to 'glare'
17:32:30 <mfedosin> hi :)
17:32:31 <kairat_> o/
17:32:54 <mfedosin> so, updates
17:33:43 <mfedosin> For the most part, we have concentrated on app catalog.
17:33:57 <mfedosin> but we made several updates in Glare
17:34:03 <docaedo> app catalog appreciates that!
17:34:15 <mfedosin> first one is storing content-type for blobs
17:34:34 <mfedosin> it's useful if you work with glare from your browser
17:34:38 <dshakhray_> o/
17:34:59 <mfedosin> icons are icons and not just octet-stream
17:35:42 <mfedosin> also kairat reworked our framework and added default validators to some fields
17:36:01 <mfedosin> for example by default string length is limited by 255 chars
17:36:31 <mfedosin> also we found and fixed several small bugs
17:37:44 <mfedosin> our next steps are integration with app-catalog: OpenID auth middleware, data validation, making Glare to work with Apache and so on
17:38:04 <mfedosin> but they are almost all app-catalog related
17:39:02 <mfedosin> also we are going to implement dynamic quota checking for artifacts
17:39:17 <mfedosin> i.e. calculate blob sizes during upload
17:39:33 <mfedosin> and generate more detailed json-schema
17:39:40 <mfedosin> that's all for today
17:40:09 <mfedosin> let's move on to the main topic.
17:40:29 <mfedosin> #topic Image Artifact Type
17:40:51 <mfedosin> nikhil: docaedo: what should we do with that?
17:41:14 <mfedosin> afaik App-Catalog requires storing images as artifacts
17:41:52 <mfedosin> but it's just for cataloging purposes only
17:41:58 <docaedo> yeah .. I am not sure, I followed that thread on the ML and didn't not have an easy answer
17:42:08 <docaedo> we can fork, but that creates lots of problems later
17:42:19 <docaedo> is it just a setting though?
17:42:34 <mfedosin> docaedo:
17:42:36 <mfedosin> yeah
17:42:48 <docaedo> because regardless of the "confustion" on the mailing list, for our case we are note going to install/manage glance for images and glare for everything else
17:42:49 <mfedosin> artifact type is a schema
17:43:07 <mfedosin> but anyway Nova won't be able to boot from it
17:43:12 <docaedo> then yeah, we use glare for images even though glare can't "officially" hold images
17:43:20 <docaedo> yeah there's no nova tied to glare in this scenario :)
17:44:13 <mfedosin> I think Glare can be used for importing/exporting images between clouds
17:44:31 <nikhil> I don't quite follow this conversation
17:44:53 <nikhil> it's coming out of nowhere and conflicts with defcore work we've been doing in glare for last 14+ months
17:45:06 <nikhil> s/doing in glare/doing in glance/
17:45:06 <mfedosin> scenario is like: glare downloads image from catalog, put it in the store, after that we create an image in glance and set location on the data in store
17:45:46 <docaedo> nikhil: the app catalog use case does not conflict with anything, as it's a one-off case where glare is going to be used to catalog all assets
17:45:58 <nikhil> Let me link the import spec so that it's clear 'why' that API is being discussed
17:46:18 <nikhil> http://specs.openstack.org/openstack/glance-specs/specs/mitaka/approved/image-import/image-import-refactor.html
17:46:19 <mfedosin> nikhil: but we were at defcore meeting, and they didn't mind if glare would provide "image" api
17:46:38 <nikhil> which was this meeting and why wasn't I informed ?
17:46:55 <mfedosin> nikhil: I'll send you a link
17:47:35 <mfedosin> if image-import refactoring is done users will be able to import images from glare directly
17:48:04 <mfedosin> I mean now this work hasn't been started yet
17:48:15 <nikhil> defcore, osc, infra and individuals related have asked for a single streamlined API in glance that will allow them to create (import) images in interoperable way. if we have multiple APIs for importing images, this directly conflicts with that spec.
17:48:18 <mfedosin> so, it's better to use glare to import images in a short term
17:48:47 <nikhil> the work has been started and is currently being discussed
17:49:14 <nikhil> there are many blockers from the defore side and that's been clearly communicated in the last glance-defcore sync
17:49:46 <mfedosin> I think we have to ask for defcore permission
17:50:04 <mfedosin> should I send a message in ML?
17:50:06 <docaedo> mfedosin: this doesn't have anything to do with the app catalog though
17:50:30 <nikhil> I will find the link and share later
17:50:37 <docaedo> mfedosin: app catalog can have any kind of artifact type if feels like having, with no interop concerns :)
17:50:55 <nikhil> mfedosin: oh gosh no, no emails that will result into more confusion
17:51:05 <mfedosin> nikhil: okay :)
17:51:54 <nikhil> docaedo: that's not a problem, it's about a interoperable images API that defcore can provide to operators and end users based on which ecosystem can be built
17:52:17 <nikhil> if there are multiple implementations of the same API (same functionality) (like importing images)
17:52:35 <nikhil> then foundation and the tc cannot provide any guidance on what needs to be used
17:52:37 <mfedosin> but images in app-catalog are just abstract artifacts
17:52:44 <nikhil> this results into broken adoption of the APIs
17:52:46 <mfedosin> it's not the same functionality
17:53:08 <mfedosin> some properties like 'virtual-size' are not there
17:53:13 <nikhil> mfedosin: may be you can create an etherpad for understanding app-catalog use case for images apis
17:53:15 <nikhil> ?
17:53:35 <docaedo> yeah there is some confusion here, app-catalog is a web site, which will let users download things from it, not something that would be installed with an openstack environment
17:54:04 <docaedo> so the app catalog simply plans to use glare as an interface to ingesting assets, cataloging the assets, and letting people choose which ones to download
17:54:09 <mfedosin> no one ever will be used it to boot vms :)
17:54:23 <docaedo> it will not be coupled to any openstack environment, connected to nova, etc.
17:54:48 <docaedo> it will present an API, but it's the app-catalog API not the glare API (even though they will be very similar)
17:54:59 <nikhil> just three things really: 1) why glance isn't sufficient 2) what APIs need to be reimplemented in glare that's not in glance and the difference in those glare-vs-glance APIs 3) how is just app-catalog going to be the sole consumer for these APIs and some details around service catalog, read only things etc
17:55:09 <mfedosin> if it helps we can call related artifact type "app-catalog-images"
17:55:21 <docaedo> mfedosin: that makes sense to me
17:55:29 <nikhil> when we have this information we can add that to the import spec so that osc, infra etc are not confused
17:56:05 <docaedo> who is confused?  This is not the glare API, it's the app-catalog API, maybe was a mistake to conflate the two in this meeting?
17:56:45 <nikhil> so, let me as a simple question:
17:56:53 <docaedo> (BTW, this kind of conversation is exactly why I was reluctant for a long time to use glare for this rather than working on our own implementation)
17:57:35 <docaedo> nikhil: please ask away :)
17:58:21 <nikhil> after implementing this stuff: will a regular user be able to GET (or POST) to <endpoint>/glare/images/artifact_id that will go ahead and create an image in the glance DB (or not sure may be glare DB -- which I don't quite get how will be used in IaaS layer)
17:58:52 <nikhil> ?
17:59:08 <mfedosin> emmm... everything is possible of course :)
17:59:15 <nikhil> lol
17:59:16 <docaedo> nikhil: for me, "regular user" is a user of the app catalog website
17:59:21 <mfedosin> but I don't think it's required
17:59:44 <docaedo> nikhil: for other cases, they would not be configured this way, so this use of uploading glance images into glare is unique to the community app catalog AFAIK
17:59:52 <nikhil> (this is why I was suggesting a service API for glare a month back that will hide all this from regular end user)
18:00:09 <mfedosin> I mean each artifact type comes with db
18:00:20 <nikhil> docaedo: and that's okay with me and exactly what I had suggested a while back
18:00:22 <mfedosin> by default it's regular artifact db
18:00:23 <docaedo> nikhil: we have an existing API for the app catalog, and glare will be behind our v2 api
18:00:36 <nikhil> docaedo: the thing is 'all is possible' type situation which creates confusion
18:00:39 <mfedosin> okay, sorry, we're out of time
18:00:51 <mfedosin> we can continue in openstack-glance
18:00:58 <docaedo> yeah, probably best to not discuss app catalog stuff too much in this context :)
18:00:59 <mfedosin> #endmeeting