| kfox1111 | kzaitsev_ws: alive? | 00:30 |
|---|---|---|
| *** toddjohn has quit IRC | 00:33 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 00:50 | |
| *** kzaitsev_mb has quit IRC | 02:17 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 03:15 | |
| *** kzaitsev_mb has quit IRC | 05:35 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 06:32 | |
| *** kzaitsev_mb has quit IRC | 06:37 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 07:33 | |
| *** kebray has quit IRC | 07:38 | |
| *** kzaitsev_mb has quit IRC | 07:38 | |
| *** kebray has joined #openstack-app-catalog | 07:41 | |
| *** kebray has quit IRC | 08:04 | |
| *** kebray has joined #openstack-app-catalog | 08:10 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 08:34 | |
| *** kzaitsev_mb has quit IRC | 08:39 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 08:43 | |
| *** openstackgerrit has quit IRC | 09:03 | |
| *** openstackgerrit has joined #openstack-app-catalog | 09:04 | |
| *** kzaitsev_mb has quit IRC | 09:23 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 10:31 | |
| openstackgerrit | Merged openstack/app-catalog: Update info about releases for murano apps and bundles https://review.openstack.org/295936 | 11:03 |
| *** openstack has joined #openstack-app-catalog | 14:24 | |
| *** toddjoh__ has joined #openstack-app-catalog | 14:30 | |
| *** toddjohn has quit IRC | 14:34 | |
| *** kebray has quit IRC | 14:45 | |
| *** toddjoh__ has quit IRC | 14:55 | |
| *** toddjohn has joined #openstack-app-catalog | 14:55 | |
| *** toddjohn has quit IRC | 15:00 | |
| *** kebray has joined #openstack-app-catalog | 15:25 | |
| *** toddjohn has joined #openstack-app-catalog | 15:28 | |
| *** kebray has quit IRC | 16:15 | |
| *** kebray has joined #openstack-app-catalog | 16:18 | |
| docaedo | Worth looking at and discussing: https://etherpad.openstack.org/p/newton-cross-project-sessions | 16:22 |
| docaedo | kzaitsev_ws: do you know if mfedosin was planning to join us here for the conversation in 40 minutes? | 16:23 |
| *** mfedosin has joined #openstack-app-catalog | 16:26 | |
| mfedosin | docaedo: hi! I'll be here in 1.5 hours | 16:26 |
| mfedosin | just a little bit busy right now | 16:27 |
| docaedo | mfedosin: oh great! ok I had the time wrong but I'll be here then too | 16:27 |
| *** spzala has quit IRC | 16:33 | |
| *** kebray has quit IRC | 16:36 | |
| *** spzala has joined #openstack-app-catalog | 16:39 | |
| *** spzala has quit IRC | 16:44 | |
| *** spzala has joined #openstack-app-catalog | 16:45 | |
| *** spzala_ has joined #openstack-app-catalog | 16:48 | |
| *** spzala has quit IRC | 16:50 | |
| *** mfedosin has quit IRC | 16:53 | |
| *** spzala_ has quit IRC | 16:53 | |
| *** spzala has joined #openstack-app-catalog | 16:54 | |
| *** spzala_ has joined #openstack-app-catalog | 16:56 | |
| *** spzala has quit IRC | 16:58 | |
| *** spzala_ has quit IRC | 17:00 | |
| kfox1111 | hi | 17:01 |
| kfox1111 | hmm.. k. bbiab. | 17:01 |
| *** spzala has joined #openstack-app-catalog | 17:02 | |
| *** spzala_ has joined #openstack-app-catalog | 17:04 | |
| *** spzala has quit IRC | 17:06 | |
| *** rhagarty has quit IRC | 17:07 | |
| *** rhagarty has joined #openstack-app-catalog | 17:08 | |
| *** spzala_ has quit IRC | 17:08 | |
| *** spzala_ has joined #openstack-app-catalog | 17:09 | |
| *** spzala_ has quit IRC | 17:13 | |
| *** spzala has joined #openstack-app-catalog | 17:14 | |
| *** spzala has quit IRC | 17:19 | |
| *** spzala has joined #openstack-app-catalog | 17:20 | |
| *** spzala has quit IRC | 17:25 | |
| kfox1111 | back. | 17:27 |
| *** spzala has joined #openstack-app-catalog | 17:28 | |
| *** spzala has quit IRC | 17:33 | |
| *** spzala has joined #openstack-app-catalog | 17:34 | |
| *** spzala has quit IRC | 17:39 | |
| *** spzala_ has joined #openstack-app-catalog | 17:48 | |
| *** spzala_ has quit IRC | 17:52 | |
| *** spzala has joined #openstack-app-catalog | 17:54 | |
| *** spzala has quit IRC | 17:58 | |
| *** kairat_ has joined #openstack-app-catalog | 17:58 | |
| nikhil | docaedo: hey, we waiting for mfedosin? | 18:02 |
| docaedo | yeah AFAIK | 18:02 |
| nikhil | cool | 18:02 |
| *** kairat_ has left #openstack-app-catalog | 18:05 | |
| *** kairat_ has joined #openstack-app-catalog | 18:05 | |
| *** spzala has joined #openstack-app-catalog | 18:06 | |
| *** mfedosin has joined #openstack-app-catalog | 18:06 | |
| *** kairat_ has left #openstack-app-catalog | 18:06 | |
| *** kairat_ has joined #openstack-app-catalog | 18:08 | |
| mfedosin | kairat_: hi :) | 18:08 |
| kairat_ | mfedosin: hello | 18:09 |
| mfedosin | waiting for docaedo | 18:09 |
| kairat_ | Ok | 18:09 |
| docaedo | I'm here ;) | 18:10 |
| nikhil | o/ | 18:10 |
| kfox1111 | o/ | 18:10 |
| mfedosin | o/ | 18:11 |
| kairat_ | o/ | 18:11 |
| mfedosin | so, can you describe in short what use cases you want to see from Glare? | 18:12 |
| *** kzaitsev_mb has joined #openstack-app-catalog | 18:13 | |
| docaedo | Basically to be a place that allows people to add artifacts to be shared with others, with anonymous download but authenticated upload | 18:14 |
| mfedosin | okay, it's easy :) | 18:14 |
| docaedo | Can hold binary assets (stored in swift), or else just a remote_url | 18:14 |
| docaedo | and last piece is default should be inactive for new assets, and an asset can only be activated by an app-catalog core | 18:15 |
| kfox1111 | also, its got to run on the internet and be scalable enough for lots of clouds aroudn the world to hit it. | 18:15 |
| docaedo | (I'm also looking for the etherpad that we had for this work, whichi might have more details) | 18:15 |
| kfox1111 | yeah. a, flagged for aproval like feature. | 18:15 |
| mfedosin | it's basic Glare functionality, so no problems here at all | 18:16 |
| mfedosin | what about discoverability? | 18:16 |
| docaedo | oh also, a user should be able to update an entry they added later (like update hash, URL or description) | 18:16 |
| docaedo | and yes, glare is a good fit for this | 18:16 |
| kairat_ | mfedosin: unautn download is not so easy | 18:16 |
| nikhil | mfedosin: unauthenticated download is a Glare functionality? | 18:16 |
| kzaitsev_mb | can only be activated by an app-catalog core: So yes, some actions like publishihng an artifact draft into an active state or changing some specific properties should be restrictable to some specific role | 18:17 |
| nikhil | kairat_: exactly my thoughts :) | 18:17 |
| mfedosin | Glance support it | 18:17 |
| mfedosin | why Glare can't? | 18:17 |
| mfedosin | unautn download I mean | 18:17 |
| nikhil | mfedosin: you mean a special filter for this? | 18:17 |
| kairat_ | mfedosin: we need auth upload | 18:17 |
| nikhil | kairat_: right, we would need a special deployment scenario | 18:18 |
| kfox1111 | I'm guessing we will need a custom middleware for auth, not keystone based. | 18:18 |
| kzaitsev_mb | mfedosin: kairat_: that probably can be solved with policies | 18:18 |
| docaedo | correct, custom middleware, intention is to use openstack ID | 18:18 |
| kzaitsev_mb | anyway policy support seems to be required to allow cores to activate assets | 18:18 |
| nikhil | basically the proxy in front of glare would need to understand which glare nodes to hit for download and which for upload | 18:18 |
| kairat_ | Yep | 18:19 |
| docaedo | there should only be one glare node in this case, as it's hosted as part of the app-catalog site, right? | 18:19 |
| mfedosin | https://github.com/openstack/glance/blob/master/glance/api/middleware/context.py#L36-L39 | 18:19 |
| mfedosin | kzaitsev_mb: we added policy support for activation yesterday | 18:20 |
| kzaitsev_mb | mfedosin: awesome =) | 18:20 |
| docaedo | nice! | 18:20 |
| mfedosin | since Glare uses the same context middleware I don't see any issues with unauthenticated upload | 18:20 |
| nikhil | mfedosin: ah nice, I missed that one! :( | 18:21 |
| docaedo | we would want authenticated upload, because don't want random people adding stuff | 18:21 |
| kzaitsev_mb | mfedosin: it's the other way round — unauth download, auth upload | 18:21 |
| mfedosin | this option is exactly what you need - it allows only read-only access | 18:21 |
| mfedosin | so everyone can list artifacts, perform download | 18:22 |
| nikhil | yep, this should do the trick | 18:22 |
| docaedo | sounds ideal | 18:22 |
| kairat_ | Agree | 18:22 |
| mfedosin | but don't upload or creating new | 18:22 |
| kzaitsev_mb | I think we would also want versioning of the assets, and filtering based on the versions, but that is also a builtin thing, right? | 18:23 |
| nikhil | once this is done, I think we should discuss a bit further on sharing | 18:23 |
| * nikhil shuts up | 18:24 | |
| mfedosin | about versioning... | 18:24 |
| mfedosin | nikhil: next thing is sharing | 18:24 |
| kfox1111 | question. does glare have searchlight integration yet? | 18:24 |
| mfedosin | images don't support it and there is no posibility to set version for them | 18:24 |
| mfedosin | kfox1111: not yet | 18:24 |
| mfedosin | but there is a plan | 18:25 |
| kfox1111 | newton then? | 18:25 |
| nikhil | kfox1111: how critical is that support? | 18:25 |
| mfedosin | kfox1111: or Ocata | 18:25 |
| nikhil | I can chat with folks on that as needed. | 18:25 |
| docaedo | how critical is what, versioning or searchlight? | 18:25 |
| nikhil | searchlight | 18:26 |
| nikhil | I think versioning is important | 18:26 |
| mfedosin | so about versioning and listing - I see two possibilities: | 18:26 |
| kfox1111 | to scale to internet scale and provide much better searchabilty we want to search via elasticsearch. | 18:26 |
| kfox1111 | we can either do that with searchlight, or just use ES directly. | 18:27 |
| mfedosin | first one - add new artifact type for app-catalog called 'apps' | 18:27 |
| kfox1111 | versioning I think is more important. | 18:27 |
| mfedosin | it allows to set version for all artifact, including images | 18:28 |
| mfedosin | also it will allow to filter and sort all installed apps | 18:28 |
| kfox1111 | right now, I think the number of artefacts we will have is small enough that the searching shoudl be ok for now. just less usable. | 18:28 |
| kfox1111 | versioning is becoming a problem though. | 18:28 |
| kfox1111 | so... there are potentially 2 glare's involved in all of this... | 18:28 |
| kfox1111 | glare backing the apps.openstack.org site, | 18:29 |
| kfox1111 | and glare running on the user's cloud. | 18:29 |
| kfox1111 | they can be (and likely) different versions. | 18:29 |
| docaedo | I'm strongly against any requirement that ties apps.openstack.org to another users cloud/glare instance | 18:29 |
| kfox1111 | +1 | 18:30 |
| kfox1111 | we're supporting multiple cloud versions with apps.openstack.org. | 18:30 |
| docaedo | yes, but there should be a disconnect between how things are consumed from the catalog - so they should be able to get things from the site and use them no matter what version of openstack they're running | 18:31 |
| kfox1111 | yeah. | 18:31 |
| mfedosin | I see... | 18:31 |
| kfox1111 | there will be a lot of clouds that won't have glare installed at all. | 18:31 |
| kfox1111 | can't have it, for years. :/ | 18:31 |
| docaedo | right, but if we're providing a searchable index of things people can download, why would a user ever need glare in the case? | 18:32 |
| mfedosin | for sure app catalog's Glare allows to download artifacts | 18:32 |
| kfox1111 | openstack's painful upgrade process pretty well ensures that. :/ | 18:32 |
| kfox1111 | glare <-> glare support could potentially provide a nice path for the two to be compared and for the cloud's glare to pull updated versions from the apps glare. | 18:33 |
| mfedosin | users need glare because it allows to install the application | 18:33 |
| kairat_ | So, do you want private glare repo to be connected with public repo? | 18:34 |
| kfox1111 | but I think we *must* have a way to pull stuff from apps glare to a cloud that doesn't have glare. there are far to many clouds in that state today, and we can't currently reasonably ask them to install glare. | 18:34 |
| docaedo | in tokyo all the operators I talked to were not interested in tying their cloud directly to app catalog stuff, most they want is to make it easy for their users to search and fetch | 18:34 |
| docaedo | I didn't think we were ever talking about requiring users to have glare? | 18:34 |
| kzaitsev_mb | mfedosin: well, if user has glare — that's awesome, but there's going to be dozens of liberty and mitaka clouds, that would not have it. I don't see why having glare on the recievers cloud side should be a requirement for anything | 18:35 |
| docaedo | that would be absolutely off the table | 18:35 |
| kzaitsev_mb | if the glare is there though — we could probably do some nice things, but that's icing on the cake | 18:35 |
| kfox1111 | right. | 18:35 |
| mfedosin | so...? | 18:36 |
| kfox1111 | like, be able to show a view of "upgraded applications to download" or something. | 18:36 |
| kairat_ | Guys, looks like we are too app catalog specific | 18:36 |
| mfedosin | ah, I disccused it kzaitsev_mb | 18:36 |
| mfedosin | there will be the possibility to download the latest version | 18:36 |
| kfox1111 | but only if glare's on the local cloud. | 18:36 |
| docaedo | I would definitely put glare<->glare connections/features down the road, and not something that should influence the work that's happening right now | 18:37 |
| kfox1111 | yeah. | 18:37 |
| kzaitsev_mb | mfedosin: I don't think you ever implied that having glare locally is a requirement =) | 18:37 |
| nikhil | are you guys talking about federated type support? (apps.openstack.org <-> users_cloud_stack) | 18:37 |
| kzaitsev_mb | or do we misunderstand each other? =) | 18:37 |
| nikhil | more of CERN model? | 18:38 |
| docaedo | yeah I am confused why we're still talking about this :) I did not get the impression glare was required from users either | 18:38 |
| mfedosin | kzaitsev_mb: it's a requirement but not necessary | 18:38 |
| docaedo | requirement usually means necessary, so that statement confuses me | 18:38 |
| kzaitsev_mb | confuses me either =) | 18:39 |
| nikhil | I would like to clarify one more thing | 18:39 |
| kfox1111 | I was just trying to make explicit what we were trying to do. glare only on apps.openstack.org, but with the potential for doing local bridging in the future. The latter was talked about a lot at the summit, | 18:39 |
| nikhil | when we say users above, do we really mean openstack cloud users or operators who are using glare? | 18:39 |
| kfox1111 | but the details of, apps.openstack has one version, local cloud another weren't really talked about. | 18:39 |
| mfedosin | Glare will work without local support | 18:39 |
| kairat_ | Yeah | 18:40 |
| docaedo | nikhil: when I say user, I mean user of an openstack cloud (end user), not operator | 18:40 |
| kfox1111 | yeah. I'm sure it will. just making sure everyone is on the same page. | 18:40 |
| nikhil | docaedo: thanks | 18:40 |
| docaedo | from app-catalog perspective, we aim to reach people who have access to openstack clouds (like OVH), not the much smaller number of people who are running clouds :) | 18:40 |
| nikhil | in that case, openstack cloud users (end users) will never need Glare on their local host! | 18:40 |
| docaedo | kfox1111: thanks for making sure that's clear, understand now why it needed to be brought up | 18:40 |
| kfox1111 | I envision most of my app-catalog users will be, high energy physisists, biologists, chemists, etc. | 18:41 |
| mfedosin | moreover, users can use direct requests to download desired application | 18:41 |
| kfox1111 | non computer science types. | 18:41 |
| kfox1111 | and especially not ops. | 18:41 |
| nikhil | yeah, my view of Glare has always been a better version of Glance | 18:41 |
| kairat_ | Yeah | 18:42 |
| nikhil | so people will use Glare just like they use Glance (but for other things too) | 18:42 |
| kfox1111 | yeah, I'd like to see that too. | 18:42 |
| kfox1111 | heat stacks are a bit of a pain without them being versioned and loaded into the cloud. | 18:42 |
| kfox1111 | I really want to load the set of stacks into one, versioned artefact. | 18:43 |
| nikhil | kfox1111: yeah, I know. that's another imp glare use case. | 18:43 |
| nikhil | I meant, I get you there! | 18:43 |
| * kfox1111 nods | 18:43 | |
| mfedosin | kfox1111: how many templates will be there? | 18:43 |
| mfedosin | I mean do you want exactly 'set'? | 18:44 |
| nikhil | https://github.com/openstack/governance/blob/master/reference/projects.yaml#L667 | 18:44 |
| nikhil | ^ that shows it's needed in glare | 18:44 |
| kfox1111 | mfedosin: see for example: https://github.com/EMSL-MSC/heat-templates/tree/master/cfn/389 | 18:45 |
| kfox1111 | they then link to stuff from: https://github.com/EMSL-MSC/heat-templates/tree/master/cfn/lib | 18:45 |
| mfedosin | kairat_: seems like we have a use case for BlobSet :) | 18:45 |
| kairat_ | Not sure | 18:45 |
| kfox1111 | right now, I'm dealing with passing heat params through, so you can fork the git repo's, then change the base url to fetch the stuff from. | 18:46 |
| kairat_ | Ewch template has a name | 18:46 |
| kfox1111 | which is really ugly. :/ | 18:46 |
| kairat_ | Looka like blob dict | 18:46 |
| mfedosin | kairat_: or dict | 18:46 |
| kfox1111 | I want to include them all in one artefact, and then be able to nest a stack over to one of the other files, in the same asset. | 18:46 |
| kairat_ | Each template is a nested stack | 18:46 |
| kfox1111 | ie, relative file references are all relative to the artefact. | 18:46 |
| kairat_ | Can you talk a bit more about vetsioning | 18:47 |
| kfox1111 | then you can download the whole set as a workable unit. | 18:47 |
| kairat_ | What do you expect from glare | 18:47 |
| kfox1111 | somewhat undefined.... | 18:47 |
| nikhil | are we going into dependency management? | 18:47 |
| kfox1111 | we know users come up with more recent versions of artefacts. | 18:47 |
| nikhil | (chaining of artifacts) | 18:48 |
| mfedosin | kfox1111: You will have to do it in several requests | 18:48 |
| docaedo | I think this use case is outside the immediate expectations of app-catalog use of glare at least | 18:48 |
| mfedosin | I mean downloading one file per request is allowed only | 18:48 |
| kfox1111 | docaedo: any really well written heat stack will have multiple templates. | 18:48 |
| kfox1111 | the set should be versioned. | 18:48 |
| nikhil | mfedosin: but we can add that logic built into client for such use cases | 18:49 |
| kairat_ | nikhil: yeah | 18:49 |
| docaedo | sure, but shouldn't heat have a way to settle that? Or wrap those heat templates with murano ;) | 18:49 |
| kfox1111 | versioning will get strange in one way... | 18:49 |
| kfox1111 | since we support multiple cloud versions, and services break things... :/ | 18:49 |
| kfox1111 | there may be a newer version of an asset available, but not on the cloud they want to load it in. | 18:50 |
| kfox1111 | we need a way to filter on that. | 18:50 |
| kfox1111 | we have a start of a way to do that today, and thats what the ever stuff is about. | 18:50 |
| mfedosin | there is the possibility to filter by version | 18:50 |
| mfedosin | for example... | 18:50 |
| kfox1111 | the filter is by engine version, then by newest version of the asset. | 18:51 |
| kairat_ | version would be just an attribute in this case | 18:51 |
| *** openstack has joined #openstack-app-catalog | 19:23 | |
| kairat_ | But they must be simple | 19:24 |
| kairat_ | Not blobs | 19:24 |
| docaedo | I don't think the app catalog needs a specific artifect type does it? We only intend to index things that would be used with openstack | 19:24 |
| kairat_ | ++ to mike | 19:24 |
| kfox1111 | mfedosin: I don't follow.... aren't the plugins we created types? | 19:24 |
| mfedosin | kfox1111: now we call them artifact types | 19:25 |
| mfedosin | but it doesn't matter | 19:25 |
| kfox1111 | ok. then yes, we need the artifact types we created. | 19:25 |
| mfedosin | in other words... | 19:26 |
| mfedosin | there is a type 'images' | 19:26 |
| mfedosin | also there will be 'templates' and 'packages' | 19:26 |
| mfedosin | do we also need 'apps' for app-catalog? | 19:27 |
| kfox1111 | no. 'apps' is a tag. | 19:27 |
| kfox1111 | a template, an image, a package, they can be apps. | 19:27 |
| kfox1111 | or just components. | 19:27 |
| docaedo | "murano apps" probably | 19:27 |
| kzaitsev_mb | I'm not yet comfortable with calling those just 'images' | 19:28 |
| kfox1111 | a components is something that you either want to install, or have to be available. a heat nested stack url, like lib | 19:28 |
| kfox1111 | an app is something a user might actually want to launch directly. | 19:28 |
| mfedosin | murano will have 'packages' :) | 19:28 |
| kfox1111 | an app can be composed of one or more components. | 19:28 |
| kzaitsev_mb | or 'packages' | 19:28 |
| docaedo | I would like the types to include intended service, so instead of "images" glance-images | 19:28 |
| docaedo | no harm in being specific :) | 19:29 |
| kzaitsev_mb | I don't like the idea to give asset types *that* generic names | 19:29 |
| kfox1111 | yeah. there coudl be docker-images or something too. | 19:29 |
| kzaitsev_mb | glance-image-asset or murano-package-asset sounds a lot more specific to me. | 19:29 |
| mfedosin | good idea btw | 19:29 |
| docaedo | kzaitsev_mb: +1 | 19:29 |
| kzaitsev_mb | and we already have 2 types of templates — tosca-templates and heat-templates | 19:30 |
| mfedosin | so, do you need 'app-catalog-apps'? | 19:30 |
| kfox1111 | true. | 19:30 |
| kfox1111 | no. an app is a tag. | 19:30 |
| docaedo | mfedosin: I don't think so | 19:30 |
| mfedosin | okay, got it | 19:30 |
| kfox1111 | just a searchable piece of metadata. | 19:30 |
| mfedosin | then we have to thing about adding version to images | 19:31 |
| mfedosin | because existing image tables in db doesn't support it | 19:31 |
| kairat_ | It must not be existing glance images, Mike | 19:32 |
| kairat_ | It will be specific type for app catalog, iiuc | 19:32 |
| mfedosin | ah, that's true | 19:32 |
| kairat_ | Or i am missing something | 19:32 |
| mfedosin | It means we have to create special vm-image type for app catalog | 19:33 |
| mfedosin | with versioning support | 19:33 |
| kairat_ | We need to investigate how searching can be integrated with glare also | 19:33 |
| mfedosin | kairat_: will call Travis next morning :) | 19:34 |
| mfedosin | (he's responsible for Searchlight) | 19:34 |
| mfedosin | nikhil: do you like the idea to create another artifact type for images? | 19:35 |
| nikhil | mfedosin: I was about to ask ... :) | 19:35 |
| nikhil | guys, how do you handle | 19:35 |
| nikhil | images for ironic and cinder? | 19:35 |
| mfedosin | are they different? | 19:35 |
| nikhil | yes | 19:36 |
| nikhil | cinder images are volume snapshots | 19:36 |
| nikhil | ironic won't have virtual size | 19:36 |
| kfox1111 | we don't handle ironic yet. I don't think you can directly download cinder images except through glance? | 19:36 |
| nikhil | kfox1111: right, because right now it's just snapshots | 19:36 |
| kfox1111 | which then turns them into glance images. | 19:36 |
| nikhil | but there's nothing stopping from someone uploading a volume into glance using the public glance api | 19:37 |
| mfedosin | nikhil: so the answer is 'in the same way as Glance does' | 19:37 |
| kfox1111 | right. | 19:37 |
| nikhil | mfedosin: yeah, something like that | 19:37 |
| kfox1111 | then its just glance. | 19:37 |
| docaedo | yep in our case I don't think we would need to differentiate - a glance image is a glance image | 19:37 |
| kfox1111 | and I think ironic's pulling from glance today too. | 19:37 |
| nikhil | kfox1111: correct | 19:37 |
| kfox1111 | unless your just using bifrost. and we're not supporting that currently. but could. | 19:37 |
| nikhil | ironic is using glance | 19:37 |
| mfedosin | since not ironic nor cinder require versioning we don't need special artifact types for them | 19:38 |
| mfedosin | they are perfectly mapped to the existing db tables | 19:38 |
| nikhil | almost | 19:39 |
| kfox1111 | how does a user know a newer image is available if not versioned? | 19:39 |
| kfox1111 | all app catalog provided resources should be versioned I think. | 19:39 |
| nikhil | (some properties don't match) | 19:39 |
| kfox1111 | arguably, all glare assets too... | 19:39 |
| kfox1111 | how do you know which version you have, if you don't store that. | 19:39 |
| nikhil | kfox1111: ideally the operators makes only the latest available | 19:40 |
| kfox1111 | (the glare <-> glare use case we talked about before) | 19:40 |
| *** spzala has quit IRC | 19:40 | |
| nikhil | and the older ones are accessible only using the known-to-user UUID | 19:40 |
| kfox1111 | nikhil: ops won't make things available. users will load what they want themselves. | 19:40 |
| mfedosin | in glance - there is no way to define version for image | 19:40 |
| kfox1111 | ops don't scale at the same rate users do. | 19:40 |
| kfox1111 | yeah. but glance != glare. | 19:40 |
| nikhil | mfedosin: that's almost true. some ops add versions to the image names though. | 19:41 |
| kzaitsev_mb | mfedosin: I don't see why that should hinder glare from having everything versioned | 19:41 |
| kfox1111 | one of the origional use cases that spawned glare in the first place was me complaining, I need a way to version my images I upload for users. | 19:41 |
| mfedosin | I don't understand how we can store version for images then | 19:41 |
| kfox1111 | so when I have a newer version, people can know they need to upgrade. | 19:41 |
| kfox1111 | the problme is, you can stick the version string in the name, but then templates have to be rewritten to target the new version. | 19:42 |
| kfox1111 | if they want just 'latest' there's no way to do that and version. | 19:42 |
| kfox1111 | or you just always call the image 'latest' but then you never know if your nova instance is running something other then 'latest' | 19:43 |
| kzaitsev_mb | mfedosin: can't you store it in a separate table with metadata on images? If you want to provide access to glance images natively through glare — you could store that info separately and join it on the fly. | 19:43 |
| kfox1111 | make it an optional flag for backwards compatability. but support versioning on everything. | 19:43 |
| nikhil | kfox1111: yeah, I understand versioning is important, I was trying to understand how it's being taken care of currently | 19:44 |
| nikhil | how about, for existing images in glance you could potentially add version as a protected property | 19:44 |
| kfox1111 | its not. and thats the problem. :/ | 19:44 |
| nikhil | and keep that in the sample file in source tree? | 19:44 |
| *** spzala has joined #openstack-app-catalog | 19:44 | |
| nikhil | but whether all operators support it or not, is upto them | 19:44 |
| mfedosin | I like the idea to create another table for images | 19:44 |
| nikhil | app-catalog can use it | 19:45 |
| mfedosin | (image_id, version) | 19:45 |
| mfedosin | just 2 columns | 19:45 |
| kfox1111 | our use case was to automate image creation, ingestion into our clouds so pre upgraded images will always be available. | 19:45 |
| mfedosin | and Glare will use it | 19:45 |
| kfox1111 | version would then need to be setable via the api. | 19:45 |
| kfox1111 | think jenkins jobs building and refreshing the images. | 19:46 |
| nikhil | mfedosin: why do we need table if the property can be used? | 19:46 |
| *** kzaitsev_mb has quit IRC | 19:46 | |
| mfedosin | because version is not a string | 19:47 |
| *** kzaitsev_mb has joined #openstack-app-catalog | 19:47 | |
| docaedo | yeah version can't be user-defined | 19:47 |
| docaedo | (if I follow the property issue anyway) | 19:47 |
| mfedosin | https://github.com/openstack/glance/blob/master/glance/db/sqlalchemy/models_glare.py#L110-L113 | 19:48 |
| nikhil | docaedo: you can have restricted access to properties | 19:48 |
| nikhil | defined by policy rules | 19:48 |
| nikhil | on CRUD | 19:48 |
| docaedo | nikhil: I just mean the version has to be managed programatically, so should bump every time the asset is modified | 19:48 |
| nikhil | docaedo: sure, I think it can be done outside of the DB model too | 19:49 |
| *** spzala has quit IRC | 19:49 | |
| nikhil | unless we're worried about race conditions, but then we are thiking of races during upload as well | 19:49 |
| mfedosin | nikhil: if you mention race conditions - we found a good solution called tooz | 19:50 |
| nikhil | and retrieval on client side can do string_to_no convert | 19:50 |
| kfox1111 | I'm ok with the users being able to set their own version numbers. if they break it, it breaks themselves. | 19:50 |
| kfox1111 | it only matters for shared images, and only the owning tenant shoudl be able to tweak that, which is us ops. | 19:50 |
| mfedosin | kfox1111: Glare has SemVer format support | 19:51 |
| mfedosin | so we can validate what users set for their images | 19:51 |
| kfox1111 | k. | 19:52 |
| mfedosin | So, intermediate results: | 19:53 |
| mfedosin | Glare requires version for everything | 19:53 |
| mfedosin | Listing 'all' artifacts is not required | 19:53 |
| mfedosin | Read-only anonymous access is obligatory | 19:54 |
| nikhil | something about sharing? (did I miss) | 19:55 |
| mfedosin | Glare must be able to work just as a catalog with user's cloud support | 19:55 |
| * nikhil oops | 19:55 | |
| kfox1111 | listing all is not required in the api so long as there's a way to get all the data somehow. (triggers, notifications, etc) | 19:55 |
| kfox1111 | wish list item for searchlight too. | 19:55 |
| mfedosin | kfox1111: yes, notifications are already supported | 19:55 |
| kfox1111 | I think that covers everything. | 19:56 |
| mfedosin | about sharing - in the same way as glance | 19:56 |
| nikhil | mfedosin: but I think we need community image sharing for glare, no? | 19:56 |
| nikhil | just clarifying | 19:56 |
| docaedo | what does community image sharing mean? | 19:56 |
| kfox1111 | I think same as glance. | 19:57 |
| nikhil | docaedo: just about to type :) | 19:57 |
| nikhil | would simple adding members work for individual images | 19:57 |
| docaedo | no, we won't need that | 19:57 |
| kfox1111 | I can see something like an organization account. mapped directly to a tenant? | 19:57 |
| docaedo | if they have anonymous access, they can get the asset, believe that's all we need | 19:57 |
| kfox1111 | like docker hub or git organizations? | 19:57 |
| docaedo | we won't have tenants, we'll have SAML auth against openID | 19:58 |
| kfox1111 | multiple users associated with one project? | 19:58 |
| kfox1111 | its a trust thing.... | 19:58 |
| docaedo | we're not running an openstack cloud though, so we don't have tenants or keystone | 19:58 |
| kfox1111 | I might trust images from "pnnl"'s organization mre then I trust from 'kfox1111' | 19:58 |
| docaedo | who validates you belong to pnnl though? | 19:59 |
| kfox1111 | same for docker. I'd rather use "official" or at least "elastico" tenant images then 'foojoe's | 19:59 |
| mfedosin | I'm not sure about community sharing, since even glance doesn't have it. if we have really good use case we can add it easily | 19:59 |
| kfox1111 | like the other site.s first come to an org, first serve. | 19:59 |
| kfox1111 | I think public, or drafting in a tenant is ok. | 19:59 |
| kfox1111 | visible only to some folks is not needed. | 20:00 |
| kfox1111 | I've got another meeting I got to head to. :/ | 20:00 |
| mfedosin | kfox1111: sure | 20:00 |
| kfox1111 | thanks for the discussion. I think it was very valuable. :) | 20:00 |
| nikhil | mfedosin: I think the sharing they talk about is completely different than glance's | 20:00 |
| docaedo | I have to head out too, but have strong feelings about app catalog asserting domain ownership | 20:00 |
| kfox1111 | we can't assert domain ownership. | 20:00 |
| mfedosin | kfox1111: it was extremely useful | 20:00 |
| kfox1111 | only group things. | 20:01 |
| docaedo | (i.e. we can't be arbiters of truth - who's going to validate I am not officially from microsoft?) | 20:01 |
| kfox1111 | github and docker hub do the same thing, and they haven't exploaded. | 20:01 |
| kfox1111 | gtg. | 20:01 |
| nikhil | kfox1111: docaedo: yeah, totally. thanks for chatting! | 20:01 |
| kfox1111 | thanks all. | 20:01 |
| nikhil | kzaitsev_mb: too :) | 20:01 |
| docaedo | ok - will talk more on that - github and docker have people that handle that in an official capacity :) | 20:01 |
| mfedosin | thanks! | 20:01 |
| docaedo | and yes, this was great, thanks everyone! | 20:01 |
| nikhil | Thanks all! | 20:01 |
| nikhil | good stuff kairat_ mfedosin | 20:02 |
| *** openstack has joined #openstack-app-catalog | 20:34 | |
| *** spzala has joined #openstack-app-catalog | 21:06 | |
| *** spzala has quit IRC | 21:08 | |
| *** spzala has joined #openstack-app-catalog | 21:08 | |
| kfox1111 | docaedo: no, they don't. anyone can sign up for an "organization" account and within seconds its created. | 21:12 |
| kfox1111 | I've created several. | 21:12 |
| docaedo | sure, but how is that valuable then? if anyone can create an org account, why does that have more value than a use account, if no one moderates those organizations? | 21:13 |
| kfox1111 | really, all it is, is a way to group a set of things together, and have multiple users in the "organization" be able to update them. | 21:13 |
| docaedo | actually I do see the value in that, and agree we should work towards it | 21:13 |
| kfox1111 | how you estabish the trustedness of an organization is seperate then it being a useful thing once you've established that trustedness. | 21:14 |
| kfox1111 | for example, I told folks in our org thourgh our official channels that "EMSL-MSC" is our organization on github. | 21:14 |
| docaedo | I was hearing too many openstack cloud parallels though, so as long as this doesn't become it's own little openstack cloud just to host a web site... | 21:14 |
| kfox1111 | then those of us with the keys to that org can do what we need to do. they trust the org. | 21:14 |
| kfox1111 | totally. I don't want that either. | 21:15 |
| docaedo | :) | 21:16 |
| kfox1111 | website, glare, elasticsearch is all we need I think. | 21:17 |
| docaedo | yep, I think that's it | 21:18 |
| kfox1111 | if we're wildly successful, website+elasticsearch may have to be scaled across multiple physical machines to handle load. | 21:18 |
| docaedo | we can dream :P | 21:18 |
| kfox1111 | but one problem at a time. :) | 21:18 |
| kfox1111 | been following the tripleo thread? | 21:20 |
| kfox1111 | they finally are really starting into the hard conversation about containers. :) | 21:21 |
| docaedo | yeah, have been following it, very interesting | 21:21 |
| kfox1111 | very curous how that all will fall out. | 21:23 |
| kfox1111 | there's a lot of ways to skin that cat. | 21:25 |
| *** mfedosin has quit IRC | 21:25 | |
| kfox1111 | still would like to see instance users thing get done... that would really help with the use case... | 21:26 |
| kfox1111 | I'm wondering if I shoudl try to push it through the kuryr folks... since they kind of have the same need too. | 21:26 |
| docaedo | interesting thought, wonder if kuryr wants to fight that fight | 21:29 |
| kfox1111 | I'm not really sure how they could not. | 21:30 |
| kfox1111 | though every project seems to have horibly hacked around it. :/ | 21:30 |
| *** mfedosin has joined #openstack-app-catalog | 21:30 | |
| docaedo | I've only seen them in the place of making networking work right across containers, vms and bare metal, sounded like they didn't have a crystal clear longer term roadmap | 21:31 |
| docaedo | but haven't been watching closely TBH | 21:31 |
| kfox1111 | yeah. but you need some way to have the vm reach out to neutron to add neutron port to the vm, so it can be moved to the container. | 21:32 |
| kfox1111 | so they must have a credential somewhere on the COE's controller to do it. | 21:32 |
| docaedo | but if it's handled on the service side, it has all the rights it needs doesn't it? | 21:33 |
| kfox1111 | I didn't think kuryr had a service. | 21:33 |
| kfox1111 | not on the cloud side. | 21:33 |
| kfox1111 | but even if it does, then you have to authenticate to the service. same issue. | 21:33 |
| kfox1111 | either you use keystone, or you reimplement keystone. :/ | 21:33 |
| docaedo | part of neutron, is the intention (so would be maybe a neutron plugin) http://galsagie.github.io/2015/08/24/kuryr-part1/ | 21:36 |
| kfox1111 | ah. ok. so yeah, its going to need keystone auth. | 21:37 |
| kfox1111 | or neutron needs to reimplement keystone. | 21:37 |
| kfox1111 | same issue. | 21:37 |
| kfox1111 | why no one wants to talk about the elephant in the room is beyond me. :/ | 21:38 |
| docaedo | why would you need to reimplement keystone for this? it would just be an abstraction so docker-style network requests know how to talk to neutron right? maybe I'm not following this properly... | 21:39 |
| kfox1111 | docker network is driven from docker's api. | 21:40 |
| kfox1111 | the request for a network create/attach then goes to neutron. | 21:40 |
| kfox1111 | how does that docker daemon authenticate with neutron, so neutron will give it the port? | 21:40 |
| docaedo | I think they expect magnum to make those calls | 21:40 |
| kfox1111 | docker doesn't know how to talk to keystone. | 21:40 |
| docaedo | ie magnum calls kuryr, magnum calls docker? | 21:40 |
| kfox1111 | kuryr doesn't depend on magnum. | 21:40 |
| kfox1111 | I thought you could plug kuryr directly into docker/kubernetes whether you started it with magnum or not. (manually, murano, etc) | 21:41 |
| docaedo | ah true .. ok I have no idea then what the plan is | 21:41 |
| kfox1111 | I think there's a "and put some credentials here..." step involved they haven't either worked through, or just pushed to the user for now... | 21:42 |
| kfox1111 | tehy will have the same issue for cinder when they try that. | 21:42 |
| *** kairat_ has quit IRC | 22:07 | |
| *** spzala has quit IRC | 22:07 | |
| *** spzala has joined #openstack-app-catalog | 22:08 | |
| *** mfedosin has quit IRC | 22:12 | |
| *** spzala has quit IRC | 22:12 | |
| kfox1111 | ah... now I get what they were talking about with split stack... | 22:19 |
| kfox1111 | they are seperating the heat stack for, deploy a pile of physical machine's with os's, | 22:19 |
| kfox1111 | with the stack for install all the things. | 22:19 |
| docaedo | that makes sense | 22:19 |
| kfox1111 | so you can use the first, and then something like kolla-ansible rather then using the second stack. | 22:19 |
| kfox1111 | that will be very very interesting. :) | 22:20 |
| kfox1111 | that actually could potentially make it even possible for fuel to consider it. | 22:20 |
| docaedo | well ... having seen how that sausage is made, I would be surprised, mainly due to the amount of work that would be required to use heat or kolla within fuel... | 22:22 |
| kfox1111 | yeah. | 22:23 |
| kfox1111 | not saying it would do anything with containers. | 22:23 |
| kfox1111 | just replace the cobbler piece. | 22:23 |
| kfox1111 | they've stated that as a goal at one point, but never followed through. | 22:23 |
| kfox1111 | was curious if that was a time constraint, not wanting to be like tripleo or something else. | 22:24 |
| docaedo | well they're doing image-based deployments (instead of cobbler), not sure that they use ironic yet but that was the plan a year ago anyway | 22:27 |
| kfox1111 | hmm... I hadn't heard they managed to make the switch. interesting. | 22:27 |
| docaedo | they also keep fuel as a something that can't impact the deployed cloud after launching - unless I missed it, tripleO still requires the undercloud to be running at all times right? | 22:28 |
| kfox1111 | not sure its current state. when I looked at ironic, they have a mode to boot a host that doesn't have to contact home to keep it running or reboot it. | 22:29 |
| *** toddjohn has quit IRC | 22:29 | |
| kfox1111 | so at least in theory, they can install and then just use ipmi/the power button to continue using it forever. | 22:29 |
| *** toddjohn has joined #openstack-app-catalog | 22:29 | |
| docaedo | yep | 22:30 |
| kfox1111 | I've kind of wanted to try out implementing the ironic seed vm as a way to install and then statefully manage its own cluster. | 22:30 |
| kfox1111 | just haven't had time enough to try. :/ | 22:31 |
| docaedo | have you played with bifrost? | 22:31 |
| kfox1111 | make a 3 vm ironic cluster, put it on a laptop, use it to deploy physical hosts that just have libvirt on them, then migrate each of the three vm's to the bare metal hosts. | 22:31 |
| kfox1111 | then you have a self sustaining ironic cluster. | 22:32 |
| kfox1111 | you can then scale out as needed. | 22:32 |
| kfox1111 | yeah, bifrost is kind of interesting. | 22:32 |
| *** toddjohn has quit IRC | 22:33 | |
| docaedo | Your cloud must be deployed and humming along happily now huh? | 22:37 |
| *** spzala has joined #openstack-app-catalog | 22:46 | |
| kfox1111 | mostly.... :/ | 22:54 |
| kfox1111 | we have a pile of patches on liberty to get it to work, and just hit one that's not easily backportable. :/ | 22:54 |
| kfox1111 | so we're debating if we want to wait a few weeks and push ahead to mitaka and fix it once and for all. | 22:54 |
| *** toddjohn has joined #openstack-app-catalog | 23:05 | |
| docaedo | heh well there's something to be said for staying closer to master (sometimes! :D ) | 23:17 |
| *** openstack has joined #openstack-app-catalog | 23:25 | |
| kfox1111 | yeah. except when they "fix"/break things. ;) | 23:49 |
| kfox1111 | mitaka has a very long list of bug fixy things we've hit though. | 23:50 |
| kfox1111 | though we're pushing the envelop on new things. :/ | 23:51 |
| kfox1111 | http://blog.kubernetes.io/2016/03/Kubernetes-1.2-even-more-performance-upgrades-plus-easier-application-deployment-and-management-.html | 23:52 |
| kfox1111 | didn't see they released 1.2 yet. interesting changes. | 23:52 |
| *** toddjohn has quit IRC | 23:58 | |
| *** toddjohn has joined #openstack-app-catalog | 23:58 | |
| kfox1111 | hmm... particularly around single node containers and draining... | 23:59 |
| *** spzala has quit IRC | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!