| *** os-chef-bot has quit IRC | 00:23 | |
| *** os4uinfo_ has joined #openstack-chef | 00:51 | |
| *** os4uinfo_ has quit IRC | 00:55 | |
| *** os4uinfo_ has joined #openstack-chef | 01:01 | |
| *** os4uinfo_ has quit IRC | 01:03 | |
| *** os4uinfo has joined #openstack-chef | 01:03 | |
| *** os4uinfo has quit IRC | 01:03 | |
| *** os4uinfo has joined #openstack-chef | 01:04 | |
| *** os4uinfo has quit IRC | 01:05 | |
| *** os4uinfo has joined #openstack-chef | 01:06 | |
| *** ch-mhass has joined #openstack-chef | 06:02 | |
| *** jklare has quit IRC | 07:25 | |
| *** jklare has joined #openstack-chef | 07:26 | |
| jklare | sc` we can move there right now if you ask me | 07:39 |
|---|---|---|
| jklare | sc` if we agree on moving out of the big tent and out of the whole openstack namespace, i can try to make that happen | 07:41 |
| jklare | sc` i mean probably the only thing we have to do here is to write a short statement to the mailing list and ask if we should fork the whole projekt or if somebody can move it | 07:43 |
| os4uinfo | ? | 08:30 |
| *** os4uinfo has quit IRC | 10:17 | |
| *** os4uinfo has joined #openstack-chef | 11:41 | |
| *** os4uinfo has quit IRC | 11:47 | |
| sc` | jklare: indeed. it's feeling like it's either time for us to be shown the door, or otherwise see ourselves out. it's really hard supporting a flexible framework like chef while prescribing a One True Way | 12:28 |
| sc` | when chef gets mentioned on the ml, it's usually either in anger or me decrying the outwardly perceived death | 12:29 |
| sc` | flexibility is likely to be the most cited reason for throwing tomatoes at us | 12:32 |
| sc` | chef offers so much out of the box, and we use like three things | 12:32 |
| sc` | up front, i really dislike shucking off the openstack branding, but at the same time, we're dying under the weight of the rapidly deflating big tent | 12:36 |
| sc` | for example, there's a recent surge in popularity from the container side of things, where they want networking like calico, but only two 'openstack' config management frameworks support it: juju and ansible | 12:39 |
| sc` | dragging in calico would immediately solve a pike community problem, and that is implementing etcd | 12:39 |
| sc` | the resident openstack folks are receptive to the notion of wider support, and they lament not having enough capable folks covering the other bases. they, too, see the surge in popularity | 12:40 |
| sc` | if sous chefs would be receptive to the idea, perhaps rehoming to there. it'd cut down on the governance-style stuff we'd have to bootstrap on our own | 12:43 |
| sc` | i'm conflicted because we're still effectively a community of five or six, and moving anywhere else really means stepping up the marketing | 12:44 |
| sc` | but, without being able to leverage natively bundled tooling like test-kitchen, that's as good as dead | 12:45 |
| sc` | i'm trying to conceptualize how that might go. taking a page from centos with their sigs, it's a matter of creating a new github group, adding the founding members, and letting them self-manage as much as possible. would we just move off to our own un-openstack group? | 12:53 |
| sc` | something not in governance? how to handle handovers? these little bits of code need a steward if something were to happen to cloudbau's mission or my own, not that i don't have faith | 12:54 |
| sc` | how's that for a good irc monologue? :D | 12:55 |
| *** os4uinfo has joined #openstack-chef | 13:29 | |
| *** os4uinfo has quit IRC | 13:34 | |
| jklare | sc` :9 | 14:01 |
| jklare | sc` i am sorry, was just grabbing some lunch | 14:01 |
| jklare | sc` so yeah, i agree that we need some sort of governance if we want to move to "just github" | 14:01 |
| jklare | sc` i am not sure if we wanna go to "sous chefs" since their aim as far as i understood is to support community cookbooks that are used by a lot of people | 14:02 |
| jklare | sc` which is not true for openstack cookbook i think, since they aim at a very specific thing and need a lot of knowledge about openstack itself to be maintained | 14:03 |
| sc` | indeed | 14:09 |
| jklare | sc` for me the most important thing is that we can keep developing the cookbooks and have some testing behind it | 14:10 |
| sc` | much of the immediate work that needs to be done is less about knowing openstack, but developing the chef around it. there aren't many ways to openstack properly | 14:11 |
| sc` | chef 13 is coming our way whether we want it or not. chef 12 can be pinned for now | 14:12 |
| sc` | the remaining operators that checked off chef on the survey are not small, and need a clear path if they are to keep investing in their chef story. retooling is almost a last resort, but will be done if the current is deemed enough of a liability | 14:14 |
| sc` | that has a knock on effect that goes a long way | 14:15 |
| jklare | sc` i think migrating to chef 13 will be a task that can only be archieved if we keep up some automated form of integration testing | 14:19 |
| sc` | exactly | 14:19 |
| sc` | we essentially need test-kitchen | 14:19 |
| sc` | there's no way around it | 14:19 |
| jklare | sc` to be honest, i have not looked into that for quite some time now, but as far as i can tell, the third party ci is still working | 14:19 |
| sc` | yeah. it's still humming along | 14:19 |
| jklare | so we need to decide if we want to migrate to chef 13 or rework our testing infrastructure first | 14:20 |
| sc` | we can absolutely do kitchen-vagrant effectively today, but need to be able to spin up vagrant instances | 14:20 |
| jklare | adding vagrant is a good first step, but i think we should not remove the other stuff in this step | 14:20 |
| sc` | kitchen-dokken is my in-my-head goal, that may or may not be an exercise in madness | 14:20 |
| sc` | as soon as chefdk is bumped past 1.1 or so, the provisioning cookbook stops working | 14:21 |
| sc` | my guess is cheffish changes that need to be made, but i only have so many hours and can't chase all the dependencies | 14:21 |
| jklare | i think another way of approaching the whole topic of integration testing is wrapping the chef cookbooks in something that is able to orchestrate them and automate the setup of a all-in-one or multi-node setup | 14:21 |
| jklare | my preferred tool for this job would be ansible right now | 14:22 |
| sc` | we can do some scripts that get kicked off in a similar manner as other repos. it's almost where i've been going with test-kitchen | 14:22 |
| jklare | since its pretty easy to write down a deployment path of a all-in-one openstack in a ansible playbook | 14:22 |
| jklare | same goes for multi-node imho | 14:22 |
| sc` | well, if we're bootstrapping with ansible, don't really need all-in-one | 14:23 |
| jklare | i think test-kitchen might be the wrong tool here, since its not able to work with multi-node scenarios as far as i know | 14:23 |
| sc` | just use multi out of the box, advocate that path | 14:23 |
| jklare | sure, why not | 14:24 |
| sc` | aio is kind of an antipattern, really. it's good for quick proof of concept 'does openstack stand up' but not much else | 14:24 |
| sc` | you can't do a real deploy with that layout | 14:24 |
| jklare | agreed, but its also the only working thing we have right now :) | 14:24 |
| sc` | sadly :D | 14:24 |
| jklare | and i think it might be easier to start with that and work from there | 14:24 |
| sc` | vagrantfile does a reasonable multi node but it may need refinement | 14:25 |
| jklare | sure, but it might be hard to integrate that into an automated setup | 14:25 |
| sc` | yeah | 14:25 |
| jklare | i have not tried the vagrant-openstack stuff for a very long time, but as far as i know the only backend which keeps working with all releases is virtualbox | 14:26 |
| sc` | ideally, chef-provisioning would be the place to go, but i'm really not wanting to become a defacto maintainer of a driver | 14:27 |
| jklare | so if we stick with vagrant for our automated testing, we might need to invest a lot of resources to get the automated testing to work | 14:27 |
| jklare | agreed, and i also agree that we can not maintain another chef project ;) | 14:27 |
| jklare | ok, so how about i sit down with the ansible experts in my team and we try to figure out a way of setting up a simple integration testing setup for the openstack-cookbooks orchestrated by ansible | 14:28 |
| sc` | they don't want it, but they appear to maintain the vagrant provisioner for tk, for whatever reason, which is why i kept thinking the tk route would be more suitable | 14:29 |
| jklare | i mean we are kind of doing that for our production setup right now | 14:29 |
| sc` | see? even you're retooling :) | 14:29 |
| jklare | not retooling, just adding tools | 14:29 |
| sc` | and the knock on effect is you have ansible experts | 14:30 |
| sc` | either you hired them, or grew them :) | 14:30 |
| jklare | grew them | 14:30 |
| jklare | :) | 14:30 |
| jklare | because chef can not orchestrate | 14:30 |
| jklare | ansible can | 14:30 |
| sc` | that's what people keep saying, and recommend terraform because /shrug | 14:30 |
| jklare | both together are amazing | 14:31 |
| sc` | indeed | 14:31 |
| jklare | so what do you think about going into that direction? | 14:31 |
| *** os4uinfo has joined #openstack-chef | 14:31 | |
| *** chlong_ has joined #openstack-chef | 14:31 | |
| sc` | that could work | 14:31 |
| jklare | ok, i will try to get some things together until mid next week | 14:32 |
| sc` | ansible is already available in openstack ci, so it can be leveraged pretty handily | 14:32 |
| jklare | yeah | 14:32 |
| sc` | it wouldn't be a big up front anything | 14:33 |
| sc` | just a 'small' playbook to wrap things together | 14:33 |
| sc` | multinode is really easy out of the box. just moving things out by role, really | 14:33 |
| jklare | it basically should not be more than a rewrite of the provisioning cookbook in ansible | 14:33 |
| sc` | yeah, pretty much | 14:33 |
| jklare | ok, i will try to get it to a first working stage and we can discuss next week were we wanna go from there | 14:34 |
| sc` | i've barely used ansible because chef requires keeping so many mental mappings, that ansible went to cold storage | 14:34 |
| sc` | happy to start down that path, though | 14:35 |
| jklare | i usually hate writing ansible playbooks, since you cant use logic.... | 14:35 |
| jklare | but as said, you dont need logic for orchestration, just order | 14:35 |
| sc` | yeah. the overcloud stuff can come later, since we can just use images for that, if we wanted to show that off | 14:37 |
| sc` | i'd like to get to a point where we can start poking real upgrades | 14:37 |
| sc` | the db migration bits will help, with enough rework to make them fit properly | 14:37 |
| *** os4uinfo has quit IRC | 14:37 | |
| *** chlong has joined #openstack-chef | 15:23 | |
| *** chlong has quit IRC | 15:26 | |
| *** chlong_ has quit IRC | 15:58 | |
| *** chlong_ has joined #openstack-chef | 16:15 | |
| *** os4uinfo has joined #openstack-chef | 16:19 | |
| *** os4uinfo has quit IRC | 16:26 | |
| *** ch-mhass has quit IRC | 16:37 | |
| *** chlong_ has quit IRC | 17:21 | |
| *** os4uinfo has joined #openstack-chef | 17:22 | |
| *** os4uinfo has quit IRC | 17:28 | |
| *** chlong_ has joined #openstack-chef | 17:34 | |
| *** os4uinfo has joined #openstack-chef | 19:10 | |
| *** chlong_ has quit IRC | 19:14 | |
| *** os4uinfo has quit IRC | 19:17 | |
| *** chlong_ has joined #openstack-chef | 19:30 | |
| *** chlong_ has quit IRC | 19:55 | |
| *** chlong_ has joined #openstack-chef | 20:44 | |
| *** os4uinfo has joined #openstack-chef | 20:59 | |
| *** os4uinfo has quit IRC | 21:05 | |
| *** chlong_ has quit IRC | 21:18 | |
| *** os4uinfo has joined #openstack-chef | 22:29 | |
| *** os4uinfo has quit IRC | 23:04 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!