#openstack-chef December 2, 2013

gistfile1.txt

The topic for #openstack-chef is: OpenStack & Chef | wiki.openstack.org/wiki/Chef/GettingStarted  | groups.google.com/group/opscode-chef-openstack | github.com/stackforge/openstack-chef-repo (8:33:15 AM)
Topic for #openstack-chef set by mattray!~Opscode@pdpc/supporter/21for7/mrayzenoss at 10:30:18 on 08/16/13 (8:33:15 AM)
mode (+o mattray) by ChanServ (8:33:17 AM)
8:35:23 AM mattray: Good morning good evening wherever you are 
9:14:42 AM openstackgerrit: Matt Ray proposed a change to stackforge/cookbook-openstack-compute: Relax the dependency on openstack-identity to the 7.x series  https://review.openstack.org/59419
9:17:10 AM openstackgerrit: Matt Ray proposed a change to stackforge/cookbook-openstack-block-storage: Relax the dependency on openstack-identity to the 7.x series  https://review.openstack.org/59421
9:18:34 AM openstackgerrit: Matt Ray proposed a change to stackforge/cookbook-openstack-compute: Relax the dependency on openstack-identity to the 7.x series  https://review.openstack.org/59419
mode (+o carlp) by ChanServ (9:18:38 AM)
9:21:50 AM openstackgerrit: Matt Ray proposed a change to stackforge/cookbook-openstack-block-storage: Relax the dependency on openstack-identity to the 7.x series  https://review.openstack.org/59421
9:25:24 AM openstackgerrit: Matt Ray proposed a change to stackforge/cookbook-openstack-image: Relax the dependency on openstack-identity to the 7.x series  https://review.openstack.org/59429
9:29:03 AM openstackgerrit: Matt Ray proposed a change to stackforge/cookbook-openstack-metering: Relax the dependency on openstack-identity to the 7.x series  https://review.openstack.org/59432
galstrom_zzz is now known as galstrom (9:29:58 AM)
9:40:41 AM openstackgerrit: A change was merged to stackforge/cookbook-openstack-metering: Adding qpid support to ceilometer  https://review.openstack.org/56802
9:41:56 AM openstackgerrit: A change was merged to stackforge/cookbook-openstack-network: Adding qpid support to quantum  https://review.openstack.org/56795
9:42:20 AM openstackgerrit: A change was merged to stackforge/cookbook-openstack-image: Adding qpid support to glance  https://review.openstack.org/56494
9:43:48 AM openstackgerrit: A change was merged to stackforge/cookbook-openstack-block-storage: Adding qpid support to cinder  https://review.openstack.org/56801
9:49:35 AM openstackgerrit: A change was merged to stackforge/cookbook-openstack-compute: Relax the dependency on openstack-identity to the 7.x series  https://review.openstack.org/59419
9:51:10 AM openstackgerrit: Matt Ray proposed a change to stackforge/cookbook-openstack-block-storage: Relax the dependency on openstack-identity to the 7.x series  https://review.openstack.org/59421
9:53:36 AM carlp: Morning everyone
9:54:03 AM openstackgerrit: Matt Ray proposed a change to stackforge/cookbook-openstack-block-storage: Relax the dependency on openstack-identity to the 7.x series  https://review.openstack.org/59421
9:54:13 AM s2r2: hi carl
9:56:33 AM mattray: https://plus.google.com/hangouts/_/76cpjqnj8rpr5go3gmpo80add8?authuser=0&hl=en
9:56:37 AM mattray: try that for the hangout
9:56:45 AM openstackgerrit: Salman Baset proposed a change to stackforge/cookbook-openstack-compute: Fixing console auth service and process names for RHEL.  https://review.openstack.org/59245
9:56:54 AM mattray: the YouTube link will be available after we go on air
9:57:16 AM spheromak: just gettin my coffee then ill be there
10:00:41 AM markvan: Hello
10:02:47 AM mattray: everyone in the chat who wants to be there?
10:03:22 AM mattray: http://youtu.be/w_ntCn1yUmQ
10:03:22 AM DeVVaN: think so yes
10:05:18 AM judd7: I'm late!
10:05:19 AM judd7: 
10:06:21 AM mattray: https://gist.github.com/mattray/7683491
10:06:56 AM carlp: ^^ That link describes the ThorSCM stuff being added to the repos
10:07:19 AM judd7: VERY NICE!
10:10:20 AM jaypipes: https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/jenkins_job_builder/config/chef-jobs.yaml
10:10:47 AM jaypipes: https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/jenkins_job_builder/config/macros.yaml#L110
10:11:05 AM openstackgerrit: Alan Meadows proposed a change to stackforge/cookbook-openstack-network: Make wsgi attributes overridable  https://review.openstack.org/59470
10:11:14 AM mattray: email will be forthcoming on the ThorSCM stuff
10:13:40 AM ehaselwanter: we have wrapper cookbooks for the grizzly-stackforge cookbooks to run havana: https://github.com/cloudbau/cookbook-openstack-network-wrapper/tree/master/recipes
ctracey|away is now known as ctracey (10:16:24 AM)
10:16:54 AM jaustinpage: o/
10:17:51 AM ehaselwanter: we have all the havana stuff in wrappers, not touching stackforge grizzly
10:23:49 AM markvan: first patch for havana neutron would be the name change?  Someone signed up for that?
10:24:57 AM judd7: Reach out to Rob for the openstack-chef hack day.  Our whole team is starting on this.
10:25:48 AM judd7: mattray - DellWorld is in two weeks.  Best sooner rather than later.
10:26:30 AM ehaselwanter: there is our heat one
10:26:30 AM ehaselwanter: https://github.com/cloudbau/cookbook-openstack-orchestration/blob/master/recipes/default.rb
10:26:33 AM ehaselwanter: a little bit dated
10:27:37 AM galstrom: jaypipes: did you want the rubocop stuff inline with the chef-cookbook-lint stuff in macros.yml?
10:27:43 AM galstrom: or were you wanting another builder?
10:28:01 AM spheromak: galstrom: i think its fine in the linter
10:28:04 AM spheromak: makes sense
10:28:17 AM galstrom: i guess i meant the style on..
10:28:20 AM galstrom: not the linter
10:28:21 AM galstrom: 
10:28:25 AM jaypipes: galstrom: inline, I think... thoughts?
10:28:40 AM jaypipes: galstrom: though... the linter is a voting gate.
10:28:43 AM galstrom: i think that is fine..
10:28:47 AM galstrom: that is what i was worried about
10:29:01 AM galstrom: we can gen a rubocop config.. that will pass on each repo
10:29:13 AM galstrom: and then we can remove stuff from the conf as they get fixed..
10:29:22 AM galstrom: but that seems counter to the reason to have a non-voting job
10:29:27 AM galstrom: IMHO
10:29:49 AM spheromak: ya bit if it's voting right now it will all go
10:36:44 AM mattray: https://github.com/cloudware-cookbooks/ktc-compute/blob/master/.kitchen.yml
10:40:33 AM galstrom: jaypipes: where do non-voting jobs go?
10:40:43 AM galstrom: not in chef-jobs.yml
10:40:45 AM galstrom: i am guessing
10:42:42 AM spheromak: ehaselwanter: nice
10:42:51 AM spheromak: ehaselwanter: you have some cinder in your nova
10:43:01 AM spheromak: extra hot
mohits_ is now known as mohits (10:43:11 AM)
10:43:12 AM ehaselwanter: we have to do some cleanup
10:43:21 AM spheromak: just being cheeky
10:43:42 AM ctracey: spheromak: we all used to have some cinder in our nova 
10:43:46 AM ehaselwanter: using lvm to get some tests running
10:43:49 AM spheromak: ctracey: yea
10:44:01 AM galstrom: jaypipes: something like that? https://review.openstack.org/#/c/59478/
10:44:06 AM spheromak: ehaselwanter: yea i understand. openstack is a bitch with the deps
10:44:10 AM galstrom: jaypipes: not sure where the non-voting pipeline is
10:44:12 AM ehaselwanter: we now have some neutron in our quantum wrappers 
10:44:17 AM spheromak: 
10:45:00 AM ehaselwanter: building our own packages at the moment .. fpm to get havana from github
10:45:01 AM spheromak: jaypipes: galstrom mattray carlp et-al: forgot this thing, but is there plans for putting ruby 2.0 in the pipe as well at some point ?
10:45:23 AM spheromak: ehaselwanter: we are in process on same deal. Jenkins doing fpm builds out to nexus for the components
10:45:31 AM ctracey: i really need to get omnibus-openstack crackin again
10:45:38 AM spheromak: ctracey: yes
10:45:53 AM ctracey: the fact that most of nova doesnt use use stevedore is proving to be a real PITA
10:46:03 AM ctracey: and omnibus would help enormously there
10:46:08 AM ehaselwanter: yes
10:46:08 AM spheromak: ctracey: Wish I could find resources to work on that, but if you got anything on it already and its out there in the tubes link it to me.
10:46:23 AM ctracey: i only have a POC on gh
10:46:28 AM ehaselwanter: we have jenkins running to spit out the packages
10:46:33 AM carlp: spheromak: since chef is going 2.0, I would say yes at some point...
10:46:34 AM spheromak: ctracey: better than nothing
10:46:44 AM ctracey: there were a number of changes I would need to make to omnibus itself
10:46:48 AM ctracey: s/need/want/
10:46:52 AM ehaselwanter: thinking "just a repo" to get them on the boxes
10:47:12 AM ctracey: we build from source now...im not in love with it
10:47:21 AM spheromak: we can't build from source in prod
10:47:25 AM carlp: ctracey: I would like to help you on that effort as part of my packaging project
10:47:36 AM spheromak: KT has some 1995 sec requirements 
10:47:49 AM ctracey: i need to get through this sprint and then I might have some good cycles for it
10:48:18 AM spheromak: ctracey: whats the link to the omni stuff you have now. I might have some time to get someone on it
10:48:50 AM spheromak: in the next 2 weeks. We are quite interested in going omni route, since we are putting alot of time into component builds. We could be building just a full omni build
10:49:05 AM ctracey: https://github.com/craigtracey/omnibus-openstack (dont judge  )
10:49:10 AM spheromak: judd7: i thought you guys were working on it
10:49:25 AM spheromak: ctracey: no judgement any bad code is better than no code 
10:49:28 AM ctracey: this was done in a very hort amount of time
10:49:48 AM ctracey: basic idea is to build venvs
10:49:50 AM spheromak: ctracey: have you seen some of the shit i've put out  ;P
10:50:17 AM judd7: spheromak - omnibuilder?  Not so much.
10:50:23 AM judd7: We're starting to look into it.
10:50:26 AM ctracey: and then run from there...all would share an openstack-common package
10:50:35 AM judd7: omnibus, i mean.
10:51:02 AM ctracey: inside openstack-common would live all system and global python deps
10:51:15 AM mattray: spheromak: I think we go to Ruby 2.0 when Chef goes to Ruby 2.0… probably with Chef 12
10:51:24 AM ctracey: that model doesnt really jive with omnibus proper
10:51:41 AM ctracey: they want every package to have every dependency
10:51:54 AM mattray: spheromak: I think Ruby 2.0 support is still not official yet
10:51:55 AM ctracey: and that seemed like overkill to me
10:52:10 AM ctracey: esp when your deps are so inter-related
10:52:18 AM spheromak: yea
10:52:23 AM spheromak: ctracey: i agree
10:52:32 AM spheromak: ctracey: my idea was an omnit that built all of it in one shot
10:52:45 AM spheromak: and then you just toggle componets on/off depending on what the target is
10:52:52 AM ctracey: yes
10:52:56 AM ctracey: that is what this does
10:52:59 AM spheromak: yep
10:53:01 AM spheromak: thats sick
10:53:04 AM spheromak: im cloning
10:53:14 AM ctracey: but...you always need to build openstack-common first
10:53:16 AM spheromak: does it blend ?
10:53:42 AM ctracey: im guessing i have a bunch of uncommitted code at home
10:53:50 AM ctracey: i can take a gander this evening
10:53:55 AM spheromak: well i forked yea push whatever.
10:54:06 AM ctracey: ill keep ya updated
10:54:12 AM judd7: which repo?  ctracey
10:54:13 AM spheromak: if its even mostly building. I would prefer to go this route vs the per-project builds in jenkins
10:54:14 AM ctracey: esp as we have an interest in it
10:54:24 AM ctracey: despite using *cough* ansible
10:54:25 AM judd7: o, there, got it ctracey
10:54:34 AM spheromak: ctracey: yea funny I have to fight ansible here.
10:54:46 AM spheromak: devs use it alot. cause they refuse to ruby
10:54:55 AM ctracey: im not the biggest fan tbh
10:54:59 AM spheromak: neither am I
10:55:03 AM ctracey: but it is what it is
10:55:11 AM spheromak: big static files for orchistration..
10:55:13 AM spheromak: yep
10:55:30 AM ehaselwanter: we spin up multinode from jenkins on openstack ..
10:55:32 AM spheromak: w/e they get thier shit done, and ops folk get their shit done.  I'm not stressed.
10:55:40 AM spheromak: ehaselwanter: how are you doing this ?
10:55:43 AM ctracey: yaml not descriptive enough and feels like I need to reinvent the wheel often
10:55:58 AM ehaselwanter: spheromak: what do you mean how?
10:55:59 AM spheromak: ehaselwanter: can you do link to jobs or configs ?
10:56:04 AM spheromak: what are you using to do it
10:56:06 AM spheromak: just vagrants
10:56:08 AM spheromak: lxc
10:56:11 AM spheromak: stack on stack ?
10:56:27 AM ehaselwanter: vagrants at the moment
10:56:29 AM spheromak: ehaselwanter: i've been down many roads to getting multi-node integration.
10:56:40 AM spheromak: ehaselwanter: I ran into concurrent builds borking vagrant
10:56:44 AM ehaselwanter: working on opensourcing the stuff
10:57:06 AM spheromak: ctracey: yea it felt like the same restrictions i had during early puppet
10:57:22 AM spheromak: ctracey: verry tears dsl that required alot of copy-paste :\
10:57:27 AM spheromak: *tears
10:57:30 AM spheromak: gdmf
10:58:03 AM ctracey: i think it is worse than puppet actually
10:58:08 AM ctracey: its hard to compose
10:58:16 AM spheromak: ehaselwanter: I have some stuff doing the same with vagrant, but when i used the vbox driver it blew up on concurrent builds. I want to move to stack on stack with a vagrant middleware.
10:58:20 AM ctracey: there is nothing like a librarian/berks
10:58:39 AM spheromak: yea but the whipuptitude is high for new folks
10:58:43 AM spheromak: and so it gets traction
10:58:46 AM spheromak: I've seen that here
10:58:58 AM spheromak: tho chef-client -z helps I think in this reguard
10:59:20 AM ctracey: fair point
10:59:22 AM spheromak: also my failing in getting working dev setups for openstack built with chef into peoples hands.
10:59:33 AM spheromak: and chef-apply.
10:59:57 AM spheromak: no reason we can't build a dumb yaml parser that looks alot like ansible with chef under it
10:59:58 AM ctracey: i can appreciate wanting to run agentless
11:00:06 AM spheromak: oh wait, mattray already did that 
11:00:18 AM spheromak: ctracey: for sure
11:00:22 AM ctracey: *cough* pushy needs to be opensourced *cough*
11:00:27 AM spheromak: srsly
11:00:32 AM mattray: yeah… fwiw, we're starting up an orchestration project in the open
11:00:36 AM ehaselwanter: this will be in repo of its own soon
11:00:36 AM ehaselwanter: https://gist.github.com/mouadino/7edfd198fe1cc26cfd2d/
11:00:49 AM ehaselwanter: ugly but works
11:00:51 AM ehaselwanter: 
11:01:01 AM ctracey: serf + chef-solo...done
11:01:05 AM ctracey: 
11:01:05 AM spheromak: well i sat in that room with opscode CEO and told em that pushy has no advantage as closed source project. and that serf will establish itself unless they do something fast.
11:01:06 AM mattray: john keiser's lead on it, still early but he has some stuff working already
11:01:10 AM spheromak: ctracey: yip
11:01:19 AM mattray: spheromak: engineering is working on it
11:01:25 AM spheromak: mattray: i know 
11:01:30 AM spheromak: but serf is now 
11:01:37 AM mattray: yup
11:01:40 AM spheromak: different things
11:01:42 AM spheromak: sorta.
11:01:52 AM spheromak: need my hands on pushy to decide
11:02:13 AM spheromak: but we are moving more an more towards a client -z + etcd + serf + nexus
11:02:25 AM spheromak: or chef-server just as cookbook artifact server
11:02:33 AM ctracey: yes
11:02:42 AM ctracey: taht is where i see it going as well
11:03:11 AM ehaselwanter: spheromak:  for vagrant openstack we created this one: https://github.com/cloudbau/vagrant-openstack-plugin
11:03:15 AM mattray: spheromak: on your internal package deployments, is that where Nexus is used?
11:03:23 AM spheromak: mattray: yea
11:03:32 AM spheromak: thats the goal right now. its not up yet
11:03:42 AM mattray: I was talking to one of the Facebook guys, they find yum repos too slow
11:03:42 AM spheromak: we have some build jobs that are emitting to nexus
11:03:57 AM mattray: no yum equivalent of debtorrent
11:04:06 AM spheromak: yea i could see that
11:04:26 AM mattray: not a common problem 
11:04:27 AM spheromak: we are still central. as the openstack project isn't on par with our cloud stack deploy yet
11:04:36 AM ehaselwanter: spheromak: for the quick an dirty devstack hackers we have https://github.com/cloudbau/devstack-chef
11:04:49 AM spheromak: but the target will end up in the 800 racks in ~16 months. Assuming we succeede 
11:04:54 AM spheromak: mattray: good to hear
11:05:27 AM spheromak: the issues that they face we are going to be close to the 20k nodes mark ourselves
11:05:31 AM ehaselwanter: spheromak: that sounds interesting
11:05:50 AM ehaselwanter: can you talk about what you use for networking then?
11:05:53 AM spheromak: ehaselwanter: yea cept i can't do devstack
11:05:58 AM spheromak: l3
11:06:01 AM spheromak: routed
11:06:06 AM ehaselwanter: *lol*
11:06:09 AM ehaselwanter: but OSS ?
11:06:40 AM ehaselwanter: was in a meeting with a client last week: again -> we *MUST* have L2
11:06:52 AM jaustinpage_: spheromak: what is -z? nexus? not finding it on google searches... :-/
11:07:00 AM spheromak: yea we did l2 on the Ucloud deploy of cloudstack
11:07:06 AM spheromak: and a couple weeks back there was a loop
11:07:08 AM spheromak: 
11:07:19 AM spheromak: 20k nodes were down for ~26 hours
11:07:21 AM ehaselwanter: any commerzial plugins used?
11:07:26 AM spheromak: while people tracked it down
11:07:27 AM ehaselwanter: wohoooo
11:07:30 AM spheromak: ehaselwanter: not at the moment
11:07:41 AM mattray: jaustinpage_: -z is chef-client using Chef Zero
11:07:43 AM spheromak: jaustinpage_: chef-client -z is chef 11
11:07:46 AM spheromak: 11.8
11:07:46 AM ehaselwanter: > 40 nodes and using OVS ?
11:07:53 AM jaustinpage_: ahh, gotcha
11:08:12 AM mattray: jaustinpage_: Nexus is a package distribution tool
11:08:20 AM mattray: commercial
11:08:20 AM spheromak: its an artifact repo
11:08:35 AM spheromak: object storage basically with metadata tied to them 
11:08:46 AM spheromak: cand do pretty much the same thing ontop of any object store.
11:08:53 AM spheromak: s3/swift/blargh
11:08:58 AM ehaselwanter: spheromak: because it is already there?
11:09:00 AM jaustinpage_: yep, cool
11:09:10 AM spheromak: ehaselwanter: cause whats already there ?
11:09:16 AM ehaselwanter: not introduced for the openstack packages .. nexus
11:09:30 AM spheromak: ah yea cause we use it for code
11:09:35 AM spheromak: for other projects already
11:09:37 AM ehaselwanter: yeah, thought so
11:09:46 AM spheromak: so tossing packages there too
11:10:18 AM spheromak: ehaselwanter: https://github.com/cloudware-cookbooks/ktc-network you can look at it here. this is not running at scale now. only ~12 racks in "release"
galstrom is now known as galstrom_zzz (11:10:26 AM)
galstrom_zzz is now known as galstrom (11:10:36 AM)
11:10:39 AM spheromak: ehaselwanter: that cook might go private soon
11:10:57 AM spheromak: actually fighting with KT over github right now.
11:11:05 AM spheromak: so all our shit might end up off github soon.
11:11:11 AM ctracey: hah
11:11:37 AM spheromak: It's like they read the 1st chapter of phoenix project and decided that was how it should be done.
11:11:39 AM spheromak: 
11:11:49 AM ctracey: its not?
11:12:24 AM judd7: spheromak - you've created a meme: "My client is so 'chapter 1'"
11:12:37 AM spheromak: judd7: lol yea for real
11:13:00 AM jaustinpage_: you guys have not heard of a go-based config management or templating engine yet, have you/
11:13:01 AM jaustinpage_: ?
11:13:08 AM judd7: Sometimes we just say, "Dell I.T."
11:13:18 AM spheromak: jaustinpage_: i've drempt about writing one. And thought about what engine to use.
11:13:28 AM jaustinpage_: spheromak
11:13:39 AM spheromak: jaustinpage_: theres a minimal ruby parser for go
11:13:49 AM spheromak: i've worked on a golib for talking to chef-server
11:13:53 AM judd7: jaustinpage_ "gobar" is a skunkworks project at Dell.  It's getting no time because we're so commited to Ruby.
11:14:01 AM spheromak: and someone wrote a go based chef-server ala chef-zero
11:15:13 AM spheromak: jaustinpage_: embedded lanuages for go: scheme, js, lua
11:15:43 AM jaustinpage_: spheromak: with etcd, docker, flynn, serf, it is only a matter of time before people use it to manage config files while they are at it
11:15:47 AM spheromak: like i was talking with ctracey a tool for CM should be mungable. I wouldn't want it to be built with a non dynamic DSL.
11:15:52 AM spheromak: yea
11:16:05 AM spheromak: the builtin template engine isn't super hot IMO either.
11:16:25 AM jaustinpage_: Ive been looking at that and not exactly been super happy
11:16:30 AM spheromak: I was looking into how i could take all the chef and parse the AST and eval in a diff client.
11:17:13 AM jaustinpage_: hmm
11:17:15 AM spheromak: the providers would have to be more like what mitchell did in packer. using RPC
11:17:25 AM jaustinpage_: on the templates side, this got my attention: http://mustache.github.io/
11:17:33 AM spheromak: and you would be arbitrarily executing binaries that you ship to nodes.
11:17:38 AM spheromak: yea
11:18:00 AM spheromak: oh didn't see the mustache go implementation
11:18:05 AM jaustinpage_: yep
11:18:17 AM spheromak: Go is getting traction. Good to see. many things to like about it.
11:18:44 AM jaustinpage_: which would mean that regardless of the cm, mustache templates should be mungable
11:19:13 AM spheromak: yea tho the provider abstraction is the powerfull construct in these tools.
11:19:26 AM jaustinpage_: yes, it is
11:19:28 AM spheromak: puppet / luke did that right, and what started all of this
11:19:58 AM spheromak: I would like something that had an interface model for providers tho.
11:20:29 AM spheromak: looks alot like packer
galstrom is now known as galstrom_zzz (11:20:43 AM)
11:20:45 AM jaustinpage_: on the orchestration side though, etcd + distributed logic driving cm of some kind is looking really interesting. especially after seeing serf..
11:20:59 AM spheromak: anyhow no time to actually write this. I spend idle minutes contemplating it
11:21:05 AM spheromak: yea
11:21:11 AM spheromak: serf + etcd = win IMO
11:21:25 AM spheromak: though i have not had extensive play time with serf. conceptually
11:21:33 AM spheromak: they seem like a strong matchup
11:21:36 AM jaustinpage_: i just saw it seconds ago...
11:21:39 AM jaustinpage_: yes
11:21:47 AM spheromak: Ive got it running locally on my lab
11:22:21 AM spheromak: still needs some time in the oven, but a damn fine start. I love the event implementation. Really ops friendly
11:22:30 AM jaustinpage_: nice
11:22:47 AM jaustinpage_: i did not realize etcd maintained any sort of quorum...
11:22:53 AM spheromak: *tries to bring it back to chef *
11:23:01 AM spheromak: jaustinpage_: its atomic
11:23:08 AM spheromak: has to have quorum for commit
11:23:19 AM spheromak: part of the raft impl
11:23:27 AM jaustinpage_: right, that makes sense
11:24:10 AM spheromak: still subject to partitioning issues tho I haven't run the jepsen test on it. I assume that there are split brain fail modes that are less than ideal.
11:24:41 AM jaustinpage_: since serf doesnt seem to care about network partitions, it seems like you might be able to build temporary etcd when you detect that you are all alone, and then try to merge back when networking is restored....
11:24:54 AM jaustinpage_: that could get crazy
11:25:07 AM spheromak: well its journal replays
11:25:19 AM spheromak: so anyting that doesn't align. I'm not sure what will happen
11:25:27 AM spheromak: def testable
11:25:35 AM spheromak: I just haven't gone down that road with it yet.
11:26:26 AM spheromak: right now its one etcd node per rack of openstack. per zone.
11:26:53 AM spheromak: but we have resources that are streaching beyond a zone. so i have to deal with that.
11:27:06 AM spheromak: still not 100% on how it should all lay out
11:27:21 AM jaustinpage_: how many pieces of hardware?
11:27:46 AM spheromak: compute nodes there are ~20 in each rack
11:28:22 AM spheromak: but the failure tolerance we are going for is a single rack
11:28:40 AM spheromak: should be able to loose a whole rack in a zone and remain functional
11:28:58 AM jaustinpage_: right
11:31:17 AM spheromak: jaustinpage_: worth reading this issue on serf: https://github.com/hashicorp/serf/issues/61
11:31:22 AM spheromak: if you are looking into it
11:31:31 AM jaustinpage_: thanks
11:35:49 AM jaustinpage_: ohh wow, this is good stuff to know, thanks spheromak
galstrom_zzz is now known as galstrom (11:44:11 AM)
11:50:30 AM spheromak: ctracey: you got a .json config file for your omni builder anywhere ? should i just wait till you can push stuff up.
zz_timnovinger is now known as timnovinger (11:57:11 AM)
galstrom is now known as galstrom_zzz (11:58:15 AM)
1:00:15 PM openstackgerrit: Alan Meadows proposed a change to stackforge/cookbook-openstack-network: Make wsgi attributes overridable  https://review.openstack.org/59470
1:04:07 PM spheromak: alanmeadows: but the template config on that won't work if i am patched and on griz right ?
1:06:53 PM alanmeadows: spheromak: That is correct, unless you modify the patch to use "api_workers" instead.  I mean it will work, but twiddling api_workers wont help since it wants "workers"
1:07:13 PM alanmeadows: I wish the patch would of been forward looking and used the same configuration parameter that havana uses, but unfortunately it does not
1:07:28 PM spheromak: yea
1:07:42 PM alanmeadows: I could make the parameter itself changeable, but just seems a bit crufty -- are you using that patch right now?
1:08:00 PM spheromak: thats realy my only objection. what i meant was it won't work when patched on griz. maybe better to just punt on griz ?
1:08:01 PM alanmeadows: We're using our own variant of it, but we use the forward looking api_workers parameter
1:08:14 PM spheromak: we can mod the patch
1:08:23 PM alanmeadows: That would set things golden 
galstrom_zzz is now known as galstrom (1:08:46 PM)
1:09:39 PM spheromak: jsut seems like it is a bit heavy of a req for someone to have to mod thepatch vs change an attrib.
1:10:23 PM spheromak: really doens't matter to me either way. Just thinking what is best for the wider udience
1:10:31 PM spheromak: *audience
1:10:47 PM alanmeadows: Let me see if I can get the patch updated so it uses api_workers
1:11:14 PM alanmeadows: That would be the best outcome -- I'm only pushing for this because grizzly is basically unusable in a production environment without multiple workers
1:11:20 PM spheromak: yea
1:11:41 PM spheromak: i want the change, I just want the cases covered
1:16:10 PM openstackgerrit: John Dewey proposed a change to stackforge/cookbook-openstack-image: Relax the dependency on openstack-identity to the 7.x series  https://review.openstack.org/59429
1:17:35 PM openstackgerrit: John Dewey proposed a change to stackforge/cookbook-openstack-image: Relax the dependency on openstack-identity to the 7.x series  https://review.openstack.org/59429
2:09:35 PM mattray: retr0h: on the CHANGELOG.md formats… I was mostly focusing on the ## VERSIONs to be consistent so the Thor::SCMVersion would find them correctly
2:09:56 PM mattray: I need to find a good example of the exact format we should be using
2:10:37 PM mattray: since I see the use of ### Bug is inconsistent 
2:15:02 PM retr0h: right
2:15:09 PM retr0h: im just looking at each changelog
2:15:17 PM retr0h: and they were diff
2:15:20 PM retr0h: so didn't know what to think
2:15:36 PM retr0h: in reality that change should be in a diff commit
2:15:44 PM retr0h: per the patch message you are just relaxing the version
2:16:02 PM retr0h: but i didn't wanna be that nitty heh
2:16:23 PM retr0h: deff would like all our changelogs and readmes to all be the same format
2:25:32 PM mattray: retr0h: welp, the Thor::SCMVersion script I wrote is going to be the new standard, so we can adjust them now
2:25:33 PM mattray: https://gist.github.com/mattray/7683491
2:25:48 PM mattray: it's just ## VERSION followed by "* commit message"
2:26:10 PM mattray: so now's the time to clean up one or the other or both
galstrom is now known as galstrom_zzz (2:29:20 PM)
2:31:13 PM alop: mattray: so, for the existing cookbooks, you're going to incorporate this, or is it up to all of us?
2:31:45 PM mattray: alop: the SCM script will just pre-pend to the top
2:32:00 PM mattray: it looks for the previous version and inserts 
2:32:12 PM alop: oh, so no need to modify?
2:32:15 PM mattray: nope
2:32:18 PM alop: cool beans
2:32:23 PM mattray: unless we want them all to be consistent
2:32:35 PM mattray: the changes I made were just to get the ## Version in place
2:32:46 PM mattray: since the SCM script looks for that
2:32:53 PM mattray: as opposed to the version underlined
2:33:02 PM mattray: both of which are fine for markdown
2:38:01 PM spheromak: oh
2:38:13 PM spheromak: mattray: gotta tag the repos versions
2:38:20 PM spheromak: to start. I didn't check if they are already tagged or not
2:38:50 PM mattray: spheromak: oh yeah, they're not
2:38:53 PM mattray: they need it
2:38:56 PM spheromak: yea no tags, so we need to tag the repo with the first version so that thor scmver will function
2:39:01 PM mattray: right
galstrom_zzz is now known as galstrom (3:03:42 PM)
3:10:04 PM openstackgerrit: Matt Ray proposed a change to stackforge/cookbook-openstack-metering: Relax the dependency on openstack-identity to the 7.x series  https://review.openstack.org/59432
3:11:38 PM retr0h: i do suggest one thing
3:11:46 PM retr0h: if we are going to add things into the gate
3:11:54 PM retr0h: we put it on a test repo or something
3:12:11 PM retr0h: b/c if the gating fails we all must wait for the openstack-infra guys to merge fixes
3:12:28 PM retr0h: and last time we did this, we couldn't do work for about 2 weeks
3:12:33 PM retr0h: due to failed gates
3:14:26 PM openstackgerrit: Paul Czarkowski proposed a change to stackforge/cookbook-openstack-network: only run recipes if quantum or neutron  https://review.openstack.org/55733
3:15:34 PM galstrom: mattray: https://review.openstack.org/#/c/59432.. do we need all the version entries do be consistent (so empty lines in the middle of a version block)?
3:16:14 PM mattray: galstrom: nope. The SCM script just looks for "## VERSION" of the previous and inserts the new one there
3:16:21 PM galstrom:  ok
3:16:35 PM mattray: so we can leave the existing changelogs alone, but we'll need tags
3:18:50 PM mattray: retr0h: on https://review.openstack.org/#/c/59421/4/CHANGELOG.md what changes do you want?
3:24:08 PM openstackgerrit: Matt Ray proposed a change to stackforge/cookbook-openstack-image: Relax the dependency on openstack-identity to the 7.x series  https://review.openstack.org/59429
3:38:09 PM retr0h: mattray: prob doesn't matter I just noticed spacing wasn't consistent thats all
3:38:28 PM mattray: retr0h: the diff spacing looked weird, but the file spacing looked fine to me
3:42:04 PM retr0h: sure
3:42:06 PM retr0h: what i mean is
3:42:08 PM retr0h: https://review.openstack.org/#/c/59421/4/CHANGELOG.md
3:42:28 PM retr0h: on the left you see v7.0.6 and directly under it ### Bug
3:42:34 PM retr0h: on the right you added a space
3:42:41 PM retr0h: but u only did that for some
3:43:05 PM retr0h: 7.2.1 , 7.2.0, 7.1.0 dont have spaces
3:43:24 PM retr0h: if we are going to change the format of the file I felt we should make it the same so others can follow suit
3:44:19 PM retr0h: this for example you didn't add spacing (https://review.openstack.org/#/c/59429/4/CHANGELOG.md)
3:44:23 PM retr0h: just like things to be the same
3:48:04 PM openstackgerrit: A change was merged to stackforge/cookbook-openstack-image: Relax the dependency on openstack-identity to the 7.x series  https://review.openstack.org/59429
4:00:08 PM openstackgerrit: Matt Ray proposed a change to stackforge/cookbook-openstack-block-storage: Relax the dependency on openstack-identity to the 7.x series  https://review.openstack.org/59421