| *** kzaitsev_mb has quit IRC | 00:12 | |
| *** spzala has quit IRC | 00:18 | |
| *** spzala has joined #openstack-app-catalog | 00:18 | |
| *** spzala has quit IRC | 00:23 | |
| *** openstackgerrit_ has quit IRC | 00:23 | |
| *** openstackgerrit_ has joined #openstack-app-catalog | 00:25 | |
| *** toddjohn_ has quit IRC | 00:35 | |
| *** openstackgerrit_ has quit IRC | 00:48 | |
| *** openstackgerrit_ has joined #openstack-app-catalog | 00:49 | |
| kfox1111 | docaedo: how do you get git to care about new files? | 01:07 |
|---|---|---|
| kfox1111 | I guess my workflow is different enough I haven't run into that. | 01:08 |
| kfox1111 | I guess that's what gitignore's for. | 01:09 |
| docaedo | kfox1111: main point was that I was trying not to leave anything long-term in app-catalog checkout on the production server, though we already create api/v1 that git notices | 01:09 |
| kfox1111 | yeah. but you can non longer run two concurrent servers with the way you changed it. | 01:09 |
| docaedo | so assets_merge.yaml doesn't have to be in /tmp TBH, could leave it where it is and just remove the "rm" | 01:09 |
| kfox1111 | yeah. I'd be ok with that. | 01:10 |
| kfox1111 | and maybe a .gitignore to cover the other case. | 01:10 |
| docaedo | two concurrent servers? what do you mean? | 01:10 |
| kfox1111 | probably shoudl have a gitignore to handle v1/assets too if you'd like. | 01:10 |
| kfox1111 | there's no reason you couldn't run two copies of the test server on different ports. | 01:11 |
| kfox1111 | with different asset files. | 01:11 |
| kfox1111 | I guess the race is only on build, so it wouldn't happen except if you started them up at about the same time. | 01:11 |
| docaedo | I suppose, but I haven't run into a need to do that so hadn't really thought much about it | 01:11 |
| kfox1111 | but still, cleaner to either put it in the checkout. | 01:11 |
| kfox1111 | I'm keeping a braincell on it for when we support a provider catalog in addtion to the global one. | 01:12 |
| kfox1111 | like we talked about last summit. | 01:12 |
| kfox1111 | they may want to provide the global one, but cache the server local. | 01:12 |
| docaedo | yeah but that sure becomes a stack of madness with glare involved | 01:13 |
| docaedo | and considering the number of providers who have been here asking how to provide global but cache local (I think zero?), definitely not something that keeps me up at night | 01:14 |
| kfox1111 | yeah. | 01:15 |
| openstackgerrit | Christopher Aedo proposed openstack/app-catalog: Keep assets_merge.yaml https://review.openstack.org/291489 | 01:16 |
| kfox1111 | heh, yeah, but I think our user base is essentially 0 right now anyway... | 01:16 |
| kfox1111 | :/ | 01:16 |
| docaedo | we're getting some users of the web site, so there's that - and the docs are pushing projects to use app-catalog if they're going to link to an image | 01:16 |
| kfox1111 | do we have metrics posted anywhere? | 01:16 |
| docaedo | I know there's nagios stuff, but I am not sure about log analysis | 01:17 |
| kfox1111 | thinking google analytics. I thought I saw some of that in the website code. | 01:17 |
| kfox1111 | how many users per day, downloads, etc. | 01:17 |
| docaedo | oh that's right, I forgot all about that | 01:17 |
| docaedo | I think that analytics bug is from the foundation actually (will find ancient mail thread and see about getting a report) | 01:18 |
| *** spzala has joined #openstack-app-catalog | 01:19 | |
| kfox1111 | k. cool. | 01:19 |
| kfox1111 | part of me want to know, and part of me is afraid to look. :/ | 01:19 |
| docaedo | meanwhile, if you have other ideas on why last_modified isn't being populated, I'm all ears | 01:19 |
| kfox1111 | is it not generating the file? hmm..... | 01:20 |
| docaedo | at this point though only debug step I could think of was to leave that assets_merge file around so infra could take a look and see what's in it | 01:20 |
| kfox1111 | and you don't seee it with a fresh checkout? | 01:20 |
| docaedo | it might be generating the file, but look at api/v1/assets and the field is empty as served from production | 01:20 |
| docaedo | works great locally | 01:20 |
| *** spzala has quit IRC | 01:24 | |
| kfox1111 | thats strange. | 01:26 |
| kfox1111 | so its not a bug in parsing out the records... | 01:26 |
| kfox1111 | it may be a difference in git versions. | 01:26 |
| kfox1111 | capturing stdout/error from the build would probably be interesting. | 01:27 |
| kfox1111 | I'm guessing the file might just show up blank. | 01:27 |
| docaedo | I think if it was blank, the assets would not have the blank last_modified field though | 01:27 |
| docaedo | (which I believe each asset does) | 01:28 |
| kfox1111 | hmm.... yeah. thats a good point. | 01:28 |
| kfox1111 | so maybe git blame is formatting differently between our boxen and the server... | 01:28 |
| kfox1111 | what os is it? | 01:28 |
| docaedo | I *think* ubuntu12/04 | 01:29 |
| kfox1111 | .... I think I remember something about a stinky old ubuntu lts.... | 01:29 |
| docaedo | 12.04 | 01:29 |
| kfox1111 | yeah. :/ | 01:29 |
| kfox1111 | git changed a lot in... 4 years.... | 01:29 |
| docaedo | it's possible it's an updated git though, as it's the same set of manifests all the infra servers use for base | 01:30 |
| docaedo | I'm off to do some familying .. infra channel would be able to answer git version question pretty quickly, also could probably give feedback on that git blame usage if it's just a matter of slightly different output. | 01:33 |
| *** spzala has joined #openstack-app-catalog | 02:42 | |
| *** spzala has quit IRC | 03:48 | |
| *** spzala has joined #openstack-app-catalog | 03:49 | |
| *** spzala has quit IRC | 03:53 | |
| *** spzala has joined #openstack-app-catalog | 04:49 | |
| *** spzala has quit IRC | 04:54 | |
| *** rmoe has quit IRC | 05:01 | |
| *** rmoe has joined #openstack-app-catalog | 05:04 | |
| *** dfflanders has joined #openstack-app-catalog | 05:34 | |
| *** spzala has joined #openstack-app-catalog | 05:51 | |
| *** spzala has quit IRC | 05:56 | |
| *** openstackgerrit_ has quit IRC | 06:17 | |
| *** openstackgerrit_ has joined #openstack-app-catalog | 06:18 | |
| *** spzala has joined #openstack-app-catalog | 06:52 | |
| *** spzala has quit IRC | 06:58 | |
| *** dfflanders has quit IRC | 07:06 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 07:59 | |
| *** pcaruana has joined #openstack-app-catalog | 08:41 | |
| *** kzaitsev_mb has quit IRC | 08:54 | |
| *** spzala has joined #openstack-app-catalog | 08:55 | |
| *** spzala has quit IRC | 09:00 | |
| *** spzala has joined #openstack-app-catalog | 09:56 | |
| *** spzala has quit IRC | 10:01 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 10:28 | |
| *** spzala has joined #openstack-app-catalog | 10:57 | |
| *** kzaitsev_mb has quit IRC | 11:02 | |
| *** spzala has quit IRC | 11:02 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 11:15 | |
| *** kzaitsev_mb has quit IRC | 11:30 | |
| *** spzala has joined #openstack-app-catalog | 11:59 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 11:59 | |
| *** spzala has quit IRC | 12:03 | |
| *** spzala has joined #openstack-app-catalog | 13:00 | |
| *** spzala has quit IRC | 13:01 | |
| *** spzala has joined #openstack-app-catalog | 13:01 | |
| openstackgerrit | Kirill Zaitsev proposed openstack/app-catalog: Add glare artifacts plugin for app-catalog asset types https://review.openstack.org/276857 | 13:33 |
| openstackgerrit | Kirill Zaitsev proposed openstack/app-catalog: Add script to upload assets to glare https://review.openstack.org/281602 | 13:39 |
| *** toddjohn_ has joined #openstack-app-catalog | 13:52 | |
| *** kzaitsev_mb has quit IRC | 15:25 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 15:30 | |
| *** spzala has quit IRC | 16:34 | |
| *** spzala has joined #openstack-app-catalog | 16:34 | |
| *** spzala has quit IRC | 16:39 | |
| *** pcaruana has quit IRC | 16:50 | |
| *** spzala has joined #openstack-app-catalog | 16:58 | |
| openstackgerrit | Merged openstack/app-catalog: Keep assets_merge.yaml https://review.openstack.org/291489 | 17:17 |
| *** pcaruana has joined #openstack-app-catalog | 17:35 | |
| *** kzaitsev_mb has quit IRC | 17:48 | |
| kfox1111 | looks like mgmt approved the summit. :) | 18:59 |
| docaedo | nice! | 19:00 |
| kfox1111 | you going for sure too? | 19:06 |
| *** spzala has quit IRC | 19:22 | |
| docaedo | definitely going to be in Austin, booked hotel and flight a while back | 19:57 |
| kfox1111 | awesome. then I'll see you there. :) | 20:01 |
| docaedo | looking forward to it! | 20:06 |
| *** kzaitsev_mb has joined #openstack-app-catalog | 21:15 | |
| kfox1111 | confused... | 21:49 |
| kfox1111 | tosca support's going into murano with an ffe. | 21:50 |
| kzaitsev_mb | thats just a plugin for heat-translator actually | 21:51 |
| kfox1111 | we're getting more and more into a weird place. direct assets, and assets that are wrapped in murano. | 21:51 |
| kfox1111 | should we just pull out support for tosca then, since we don't really support it yet, | 21:51 |
| kfox1111 | and then just push those into murano? | 21:51 |
| kfox1111 | since murano already supports horizon. | 21:51 |
| kfox1111 | and tosca doesn't have gui support. | 21:51 |
| kfox1111 | but then there's the filtering thing for murano. | 21:53 |
| kfox1111 | if plugins are optional, then some clouds wont have tosca support in them, and then we should know which plugins murano supports and filter out assets that don't match. :/ | 21:53 |
| kfox1111 | so we would have a murano tosca type asset in that case? | 21:53 |
| kzaitsev_mb | kfox1111: hm. I think it would be easier. it's a matter of format of murano-package, not a separate asset type | 21:54 |
| kfox1111 | would it always be enabled, or would it be optional? | 21:56 |
| kzaitsev_mb | the package would have a TOSCA.CSAR format or smth similar, I think. the plugin would use heat-translator to convert it on the fly into a heat template and murano than would just use it. | 21:57 |
| kzaitsev_mb | I believe it would be optional. it adds requirement on heat translator and I'm not even sure if it's in global-requirements | 21:57 |
| kfox1111 | would it be wraped though into a murano package like you do with heat? | 21:58 |
| kfox1111 | if its optional, then we'd need a way to ask murano which plugins it supports. | 21:59 |
| kzaitsev_mb | pretty much yes. I think it would require an additional release of the client to make creating those packages from tosca templates easier | 21:59 |
| kfox1111 | right now we can only guess based on murano version. but if optional, we wouldn't be able to guess that part. | 21:59 |
| kzaitsev_mb | sounds fair. an API call to get package formats supported by the api | 22:00 |
| kfox1111 | could that be added as part of the ffe? | 22:01 |
| *** toddjohn_ has quit IRC | 22:05 | |
| kfox1111 | we'd need to be able to get to it via angular like we are the rest of the murano api. | 22:05 |
| kzaitsev_mb | It might be a bit too late, since next week would be RC1, Although the call would be a really easy one. | 22:07 |
| kzaitsev_mb | We might ask for one more exception or ask for an exception to backport it to stable/m later (since it wouldn't really break anything and might be considered a bug integration wise) | 22:08 |
| kfox1111 | or postpone tosca 6 months. :/ | 22:11 |
| kfox1111 | well.... | 22:12 |
| kfox1111 | would the murano api as is take it without changes? | 22:12 |
| kzaitsev_mb | take what? additional call? | 22:12 |
| kzaitsev_mb | or the tosca template as it is? | 22:12 |
| kfox1111 | like, if we add a tosca package as a murano package, | 22:13 |
| kfox1111 | and we use the horizon ap catalog plugin to load it, woudl it just work as is today, assuming the plugin was loaded into murano? | 22:13 |
| kfox1111 | if that does work, until we get an api from murano to list plugins, | 22:14 |
| kfox1111 | we could make a horizon setting for enabling it. | 22:15 |
| kzaitsev_mb | no, not yet, it first would need to be transformed into murano package. For heat-murano-packages this code lives in murano-client and for tosca I don't think there would be such code. | 22:16 |
| kfox1111 | yeah, but what I mean, if the user had the plugin loaded in murano, | 22:17 |
| kfox1111 | and we hadd murano packaged tosca assets listed, | 22:18 |
| kfox1111 | would the existing hadoff code between app-catalog-ui and murano work unmodified? | 22:18 |
| kzaitsev_mb | no, there is no wrapping code in ui yet. Probably worth adding it, but that can only happen in newton now. | 22:21 |
| kfox1111 | oh. so with the plugin, it wont be able to launch it in the gui, just the cli? | 22:22 |
| kzaitsev_mb | I mean murano-dashboard wouldn't know waht to do with bare tosca plugin yet. | 22:22 |
| kfox1111 | well, if it just pushes it back to heat, I would have thought the heat dashboard code would pick it up from there. | 22:22 |
| kzaitsev_mb | no. with the plugin you would be able to package your tosca template in murano package and then load this murano-package in murano and it would behave just fine. | 22:23 |
| kfox1111 | or can the tosca stuff have aditional params then the heat ones? | 22:23 |
| kzaitsev_mb | but the packaging part. I think it's manual right now | 22:23 |
| kfox1111 | yeah. thats fine. not really my concern. | 22:23 |
| kfox1111 | I'm just saying, if we did this: | 22:23 |
| kfox1111 | * ask for tosca assets as murano packages | 22:23 |
| kfox1111 | * mark the packages with a subtype of 'tosca' or something in the asset.yaml | 22:24 |
| kfox1111 | * add a flag to the app-catalog-ui in its settings for wheter murano supports tosca (to be replaced with a probing mechanism later) | 22:25 |
| kfox1111 | * and then tweak app-catalog-ui to filter out tosca assets if the flag isn't set | 22:25 |
| kfox1111 | would things then work? users could search and launch tosca templates? | 22:25 |
| kfox1111 | users would need a way to make the murano packages, but that part is something else. that could be done outside of a feature freeze. | 22:26 |
| kfox1111 | (maybe even a shell script until it merges to trunk) | 22:26 |
| kzaitsev_mb | ask for tosca assets as murano packages — you mean from the ones uploading it? | 22:26 |
| kfox1111 | yeah. | 22:26 |
| kfox1111 | we remove the tosca asset type we just added, and just use murano packages. | 22:26 |
| kfox1111 | since the type we just added doesn't work. | 22:27 |
| kzaitsev_mb | yes, that should work just fine. We indeed would need to add listing of supported package formats as part of that ffe then | 22:29 |
| kzaitsev_mb | the easy way would be to just add format param to murano-packages and filter by it | 22:29 |
| kzaitsev_mb | since that's exactly what the plugin adds — a new package format | 22:29 |
| kfox1111 | we could do that outside of a ff in the ap catalog. we'd only need to know which plugins murano supports. | 22:33 |
| kzaitsev_mb | kfox1111: btw, would we cut a stable branch for app-catalog-ui? | 22:34 |
| kzaitsev_mb | does it release independently? | 22:34 |
| kzaitsev_mb | the only thing I don't really like is that we'll probably have to have a hack in dashboard for the request to api (since client won't have it), but that one is tolerable/doable | 22:41 |
| docaedo | Big -1 on removing TOSCA assets just because there's a way to deploy them if you have an environment with murano | 22:45 |
| kfox1111 | we could cut another release, but we havent really chagned anything since Liberty. | 22:45 |
| kfox1111 | docaedo: this would be with murano. | 22:45 |
| docaedo | the catalog web site should continue to be the place where people can share and find things that work with OpenStack - in this case, a TOSCA template that someone can use with their translator is a good thing to have in the catalog | 22:45 |
| docaedo | kfox1111: I understand that would be with murano, but TOSCA folks aren't saying users need murano and heat to consume them, only heat | 22:46 |
| kfox1111 | so, then we're back into the, there's 4 ways to package 2 types of assets. :/ | 22:47 |
| docaedo | If it makes more sense for app-catalog-ui (to only have the UI use TOSCA stuff if the environment has Murano), that's a different thing | 22:47 |
| kfox1111 | the problem I have with tosca, is there isn't a service associated with it. | 22:47 |
| kfox1111 | which makes it a cli only thing. | 22:47 |
| kfox1111 | really different then any other openstack project. | 22:48 |
| kfox1111 | ideally, it should just be in heat. | 22:48 |
| kfox1111 | like cfn and hot. | 22:48 |
| docaedo | ok - but why would that prevent the catalog from being a place to share TOSCA assets? There's no other overlap between TOSCA and OpenStack other than the translator and a template | 22:48 |
| kfox1111 | kind of overlap with heat itself. bit I get where your coming from. | 22:49 |
| docaedo | app catalog should be agnostic on that stuff though, by choosing to refuse assets because we think they should be packaged/used differently, .. well that's the best way to tell people to go away :) | 22:50 |
| kfox1111 | its just weird we're growing all these different ways to package stuff. :/ | 22:50 |
| kzaitsev_mb | tbh I'd rather agree, that app-catalog-wise it feels better to have tosca templates separately. You want to consume them with heat — consume them with heat. You want to consume them with murano — consume them with murano. | 22:50 |
| kfox1111 | really, the odd thing is probably the cleanest way, is for them to be raw, and then pass the raw url to murano for processing rather hten it being in a package. | 22:51 |
| kfox1111 | or be a glance package, in the glare sense. | 22:51 |
| kfox1111 | but glare's not going to be deployed on any cloud for a while. :/ | 22:51 |
| docaedo | thing is, WE are not growing different ways (app catalog), OpenStack as a community is | 22:51 |
| kfox1111 | what a mess. :/ | 22:51 |
| kfox1111 | true. | 22:52 |
| kfox1111 | but we're being left to deal with the fallout. :/ | 22:52 |
| docaedo | from one perspective, sure, but the core of the app catalog is an index of things that run on openstack, it's not "the central orchestration tool for a few services" or anything like that | 22:53 |
| docaedo | Same reasoning I right against becoming a dependency resolver for things between different projects | 22:54 |
| kzaitsev_mb | I'd rather work on murano being able to process and consume raw tosca templates natively, than restrict users from getting that tosca template (although as a murano developer I would love the idea to have them use murano to launch tosca =))))) | 22:54 |
| kfox1111 | yeah. but the disconnect is becoming, there isn't a 1 to 1 relation between asset and engine. | 22:54 |
| kzaitsev_mb | (by consume I mean — process it with the plugin of course) | 22:54 |
| docaedo | In this case I'd argue the heat-translator is the service, so there is one to one | 22:54 |
| kfox1111 | think of it this way... say murano gains the ability to launch with the raw url. | 22:55 |
| kfox1111 | and tosca-translator gains a horizon plugin to launc directly with heat. | 22:56 |
| kfox1111 | then their two consumers. | 22:56 |
| kfox1111 | then we have 3 possible ways of wrapping the asset type. murano package, raw, and glare artefact. | 22:56 |
| kfox1111 | the same is true of heat.... | 22:56 |
| kfox1111 | and we haven't even talked about docker. :/ | 22:56 |
| docaedo | not fare to include glare artifact just yet (at least not until that functionality is actually working regardless of whether it's part of app catalog backend or not) | 22:57 |
| docaedo | I hear what you're saying, but these are issues between the projects, not for app catalog to solve | 22:57 |
| kfox1111 | heh. its probably going to be a thing sooner or later, and its not going to emediately deprectate all assets the moment it comes out, so there will be a 2+ year overlap. :/ | 22:57 |
| docaedo | what you're saying is you don't like that there are multiple ways to deploy/use a TOSCA template, why not talk to the TOSCA folks about that? | 22:57 |
| kfox1111 | its not visible in the projects though. because you only ever have one version in a cloud. | 22:58 |
| kfox1111 | it is visibile in our project though, since we support multiple clouds. | 22:58 |
| kfox1111 | so users see it as our problem, not their clouds. | 22:58 |
| docaedo | are you talking about app-catalog-ui or app-catalog? | 22:58 |
| kfox1111 | thats fair. | 22:58 |
| kfox1111 | both. | 22:58 |
| kfox1111 | we store assets that are ment to be consumed by more then just trunk openstack. | 22:59 |
| docaedo | app-catalog website (index of pointers to assets) can support any version/any could | 22:59 |
| kfox1111 | then we need a way for users to select assets that can be ran by their cloud. | 22:59 |
| kfox1111 | thats not specific to the plugin or the site. | 22:59 |
| docaedo | I agree that's useful, but it also starts to get opinionated, saying users can't figure it out for themselves if we have multiple versions of assets, or multiple different ways to consume them | 23:00 |
| kfox1111 | I'm sure some uses will be able to figure it out. | 23:00 |
| kfox1111 | I KNOW some of my users won't be able to. | 23:00 |
| docaedo | sure, but it's not the app-catalog charter to become the nanny in that case | 23:01 |
| * kfox1111 shrugs. | 23:02 | |
| kfox1111 | guess thats where we disagree. | 23:02 |
| kfox1111 | its an ease of use feature. | 23:02 |
| docaedo | At least the original intention was for the catalog to be agnostic, like a search engine | 23:02 |
| kfox1111 | if the catalog's hard to use, it won't get used. | 23:02 |
| kfox1111 | I agree, we need to be as agnostic as we can. | 23:02 |
| kfox1111 | but we also need to be as user friendly as we can. | 23:02 |
| kfox1111 | those two must ballance. | 23:03 |
| docaedo | Sure, I agree there's cause for balance, but I don't agree that making the catalog opinionated (you should use THIS approach only for this asset type) is the right move | 23:03 |
| docaedo | just like openstack foundation does not prevent projects from having overlapping capabilities | 23:04 |
| docaedo | otherwise, why murano? You can do the same thing with heat | 23:04 |
| kfox1111 | because heat can't. :/ | 23:05 |
| *** toddjohn_ has joined #openstack-app-catalog | 23:05 | |
| kfox1111 | but I mostly agree. | 23:05 |
| kfox1111 | I'm mostly arguing, if there already is 1 way to do something, we shouldn't encurage multiple ways of doing the same thing, to be developed. | 23:06 |
| kfox1111 | they are making our lives harder, as well as their own. | 23:06 |
| docaedo | I can see the point, though I don't feel as strongly about it as you do. I definitely feel the way to handle it is by talking to the project teams that you think are making bad choices, not by just blocking catalog growth | 23:07 |
| kfox1111 | +1 | 23:07 |
| kfox1111 | I feel stronly mostly because I've written the code to glue the things together, and they don't make that easy. :) | 23:08 |
| kfox1111 | but the conversation tends to stop if we just accept a new asset type. | 23:09 |
| kfox1111 | we should have the conversation before we commit to a new type. | 23:09 |
| kfox1111 | if I knew murano was gaining package support for tosca, I would have blocked the new asset type until everyone talked it through. | 23:09 |
| *** toddjohn_ has quit IRC | 23:10 | |
| kfox1111 | but, yeah. we should definitely have the conversation before we go any further with the website/app-catalog-ui code. | 23:10 |
| docaedo | I think the work you're doing to glue this stuff together needs to have a higher profile, otherwise you're never going to stay ahead of progress | 23:10 |
| docaedo | Another really useful thing we could be doing would be the openstack client plugin (which is something I am hoping to start before the summit) | 23:12 |
| kfox1111 | yeah. | 23:12 |
| kfox1111 | +1 | 23:12 |
| docaedo | big advantage to that approach is that will be in everyones hands immediately (rather than having to convince people to install app-catalog-ui), and can easily work with the other CLIs | 23:13 |
| kfox1111 | well, if its a plugin, its no different then the horizon plugin. | 23:13 |
| kfox1111 | still mostly has to go through the distro packaging path. | 23:13 |
| kfox1111 | we don't deploy openstack cli and plugins via pip. we do it with a yum install for our users. | 23:14 |
| kfox1111 | I'm sure most sites are like that. | 23:14 |
| kfox1111 | I do think it should be a plugin though. | 23:14 |
| kfox1111 | if its not a plugin, it would be much harder to add new asset types. | 23:14 |
| docaedo | well it has to be to work with openstack cli AFAIK | 23:14 |
| kfox1111 | yeah, I thought so. | 23:15 |
| docaedo | on the other hand, nothing prevents a user from running "pip install python-app-catalog-openstackclient" on their machine | 23:16 |
| docaedo | which we can (and should) encourage when it's available, giving users a clean and easy way to search and fetch (and *maybe* launch) things from the catalog | 23:17 |
| kfox1111 | yeah, except knowlege. ;) | 23:17 |
| kfox1111 | 98% of our users here have never touched the login nodes with the preinstalled cli, let alone trying to do it themselves. | 23:17 |
| docaedo | ok, that's reasonable for your users, but I don't think it's reasonable to assume all users are like your users | 23:18 |
| kfox1111 | I agree. I'm just saying, there will be points of deminishing returns there. | 23:18 |
| kfox1111 | if the goal is to maximize users of the app catalog, and we have limited resources, it would be good, but not nessisarily a good priority. | 23:19 |
| kfox1111 | if someone steps up to write it, great. | 23:19 |
| docaedo | I'm working on that :) | 23:20 |
| kfox1111 | k. nice. | 23:20 |
| kfox1111 | tangent.... very interesting: https://sourcecode.cio.gov/ | 23:46 |
| *** toddjohn_ has joined #openstack-app-catalog | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!