| *** kzaitsev_mb has quit IRC | 00:03 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 00:17 | |
| *** kzaitsev_mb has quit IRC | 00:34 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 00:46 | |
| *** kzaitsev_mb has quit IRC | 00:58 | |
| *** kebray has joined #openstack-app-catalog | 04:03 | |
| *** openstack has joined #openstack-app-catalog | 06:30 | |
| *** kebray has quit IRC | 07:01 | |
| *** openstack has joined #openstack-app-catalog | 08:49 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 09:32 | |
| *** kzaitsev_mb has quit IRC | 09:45 | |
| *** openstackgerrit has quit IRC | 10:01 | |
| *** openstackgerrit has joined #openstack-app-catalog | 10:02 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 10:59 | |
| *** kzaitsev_mb has quit IRC | 12:49 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 13:04 | |
| *** kzaitsev_mb has quit IRC | 15:02 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 15:06 | |
| kfox1111 | docaedo: +1 for more service catalog standardization. -1 for yet one more bloody change that takes years for everyone to implement, if at all. Really hurting the app catalog. (https://xkcd.com/927/) | 16:03 |
|---|---|---|
| kfox1111 | rhagarty__: Here now. whats up? | 16:03 |
| rhagarty__ | kfox1111, brb | 16:05 |
| kfox1111 | k. | 16:05 |
| docaedo | kfox1111: yeah I am not really trying to get into fixing the service catalog :) BUT wanted to use that as a way to highlight what is available on the openstack public clouds w/r/t orchestration and app distribution | 16:06 |
| *** rhagarty__ has quit IRC | 16:06 | |
| kfox1111 | sure. | 16:07 |
| kfox1111 | just thinking we should maybe start pushing back a little harder when folks want to "fix things" by completely changing protocols so that havana clouds and mitaka clouds are even farther apart. :/ | 16:08 |
| kfox1111 | the service catalog could use some standardization, slight enhancements, but the, lets throw out it all and start with dns thing seems extreme. :/ | 16:09 |
| *** rhagarty has joined #openstack-app-catalog | 16:10 | |
| docaedo | yeah I have some thoughts about that for sure (but have to step away for a kid thing for a little bit so can't run my mouth :) ) | 16:12 |
| rhagarty | kfox1111, hey, we talked a while back about horizon plug-ins... was hoping to pick your brain for a couple minutes. | 16:16 |
| rhagarty | kfox1111, I noticed a few of the plug-ins changed how they are installed into devstack - i.e. the enable_plugin feature. Is this the new standard? | 16:18 |
| kfox1111 | sure. | 16:28 |
| kfox1111 | not sure. I don't use devstack much unfortunately. | 16:28 |
| kfox1111 | docaedo would know more about that then I would. | 16:29 |
| rhagarty | kfox1111, so how do real users get your plug-in? Does it have to be packaged for an OpenStack distro? | 16:30 |
| kfox1111 | thats part of the plan. | 16:30 |
| kfox1111 | no production cloud should be running devstack. | 16:30 |
| rhagarty | how is that initiated and managed? | 16:30 |
| kfox1111 | docaedo got it packaged on debian, and I'm working on rdo packages. | 16:30 |
| kfox1111 | sec... | 16:30 |
| rhagarty | oh, so each plug-in is responsible? | 16:31 |
| kfox1111 | yeah. :/ | 16:31 |
| kfox1111 | debian instructions here: http://openstack.alioth.debian.org/ | 16:31 |
| rhagarty | difficult? | 16:31 |
| rhagarty | ok - thanks for link | 16:31 |
| kfox1111 | rdo here: https://www.rdoproject.org/packaging/rdo-packaging.html | 16:31 |
| kfox1111 | debian took about a week. seemed relatively easy. | 16:31 |
| kfox1111 | I'm still waiting on RDO, months later. :/ | 16:31 |
| kfox1111 | way harder then it should be. | 16:32 |
| kfox1111 | kind of grumpy about it. going to bring it up at the next rdo meeting. | 16:32 |
| rhagarty | and how would a user know that it is available? | 16:32 |
| kfox1111 | the app catalog ui package is about as trivial a package as you can get. | 16:32 |
| kfox1111 | via apt-search/yum list. or, we're going to put install information on the apps.openstack.org site. | 16:33 |
| kfox1111 | also, theres: | 16:33 |
| kfox1111 | http://docs.openstack.org/developer/horizon/plugins.html | 16:33 |
| rhagarty | so good idea to be on that list? | 16:34 |
| kfox1111 | I think once we have a web page describing the install stuff, then we'll link to that. | 16:34 |
| kfox1111 | couldn't hurt. | 16:34 |
| rhagarty | will you have "openstack" in your package name to show up in searches? Or maybe some other associations? | 16:35 |
| kfox1111 | in rdo, I submitted it as openstack-app-catalog-ui so it would show up that way, yeah. | 16:35 |
| kfox1111 | debian wantied it packaged python-app-catalog-ui, which I think's a bit odd, considering. | 16:36 |
| rhagarty | ok - makes sense | 16:36 |
| kfox1111 | it happens to be python, but thats an implementation detail that shouldn't leak into the package name IMHO. | 16:36 |
| kfox1111 | a user won't care. | 16:36 |
| rhagarty | so, as far as you know, each plug-in is responsible for building their own package for each OpenStack distro? | 16:37 |
| kfox1111 | yeah, or else getting the distro's to package it themselves. | 16:37 |
| kfox1111 | same goes with the config management systems too. ansible/puppet/chef. :/ | 16:38 |
| rhagarty | seems like yours would fall into that category (done by the distro) | 16:38 |
| kfox1111 | I'd hope, but sometimes just getting it there in the first place, so they can manage afterwards greatly speeds up the process. | 16:38 |
| docaedo | rhagarty: hi .. will answer some questions | 16:39 |
| kfox1111 | getting it into the distro can be hard. keeping it updated is relatively easy. | 16:39 |
| rhagarty | oh, so there is a process to get on the "list"? | 16:39 |
| docaedo | regarding devstack - the ONLY supported thing is the plugins, method | 16:39 |
| kfox1111 | meeting next... bbiab. | 16:40 |
| rhagarty | docaedo, hello - so did this just happen? | 16:40 |
| docaedo | No it's been in process and available for a while - we're talking specifically about extending devstack here :) | 16:41 |
| rhagarty | docaedo, I recently noticed alot of the plug-ins suddenly added some devstack files | 16:41 |
| docaedo | yes, hold one sec there was a recent thread on the dev mailing list about this | 16:41 |
| rhagarty | k | 16:41 |
| docaedo | http://lists.openstack.org/pipermail/openstack-dev/2015-October/076310.html | 16:42 |
| docaedo | since devstack isn't meant for production at all, it's pretty easy to write that plugin (as it can be kind of dumb and clunky, doesn't have to necessarily work nicely with anything else) - though issues with the devstack plugin will be exposed in the gate if you're including the tests I suppose | 16:43 |
| rhagarty | ok - thanks for that. | 16:43 |
| docaedo | In our case, as kfox1111 said we have a REALLY minimal plugin that doesn't depend on anything other than Horizon | 16:44 |
| rhagarty | yeah, mine is a bit more integrated. It extends some table/row options for volumes. | 16:44 |
| docaedo | so if you want people to be able to play with anything you're building via devstack, the only way to go is follow the plugin instructions (which amounts to a devstack subdirectory and a shell script basically, not much more than that) | 16:45 |
| docaedo | understood .. | 16:45 |
| rhagarty | I originally had an overrides file (I know this is bad), and someone suggested I stick all of those classes in an __init__.py file so that they get loaded without having to specify an overrides file. | 16:46 |
| rhagarty | this stopped working | 16:46 |
| rhagarty | I wend back to the overrides and it works again | 16:47 |
| rhagarty | I went and looked at some other plug-ins and noticed the Cisco plug-in does the same thing (uses an overrides file). So I'm not sure what the real answer is.. | 16:48 |
| docaedo | ah sorry I am probably not going to be able to help too much on that front, other than saying if you can't get it to work in the confines of the devstack plugin framework, it will eventually stop working with devstack | 16:48 |
| docaedo | wouldn't hurt to ask on the mailing list though :) | 16:48 |
| docaedo | you'll likely get an answer from someone who knows what's up | 16:48 |
| rhagarty | good idea. appreciate your time | 16:48 |
| docaedo | oh no problem, happy to help out and you can always ask, sometimes one of us knows the right answer | 16:49 |
| docaedo | on the packaging front | 16:49 |
| docaedo | you are responsible for creating the packages, and keeping them up to date if you want them included in debian and RDO | 16:49 |
| docaedo | THEN | 16:49 |
| docaedo | if you have the packages, you can work with chef and puppet communities to include manifests/recipes for deploying that package with the distro | 16:50 |
| rhagarty | yes, I need to start this process. | 16:50 |
| docaedo | that dramatically increases the odds of people being able to include your bits in their environments | 16:50 |
| rhagarty | good to know | 16:50 |
| docaedo | and from there you can go one step further up the chain and work with the deployment tools like fuel, ubuntu juju, rdo packstack (others as well) to try to get your package included as an installable option | 16:51 |
| rhagarty | so, how do you test your packages? Do you really stand up each of the openstack distros for testing? | 16:51 |
| docaedo | Depends on the depth of change I guess - in your case if I recall it's a plugin that works with an external storage array or something like that? Or was it a neutron thing? | 16:52 |
| rhagarty | yes, it is storage related | 16:53 |
| docaedo | do you need a cinder driver to use it? | 16:53 |
| rhagarty | my question is more fundamental - I create a package. How do I know if can install correctly on each of the distros? | 16:54 |
| rhagarty | (yes, I need cinder and barbican) | 16:54 |
| docaedo | so when you have unique hardware in the mix, you need to have your own CI infrastructure that tests at a minimum the cinder stuff, and beyond that you can extend it as much as you want. But yes, if you want to say it works with Ubuntu/Juju environments, you have to deploy that environment (AFAIK nobody does testing on external hardware unless the hardware is supplied and they have some vendor | 16:56 |
| docaedo | agreement) | 16:56 |
| rhagarty | ok - that makes sense, but was hoping each of the distros had some sort of certification lab where you could submit your package | 16:58 |
| docaedo | that would be nice but how could they certify your package without your hardware? | 17:02 |
| rhagarty | I was thinking more like "it loads successfully without errors, and it shows up in Horizon". Anything more detailed would fall on us. | 17:04 |
| docaedo | ah OK I see what you're saying - but I think the closest you get to that is the gate tests, so you can included devstack/gate tests in your repo that validate the code loads successfully without errors | 17:06 |
| docaedo | and from there you can show the packages of that are based on the same codebase | 17:06 |
| rhagarty | ok - looks like I need to look into those details. | 17:07 |
| docaedo | I would HIGHLY encourage you to get on #openstack-infra and chat up clarkb, fungi and others about this | 17:07 |
| docaedo | they can give you really good guidance here, as basically everyone who has wanted to do what you are talking about has gone through openstack infra team gate stuff | 17:08 |
| rhagarty | great advise... thanks | 17:08 |
| docaedo | and I think they love to hep (in my experience they've done a ton of hand holding for me, and given me lots of pointers, and continue to do so all the time) | 17:08 |
| rhagarty | nice | 17:08 |
| docaedo | no problem - I actually think that IRC channel is the place everyone should lurk, as you get the view of how ALL the things come together there | 17:09 |
| rhagarty | and you guys are definitely my favorite channel! | 17:09 |
| docaedo | haha thanks! I'm angling to be an official openstack ambassador some day so you know, just trying to be consistently helpful and friendly :D | 17:10 |
| docaedo | also to circle back to your distro certification | 17:11 |
| docaedo | I know Mirtantis has a plugin certification process, and they're happy to help with that stuff | 17:12 |
| rhagarty | good to know | 17:12 |
| docaedo | I am *pretty sure* RedHat and Ubuntu have similar programs, where they willingly help people - sometimes only requires donation of a little gear for their lab | 17:12 |
| kfox1111 | rhagarty: might ask on the openstack-horizon channel about overrides like questions. they are usually quite responsive. | 17:13 |
| rhagarty | yeah, it seems like it would beneficial to both parties to have some shared testing | 17:13 |
| rhagarty | kfox1111, will do. | 17:14 |
| kfox1111 | last summit there was a push to get all the packagers to share a common repo. | 17:14 |
| kfox1111 | its not there yet, but they have made a lot of progress. | 17:14 |
| rhagarty | any patches up yet to support that? | 17:14 |
| kfox1111 | I'm going to try and sit in on that meeting again this comming summit if they have it again. | 17:15 |
| kfox1111 | slower then that. I think there's an openstack-rpms channel now for communication between rdo & suse. | 17:15 |
| kfox1111 | and I think the debian/ubuntu distro's are working closer together. | 17:15 |
| kfox1111 | rdo's been getting building from trunk to be a thing. (delorean) | 17:16 |
| kfox1111 | etc. | 17:16 |
| kfox1111 | docaedo: we need to figure out ubunutu at some point too. | 17:16 |
| kfox1111 | with the big tent, its getting much harder for the distro's not to share some of the work between them. | 17:17 |
| rhagarty | wow... I have my head buried in devstack and never knew about this stuff. Glad I asked you guys... | 17:17 |
| kfox1111 | devstack folks do point out its not for production, but not as loudly and in blinky letters as they should. | 17:17 |
| docaedo | rhagarty: glad we could provide some scary information (in the spirit of Halloween and all!) | 17:17 |
| kfox1111 | :) | 17:17 |
| rhagarty | ok - back to work on my plug-in. Thanks again for all the info... | 17:19 |
| kfox1111 | np. :) | 17:20 |
| kfox1111 | we're still kind of figuring this stuff out ourselves. | 17:20 |
| kfox1111 | happy to make it easier on other projects where we can. :) | 17:20 |
| docaedo | yep - glad we could help and definitely ping us here with questions. especially around debian packaging, that's very fresh in my mind as I just went through it :) | 17:21 |
| rhagarty | cool. thanks | 17:21 |
| kfox1111 | docaedo: do you know if ubunutu officially pulls from debian for openstack packages yet, or do we need to submit ubuntu packages too? | 17:23 |
| kfox1111 | there are a lot more ubuntu clouds then debian ones right now. :/ | 17:24 |
| docaedo | :) Just asked that question on the Debian IRC channel | 17:24 |
| kfox1111 | thx. :) | 17:24 |
| docaedo | Internet makes me think Ubuntu grabs up the debs and only makes changes for things they care about (http://www.ubuntu.com/about/about-ubuntu/ubuntu-and-debian) but really not sure. Likely they curate all things around openstack because they have a vested interest in managing what openstack on ubuntu looks like | 17:25 |
| kfox1111 | I know they were doing their own packages until debian started doing there's. so I'm not sure if tehy have broken down their own ubuntu process yet or not. | 17:26 |
| docaedo | yeah I wonder, though I suspect there's extra scrutiny around all things openstack, because they do their own packages for at least some of it. Like a juju deployed openstack has an ubuntu-themed horizon | 17:27 |
| kfox1111 | ah. right. | 17:50 |
| kfox1111 | in rdo, they make the theme a seperate package, but ubuntu might not of gotten that part working yet. | 17:51 |
| docaedo | oh actually maybe that's how they do it too? I did not scrutinize that piece closely because I was just doing a juju deployment as a comparison point, didn't do much peeling back of layers | 17:52 |
| kfox1111 | ah. | 17:54 |
| kfox1111 | haven't played with juju. it looks kind of cool, but I was turned off by the terminology and the ubuntu onlyness of it. | 17:54 |
| kfox1111 | oh. wait. juju, not metal as a service. | 17:55 |
| kfox1111 | just the ubunutu only ness of that one. | 17:55 |
| kfox1111 | I don't understand metal as a service being created instead of contributing to ironic. | 17:56 |
| kfox1111 | and juju seems to be kind of a competitor of heat's. | 17:56 |
| docaedo | yeah well .. juju is interesting, but solving problems that are already solved with just a smidge of difference (like chef puppet ansible salt, with slightly better orchestration parts) | 17:56 |
| kfox1111 | yeah. | 17:57 |
| kfox1111 | I think the one thing juju really has for it is a nice ui. | 17:57 |
| kfox1111 | that could be contributed and adapted to those other things. | 17:57 |
| docaedo | well thing about heat is it only works in openstack, vs. juju (or the other config management approaches) work with linux (and somewhat with windows too) | 17:57 |
| kfox1111 | yes,no? heat can deploy bare metal with ironic and manage linux and windows instances. | 17:58 |
| docaedo | and they can all be easily extended to work with an openstack environment | 17:58 |
| kfox1111 | just in a bit different a way. | 17:58 |
| kfox1111 | yeah. | 17:59 |
| kfox1111 | the problem I have with most of the config management systems at the moment, is they assume they do everything. | 17:59 |
| kfox1111 | IE, you want a load balancer, you have it stand up a machine using haproxy. | 17:59 |
| kfox1111 | with openstack, it provides an api, that is abstract, that could do that exact thing, or could controll a hardware load balancer. | 17:59 |
| kfox1111 | so the config management system needs openstack api support. | 18:00 |
| kfox1111 | which none seem to have. | 18:00 |
| docaedo | right, but you are still limited to people with openstack environments | 18:00 |
| kfox1111 | sure, but if all goes well, that will be everyone. ;) | 18:00 |
| kfox1111 | openstack really needs to finish up the "its hard to deploy" issue though. | 18:00 |
| kfox1111 | then that should get much better. | 18:00 |
| kfox1111 | I think between merging TripleO and Kolla, there's a chance to finally make that part work smoothly. | 18:01 |
| kfox1111 | though I think its probably another year out. :/ | 18:01 |
| kfox1111 | the, you start with a seed vm, then use it to deploy some real hardware, which becomes self hosting, and then you deploy everything else is a very compelling thing. so long as they iron out all the kinks. | 18:02 |
| docaedo | when you say "needs openstack api support" do you mean ability to control things in an openstack environment via API? | 18:02 |
| kfox1111 | like, the user said that there should be a load balancer in front of these servers, and the member list comes from this chef search: ..... | 18:03 |
| docaedo | (sorry super laggy! my responses are delayed about 2 minutes!) | 18:03 |
| kfox1111 | chef server should deploy the lb using a neutron lb, and then do the chef search and maintain the member list in openstack. | 18:03 |
| docaedo | Time to move my weechat client to a VM on vexxhost I think | 18:04 |
| kfox1111 | rather then trying to setup a new vm using haproxy. in some clouds, you can't ever have a vm with haproxy be faster then what neutron lbaas can provide. | 18:04 |
| kfox1111 | :) | 18:04 |
| kfox1111 | chef for example is good at maintaining the software config of a node. it currently has no concept of non node things. like load balancers. | 18:05 |
| kfox1111 | so they keep shoehorning concepts like load balancers through the only tool they have, node config's. | 18:05 |
| kfox1111 | heat I think gets that part right. | 18:06 |
| kfox1111 | orchistrate the deployment of all of the physical/virutal resources, | 18:06 |
| kfox1111 | then leave it up to a config management piece to finish deploying nodes, since thats what they can do at present. | 18:07 |
| kfox1111 | most of the config management systems dont play too nicely with heat though. they assume they are running the show, and not some other piece like heat. :/ | 18:09 |
| kfox1111 | so I haven't seen many things that play nicely with heat autoscaling for example. | 18:09 |
| kfox1111 | which is the holy grail of cloud scaled apps. | 18:10 |
| kfox1111 | I'm kind of wondering how long the traditional config management systems can stay unchanged while openstack api's, heat autoscaling, docker container orchestration, etc comes in and totally changes things. | 18:11 |
| docaedo | yeah my opinion is that heat doesn't do anything special that can't be replicated from ansible - ansible can be aware of what it's deployed, and manage the plumbing between the things it deployed, including scaling things up and down | 18:12 |
| kfox1111 | totally disagree on that one. :) | 18:12 |
| kfox1111 | heat stays running and can adapt to load. ansible is maintained on one machine and takes a user to do something. | 18:13 |
| kfox1111 | (or stuck in a cron job). | 18:13 |
| kfox1111 | I use ansible every day, and really like it, but it definatly is a different thing then heat. | 18:13 |
| docaedo | that's true :) | 18:13 |
| kfox1111 | ansible still really only has the concept of machines last I looked. something you can ssh into and then run ansible stuff on. | 18:14 |
| kfox1111 | has the same issues with lb's and such that chef and others have. | 18:14 |
| kfox1111 | no dbaas, lbaas, securitygroup support, etc. | 18:15 |
| kfox1111 | I'd like ansible or chef to manage security groups, since it knows which ones are appropriate to the software running on the node. | 18:15 |
| kfox1111 | but having them done outside of the vm, inside the cloud is a much better security thing, then iptables inside the vm. | 18:16 |
| kfox1111 | they only can do inside at the moment. :/ | 18:16 |
| kfox1111 | I'd really like a cloud aware config management system. :/ | 18:16 |
| kfox1111 | ansible's the closest I've found, just because through the dynamic inventory plugins, you can at least make ansible aware of the hosts/services that exist. | 18:17 |
| kfox1111 | so, like: run this command on all vm's that use xyz glance image. | 18:17 |
| kfox1111 | that part's awesome. :) | 18:17 |
| kfox1111 | but what woudl be awesomer still is "deploy this webserver on this vm", and its smart enough to ensure the web security group is added to the vm too. | 18:18 |
| kfox1111 | currently the only way to do something like that is two pass. deploy all the things with heat, then run asible across to do the rest. but that's a bit splitbrained for my tastes. | 18:19 |
| docaedo | there are tradeoffs and things ansible doesn't do - I guess my frustration is that heat aims to do a LOT of stuff, while much of the core base parts of openstack still need a lot of love, so I just get annoyed (like let's fix scheduler, image distribution, storage and networking - basic IaaS stuff to be GREAT at HUGE SCALE, then start worrying about all the things that tack on top of that) | 18:19 |
| docaedo | realistically though | 18:19 |
| kfox1111 | its a open source thing though. the heat developers only care about developing on heat, not fixing those other things. Those other things will come in time. | 18:20 |
| docaedo | kubernetes is going to do all the things, and get adopted on a much larger scale before Heat does all the things in a way everyone loves :) (maybe) | 18:20 |
| kfox1111 | in the mean time, I agree, its frustrating. | 18:20 |
| kfox1111 | as an op/user. | 18:20 |
| kfox1111 | yeah, kubernetes is interesting. but like all things hyped, it will settile into a nitch, and I think heat and kubernetes will coexist nicely. | 18:21 |
| kfox1111 | I can totally see using heat to deploy cloud scaled apps that end up launching parts into kubernetes. | 18:22 |
| kfox1111 | heat deploys a lb, and a set of containers into kubernetes managed vm's, and autoscales things. | 18:22 |
| docaedo | yes, they could coexist nicely that's true | 18:22 |
| kfox1111 | one of the things I really like about heat, that I have'nt seen in many other systems, | 18:24 |
| kfox1111 | is a relatively clean seperation between those who launch a stack (app user) and the developer of the stack (app developer). | 18:24 |
| kfox1111 | the horizon form that lets users fill out settings to use to launch the instance. | 18:25 |
| kfox1111 | chef/ansible/puppet/salt,etc all expect devops folks to be running the show. so, not as good for app catalog kinds of usage without some wrapers around them. | 18:25 |
| kfox1111 | heat does seem well suited to having an application entry in a catalog, a user pics, fills out the form, and gets a working cloud app out of the other end, without having to be a dev. | 18:26 |
| kfox1111 | there's huge value in that. more then I think the a lot of heat devs realize. | 18:26 |
| *** kzaitsev_mb has quit IRC | 19:17 | |
| *** docaedo has quit IRC | 20:51 | |
| *** docaedo_ has joined #openstack-app-catalog | 20:56 | |
| *** docaedo_ is now known as docaedo | 20:56 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 21:32 | |
| *** kzaitsev_mb has quit IRC | 21:37 | |
| *** kebray has joined #openstack-app-catalog | 22:56 | |
| *** kzaitsev_mb has joined #openstack-app-catalog | 23:29 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!