| *** kebray has joined #openstack-app-catalog | 03:45 | |
| *** kebray has quit IRC | 06:08 | |
| kfox1111_ | docaedo: Does the chef entry replace the correct one in the right order? I'm not sure the correct ordering. if it is, then I'm ok +ing it. | 19:14 |
|---|---|---|
| j^2 | :D | 20:26 |
| j^2 | yeah i created it whith what docaedo wanted | 20:27 |
| j^2 | with what i think he wanted i mean | 20:27 |
| kfox1111_ | k. | 20:28 |
| kfox1111_ | has any work been done on a heat template to go along with it? | 20:28 |
| kfox1111_ | its really handy to have a cinder volume to go along with chef servers. | 20:28 |
| kfox1111_ | that way you can destroy/rebuild the vm quickly and keep your server's data safe on the volume. | 20:29 |
| kfox1111_ | j^2: Approved. Should go through shortly. | 20:30 |
| j^2 | rock on | 20:32 |
| openstackgerrit | Merged stackforge/apps-catalog: Added the Chef logo for the main page https://review.openstack.org/204709 | 20:32 |
| j^2 | kfox1111_: i know little about heat to be honsest | 20:32 |
| j^2 | this was my excuse to start learning it though | 20:32 |
| j^2 | any suggestions on tutorials or anything to help bootstrap me? | 20:33 |
| kfox1111_ | I have e presentation I've been writing that might help. its not quite done yet... | 20:39 |
| j^2 | anything would me helpful :D | 20:39 |
| kfox1111_ | I've got some examples I've been doing that may help too. | 20:39 |
| j^2 | oh nice. | 20:39 |
| j^2 | i’ve started working with the jjb too, that is suprisely hard if you are coming from nothing | 20:40 |
| kfox1111_ | I've been putting most of what I've been doing out here: https://github.com/EMSL-MSC/heat-templates/tree/master/cfn | 20:40 |
| kfox1111_ | One of the simplest is under mgmt. | 20:40 |
| kfox1111_ | The Init template creates a formatted cinder volume with stuff in it. | 20:41 |
| kfox1111_ | the Mgmt.yaml template consumes the volume and hydrates it unto a workable server. | 20:41 |
| kfox1111_ | into | 20:41 |
| kfox1111_ | Its a pretty old template though. doesn't use too much of the yaml features heat has now. | 20:42 |
| j^2 | ah ok, cool, but it’s something to start with | 20:42 |
| j^2 | thanks! | 20:42 |
| kfox1111_ | https://github.com/EMSL-MSC/heat-templates/tree/master/cfn/Jenkins is a newer one by the looks of it. | 20:43 |
| kfox1111_ | a little easier to read. might be a better starting point. | 20:43 |
| kfox1111_ | np. let me know if you have any questions. :) | 20:43 |
| kfox1111_ | the #heat chanel is also quite responsive when I've had issues. | 20:43 |
| kfox1111_ | gota head out. talk to you later. | 20:43 |
| j^2 | kk | 20:44 |
| openstackgerrit | JJ Asghar proposed stackforge/apps-catalog: Chef Server Link was wrong https://review.openstack.org/205771 | 21:28 |
| j^2 | *facepalm* the link was missing “server” ^^^ | 21:28 |
| openstackgerrit | Merged stackforge/apps-catalog: Chef Server Link was wrong https://review.openstack.org/205771 | 21:46 |
| openstackgerrit | JJ Asghar proposed stackforge/apps-catalog: It's placed under images not glance-apps https://review.openstack.org/205772 | 22:10 |
| kfox1111_ | docaedo: sent an email to the list. Curious if some integration with the TripleO folks would be in order. | 22:11 |
| j^2 | kfox1111_: can you +1 +2 that review, it seems there is different glance-apps and glance-images? | 22:11 |
| kfox1111_ | I as going to, but docaedo looks like got to it first. | 22:12 |
| j^2 | :D | 22:13 |
| j^2 | oh i mean | 22:13 |
| j^2 | https://review.openstack.org/#/c/205772/ | 22:13 |
| kfox1111_ | oh. just a sec... | 22:13 |
| j^2 | thanks, yeah didnt realize theres glance-apps and glance-images | 22:13 |
| j^2 | wow, that’s what happens when you try to cargo cult i guess | 22:14 |
| kfox1111_ | me neither. good catch. :) | 22:14 |
| kfox1111_ | Should be much better when we get stuff merged into one yaml file. | 22:15 |
| kfox1111_ | we can use the same identifier everywhere then. | 22:15 |
| j^2 | kfox1111_: makes sense | 22:15 |
| openstackgerrit | Merged stackforge/apps-catalog: It's placed under images not glance-apps https://review.openstack.org/205772 | 22:16 |
| j^2 | :rockon: thanks! | 22:16 |
| kfox1111_ | np. thanks for catching the error and proposing the fix so fast. :) | 22:16 |
| j^2 | :D | 22:17 |
| j^2 | i really do want to become active in this project | 22:17 |
| j^2 | it’s a great idea for openstack as a whole | 22:17 |
| j^2 | the best thing i can do is keep up with what i’m trying to propose :D | 22:17 |
| kfox1111_ | yeah. its a big help. :) | 22:18 |
| kfox1111_ | One of the groups I work with at PNNL is using Chef. Its great to see the bar lower for setting up a working Chef server. :) | 22:19 |
| j^2 | yep, there is one bug with it though, i wrote up a workaround today. They plan on a fix for 12.3 which should be a release or two away | 22:20 |
| j^2 | http://jjasghar.github.io/blog/2015/07/20/ssl-connect-returned-equals-1-errno-equals-0-state-equals-sslv3-read-server-certificate-b/ | 22:20 |
| j^2 | that’s assuming youre lazy like me and use self signed stuff | 22:20 |
| j^2 | other than that, that chef server is good enough to run 10,000s of nodes if needed | 22:21 |
| kfox1111_ | ah. yeah. | 22:22 |
| j^2 | btw, the image was built: https://github.com/chef-partners/marketplace_image/pull/10 | 22:23 |
| j^2 | we’re internally debating on the iptables thing | 22:23 |
| j^2 | i’m pushing for it, it seems that this should be as secure as possible and the majority of the “best practises” possible | 22:23 |
| kfox1111_ | iptables for the openstack version? | 22:25 |
| j^2 | on the image for centos6 and the glance image and chef server | 22:25 |
| kfox1111_ | ah. | 22:25 |
| j^2 | just have 22 80 and 443 open nothing else | 22:25 |
| j^2 | that’s all you need for a standalone chef server | 22:25 |
| kfox1111_ | Yeah. I can see that. We've been doing something very different. | 22:25 |
| j^2 | yeah there’s like 6-7 different ways to set up a chef server that isn’t standalone | 22:26 |
| kfox1111_ | we've been doing it all with heat. using a custom security group with the vm. | 22:26 |
| j^2 | ahh interesting | 22:26 |
| kfox1111_ | there are 2 main advantages to doing it that way. | 22:26 |
| kfox1111_ | 1, security group changes are easier to manage from within the cloud. updates apply automatically. | 22:26 |
| kfox1111_ | and 2, its more secuire if something gets comped. if someone gets into the vm, they can not touch the firewall since it exists outside of the vm. | 22:27 |
| j^2 | yeah that’s how AWS tells you to do it, per my aws cohort. being i can’t mandate it i thought iptables was a good….copromise | 22:28 |
| kfox1111_ | yeah. | 22:28 |
| kfox1111_ | so are you a chef guy? what do you spend most of your time on? | 22:29 |
| kfox1111_ | might make it configurable ala cloud-init. | 22:31 |
| kfox1111_ | #!/bin/bash no-setup-iptables or something. Then if you wrap it in a heat template, you can disable that piece. | 22:32 |
| j^2 | https://twitter.com/jjasghar/status/625070831371063296 :D | 22:33 |
| j^2 | kfox1111_: yeah i work for chef | 22:33 |
| j^2 | i’m the Chef “OpenStack” dude | 22:34 |
| j^2 | anything openstack and chef related comes through me | 22:34 |
| j^2 | threw* | 22:34 |
| j^2 | kfox1111_: nice, on the cloud-init thing | 22:34 |
| kfox1111_ | cool. :) | 22:34 |
| kfox1111_ | I'm sure we'll be chatting more on that subject at some point. :) | 22:36 |
| j^2 | sounds great | 22:36 |
| j^2 | part of my job is to attempt to elevate the chef community in the openstack community, so anything i can do to help or whatever don’t hesitate to ask | 22:37 |
| j^2 | hence the glance image, i thought it was a pretty easy get to get more people start playing with chef in/on/with openstack | 22:38 |
| j^2 | and obviously i dog food this too; its how i build my chef server in my clouds | 22:38 |
| kfox1111_ | cool. :) | 22:38 |
| kfox1111_ | I can think of a few ways to really enhance things. | 22:39 |
| j^2 | i’d love to hear em | 22:40 |
| j^2 | any chance you’re going to either the ops meetup or toyko? | 22:40 |
| kfox1111_ | one big one that I've almost written a few times is a better bootstrapping mechanism. chef has a problem in that it assumes it is driving the show. | 22:40 |
| kfox1111_ | slight chance. Not sure. :/ | 22:40 |
| kfox1111_ | so Heat has this awesome feature called autoscaling. | 22:41 |
| kfox1111_ | it creates/destroyes vm's as needed. | 22:41 |
| j^2 | oohhh | 22:41 |
| kfox1111_ | you can say, "I want between 3 and 10 of this heat template" | 22:41 |
| kfox1111_ | and it will make it so. :) | 22:41 |
| kfox1111_ | but the knife bootstrap thing totally doesn't work with it. | 22:42 |
| j^2 | hmm | 22:42 |
| kfox1111_ | chef needs some kind of integration with nova or heat such that when it launches things, it can bootstrap the node on your behalf. | 22:42 |
| j^2 | sounds like a feature request to knife openstack? | 22:43 |
| j^2 | heat template support? | 22:43 |
| kfox1111_ | maybe? I'm not sure it belongs in knife, or is just a new kind of heat resource? | 22:43 |
| kfox1111_ | or if it belongs as a nova plugin somehow. | 22:44 |
| j^2 | interesting | 22:44 |
| j^2 | it doesn’t seem very radical, it seems like something that should be there already | 22:44 |
| kfox1111_ | it would be nice if you coud associate a chef server with a keystone tenant, | 22:44 |
| kfox1111_ | and all vm's built in that tenant are automatically enrolled to the server. | 22:44 |
| kfox1111_ | no boot strap needed. | 22:44 |
| j^2 | You given me something to think about | 22:46 |
| j^2 | There is something here though | 22:46 |
| kfox1111_ | another thing would be chef as a service. provide one chef instance at the cloud operator to tenants so they don't have to manage their own server. maybe tie it into the horizon dashboard too. that would be awesome. :) | 22:47 |
| kfox1111_ | it could tie into the previous feature too. | 22:48 |
| j^2 | Chef 12 should be able to do that what your suggestioning | 22:48 |
| j^2 | The cloud operator | 22:48 |
| kfox1111_ | You'd need keystone integration for authentication and hopefully some kind of dashboard integration too. | 22:49 |
| j^2 | Oh that's true Keystone integration would be the hard part | 22:49 |
| j^2 | I have to learn more about how to do that though | 22:49 |
| kfox1111_ | I don't think it would be too hard to do. just a bit of work to have a ui that lets you create/fetch admin keys for a tenant. | 22:50 |
| j^2 | Interesting | 22:50 |
| kfox1111_ | and map the keystone tenants to a chef one somehow. | 22:50 |
| j^2 | Be nice if there were Shared keys though | 22:51 |
| j^2 | Shuffle requires a pem so in theory we could take that from Keystone | 22:51 |
| kfox1111_ | yeah. the admin key would be for the whole tenant. but with the ui like that, the users coudl self provision their chef admin keys if they wanted. then the op doesn't have to be involved. | 22:51 |
| j^2 | I think there's something really here | 22:52 |
| kfox1111_ | really basic horizon integration could just bring you to the right place in the chef web ui. nicer integration would actually embed it somehow. | 22:53 |
| j^2 | Yep | 22:53 |
| kfox1111_ | the third integration point I'd releally like to see, but somewhat behind the first 2, is security related. | 22:54 |
| j^2 | Could you explain that | 22:54 |
| kfox1111_ | encrypted databags really don't work well with the heat autoscaling model either. some kind of easy barbican integration would be nice. | 22:54 |
| j^2 | ahhh | 22:54 |
| kfox1111_ | so encrypted data bags are associated with a node by search usually. | 22:54 |
| kfox1111_ | but the query has to be vetted by and admin, or else any vm can add the attribute to get a given key and get access to it automatically. | 22:55 |
| kfox1111_ | 'by an admin' | 22:55 |
| kfox1111_ | but requiring an admin to verify a node should get a key doesn't work when the vm should get it automatically to make autoscaling work. :/ | 22:56 |
| j^2 | i think i follow yeah, that is a challange | 22:56 |
| kfox1111_ | I've been working a different angle to let vm's get keystone users so it can talk to barbican. | 22:57 |
| kfox1111_ | https://review.openstack.org/#/c/186617 | 22:57 |
| kfox1111_ | if that makes it through, vm's can get access to the secrets they need. | 22:58 |
| kfox1111_ | chef just needs to be able to fetch them when needed from barbican. | 22:58 |
| j^2 | yep | 22:59 |
| kfox1111_ | so maybe some encrypted databag comptable abstraction layer that can pull from either encrypted databags or from barbican would help. | 23:00 |
| kfox1111_ | that way existing cookbooks don't have to be rewritten. | 23:00 |
| j^2 | so i get it barbican becomes the data store for the data bags | 23:02 |
| *** kebray has joined #openstack-app-catalog | 23:02 | |
| kfox1111_ | yeah. | 23:06 |
| kfox1111_ | Those are the big thinkgs I can think of. | 23:11 |
| kfox1111_ | probably a bunch of minor things that would be nice to have's. | 23:12 |
| kfox1111_ | oh. one more I'd kind of like to see, which might be much harder, is multiple servers... | 23:16 |
| kfox1111_ | can be dangerious, but the intent is, the tenant wants to use config management for config mangaement. setting stuff up, configing it, etc. | 23:17 |
| kfox1111_ | the cloud operator itself may want to manage all the vm's themselves via chef also, to ensure all security updates are applied, etc. | 23:17 |
| j^2 | yeah as i get my head wrapped around heat no reason why i couldnt create an HA template | 23:20 |
| kfox1111_ | that would be awesome. :) | 23:21 |
| j^2 | Got to go baby is crying till Monday | 23:21 |
| kfox1111_ | have a good one. :) | 23:23 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!