*** kzaitsev_mb has quit IRC | 00:02 | |
*** kebray has quit IRC | 01:12 | |
*** kebray has joined #openstack-app-catalog | 01:54 | |
*** jmolsen has joined #openstack-app-catalog | 01:54 | |
*** kebray has quit IRC | 01:55 | |
*** jmolsen has quit IRC | 01:58 | |
*** kebray has joined #openstack-app-catalog | 03:33 | |
*** kebray has quit IRC | 03:33 | |
*** kebray has joined #openstack-app-catalog | 03:34 | |
*** kzaitsev_mb has joined #openstack-app-catalog | 05:00 | |
*** kzaitsev_mb has quit IRC | 05:05 | |
*** kzaitsev_mb has joined #openstack-app-catalog | 07:09 | |
*** kzaitsev_mb has quit IRC | 07:43 | |
*** kebray has quit IRC | 07:51 | |
*** kzaitsev_mb has joined #openstack-app-catalog | 09:22 | |
*** jmolsen has joined #openstack-app-catalog | 10:39 | |
*** jmolsen has quit IRC | 12:15 | |
*** kebray has joined #openstack-app-catalog | 15:05 | |
*** kebray has quit IRC | 16:34 | |
*** kebray has joined #openstack-app-catalog | 16:35 | |
*** kzaitsev_mb has quit IRC | 16:36 | |
*** kebray has quit IRC | 16:36 | |
*** kebray has joined #openstack-app-catalog | 16:37 | |
*** kebray has quit IRC | 17:38 | |
kfox1111 | docaedo: have a look a the python server yet? | 17:59 |
---|---|---|
*** kebray has joined #openstack-app-catalog | 17:59 | |
*** kebray has quit IRC | 17:59 | |
*** kebray has joined #openstack-app-catalog | 18:00 | |
docaedo | I did, looked OK and worked for me but still slightly dubious of the cost of supporting django versions for the sake of compressing the whole asset list | 18:02 |
docaedo | BUT that is not to say I'm fully against it either :) Did not get as much time this weekend to play with flask and RAML, but was just going to throw in a few assets and paste up a URL where you can see the results | 18:04 |
kfox1111 | yeah, if another project was doing all of the bits with flask, then I'd vote for just flask. but | 18:05 |
kfox1111 | it was really really useful to be able to look at horizon, see what they did, and just copy a working solution. | 18:06 |
kfox1111 | it would have taken me at least 10 times longer to figure it all out from scratch in flask I think. :/ | 18:07 |
docaedo | yeah :) I am torn because I've never made my own site with API endpoints from scratch, so looking for easy/fast/transparent way. Along that path, flask plus ramses (RAML api definition YAMLs) is SO easy | 18:10 |
docaedo | everything I'm seeing about how to do this under Django looks like it's got lots more pitfalls and will take a whole lot longer. | 18:10 |
docaedo | but that doesn't mean we won't end up going that route, could be that using flask and ramses leaves out enough options to where it would be even more work to make it do what we want longer term | 18:11 |
kfox1111 | yeah, I see them as almost completely seperate things. rest api is a very different t hing then a website. | 18:12 |
kfox1111 | so choosing one technology to rule them all is limiting. | 18:12 |
docaedo | right - so that's the thing I am missing I guess - why do we need python to serve a static website? | 18:12 |
kfox1111 | for example, javascript is much more responsive in a website then python due to working on the client. | 18:13 |
kfox1111 | python for restapi's are great though. | 18:13 |
kfox1111 | basically, we're using python to generate the static website. | 18:13 |
kfox1111 | IE, take 37 different .js files and compile them to 1. | 18:13 |
kfox1111 | so, in a way, we're using python as a web build system. | 18:14 |
kfox1111 | but not using it for anything else server side. | 18:14 |
docaedo | ah! ok that makes a lot more sense and somehow I missed that, apologies :) | 18:14 |
kfox1111 | yeah. I'd like to keep everything I can javascript on the client side, and access stuff through the api calls. | 18:15 |
kfox1111 | django just provides a very simple way to deal with all of the javascript includes. | 18:16 |
kfox1111 | you don't have to copy javascript into the repo, or link to external sites. you just ask xstatic for them, and include them in one template, and it takes care of the rest. | 18:16 |
kfox1111 | pip deals with the rest. | 18:17 |
docaedo | makes sense now, really feel dim for having missed that logic earlier haha | 18:20 |
kfox1111 | no worries. its not really aparent from how djano's setup. | 18:22 |
kfox1111 | but that's all we'd be using it for. | 18:22 |
kfox1111 | it took me a long time to figure out how django compress works. debugging horizon mostly. :/ | 18:23 |
kfox1111 | but basically your just marking the stuff you want all merged together with the compress tag in the template, and the engine takes care of the rest. | 18:23 |
kfox1111 | you can then set COMPRESS_ENABLED=True for it to spit out one file, | 18:24 |
kfox1111 | or set it to false to include all the individual files (makes debugging much easier) | 18:24 |
kfox1111 | We do have to figure out how to make flask rest api do the CORS stuff, and then I think its possible to merge the review. | 18:26 |
docaedo | pip install -U flask-cors | 18:35 |
docaedo | There's slightly more to it, and I'm looking right now for where I saw it, I think I saw something as simple as a config flip in the ini | 18:35 |
docaedo | cors.enable = false | 18:36 |
docaedo | cors.allow_origins = %(base_url)s | 18:36 |
docaedo | cors.allow_credentials = true | 18:36 |
docaedo | (that's with ramses and nefertari) | 18:36 |
kfox1111 | hmm.. | 18:37 |
kfox1111 | probably just a decorator on the rest api? | 18:37 |
kfox1111 | (for v1) | 18:37 |
kfox1111 | ah.. https://github.com/corydolphin/flask-cors/blob/master/examples/view_based_example.py | 18:39 |
docaedo | Also tangentially related, openstack marketplace is php so not sure what we will be able to reference from there w/r/t using openstack ID for auth (https://github.com/openstack-infra/openstackweb/tree/master/marketplace) just wanted to share that before I forgot | 18:49 |
docaedo | and in the category of other things that are apparently afoot, as noted from Serg's reply on the mailing list "The Mirantis team is building a PoC of using Glance v3 (artifacts) as the back-end over the next two weeks." | 18:51 |
docaedo | I'm really not sure what that's about, and might just be miscommunication around "app catalog" vs. "murano", because I don't think anybody has been talking about that, what it would look like, exactly where/how it integrates with the app catalog etc. | 18:52 |
docaedo | but I guess if it does suddenly show up as a glance back end for the app catalog we will see what that could look like :) | 18:53 |
kfox1111 | I think that means just using glance to store its packages rather then storing them in its own db. | 18:53 |
kfox1111 | glance/murano is a local app catalog. what we're providing is a remote catalog. | 18:54 |
kfox1111 | complimentry. | 18:54 |
kfox1111 | yeah, I figured we'd have to use openid or something? | 18:54 |
kfox1111 | I think the'res quite a few implementations. | 18:55 |
docaedo | for murano - which is a cool idea for murano. I do wonder what getting that adopted would look like, as a huge number of operators are still on glance v2, let alone glance v3 | 18:55 |
kfox1111 | unlike v1->v2, I think v3's on the same api server as v2. so I don't think its burdonsom on the deployer like v1. | 18:55 |
kfox1111 | you just kind of get it for free I think. | 18:56 |
docaedo | yep, I don't think using openstackID as one of the auth options will be much of a challenge, seems like the work for ask openstack is a good model too (as you can use a few different ID sources) | 18:56 |
kfox1111 | yeah. | 18:56 |
docaedo | ah interesting, I didn't know that about v1-v2 vs v3 | 18:56 |
kfox1111 | been thinking more and more about using a cloud key of some kind for auth for horizon, so each user doesn't have to auth idividually. | 18:56 |
kfox1111 | it also gives a very interesting other idea. | 18:56 |
kfox1111 | the cloud key could be tied to particulars of the cloud. so, heat engine version... say. | 18:57 |
kfox1111 | then if the user +1's or -1's an entry, we could figure out if its because they had a bad experience due to an incopatable version of heat-engine. | 18:57 |
kfox1111 | say, everyone but a few always plus 1, but everyone who -1'ed are all on the same heat version. | 18:58 |
kfox1111 | we could then flag the template as incompatable with xxxx. | 18:58 |
docaedo | could be an interesting approach | 19:02 |
kfox1111 | nice... delorean's building packages on my box for app-catalog-ui pretty reliably now. | 19:23 |
kfox1111 | just gota get the spec upstreamed now. | 19:23 |
*** kzaitsev_mb has joined #openstack-app-catalog | 20:31 | |
kfox1111 | kzaitsev_mb: hey. | 20:36 |
kzaitsev_mb | pong | 21:30 |
kzaitsev_mb | kfox1111: pong =) | 21:30 |
kfox1111 | hey. | 21:35 |
kfox1111 | heat has a build-info command that lets you query the heat engine version. | 21:36 |
kfox1111 | does murano have such an animal? | 21:36 |
kzaitsev_mb | I believe not. not that I know about anyway | 21:36 |
kfox1111 | could it? :) | 21:37 |
docaedo | That would be pretty great, especially considering the intention to continue improving the capabilities, would be useful to determine what your locally available murano engine is capable of | 21:38 |
kzaitsev_mb | murano is aiming at independable versions of apps. I mean that they should not be dependant on the version of the engine, but on the version of the core library (which is distributed as part of murano, but it aims to be able to distribute it separately.) | 21:41 |
kzaitsev_mb | so in fact it aims for the situation, where the app says I need core-library >= 1.2.3 (and all the features defined there) | 21:41 |
kzaitsev_mb | although the two ideas may complement each other. | 21:44 |
docaedo | sure - should be possible to detect what murano engine you (user/service) has access to from outside murano, that enables the ability for something external to determine which version of an asset/bundle to share for instance | 21:46 |
kzaitsev_mb | I'll definitelly take a look at heats 'build-info', seems usefull for debugging anyway! | 21:47 |
kfox1111 | kzaitsev_mb: we've already hit a situation where liberty murano has more support for things then kilo murano. | 21:47 |
kfox1111 | do you really think that will change so that no new features are added to the engine? | 21:48 |
kzaitsev_mb | well, that's the aim for mitaka, as far as I understand murano versioning | 21:49 |
kfox1111 | hmm... k. | 21:49 |
kfox1111 | will the murano core library come as part of murano then? | 21:50 |
kzaitsev_mb | but I really like the build-info idea anyway. should be usefull as hell for debugging | 21:50 |
kfox1111 | yeah. :) | 21:51 |
kzaitsev_mb | oslo guys spoke of a common bug-report tool for all the projects to share on the meeting today | 21:51 |
kfox1111 | that would be cool. :) | 21:52 |
kzaitsev_mb | don't know why I mentioned it, just thought these might be related =)) | 21:52 |
kfox1111 | somewhat. a bug reporting tool would need to know things like engine version. | 21:53 |
kzaitsev_mb | yeah | 21:53 |
kzaitsev_mb | the plan is to allow distribution of Core-Library separately and version it accordingly — i.e. bump the version whenever a breaking/incompatible change is made. | 21:59 |
kfox1111 | very nice. thats one of my biggest complains with python. | 22:00 |
kfox1111 | so, at some point though, you can't add any more funcitonality to a core library without extending the engine. | 22:01 |
kfox1111 | unless the engine's turnign complete. | 22:01 |
kfox1111 | and I really hope its not. :/ | 22:01 |
kfox1111 | is murano intended to be turning complete? | 22:04 |
kzaitsev_mb | tbh — I do not know the answer =) | 22:05 |
kfox1111 | something the murano teem needs to be able to. As an op, I'm very concerned about not allowing user owned code running on the controller nodes. | 22:06 |
kfox1111 | heat's tried very hard to ensure all run's are time bound, and all user provided code only runs in the vm's they own. | 22:07 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!