kfox1111 | kzaitsev_mb: hah. in the end, it was a missing ';' ! :) | 00:19 |
---|---|---|
*** kzaitsev_mb has quit IRC | 00:20 | |
kfox1111 | kzaitsev_ws: https://review.openstack.org/#/c/224937/ :) | 00:22 |
openstackgerrit | Kevin Fox proposed openstack/app-catalog-ui: Add missing semicolons https://review.openstack.org/224939 | 00:31 |
kfox1111 | this patch wasn't needed, but doesn't hurt to cleanup anyway. | 00:31 |
openstackgerrit | Merged openstack/app-catalog-ui: Add missing semicolons https://review.openstack.org/224939 | 00:32 |
*** openstackgerrit has quit IRC | 05:31 | |
*** openstackgerrit has joined #openstack-app-catalog | 05:31 | |
*** dddh has joined #openstack-app-catalog | 08:08 | |
*** kzaitsev_mb has joined #openstack-app-catalog | 09:36 | |
*** kzaitsev_mb has quit IRC | 09:41 | |
*** kzaitsev_mb has joined #openstack-app-catalog | 11:14 | |
*** kebray has joined #openstack-app-catalog | 12:00 | |
*** kzaitsev_mb has quit IRC | 12:02 | |
*** kzaitsev_mb has joined #openstack-app-catalog | 13:07 | |
*** kebray has quit IRC | 13:42 | |
*** openstackgerrit has quit IRC | 13:46 | |
*** openstackgerrit has joined #openstack-app-catalog | 13:46 | |
*** kebray has joined #openstack-app-catalog | 13:59 | |
kzaitsev_mb | https://review.openstack.org/#/c/224937/ | 14:22 |
kzaitsev_mb | ha | 14:22 |
kzaitsev_mb | ha =( | 14:22 |
*** rhagarty_ has quit IRC | 14:36 | |
*** rhagarty has quit IRC | 14:36 | |
*** kebray has quit IRC | 14:40 | |
*** rhagarty has joined #openstack-app-catalog | 14:43 | |
*** rhagarty_ has joined #openstack-app-catalog | 14:43 | |
*** kebray has joined #openstack-app-catalog | 14:52 | |
*** kebray has quit IRC | 14:54 | |
*** kebray has joined #openstack-app-catalog | 14:55 | |
kfox1111 | its merged. so I think we're good again. :) | 16:02 |
kzaitsev_mb | yep | 16:02 |
kfox1111 | kzaitsev_mb: have a review up for the url thing yet?\ | 16:02 |
kzaitsev_mb | kfox1111: sure I did. Pinged all the folks in murano, but couldn't reach Serg (the PTL) he must be traveling right now I guess | 16:03 |
kzaitsev_mb | so I believe that murano guys would be able to respond only on Monday | 16:04 |
kfox1111 | k. got a url? | 16:04 |
kzaitsev_mb | url for what? | 16:05 |
kfox1111 | the review. | 16:05 |
kzaitsev_mb | oh, sure. docaedo sent a nice letter ) | 16:05 |
kfox1111 | yup. :) | 16:06 |
kfox1111 | kzaitsev_mb: can't find the review. | 16:17 |
kzaitsev_mb | you mean, that changes MURANO_REPO_URL? | 16:17 |
kfox1111 | yeah. | 16:18 |
kzaitsev_mb | haven't commited it yet. We've been discussing alternatives with murano guys | 16:19 |
kfox1111 | ah. ok. | 16:20 |
kfox1111 | any alternatives pop up? | 16:20 |
kzaitsev_mb | Can do it now with WIP, if you want to test | 16:20 |
kzaitsev_mb | well, they're more complicated | 16:20 |
kfox1111 | on which side? :) | 16:21 |
kfox1111 | thats ok. just wanted to follow it if it existed. | 16:21 |
kzaitsev_mb | one of the ideas would be to pass version to that script on murano_store and make it redirect to the version. | 16:22 |
kzaitsev_mb | but that IMO leads to sooo many complications | 16:22 |
kzaitsev_mb | like there has to be a way in the UI to specify the version you want and discover what versions exist | 16:23 |
kfox1111 | ah. yeah. then murano needs intimite knowlege of the catalog then. | 16:24 |
kzaitsev_mb | and it also feels like premature shot at versioning | 16:24 |
kfox1111 | which may be ok, but would have to be discussed carefully. | 16:24 |
kfox1111 | which would take time. | 16:24 |
kfox1111 | yeah. | 16:24 |
kzaitsev_mb | and that kind of API would have to stick and be supported for some time | 16:24 |
kfox1111 | right. with the url change, its a very very corse grained versioning that will be easy to support for a long time, | 16:25 |
kfox1111 | and can be updated to use the real versioning once its decided what that would look like. | 16:25 |
kfox1111 | yeah, I guess I'm -1 on the passing through murano_store since it then needs to know when to pass it, which means they need to start parsing the app catalog entries. that woudl be a very last minute change. :/ | 16:26 |
kfox1111 | we'd have to quickly figure out how to tag entries and add multiple url's to the catalog... | 16:27 |
kfox1111 | yeah, we'd be basically implementing an early version of versioning at that point. :/ | 16:27 |
kzaitsev_mb | passing through murano_store: you mean passing parameters to that url? | 16:27 |
kfox1111 | to have murano ask for a kilo / liberty version depending on what it throught it wanted. | 16:28 |
kzaitsev_mb | the idea was to pass something like version=x.y.z, actually | 16:28 |
kfox1111 | if it just roots at the liberty url, we can pass back kilo packages as needed and murano doesn't have to know... | 16:28 |
kzaitsev_mb | but anyway ) | 16:28 |
kfox1111 | oh. | 16:28 |
kfox1111 | version of murano? | 16:28 |
kzaitsev_mb | version of asset ) | 16:29 |
kzaitsev_mb | that doesn't change much, just to clarify | 16:29 |
kfox1111 | but they would have to know which version. | 16:29 |
kfox1111 | would they update package_name to include version then? | 16:30 |
kzaitsev_mb | murano apps know which version they depend upon | 16:30 |
kfox1111 | or woudl they require version + package_name to always be specified? | 16:30 |
docaedo | Yeah the catalog should not have to know much of anything about murano, it's basically a bucket of things, and murano or any other app can pull things out of the bucket | 16:30 |
kfox1111 | thats in the zip? | 16:30 |
kzaitsev_mb | version + package_name in the zip, yes. version is currently optional | 16:30 |
kzaitsev_mb | and will be, I guess, which means any version | 16:31 |
docaedo | and it sounds like Murano has the logic needed, maybe just comes down to naming assets right | 16:31 |
kfox1111 | so then it can't be relied apon. :/ | 16:31 |
kfox1111 | version I mean. | 16:31 |
kfox1111 | if it doesn't always specify it. | 16:31 |
kzaitsev_mb | kfox1111: doesn't sound true. you can always pip install foo | 16:31 |
kfox1111 | the logic is something like, if version specified, then give that one, if not, find the newest version of the asset that matches the engine version. :/ | 16:32 |
kzaitsev_mb | and you can install foo=x.y.z | 16:32 |
docaedo | kzaitsev_mb: you said "We've been discussing alternatives with murano guys" .. where is this discussion happening? | 16:32 |
kzaitsev_mb | kfox1111: no, engine version should not be concidered I believe | 16:32 |
kfox1111 | then you break kilo. :/ | 16:32 |
kzaitsev_mb | docaedo: I'm afraid it was more personal | 16:32 |
kfox1111 | or have to go back and rebuild all your kilo artifacts to pin them to specific versions. | 16:33 |
kzaitsev_mb | kfox1111: kilo does not yet have versioning | 16:33 |
kzaitsev_mb | it was introduced in l | 16:33 |
kfox1111 | ... | 16:33 |
kzaitsev_mb | so I believe kilo would have to stay the way it is | 16:34 |
kfox1111 | so then the only option is to have a seperate repo url for kilo and liberty+. | 16:34 |
kzaitsev_mb | why? | 16:34 |
kfox1111 | because if you don't have seperate url's, then when you make a change for liberty that relies on versions, it will break kilo. | 16:34 |
kzaitsev_mb | I thought, that app-catalog would have an API for versioning and requesting binaries | 16:34 |
kzaitsev_mb | and it would be different from what we have for kilo | 16:35 |
kfox1111 | we will. buit probably not in liberty... there's very little time for that. :/ | 16:35 |
docaedo | kzaitsev_mb: it will, but not in time for liberty | 16:35 |
kzaitsev_mb | sure not for liberty | 16:35 |
kfox1111 | if we do the REPO_URL = apps.openstack.org/api/v1/murano_repo/liberty thing, then we buy us time to fix liberty and come up with a real solution for Mitaka. | 16:35 |
docaedo | kzaitsev_mb: also even if the app catalog has the concept of different versions, that doesn't help murano today, and would still break for kilo users if we suddenly change/add stuff | 16:36 |
kfox1111 | once we come up with the real fix for Mitaka, we can make the murano_repo/liberty script honor the versioning system came up with for Mitaka. | 16:36 |
docaedo | I agree with kfox1111 that the only way to keep kilo working, and introduce a temporary fix for liberty is change the URL | 16:36 |
kzaitsev_mb | kfox1111: Agree on that one | 16:36 |
kzaitsev_mb | hey, I'm not advocating that other solution ) | 16:37 |
docaedo | BUT all of that only matters if murano wants backward compatability. if murano doesn't care, then we shouldn't care, and we cant go down the path of tying the catalog closely to murano | 16:37 |
kfox1111 | yeah. just trying to understand it. | 16:37 |
kzaitsev_mb | I do not like it either, cause I feel, that it means too much work too late in the cycle ) | 16:37 |
kfox1111 | with my op hat on, | 16:37 |
kfox1111 | lack of caring about compatabiliyt would be one more reason not to install it for my users. :/ | 16:38 |
kzaitsev_mb | how would the backward compatibility break if we keep those storage.apps files where they are? | 16:40 |
docaedo | kzaitsev_mb: sounds like that would not be a problem, and I think the three of us are all thinking along those lines | 16:40 |
docaedo | the issue/question is for liberty release of murano, what (if anything) will need to change on the app catalog side? | 16:40 |
kfox1111 | because if we update the resources to liberty versions to make the liberty murano engine happy, it breaks the kilo engine if they try and import them. | 16:41 |
docaedo | I thought this all came up because liberty version of murano needed different app packages? If it doesn't, and if it's possible to just move ahead with everything as-is sounds like maybe we don't have a problem? | 16:41 |
kfox1111 | liberty versions of the packages have extra fetures, that only work with liberty. | 16:42 |
kfox1111 | so if we don't have a seperate repo for those packages, the only other option is only keep the kilo versions of the packages and not accept the liberty versions. | 16:42 |
docaedo | right, so as long as murano people only upload liberty packages with NEW names, and categorize them properly in the catalog, sounds like no problem | 16:42 |
docaedo | we can keep both, they just have "liberty only" versions, with new/different names | 16:42 |
kfox1111 | but new names wont work. they'd have to rename everything I think. | 16:42 |
kfox1111 | which is a lot of work. :/ | 16:43 |
docaedo | no new names would work | 16:43 |
kzaitsev_mb | wait, I thought we settled on having a separate /liberty directory and redirect there as needed, or am I wrong? | 16:43 |
docaedo | kzaitsev_mb: we are OK with that, but Murano has to be OK with that too | 16:43 |
kfox1111 | kzaitsev_mb: yes. thats the current, workable solution. | 16:43 |
docaedo | i.e. app catalog will not detect murano versions, so murano has to include that URL ... if that's the accepted solution then I think we are mostly fine? | 16:44 |
kfox1111 | docaedo: yes. | 16:44 |
docaedo | (oh though we have extra administrative work I guess on accepting those liberty packages and putting them in the right place...) | 16:44 |
kfox1111 | docaedo: correct. | 16:44 |
kzaitsev_mb | yep. I'll ping Serg to have him answer the letter | 16:45 |
kfox1111 | thought that adminstrative work can go away once we figure out versioning, and update the url to honor it. | 16:45 |
docaedo | correct, administrative effort will go away when we have versions and logic to handle it :) | 16:45 |
kzaitsev_mb | he must be travveling now and during this weekend, I guess | 16:45 |
kzaitsev_mb | just to make sure, I understand everything correctly | 16:46 |
kzaitsev_mb | We're going to put new packages into /liberty directory on storage.apps.openstack.org and add a script, that would fetch yaml and redirect to either storage.apps.openstack.org or storage.apps.openstack.org/liberty right? | 16:47 |
kzaitsev_mb | and the script would live under http://apps.openstack.org/api/v1/murano_repo/liberty/ | 16:48 |
kfox1111 | yeah. | 16:48 |
kfox1111 | and murano liberty should use that script as the base repo url so the script can hand back the right files. | 16:48 |
docaedo | I don't think there's even a script necessary TBH | 16:49 |
kfox1111 | yes/no. | 16:49 |
docaedo | Murano client doesn't do anything other than take in a package name, and then append that name to storage.apps.openstack.org | 16:49 |
kfox1111 | its not required if you copied every package from kilo -> /liberty. | 16:49 |
kzaitsev_mb | yep. still like the idea. seems to be minimal impact for both sides. | 16:50 |
kfox1111 | it would be required if you wanted only liberty packages in /liberty, and have it fall back gracefully to the kilo version if a liberty version didn't exist, making administration easier. | 16:50 |
docaedo | for for Liberty version, if Murano repo URL was just set to storage.apps.openstack.org/liberty (and we just copy the packages there), then for liberty, problems basically solved | 16:50 |
kfox1111 | correct. | 16:50 |
kfox1111 | wait.. no. | 16:50 |
kfox1111 | we don't want them pinting to storage.apps.openstack.org/liberty directly. | 16:51 |
kfox1111 | because we can't put a script there ever. | 16:51 |
kfox1111 | so we would have to manually copy files in there forever. | 16:51 |
kzaitsev_mb | kfox1111: nobody said that ) | 16:51 |
kfox1111 | 12:50 < docaedo> for for Liberty version, if Murano repo URL was just set to storage.apps.openstack.org/liberty (and we just copy the packages there), then for liberty, problems basically solved | 16:51 |
docaedo | kzaitsev_mb: that's what I just said though - proposing something that would only work for liberty version | 16:51 |
kzaitsev_mb | oh, right | 16:52 |
docaedo | so my only question then: | 16:52 |
kfox1111 | I'd like a script in front just so that we can update logic later if we think its important. | 16:52 |
kfox1111 | we tie our hands forever if we don't have the script in front. | 16:52 |
kfox1111 | and forever's a long time. | 16:52 |
kzaitsev_mb | =) | 16:52 |
docaedo | does murano client handle a redirect gracefully when trying to fetch a package? I.e. it asks for the package from apps.openstack.org/api/blah but then is told to go get it from <new URI> | 16:52 |
kfox1111 | it should. if not, we should fix that at the same time. | 16:53 |
docaedo | as long as murano client handles the redirect AOK, I'm good with this approach | 16:53 |
kzaitsev_mb | I'll check that. should be ok | 16:53 |
kfox1111 | usually its just a libcurl flag to set. or something equivalant. | 16:53 |
kzaitsev_mb | and if it doesn't there's still time to have that in L | 16:53 |
docaedo | and for this next cycle, seriously, murano folk need to communicate on IRC and on the mailing list if they want the M release to work nicely with murano :) | 16:54 |
kzaitsev_mb | agree on that one | 16:54 |
docaedo | I mean M release of murano to work nicely with app catalog | 16:54 |
docaedo | As far as I can tell, we are on the same page here then - go team! | 16:55 |
kfox1111 | yup. I still think the proposed solution is the cleanest that can be implemented for liberty and we then buy time to fix things right for M. | 16:55 |
kfox1111 | +1 for greater communication in the future too. | 16:56 |
kfox1111 | Since the app catalog spawned from Murano in a way, there is some murano specific api that was just grandfathered in and there was no formal specification of it. | 16:57 |
kfox1111 | storage.apps.openstack.org/ | 16:57 |
kfox1111 | going forward, we need to ensure our api's are documented and agreed apon. since we will have to support them for a long time. | 16:58 |
docaedo | kfox1111: you are correct about that. while I was helping before this thing even launched, the ties between the catalog and murano client were not clear and kind of frustratingly, were not discussed :) | 16:58 |
kfox1111 | also, our api's meet the needs of those using the catalog. | 16:58 |
docaedo | +1 on documenting clearly all the API stuff, and being crystal clear with everyone else on how they can add things to and consume things from the catalog | 16:58 |
kfox1111 | long term, we shuld have our api on http://developer.openstack.org/api-ref.html | 16:59 |
kfox1111 | should. | 16:59 |
kfox1111 | ... | 17:00 |
* kfox1111 files a blueprint... | 17:00 | |
docaedo | yes! | 17:01 |
kfox1111 | https://blueprints.launchpad.net/app-catalog/+spec/v1-api-docs | 17:02 |
kfox1111 | two parts to that. 1, figure out where to put it/how to format it so that it shows up at http://developer.openstack.org/api-ref.html | 17:03 |
kfox1111 | and 2, write the content. | 17:03 |
kfox1111 | kzaitsev_mb: on second thought, can you please do put up the murano_repo_url patch? Just to get it going? | 17:05 |
kzaitsev_mb | sure | 17:05 |
kfox1111 | shouldn't hurt to have it in review while they discuss other options. | 17:05 |
docaedo | +1 | 17:05 |
*** kebray has quit IRC | 17:06 | |
kzaitsev_mb | done. there has to be one more thing to do in the dashboard commit, I'll have to do a bit later. | 17:16 |
kfox1111 | whats that? | 17:16 |
kzaitsev_mb | it actually uses the REPO_URL for displaying, so I'll have to add some parsing there | 17:16 |
kfox1111 | ah. ok. | 17:16 |
kfox1111 | thanks. | 17:18 |
kzaitsev_mb | https://review.openstack.org/#/q/status:open+branch:master+topic:update_repo_url,n,z | 17:18 |
kfox1111 | just curious, why set the default in so many places? | 17:20 |
kzaitsev_mb | CLI and dashboard | 17:20 |
kfox1111 | does the dashboard not use the cli? | 17:20 |
kfox1111 | python module. | 17:21 |
kzaitsev_mb | it does, but does horizon respect OS_TENANT_NAME? | 17:21 |
kzaitsev_mb | it doesn't use the CLI per se, just the library | 17:21 |
kfox1111 | was just thinking, if you passed it as None through horizon, then have the client use default if not set. it would only be in one place. | 17:22 |
kfox1111 | but if not none, in local_settings, then it would pass all the way through. | 17:22 |
kzaitsev_mb | kfox1111: setting env variables for a process, that runs horizon seems like too much hassle, and I'm not sure if I saw any horizon module do that | 17:24 |
kzaitsev_mb | might be wrong though | 17:24 |
kfox1111 | wait... its setting env vars? | 17:24 |
kfox1111 | let me look through the code closer... | 17:24 |
kzaitsev_mb | CLI defautls to env var | 17:24 |
kzaitsev_mb | dashboard[C to horizon setting | 17:25 |
kfox1111 | I see.. this code's not doing wha | 17:27 |
kfox1111 | well... | 17:28 |
kzaitsev_mb | kfox1111: you might be right, that it might be better to set it once in the client | 17:29 |
kfox1111 | wait... | 17:32 |
kfox1111 | v1/client.py | 17:33 |
kfox1111 | artifacts_client... | 17:33 |
kfox1111 | it has a ArtifactRepo branch for pulling packages now... | 17:34 |
kfox1111 | is that the glance artifact repo? | 17:34 |
kfox1111 | will this break with glance artifacts and the app-catalog both enabled? | 17:34 |
kzaitsev_mb | yep. it's experimental now. And it's for different kind of pulling | 17:34 |
kzaitsev_mb | no | 17:34 |
kfox1111 | ah. ok. | 17:35 |
kzaitsev_mb | it's the type storage for apps, installed in murano. | 17:35 |
kfox1111 | ah. | 17:35 |
kfox1111 | just was seeing it creating package objects that then have download members. | 17:36 |
kfox1111 | download seems to be from murano though... | 17:36 |
kfox1111 | ok. the murano client and horizon don't share code for interacting with the app-catalog. | 17:39 |
kfox1111 | v1/shell.py:def do_package_import(mc, args) | 17:40 |
kzaitsev_mb | you're right on that one | 17:40 |
kfox1111 | ok. then your other patches are pretty optimal at this point then. it would be a large refactoring to make it cleaner. | 17:40 |
kzaitsev_mb | I really hope we'll have some API in app-catalog, That I would later be able to integrate somewhere in muranoclient | 17:41 |
kfox1111 | +1. | 17:41 |
*** kzaitsev_mb has quit IRC | 17:55 | |
*** kebray has joined #openstack-app-catalog | 18:33 | |
*** kebray has quit IRC | 18:35 | |
*** kebray has joined #openstack-app-catalog | 18:45 | |
*** kebray has quit IRC | 18:45 | |
*** kebray has joined #openstack-app-catalog | 18:46 | |
*** openstackgerrit has quit IRC | 22:46 | |
*** openstackgerrit has joined #openstack-app-catalog | 22:46 | |
*** kebray has quit IRC | 23:09 | |
*** kzaitsev_mb has joined #openstack-app-catalog | 23:09 | |
kfox1111 | https://review.openstack.org/#/c/219809/ seems stalled... | 23:19 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!