Friday, 2016-03-11

*** kzaitsev_mb has quit IRC00:12
*** spzala has quit IRC00:18
*** spzala has joined #openstack-app-catalog00:18
*** spzala has quit IRC00:23
*** openstackgerrit_ has quit IRC00:23
*** openstackgerrit_ has joined #openstack-app-catalog00:25
*** toddjohn_ has quit IRC00:35
*** openstackgerrit_ has quit IRC00:48
*** openstackgerrit_ has joined #openstack-app-catalog00:49
kfox1111docaedo: how do you get git to care about new files?01:07
kfox1111I guess my workflow is different enough I haven't run into that.01:08
kfox1111I guess that's what gitignore's for.01:09
docaedokfox1111: 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 notices01:09
kfox1111yeah. but you can non longer run two concurrent servers with the way you changed it.01:09
docaedoso assets_merge.yaml doesn't have to be in /tmp TBH, could leave it where it is and just remove the "rm"01:09
kfox1111yeah. I'd be ok with that.01:10
kfox1111and maybe a .gitignore to cover the other case.01:10
docaedotwo concurrent servers? what do you mean?01:10
kfox1111probably shoudl have a gitignore to handle v1/assets too if you'd like.01:10
kfox1111there's no reason you couldn't run two copies of the test server on different ports.01:11
kfox1111with different asset files.01:11
kfox1111I 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
docaedoI suppose, but I haven't run into a need to do that so hadn't really thought much about it01:11
kfox1111but still, cleaner to either put it in the checkout.01:11
kfox1111I'm keeping a braincell on it for when we support a provider catalog in addtion to the global one.01:12
kfox1111like we talked about last summit.01:12
kfox1111they may want to provide the global one, but cache the server local.01:12
docaedoyeah but that sure becomes a stack of madness with glare involved01:13
docaedoand 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 night01:14
openstackgerritChristopher Aedo proposed openstack/app-catalog: Keep assets_merge.yaml
kfox1111heh, yeah, but I think our user base is essentially 0 right now anyway...01:16
docaedowe'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 image01:16
kfox1111do we have metrics posted anywhere?01:16
docaedoI know there's nagios stuff, but I am not sure about log analysis01:17
kfox1111thinking google analytics. I thought I saw some of that in the website code.01:17
kfox1111how many users per day, downloads, etc.01:17
docaedooh that's right, I forgot all about that01:17
docaedoI 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-catalog01:19
kfox1111k. cool.01:19
kfox1111part of me want to know, and part of me is afraid to look. :/01:19
docaedomeanwhile, if you have other ideas on why last_modified isn't being populated, I'm all ears01:19
kfox1111is it not generating the file? hmm.....01:20
docaedoat 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 it01:20
kfox1111and you don't seee it with a fresh checkout?01:20
docaedoit might be generating the file, but look at api/v1/assets and the field is empty as served from production01:20
docaedoworks great locally01:20
*** spzala has quit IRC01:24
kfox1111thats strange.01:26
kfox1111so its not a bug in parsing out the records...01:26
kfox1111it may be a difference in git versions.01:26
kfox1111capturing stdout/error from the build would probably be interesting.01:27
kfox1111I'm guessing the file might just show up blank.01:27
docaedoI think if it was blank, the assets would not have the blank last_modified field though01:27
docaedo(which I believe each asset does)01:28
kfox1111hmm.... yeah. thats a good point.01:28
kfox1111so maybe git blame is formatting differently between our boxen and the server...01:28
kfox1111what os is it?01:28
docaedoI *think* ubuntu12/0401:29
kfox1111.... I think I remember something about a stinky old ubuntu lts....01:29
kfox1111yeah. :/01:29
kfox1111git changed a lot in... 4 years....01:29
docaedoit's possible it's an updated git though, as it's the same set of manifests all the infra servers use for base01:30
docaedoI'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-catalog02:42
*** spzala has quit IRC03:48
*** spzala has joined #openstack-app-catalog03:49
*** spzala has quit IRC03:53
*** spzala has joined #openstack-app-catalog04:49
*** spzala has quit IRC04:54
*** rmoe has quit IRC05:01
*** rmoe has joined #openstack-app-catalog05:04
*** dfflanders has joined #openstack-app-catalog05:34
*** spzala has joined #openstack-app-catalog05:51
*** spzala has quit IRC05:56
*** openstackgerrit_ has quit IRC06:17
*** openstackgerrit_ has joined #openstack-app-catalog06:18
*** spzala has joined #openstack-app-catalog06:52
*** spzala has quit IRC06:58
*** dfflanders has quit IRC07:06
*** kzaitsev_mb has joined #openstack-app-catalog07:59
*** pcaruana has joined #openstack-app-catalog08:41
*** kzaitsev_mb has quit IRC08:54
*** spzala has joined #openstack-app-catalog08:55
*** spzala has quit IRC09:00
*** spzala has joined #openstack-app-catalog09:56
*** spzala has quit IRC10:01
*** kzaitsev_mb has joined #openstack-app-catalog10:28
*** spzala has joined #openstack-app-catalog10:57
*** kzaitsev_mb has quit IRC11:02
*** spzala has quit IRC11:02
*** kzaitsev_mb has joined #openstack-app-catalog11:15
*** kzaitsev_mb has quit IRC11:30
*** spzala has joined #openstack-app-catalog11:59
*** kzaitsev_mb has joined #openstack-app-catalog11:59
*** spzala has quit IRC12:03
*** spzala has joined #openstack-app-catalog13:00
*** spzala has quit IRC13:01
*** spzala has joined #openstack-app-catalog13:01
openstackgerritKirill Zaitsev proposed openstack/app-catalog: Add glare artifacts plugin for app-catalog asset types
openstackgerritKirill Zaitsev proposed openstack/app-catalog: Add script to upload assets to glare
*** toddjohn_ has joined #openstack-app-catalog13:52
*** kzaitsev_mb has quit IRC15:25
*** kzaitsev_mb has joined #openstack-app-catalog15:30
*** spzala has quit IRC16:34
*** spzala has joined #openstack-app-catalog16:34
*** spzala has quit IRC16:39
*** pcaruana has quit IRC16:50
*** spzala has joined #openstack-app-catalog16:58
openstackgerritMerged openstack/app-catalog: Keep assets_merge.yaml
*** pcaruana has joined #openstack-app-catalog17:35
*** kzaitsev_mb has quit IRC17:48
kfox1111looks like mgmt approved the summit. :)18:59
kfox1111you going for sure too?19:06
*** spzala has quit IRC19:22
docaedodefinitely going to be in Austin, booked hotel and flight a while back19:57
kfox1111awesome. then I'll see you there. :)20:01
docaedolooking forward to it!20:06
*** kzaitsev_mb has joined #openstack-app-catalog21:15
kfox1111tosca support's going into murano with an ffe.21:50
kzaitsev_mbthats just a plugin for heat-translator actually21:51
kfox1111we're getting more and more into a weird place. direct assets, and assets that are wrapped in murano.21:51
kfox1111should we just pull out support for tosca then, since we don't really support it yet,21:51
kfox1111and then just push those into murano?21:51
kfox1111since murano already supports horizon.21:51
kfox1111and tosca doesn't have gui support.21:51
kfox1111but then there's the filtering thing for murano.21:53
kfox1111if 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
kfox1111so we would have a murano tosca type asset in that case?21:53
kzaitsev_mbkfox1111: hm. I think it would be easier. it's a matter of format of murano-package, not a separate asset type21:54
kfox1111would it always be enabled, or would it be optional?21:56
kzaitsev_mbthe 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_mbI believe it would be optional. it adds requirement on heat translator and I'm not even sure if it's in global-requirements21:57
kfox1111would it be wraped though into a murano package like you do with heat?21:58
kfox1111if its optional, then we'd need a way to ask murano which plugins it supports.21:59
kzaitsev_mbpretty much yes. I think it would require an additional release of the client to make creating those packages from tosca templates easier21:59
kfox1111right now we can only guess based on murano version. but if optional, we wouldn't be able to guess that part.21:59
kzaitsev_mbsounds fair. an API call to get package formats supported by the api22:00
kfox1111could that be added as part of the ffe?22:01
*** toddjohn_ has quit IRC22:05
kfox1111we'd need to be able to get to it via angular like we are the rest of the murano api.22:05
kzaitsev_mbIt might be a bit too late, since next week would be RC1, Although the call would be a really easy one.22:07
kzaitsev_mbWe 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
kfox1111or postpone tosca 6 months. :/22:11
kfox1111would the murano api as is take it without changes?22:12
kzaitsev_mbtake what? additional call?22:12
kzaitsev_mbor the tosca template as it is?22:12
kfox1111like, if we add a tosca package as a murano package,22:13
kfox1111and 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
kfox1111if that does work, until we get an api from murano to list plugins,22:14
kfox1111we could make a horizon setting for enabling it.22:15
kzaitsev_mbno, 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
kfox1111yeah, but what I mean, if the user had the plugin loaded in murano,22:17
kfox1111and we hadd murano packaged tosca assets listed,22:18
kfox1111would the existing hadoff code between app-catalog-ui and murano work unmodified?22:18
kzaitsev_mbno, there is no wrapping code in ui yet. Probably worth adding it, but that can only happen in newton now.22:21
kfox1111oh. so with the plugin, it wont be able to launch it in the gui, just the cli?22:22
kzaitsev_mbI mean murano-dashboard wouldn't know waht to do with bare tosca plugin yet.22:22
kfox1111well, 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_mbno. 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
kfox1111or can the tosca stuff have aditional params then the heat ones?22:23
kzaitsev_mbbut the packaging part. I think it's manual right now22:23
kfox1111yeah. thats fine. not really my concern.22:23
kfox1111I'm just saying, if we did this:22:23
kfox1111 * ask for tosca assets as murano packages22:23
kfox1111 * mark the packages with a subtype of 'tosca' or something in the asset.yaml22: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 set22:25
kfox1111would things then work? users could search and launch tosca templates?22:25
kfox1111users 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_mbask for tosca assets as murano packages — you mean from the ones uploading it?22:26
kfox1111we remove the tosca asset type we just added, and just use murano packages.22:26
kfox1111since the type we just added doesn't work.22:27
kzaitsev_mbyes, that should work just fine. We indeed would need to add listing of supported package formats as part of that ffe then22:29
kzaitsev_mbthe easy way would be to just add format param to murano-packages and filter by it22:29
kzaitsev_mbsince that's exactly what the plugin adds — a new package format22:29
kfox1111we could do that outside of a ff in the ap catalog. we'd only need to know which plugins murano supports.22:33
kzaitsev_mbkfox1111: btw, would we cut a stable branch for app-catalog-ui?22:34
kzaitsev_mbdoes it release independently?22:34
kzaitsev_mbthe 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/doable22:41
docaedoBig -1 on removing TOSCA assets just because there's a way to deploy them if you have an environment with murano22:45
kfox1111we could cut another release, but we havent really chagned anything since Liberty.22:45
kfox1111docaedo: this would be with murano.22:45
docaedothe 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 catalog22:45
docaedokfox1111: I understand that would be with murano, but TOSCA folks aren't saying users need murano and heat to consume them, only heat22:46
kfox1111so, then we're back into the, there's 4 ways to package 2 types of assets. :/22:47
docaedoIf 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 thing22:47
kfox1111the problem I have with tosca, is there isn't a service associated with it.22:47
kfox1111which makes it a cli only thing.22:47
kfox1111really different then any other openstack project.22:48
kfox1111ideally, it should just be in heat.22:48
kfox1111like cfn and hot.22:48
docaedook - 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 template22:48
kfox1111kind of overlap with heat itself. bit I get where your coming from.22:49
docaedoapp 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
kfox1111its just weird we're growing all these different ways to package stuff. :/22:50
kzaitsev_mbtbh 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
kfox1111really, 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
kfox1111or be a glance package, in the glare sense.22:51
kfox1111but glare's not going to be deployed on any cloud for a while. :/22:51
docaedothing is, WE are not growing different ways (app catalog), OpenStack as a community is22:51
kfox1111what a mess. :/22:51
kfox1111but we're being left to deal with the fallout. :/22:52
docaedofrom 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 that22:53
docaedoSame reasoning I right against becoming a dependency resolver for things between different projects22:54
kzaitsev_mbI'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
kfox1111yeah. 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
docaedoIn this case I'd argue the heat-translator is the service, so there is one to one22:54
kfox1111think of it this way... say murano gains the ability to launch with the raw url.22:55
kfox1111and tosca-translator gains a horizon plugin to launc directly with heat.22:56
kfox1111then their two consumers.22:56
kfox1111then we have 3 possible ways of wrapping the asset type. murano package, raw, and glare artefact.22:56
kfox1111the same is true of heat....22:56
kfox1111and we haven't even talked about docker. :/22:56
docaedonot 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
docaedoI hear what you're saying, but these are issues between the projects, not for app catalog to solve22:57
kfox1111heh. 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
docaedowhat 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
kfox1111its not visible in the projects though. because you only ever have one version in a cloud.22:58
kfox1111it is visibile in our project though, since we support multiple clouds.22:58
kfox1111so users see it as our problem, not their clouds.22:58
docaedoare you talking about app-catalog-ui or app-catalog?22:58
kfox1111thats fair.22:58
kfox1111we store assets that are ment to be consumed by more then just trunk openstack.22:59
docaedoapp-catalog website (index of pointers to assets) can support any version/any could22:59
kfox1111then we need a way for users to select assets that can be ran by their cloud.22:59
kfox1111thats not specific to the plugin or the site.22:59
docaedoI 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 them23:00
kfox1111I'm sure some uses will be able to figure it out.23:00
kfox1111I KNOW some of my users won't be able to.23:00
docaedosure, but it's not the app-catalog charter to become the nanny in that case23:01
* kfox1111 shrugs.23:02
kfox1111guess thats where we disagree.23:02
kfox1111its an ease of use feature.23:02
docaedoAt least the original intention was for the catalog to be agnostic, like a search engine23:02
kfox1111if the catalog's hard to use, it won't get used.23:02
kfox1111I agree, we need to be as agnostic as we can.23:02
kfox1111but we also need to be as user friendly as we can.23:02
kfox1111those two must ballance.23:03
docaedoSure, 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 move23:03
docaedojust like openstack foundation does not prevent projects from having overlapping capabilities23:04
docaedootherwise, why murano? You can do the same thing with heat23:04
kfox1111because heat can't. :/23:05
*** toddjohn_ has joined #openstack-app-catalog23:05
kfox1111but I mostly agree.23:05
kfox1111I'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
kfox1111they are making our lives harder, as well as their own.23:06
docaedoI 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 growth23:07
kfox1111I feel stronly mostly because I've written the code to glue the things together, and they don't make that easy. :)23:08
kfox1111but the conversation tends to stop if we just accept a  new asset type.23:09
kfox1111we should have the conversation before we commit to a new type.23:09
kfox1111if 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 IRC23:10
kfox1111but, yeah. we should definitely have the conversation before we go any further with the website/app-catalog-ui code.23:10
docaedoI 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 progress23:10
docaedoAnother 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
docaedobig 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 CLIs23:13
kfox1111well, if its a plugin, its no different then the horizon plugin.23:13
kfox1111still mostly has to go through the distro packaging path.23:13
kfox1111we don't deploy openstack cli and plugins via pip. we do it with a yum install for our users.23:14
kfox1111I'm sure most sites are like that.23:14
kfox1111I do think it should be a plugin though.23:14
kfox1111if its not a plugin, it would be much harder to add new asset types.23:14
docaedowell it has to be to work with openstack cli AFAIK23:14
kfox1111yeah, I thought so.23:15
docaedoon the other hand, nothing prevents a user from running "pip install python-app-catalog-openstackclient" on their machine23:16
docaedowhich 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 catalog23:17
kfox1111yeah, except knowlege. ;)23:17
kfox111198% of our users here have never touched the login nodes with the preinstalled cli, let alone trying to do it themselves.23:17
docaedook, that's reasonable for your users, but I don't think it's reasonable to assume all users are like your users23:18
kfox1111I agree. I'm just saying, there will be points of deminishing returns there.23:18
kfox1111if 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
kfox1111if someone steps up to write it, great.23:19
docaedoI'm working on that :)23:20
kfox1111k. nice.23:20
kfox1111tangent.... very interesting:
*** toddjohn_ has joined #openstack-app-catalog23:59

Generated by 2.14.0 by Marius Gedminas - find it at!