Wednesday, 2016-03-23

kfox1111kzaitsev_ws: alive?00:30
*** toddjohn has quit IRC00:33
*** kzaitsev_mb has joined #openstack-app-catalog00:50
*** kzaitsev_mb has quit IRC02:17
*** kzaitsev_mb has joined #openstack-app-catalog03:15
*** kzaitsev_mb has quit IRC05:35
*** kzaitsev_mb has joined #openstack-app-catalog06:32
*** kzaitsev_mb has quit IRC06:37
*** kzaitsev_mb has joined #openstack-app-catalog07:33
*** kebray has quit IRC07:38
*** kzaitsev_mb has quit IRC07:38
*** kebray has joined #openstack-app-catalog07:41
*** kebray has quit IRC08:04
*** kebray has joined #openstack-app-catalog08:10
*** kzaitsev_mb has joined #openstack-app-catalog08:34
*** kzaitsev_mb has quit IRC08:39
*** kzaitsev_mb has joined #openstack-app-catalog08:43
*** openstackgerrit has quit IRC09:03
*** openstackgerrit has joined #openstack-app-catalog09:04
*** kzaitsev_mb has quit IRC09:23
*** kzaitsev_mb has joined #openstack-app-catalog10:31
openstackgerritMerged openstack/app-catalog: Update info about releases for murano apps and bundles
*** openstack has joined #openstack-app-catalog14:24
*** toddjoh__ has joined #openstack-app-catalog14:30
*** toddjohn has quit IRC14:34
*** kebray has quit IRC14:45
*** toddjoh__ has quit IRC14:55
*** toddjohn has joined #openstack-app-catalog14:55
*** toddjohn has quit IRC15:00
*** kebray has joined #openstack-app-catalog15:25
*** toddjohn has joined #openstack-app-catalog15:28
*** kebray has quit IRC16:15
*** kebray has joined #openstack-app-catalog16:18
docaedoWorth looking at and discussing:
docaedokzaitsev_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-catalog16:26
mfedosindocaedo: hi! I'll be here in 1.5 hours16:26
mfedosinjust a little bit busy right now16:27
docaedomfedosin: oh great! ok I had the time wrong but I'll be here then too16:27
*** spzala has quit IRC16:33
*** kebray has quit IRC16:36
*** spzala has joined #openstack-app-catalog16:39
*** spzala has quit IRC16:44
*** spzala has joined #openstack-app-catalog16:45
*** spzala_ has joined #openstack-app-catalog16:48
*** spzala has quit IRC16:50
*** mfedosin has quit IRC16:53
*** spzala_ has quit IRC16:53
*** spzala has joined #openstack-app-catalog16:54
*** spzala_ has joined #openstack-app-catalog16:56
*** spzala has quit IRC16:58
*** spzala_ has quit IRC17:00
kfox1111hmm.. k. bbiab.17:01
*** spzala has joined #openstack-app-catalog17:02
*** spzala_ has joined #openstack-app-catalog17:04
*** spzala has quit IRC17:06
*** rhagarty has quit IRC17:07
*** rhagarty has joined #openstack-app-catalog17:08
*** spzala_ has quit IRC17:08
*** spzala_ has joined #openstack-app-catalog17:09
*** spzala_ has quit IRC17:13
*** spzala has joined #openstack-app-catalog17:14
*** spzala has quit IRC17:19
*** spzala has joined #openstack-app-catalog17:20
*** spzala has quit IRC17:25
*** spzala has joined #openstack-app-catalog17:28
*** spzala has quit IRC17:33
*** spzala has joined #openstack-app-catalog17:34
*** spzala has quit IRC17:39
*** spzala_ has joined #openstack-app-catalog17:48
*** spzala_ has quit IRC17:52
*** spzala has joined #openstack-app-catalog17:54
*** spzala has quit IRC17:58
*** kairat_ has joined #openstack-app-catalog17:58
nikhildocaedo: hey, we waiting for mfedosin?18:02
docaedoyeah AFAIK18:02
*** kairat_ has left #openstack-app-catalog18:05
*** kairat_ has joined #openstack-app-catalog18:05
*** spzala has joined #openstack-app-catalog18:06
*** mfedosin has joined #openstack-app-catalog18:06
*** kairat_ has left #openstack-app-catalog18:06
*** kairat_ has joined #openstack-app-catalog18:08
mfedosinkairat_: hi :)18:08
kairat_mfedosin: hello18:09
mfedosinwaiting for docaedo18:09
docaedoI'm here ;)18:10
mfedosinso, can you describe in short what use cases you want to see from Glare?18:12
*** kzaitsev_mb has joined #openstack-app-catalog18:13
docaedoBasically to be a place that allows people to add artifacts to be shared with others, with anonymous download but authenticated upload18:14
mfedosinokay, it's easy :)18:14
docaedoCan hold binary assets (stored in swift), or else just a remote_url18:14
docaedoand last piece is default should be inactive for new assets, and an asset can only be activated by an app-catalog core18:15
kfox1111also, 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
kfox1111yeah. a, flagged for aproval like feature.18:15
mfedosinit's basic Glare functionality, so no problems here at all18:16
mfedosinwhat about discoverability?18:16
docaedooh also, a user should be able to update an entry they added later (like update hash, URL or description)18:16
docaedoand yes, glare is a good fit for this18:16
kairat_mfedosin: unautn download is not so easy18:16
nikhilmfedosin: unauthenticated download is a Glare functionality?18:16
kzaitsev_mbcan 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 role18:17
nikhilkairat_: exactly my thoughts :)18:17
mfedosinGlance support it18:17
mfedosinwhy Glare can't?18:17
mfedosinunautn download I mean18:17
nikhilmfedosin: you mean a special filter for this?18:17
kairat_mfedosin: we need auth upload18:17
nikhilkairat_: right, we would need a special deployment scenario18:18
kfox1111I'm guessing we will need a custom middleware for auth, not keystone based.18:18
kzaitsev_mbmfedosin: kairat_: that probably can be solved with policies18:18
docaedocorrect, custom middleware, intention is to use openstack ID18:18
kzaitsev_mbanyway policy support seems to be required to allow cores to activate assets18:18
nikhilbasically the proxy in front of glare would need to understand which glare nodes to hit for download and which for upload18:18
docaedothere should only be one glare node in this case, as it's hosted as part of the app-catalog site, right?18:19
mfedosinkzaitsev_mb: we added policy support for activation yesterday18:20
kzaitsev_mbmfedosin: awesome =)18:20
mfedosinsince Glare uses the same context middleware I don't see any issues with unauthenticated upload18:20
nikhilmfedosin: ah nice, I missed that one! :(18:21
docaedowe would want authenticated upload, because don't want random people adding stuff18:21
kzaitsev_mbmfedosin: it's the other way round — unauth download, auth upload18:21
mfedosinthis option is exactly what you need - it allows only read-only access18:21
mfedosinso everyone can list artifacts, perform download18:22
nikhilyep, this should do the trick18:22
docaedosounds ideal18:22
mfedosinbut don't upload or creating new18:22
kzaitsev_mbI 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
nikhilonce this is done, I think we should discuss a bit further on sharing18:23
* nikhil shuts up18:24
mfedosinabout versioning...18:24
mfedosinnikhil: next thing is sharing18:24
kfox1111question. does glare have searchlight integration yet?18:24
mfedosinimages don't support it and there is no posibility to set version for them18:24
mfedosinkfox1111: not yet18:24
mfedosinbut there is a plan18:25
kfox1111newton then?18:25
nikhilkfox1111: how critical is that support?18:25
mfedosinkfox1111: or Ocata18:25
nikhilI can chat with folks on that as needed.18:25
docaedohow critical is what, versioning or searchlight?18:25
nikhilI think versioning is important18:26
mfedosinso about versioning and listing - I see two possibilities:18:26
kfox1111to scale to internet scale and provide much better searchabilty we want to search via elasticsearch.18:26
kfox1111we can either do that with searchlight, or just use ES directly.18:27
mfedosinfirst one - add new artifact type for app-catalog called 'apps'18:27
kfox1111versioning I think is more important.18:27
mfedosinit allows to set version for all artifact, including images18:28
mfedosinalso it will allow to filter and sort all installed apps18:28
kfox1111right 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
kfox1111versioning is becoming a problem though.18:28
kfox1111so... there are potentially 2 glare's involved in all of this...18:28
kfox1111glare backing the site,18:29
kfox1111and glare running on the user's cloud.18:29
kfox1111they can be (and likely) different versions.18:29
docaedoI'm strongly against any requirement that ties to another users cloud/glare instance18:29
kfox1111we're supporting multiple cloud versions with
docaedoyes, 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 running18:31
mfedosinI see...18:31
kfox1111there will be a lot of clouds that won't have glare installed at all.18:31
kfox1111can't have it, for years. :/18:31
docaedoright, 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
mfedosinfor sure app catalog's Glare allows to download artifacts18:32
kfox1111openstack's painful upgrade process pretty well ensures that. :/18:32
kfox1111glare <-> 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
mfedosinusers need glare because it allows to install the application18:33
kairat_So, do you want private glare repo to be connected with public repo?18:34
kfox1111but 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
docaedoin 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 fetch18:34
docaedoI didn't think we were ever talking about requiring users to have glare?18:34
kzaitsev_mbmfedosin: 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 anything18:35
docaedothat would be absolutely off the table18:35
kzaitsev_mbif the glare is there though — we could probably do some nice things, but that's icing on the cake18:35
kfox1111like, be able to show a view of "upgraded applications to download" or something.18:36
kairat_Guys, looks like we are too app catalog specific18:36
mfedosinah, I disccused it kzaitsev_mb18:36
mfedosinthere will be the possibility to download the latest version18:36
kfox1111but only if glare's on the local cloud.18:36
docaedoI would definitely put glare<->glare connections/features down the road, and not something that should influence the work that's happening right now18:37
kzaitsev_mbmfedosin: I don't think you ever implied that having glare locally is a requirement =)18:37
nikhilare you guys talking about federated type support? ( <-> users_cloud_stack)18:37
kzaitsev_mbor do we misunderstand each other? =)18:37
nikhilmore of CERN model?18:38
docaedoyeah I am confused why we're still talking about this :) I did not get the impression glare was required from users either18:38
mfedosinkzaitsev_mb: it's a requirement but not necessary18:38
docaedorequirement usually means necessary, so that statement confuses me18:38
kzaitsev_mbconfuses me either =)18:39
nikhilI would like to clarify one more thing18:39
kfox1111I was just trying to make explicit what we were trying to do. glare only on, but with the potential for doing local bridging in the future. The latter was talked about a lot at the summit,18:39
nikhilwhen we say users above, do we really mean openstack cloud users or operators who are using glare?18:39
kfox1111but the details of, apps.openstack has one version, local cloud another weren't really talked about.18:39
mfedosinGlare will work without local support18:39
docaedonikhil: when I say user, I mean user of an openstack cloud (end user), not operator18:40
kfox1111yeah. I'm sure it will. just making sure everyone is on the same page.18:40
nikhildocaedo: thanks18:40
docaedofrom 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
nikhilin that case, openstack cloud users (end users) will never need Glare on their local host!18:40
docaedokfox1111: thanks for making sure that's clear, understand now why it needed to be brought up18:40
kfox1111I envision most of my app-catalog users will be, high energy physisists, biologists, chemists, etc.18:41
mfedosinmoreover, users can use direct requests to download desired application18:41
kfox1111non computer science types.18:41
kfox1111and especially not ops.18:41
nikhilyeah, my view of Glare has always been a better version of Glance18:41
nikhilso people will use Glare just like they use Glance (but for other things too)18:42
kfox1111yeah, I'd like to see that too.18:42
kfox1111heat stacks are a bit of a pain without them being versioned and loaded into the cloud.18:42
kfox1111I really want to load the set of stacks into one, versioned artefact.18:43
nikhilkfox1111: yeah, I know. that's another imp glare use case.18:43
nikhilI meant, I get you there!18:43
* kfox1111 nods18:43
mfedosinkfox1111: how many templates will be there?18:43
mfedosinI mean do you want exactly 'set'?18:44
nikhil^ that shows it's needed in glare18:44
kfox1111mfedosin: see for example:
kfox1111they then link to stuff from:
mfedosinkairat_: seems like we have a use case for BlobSet :)18:45
kairat_Not sure18:45
kfox1111right 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 name18:46
kfox1111which is really ugly. :/18:46
kairat_Looka like blob dict18:46
mfedosinkairat_: or dict18:46
kfox1111I 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 stack18:46
kfox1111ie, relative file references are all relative to the artefact.18:46
kairat_Can you talk a bit more about vetsioning18:47
kfox1111then you can download the whole set as a workable unit.18:47
kairat_What do you expect from glare18:47
kfox1111somewhat undefined....18:47
nikhilare we going into dependency management?18:47
kfox1111we know users come up with more recent versions of artefacts.18:47
nikhil(chaining of artifacts)18:48
mfedosinkfox1111: You will have to do it in several requests18:48
docaedoI think this use case is outside the immediate expectations of app-catalog use of glare at least18:48
mfedosinI mean downloading one file per request is allowed only18:48
kfox1111docaedo: any really well written heat stack will have multiple templates.18:48
kfox1111the set should be versioned.18:48
nikhilmfedosin: but we can add that logic built into client for such use cases18:49
kairat_nikhil: yeah18:49
docaedosure, but shouldn't heat have a way to settle that? Or wrap those heat templates with murano ;)18:49
kfox1111versioning will get strange in one way...18:49
kfox1111since we support multiple cloud versions, and services break things... :/18:49
kfox1111there may be a newer version of an asset available, but not on the cloud they want to load it in.18:50
kfox1111we need a way to filter on that.18:50
kfox1111we have a start of a way to do that today, and thats what the ever stuff is about.18:50
mfedosinthere is the possibility to filter by version18:50
mfedosinfor example...18:50
kfox1111the filter is by engine version, then by newest version of the asset.18:51
kairat_version would be just an attribute in this case18:51
*** openstack has joined #openstack-app-catalog19:23
kairat_But they must be simple19:24
kairat_Not blobs19:24
docaedoI don't think the app catalog needs a specific artifect type does it? We only intend to index things that would be used with openstack19:24
kairat_++ to mike19:24
kfox1111mfedosin: I don't follow.... aren't the plugins we created types?19:24
mfedosinkfox1111: now we call them artifact types19:25
mfedosinbut it doesn't matter19:25
kfox1111ok. then yes, we need the artifact types we created.19:25
mfedosinin other words...19:26
mfedosinthere is a type 'images'19:26
mfedosinalso there will be 'templates' and 'packages'19:26
mfedosindo we also need 'apps' for app-catalog?19:27
kfox1111no. 'apps' is a tag.19:27
kfox1111a template, an image, a package, they can be apps.19:27
kfox1111or just components.19:27
docaedo"murano apps" probably19:27
kzaitsev_mbI'm not yet comfortable with calling those just 'images'19:28
kfox1111a components is something that you either want to install, or have to be available. a heat nested stack url, like lib19:28
kfox1111an app is something a user might actually want to launch directly.19:28
mfedosinmurano will have 'packages' :)19:28
kfox1111an app can be composed of one or more components.19:28
kzaitsev_mbor 'packages'19:28
docaedoI would like the types to include intended service, so instead of "images" glance-images19:28
docaedono harm in being specific :)19:29
kzaitsev_mbI don't like the idea to give asset types *that* generic names19:29
kfox1111yeah. there coudl be docker-images or something too.19:29
kzaitsev_mbglance-image-asset or murano-package-asset sounds a lot more specific to me.19:29
mfedosingood idea btw19:29
docaedokzaitsev_mb: +119:29
kzaitsev_mband we already have 2 types of templates — tosca-templates and heat-templates19:30
mfedosinso, do you need 'app-catalog-apps'?19:30
kfox1111no. an app is a tag.19:30
docaedomfedosin: I don't think so19:30
mfedosinokay, got it19:30
kfox1111just a searchable piece of metadata.19:30
mfedosinthen we have to thing about adding version to images19:31
mfedosinbecause existing image tables in db doesn't support it19:31
kairat_It must not be existing glance images, Mike19:32
kairat_It will be specific type for app catalog, iiuc19:32
mfedosinah, that's true19:32
kairat_Or i am missing something19:32
mfedosinIt means we have to create special vm-image type for app catalog19:33
mfedosinwith versioning support19:33
kairat_We need to investigate how searching can be integrated with glare also19:33
mfedosinkairat_: will call Travis next morning :)19:34
mfedosin(he's responsible for Searchlight)19:34
mfedosinnikhil: do you like the idea to create another artifact type for images?19:35
nikhilmfedosin: I was about to ask ... :)19:35
nikhilguys, how do you handle19:35
nikhilimages for ironic and cinder?19:35
mfedosinare they different?19:35
nikhilcinder images are volume snapshots19:36
nikhilironic won't have virtual size19:36
kfox1111we don't handle ironic yet. I don't think you can directly download cinder images except through glance?19:36
nikhilkfox1111: right, because right now it's just snapshots19:36
kfox1111which then turns them into glance images.19:36
nikhilbut there's nothing stopping from someone uploading a volume into glance using the public glance api19:37
mfedosinnikhil: so the answer is 'in the same way as Glance does'19:37
nikhilmfedosin: yeah, something like that19:37
kfox1111then its just glance.19:37
docaedoyep in our case I don't think we would need to differentiate - a glance image is a glance image19:37
kfox1111and I think ironic's pulling from glance today too.19:37
nikhilkfox1111: correct19:37
kfox1111unless your just using bifrost. and we're not supporting that currently. but could.19:37
nikhilironic is using glance19:37
mfedosinsince not ironic nor cinder require versioning we don't need special artifact types for them19:38
mfedosinthey are perfectly mapped to the existing db tables19:38
kfox1111how does a user know a newer image is available if not versioned?19:39
kfox1111all app catalog provided resources should be versioned I think.19:39
nikhil(some properties don't match)19:39
kfox1111arguably, all glare assets too...19:39
kfox1111how do you know which version you have, if you don't store that.19:39
nikhilkfox1111: ideally the operators makes only the latest available19:40
kfox1111(the glare <-> glare use case we talked about before)19:40
*** spzala has quit IRC19:40
nikhiland the older ones are accessible only using the known-to-user UUID19:40
kfox1111nikhil: ops won't make things available. users will load what they want themselves.19:40
mfedosinin glance - there is no way to define version for image19:40
kfox1111ops don't scale at the same rate users do.19:40
kfox1111yeah. but glance != glare.19:40
nikhilmfedosin: that's almost true. some ops add versions to the image names though.19:41
kzaitsev_mbmfedosin: I don't see why that should hinder glare from having everything versioned19:41
kfox1111one 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
mfedosinI don't understand how we can store version for images then19:41
kfox1111so when I have a newer version, people can know they need to upgrade.19:41
kfox1111the 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
kfox1111if they want just 'latest' there's no way to do that and version.19:42
kfox1111or 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_mbmfedosin: 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
nikhilkfox1111: yeah, I understand versioning is important, I was trying to understand how it's being taken care of currently19:44
nikhilhow about, for existing images in glance you could potentially add version as a protected property19:44
kfox1111its not. and thats the problem. :/19:44
nikhiland keep that in the sample file in source tree?19:44
*** spzala has joined #openstack-app-catalog19:44
nikhilbut whether all operators support it or not, is upto them19:44
mfedosinI like the idea to create another table for images19:44
nikhilapp-catalog can use it19:45
mfedosin(image_id, version)19:45
mfedosinjust 2 columns19:45
kfox1111our use case was to automate image creation, ingestion into our clouds so pre upgraded images will always be available.19:45
mfedosinand Glare will use it19:45
kfox1111version would then need to be setable via the api.19:45
kfox1111think jenkins jobs building and refreshing the images.19:46
nikhilmfedosin: why do we need table if the property can be used?19:46
*** kzaitsev_mb has quit IRC19:46
mfedosinbecause version is not a string19:47
*** kzaitsev_mb has joined #openstack-app-catalog19:47
docaedoyeah version can't be user-defined19:47
docaedo(if I follow the property issue anyway)19:47
nikhildocaedo: you can have restricted access to properties19:48
nikhildefined by policy rules19:48
nikhilon CRUD19:48
docaedonikhil: I just mean the version has to be managed programatically, so should bump every time the asset is modified19:48
nikhildocaedo: sure, I think it can be done outside of the DB model too19:49
*** spzala has quit IRC19:49
nikhilunless we're worried about race conditions, but then we are thiking of races during upload as well19:49
mfedosinnikhil: if you mention race conditions - we found a good solution called tooz19:50
nikhiland retrieval on client side can do string_to_no convert19:50
kfox1111I'm ok with the users being able to set their own version numbers. if they break it, it breaks themselves.19:50
kfox1111it only matters for shared images, and only the owning tenant shoudl be able to tweak that, which is us ops.19:50
mfedosinkfox1111: Glare has SemVer format support19:51
mfedosinso we can validate what users set for their images19:51
mfedosinSo, intermediate results:19:53
mfedosinGlare requires version for everything19:53
mfedosinListing 'all' artifacts is not required19:53
mfedosinRead-only anonymous access is obligatory19:54
nikhilsomething about sharing? (did I miss)19:55
mfedosinGlare must be able to work just as a catalog with user's cloud support19:55
* nikhil oops19:55
kfox1111listing 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
kfox1111wish list item for searchlight too.19:55
mfedosinkfox1111: yes, notifications are already supported19:55
kfox1111I think that covers everything.19:56
mfedosinabout sharing - in the same way as glance19:56
nikhilmfedosin: but I think we need community image sharing for glare, no?19:56
nikhiljust clarifying19:56
docaedowhat does community image sharing mean?19:56
kfox1111I think same as glance.19:57
nikhildocaedo: just about to type :)19:57
nikhilwould simple adding members work for individual images19:57
docaedono, we won't need that19:57
kfox1111I can see something like an organization account. mapped directly to a tenant?19:57
docaedoif they have anonymous access, they can get the asset, believe that's all we need19:57
kfox1111like docker hub or git organizations?19:57
docaedowe won't have tenants, we'll have SAML auth against openID19:58
kfox1111multiple users associated with one project?19:58
kfox1111its a trust thing....19:58
docaedowe're not running an openstack cloud though, so we don't have tenants or keystone19:58
kfox1111I might trust images from "pnnl"'s organization mre then I trust from 'kfox1111'19:58
docaedowho validates you belong to pnnl though?19:59
kfox1111same for docker. I'd rather use "official" or at least "elastico" tenant images then 'foojoe's19:59
mfedosinI'm not sure about community sharing, since even glance doesn't have it. if we have really good use case we can add it easily19:59
kfox1111like the other site.s first come to an org, first serve.19:59
kfox1111I think public, or drafting in a tenant is ok.19:59
kfox1111visible only to some folks is not needed.20:00
kfox1111I've got another meeting I got to head to. :/20:00
mfedosinkfox1111: sure20:00
kfox1111thanks for the discussion. I think it was very valuable. :)20:00
nikhilmfedosin: I think the sharing they talk about is completely different than glance's20:00
docaedoI have to head out too, but have strong feelings about app catalog asserting domain ownership20:00
kfox1111we can't assert domain ownership.20:00
mfedosinkfox1111: it was extremely useful20:00
kfox1111only 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
kfox1111github and docker hub do the same thing, and they haven't exploaded.20:01
nikhilkfox1111: docaedo: yeah, totally. thanks for chatting!20:01
kfox1111thanks all.20:01
nikhilkzaitsev_mb: too :)20:01
docaedook - will talk more on that - github and docker have people that handle that in an official capacity :)20:01
docaedoand yes, this was great, thanks everyone!20:01
nikhilThanks all!20:01
nikhilgood stuff kairat_ mfedosin20:02
*** openstack has joined #openstack-app-catalog20:34
*** spzala has joined #openstack-app-catalog21:06
*** spzala has quit IRC21:08
*** spzala has joined #openstack-app-catalog21:08
kfox1111docaedo: no, they don't. anyone can sign up for an "organization" account and within seconds its created.21:12
kfox1111I've created several.21:12
docaedosure, 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
kfox1111really, 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
docaedoactually I do see the value in that, and agree we should work towards it21:13
kfox1111how you estabish the trustedness of an organization is seperate then it being a useful thing once you've established that trustedness.21:14
kfox1111for example, I told folks in our org thourgh our official channels that "EMSL-MSC" is our organization on github.21:14
docaedoI 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
kfox1111then those of us with the keys to that org can do what we need to do. they trust the org.21:14
kfox1111totally. I don't want that either.21:15
kfox1111website, glare, elasticsearch is all we need I think.21:17
docaedoyep, I think that's it21:18
kfox1111if we're wildly successful, website+elasticsearch may have to be scaled across multiple physical machines to handle load.21:18
docaedowe can dream :P21:18
kfox1111but one problem at a time. :)21:18
kfox1111been following the tripleo thread?21:20
kfox1111they finally are really starting into the hard conversation about containers. :)21:21
docaedoyeah, have been following it, very interesting21:21
kfox1111very curous how that all will fall out.21:23
kfox1111there's a lot of ways to skin that cat.21:25
*** mfedosin has quit IRC21:25
kfox1111still would like to see instance users thing get done... that would really help with the use case...21:26
kfox1111I'm wondering if I shoudl try to push it through the kuryr folks... since they kind of have the same need too.21:26
docaedointeresting thought, wonder if kuryr wants to fight that fight21:29
kfox1111I'm not really sure how they could not.21:30
kfox1111though every project seems to have horibly hacked around it. :/21:30
*** mfedosin has joined #openstack-app-catalog21:30
docaedoI'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 roadmap21:31
docaedobut haven't been watching closely TBH21:31
kfox1111yeah. 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
kfox1111so they must have a credential somewhere on the COE's controller to do it.21:32
docaedobut if it's handled on the service side, it has all the rights it needs doesn't it?21:33
kfox1111I didn't think kuryr had a service.21:33
kfox1111not on the cloud side.21:33
kfox1111but even if it does, then you have to authenticate to the service. same issue.21:33
kfox1111either you use keystone, or you reimplement keystone. :/21:33
docaedopart of neutron, is the intention (so would be maybe a neutron plugin)
kfox1111ah. ok. so yeah, its going to need keystone auth.21:37
kfox1111or neutron needs to reimplement keystone.21:37
kfox1111same issue.21:37
kfox1111why no one wants to talk about the elephant in the room is beyond me. :/21:38
docaedowhy 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
kfox1111docker network is driven from docker's api.21:40
kfox1111the request for a network create/attach then goes to neutron.21:40
kfox1111how does that docker daemon authenticate with neutron, so neutron will give it the port?21:40
docaedoI think they expect magnum to make those calls21:40
kfox1111docker doesn't know how to talk to keystone.21:40
docaedoie magnum calls kuryr, magnum calls docker?21:40
kfox1111kuryr doesn't depend on magnum.21:40
kfox1111I thought you could plug kuryr directly into docker/kubernetes whether you started it with magnum or not. (manually, murano, etc)21:41
docaedoah true .. ok I have no idea then what the plan is21:41
kfox1111I 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
kfox1111tehy will have the same issue for cinder when they try that.21:42
*** kairat_ has quit IRC22:07
*** spzala has quit IRC22:07
*** spzala has joined #openstack-app-catalog22:08
*** mfedosin has quit IRC22:12
*** spzala has quit IRC22:12
kfox1111ah... now I get what they were talking about with split stack...22:19
kfox1111they are seperating the heat stack for, deploy a pile of physical machine's with os's,22:19
kfox1111with the stack for install all the things.22:19
docaedothat makes sense22:19
kfox1111so you can use the first, and then something like kolla-ansible rather then using the second stack.22:19
kfox1111that will be very very interesting. :)22:20
kfox1111that actually could potentially make it even possible for fuel to consider it.22:20
docaedowell ... 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
kfox1111not saying it would do anything with containers.22:23
kfox1111just replace the cobbler piece.22:23
kfox1111they've stated that as a goal at one point, but never followed through.22:23
kfox1111was curious if that was a time constraint, not wanting to be like tripleo or something else.22:24
docaedowell they're doing image-based deployments (instead of cobbler), not sure that they use ironic yet but that was the plan a year ago anyway22:27
kfox1111hmm... I hadn't heard they managed to make the switch. interesting.22:27
docaedothey 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
kfox1111not 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 IRC22:29
kfox1111so 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-catalog22:29
kfox1111I'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
kfox1111just haven't had time enough to try. :/22:31
docaedohave you played with bifrost?22:31
kfox1111make 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
kfox1111then you have a self sustaining ironic cluster.22:32
kfox1111you can then scale out as needed.22:32
kfox1111yeah, bifrost is kind of interesting.22:32
*** toddjohn has quit IRC22:33
docaedoYour cloud must be deployed and humming along happily now huh?22:37
*** spzala has joined #openstack-app-catalog22:46
kfox1111mostly.... :/22:54
kfox1111we have a pile of patches on liberty to get it to work, and just hit one that's not easily backportable. :/22:54
kfox1111so 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-catalog23:05
docaedoheh well there's something to be said for staying closer to master (sometimes! :D )23:17
*** openstack has joined #openstack-app-catalog23:25
kfox1111yeah. except when they "fix"/break things. ;)23:49
kfox1111mitaka has a very long list of bug fixy things we've hit though.23:50
kfox1111though we're pushing the envelop on new things. :/23:51
kfox1111didn't see they released 1.2 yet. interesting changes.23:52
*** toddjohn has quit IRC23:58
*** toddjohn has joined #openstack-app-catalog23:58
kfox1111hmm... particularly around single node containers and draining...23:59
*** spzala has quit IRC23:59

Generated by 2.14.0 by Marius Gedminas - find it at!