| *** sdake has quit IRC | 00:24 | |
| *** erkules has quit IRC | 00:41 | |
| *** sdake has joined #kolla | 00:48 | |
| *** sdake_ has joined #kolla | 00:58 | |
| sdake_ | samyaple arisen yet? | 01:01 |
|---|---|---|
| *** sdake has quit IRC | 01:01 | |
| *** tobe has joined #kolla | 01:05 | |
| *** diogogmt has quit IRC | 01:07 | |
| *** jasonsb has joined #kolla | 01:13 | |
| *** bradjones has quit IRC | 01:21 | |
| *** bradjones has joined #kolla | 01:29 | |
| *** bradjones has joined #kolla | 01:29 | |
| *** jasonsb has quit IRC | 01:29 | |
| *** loth has quit IRC | 01:43 | |
| *** diogogmt has joined #kolla | 01:49 | |
| *** jtriley has joined #kolla | 01:52 | |
| *** jtriley has quit IRC | 01:57 | |
| *** dims has quit IRC | 02:04 | |
| *** dims has joined #kolla | 02:08 | |
| *** bmace has quit IRC | 02:08 | |
| *** dims has quit IRC | 02:19 | |
| *** bmace has joined #kolla | 02:20 | |
| sdake_ | samyaple did you make it up yet :) | 02:43 |
| sdake_ | its almost 8pm and i need to hit the rack early today :) | 02:43 |
| *** sdake_ is now known as sdake | 03:00 | |
| SamYaple | i am here sdake | 03:13 |
| sdake | yay :) | 03:13 |
| sdake | did you see spec suggestions | 03:14 |
| sdake | looks like we are in the home stretch | 03:14 |
| SamYaple | just got to work | 03:14 |
| sdake | i see | 03:14 |
| sdake | that pesky work thing | 03:14 |
| SamYaple | sdake: I dont think CONFIG_STRATEGY_SOURCE_DIR="/opt/kolla/configs/keystone" needs to exist | 03:19 |
| sdake | ok remove then | 03:19 |
| sdake | we decided against that iirc | 03:19 |
| rbergeron | pesky eork! | 03:20 |
| rbergeron | work | 03:20 |
| sdake | more like pesky sdake | 03:20 |
| rbergeron | mayyybe | 03:20 |
| sdake | what wa your thinking on the pool idea | 03:20 |
| sdake | samyaple ^^ | 03:21 |
| sdake | just to be clear :) | 03:21 |
| SamYaple | my thinking is http://docs.ansible.com/intro_inventory.html | 03:21 |
| SamYaple | you want to implement pools, go for it | 03:21 |
| SamYaple | this doesnt stop you | 03:21 |
| SamYaple | we arent doing it in the project though | 03:22 |
| SamYaple | thats all ansible stuff | 03:22 |
| SamYaple | The inventory file can literally be a script. | 03:22 |
| sdake | i thin kthe suggestio nwas to implement pools | 03:23 |
| SamYaple | yea. but thats not a kolla suggestion. | 03:23 |
| SamYaple | pools/rack seperation would be implemented by the inventory | 03:23 |
| SamYaple | you can do all the inventory stuff you want..... with ansiblew | 03:23 |
| sdake | so whatever managed that file is what would manage the pools | 03:24 |
| SamYaple | correct | 03:24 |
| SamYaple | http://docs.ansible.com/intro_dynamic_inventory.html | 03:24 |
| sdake | think that is a valid responseo n the comment | 03:24 |
| SamYaple | that would probably be what your looking at, you can tie it into external systems as well | 03:24 |
| rbergeron | anything is possi-bull. so says the @ansibull! | 03:24 |
| sdake | looks like russian to me | 03:26 |
| sdake | so in essence what britt suggested was a third layer, on top of ansible | 03:26 |
| sdake | where the kolla-ansible script is currently | 03:26 |
| sdake | that creates the inventory files based upon some master config? | 03:26 |
| sdake | i htink we need to be open to the idea of scope expansio nfor the kolla-ansible script | 03:27 |
| SamYaple | im not sure exactly, but we already have groups (keystone runs on all the hosts in the keystone group) so you just need to setup the keystone group with the hosts you want in that group | 03:27 |
| sdake | possilby with a rewrite in python if it gets more complex | 03:27 |
| SamYaple | you can build the rack seperation yourself/dynamically | 03:27 |
| SamYaple | I am, but not at the moment | 03:28 |
| sdake | ya long term i mean | 03:28 |
| SamYaple | i want something clean and functional for Liberty | 03:28 |
| sdake | not initially | 03:28 |
| SamYaple | past that i have ideas about it myself | 03:28 |
| sdake | well 100 nodes = 3-4 racks | 03:28 |
| sdake | I'd like to get to 3-4 rack deploys | 03:28 |
| SamYaple | 100 x 2U == minimum 5 racks, more likely 6 | 03:29 |
| SamYaple | 100 nodes is alot | 03:29 |
| sdake | ok well you get the point | 03:29 |
| sdake | we need some way of managing the racks | 03:29 |
| sdake | sounds like the inventory file is not that thing | 03:29 |
| sdake | or is a building block for that thing | 03:30 |
| sdake | 100 nodes is what i set in my ptl bencmark announcement :) | 03:30 |
| sdake | number randomly picked out of my arse :) | 03:30 |
| sdake | so the abstraction is above the inventory file then? | 03:31 |
| sdake | just so I am completely clear on what was proposed | 03:31 |
| sdake | because britt seemed to indicate it went between kolla-ansible and the ansible files | 03:32 |
| SamYaple | I like 5 "support/control"x 5 storage x 100 computes benchmark | 03:32 |
| sdake | but to me it seems to go in kolla-ansible directly | 03:32 |
| SamYaple | it needs to be all ansible | 03:32 |
| SamYaple | has to be | 03:32 |
| sdake | so how does one implement what britt proposed | 03:33 |
| SamYaple | the orchastration is just how it arranges the services on the physical host. if you want keystone to run on controller01,03,07 only put those hosts in the keystone group | 03:33 |
| sdake | and what britt was talking about was making a group of controller01,03,07 and making that a group? | 03:34 |
| sdake | and having that group in the keystone group? | 03:34 |
| SamYaple | he was talking about something like CoreOS fleet/kubernetes level of "pools" it appears | 03:35 |
| SamYaple | you can do that, but thats at a layer even outside of ansible | 03:35 |
| SamYaple | thats all inventory management | 03:35 |
| SamYaple | thats a whole other project in itself | 03:35 |
| sdake | i see us expanding into inventory management down the road | 03:35 |
| SamYaple | well we kinda already do that with the inventory file. am im cool to expand that, just not now | 03:36 |
| sdake | to handle the multi-rack case | 03:36 |
| sdake | ya lets keep it simple for l2 | 03:36 |
| sdake | could you respond with some kind words on his request | 03:36 |
| sdake | i'm good with doing one step at a time | 03:37 |
| sdake | i prefer that approach | 03:37 |
| SamYaple | i did respond. i said future | 03:37 |
| sdake | i was curious if this was one step or two :) | 03:37 |
| sdake | there wer etoher parts of the review that need adjustment to meet harmw's standards I think :) | 03:38 |
| SamYaple | just one | 03:38 |
| sdake | so britt's request is two steps | 03:38 |
| sdake | not one | 03:38 |
| sdake | correct or incorrect? | 03:38 |
| SamYaple | ? | 03:39 |
| sdake | the ansi-bull says kolla-poluza in SJC :) | 03:39 |
| sdake | he was asking for something | 03:40 |
| SamYaple | i have no idea what youre asking | 03:40 |
| sdake | you pointed me at a bunch of docs which I read but dont understand | 03:40 |
| sdake | what is he asking for precisely | 03:40 |
| SamYaple | thats how you handle the inventory files. He can implement what he wants there | 03:40 |
| sdake | an expansion of how inventory files are managed? | 03:40 |
| SamYaple | basically | 03:40 |
| SamYaple | but also another layer of kolla somehow tracking the physical environment | 03:40 |
| SamYaple | something we have no basis to do (and i dont honestly think is our business to do) | 03:41 |
| *** jtriley has joined #kolla | 03:41 | |
| sdake | well if we deploy the physical environment shouldn't we track it? | 03:42 |
| SamYaple | in my opinion, no thats is for the operator to do | 03:42 |
| SamYaple | in the longrun, sure we can do that with scope creep | 03:43 |
| SamYaple | but its all ansible stuff | 03:43 |
| sdake | ok | 03:43 |
| sdake | i just really would like to get to one config file if possible | 03:43 |
| sdake | rather then many | 03:43 |
| sdake | inventory and globals are two | 03:44 |
| SamYaple | yea thats all. i think that is fine | 03:44 |
| SamYaple | they are two vastly different files | 03:44 |
| SamYaple | technically we can merge them but thats by building out our own thing. lets just stick with that | 03:44 |
| *** jtriley has quit IRC | 03:46 | |
| sdake | the thing i dont like about the invetory file is it has to magically managed in some way | 03:49 |
| sdake | as in, manually | 03:49 |
| sdake | i'd much rather define an ip range and have the inventory file generated | 03:49 |
| sdake | we dont need to tackle that in this spec | 03:49 |
| SamYaple | that is a bad path | 03:50 |
| SamYaple | you need to manually specify your hosts or build a dynamic way to do it | 03:50 |
| sdake | well vi invetory.yaml is a bad path | 03:50 |
| SamYaple | thats all ops | 03:50 |
| SamYaple | wrong | 03:50 |
| sdake | ok well it isn't relevant for this spec | 03:51 |
| SamYaple | agreed | 03:51 |
| sdake | we can argue about that later :) | 03:51 |
| SamYaple | im sure we will :) | 03:51 |
| openstackgerrit | Sam Yaple proposed stackforge/kolla: Ansible multi-node specification https://review.openstack.org/189157 | 03:57 |
| SamYaple | alright you animals, go tear that patchset up | 03:57 |
| sdake | harmw beat at it | 03:58 |
| SamYaple | I kid i kid, we are getting there! | 03:58 |
| bmace | looks good to me. one quick question. we could conceptually allow no CONFIG_STRATEGY and have a default behavior.. but we want to force having that i guess so as to follow the law of least surprise. | 04:04 |
| SamYaple | bmace: yea force having it. this needs to be implicit how we are doing it | 04:05 |
| SamYaple | explicit* | 04:05 |
| bmace | yup. i'm good with it :) explicit decisions force known behaviors. | 04:05 |
| bmace | great work guys | 04:05 |
| bmace | back in a few | 04:05 |
| sdake | looks good samyaple | 04:08 |
| SamYaple | sdake: you know.... me and you have to pwer right this second to get this commited | 04:09 |
| SamYaple | im just sayin' | 04:09 |
| sdake | no exceptions :) | 04:10 |
| sdake | but if the core team doesn't start voting +2, I am going to crank up the pressure :) | 04:11 |
| sdake | either that or the core team needs to vote -2 and stop wasting time on trivial changes | 04:11 |
| sdake | this is precisely why I dont like a spec process | 04:12 |
| sdake | takes forever to get anything done | 04:12 |
| sdake | this damn thing coudl have been written already | 04:13 |
| sdake | although I think we get a better result with the spec then our original intent | 04:13 |
| sdake | lots of cores nerd rage about the specs process in mature projects | 04:14 |
| sdake | like nova for exampe | 04:15 |
| sdake | "typo review after the review has been up for 3 weeks" | 04:15 |
| sdake | bunch of nonsense :) | 04:15 |
| SamYaple | yea -1 for trival is no good | 04:18 |
| sdake | harmw around | 04:47 |
| sdake | or have you disappeared for the day | 04:47 |
| diga | sdake: have you finalised the mid-cycle meetup date ?? | 04:50 |
| sdake | diga deadline is the 17th for voting on date | 04:50 |
| sdake | i need few days turnaround from facilities on room scheduling | 04:51 |
| sdake | then I'll publish the date | 04:51 |
| sdake | s | 04:51 |
| diga | okay | 04:51 |
| diga | can you arrange some sessions for remote attendees through webex, will that be possible ?? | 04:53 |
| sdake | yes | 04:58 |
| sdake | don't know how well it will work | 04:58 |
| sdake | so don't blame me if imperfect :) | 04:58 |
| diga | Great, NP | 04:59 |
| SamYaple | blame has been assigned | 04:59 |
| SamYaple | well im going to start submitting WIP patches based on the spec as it is | 05:00 |
| SamYaple | i dont htink it will change much | 05:01 |
| diga | no, I understand how much difficult to arrange all this stuff | 05:01 |
| diga | atleast I wont have any problem if certain issues comes up | 05:02 |
| *** Haomeng|2 has quit IRC | 05:02 | |
| *** jasonsb has joined #kolla | 05:08 | |
| *** nihilifer has joined #kolla | 05:12 | |
| nihilifer | good morning | 05:13 |
| SamYaple | morning nihilifer | 05:14 |
| *** Haomeng has joined #kolla | 05:15 | |
| *** erkules has joined #kolla | 05:27 | |
| *** jtriley has joined #kolla | 05:30 | |
| *** jtriley has quit IRC | 05:35 | |
| *** tobe has quit IRC | 05:39 | |
| sdake | hey nih* | 06:00 |
| sdake | nih* would you be intrestesd in adding your tz to our wiki alon with name and irc nick | 06:00 |
| sdake | https://wiki.openstack.org/wiki/Kolla | 06:00 |
| sdake | nihilifer^^ | 06:00 |
| *** dasm|afk is now known as dasm | 06:01 | |
| Haomeng | sdake: ping | 06:04 |
| SamYaple | when do we stop worrying about typos and merge? | 06:04 |
| sdake | haomeng wound me | 06:04 |
| sdake | samyaple t omorrow | 06:05 |
| sdake | look at agenda | 06:05 |
| Haomeng | sdake: I am new guys for kolla, one question, is kolla called from tripleo to deploy openstack systems, or we can run it standalone to deoploy ironic into via docker images? | 06:05 |
| Haomeng | sdake: not sure how to use it to deploy openstack, is there some guide which I did not find? | 06:06 |
| sdake | haomeng depends when | 06:06 |
| sdake | https://github.com/stackforge/kolla/blob/master/docs/dev-quickstart.md | 06:07 |
| nihilifer | sdake: yes, sure, I added myself now | 06:07 |
| sdake | this is panned for liberty-2 (July 31 deadline) https://review.openstack.org/#/c/189157/ | 06:07 |
| Haomeng | sdake: should I follow section "Starting Kolla" to run kolla? | 06:08 |
| sdake | planned | 06:08 |
| sdake | haomeng warning kolla is single node at the moment | 06:08 |
| sdake | we are fixing that with the above link | 06:08 |
| Haomeng | Haomeng: ok, is there existing doc patch, let me check latest out | 06:09 |
| *** inc0 has joined #kolla | 06:09 | |
| sdake | feel free to vote on it | 06:09 |
| inc0 | good morning | 06:09 |
| inc0 | whats up guys? | 06:09 |
| sdake | inc0 new rev of the ansible-multi spec availble for your voting pleasure | 06:09 |
| Haomeng | sdake: ok | 06:10 |
| Haomeng | sdake: thk | 06:10 |
| sdake | ironic is not yet containerized, jpeeler started work on that today | 06:11 |
| Haomeng | sdake: yes, thanks for your information | 06:11 |
| Haomeng | sdake: ironic depends on neutron dhcp agent, not sure if dhcp agent works in container? | 06:12 |
| sdake | it does, but our neutron agents are fat atm | 06:12 |
| sdake | which means single node | 06:12 |
| sdake | they are being thinified by samyaple | 06:13 |
| Haomeng | sdake: yes, neutron is complex | 06:13 |
| sdake | what i mean by fat is 4 agents run in one container | 06:13 |
| sdake | we are changing to run 4 containers 1 per agent | 06:13 |
| Haomeng | sdake: yes, good idea, each container run single service, that is easy to control and update/upgrade | 06:14 |
| sdake | a majority of our containers are thin | 06:14 |
| sdake | the ony ones thare not are neutron and cinder | 06:14 |
| sdake | for technical reasons | 06:14 |
| Haomeng | sdake: yes | 06:14 |
| sdake | but fixedwith docker .17 | 06:14 |
| Haomeng | sdake: :) | 06:14 |
| sdake | 1.7 | 06:14 |
| SamYaple | and dokcer 1.7 has zfs | 06:15 |
| SamYaple | wooo | 06:15 |
| SamYaple | "mounting --device recursively" is listed as a bugfix even. its not even a "feature" nice | 06:16 |
| SamYaple | https://github.com/docker/docker/blob/f4176020f325869274676b10d9afe8395e5e8fe3/CHANGELOG.md | 06:16 |
| Haomeng | one more question, is this "A Kolla Cluster with Heat" depends on magnum? | 06:16 |
| Haomeng | sdake: because magnum can deploy container cluster | 06:17 |
| SamYaple | sdake ---- "Experimental feature: support for out-of-process volume plugins" | 06:17 |
| SamYaple | that is a 'volumes on thier own' thing | 06:17 |
| SamYaple | no more data contaienr | 06:17 |
| sdake | sounds interesting from a performance perspective | 06:18 |
| sdake | our performance atm sucks | 06:18 |
| Haomeng | sdake: ok, just a question, no idea:) | 06:18 |
| sdake | no doesn't depend on magnum | 06:19 |
| sdake | magnum and kolla are orthognoal | 06:19 |
| sdake | this wasn't my origina thinking | 06:19 |
| Haomeng | osdake: k | 06:19 |
| sdake | but my thinkinghas refined over the last 6 months | 06:19 |
| Haomeng | sdake: :) | 06:19 |
| SamYaple | sdake: yea bind mounts are fast for a reason | 06:20 |
| SamYaple | its why i use them | 06:20 |
| *** tobe has joined #kolla | 06:20 | |
| inc0 | sdake, you mention in section "CONFIG_INSIDE" that it will also do stuff like dbsync or keystone registration | 06:21 |
| SamYaple | inc0: CONFIG_INSIDE will be what we currently do | 06:21 |
| sdake | maybe this experimental ffeature will provide immutability | 06:21 |
| sdake | inc0 yes | 06:21 |
| inc0 | do we ditch this logic in CONFIG_OUTSIDE | 06:21 |
| inc0 | ? | 06:21 |
| SamYaple | basically we just mv start.sh | 06:21 |
| sdake | inco 0 | 06:21 |
| sdake | inc0 yes | 06:21 |
| inc0 | ok, hmm... yeah makes sense | 06:22 |
| inc0 | I'm thinking how this part will affect tripleo, and I don't think it will too much | 06:23 |
| inc0 | so what will remain in kolla? just package installation? | 06:23 |
| sdake | the effect is a new enviornment variable CONFIG_STRATEGY will hae to be passed to each container | 06:24 |
| sdake | in a tripleo scenario | 06:24 |
| sdake | package installation and ansible deployment | 06:24 |
| sdake | and container build | 06:24 |
| sdake | the container build will build very similar containers from a start.sh perspective | 06:25 |
| inc0 | ok, I guess that's even better than what I thought before | 06:26 |
| inc0 | then from tripleo perspective, instead of decoupling config generation and running just that | 06:26 |
| inc0 | we'll have to change package installation to container deployment | 06:27 |
| inc0 | and *-manage scripts to run docker exec | 06:27 |
| inc0 | but | 06:28 |
| sdake | no you dont hve to do any of that | 06:28 |
| sdake | just change the env variable and use slower/rhallisey's designed review | 06:28 |
| sdake | fully compatible with tripleo | 06:28 |
| sdake | although I believe slagle thinks mode 2/3 is bteter long term for tripleo | 06:29 |
| inc0 | I'm in total agreement with thim | 06:29 |
| inc0 | him | 06:29 |
| inc0 | I'm thinking about tripleo+mode 2/3 | 06:29 |
| sdake | but it requires more r&d at the puppet side of things | 06:29 |
| inc0 | what will be required from tripleo side to use it | 06:29 |
| sdake | to decouple config from everything else the puppet scripts do | 06:30 |
| sdake | rhallisey is your go to guy there | 06:30 |
| inc0 | I know | 06:30 |
| inc0 | but now I'm thinking | 06:30 |
| SamYaple | oh boy | 06:30 |
| SamYaple | you got him thinking sdake | 06:30 |
| sdake | dangeorus thing there | 06:30 |
| inc0 | since container will run an executable | 06:30 |
| *** bmace has quit IRC | 06:30 | |
| inc0 | yeah, it hurts a little, so I'll keep this brief | 06:30 |
| inc0 | and thats maybe /ust/bin/keystone-all | 06:31 |
| inc0 | how do we inject init scripts? like dbsync? | 06:31 |
| sdake | in the ansible case? | 06:31 |
| inc0 | between container runtime and running an executable | 06:31 |
| inc0 | in any case | 06:31 |
| sdake | good question - this is the special case I was talkingabout in the spec ;) | 06:31 |
| inc0 | so I guess I should finish my reading before thinking too much | 06:32 |
| inc0 | off to review I go | 06:32 |
| SamYaple | in the ansible case you can launch the (for example) keystone container and override the entrypoint with a "bootstrap.sh" script (or pass a BOOTSTRAP variable). the cool that about that is you can wait for the cotnainer to exit before proceeding with ansible. so you can be ASSURED the DB has sync'd before proceeding | 06:35 |
| SamYaple | no need for the container to wait/guess/checkin | 06:35 |
| SamYaple | you can also catch sync errors and exit early | 06:35 |
| sdake | samyaple | 06:35 |
| sdake | daneyon has a wall of text in your review | 06:36 |
| SamYaple | noooo | 06:36 |
| sdake | can you fix or respond | 06:36 |
| sdake | i know, nothing like waiting 2 weeks to review a spec | 06:36 |
| * sdake groans | 06:36 | |
| sdake | i cut him some slack because he as been in travel hell | 06:36 |
| SamYaple | daneyon: you get no slack from me! | 06:36 |
| SamYaple | I rule with an iron fist | 06:37 |
| sdake | it would be handy if people hadn't been telling me they would review the spec tomorrow for the last 15 days | 06:37 |
| sdake | but it is what it is | 06:37 |
| sdake | can you resolve please | 06:38 |
| sdake | there is always tomorrow! | 06:38 |
| SamYaple | yea it just requires having the same conversation I had 5 reviews ago and 1-5 weeks ago | 06:38 |
| SamYaple | again | 06:38 |
| sdake | yes specs are evil | 06:39 |
| sdake | i really dislike them highly | 06:39 |
| sdake | let me enumerate the reasons for you | 06:39 |
| sdake | oh you already know :) | 06:39 |
| daneyon | SamYaple beat me up | 06:39 |
| daneyon | just trying to understand a few more details.. don;t hate me too much | 06:40 |
| SamYaple | lol daneyon I am not hating on you :) | 06:40 |
| SamYaple | im responding | 06:40 |
| SamYaple | Ive just got ~15 patches waiting on this spec | 06:40 |
| sdake | do like inc0 does, jam em in anyway :) | 06:41 |
| inc0 | :D | 06:41 |
| inc0 | yeah, I suspect half of HA implementation will land even before spec will get approved | 06:41 |
| inc0 | I even started an ha-guide.md in my review!;) | 06:42 |
| *** bmace has joined #kolla | 06:42 | |
| sdake | come hell or highwater we are approving or vetoing those specs tomorrow | 06:42 |
| sdake | well maybe not highwater | 06:43 |
| sdake | in arizona, that is a bad thing | 06:43 |
| sdake | that means the entire earth is flooded :) | 06:43 |
| inc0 | and hell is just another slightly hotter day? | 06:43 |
| sdake | ya 115 f tomorrow | 06:44 |
| * sdake groans | 06:44 | |
| sdake | people in arizona become decidely less nice during summertime | 06:44 |
| inc0 | 62 fahrenheit today at midday! | 06:44 |
| inc0 | I wonder which one is worse | 06:44 |
| sdake | trade my summer for your summer | 06:44 |
| sdake | i'll keep my winters :) | 06:44 |
| inc0 | let me guess, our summer is like your winter? | 06:45 |
| inc0 | or your winter is hotter? | 06:45 |
| sdake | first | 06:45 |
| sdake | i'm much more productive during winter | 06:46 |
| sdake | more cigars = more nicoteen = brain works better | 06:46 |
| inc0 | I'm not. I mean, depends on winter, but there are days with 0 fahrenheit here | 06:46 |
| bmace | nite all, see you in a few hours :) | 06:46 |
| inc0 | its not THAT uncommon either | 06:46 |
| sdake | bmace going to power nap | 06:46 |
| sdake | sdake on the other hand, going ot PTFO | 06:47 |
| bmace | well, a few is sort of ambiguous. up to but almost never to exceed 7. | 06:48 |
| inc0 | SamYaple, where do you keep Dockerfiles in yaodu? | 06:48 |
| sdake | few = 3 in my public education :) | 06:49 |
| sdake | bmace obviously went to better schooling :) | 06:49 |
| harmw | sdake: here now | 06:49 |
| sdake | harmw review specs plz | 06:49 |
| sdake | or atleast sam's latest | 06:50 |
| harmw | looked through, but at $work so can't do anything | 06:50 |
| harmw | one question though | 06:50 |
| harmw | about the template | 06:50 |
| SamYaple | inc0: i generate them | 06:50 |
| inc0 | yeah, but I can't find template | 06:51 |
| inc0 | that might be my stupidity tho | 06:51 |
| harmw | the keystone container comes preloaded with /etc/keystone/keystone.conf, will our template file overwrite that file or will it merge with it? (thus keeping all kinds of valid default config bits in place) | 06:51 |
| SamYaple | inc0: its a secret | 06:51 |
| SamYaple | magic | 06:51 |
| SamYaple | https://github.com/SamYaple/yaodu/tree/master/ansible/roles/docker_build/templates/ubuntu/keystone | 06:51 |
| SamYaple | harmw: overwrite | 06:52 |
| SamYaple | im commenting now | 06:52 |
| inc0 | hmf, stupidity it is then, thanks:) | 06:52 |
| harmw | SamYaple: that would mean we loose all kinds of valid config bits, right? or we'd need to specify (and maintain) the whole damn thing in our codebase | 06:53 |
| sdake | daneyon since your burning the midnight oil can you crank out a new spec addressing sam's concerns | 06:55 |
| sdake | harmw see work items | 06:55 |
| sdake | #5 | 06:55 |
| daneyon | sdake working it now | 06:55 |
| sdake | thanks daneyon | 06:55 |
| daneyon | yw | 06:55 |
| SamYaple | harmw: nope. all of those "default" configs are generated anyway (except for neutron, they handwrite those lol) | 06:55 |
| SamYaple | harmw: we just need to maintain the bare bones config to get the environment running | 06:56 |
| harmw | ofcourse, but that comes with the rpm | 06:56 |
| SamYaple | what? | 06:56 |
| harmw | default configs | 06:56 |
| SamYaple | they do not | 06:57 |
| inc0 | brb, gonna eat something and then I'll review this spec | 06:57 |
| SamYaple | they come with the pregened template. you still have to configure it harmw | 06:57 |
| harmw | true, true | 06:58 |
| harmw | will it be different from what we currently coinfigure with crudini? if not, I'm cool | 06:58 |
| SamYaple | have yo uread the spec? | 06:59 |
| sdake | harmw see item #5 | 06:59 |
| harmw | I've read it, ofcourse but perhaps I'm just not getting 'it' yet :) | 06:59 |
| sdake | harmw and I uote: | 07:00 |
| sdake | 5. Implement our existing crudini defaults in Ansible.306 | 07:00 |
| sdake | under work items | 07:00 |
| harmw | yep, and we'll do that using the template thing described at L193 | 07:00 |
| sdake | i didn't write that for my health :) | 07:00 |
| sdake | right | 07:00 |
| sdake | every word in that spec has meaning | 07:01 |
| sdake | treat it like a phd thesis :) | 07:01 |
| sdake | for those familiar with reading phd thesis | 07:01 |
| sdake | forthose not, every word has meaning ;) | 07:01 |
| harmw | haha | 07:01 |
| sdake | leave out one word, and it no worky | 07:01 |
| harmw | yep | 07:02 |
| sdake | i guess the correct word is dissertation | 07:02 |
| sdake | specs = madness | 07:02 |
| harmw | yea sure, as if augmentation wasn't difficuly enough already | 07:03 |
| sdake | that is something only kolla has | 07:03 |
| sdake | no other deployment tool has that | 07:03 |
| SamYaple | youre welcome | 07:03 |
| SamYaple | im the cause of confusion | 07:03 |
| harmw | I think it's clear now though | 07:04 |
| sdake | samyaple just dont take out my ipman quote | 07:04 |
| sdake | then i'll -2 the review! | 07:04 |
| harmw | just.. we now load up containers with rpm packages, stock configs are placed consisting of defaults and such and we change some specific (!) bits and pieces where ever necessary using crudini | 07:05 |
| sdake | crudini is not used in ansible model | 07:06 |
| harmw | that will change and ansible will be doing that, using the templates and perhaps augmentation | 07:06 |
| harmw | sdake: 'now' ;) | 07:06 |
| sdake | right | 07:06 |
| harmw | but the template is not replacing anything (file level), it's merging with a specific file and in the process updating/adding certain sections and/or keys | 07:07 |
| harmw | thus leaving the packaged bits we don't want/need to change in place, and effectively achieving what we now do with crudini | 07:08 |
| SamYaple | harmw: no | 07:09 |
| harmw | damn | 07:09 |
| openstackgerrit | Daneyon Hansen proposed stackforge/kolla: Spec to Add Support for High Availability https://review.openstack.org/181983 | 07:12 |
| sdake | harmw its replacement | 07:12 |
| harmw | so a DEFAULT section with 100 keys gets replaced with the DEFAULT section we've specified which consists of 25 keys, is that it? | 07:14 |
| harmw | or is it just replacing those 25 keys? | 07:14 |
| SamYaple | i dont think any default section has 25 keys harmw | 07:14 |
| SamYaple | the defaults needed to run all of openstack are like 150 options | 07:14 |
| harmw | it's just an example | 07:14 |
| harmw | I want to understand this, since it's not rocket science at all | 07:15 |
| harmw | and I'm obviously stuck at something quite simple/stupid :) | 07:15 |
| *** jmccarthy has joined #kolla | 07:17 | |
| *** gfidente has joined #kolla | 07:18 | |
| daneyon | sdake and SamYaple the HA spec https://review.openstack.org/181983 has been updated. Feel free to whack at it while i sleep ;-) | 07:18 |
| sdake | i'm going to whack something | 07:19 |
| SamYaple | daneyon: yea im reviewing it now | 07:19 |
| *** jtriley has joined #kolla | 07:19 | |
| *** daneyon has quit IRC | 07:20 | |
| sdake | night all enjoy the evening | 07:20 |
| *** sdake has quit IRC | 07:20 | |
| *** jtriley has quit IRC | 07:24 | |
| SamYaple | see ya sdake | 07:26 |
| SamYaple | harmw: would you like to discuss the issue further. I am confident I can explain it to you in a satisfactory manner | 07:26 |
| harmw | please do! | 07:26 |
| SamYaple | what do you need to get explained | 07:26 |
| harmw | perhaps I should explain my concern a bit | 07:27 |
| harmw | I've ran into missing config bits while upgrading between major releases once, which happened because I didn't copy the new default configuration file(s) for nova/neutron/whatever | 07:28 |
| harmw | ever since, I'm just inserting the default config (which is kept as .orig or whatever) when running minor updates and applying my own specifics on top of those | 07:28 |
| harmw | so the baselevel is always sane | 07:28 |
| harmw | I only have specific bits in my repo and don't need to keep an eye out on all the new keys and values that got added | 07:29 |
| harmw | (eg. I'll happily learn them from release notes) | 07:29 |
| harmw | so, my concern is will the new ansible template model force us to keep a complete configfile in our codebase or will it suffice to just whats realy realy necessary (as is the current case, with crudini) | 07:30 |
| harmw | a complete config file as in a template with replacable parts, ofcourse | 07:30 |
| SamYaple | harmw: a complete config file is what we want to avoid at al lcosts | 07:33 |
| SamYaple | _that_ is what is unmaintainable | 07:33 |
| harmw | BAM | 07:33 |
| harmw | +2 on making that clear :) | 07:33 |
| SamYaple | it will require that we keep uptodate with the latest changes for our default barebones template | 07:33 |
| SamYaple | this will only change between major versions | 07:34 |
| harmw | (and it's what I was expecting, hency my personal annoyance on where I'm not getting it) | 07:34 |
| SamYaple | so before libirety they wil lneed to be a config cleanup push | 07:34 |
| harmw | yep | 07:34 |
| SamYaple | I have the default configs for kilo ready | 07:34 |
| SamYaple | it took about 3 hours to convert them from my barebones juno configs | 07:34 |
| harmw | you've got it in your repo already, right? | 07:37 |
| harmw | so I should've just looked at that in detail, since it most probably will answer to my questions | 07:37 |
| SamYaple | not the kilo changes, i dont push to yaodu anymore | 07:37 |
| SamYaple | it probably would, but im just using it as a template moving forward | 07:38 |
| harmw | kilo, juno, the concept is the same even for grizzly right :) | 07:38 |
| SamYaple | yea but the options differe | 07:38 |
| harmw | ofcourse | 07:38 |
| harmw | but I just want to look at the implementation, so make sure understand what I'm +2ing :) | 07:38 |
| harmw | SamYaple: what happens when you leave out L13 in https://github.com/SamYaple/yaodu/blob/master/ansible/roles/glance/templates/glance-api.conf.j2 | 07:42 |
| SamYaple | harmw: what? | 07:43 |
| harmw | nvm, I think it's falling into place now | 07:45 |
| *** athomas has joined #kolla | 07:56 | |
| *** zhiwei has joined #kolla | 08:08 | |
| *** jmccarthy has quit IRC | 08:10 | |
| *** jmccarthy has joined #kolla | 08:11 | |
| openstackgerrit | Sam Yaple proposed stackforge/kolla: WIP - DO NOT MERGE Add initial config function and keystone support https://review.openstack.org/192544 | 08:12 |
| openstackgerrit | Sam Yaple proposed stackforge/kolla: WIP - DO NOT MERGE Add initial config function and keystone support https://review.openstack.org/192544 | 08:13 |
| inc0 | nice job SamYaple, as I understand we'll need to add bootstrap.sh somewhere as well right? | 08:14 |
| SamYaple | inc0: yea | 08:14 |
| inc0 | soo...hmm...let's sum it up SamYaple ok? | 08:50 |
| inc0 | we'll have ENTRYPOINTs in containers | 08:50 |
| SamYaple | wait | 08:50 |
| SamYaple | im about to push an update | 08:51 |
| inc0 | ok | 08:51 |
| openstackgerrit | Sam Yaple proposed stackforge/kolla: WIP - DO NOT MERGE Add initial config function and keystone support https://review.openstack.org/192544 | 08:51 |
| SamYaple | i added a BOOTSTRAP thing | 08:52 |
| SamYaple | im going to add the ansible component in a few minutes | 08:52 |
| SamYaple | i figure a rough draft will get this spec done sooner | 08:52 |
| inc0 | true | 08:53 |
| inc0 | I'm thinking of actual solution | 08:55 |
| inc0 | how to make it most flexible | 08:55 |
| inc0 | so ENTRYPOINT stages.sh | 08:55 |
| inc0 | where stages.sh will have this if bootstrap, then exec bootstrap.sh | 08:55 |
| inc0 | and we'll provide bootstap.sh in container, deployer will just set up this env right? | 08:56 |
| inc0 | or deployer provides bootstrap.sh? | 08:56 |
| inc0 | by deployer I mean Ansible or TripleO/Puppet | 08:56 |
| inc0 | by us I mean creators of container for keystone for example | 08:56 |
| *** tobe has quit IRC | 08:58 | |
| *** tobe has joined #kolla | 08:59 | |
| SamYaple | it does that now with the review above | 08:59 |
| SamYaple | config-inside.sh is exec'd | 08:59 |
| inc0 | yeah, now it does, but do we want it to do it as long term? | 08:59 |
| SamYaple | the bootstrap still need the configs setup, so if its in its own script it will have dup code which is no good | 09:00 |
| inc0 | my point is, different configurations might need different bootstrap scripts | 09:00 |
| inc0 | for example, if you use PKI tokens in keystone, you need to setup certs | 09:01 |
| inc0 | you don't need that with UUID | 09:01 |
| *** tobe_ has joined #kolla | 09:01 | |
| *** tobe_ has quit IRC | 09:01 | |
| inc0 | and we want to be config-agnostic | 09:01 |
| SamYaple | you are wrong. no different strategies need. just the right files in the right space | 09:01 |
| inc0 | for configs or alltogether? | 09:01 |
| SamYaple | the current config-outside.sh is not representative of the flow | 09:01 |
| *** Slower has quit IRC | 09:01 | |
| inc0 | yes, what I mean is | 09:02 |
| inc0 | we use config outside | 09:02 |
| inc0 | and we specify in our outside-config if we want PKI or UUID | 09:03 |
| inc0 | then we go to bootsrap.sh | 09:03 |
| SamYaple | bootstrap.sh doesnt need to change in that scenario | 09:03 |
| inc0 | and depending on this one option, we'll either have line to setup certs, or not | 09:03 |
| *** tobe has quit IRC | 09:03 | |
| inc0 | soo..I'm thinking if deployer should also provide bootstap.sh | 09:06 |
| inc0 | instead of us - container creators | 09:06 |
| *** daneyon has joined #kolla | 09:09 | |
| openstackgerrit | Sam Yaple proposed stackforge/kolla: Ansible multi-node specification https://review.openstack.org/189157 | 09:10 |
| SamYaple | inc0: no staph | 09:10 |
| SamYaple | none of that needs to happen | 09:11 |
| SamYaple | the bootstrap.sh thing is really only for the database | 09:11 |
| *** jmccarthy has quit IRC | 09:11 | |
| SamYaple | inc0: https://review.openstack.org/#/c/192544/2..3/docker/centos/binary/keystone/start.sh | 09:11 |
| SamYaple | its not even a seperate script | 09:12 |
| SamYaple | the config copies for the ssl and things is handled in the config-bind.sh script | 09:12 |
| SamYaple | with the files in the right location and the appropriate config file there is no need for a user defined script | 09:12 |
| SamYaple | additionally, user defined scripts are a bad idea | 09:13 |
| *** Slower has joined #kolla | 09:13 | |
| inc0 | hold on -config-bind.sh? | 09:14 |
| *** daneyon has quit IRC | 09:14 | |
| SamYaple | config-outside.sh | 09:14 |
| inc0 | so...in config-inside we'll have to duplicate this logic? | 09:15 |
| SamYaple | which logic? | 09:15 |
| inc0 | cert stuff for example | 09:15 |
| SamYaple | config-inside.sh is all the crudini/self-configuring stuff. How that handles certs I don't know | 09:16 |
| SamYaple | how that gets certs into the container, i dont know | 09:16 |
| SamYaple | config-inside does not use bind | 09:16 |
| inc0 | ok, I guess we'll find out soon enough | 09:17 |
| inc0 | I'm just curious if we should provide customizable hooks to containers | 09:17 |
| SamYaple | as in? | 09:17 |
| inc0 | so people can inject their own scripts in cetain stages | 09:17 |
| SamYaple | no thats bad | 09:17 |
| inc0 | why? | 09:17 |
| SamYaple | user defined scripts are bad | 09:17 |
| SamYaple | security would be the biggest one | 09:18 |
| inc0 | that's why we won't support anything more than just hooks | 09:18 |
| SamYaple | why poke holes in the security? | 09:18 |
| inc0 | real life use case I've been faced with | 09:18 |
| inc0 | Designate | 09:18 |
| SamYaple | what is this lacking that you need to poke holes to solve? | 09:18 |
| inc0 | on bootstrap, I had to add revdns records to database | 09:18 |
| SamYaple | ok. why would that not be possible in this method? | 09:19 |
| inc0 | how to do this in this method? | 09:19 |
| SamYaple | using config-inside, i dont know. Using ansible, with ansible | 09:19 |
| inc0 | you'd need to hack around ansible | 09:20 |
| inc0 | and we don't want that even more | 09:20 |
| SamYaple | well ansible is the scripting here, hacking would be a hook in the container | 09:20 |
| inc0 | but I'd rather keep containers deployer-agnostic | 09:20 |
| SamYaple | they are. | 09:20 |
| inc0 | and since there will be dbsync scripts in containers | 09:20 |
| inc0 | why not provide additional places where people can put their logic | 09:21 |
| inc0 | I don't think this is security risk | 09:21 |
| SamYaple | if yo ureally want to go down that path, they dont need to be in the container. | 09:21 |
| inc0 | because that will require access to repo, which allows you to do anything anyway | 09:21 |
| SamYaple | inc0 i was under the impression triple-o was using config-inside? | 09:21 |
| inc0 | but James pointed out that probably won't be long term solution | 09:22 |
| inc0 | and I agree that it shouldn't | 09:22 |
| inc0 | and I'm talking about everyone else as well, those who will deploy stuff manually | 09:22 |
| inc0 | there will be lots of these people | 09:22 |
| SamYaple | ok. then the orchastration peice you use should do the insert of revdns records | 09:22 |
| SamYaple | i am strongly opposed to outside shell scripts injected into the container. that is a huge security risk in my opinion | 09:23 |
| SamYaple | a user modified shell script now runs as root. thats bad | 09:23 |
| inc0 | and how about creation of /opt/kolla/keystone/post-bootstap.sh | 09:23 |
| *** tobe has joined #kolla | 09:23 | |
| inc0 | and that sort of scripts | 09:23 |
| inc0 | which initially will be empty | 09:23 |
| inc0 | but people can fill them in with their stuff as they please | 09:24 |
| SamYaple | if you are building the containers youself, you can add anything. | 09:24 |
| inc0 | yes, and I just want to expose one-and-only-good-place-to-do-this | 09:24 |
| SamYaple | because it wont fit everyones use case | 09:25 |
| SamYaple | and if you are building them yourself, do what you want | 09:25 |
| SamYaple | thats what it comes down too | 09:25 |
| SamYaple | if you review https://review.openstack.org/#/c/192544/ again, youll see there isn't even a bootstrap.sh | 09:26 |
| SamYaple | but if you think no bootstrap logic should be included, i am ok with that. I can do that from ansible | 09:26 |
| SamYaple | you can do that from puppet or the like | 09:26 |
| SamYaple | that sounds like what you want | 09:26 |
| inc0 | I know SamYaple, that's not my point, anyway, I'll hone this idea and let you guys figure out everything else, maybe it will be there by design | 09:26 |
| inc0 | that's what I want, yeah. I just want to provide only good way to do this | 09:27 |
| SamYaple | it would be from the orchastation tool | 09:27 |
| inc0 | not "play with start.sh" because that will lead to lots of different, possibly unmaintainable openstacks there | 09:27 |
| SamYaple | not typing scripts into containers | 09:27 |
| inc0 | yeah, before we even build | 09:28 |
| inc0 | or to place them in same folder as config in outside-bind method | 09:28 |
| inc0 | and just add "exec if this file is present" | 09:28 |
| inc0 | to our containers | 09:28 |
| *** jmccarthy has joined #kolla | 09:28 | |
| SamYaple | no outside script support, "a user modified shell script now runs as root. thats bad" | 09:28 |
| SamYaple | i mean thats not law, but ill fight it tooth and nail | 09:29 |
| inc0 | if user has access to this folder | 09:29 |
| inc0 | he can put configs there | 09:29 |
| inc0 | and that itself I suppose should require root access | 09:29 |
| SamYaple | if the user isnt root, he can elevate | 09:29 |
| SamYaple | nope | 09:29 |
| SamYaple | that would not be required | 09:30 |
| SamYaple | since hte docker daemon _is_ root it can mount a users folder | 09:30 |
| openstackgerrit | Paul Bourke proposed stackforge/kolla: Symlink all non Dockerfile resources in images https://review.openstack.org/190117 | 09:31 |
| inc0 | well, ok I rest my case, I'll wait for you guys to finish | 09:32 |
| openstackgerrit | Paul Bourke proposed stackforge/kolla: Add base image for oraclelinux https://review.openstack.org/191013 | 09:33 |
| openstackgerrit | Paul Bourke proposed stackforge/kolla: Create keystone user in start.sh if it doesn't exist https://review.openstack.org/191071 | 09:36 |
| inc0 | pbourke, soo...sources... | 09:36 |
| pbourke | inc0: yes :) | 09:37 |
| pbourke | inc0: did you catch the summary I put on the bp? | 09:37 |
| inc0 | yeah | 09:37 |
| inc0 | thanks for that | 09:37 |
| inc0 | I'm generally slightly inclined to git pull stuff | 09:37 |
| inc0 | and then pip install -r requirements.txt | 09:38 |
| inc0 | pip install -e . | 09:38 |
| inc0 | as this provides lots of flexibility | 09:38 |
| inc0 | ofc we can tar.gz this, but I think its kinda redundant | 09:38 |
| pbourke | well, tars can be a good common demoninator? | 09:39 |
| pbourke | as some will want to use tarballs.openstack.org for example | 09:39 |
| inc0 | uhh..why would anyone use this? | 09:40 |
| pbourke | its faster than git clone | 09:40 |
| inc0 | van you generate tarball from specific ref easily? | 09:40 |
| inc0 | also, if someone has "their own patched openstack"...and really lot of people do | 09:41 |
| pbourke | not sure if there's a python task for it... if not tar -cf | 09:41 |
| inc0 | so first pull whatever you want, and then tar it and put it somewhere? | 09:41 |
| inc0 | and...where? how do we get tar to container? | 09:42 |
| inc0 | also....2s build instead of 10s build...is this really an issue? | 09:42 |
| pbourke | these are just my current thoughts, I need to double check how SamYaple was doing things in yaodu. but, I imagine we either put it somewhere like /tmp that Dockerfile can pick up, or generate it into the same dir as the dockerfile | 09:43 |
| inc0 | its just a build, you can do it offline, nightly | 09:43 |
| pbourke | so the dockerfile has something like ADD /tmp/keystone.tar | 09:43 |
| inc0 | SamYaple, is doing tars as I see | 09:43 |
| pbourke | inc0: wrt the speed, probably not, but might as well support both if it's not too much overhead | 09:44 |
| inc0 | but we don't want people to first pull a repo, then tar it, then put it to Docker folder, and deploy container | 09:44 |
| inc0 | we want them to git clone kolla, kolla-deploy keystone | 09:45 |
| inc0 | and you have keystone | 09:45 |
| inc0 | or kolla-deploy keystone --source --repo-url github/... --branch master --commit abc123 | 09:45 |
| pbourke | from what I gathered from SamYaple the idea is to have a helper script that build will call | 09:46 |
| pbourke | that does the download or clone+tar | 09:46 |
| pbourke | for you | 09:46 |
| inc0 | how about having source untared inside container | 09:46 |
| inc0 | and have helpers in ./build? | 09:46 |
| inc0 | or yeah, have helper to download and tar it | 09:47 |
| *** athomas has quit IRC | 09:48 | |
| SamYaple | .buildconf as it currently exists can git clone/download tarball and set it up to be consumed by the dockerfile | 09:49 |
| SamYaple | this way you can do ref/changes from a review upstream | 09:49 |
| SamYaple | you cant straight gitclone those | 09:49 |
| inc0 | how about local code? | 09:50 |
| inc0 | can you point to local stuff? | 09:50 |
| SamYaple | what about it? just drop a tarball in the right location then BAM | 09:50 |
| SamYaple | its a script, point it where you will | 09:50 |
| SamYaple | .buildconf is 100% in the builders control | 09:50 |
| inc0 | stupid quesiton vol 2: which .buildconf? | 09:51 |
| SamYaple | the .buildconf in the folder with the container build | 09:52 |
| *** athomas has joined #kolla | 09:52 | |
| pbourke | BAM | 09:53 |
| pbourke | :) | 09:53 |
| inc0 | looking for "one that already exist";) | 09:54 |
| inc0 | I think today I overcomplicate stuff | 09:54 |
| inc0 | even more than my ususal | 09:55 |
| inc0 | usual* | 09:55 |
| pbourke | inc0: so wrt how we'll split this up. I think we should get a snippet of an example .buildconf on the whiteboard, along with a consuming dockerfile | 09:56 |
| pbourke | inc0: then we can each take a basic container to add? | 09:56 |
| pbourke | e.g. rabbitmq and keystone | 09:56 |
| inc0 | sure, and we focus on centos right now? | 09:56 |
| pbourke | yes | 09:57 |
| inc0 | I don't thing we'll even make rabbitmq source | 09:57 |
| pbourke | oh, yeah | 09:57 |
| inc0 | not for start anyway | 09:57 |
| pbourke | my mistake | 09:57 |
| inc0 | I'll take on heat then, Ala already started keystone | 09:57 |
| inc0 | on centos | 09:58 |
| SamYaple | for testing purposes we might want to start with the core services | 09:59 |
| SamYaple | keystone/glance/nova/neutron | 09:59 |
| pbourke | ill go with nova then | 09:59 |
| inc0 | so I'll go neutron, witness me! (have you seen new mad max?) | 10:00 |
| pbourke | not yet :) | 10:00 |
| inc0 | cool one | 10:00 |
| pbourke | cool, as glance should be fairly straight forward | 10:00 |
| SamYaple | no but i saw a trailer for the FFVII remake | 10:00 |
| pbourke | shenmue 3 is where it's at | 10:00 |
| SamYaple | so, guys. we should probably wait for keystone source to land, as that will be the template | 10:01 |
| SamYaple | i image debate will happen for it as well | 10:01 |
| inc0 | I'll help Ala to get this through asap | 10:01 |
| pbourke | awesome | 10:01 |
| inc0 | and we'll work on this one together | 10:01 |
| dasm | btw FFVII an Shenmue3 http://www.nerfnow.com/comic/1577 | 10:02 |
| dasm | and mstachow is very interested in this | 10:02 |
| pbourke | xD | 10:02 |
| SamYaple | mstachow mentioned FFVII yesterday and i didnt know what he meant | 10:02 |
| SamYaple | i got home to unwind and then turned on the internet | 10:02 |
| inc0 | now you know? | 10:02 |
| SamYaple | BAM | 10:02 |
| SamYaple | no unwinding for me | 10:02 |
| dasm | xD | 10:02 |
| inc0 | BAM indeed | 10:03 |
| SamYaple | i dont console game, but i will get a PS4 for this | 10:03 |
| SamYaple | i still have the FFVII strategy guide im sure | 10:03 |
| inc0 | I just hope they'll keep the atmosphere | 10:04 |
| SamYaple | the new/old music was spot on | 10:04 |
| inc0 | but if they won't that will cause riots | 10:04 |
| SamYaple | gave me chills | 10:04 |
| inc0 | and heads may roll...literally | 10:04 |
| pbourke | im holding on for the steam machine | 10:05 |
| pbourke | if its no good then ps4 | 10:05 |
| dasm | pbourke: are you planning to buy steam machine? | 10:06 |
| mstachow | I'm so happy because of this :D | 10:06 |
| pbourke | dasm: if the reviews are good | 10:06 |
| dasm | in general, it seems to be just PC + nice outfit for this. | 10:06 |
| pbourke | there's also the option of standard gaming pc and just getting this steam link and controller | 10:07 |
| pbourke | decisions! | 10:07 |
| mstachow | 25RnZsY65q# | 10:07 |
| SamYaple | if they make it available through steam i will be esstatic | 10:07 |
| mstachow | that's not happened :O | 10:07 |
| pbourke | mstachow: woops :) | 10:07 |
| mstachow | woops | 10:07 |
| dasm | mstachow: thx, give also username and bank account to this password | 10:07 |
| mstachow | eh it's good to have one password for one account | 10:07 |
| dasm | pbourke: i have pc + win8 + steam in Big Picture mode + xbox360 controller | 10:08 |
| dasm | and that's all :) | 10:08 |
| dasm | works (almost) flawless :) | 10:08 |
| pbourke | nice | 10:08 |
| SamYaple | mstachow: http://www.bash.org/?top | 10:08 |
| dasm | SamYaple: ROTFL | 10:09 |
| mstachow | That's not my day :D | 10:10 |
| openstackgerrit | Paul Bourke proposed stackforge/kolla: Symlink all non Dockerfile resources in images https://review.openstack.org/190117 | 10:13 |
| dasm | i like this one | 10:17 |
| dasm | "<erno> hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is." | 10:17 |
| *** dims has joined #kolla | 10:17 | |
| dasm | it reminds me, when inc0 told us, pretty the same situation in his previous job,. | 10:17 |
| inc0 | well, it might have been corp urban myth | 10:17 |
| SamYaple | check the packet latency | 10:17 |
| *** tobe has quit IRC | 10:17 | |
| *** dims has quit IRC | 10:17 | |
| inc0 | we went through switch configs, find out macs | 10:17 |
| inc0 | bound to given port | 10:17 |
| *** dims has joined #kolla | 10:18 | |
| inc0 | I mean they, ops from my previous jopb | 10:18 |
| inc0 | and they followed cable from this port | 10:18 |
| dasm | inc0: nooo.. urban legend? i don't believe in it. everything what you can read in internet, must be true | 10:18 |
| inc0 | it ended in the wall | 10:18 |
| inc0 | it turns out there was slight refibrushment of server room, and this was old machine without redundant power sources and so on | 10:19 |
| inc0 | you know, one which was on for last 5 years, person who set this up was probably dead by then and everyone was afraid to turn this off | 10:19 |
| inc0 | that sort of server | 10:19 |
| inc0 | so they just leave it between walls... | 10:19 |
| inc0 | left* | 10:21 |
| mstachow | huh I've got similar with my smartphone in my home - standard ;) | 10:21 |
| SamYaple | "unplug and act clueless" | 10:25 |
| SamYaple | remove if no one complains for a week | 10:25 |
| *** inc0 has quit IRC | 10:30 | |
| *** akwasnie_ has joined #kolla | 10:30 | |
| *** akwasnie_ is now known as akwasnie | 10:30 | |
| *** inc0 has joined #kolla | 10:34 | |
| *** vbel has quit IRC | 10:40 | |
| *** vbel has joined #kolla | 10:40 | |
| *** inc0 has quit IRC | 10:41 | |
| *** inc0 has joined #kolla | 10:42 | |
| *** inc0 has quit IRC | 10:46 | |
| *** inc0 has joined #kolla | 10:49 | |
| *** inc0 has quit IRC | 10:57 | |
| *** daneyon has joined #kolla | 10:58 | |
| *** daneyon has quit IRC | 11:02 | |
| *** zhiwei has quit IRC | 11:04 | |
| openstackgerrit | Sam Yaple proposed stackforge/kolla: WIP - DO NOT MERGE Add initial config function and keystone support https://review.openstack.org/192544 | 11:13 |
| SamYaple | pbourke: inc0: would you mind looking at the ansible things for https://review.openstack.org/192544 | 11:13 |
| SamYaple | as an initial look | 11:13 |
| pbourke | looking | 11:13 |
| SamYaple | start with "main.yml" | 11:13 |
| SamYaple | include means "source" in bash | 11:14 |
| SamYaple | it will run those playbooks | 11:14 |
| *** inc0 has joined #kolla | 11:24 | |
| *** inc0 has quit IRC | 11:28 | |
| *** athomas has quit IRC | 11:32 | |
| *** inc0 has joined #kolla | 11:33 | |
| *** sdake has joined #kolla | 11:41 | |
| *** athomas has joined #kolla | 11:41 | |
| inc0 | good morning sdake | 11:42 |
| *** prad has quit IRC | 11:42 | |
| SamYaple | hey sdake, got a rough draft review of the keystone support for ansible stuffs. asked inc0 and pbourke to have a look at it and leave early feedback | 11:43 |
| SamYaple | https://review.openstack.org/192544 | 11:43 |
| *** rhallisey has joined #kolla | 11:48 | |
| rhallisey | morning | 11:52 |
| SamYaple | morning rhallisey | 11:53 |
| mstachow | hi rhallisey | 11:56 |
| rhallisey | hey guys | 11:57 |
| SamYaple | rhallisey: ansible-multi is up for review. should have the basis all done for people to (hopefully) agree on | 11:58 |
| rhallisey | SamYaple, ya I've been looking at it | 11:59 |
| SamYaple | its been a time going through the comments to be sure | 11:59 |
| *** sdake has quit IRC | 12:04 | |
| *** gfidente is now known as gfidente|afk | 12:05 | |
| akwasnie | hi, SamYample: can you tell me more about .buildconf file you mentioned before? can it clone tarball? | 12:10 |
| *** dwalsh has joined #kolla | 12:10 | |
| SamYaple | akwasnie: it can execute arbitrary code. its just a bash file | 12:10 |
| SamYaple | it is sourced when the container is built | 12:10 |
| akwasnie | thanks | 12:15 |
| *** erkules has quit IRC | 12:16 | |
| *** erkules has joined #kolla | 12:16 | |
| openstackgerrit | Ryan Hallisey proposed stackforge/kolla: Cinder container https://review.openstack.org/170965 | 12:31 |
| inc0 | Ryan, sorry for that, I've missed also 2 lines above, these should be moved to INIT_DB block as well | 12:33 |
| openstackgerrit | Ryan Hallisey proposed stackforge/kolla: Add cinder into the docker compose setup https://review.openstack.org/173507 | 12:35 |
| *** dims has quit IRC | 12:36 | |
| *** dims has joined #kolla | 12:36 | |
| rhallisey | inc0, init_db vars may need to be added in other places.. | 12:37 |
| rhallisey | I'll do that after | 12:37 |
| rhallisey | inc0, also, docs and env stuff are in path #2 | 12:38 |
| inc0 | I saw that now, I'll remove these comments, but you might want to create patchset dependency between these | 12:38 |
| rhallisey | inc0, are you saying the mysql stuff above should use $INIT_DB | 12:39 |
| rhallisey | and not init_cinder_db | 12:40 |
| inc0 | I meant init_cinder_db | 12:40 |
| rhallisey | ok I'll wrap the whole thing in the if block | 12:40 |
| inc0 | also I'd rename it to cinder_db_init, to keep name consistency | 12:40 |
| inc0 | yeah, that's my point | 12:40 |
| rhallisey | well technically there is no other name to follow | 12:41 |
| rhallisey | I was thinking these go into the #database comment | 12:41 |
| rhallisey | in the env file | 12:41 |
| *** athomas has quit IRC | 12:41 | |
| rhallisey | I think* | 12:41 |
| * rhallisey looks | 12:41 | |
| *** athomas has joined #kolla | 12:41 | |
| inc0 | there are CINDER_DB_USER:) | 12:41 |
| inc0 | and CINDER_DB_PASSWORD | 12:41 |
| rhallisey | nevermind... DESIGNATE_INITDB | 12:42 |
| rhallisey | no I mean for 'init_db' vars | 12:42 |
| inc0 | ah, ok, anyway, there is one, but we'll need to check this in every container | 12:42 |
| rhallisey | since they will be grouped under the 'database' title | 12:42 |
| rhallisey | ya I'll write a patch for that in a moment | 12:42 |
| inc0 | I mean if every container has this conditional | 12:42 |
| rhallisey | it makes sense | 12:43 |
| inc0 | I'll look at it tomorrow and file a but for each missing | 12:43 |
| rhallisey | inc0, what do you want to call these '<service>_init_db' or 'init_<service>_db' | 12:43 |
| inc0 | I'd keep <service>_init_db | 12:43 |
| inc0 | to keep all vars required for cinder to be up in same place | 12:44 |
| rhallisey | what I'm saying is that these db vars will go in the 'database' section | 12:44 |
| inc0 | db_init for me is more about create mysql service itself, init servers, datafiles and so forth | 12:44 |
| rhallisey | in tools/genenv | 12:44 |
| *** jtriley has joined #kolla | 12:45 | |
| inc0 | well, we'll need to create standard I guess if there is none so far | 12:45 |
| rhallisey | ya that's what saying I don't care though what would you prefer | 12:46 |
| rhallisey | I kinda like init_<service>_db because it groups them together | 12:46 |
| *** daneyon has joined #kolla | 12:46 | |
| inc0 | groups inits, but it would require to check envs in 2 places for each service | 12:47 |
| inc0 | because if someone set ups cinder for a first time, he would need to change it | 12:47 |
| inc0 | becase I'd suggest to default it to false | 12:48 |
| inc0 | so by default container deploy will fail, but will not break data | 12:48 |
| inc0 | unless explicitly said to | 12:48 |
| rhallisey | inc0, which part is breaking the data? The cinder db creation? | 12:49 |
| inc0 | syncdb | 12:49 |
| *** jtriley has quit IRC | 12:50 | |
| rhallisey | doesn't the db sync just update with the cinder table though? | 12:50 |
| rhallisey | is that what you mean by breaking it | 12:50 |
| inc0 | well, if we consider code upgrade | 12:51 |
| inc0 | we'll build new container and someone will do accidental db migration | 12:51 |
| *** daneyon has quit IRC | 12:51 | |
| inc0 | also, dbsync is done once, container deployment is done x times | 12:52 |
| rhallisey | when though does a db sync become damaging? If you upgrade? | 12:53 |
| inc0 | alter can lock tables, and that can cause downtime of APIs | 12:54 |
| inc0 | for example | 12:54 |
| rhallisey | ya but for our purpose of using it I'd say we default it to true and document that it should be run as false | 12:57 |
| inc0 | also, have you seen what nova did with flavors one day?:) | 12:57 |
| rhallisey | no I haven't | 12:57 |
| rhallisey | :) | 12:57 |
| inc0 | they droppet table from instance and create new table | 12:57 |
| inc0 | and did some magic for lazy loading and migrations | 12:58 |
| inc0 | if you'd to that without full prior code upgrade, you'll break stuff;) | 12:58 |
| rhallisey | I hear ya | 12:58 |
| rhallisey | I think though for our purposes we should leave it as true since we arn't deploying in production or anything too serious | 12:59 |
| inc0 | well, not dropped, but made big alter there | 12:59 |
| rhallisey | ya I understand your point | 12:59 |
| inc0 | let's just discuss that with more people | 12:59 |
| rhallisey | sure | 12:59 |
| inc0 | and approach this as separate issue | 12:59 |
| rhallisey | deal | 12:59 |
| rhallisey | let me update the patch.. | 12:59 |
| inc0 | thank you | 12:59 |
| rhallisey | :) no problem | 13:00 |
| inc0 | I haven't seen any more INIT-only stuff there, but please take one more look | 13:00 |
| rhallisey | sure | 13:01 |
| inc0 | maybe some lvm init stuff? | 13:01 |
| rhallisey | well for one, we are using a backing file and we should support physical backup | 13:01 |
| rhallisey | that patch will be an addition after this merges | 13:02 |
| inc0 | if you say so;) | 13:04 |
| inc0 | anyway, I'm off | 13:04 |
| inc0 | thanks and see you around | 13:04 |
| *** inc0 has quit IRC | 13:05 | |
| openstackgerrit | Ryan Hallisey proposed stackforge/kolla: Cinder container https://review.openstack.org/170965 | 13:05 |
| rhallisey | see ya | 13:05 |
| *** diogogmt has quit IRC | 13:07 | |
| *** jmccarthy1 has joined #kolla | 13:11 | |
| *** jmccarthy has quit IRC | 13:11 | |
| *** jmccarthy1 has quit IRC | 13:13 | |
| *** jmccarthy has joined #kolla | 13:14 | |
| *** nihilifer has quit IRC | 13:14 | |
| pbourke | SamYaple: can you help me understand, to what degree is re-pulling a docker image not idempotent | 13:30 |
| pbourke | (im looking at the pull task in your review) | 13:31 |
| *** dwalsh has quit IRC | 13:32 | |
| *** jtriley has joined #kolla | 13:40 | |
| *** fangfenghua has joined #kolla | 13:40 | |
| *** prad has joined #kolla | 13:40 | |
| SamYaple | pbourke: the ansible docker module is not idempotent | 13:41 |
| pbourke | I think Im wondering what your definition of idempotent is (not saying it's wrong just curious) | 13:42 |
| SamYaple | run repeatedly without change | 13:42 |
| SamYaple | the ansible docker module will report change (even if there is none) | 13:42 |
| pbourke | if I run 'docker pull fedora:21' on my machine for example it is not changing anything | 13:42 |
| SamYaple | the issue is with the ansible module not with docker pbourke | 13:45 |
| pbourke | ok I had a feeling that's what you were getting at | 13:45 |
| pbourke | makes sense | 13:45 |
| pbourke | i'll put other questions on the review as too much info gets lost on irc i think! | 13:46 |
| SamYaple | agreed | 13:47 |
| *** fangfenghua has quit IRC | 13:49 | |
| *** dwalsh has joined #kolla | 13:50 | |
| *** jmccarthy has quit IRC | 14:09 | |
| *** jmccarthy has joined #kolla | 14:10 | |
| *** jtriley has quit IRC | 14:26 | |
| *** jtriley has joined #kolla | 14:28 | |
| *** gfidente|afk is now known as gfidente | 14:28 | |
| *** absubram has joined #kolla | 14:33 | |
| *** daneyon has joined #kolla | 14:35 | |
| *** daneyon has quit IRC | 14:40 | |
| *** akwasnie has quit IRC | 14:41 | |
| SamYaple | eveeyonr review the ansible spec? | 14:41 |
| *** dasm is now known as dasm|afk | 14:42 | |
| pbourke | MERGE IT | 14:46 |
| *** diogogmt has joined #kolla | 14:50 | |
| *** jasonsb has quit IRC | 14:52 | |
| *** sdake_ has joined #kolla | 14:53 | |
| sdake_ | morning folks | 14:53 |
| pbourke | afternoon :) | 14:55 |
| jmccarthy | hiya | 14:56 |
| *** nihilifer has joined #kolla | 15:00 | |
| sdake_ | greetings in whichever timezone you are in :) | 15:04 |
| *** openstackgerrit has quit IRC | 15:05 | |
| *** openstackgerrit has joined #kolla | 15:05 | |
| *** jmccarthy has quit IRC | 15:07 | |
| *** jmccarthy has joined #kolla | 15:07 | |
| *** blahRus has joined #kolla | 15:09 | |
| SamYaple | harmw: only +1 workflow when another core has already +2 | 15:21 |
| *** mstachow has quit IRC | 15:21 | |
| *** absubram has quit IRC | 15:21 | |
| harmw | oh sry | 15:23 |
| SamYaple | not a problem! just fyi | 15:23 |
| harmw | there:) | 15:24 |
| pbourke | sdake_: to add a new gate are the following steps correct? 1) add script under tests/ to kolla. 2) add entry to https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml | 15:24 |
| pbourke | this would be for building the ol images | 15:25 |
| sdake_ | let me wake up pbourke | 15:25 |
| sdake_ | then i'll be with you | 15:25 |
| sdake_ | in this cae dont workflow at all | 15:25 |
| sdake_ | I want to get a rollcall vote | 15:25 |
| SamYaple | yea if we can get a review before the meeting that owuld be great | 15:26 |
| *** diga has quit IRC | 15:32 | |
| sdake_ | we are reviewing during the meeting | 15:34 |
| *** dwalsh has quit IRC | 15:34 | |
| sdake_ | note to core reviewers: | 15:34 |
| sdake_ | I have added "how to review the specification" notes in both specifications under review | 15:34 |
| sdake_ | we still only require two +2 votes (plus the implicit vote of the submitter) however, I want to see where the core team stands on both the ha spec and ansible spec | 15:35 |
| sdake_ | so do not use +w until a full rollcall vote can be done | 15:36 |
| sdake_ | pbourke i'mm all yours | 15:43 |
| sdake_ | pbourke which scritp do you want to add under rtests? | 15:43 |
| sdake_ | pbourke this is one place: https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L6510 | 15:44 |
| pbourke | sdake_: well, the ol base image isn't merged yet, but Id like to tee up a gate to build it while I wait (inc0 and alicja are working on the first iteration of the centos source install after which point I'll jump in) | 15:44 |
| sdake_ | this is another place: https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/kolla.yaml | 15:45 |
| sdake_ | jpeeler are there other parts to setting up the functional gate? | 15:46 |
| sdake_ | please take care to make your job non-voting to begin | 15:46 |
| pbourke | yup that's basically my question - are those the only places I need to touch | 15:46 |
| sdake_ | ya we probably want somehting more descriptive then kolla-functional-build-f1 | 15:47 |
| sdake_ | like kolla-func-image-build-f21 | 15:47 |
| sdake_ | or kolla-func-image-build-centos-f21 | 15:47 |
| sdake_ | and kolla-func-image-builld-ol-f21 | 15:47 |
| sdake_ | pbourke when you begin yuo dont set up a gate pipeline only a check pipeline | 15:48 |
| sdake_ | a check pipeline happens prior to commit - it indicates to core reviewers the patch has passed testing | 15:48 |
| sdake_ | a gate pipeline happens prior to commit but after review - it triggers jenkins to merge the patch into the repository | 15:48 |
| sdake_ | a non-voting gate doesn't have a gate pipeline job | 15:48 |
| pbourke | yup understood | 15:49 |
| sdake_ | pbourke I'd prefer one script for all types of environments | 15:49 |
| sdake_ | and pass in stuff in the environment to the builders shell (line 14) | 15:49 |
| sdake_ | or we may need a tox -e images-ol | 15:49 |
| sdake_ | and tox -e images-centos | 15:50 |
| sdake_ | and leave tox -e images for all images | 15:50 |
| pbourke | it wont be as visible as to what set of tests are running on the board then though? | 15:50 |
| sdake_ | once the test completes you will get a job results output - is that what you mean? | 15:50 |
| sdake_ | the tox -e images test case takes about 45 mins atm | 15:50 |
| sdake_ | so we need each distro and binary/source as a separate job | 15:51 |
| sdake_ | to keep the gate running in parallel | 15:51 |
| jpeeler | the only 3 files i've touched are: jenkins/jobs/kolla.yaml, jenkins/jobs/projects.yaml, zuul/layout.yaml | 15:51 |
| sdake_ | jpeeler thoughts on the tox -e images-centos vs tox -e images-ol | 15:52 |
| jpeeler | not to be exclusive, but where do we draw the line for images built in the gate when each distro will be a +40 minutes | 15:52 |
| sdake_ | i'd like to test all distros that are feasible and all deploy methods that are feasible | 15:52 |
| sdake_ | the only ones i can think of that are not feasible are rhel because you can[t install packages in the containers wihtout a rhel license | 15:53 |
| pbourke | jpeeler: if they can be done in parallel it probably shouldn't make a huge difference? | 15:53 |
| sdake_ | the parallel thing - we may have to change our gate to run on ubuntu | 15:53 |
| sdake_ | infra doesn't have many fedora 21 builders | 15:53 |
| *** bmace has quit IRC | 15:54 | |
| sdake_ | let me ask | 15:54 |
| jpeeler | all tox -e images does is call build-all-docker-images | 15:56 |
| jpeeler | i mean, we can make a tox target for whatever. but is there a way to toggle which set of images get built with our current tools scripts? | 15:57 |
| pbourke | jpeeler: I think it should be quite easy to add once SamYaple's --prefix patch merges | 16:00 |
| sdake_ | there is an unlimited number of fedora builders | 16:00 |
| sdake_ | (limited by quotas) | 16:00 |
| jpeeler | pbourke: great, feel free to depend on his patch then | 16:02 |
| sdake_ | so we dont have to change to ubuntu builders | 16:02 |
| *** jtriley has quit IRC | 16:02 | |
| SamYaple | meeting? | 16:03 |
| SamYaple | or is that tomorrow? | 16:03 |
| jpeeler | just need to add a prefix arg to test_images assuming testr accepts args | 16:03 |
| pbourke | SamYaple: today, not till 23:00 UTC though | 16:03 |
| jpeeler | SamYaple: in 6 hours | 16:03 |
| SamYaple | jpeeler: currently the scture allows setting the "prefix" in the .buildconf in root | 16:03 |
| *** daneyon has joined #kolla | 16:04 | |
| SamYaple | wow. then i have been awake for nothing | 16:04 |
| SamYaple | i hate time | 16:04 |
| pbourke | thats midnight my time so I may or may not stay up | 16:04 |
| *** daneyon_ has joined #kolla | 16:04 | |
| jpeeler | SamYaple: thanks, might as well build on the future though! assuming --prefix is close | 16:05 |
| SamYaple | i think it can be merged now jpeeler | 16:05 |
| SamYaple | ill check | 16:05 |
| harmw | rhallisey: almost done with cinder, one minor issue remains | 16:05 |
| harmw | *you are | 16:05 |
| rhallisey | harmw, cool thx | 16:05 |
| harmw | (I was ready to +2 it again, but well...) | 16:06 |
| *** jtriley has joined #kolla | 16:06 | |
| * jpeeler goes to look at patch | 16:07 | |
| *** bmace has joined #kolla | 16:07 | |
| *** mstachow has joined #kolla | 16:08 | |
| *** daneyon has quit IRC | 16:08 | |
| mstachow | have we got meeting today? | 16:09 |
| *** absubram has joined #kolla | 16:11 | |
| *** dims_ has joined #kolla | 16:11 | |
| jpeeler | mstachow: in 5 hours 50 minutes | 16:11 |
| mstachow | oh, ok | 16:12 |
| mstachow | thanky jpeeler | 16:12 |
| mstachow | *thanks | 16:12 |
| jpeeler | would be kind of neat if openstack bot did a one hour warning for that sort of thing... | 16:12 |
| jpeeler | np | 16:12 |
| *** dims has quit IRC | 16:13 | |
| rhallisey | harmw, I'm thinking of changing the names of 'INIT_DB' stuff | 16:18 |
| rhallisey | I'll follow up with that patch in a bit | 16:18 |
| rhallisey | since I know designate has "DESIGNATE_INITDB" | 16:19 |
| rhallisey | but I'm going to change it and add it to other services | 16:19 |
| *** sdake_ is now known as sdake | 16:25 | |
| openstackgerrit | Ryan Hallisey proposed stackforge/kolla: Cinder container https://review.openstack.org/170965 | 16:25 |
| sdake | rhallisey sounds good - we should have one varaiable for that i thnk | 16:26 |
| rhallisey | sdake, I'm not sure though. What if I just introduces cinder into my stack and I don't want to run the db sync for my other services | 16:27 |
| rhallisey | all the services need something there though | 16:28 |
| *** vinkman has joined #kolla | 16:31 | |
| openstackgerrit | Paul Bourke proposed stackforge/kolla: Add base image for oraclelinux https://review.openstack.org/191013 | 16:33 |
| sdake | rhallisey good point | 16:33 |
| *** openstackgerrit has quit IRC | 16:33 | |
| harmw | rhallisey: I can fully agree to chaning it to something else, given a certain logic :) | 16:34 |
| sdake | do whatevery ou think is best ;) | 16:34 |
| *** openstackgerrit has joined #kolla | 16:34 | |
| harmw | there are more things in that area that deserve attntion btw | 16:34 |
| sdake | review process should pinpoint those harmw | 16:34 |
| sdake | harmw although if you have a pointer on these to avoid rework that would be appreciated :) | 16:35 |
| mstachow | who want do some review of my code :>? | 16:37 |
| mstachow | it also has got one variable with init_db | 16:38 |
| mstachow | but It will be great to know about other issues | 16:38 |
| harmw | sdake: I noticed some quircks in old containers | 16:40 |
| harmw | so in general, there is some polishing to do in that area | 16:40 |
| harmw | nothing big though | 16:41 |
| harmw | and yes, the reviewprocess is exactly what brought this to my mind :P | 16:41 |
| *** gfidente^2nd has joined #kolla | 16:44 | |
| *** gfidente has quit IRC | 16:45 | |
| openstackgerrit | Daneyon Hansen proposed stackforge/kolla: Spec to Add Support for High Availability https://review.openstack.org/181983 | 16:47 |
| sdake | harmw yes one big key advantage of reviewing patches is you learn how the code base works :) | 16:49 |
| sdake | that isn't by accident | 16:49 |
| sdake | this is why I appreciate any reviews from anyone - even if they are wrong :) | 16:49 |
| harmw | yep :) | 16:50 |
| harmw | now, time to feed while going over the H-A spec | 16:51 |
| *** mfalatic has joined #kolla | 16:54 | |
| daneyon_ | jpeeler ping | 16:54 |
| jpeeler | hey | 16:54 |
| jpeeler | i don't have much expertise with what the max_connections number should be, but i thought it was interesting that devstack uses 200, but that's for postgresql | 16:56 |
| jpeeler | i didn't realize 151 was the default, so i'm fine with keeping it as is and will change my vote based on your comment | 16:56 |
| SamYaple | 200 is a goos number for maeiadb+galera too | 16:56 |
| SamYaple | good* | 16:56 |
| SamYaple | i should get off pgone and sleep | 16:57 |
| mstachow | Try to get some sleep before our meeting SamYaple | 16:57 |
| jpeeler | SamYaple: the link i refenenced used 1024 for that scenario | 16:58 |
| jpeeler | but i do still wonder if there's any disadvantage to making the number higher than normal | 16:59 |
| SamYaple | jpeeler i shouldnt be comment atm. sorry brain stew. | 16:59 |
| jpeeler | SamYaple: it's too late, you just committed to another hour of IRC | 17:00 |
| jpeeler | j/k get some rest | 17:00 |
| openstackgerrit | Daneyon Hansen proposed stackforge/kolla: Fixes MariaDB to Support Heat https://review.openstack.org/192011 | 17:00 |
| daneyon_ | jpeeler re: https://review.openstack.org/#/c/192011/ I am open to changing the default if someone else can reproduce the issue. Otherwise, I am unsure whether this is an issue specific to my environment. | 17:01 |
| harmw | bla, blablablabla and bla bla and more bla [..] and your committed as a core reviewer to reviewing the work output of this specification. | 17:05 |
| harmw | check! | 17:05 |
| daneyon_ | rhallisey jpeeler harmw mandre when you have a moment, do u mind reviewing the HA spec: https://review.openstack.org/181983 As sdake requested, we would like to get feedback from the cores and a +2 if you are cool with the spec. | 17:05 |
| harmw | though I'm already afraid of it :p | 17:06 |
| jpeeler | daneyon_: honestly don't feel that strongly about it, just figured a higher number wouldn't hurt. sure i'll look at it soon. lunch first! | 17:06 |
| harmw | daneyon_: I +2'd it like 30secs ago :) | 17:07 |
| *** mfalatic has quit IRC | 17:07 | |
| daneyon_ | jpeeler thx. i think this could be a reason to increase the number but we just need someone else to reproduce. maybe we can just move forward with keeping the default consistent with upstream and adjust in the future if a big is filed similar to mine. | 17:08 |
| daneyon_ | harmw thx!!! | 17:08 |
| *** jmccarthy has quit IRC | 17:09 | |
| *** dwalsh has joined #kolla | 17:13 | |
| *** inc0 has joined #kolla | 17:15 | |
| inc0 | good evening everyone | 17:15 |
| *** dims_ has quit IRC | 17:16 | |
| *** dims has joined #kolla | 17:17 | |
| rhallisey | daneyon_, ya I'll have a look | 17:17 |
| daneyon_ | rhallisey thx | 17:17 |
| *** jtriley has quit IRC | 17:17 | |
| *** mfalatic has joined #kolla | 17:19 | |
| *** jasonsb has joined #kolla | 17:26 | |
| sdake | inc0 yo | 17:26 |
| inc0 | https://review.openstack.org/#/dashboard/?foreach=project%3Astackforge%2Fkolla+status%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%252D1+label%3AVerified%3E%3D1%252cjenkins+NOT+label%3ACode%252DReview%3E%3D0%252cself&title=Kolla+Review+Inbox&Proposal+Bot+Proposals=owner%3A%22OpenStack+Proposal+Bot+%3Copenstack%252Dinfra%40lists.openstack.org%3E%22&Needs+final+%2B2=label%3ACode%252DReview%3E%3D2+NOT+label%3ACode%252DReview%3C%3D%252D1+limit%3A50&Needs+Feed | 17:29 |
| inc0 | back+%28Changes+older+than+5+days+that+have+not+been+reviewed+by+anyone%29=NOT+label%3ACode%252DReview%3C%3D2+age%3A5d&You+are+a+reviewer%252c+but+haven%27t+voted+in+the+current+revision=NOT+label%3ACode%252DReview%3C%3D2%252cself+reviewer%3Aself&Passed+Jenkins%252c+No+Negative+Feedback=NOT+label%3ACode%252DReview%3E%3D2+NOT+label%3ACode%252DReview%3C%3D%252D1+limit%3A50&Wayward+Changes+%28Changes+with+no+code+review+in+the+last+2days%29=NOT+label%3ACode%252DRe | 17:29 |
| inc0 | view%3C%3D2+age%3A2d&Negative+Feedback=label%3ACode%252DReview%3C%3D%252D1+limit%3A10 | 17:29 |
| inc0 | that didn't end well, hold on | 17:29 |
| inc0 | http://paste.openstack.org/show/298976/ | 17:30 |
| *** sdake_ has joined #kolla | 17:30 | |
| *** rhallisey has quit IRC | 17:31 | |
| inc0 | http://tinyurl.com/odoqtcu or this one | 17:31 |
| *** rhallisey has joined #kolla | 17:32 | |
| *** sdake has quit IRC | 17:34 | |
| *** jtriley has joined #kolla | 17:42 | |
| *** jtriley has quit IRC | 17:55 | |
| *** sdake has joined #kolla | 17:58 | |
| *** sdake_ has quit IRC | 18:01 | |
| *** sdake_ has joined #kolla | 18:10 | |
| *** sdake has quit IRC | 18:14 | |
| *** athomas has quit IRC | 18:40 | |
| *** daneyon_ has quit IRC | 18:45 | |
| *** daneyon has joined #kolla | 18:46 | |
| *** nihilifer has quit IRC | 18:48 | |
| *** daneyon_ has joined #kolla | 18:49 | |
| *** akwasnie has joined #kolla | 18:51 | |
| *** daneyon has quit IRC | 18:52 | |
| *** mstachow has quit IRC | 18:54 | |
| *** jtriley has joined #kolla | 19:03 | |
| *** openstackgerrit has quit IRC | 19:16 | |
| *** openstackgerrit has joined #kolla | 19:16 | |
| *** jtriley has quit IRC | 19:18 | |
| *** nihilifer has joined #kolla | 19:23 | |
| sdake_ | hey folks just got around to reviewing the ansible-multi spec once again, thanks for your comments | 19:24 |
| sdake_ | I have responded inline | 19:24 |
| *** jtriley has joined #kolla | 19:26 | |
| *** gfidente^2nd is now known as gfidente | 19:41 | |
| *** gfidente has quit IRC | 19:41 | |
| *** gfidente has joined #kolla | 19:41 | |
| *** jtriley has quit IRC | 19:52 | |
| *** nihilifer_ has joined #kolla | 19:54 | |
| *** nihilifer has quit IRC | 19:56 | |
| *** jruano has joined #kolla | 20:03 | |
| *** jtriley has joined #kolla | 20:04 | |
| harmw | whats a big tent | 20:22 |
| harmw | one wonders... | 20:22 |
| rhallisey | https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/the-big-tent-a-look-at-the-new-openstack-projects-governance | 20:24 |
| harmw | jeez, got an executive summary? :P | 20:25 |
| bmace | a big tent, also known as a circus ;) | 20:26 |
| harmw | ah, with clowns | 20:26 |
| rhallisey | harmw, by the way I added INIT_CINDER_DB into the other patch that has changes to docs/integration-guide | 20:26 |
| harmw | ooh, lol | 20:27 |
| rhallisey | harmw, I understand it to be that openstack will try and accept more projects | 20:27 |
| harmw | I just no got that part | 20:27 |
| harmw | more? | 20:27 |
| rhallisey | I requirements and governance rules have been loosened | 20:28 |
| rhallisey | if I understand correctly | 20:28 |
| *** vinkman has quit IRC | 20:29 | |
| *** vinkman has joined #kolla | 20:30 | |
| harmw | right, well thats about enough reviews for tonight :) | 20:37 |
| *** inc0_ has joined #kolla | 20:44 | |
| *** absubram has quit IRC | 20:44 | |
| *** inc0 has quit IRC | 20:47 | |
| *** rhallisey has quit IRC | 20:52 | |
| openstackgerrit | imain proposed stackforge/kolla: Set up glance to use a data container. https://review.openstack.org/191975 | 20:56 |
| *** jruano has quit IRC | 21:04 | |
| sdake_ | running late | 21:05 |
| sdake_ | wrong channel | 21:05 |
| *** inc0_ has quit IRC | 21:08 | |
| *** jtriley has quit IRC | 21:11 | |
| sdake_ | harmw rhallisey this is also worth a read: https://github.com/openstack/governance/blob/master/reference/new-projects-requirements.rst | 21:12 |
| harmw | will do | 21:14 |
| harmw | god, todays meeting is way to late... | 21:14 |
| sdake_ | or anyone else that wants to see Kolla enter the big tent ) | 21:14 |
| sdake_ | ;) that is :) | 21:14 |
| harmw | I'm not sure if I can say awake for another hour though :P | 21:16 |
| sdake_ | red bull | 21:16 |
| sdake_ | hit the circle k | 21:16 |
| harmw | all out | 21:16 |
| sdake_ | or whatever the equivalent is in the nl :) | 21:16 |
| harmw | hhe | 21:17 |
| slagle | sdake_: thanks for clarying on the spec. i really don't know where the packaging argument was coming from | 21:21 |
| slagle | it's a totally unrelated technicality | 21:21 |
| sdake_ | sorry maybe i read into that too much based upon m years of thinking like a red hatter :) | 21:21 |
| sdake_ | slagle been one emergency after another in my household today | 21:21 |
| sdake_ | i re-read and think got to the meat of the ask | 21:22 |
| slagle | yea, i understand you're positioning | 21:23 |
| sdake_ | i totally want to cooperate with tripleo and think the spec represents that | 21:23 |
| *** openstackgerrit has quit IRC | 21:24 | |
| sdake_ | i suspect the community is completely on board with that concept | 21:24 |
| *** openstackgerrit has joined #kolla | 21:24 | |
| slagle | i feel it does as well. i think we've clarified around the only language i was concerned about | 21:24 |
| sdake_ | yup and reviews are a permanant record ;) | 21:25 |
| sdake_ | so if we don't hold up to our end of the bargain, call us out :) | 21:25 |
| sdake_ | bargain such a bad wor | 21:25 |
| sdake_ | d | 21:25 |
| * sdake_ needs to go to sleep | 21:25 | |
| slagle | :) | 21:25 |
| *** sdake_ is now known as sdake | 21:25 | |
| *** nihilifer_ is now known as nihilifer | 21:26 | |
| sdake | i think commitment i s a better word there slagle | 21:26 |
| *** jasonsb has quit IRC | 21:52 | |
| *** rhallisey has joined #kolla | 21:57 | |
| sdake | heads up, kolla meeting starting now in openstack-meeting-4 | 22:01 |
| *** dwalsh has quit IRC | 22:07 | |
| *** mfalatic has quit IRC | 22:07 | |
| *** mfalatic has joined #kolla | 22:08 | |
| harmw | so.. tired... | 22:16 |
| *** prad has quit IRC | 22:23 | |
| *** dims has quit IRC | 22:26 | |
| *** mstachow has joined #kolla | 22:27 | |
| *** akwasnie has quit IRC | 22:31 | |
| *** akwasnie has joined #kolla | 22:31 | |
| sdake | ok befoe harmw passes out | 22:40 |
| sdake | are people still reading the comments? | 22:40 |
| harmw | nope, isn't that something to do *before* these meetings :P since, obviously, reading takes time :p | 22:41 |
| sdake | yes i've ahrassed people to read for the last 15 days | 22:42 |
| sdake | and everyone keeps saying "i'll read it tomorrow" | 22:42 |
| harmw | and I did! :p | 22:42 |
| sdake | well tomorrow has come :) | 22:42 |
| sdake | jpeeler rhallisey I think your votes are outstanding | 22:42 |
| sdake | looks like daneyon changed hsi vote | 22:42 |
| *** pbourke has quit IRC | 22:44 | |
| *** pbourke has joined #kolla | 22:44 | |
| sdake | wrong channel | 22:45 |
| sdake | my bad | 22:45 |
| jpeeler | (for the record, i did read the spec when i said i would. i just didn't vote or comment) | 22:46 |
| *** jasonsb has joined #kolla | 22:46 | |
| harmw | whoops, kid fell out of bed :| back now | 22:49 |
| *** jasonsb has quit IRC | 22:58 | |
| openstackgerrit | Merged stackforge/kolla: Spec to Add Support for High Availability https://review.openstack.org/181983 | 22:58 |
| *** nihilifer has quit IRC | 23:01 | |
| *** mstachow has quit IRC | 23:04 | |
| *** mfalatic has quit IRC | 23:08 | |
| *** gfidente has quit IRC | 23:10 | |
| *** dims has joined #kolla | 23:24 | |
| *** rhallisey has quit IRC | 23:25 | |
| *** dims has quit IRC | 23:28 | |
| *** dims has joined #kolla | 23:28 | |
| openstackgerrit | Merged stackforge/kolla: Ansible multi-node specification https://review.openstack.org/189157 | 23:31 |
| *** kfox1111 has joined #kolla | 23:33 | |
| *** dims has quit IRC | 23:33 | |
| kfox1111 | Just swung by to say, congrats! :) | 23:33 |
| kfox1111 | That was a hard spec to get through, but I think it was very good. :) | 23:34 |
| *** blahRus has quit IRC | 23:37 | |
| sdake | kfox1111 the harder part is implementing :) | 23:41 |
| bmace | meh, the implementation is the fun part :) | 23:41 |
| sdake | jpeeler my bad :) | 23:42 |
| sdake | (reading scrollback) | 23:42 |
| sdake | listen guys, I wanted to clarify something that I forgot to metnion in the meeting | 23:43 |
| sdake | priority for reviews should be on specs if they are outstanding | 23:43 |
| sdake | god forbid we have new ones | 23:43 |
| sdake | but i didn't communicate that early on | 23:43 |
| sdake | so it was totally my lack of communication and a fialure on my part as a leader to set expectations there | 23:44 |
| sdake | so if anyone is to blame on the slow review process of the spec its me | 23:44 |
| sdake | in fact, blame me for all the bad things :) | 23:44 |
| *** diogogmt has quit IRC | 23:45 | |
| sdake | jpeeler make sense? | 23:45 |
| bmace | i'm all out of coffee... darn you sdake!!!! | 23:46 |
| sdake | the reason I cranked up the pressure on the reviews is because they are blocking alot of individuals progress | 23:46 |
| sdake | when our whole community is blocked on a decision, that is bad for progress | 23:47 |
| sdake | its one of the ptl's many jobs to unlock as many things as he/she can | 23:47 |
| sdake | so sorry for the temporary abuse ;) | 23:47 |
| kfox1111 | sdake: can you please be ptl on some other projects for me so you can speed up spec review on other projects? :) | 23:50 |
| kfox1111 | its killing me right now. :) | 23:51 |
| sdake | kfox1111 that process we went through causes a bit of discontent | 23:51 |
| sdake | (lifemeeting review of a change) | 23:51 |
| sdake | live meeting review of a change) | 23:52 |
| sdake | its nto something i'd use on a daily basis | 23:52 |
| sdake | i'd recommend every project abandon specs process except for critical changes ;) | 23:52 |
| kfox1111 | yeah. I'm trying to get specs through for features that cross openstack project silo's. Its really really bad for that. :/ | 23:52 |
| *** Haomeng|2 has joined #kolla | 23:53 | |
| sdake | the spec process is bad for just about eveything | 23:53 |
| sdake | necessary evil i guess | 23:53 |
| kfox1111 | something about software design by comittee.... hmm... | 23:53 |
| kfox1111 | :) | 23:53 |
| *** Haomeng has quit IRC | 23:55 | |
| kfox1111 | It has some benifits. More eyes to see creative alternatives can be a good thing. More eyes to simply bike shed things that really don't matter its its greatest flaw. :/ | 23:55 |
| sdake | it slows down velocity | 23:55 |
| kfox1111 | yeah. | 23:56 |
| sdake | some projects use it precisely for this purpose ;) | 23:56 |
| *** sdake_ has joined #kolla | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!