| docaedo | interesting - I saw something else about kubespray last week, kargo I think. .. looks great | 00:05 |
|---|---|---|
| kfox1111 | totally should figure out how to cross pollinate with them or something like that. | 00:06 |
| docaedo | it's the kind of thing I'd be inclined to use on top of an openstack cloud TBH - but wonder how solid it is, or if it's mainly just a wrapper for the kubernetes core stuff | 00:06 |
| kfox1111 | its an app catalog and a templating engine on top of kubernetes yaml. | 00:07 |
| kfox1111 | to make it generic enough to share the templates. | 00:07 |
| kfox1111 | same issue as heat. :/ | 00:07 |
| kfox1111 | for users, its too hard to do.... | 00:07 |
| kfox1111 | step 1, launch a kubernetes cluster in the dashboard. | 00:08 |
| kfox1111 | step 2. download credentials | 00:08 |
| kfox1111 | step 3. load them into kubernetes cli. | 00:08 |
| kfox1111 | step 4, install kpm | 00:08 |
| docaedo | is it an app catalog? thought you just named docker containers? | 00:08 |
| kfox1111 | step 5, figure out cli to search and lauch thingy. | 00:08 |
| kfox1111 | what would be awesome, is if we chould show their entries in the app catalog in horizon, | 00:09 |
| kfox1111 | and when you click "Launch" it pokes kpm to do the rest. :) | 00:09 |
| kfox1111 | nice, seamless, the user doesn't even know its kubernetes instead of a vm. | 00:09 |
| kfox1111 | thats the way the cloud should work. | 00:09 |
| kfox1111 | the catalog piece is here: https://kpm.kubespray.io/#/home | 00:10 |
| docaedo | OK got it .. I like their deploy a k8s cluster with ansible: https://docs.kubespray.io/ | 00:11 |
| kfox1111 | it seems to do the right thing with deps and templates too. for example, see: https://kpm.kubespray.io/#/package/ant31/k8s-elk | 00:11 |
| kfox1111 | want a scalable elk? bam. there it is. :) | 00:12 |
| kfox1111 | nice... gota play with that. | 00:12 |
| docaedo | from the user perspective you don't need openstack to do anything other than provide the IaaS stuff - give kubespray CLI your openstack creds and you're done | 00:13 |
| kfox1111 | yeah. pretty cool. | 00:14 |
| kfox1111 | not as nice as magnum when in openstack, but definately something to consider when not in openstack. | 00:14 |
| docaedo | I hadn't looked at KPM yet, but bookmarked kargo for looking at later | 00:14 |
| docaedo | Unless I only have access to an openstack cloud though (as a user), I'm better off using this over magnum, since I can use it way more places | 00:15 |
| kfox1111 | this is probably one of those cases where we try and extend our api to query theirs. | 00:15 |
| kfox1111 | we then just pass through a new type of 'kpm' for it. | 00:16 |
| docaedo | sure, hopefully their API access is licensed to support that model | 00:16 |
| kfox1111 | yeah. we'd have to discuss it with them. | 00:17 |
| kfox1111 | but I'd think anything that would increase their number of users would make them happy. | 00:17 |
| docaedo | yeah though it seems like consuming these things via horizon or app catalog would be pretty cumbersome.. requires the user to go away and install things so their environment has this, and then circle back to the app catalog | 00:19 |
| docaedo | (at which point coming back to the app catalog to find the things to run doesn't make any sense) | 00:19 |
| kfox1111 | same's true of any openstack service really. | 00:19 |
| kfox1111 | hopefully the resources showing up to app catalog users, and them passing the request for support to their operators would get the nessisary bits installed. | 00:20 |
| docaedo | not at all - if I need murano or heat, it's something an operator supplies so it's part of the cloud already | 00:20 |
| kfox1111 | same could be done for the magnum glue to things like kpm. | 00:20 |
| kfox1111 | or passing a package name off to murano. | 00:20 |
| kfox1111 | here magnum, the user wants one of these. start the workflow. | 00:21 |
| docaedo | but I'm saying from end user who is not an operator, they don't have to touch that stuff, they just use the service | 00:21 |
| docaedo | ah ok you're saying if Magnum happened to adopt this | 00:21 |
| docaedo | yes, if that were the case, would be the same thing | 00:21 |
| kfox1111 | yeah. | 00:21 |
| kfox1111 | or murano if magnum won't. | 00:21 |
| kfox1111 | seems to be something murano does to support the app workflow. :/ | 00:22 |
| docaedo | murano -> heat -> ansible -> kubernetes | 00:22 |
| docaedo | yuck! | 00:22 |
| kfox1111 | murano -> kpm -> kubernetes. | 00:22 |
| kfox1111 | or magnum -> kpm -> kubernetes | 00:22 |
| kfox1111 | well, horzion -> app catalog -> magnum -> kpm -> kubernetes -> proffit! :) | 00:23 |
| docaedo | but murano AFAIK uses heat to actually deploy the things (but yeah, murano can give you a kubernetes cluster) | 00:23 |
| docaedo | ok I'm out, dinner time - talk to you later on :) | 00:23 |
| kfox1111 | l8r | 00:23 |
| *** pvaneck has quit IRC | 01:09 | |
| *** kzaitsev_mb has quit IRC | 01:24 | |
| openstackgerrit | Kevin Fox proposed openstack/app-catalog-common: Add support for displaying TOSCA templates. https://review.openstack.org/304366 | 02:44 |
| *** toddjohn has joined #openstack-app-catalog | 02:50 | |
| *** toddjohn has quit IRC | 02:55 | |
| *** toddjohn has joined #openstack-app-catalog | 02:56 | |
| *** toddjohn has quit IRC | 03:26 | |
| *** toddjohn has joined #openstack-app-catalog | 03:26 | |
| *** toddjohn has quit IRC | 03:31 | |
| *** ssearles has joined #openstack-app-catalog | 03:47 | |
| ssearles | anyone around? | 03:48 |
| *** ssearles has left #openstack-app-catalog | 03:49 | |
| openstackgerrit | Kevin Fox proposed openstack/app-catalog: Additional check https://review.openstack.org/304379 | 03:52 |
| *** ssearles has joined #openstack-app-catalog | 03:53 | |
| ssearles | Anyone around that can give me a hand with this issue I am seeing on install? | 03:54 |
| ssearles | x86_64-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DEXT_MODULE=_rcssmin -UEXT_PACKAGE -I_setup/include -I/usr/include/python2.7 -c rcssmin.c -o build/temp.linux-x86_64-2.7/rcssmin.o | 03:54 |
| ssearles | In file included from rcssmin.c:18:0: | 03:54 |
| ssearles | _setup/include/cext.h:34:20: fatal error: Python.h: No such file or directory | 03:54 |
| ssearles | #include "Python.h" | 03:54 |
| ssearles | ^ | 03:54 |
| ssearles | compilation terminated. | 03:54 |
| ssearles | Obviously Python.h is missing but I am not seeing what dependency it should be coming from? | 03:56 |
| ssearles | nevermind stupid move on my end, | 03:59 |
| ssearles | python-dev header files and static libs were missing on this node. Dumb mistake. | 04:00 |
| *** ssearles has quit IRC | 04:12 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 07:55 | |
| *** kzaitsev_mb has quit IRC | 08:29 | |
| *** toddjohn has joined #openstack-app-catalog | 08:37 | |
| *** toddjohn has quit IRC | 08:41 | |
| *** openstackgerrit has quit IRC | 09:17 | |
| *** openstackgerrit has joined #openstack-app-catalog | 09:18 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 09:27 | |
| *** kzaitsev_mb has quit IRC | 09:47 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 09:51 | |
| *** openstack has joined #openstack-app-catalog | 10:01 | |
| *** kzaitsev_mb has quit IRC | 11:57 | |
| *** openstack has quit IRC | 12:04 | |
| *** openstack has joined #openstack-app-catalog | 12:07 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 12:29 | |
| *** toddjohn has joined #openstack-app-catalog | 12:34 | |
| *** toddjohn has quit IRC | 13:05 | |
| *** toddjohn has joined #openstack-app-catalog | 13:44 | |
| *** jhesketh has left #openstack-app-catalog | 13:53 | |
| *** spzala has joined #openstack-app-catalog | 14:01 | |
| openstackgerrit | Kevin Fox proposed openstack/app-catalog: WIP - Pythonserver cleanup #1 https://review.openstack.org/239560 | 14:19 |
| *** rhagarty__ has quit IRC | 14:34 | |
| *** rhagarty has joined #openstack-app-catalog | 14:39 | |
| *** kzaitsev_mb has quit IRC | 14:45 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 14:52 | |
| *** openstackgerrit has quit IRC | 15:18 | |
| *** openstackgerrit has joined #openstack-app-catalog | 15:18 | |
| *** toddjohn has quit IRC | 16:11 | |
| *** kzaitsev_mb has quit IRC | 16:38 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 16:47 | |
| openstackgerrit | Merged openstack/app-catalog: Added Hyperglance app to the Marketplace. https://review.openstack.org/301026 | 16:52 |
| *** kebray has joined #openstack-app-catalog | 16:57 | |
| kfox1111 | fascinating... | 17:10 |
| kfox1111 | the user survey report mentions almost a 3rd of the respondants were app developers. | 17:11 |
| kfox1111 | But we've seen very little contributions. which does point to either a technical or cultural issue. | 17:11 |
| kzaitsev_mb | might it be that these app developers are developing highly specific apps? | 17:12 |
| kzaitsev_mb | or are bound with licensing policies for sharing those? | 17:12 |
| kfox1111 | I still believe its a technical problem with not having enough ability to write the apps genericly, but its been hard to dig up numbers. | 17:13 |
| kzaitsev_mb | although to suggest that everyone falls in either of 2 groups is a bit exaggerating I guess | 17:13 |
| kfox1111 | just general feeling from when I've tried to make things more generic. | 17:13 |
| kfox1111 | yeah. | 17:13 |
| kfox1111 | I think though, seeing how quickly things have been docker containerized, that some of it for sure is openstack technical related. | 17:14 |
| docaedo | I'd love to get more details on that "app developer" thing too - TBH anyone who is trying to use an openstack cloud to run something can consider themselves an app developer (from the OpenStack perspective) | 17:16 |
| docaedo | the thing I wonder is if those are people developing apps that they would ever want to share, vs. making their private thing run on an openstack cloud | 17:17 |
| kfox1111 | I think that's part of the problem. nova and friends consider that to be an absolute. "users *MUST* be an app developer" | 17:19 |
| kfox1111 | I think that assumption is holding openstack back. | 17:19 |
| kfox1111 | I don't begrudge folks that want to be. I'm in that boat too. I develop and launch on my own clouds. but I want to share with those who aren't. | 17:19 |
| docaedo | What I see the most is that within OpenStack everyone sees a developer as somone who develops some component of OpenStack. | 17:20 |
| docaedo | But look at AWS, Azure, GCE - people who "develop" on those clouds have zero knowledge of the underpinnings | 17:20 |
| docaedo | they are offered API endpoints, and various SDKs that make use of the infrastructure underneath | 17:21 |
| kfox1111 | true. | 17:21 |
| docaedo | but we in OpenStack expect an app developer to be very familiar with all the internals, and have to sort out how to connect all the pieces | 17:21 |
| kfox1111 | yeah. I'm hoping the openstack sdk help with that too, but with all the use case gaping holes, | 17:22 |
| docaedo | also - none of those clouds have app stores, because they're not single platforms (like the android app store, that makes sense) .. which maybe means the OpenStack App Store doesn't make sense unless there's a unified way to package/deploy/use an openstack app | 17:22 |
| kfox1111 | you really really need to know the internals to try and work around the lack of needed features. :/ | 17:22 |
| kfox1111 | Yeah, I'm a little puzzled why aws and azure don't. | 17:23 |
| kfox1111 | it would help lock more users in, so it would make sense for amazon or microsoft to try it. | 17:23 |
| docaedo | because they're just trying to solve the IaaS layer mainly, and it's a whole new business (look at bitnami), you spend a TON of resources just keeping a single app up to date and supported | 17:24 |
| docaedo | so your effort (team) scales almost linearly with the number of apps you're going to support | 17:24 |
| kfox1111 | but that's the wrong aproach. amazon, microsoft and google already know how to do scalable app stores. you make the people putting in the content do all the work. | 17:25 |
| kfox1111 | and encurage the growth of the echosystem to allow it. | 17:26 |
| docaedo | I can't think of apps where that approach makes more sense (open source onces anyway) vs. just offering an installer that works on any platform, and letting people hire you for support | 17:27 |
| docaedo | Like http://phabricator.org/ - the closest thing that would make sense for app catalog would be to have an installer that helps you get it up and running, but from their perspective, that would be one more thing to take care of (and probably one installation/package system for each cloud) | 17:29 |
| kfox1111 | ok, say you want to host your own confluence site... but want it in a public cloud for a better price or something. | 17:29 |
| kfox1111 | you trust amazon more then you trust the company behind it to host the physical resource. | 17:30 |
| kfox1111 | so you go into the amazon app store, find confluence, click buy, enter a credit card, and bamn, you get one. | 17:30 |
| kfox1111 | the company gets the money for the software. amazon gets the money for the resources consumed, the end user gets a site. | 17:30 |
| docaedo | maybe, but in this case why would atlassian spend any time making that easy? maybe I'm nit picking that choice (becuase they would rather host it for you) | 17:30 |
| kfox1111 | everyone wins. | 17:30 |
| kfox1111 | yeah, but again, I may have an arangement with the secruity folks to allow a private vpn to the aws cloud. | 17:31 |
| kfox1111 | random one off companies, not so much. | 17:31 |
| kfox1111 | its in their best interest to gain more customers. and once they have them, then theirs a potential path to convince them to go to atlassian's service. | 17:32 |
| docaedo | I agree that it's in their best interest to get more customers, but the more installation packages and platforms you have to support comes at a cost, vs. simple "host with us, or read the install docs and host somewhere else" | 17:33 |
| kfox1111 | yeah, thats the software as a service vs not argument. | 17:33 |
| docaedo | we DO see some app vendors wanting their stuff in the app catalog for the exposure at least | 17:33 |
| kfox1111 | I think the latter will still be very common for a while. | 17:33 |
| docaedo | and so far 100% of them offer thier app as a glance image | 17:34 |
| kfox1111 | yeah. :/ | 17:34 |
| docaedo | (because that's the only real way to "package" an app for an OpenStack cloud right now) | 17:34 |
| kfox1111 | which is generally really hard to call an app. | 17:34 |
| kfox1111 | its a ball of stuff that can be used to stand up an app. but its usually not cloud scaled but just a pet. | 17:34 |
| kfox1111 | :/ | 17:34 |
| docaedo | sure, but can you point to an example of a cloud-scaled application available in a marketplace (for any cloud) that works the way you're talking? | 17:35 |
| kfox1111 | the problem is, writing a template that's generic enough to be cloud sclaed can't really be written, becuase secrets and things have no place yet. :/ | 17:35 |
| docaedo | I think that's one problem of a great many | 17:35 |
| kfox1111 | chef had some interesting ones. | 17:35 |
| kfox1111 | our version is a gutted version of the amazon one, since amazon has instance users and we dont. | 17:36 |
| kfox1111 | so we can't do HA setups. :/ | 17:36 |
| docaedo | but also, amazon has one cloud, openstack is a set of tools to build your own cloud any way you want | 17:36 |
| kfox1111 | there's would move the ebs volume with the state between the two ha nodes on failure using pacemaker and an instance user set. | 17:36 |
| docaedo | sure, with amazon you know you have access to EBS. with Openstack you can't even be guaranteed cinder, let alone a fault tolerant one | 17:37 |
| docaedo | and the networking .. wheee! | 17:37 |
| kfox1111 | I still think thats a point of view thing. I still believe openstack is an os. so is aws and azure. | 17:37 |
| kfox1111 | agreed. | 17:37 |
| kfox1111 | and that's what defcore's supposed to be about. | 17:37 |
| kfox1111 | but they are really catering to the lowest common denominator, rather then try and further the app developer use case and force the bar up slowly. | 17:38 |
| kfox1111 | so, unlike aws or azure, our os is fractured, like the unicies. | 17:38 |
| kfox1111 | so its harder as an app developer to target "unix". | 17:39 |
| kfox1111 | openstack. | 17:39 |
| kfox1111 | defcore's ending up as the same thing as posix. | 17:39 |
| docaedo | on that point (the fractured difference) I don't think it could ever be solved because of the nature of openstack. It's ALWAYS going to be shifting and changing | 17:39 |
| kfox1111 | a standard layer thats bare minimum agreement between all the parties, but not terribly useful to app developers. :/ | 17:40 |
| docaedo | so effort is better spent (from app dev perspective) on assuming the minimal from OpenStack (can I have a VM with some storage and networking?) | 17:40 |
| docaedo | then use something one layer up (ansible, swarm, whatever) to build and manage your app | 17:40 |
| kfox1111 | no, while there will always be some fracturing, there are counter examples in the opensource community of antifracturing. | 17:40 |
| kfox1111 | the linux kernel for example. the linux distro's are all much more similar to each other, then the unicies to each other. | 17:40 |
| docaedo | I agree there are, but openstack specifically is always going to lean towards flexibility for the deployer so clouds can all be as different as people want | 17:41 |
| kfox1111 | because of focus on not forking. | 17:41 |
| kfox1111 | Yeah. I'm ok with that. but I want linux, not unix at minimum. we're pretty far from that currnely. :/ | 17:41 |
| kfox1111 | though the neutron stuff is finally getting better. | 17:41 |
| docaedo | benevolent dictator :) | 17:41 |
| docaedo | that's why linux kernel doesn't fork | 17:41 |
| kfox1111 | at bare minumum we need conditionals so we can write generic ttemplates that handle multiple differences. we dont even have that! :/ | 17:42 |
| kfox1111 | yeah, linus is part of the solution. | 17:42 |
| kfox1111 | license is part of it, | 17:42 |
| kfox1111 | and a general push to educate folks that its better long run for everyone if we all work together on the same solution then fork. | 17:43 |
| kfox1111 | the android fork has been a long time fork, but its still getting merged back. | 17:43 |
| kfox1111 | its almost there. | 17:44 |
| kfox1111 | but.... linus realizes that the importance of a stable, long term, supported api is perimount. | 17:44 |
| kfox1111 | openstack, not so much. :/ | 17:44 |
| docaedo | because openstack foundation is driven by $$$ | 17:45 |
| kfox1111 | and the api can't be too sparse. he's willing to add api when needed then trying to be cs pure, like implementing microkernels and such. | 17:45 |
| kfox1111 | yeah, in part. I think the other part is the projects don't believe the api needs to be stable, since "openstack is not an os". | 17:45 |
| kfox1111 | because they don't believe non developer users are users. | 17:46 |
| docaedo | thats true, there seems to be a big disconnect between the working groups and openstack developers (like the thread about rolling upgrades, and how there's a WG that wants rolling upgrades and lots of devs saying "yep, that'd be nice") | 17:47 |
| kfox1111 | yeah. | 17:47 |
| kfox1111 | I'm grumpy about the instance user thing still. the nova ptl is not attending. | 17:47 |
| kfox1111 | an no nova representitive has yet stepped up to go. he said he'd ask at the next meeting. :/ | 17:48 |
| kfox1111 | I'm torn between still having it and just pushing forward anyway, and just giving up for another 6 months. :/ | 17:48 |
| docaedo | well the solution to that instances users problem is to move up the stack, don't count on OpenStack to supply every possible tool, but that's not going to further your "see it as an OS" plans in any useful way | 17:49 |
| docaedo | mainly it's saying "don't expect Heat to do your scaling" | 17:49 |
| kfox1111 | but the app catalog needs it, and we are openstack. | 17:49 |
| kfox1111 | thats a problem. | 17:49 |
| docaedo | I disagree that we need it. It could help, but it's not an absolute necessity | 17:49 |
| kfox1111 | try writing some cloud scaled apps. :/ | 17:50 |
| docaedo | sure, today, I'd use ansible for that | 17:50 |
| docaedo | or kubernetes | 17:50 |
| kfox1111 | yeah. so why bother with the app catalog? | 17:51 |
| kfox1111 | so openstack's just a iaas thingy you use to setup your real cluster, kubernetes or ssh cluster, | 17:51 |
| kfox1111 | and ansible's your tool or kubectl. | 17:51 |
| kfox1111 | openstack really doesn't matter then. | 17:51 |
| docaedo | Not sure TBH, I want the catalog to be useful and relevant, but I also want to choose a path that is possible. So far, heat and instances users feels like a dead end, | 17:51 |
| kfox1111 | yeah. I'm with you there. | 17:52 |
| docaedo | but that iaas thingy is THE HEART of OpenStack | 17:52 |
| docaedo | and if that's not rock solid | 17:52 |
| docaedo | then bolting on 50 extra projects on top of it to do every little fiddly extra thing is not going to help OpenStack win as the IaaS of choice for open clouds around the world | 17:52 |
| docaedo | to be clear - I think if heat was working awesome all the time and instance users allowed heat to do basically everything for you, that would be AWESOME | 17:53 |
| kfox1111 | yeah. | 17:54 |
| docaedo | so I'm fully in support of those efforts, but it's pretty discouraging to see people agree that those things need to be fixed/implemented but then the cores are .. not interested | 17:54 |
| kfox1111 | but stability of neutron for example shouldn't hold back writing features for nova. | 17:54 |
| *** pvaneck has joined #openstack-app-catalog | 17:54 | |
| docaedo | completely agree | 17:55 |
| kfox1111 | when a developer steps up to actually implement the danged thing. multiple times. :/ | 17:55 |
| kfox1111 | the cores shouldn't block it. | 17:55 |
| kfox1111 | grr.. :) | 17:55 |
| *** toddjohn has joined #openstack-app-catalog | 17:56 | |
| docaedo | yeah the thing I'm bummed about is that the more splinter groups I get involved with, the more I realize they're not tracking on OpenStack as a whole and are generally unfamiliar with how the pieces fit together | 17:57 |
| kfox1111 | yeah. they are very very silo'd. | 17:57 |
| kfox1111 | the barbican guys were very shocked a few summits ago when I mentioned that the project was basically unusable to most folks. | 17:58 |
| kfox1111 | "but, we have an api" | 17:58 |
| docaedo | haha | 17:58 |
| kfox1111 | yeah. but no credentials to get stuff out.... | 17:58 |
| kfox1111 | I'm not giving my pnnl credentials to vm's. my account has way too much power. | 17:59 |
| kfox1111 | keystone trusts are still way too corse grained too. | 18:00 |
| kfox1111 | I want to give a trust for a resource, not a tenant/role. | 18:00 |
| kfox1111 | This user can manipulate cinder volume foo. but can't touch baz. | 18:00 |
| kfox1111 | aws can do it. we cant. :/ | 18:00 |
| kfox1111 | they've been able to do it for years. :/ | 18:00 |
| kfox1111 | but they are focused on the end use cases, as a whole that their users care about. | 18:01 |
| kfox1111 | not per project. | 18:01 |
| docaedo | I thought you could define pretty fine-grained stuff with RBAC in keystone though (but without any useful UI or anything) | 18:01 |
| kfox1111 | I don't think so. | 18:01 |
| kfox1111 | if you find a way, please let me know. :) | 18:01 |
| docaedo | http://docs.openstack.org/developer/keystone/configuration.html#keystone-api-protection-with-role-based-access-control-rbac | 18:02 |
| docaedo | far cry from what you get with relative ease on AWS | 18:03 |
| docaedo | and it's operator driven, so this ONLY works on a cloud you already have full access to | 18:03 |
| kfox1111 | ah, yeah, no. thats per api thingy, not per resource. | 18:03 |
| kfox1111 | and yeah, the operator thing is true, but kind of. | 18:03 |
| kfox1111 | I'm terrified of tweaking the policies, because if I do, then I have to forward port policis on upgrades. | 18:04 |
| kfox1111 | and a bug in that forward porting effort is called a security breach. :/ | 18:04 |
| kfox1111 | so ops tend not to tweak them. :/ | 18:04 |
| docaedo | yeah it's not workable | 18:04 |
| kfox1111 | and some of the basic roles they have are sucky. | 18:04 |
| kfox1111 | why is there not a role for read only status monitoring, so you can easily plug in nagios? | 18:05 |
| kfox1111 | today, you have to give your monitoring system the power to destroy everything in order to monitor, or beg your op to setup some policy rules, and then see previous conversation. :/ | 18:05 |
| kfox1111 | being an app developer on openstack really really sucks. :/ | 18:06 |
| *** kzaitsev_mb has quit IRC | 18:06 | |
| kfox1111 | to be fair, not having it sucks a bit more. :) | 18:06 |
| docaedo | trut | 18:06 |
| kfox1111 | still, sand off a few really sharp edges and it can be sooooo much better. | 18:06 |
| docaedo | *true | 18:06 |
| kfox1111 | sadly, kubernes gets it. openstack doesnt. | 18:07 |
| docaedo | https://github.com/openstack/openstack-user-stories/blob/master/user-stories/proposed/rolebasedaccess.rst | 18:08 |
| kfox1111 | if kubernetes gains multitenancy, openstack's going to nich itself really tightly into a corner. :/ | 18:08 |
| docaedo | I wouldn't say that | 18:08 |
| docaedo | (on a logged channel that is ;) ) | 18:08 |
| kfox1111 | yeah. that's ayoung's baby. and he was getting push back the same way instance users have. | 18:08 |
| kfox1111 | I sat in on one of the summit sessions. I saw the same frustration. :/ | 18:09 |
| kfox1111 | the feature is about non direct usage of the silo though, so it doesn't get the attention it needs. | 18:10 |
| kfox1111 | they need to address the issues, or kubernetes will win the general user population, because it is addressing the issues. | 18:11 |
| *** kebray has quit IRC | 18:11 | |
| kfox1111 | kube's got a barbican like feature built in and works out of the box. | 18:11 |
| kfox1111 | secrets to containers just works. | 18:11 |
| kfox1111 | secrets to vm's in openstack? not a thing... | 18:11 |
| kfox1111 | people tend to flock to whatever's easiest. | 18:12 |
| kfox1111 | kube also seems to get one other thing right. | 18:13 |
| kfox1111 | the more advanced kube services deploy with kube itself as containers. | 18:13 |
| kfox1111 | so if you can get teh core installed/working, you can do a lot of the hard heavy lifting with the same tool. | 18:13 |
| docaedo | yeah there is a LOT of stuff done right with kubernetes | 18:13 |
| kfox1111 | tripleo's kind of the same aproach, but hamstrung by the other silo's. | 18:14 |
| kfox1111 | the unified kube team really helps. | 18:14 |
| kfox1111 | I think long term, if tripeo adopted ironic for bare metal deployment and magnum to deploy kubernetes, then have overcloud deployment stuff on kubernetes. | 18:15 |
| kfox1111 | then you can deploy a cloud completely from bare metal, or if you have an existing kubernetes, just deploy on that. | 18:16 |
| kfox1111 | and I'd like to see the other advanced services layer modularly on top. | 18:16 |
| kfox1111 | use redhat or something to provide the base cloud, and the cloud itself to deploy sahara or murano. | 18:17 |
| kfox1111 | there's no reason that stuff has to be distro specfic. | 18:17 |
| docaedo | agreed on that | 18:17 |
| kfox1111 | triplo could provide those templates. and we could host them. but its pretty monolithic at the moment. :/ | 18:17 |
| kfox1111 | I think their split template spec though is a first step in that direction. which I really like. | 18:18 |
| kfox1111 | wow... | 18:24 |
| kfox1111 | there are still essex clouds out there... | 18:24 |
| kfox1111 | like, at least 3... | 18:24 |
| kfox1111 | well, assuming they didn't round up to 1%. :) | 18:24 |
| kfox1111 | interesting.... so the majority of clouds are staying one release back. | 18:25 |
| kfox1111 | so for the app catalog, we want to definitely target that. | 18:26 |
| kfox1111 | 2 back is much better. | 18:26 |
| docaedo | but the index of things shouldn't care as long as contributors are able to note which versions their asset will work with (when the asset is limited like that) | 18:28 |
| kfox1111 | heat's made some progress, but still lower then I'd like. :/ | 18:28 |
| kfox1111 | yeah, but again, the problem I come up with time and time again is to make it generic, I need just that one extra feature, that heat just implemented.... | 18:28 |
| kfox1111 | so my templates get more and more generic, but push out more and more to which version they need. :/ | 18:28 |
| docaedo | sure but I definitely dont want to see heat issues influence the app catalog unless there's heat content | 18:29 |
| kfox1111 | neutron's finally gaing a fair amount of ground. | 18:29 |
| docaedo | and there's nothing useful in there for heat right now, nor have I seen any indication that will change | 18:29 |
| kfox1111 | I have a bunch of content I want to contribute, but held up on ssl/instance user issues. :/ | 18:30 |
| kfox1111 | which is why I keep fighting that fight. | 18:30 |
| kfox1111 | barbican... 2%. :/ | 18:31 |
| kfox1111 | not really surprising due to the lack if instance users, but... if you need it to solve instance users... :_( | 18:32 |
| kfox1111 | unrelated note... I talked to the openstack cli folks. | 18:34 |
| kfox1111 | they said a plugin can set any words they want. | 18:34 |
| docaedo | cool | 18:35 |
| kfox1111 | so we could do 'openstack catalog community apps list' or something. | 18:35 |
| kfox1111 | openstack catalog local apps list for murano or something. | 18:35 |
| docaedo | I would disagree with that - because why not also search local glance from app catalog CLI? | 18:36 |
| docaedo | I think app catalog CLI should be limited to searching/listing the catalog itself, otherwise starts to get way too murky and confusing for users | 18:36 |
| kfox1111 | well, sure. I think that part woudl be unified. | 18:37 |
| docaedo | use murano client for murano, glance client for glance | 18:37 |
| kfox1111 | like the app catalog ui shows you glance installed stuff and murano installed stuff. | 18:37 |
| kfox1111 | I didn't mean it would be only murano. | 18:37 |
| kfox1111 | I think the issue is continuously confusing to users... it wont be any less confusing when murano plugs into the openstack cli. | 18:38 |
| docaedo | Maybe I'm not following the use case here, but other than indicating you already have something (i.e. show "installed" when you're doing a list) | 18:38 |
| kfox1111 | but its better to work together to try to minimize the confusion. | 18:38 |
| kfox1111 | like we did at the last summit for the ui. | 18:38 |
| docaedo | sure, but did anything happen with that? | 18:39 |
| kfox1111 | murano is the "applications catalog". users want to list out whats in it. its a reasonable thing to do. | 18:39 |
| kfox1111 | how do they do that? | 18:39 |
| docaedo | openstack murano list | 18:39 |
| kfox1111 | yes and no. yes a plan was struck. no, I've been too busy to finish the plan. its tabled, not dead. | 18:39 |
| kfox1111 | -1000 :) | 18:39 |
| kfox1111 | murano is not a verb. bleh. | 18:40 |
| docaedo | but murano is a specific service, the catalog is a generic index of things | 18:40 |
| kfox1111 | It always struck me as horible ui in horizon too. | 18:40 |
| kfox1111 | the cli and horizon are both user centric, which means never using a project name. murano thus far has broken that. | 18:40 |
| kfox1111 | and worse, the type is app catalog, which is our name and type. | 18:40 |
| docaedo | ah right ok I follow and agree at least on that part (not use a service name) | 18:41 |
| kfox1111 | a user has no clue what a murano is. they do have a clue what a catalog is. | 18:41 |
| *** kzaitsev_ has joined #openstack-app-catalog | 18:41 | |
| kfox1111 | yeah. | 18:41 |
| docaedo | unfortunately that ties murano and app catalog even closer together, but seems like that's inevitable | 18:42 |
| kfox1111 | so we've got to find a namespace we can co'exist in, or totally rename ourselves. | 18:42 |
| kfox1111 | kind of. so long as we can agree where not to step on each others toes, I think we're ok. | 18:42 |
| docaedo | but that's why I'm OK with "App Catalog" as a branding thing, and continuing to make it clear that "App Catalog" is the community index of things you can run on an openstack cloud | 18:43 |
| kfox1111 | murano is a local app catalog. we're a global one. | 18:43 |
| kfox1111 | yeah. but murano doesn't agree. | 18:43 |
| kfox1111 | its even in the user servey as "app catalog" | 18:43 |
| kfox1111 | :/ | 18:43 |
| kfox1111 | hence a lot of the confusion. | 18:43 |
| kzaitsev_ | I'm on the go, so I probably missed a couple of lines. the osc folks usually encourage to not use service names in the namespaces of plugins/commands. | 18:43 |
| docaedo | kzaitsev_: thanks yep, I remembered that :) | 18:44 |
| kfox1111 | yeah. | 18:44 |
| kfox1111 | kzaitsev_: we were discussing where to put the app catalog cli stuff. | 18:44 |
| kfox1111 | found out that catalog is taken by keystone, | 18:44 |
| kfox1111 | but sub words can be taken by other plugins. | 18:44 |
| kfox1111 | so we could do something like | 18:44 |
| kfox1111 | openstack catalog community app list | 18:45 |
| docaedo | yuck | 18:45 |
| kfox1111 | and murano could plugin maybe at openstack catalog local app list | 18:45 |
| kfox1111 | or something like that. | 18:45 |
| docaedo | what about local heat templates? don't they count as a local app list? | 18:45 |
| kfox1111 | then the help messages for openstack catalog could help point users along the way nicely. | 18:45 |
| kfox1111 | there is no local repo for heat templates. | 18:46 |
| kfox1111 | the catalog is for stuff "installed" that you may want to launch. | 18:46 |
| kfox1111 | once glare supports heat template artefacts taht get installed, that would show up there too I think. | 18:46 |
| kfox1111 | or you can wrap them in murano packages today and "intall" them in the local catalog. | 18:46 |
| kzaitsev_ | totally agree, that name/mission ambiguity for app catalog and murano are causing so much confusion, that it's worth thinking through the names once more. hope we'll have that chance in Austin | 18:47 |
| kfox1111 | +1 | 18:48 |
| kfox1111 | I'm finally starting to get a bit of free time now too, to start working on the more unified horizon interface we were talking about last summit. | 18:48 |
| kfox1111 | I've been doing some refactering recently to make it possible. | 18:48 |
| kfox1111 | but yeah, coming up with a final name would help. | 18:48 |
| kzaitsev_ | I've been asking members of team on that and it's not as impossible as one might think, if we come up with a compromise that's going to satisfy everyone:) | 18:49 |
| kfox1111 | yeah. ideally we'd both rename to make sure that no feelings are hurt and that both parties strenghts are clearly articulated. | 18:50 |
| docaedo | I should be able to make the murano sesson at 130 on Thursday | 18:50 |
| kfox1111 | I think murano's much more then just an app catalog. | 18:50 |
| kfox1111 | I think of it much more of an app engine. or app orchestrator. | 18:50 |
| kzaitsev_ | we actually have a osc plugin already in murano btw. I think there are no commands for packages yet. but it would be 'openstack package list' if we follow the spirit of osc plugin guidelines | 18:51 |
| kfox1111 | but then where does glare go? :) | 18:52 |
| kfox1111 | thats one of the problems with openstack unified cli. its great from a usability standpoint, but is forces the silo's to talk to each other and reach some kind of agreement in the best case, or convolute things after the fact in the worsed case. | 18:53 |
| kfox1111 | maybe we should talk about that part more at the summit too. | 18:53 |
| kzaitsev_ | I'm embarrassed to say that we still have not come up with our final schedule :) the deadline is end of this week but I really hope we'll have it rest by Thursday:) | 18:53 |
| kfox1111 | "what do we call ourselves and where do we plugin"? | 18:53 |
| kfox1111 | docaedo: did we settle on one of our sessions being naming? | 18:54 |
| kzaitsev_ | also, are you guys staying on Friday this time? :) | 18:54 |
| kfox1111 | most of friday. | 18:54 |
| docaedo | No, I just dumped the bullets in both sessions since they're back to back | 18:54 |
| docaedo | I'm around Friday morning | 18:54 |
| kfox1111 | so worst case, we can use one of the app catalog work sessions to cover it. | 18:56 |
| kfox1111 | murano has 3 sessions too? | 18:58 |
| kzaitsev_ | Thursday meeting should be a good point to sync up on that :) | 18:58 |
| docaedo | yeah if we have the right people in the room we can cover it - I figure we'll need to be flexible based on who is actually there, and which rooms we get in to | 18:58 |
| kzaitsev_ | yep and 1 overlaps with app cats | 18:58 |
| kzaitsev_ | I want to schedule it in such a way, that I would be able to attend the 2d half of app cats fishbowl | 18:59 |
| kfox1111 | k. | 19:00 |
| docaedo | kzaitsev_: great thanks | 19:00 |
| docaedo | Like I said I'll definitely be at the 130 murano one | 19:00 |
| kzaitsev_ | docaedo: thanks, noted that :) | 19:01 |
| kfox1111 | arg...... "lets build an openstack cross project and user story dashboard", "making cloud interoperability across openstack vendors a possibility using refstack" same time.... | 19:01 |
| kfox1111 | why do the same kind of topics always end up at the same time. :/ | 19:01 |
| docaedo | much to cover, not much time :) | 19:02 |
| kfox1111 | yeah. | 19:05 |
| kfox1111 | I'm really really grateful they post most of the presentations via video. | 19:05 |
| kfox1111 | the next few weeks after the summit are usually summit too. :) | 19:05 |
| *** kzaitsev_ has quit IRC | 19:06 | |
| kfox1111 | ah, a talk on senlin... | 19:08 |
| kfox1111 | I've been curious when they would pop up. | 19:08 |
| kfox1111 | its an abstract enough project its hard to get a handle on just what they are trying to accomplish. | 19:09 |
| *** kzaitsev_ has joined #openstack-app-catalog | 19:12 | |
| *** kzaitsev_ has quit IRC | 19:15 | |
| *** rmoe has quit IRC | 19:21 | |
| *** rmoe has joined #openstack-app-catalog | 19:22 | |
| kfox1111 | heh... cross project workshops: alternatives to polling..... zaqar and instance users.... :/ | 19:24 |
| kfox1111 | ah... heat's driving it. | 19:25 |
| *** toddjohn has quit IRC | 19:27 | |
| *** toddjohn has joined #openstack-app-catalog | 19:29 | |
| *** toddjoh__ has joined #openstack-app-catalog | 19:30 | |
| *** toddjohn has quit IRC | 19:34 | |
| *** kebray has joined #openstack-app-catalog | 19:39 | |
| *** spzala has quit IRC | 19:42 | |
| *** spzala has joined #openstack-app-catalog | 19:43 | |
| *** spzala has quit IRC | 19:43 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 20:31 | |
| *** toddjoh__ has quit IRC | 20:40 | |
| *** toddjohn has joined #openstack-app-catalog | 20:41 | |
| *** toddjohn has quit IRC | 20:41 | |
| *** spzala has joined #openstack-app-catalog | 20:46 | |
| *** spzala has quit IRC | 20:50 | |
| *** morgan has joined #openstack-app-catalog | 21:04 | |
| morgan | o/ | 21:04 |
| morgan | docaedo: oh look i see a docaedo and a hogepodge here. it must be a good channel | 21:04 |
| *** jroll has joined #openstack-app-catalog | 21:04 | |
| morgan | (and everyone else!) | 21:04 |
| morgan | :) | 21:04 |
| hogepodge | o/ | 21:04 |
| docaedo | morgan: welcome! it's a good channel IMO | 21:04 |
| jroll | \o | 21:04 |
| morgan | hogepodge: that reminds me.... | 21:04 |
| jroll | kfox1111: well, I'm not saying the thing that installs it, is or is not openstack. just asking the question. | 21:05 |
| docaedo | hogepodge: you missed it, I threw a grenade at the end of the TC meeting, that was fun | 21:05 |
| morgan | hogepodge: yeah you def. missed that | 21:07 |
| hogepodge | docaedo: I did miss it | 21:07 |
| *** spzala has joined #openstack-app-catalog | 21:08 | |
| hogepodge | docaedo: I would have had things to say. I've been doing ISV work too. Lots of groups spinning around the same things | 21:09 |
| docaedo | yep, I get really bummed when I find there's yet another effort to help app devs some way, and it's totally disconnected from the other three or four efforts I'm aware of | 21:11 |
| hogepodge | docaedo: let's try to get a unification in austin | 21:11 |
| docaedo | hogepodge: absolutely! | 21:11 |
| docaedo | hogepodge: that's part of the reason I am joining defcore meetings and getting involved in interop - I should have been doing that for the last year (sorry!) | 21:12 |
| hogepodge | docaedo: don't be sorry. It's good to have new people there | 21:27 |
| *** kzaitsev_mb has quit IRC | 21:29 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 21:30 | |
| *** kzaitsev_mb has quit IRC | 21:36 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 21:47 | |
| kfox1111 | jroll: I kind of lost track of the conversation. | 21:51 |
| kfox1111 | it just bothers me when folks push back so strongly that openstack is not an operating system. its usually the folks that don't think users can be non developers. | 21:52 |
| kfox1111 | the same thinking was applied to Linux for a while. And if that thinking continued, we wouldn't be using it today. | 21:52 |
| *** agentle has joined #openstack-app-catalog | 21:58 | |
| *** kzaitsev_mb has quit IRC | 22:01 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 22:06 | |
| *** kzaitsev_mb has quit IRC | 22:11 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 22:27 | |
| *** kzaitsev_mb has quit IRC | 22:45 | |
| kfox1111 | wow... refstack really is light on the requirements... | 22:49 |
| kfox1111 | http://www.openstack.org/brand/interop/ | 22:49 |
| *** kzaitsev_mb has joined #openstack-app-catalog | 22:50 | |
| kfox1111 | so, really just, user can use the nova api to launch a single server at a time, and upload some files to an object store. | 22:50 |
| kfox1111 | everything else you have to do yourself, if your targeting the lcd. | 22:51 |
| *** toddjohn has joined #openstack-app-catalog | 23:01 | |
| *** kzaitsev_mb has quit IRC | 23:02 | |
| *** toddjohn has quit IRC | 23:05 | |
| docaedo | basically but that makes sense if you're testing the IaaS part | 23:06 |
| *** spzala has quit IRC | 23:08 | |
| *** spzala has joined #openstack-app-catalog | 23:08 | |
| kfox1111 | yeah. if that's all you consider openstack to be, then thats reasonable. | 23:09 |
| kfox1111 | but then why bother with the big tent at all. | 23:09 |
| kfox1111 | interesting spec: https://review.openstack.org/#/c/284950 | 23:10 |
| docaedo | encourage someone to make awesome things, and if they're crazy good it'll be widely adopted. Like Josh's idea on the "one platform" thread, would be awesome if something could be implemented like that | 23:10 |
| kfox1111 | related to the magnum, lets avoid barbican spec. | 23:11 |
| docaedo | and TBH it sounds a little bit like what Murano would want to do | 23:11 |
| kfox1111 | yeah. totally. | 23:11 |
| docaedo | (the one-platform thing I mean) | 23:11 |
| * kfox1111 nods | 23:11 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 23:12 | |
| kfox1111 | which is something I think murano could do. going back to the, I think murano's more of an app engine then a catalog conversation from before. | 23:12 |
| *** spzala has quit IRC | 23:13 | |
| docaedo | yep, agreed on that - but then how many people will stand up and say "wait wait, stop, that sounds like heat, let's just do it in heat, stop fragmenting developer efforts!" | 23:13 |
| kfox1111 | to me, a catalog's a pretty basic thing. a book of paper with things in it you might want to procure. | 23:13 |
| docaedo | (guess I'm grumpy about prospects of progress something) | 23:13 |
| kfox1111 | because heat doesn't do COE or SFC. | 23:13 |
| kfox1111 | you could argue then that Murano's an engine that ties them all together. | 23:14 |
| docaedo | very true | 23:14 |
| kfox1111 | doh. gota go. have a good one. | 23:16 |
| docaedo | you too! | 23:17 |
| *** kzaitsev_mb has quit IRC | 23:24 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 23:36 | |
| *** kzaitsev_mb has quit IRC | 23:47 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!