| *** vinkman has quit IRC | 00:03 | |
| *** sdake_ has joined #kolla | 00:06 | |
| *** sdake has quit IRC | 00:10 | |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make swift bashate compliant https://review.openstack.org/189166 | 00:10 |
|---|---|---|
| openstackgerrit | Merged stackforge/kolla: Autogenerated value for DESIGNATE_POOLMAN_POOLID https://review.openstack.org/189043 | 00:18 |
| *** sdake has joined #kolla | 00:32 | |
| *** sdake_ has quit IRC | 00:35 | |
| *** zhiwei has joined #kolla | 00:39 | |
| *** sdake_ has joined #kolla | 01:06 | |
| *** dims__ has quit IRC | 01:06 | |
| *** sdake__ has joined #kolla | 01:09 | |
| *** sdake has quit IRC | 01:09 | |
| *** sdake__ is now known as sdake | 01:09 | |
| *** sdake_ has quit IRC | 01:13 | |
| *** jtriley has joined #kolla | 01:26 | |
| *** jpeeler has joined #kolla | 01:26 | |
| *** jtriley has quit IRC | 01:31 | |
| *** erkules_ has joined #kolla | 01:32 | |
| *** erkules has quit IRC | 01:35 | |
| zhiwei | sdake: If you are using VIM, you can add these lines to ~/.vimrc file. http://paste.openstack.org/show/272544/ | 01:40 |
| sdake | thanks zhiwei I am ware of that | 01:41 |
| sdake | but it makes my screen bleed when I'm typing :) | 01:41 |
| zhiwei | haha | 01:41 |
| zhiwei | you can remove the highlight line | 01:41 |
| zhiwei | only add the autoremove section. | 01:41 |
| sdake | i like my vi the way it is :) | 01:42 |
| sdake | *default* :) | 01:42 |
| zhiwei | ya | 01:42 |
| sdake | i'll submit another review if a review is busted ;) | 01:42 |
| zhiwei | ok | 01:42 |
| *** sdake_ has joined #kolla | 01:43 | |
| zhiwei | can we use ansible for both aio and multi node deployment? | 01:43 |
| *** sdake has quit IRC | 01:46 | |
| sdake_ | i dont see why not | 01:47 |
| sdake_ | just a matter of the inventory file | 01:47 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Ansible multi-node specification https://review.openstack.org/189157 | 01:49 |
| sdake_ | zhiwei in the future if you wouldn't mind voting +1 or -1, so I know the problems you found are met, i'd super appreciate it :) | 01:50 |
| zhiwei | ok, will do that. | 01:51 |
| sdake_ | ta | 01:51 |
| *** sdake has joined #kolla | 01:54 | |
| *** sdake_ has quit IRC | 01:58 | |
| *** dims_ has joined #kolla | 01:58 | |
| *** dims_ has quit IRC | 02:03 | |
| sdake | zhiwei the defeciency has been corrected, can you revote plz | 02:08 |
| zhiwei | sdake: new comments added. | 02:23 |
| *** sdake_ has joined #kolla | 02:25 | |
| *** sdake has quit IRC | 02:29 | |
| *** bmace has quit IRC | 02:31 | |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Ansible multi-node specification https://review.openstack.org/189157 | 02:32 |
| sdake_ | zhiwei ok problems should be fixed ;-) | 02:43 |
| zhiwei | I saw | 02:43 |
| *** bmace has joined #kolla | 02:44 | |
| *** sdake has joined #kolla | 02:44 | |
| *** sdake_ has quit IRC | 02:48 | |
| *** dims_ has joined #kolla | 03:03 | |
| sdake | bmace there? | 03:04 |
| *** dims_ has quit IRC | 03:09 | |
| *** jtriley has joined #kolla | 03:15 | |
| SamYaple | sdake: i am here | 03:16 |
| sdake | samyaple for your viewing pleasure | 03:17 |
| sdake | https://review.openstack.org/189157 | 03:17 |
| SamYaple | yup skimmed it | 03:17 |
| * sdake has to work with someone from every timezone | 03:17 | |
| * sdake groans | 03:17 | |
| SamYaple | good work | 03:17 |
| SamYaple | do be fair, im only like 2 hours off of your timezone... | 03:17 |
| sdake | Kevin has some interesting thoughts in review #2 | 03:17 |
| SamYaple | to* | 03:17 |
| sdake | I wouldn't do it if I didn't choose to ;) | 03:18 |
| sdake | (the tz thing) | 03:18 |
| *** jtriley has quit IRC | 03:20 | |
| SamYaple | " If the reason is to have containers not change once they start, you could pass the config files through a unique dir per container /var/lib/kola/onfdir/<id>/ or something. Then pass it through from the host." | 03:20 |
| SamYaple | how ouwld that work? | 03:20 |
| sdake | bindmount /etc/blerg | 03:20 |
| sdake | copy /etc/blerg/keystone.conf /etc/keystone.conf ; rm -f /etc/blerg/keystone.conf | 03:20 |
| SamYaple | but the bndmount never goes away | 03:21 |
| SamYaple | that is by far the cleanest solution and I like that idea for sure | 03:21 |
| SamYaple | but the bindmount persists | 03:21 |
| sdake | ya I'm not quite sure what to make of it | 03:22 |
| SamYaple | interestingly, through the docker api we could remove the bindmount without regenerating a new container | 03:22 |
| SamYaple | it would remove the ability to docker inspect and backup the container, configs and all | 03:23 |
| SamYaple | its dancing o nthe edge of non-immutable containers | 03:23 |
| sdake | I agree | 03:24 |
| sdake | i have a preference for serialization/deserialization | 03:25 |
| sdake | samyaple if there is anything I got wrong in the spec, please comment and vote on it so it can be corrected or merged ;-) | 03:27 |
| *** dasm has quit IRC | 03:27 | |
| *** shadower has quit IRC | 03:27 | |
| *** bradjones|away has quit IRC | 03:27 | |
| *** dasm has joined #kolla | 03:28 | |
| SamYaple | serialization/deserialization does work very weel, but it can be a bit confusing/opaque I agree | 03:28 |
| SamYaple | it can be used by anyone though, not just ansible | 03:28 |
| *** bradjones has joined #kolla | 03:28 | |
| *** bradjones has joined #kolla | 03:28 | |
| sdake | feel free to comment with kevin's review as well | 03:29 |
| sdake | there was a Q re security hidden in there ;) | 03:29 |
| SamYaple | answered already | 03:29 |
| SamYaple | or replied too | 03:29 |
| SamYaple | the inventory is _not_ optional | 03:29 |
| sdake | if you reply to his comments, you have to click "review" on the review where you commented | 03:30 |
| sdake | he was talking abou the unified config file to be optional | 03:30 |
| sdake | not the inventory file | 03:30 |
| sdake | I may just remove that language | 03:30 |
| SamYaple | i think kevin means to say the inventory should be optional, it is not | 03:31 |
| sdake | depends what happens next week | 03:31 |
| sdake | recommend asking in the review - the seciton talks about a unified config file | 03:31 |
| SamYaple | not that section | 03:31 |
| sdake | ok | 03:31 |
| sdake | maybe i'm too tired to function :) | 03:31 |
| SamYaple | its cool | 03:31 |
| *** dasm has quit IRC | 04:54 | |
| *** jtriley has joined #kolla | 05:04 | |
| *** jtriley has quit IRC | 05:08 | |
| *** nihilifer_ has joined #kolla | 05:09 | |
| *** dasm|afk has quit IRC | 06:04 | |
| *** dasm has joined #kolla | 06:12 | |
| dasm | good morning :) | 06:12 |
| SamYaple | good morning dasm | 06:20 |
| sdake | hey dasm | 06:26 |
| sdake | dasm highest priority review https://review.openstack.org/189157 | 06:26 |
| sdake | plz take a look ;) | 06:26 |
| *** tobe has joined #kolla | 06:45 | |
| *** jtriley has joined #kolla | 06:52 | |
| *** jtriley has quit IRC | 06:58 | |
| *** inc0 has joined #kolla | 07:01 | |
| inc0 | good morning | 07:01 |
| SamYaple | hello inc0 | 07:01 |
| SamYaple | how are you | 07:01 |
| inc0 | we had long weekend in PL, so a bit lazy afterwards | 07:02 |
| SamYaple | PL? | 07:03 |
| inc0 | Poland | 07:03 |
| SamYaple | oh cool | 07:03 |
| inc0 | 4 days is enough to forget about work;) | 07:03 |
| SamYaple | tell that to sdake | 07:04 |
| inc0 | today is good day to resolve corporate paperwork and maybe just address few comments | 07:05 |
| inc0 | or make nitpicks reviews;P | 07:05 |
| inc0 | ;) | 07:05 |
| inc0 | speaking of which...Steven was busy | 07:06 |
| inc0 | I've just seen gerrit | 07:07 |
| SamYaple | the dake sleeps for no man | 07:07 |
| *** fabiand has joined #kolla | 07:08 | |
| fabiand | Hey | 07:08 |
| SamYaple | hello | 07:09 |
| inc0 | morning | 07:09 |
| fabiand | Oh - this time zone also seems to be represented .) | 07:10 |
| fabiand | :) | 07:10 |
| fabiand | Hey, I'm looking at the kolla dockerfiles, and wondered a bit about cinder. | 07:10 |
| fabiand | Isn't cinder also using an iscsi initiator? | 07:10 |
| fabiand | Or is it rather a target, and nova is using the initiator to connect to it? | 07:11 |
| inc0 | well, I think it's nova who does connections | 07:11 |
| inc0 | and cinder just exposes target, but I'm not sure about that | 07:11 |
| fabiand | My reason for asking is around the question if someone ever tried to connect to iscsi targets from within the container | 07:12 |
| fabiand | inc0, right - that sounds reasonable to me .. | 07:12 |
| fabiand | We also tried to run an iscsi initiator inside a container and ran into some trouble | 07:13 |
| inc0 | I don't think we contenerize qemu, but we do contenerize nova-compute | 07:14 |
| SamYaple | inc0: we containerize everything | 07:14 |
| fabiand | inc0, so qemu is directly accessing the iscsi tgt by it's built-in iscsi support? | 07:15 |
| fabiand | we do it indirectly by pointing qemu to a local device mapping the the remote target (so using iscsiadm to discover and attach the remote tgt) | 07:15 |
| inc0 | I supose, but I never really looked at that | 07:15 |
| fabiand | Right, I'll loook at it as well. | 07:16 |
| SamYaple | however nova does it fabiand. ill check | 07:16 |
| fabiand | Another issue we had is that - we meess with lvm etc - that lvm would not work correctly without udev | 07:16 |
| SamYaple | fabiand: it will actually work, but you have to mount in /dev | 07:16 |
| fabiand | And I wondered of cinder is also manipulating storage devices, or just exposing already available devices .. | 07:17 |
| SamYaple | then the host udev can handle everything | 07:17 |
| fabiand | SamYaple, ah .. | 07:17 |
| fabiand | You seee parts if you do that, you see the kernel events, but you don't get all the udev event's from the udev daemin | 07:17 |
| fabiand | daemon | 07:17 |
| *** athomas has joined #kolla | 07:18 | |
| SamYaple | fabiand: looks like iscsi is attached to the host, not using qemu initiator | 07:18 |
| fabiand | SamYaple, cool - thanks for looking | 07:18 |
| fabiand | Then I'd really be interested if that was tried, because here as well, udev played a role .. | 07:18 |
| SamYaple | using the qemu initiator would actually resolve alot of the cinder headaches | 07:18 |
| fabiand | :) | 07:18 |
| SamYaple | http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/qemu-built-in-iscsi-initiator.html | 07:19 |
| inc0 | https://github.com/openstack/nova/blob/master/nova/virt/volumeutils.py#L23 | 07:19 |
| inc0 | fabiand, and btw, person you'd really want to talk to is rhallisey | 07:20 |
| SamYaple | yea fabiand he did all the cinder work | 07:20 |
| SamYaple | ive only done cinder+ceph stuff. i abandonded lvm+iscsi long ago | 07:20 |
| fabiand | Why did you abandon it, SamYaple ? | 07:20 |
| fabiand | Did someone take it over, or did you run into difficulties? | 07:21 |
| SamYaple | for the reasons we are having the conversation xD | 07:21 |
| fabiand | inc0, SamYaple -- I'll then wait for him .. | 07:21 |
| fabiand | You mean, it did nto work? | 07:21 |
| inc0 | iscsi is hard to contenerize | 07:22 |
| inc0 | and really not too many people use it on prod | 07:22 |
| fabiand | :) | 07:22 |
| inc0 | ususally prod is ceph based | 07:22 |
| fabiand | Right | 07:22 |
| SamYaple | i didnt dig into it to much. ceph is a much better storage system for openstack in my opinion | 07:22 |
| * fabiand comes from the oVirt land ... and there people do use iSCSI in production | 07:22 | |
| SamYaple | its more openstack-ihs too | 07:22 |
| fabiand | Yep, I think ceph works nicely in containers .. | 07:22 |
| SamYaple | fabiand: dont feel bad, its all iscsi where I work | 07:23 |
| fabiand | a lot of the device stuff is not there. | 07:23 |
| inc0 | and it's *way* more scallable | 07:23 |
| fabiand | I believe qemu access ceph directly? | 07:23 |
| SamYaple | yes | 07:23 |
| fabiand | There we goo .. | 07:23 |
| fabiand | Then you don't have these core issue with udev | 07:23 |
| fabiand | udev really is a bummer in the container land | 07:23 |
| * SamYaple shudders | 07:23 | |
| SamYaple | udev ugh | 07:23 |
| fabiand | SamYaple, I don't feel bad about iSCSI, just getting it containerized | 07:23 |
| inc0 | nope, ceph does all that and it exposes block devices | 07:23 |
| fabiand | inc0, right ... | 07:24 |
| inc0 | nova can use it for ephemeral disks as well | 07:24 |
| inc0 | out of the box | 07:24 |
| SamYaple | inc0: kinda. ceph in containers is still a bit annoying _if_ you let container mount the disk | 07:24 |
| fabiand | Oh well .. okay, it exposes block devices, and qemu is using them .. | 07:24 |
| fabiand | SamYaple, would you elaborate on that? I mean - who should mount the disk, if not the container? | 07:24 |
| SamYaple | I mount it external with the host and bindmount it into the container | 07:25 |
| fabiand | Awh! That's cheating :) | 07:25 |
| SamYaple | otherwise youll have issue with the mount namespace disappering during a container restart | 07:25 |
| fabiand | Yes, I see .. | 07:25 |
| SamYaple | nah its the only safe way t ogo! | 07:25 |
| fabiand | Well, you could have a data container :) | 07:26 |
| SamYaple | i care about data integrity | 07:26 |
| SamYaple | not with ceph, since youll only get performance when its talking to the raw disk for journaling | 07:26 |
| inc0 | don't forget we don't care about separation *that* much - kolla isn't supposed to be multitenant project | 07:26 |
| fabiand | Right .. | 07:26 |
| SamYaple | inc0: what do you mean by that? | 07:27 |
| SamYaple | i most certainly care about seperation | 07:27 |
| fabiand | inc0, I was about to throw that in - isolation, you give up isolation ... | 07:27 |
| fabiand | But yes, I - I agree, sometimes you don#t care about that aspect of containers. | 07:27 |
| *** jasonsb has quit IRC | 07:27 | |
| inc0 | I mean if container plays with base system, when it has to (kernel, storage), we can run priviledged containers | 07:27 |
| fabiand | (limited) | 07:27 |
| SamYaple | you guys do know oyu can still access all the container storage in /var/lib/docker right? | 07:27 |
| *** jasonsb has joined #kolla | 07:28 | |
| inc0 | what I mean is we don't do that lightly, but we can do that | 07:28 |
| inc0 | otherwise things would be much uglier | 07:29 |
| * fabiand sees that cinder is manipulating LVM .. so I'm curious to speak with rhallisey | 07:29 | |
| SamYaple | agreed. im still not happy about everything running as root in the container. but i havent got around to patching in all the yaodu stuff to fix that yet | 07:29 |
| SamYaple | root in container == root on host | 07:29 |
| fabiand | Yes .. | 07:29 |
| fabiand | You also neet to be in peermissive mode with that many bind mounts form the host side, right? | 07:30 |
| inc0 | I'm pretty sure there will be things which won't be doable without priviledged mode | 07:30 |
| SamYaple | inc0: things will be harder to do, but root is root | 07:30 |
| inc0 | still, since kolla is deployment method, I don't think this is that much of an issue | 07:30 |
| inc0 | I mean, people would deploy this stuff as root anyway | 07:31 |
| SamYaple | no its pretty important. its just a few lines and we can have a MUCH more secure project. | 07:31 |
| fabiand | I also saw that some (maybe neutron?) are using --net=host ... How is the experience with that so far. | 07:31 |
| fabiand | Any performance impact or management difficulties? | 07:31 |
| SamYaple | fabiand: everything uses --net=host | 07:32 |
| SamYaple | its for performance | 07:32 |
| fabiand | Oh, everything .. | 07:32 |
| fabiand | Right | 07:32 |
| SamYaple | docker-proxy is slow as dirt | 07:32 |
| SamYaple | something like a ~20ms delay per packet | 07:32 |
| fabiand | Yeah, I read that in the spec | 07:32 |
| *** jasonsb has quit IRC | 07:32 | |
| SamYaple | personally i like --net=host, but it requires a bit more tying container to host in the config files | 07:33 |
| fabiand | Yes .. | 07:33 |
| fabiand | I thought about an approach where the container claims all the devices which are not yet configured when it get#s started .. | 07:34 |
| SamYaple | only a bit though. some stuff would still need those per host configs (mariadb/galera, rabbitmq, some openstakc services) | 07:34 |
| fabiand | Then you can leave like one device to the host, for mgmt/communication and the rest is moved into the container ns .. | 07:34 |
| SamYaple | :) i like ideas like that. i would like to see an implementation | 07:35 |
| fabiand | SamYaple, http://dummdida.tumblr.com/post/118686497295/moving-unconnected-nics-into-a-container-namespace -- just needs to be pulled into the container | 07:35 |
| SamYaple | ah i see. this isn't something the container automatically does | 07:36 |
| *** mstachow has joined #kolla | 07:36 | |
| *** mstachow has quit IRC | 07:37 | |
| harmw | sdake: sup | 07:50 |
| *** gfidente has joined #kolla | 07:51 | |
| harmw | sdake: if its about https://review.openstack.org/#/c/189157/4/specs/ansible-multi.rst, Ill be heading down ansible-road from this week on - now that designate got merged, finally :) | 07:55 |
| *** dims_ has joined #kolla | 08:28 | |
| *** dims_ has quit IRC | 08:33 | |
| *** shadower has joined #kolla | 08:34 | |
| *** jtriley has joined #kolla | 08:41 | |
| *** jtriley has quit IRC | 08:46 | |
| *** weiyu-001 has joined #kolla | 08:52 | |
| *** inc0 has quit IRC | 08:57 | |
| *** inc0 has joined #kolla | 08:59 | |
| openstackgerrit | Paul Bourke proposed stackforge/kolla: Documentation improvements and minor fixups https://review.openstack.org/188742 | 08:59 |
| *** jasonsb has joined #kolla | 09:02 | |
| fabiand | mh, btw - SamYaple inc0 -- did you experience selinux issues when biond mounting much stuff from the host? | 09:04 |
| fabiand | I imagine that you'll need to turn off selinux to get freedom when you bind mount in a lot of paths from the host. | 09:05 |
| fabiand | But I haven't investigated that area so far .. | 09:05 |
| SamYaple | we make turning selinux off a requiremnt for kolla | 09:05 |
| fabiand | hehe | 09:08 |
| fabiand | Will it stay like that? | 09:08 |
| fabiand | Or do you plan to somehow get along with selinux? | 09:09 |
| SamYaple | probably | 09:09 |
| SamYaple | its more a docker+selinux thing | 09:09 |
| SamYaple | it has its own issues | 09:09 |
| fabiand | Yeah .. | 09:09 |
| SamYaple | i dont think anyone is against supporting it, but it isnt possible at the moment | 09:10 |
| fabiand | Right | 09:10 |
| SamYaple | i honestly havent dug into it for quite a while | 09:10 |
| fabiand | Yeah .. | 09:10 |
| fabiand | It will be quite a mess IMO | 09:10 |
| SamYaple | i agree | 09:10 |
| fabiand | I.e. I'd imagine that you get denials for each bind mount you use .. | 09:10 |
| fabiand | etc | 09:11 |
| *** jasonsb has quit IRC | 09:13 | |
| SamYaple | it also requires kolla ot maintain profiles for selinux and inject them on the host | 09:13 |
| SamYaple | i would like to get there htoug | 09:14 |
| fabiand | Yeah, sure, that would be a solution | 09:14 |
| *** inc0 has quit IRC | 09:27 | |
| *** inc0 has joined #kolla | 09:33 | |
| *** zhiwei has quit IRC | 09:55 | |
| *** sdake has quit IRC | 10:00 | |
| *** inc0 has quit IRC | 10:01 | |
| *** openstackgerrit has quit IRC | 10:09 | |
| *** dims_ has joined #kolla | 10:09 | |
| *** openstackgerrit has joined #kolla | 10:09 | |
| *** shardy_ has joined #kolla | 10:19 | |
| *** shardy has quit IRC | 10:21 | |
| SamYaple | pdb: you around? | 10:24 |
| pdb | SamYaple: howdy | 10:24 |
| SamYaple | hey! | 10:24 |
| *** shardy_ has quit IRC | 10:25 | |
| SamYaple | per your ansible spec review | 10:25 |
| SamYaple | can you define what ansible generated configs into a container would look like? | 10:25 |
| *** shardy has joined #kolla | 10:25 | |
| pdb | well, originally in an implementation I toyed with internally, we had ansible push configs out to target nodes, then bind mounted them to containers. However given bind mounts are something we want to avoid, I wondering if there's a way we can store them in data vols instead | 10:27 |
| SamYaple | it would require a recreation of the data vol to update the configs | 10:27 |
| SamYaple | bindmounting is what i did in yaodu as well | 10:27 |
| SamYaple | it worked fine, except you had permissions issues | 10:28 |
| pdb | I think that's the main reason we used bind mounts | 10:28 |
| pdb | permissions should be ok so long as you store the configs somewhere the ansible user can write to | 10:29 |
| SamYaple | pdb: nope. doesnt work like that | 10:29 |
| SamYaple | you have to match the uid from the user in the container to the file | 10:29 |
| SamYaple | with yaodu I solved this with a "yaodu" user and group on the host, not ideal for sure | 10:30 |
| *** jtriley has joined #kolla | 10:30 | |
| SamYaple | I am open to other suggestions. I have been thinking about this issue for ~4 months now. The generated configs are the cleanest solution I can find with the least amount of maintenance | 10:31 |
| SamYaple | the env variable to config option mapping of crudini is not sustatainable in my opinion | 10:31 |
| pdb | yeah I would not be in favor of maintaing the crudini option at all tbh | 10:31 |
| SamYaple | well that has to stick around to support triple-o downstream (unless that can be eventually changed) | 10:32 |
| SamYaple | but it doesnt have to be the default/required | 10:32 |
| pdb | Im probably lacking context on this, but it feels we're making this more difficult for ourselves just to support a project that only potentially might use kolla | 10:34 |
| pdb | s/this/things | 10:34 |
| *** jtriley has quit IRC | 10:35 | |
| SamYaple | I understand. sdake is leading this and his stance is we dont leave people/projects behind. I agree with him, but it is on those who use crudini to maintain it | 10:35 |
| SamYaple | im more interested in your thoughts on the dynamic config since that is the blocker for moving forward | 10:35 |
| pdb | yeah I'll have a think about it some more and let you know | 10:37 |
| pdb | sort of curious about this permissions with bind mounts you mentioned as I really dont recall having issues there | 10:38 |
| SamYaple | you were running as root in the container | 10:38 |
| pdb | yes :) | 10:38 |
| SamYaple | that is why it worked | 10:38 |
| pdb | thought so | 10:38 |
| SamYaple | and why its bad | 10:38 |
| SamYaple | in yaodu i did it proper with user and dropping privs | 10:39 |
| SamYaple | well do that in kolla too, but only so many hours in the day | 10:39 |
| pdb | that's fair enough. From what Ive heard bind mounts aren't an option anyway? | 10:39 |
| SamYaple | everyhting is an option, but sdake makes valid point against them that I cant argue | 10:39 |
| SamYaple | pdb: your comment about other non configini configs is valid | 10:42 |
| SamYaple | i had thought about this | 10:42 |
| SamYaple | there is an ugly option, that works well | 10:42 |
| SamYaple | base64 the non config-ini configs and convert them in much the same manner | 10:42 |
| pdb | how does that work with the augment files though? | 10:43 |
| SamYaple | so fun fact about the augment files. the merging happens outside the container | 10:44 |
| SamYaple | it is just an ansible module i wrote to merge config-ini files (can be run as native python file with some tweaking) | 10:45 |
| SamYaple | the rabbit configs are wierd because erlang is wierd | 10:45 |
| pdb | yeah what I was going to say | 10:45 |
| SamYaple | but could be merged just the same | 10:45 |
| SamYaple | not the same module, but a new one for rabbit | 10:45 |
| pdb | regardless of where it happens, you'll have to end up writing custom merge code for each config format? | 10:46 |
| SamYaple | mysql is ocnfig ini parsible | 10:46 |
| SamYaple | how many custom configs are there :) | 10:46 |
| SamYaple | rabbit and configini | 10:46 |
| SamYaple | between those two thats all of openstack | 10:46 |
| pdb | haproxy | 10:46 |
| SamYaple | thats a hole nother thing | 10:47 |
| SamYaple | whole* other* | 10:47 |
| SamYaple | so that one is very tricky, but has nothing to do with the generated/augment stuff | 10:47 |
| SamYaple | and it depends on what we want to allow being configurrable | 10:47 |
| SamYaple | I believ ethe fully configurable bit was only for openstack configs (though I would like to extend it as far as feasible) | 10:48 |
| pdb | I need to revisit sdake's arguments around bind mounts. I think you're approach is a decent compromise but do see it as being complex and there will be complications in the serialisation/deserialisation rigmarole | 10:52 |
| pdb | s/you're/your/ | 10:52 |
| SamYaple | yea i agree. i would love to make it less ocmplicated | 10:52 |
| SamYaple | bind mounts were way cleaner imo | 10:52 |
| pdb | its much easier for the user and newcomers to understand, that probably shouldn't be underestimated | 10:53 |
| SamYaple | plus it lets you keep the traditional 'from host modify /etc/keystone/keysotne.conf and restart container' approach | 10:53 |
| pdb | what I was about to say | 10:53 |
| pdb | :) | 10:53 |
| SamYaple | dont get me wrong, it is very clean and works well | 10:53 |
| SamYaple | if the community is ok with a seperate kolla user it is also secure | 10:54 |
| SamYaple | i chose are random uid and guid, but they were static assignments | 10:54 |
| SamYaple | 42424 i think | 10:54 |
| pdb | It's not really related to my views but we have had customers here say they want the option of modifying configs on the target for debugging/testing/etc | 10:54 |
| pdb | I guess depending on the arguments for/against we could make it another deploy option | 10:55 |
| SamYaple | as long as I can do dynamic config generation and privelege dropping (running as a user, not root) im happy | 10:55 |
| SamYaple | but keep in mind, its a config per container | 10:55 |
| SamYaple | we would have nova-api.conf nova-compute.conf nova-scheulder.conf | 10:56 |
| SamYaple | (well nova-compute.conf was a different ocnfig in the past, but you get my point) | 10:56 |
| pdb | is that a problem? | 10:56 |
| SamYaple | no, but its not /etc/nova/nova.conf is my point | 10:57 |
| pdb | sure | 10:57 |
| SamYaple | realisitcally it would be /opt/kolla/nova/scheduler.conf | 10:57 |
| SamYaple | or something like that | 10:57 |
| SamYaple | that file would be /etc/nova/nova.conf in the container | 10:57 |
| pdb | yeah that's how I did it | 10:57 |
| SamYaple | same on yaodu :) | 10:57 |
| pdb | seeing a pattern here ;) | 10:58 |
| SamYaple | KISS | 10:58 |
| pdb | yup | 10:58 |
| SamYaple | damn. now im going to have to have a conversation about this. | 10:59 |
| * SamYaple sighs | 10:59 | |
| SamYaple | i suppose we need a poll from the community on what they want. ie configs modifiable outside of docker and bindmounted in or truly idempotent containers | 11:00 |
| pdb | are bind mounts any less idempotent than the env file? | 11:02 |
| SamYaple | yea | 11:02 |
| SamYaple | the env cant change in the container | 11:02 |
| SamYaple | if its bindmounted it can | 11:02 |
| pdb | yeah but realistically the container wont change once the service has started | 11:03 |
| SamYaple | idempotent is about restarting | 11:03 |
| pdb | what if I change the env file though and restart | 11:03 |
| SamYaple | wit hthe env method itll get overwritten | 11:04 |
| SamYaple | bindmount the change takes effect | 11:04 |
| pdb | are you not startng the container with something like --env-file=openstack.env | 11:04 |
| SamYaple | kinda? best way to put it. mostly no | 11:05 |
| SamYaple | https://gist.github.com/SamYaple/444e20b067695e8ac838 | 11:05 |
| SamYaple | pdb ^ | 11:05 |
| *** tobe has quit IRC | 11:26 | |
| *** inc0 has joined #kolla | 11:51 | |
| *** jtriley has joined #kolla | 12:19 | |
| *** rhallisey has joined #kolla | 12:20 | |
| *** ChanServ sets mode: +o rhallisey | 12:23 | |
| *** rhallisey is now known as rhallisey|pto | 12:23 | |
| *** jtriley has quit IRC | 12:24 | |
| *** nihilifer_ has quit IRC | 12:28 | |
| *** shardy_ has joined #kolla | 12:36 | |
| *** shardy has quit IRC | 12:38 | |
| *** pdb has quit IRC | 12:41 | |
| *** pdb has joined #kolla | 12:42 | |
| *** shardy_ has quit IRC | 12:42 | |
| *** shardy has joined #kolla | 12:43 | |
| *** fabiand has quit IRC | 12:43 | |
| *** prad has joined #kolla | 12:45 | |
| *** fabiand has joined #kolla | 12:55 | |
| *** fabiand has quit IRC | 12:55 | |
| *** fabiand has joined #kolla | 12:55 | |
| *** fabiand has quit IRC | 12:59 | |
| *** fabiand has joined #kolla | 12:59 | |
| *** dwalsh has joined #kolla | 13:28 | |
| *** jtriley has joined #kolla | 13:30 | |
| *** jtriley has quit IRC | 13:35 | |
| *** jtriley has joined #kolla | 13:45 | |
| *** sdake has joined #kolla | 13:48 | |
| pdb | SamYaple: what was the reasoning behind .buildconf rather than making it a parameter? | 13:52 |
| *** gfidente has quit IRC | 13:52 | |
| sdake | morning please review https://review.openstack.org/#/c/189157/ | 13:53 |
| *** jtriley has quit IRC | 13:54 | |
| pdb | sdake: hi, thanks for the reply. was discussing it somewhat with SamYaple earlier this morning (our morning :)) | 13:57 |
| sdake | discuss in review plz :) | 13:58 |
| pdb | ok | 13:58 |
| *** sdake_ has joined #kolla | 14:00 | |
| SamYaple | pdb: i didnt do .buildconf but i am trying to get rid of it ;) | 14:03 |
| pdb | SamYaple: ok, that reminds me I still need to run my blueprint past sdake | 14:03 |
| pdb | SamYaple: I feel I would remove them in favor of a parameter to the build script | 14:03 |
| pdb | sdake: would you mind having a look at this if you get a chance? https://blueprints.launchpad.net/kolla/+spec/refactor-base-image-layout | 14:04 |
| *** sdake has quit IRC | 14:04 | |
| SamYaple | pdb: the issue with that is the differences in the scripts that may pop up with different distros | 14:05 |
| SamYaple | im ok with it, but this means added if;then;else blocks for every distro | 14:06 |
| pdb | SamYaple: yes, you had suggested that approach and I think it sounds good | 14:06 |
| SamYaple | oh then we have discussed this | 14:06 |
| pdb | I believe it's how devstack does it | 14:06 |
| SamYaple | lets not base what we do on devstack | 14:07 |
| *** fabiand has quit IRC | 14:07 | |
| *** fabiand has joined #kolla | 14:08 | |
| *** jtriley has joined #kolla | 14:08 | |
| *** fabiand has quit IRC | 14:09 | |
| *** vinkman has joined #kolla | 14:10 | |
| openstackgerrit | Michal Jastrzebski (inc0) proposed stackforge/kolla: Keepalived container https://review.openstack.org/187981 | 14:16 |
| sdake_ | inc0 did you have a chance to review the blueprint on ansible | 14:17 |
| inc0 | sdake_, unfortunately I haven't I had cluster of meetings today | 14:18 |
| inc0 | I'll do that first thing tomorrow | 14:18 |
| sdake_ | groan | 14:18 |
| sdake_ | i'll be out of the office tomorrow | 14:18 |
| inc0 | ok, I'll look at it now then | 14:18 |
| sdake_ | thanks :) | 14:18 |
| sdake_ | love you long time ;) | 14:19 |
| sdake_ | samyaple what are your thoughts on a data volume for config data vs serialization/deserialization | 14:19 |
| sdake_ | i had this idea some time ago as well | 14:20 |
| pdb | sdake_: in spirit of discussing on the review my reply is there now | 14:20 |
| SamYaple | data volume will not work | 14:22 |
| SamYaple | it would have to be a bind mount | 14:22 |
| sdake_ | pdb i put your blueprint in the discussion state and added some discussion to the whiteboard | 14:22 |
| sdake_ | feel free to respond at your liesure :) | 14:22 |
| pdb | sdake_: thanks very much | 14:23 |
| sdake_ | well it would be a -volumes-from which is a bindmount but we should be ok with volume-from bindmounts | 14:23 |
| sdake_ | is that the type of bindmount you speak of or something else? | 14:23 |
| SamYaple | no, bind mount host files | 14:24 |
| SamYaple | using a "data container" would not work | 14:24 |
| SamYaple | there is no way t oupdate those files | 14:24 |
| inc0 | sdake_, uhh...having 2 different configs might bite us someday | 14:27 |
| sdake_ | delete the data container make a new one? | 14:27 |
| vinkman | Hmmm… I would vote against bind mounting host files into the containers… It opens the door to people doing all kinds of random things to the configurations… | 14:28 |
| sdake_ | vinkman yes that idea is definately vetoed by everyone involved :) | 14:28 |
| inc0 | vinkman, who "people"? admins? | 14:28 |
| sdake_ | anyone with access | 14:28 |
| vinkman | anyone with access to the host... | 14:29 |
| sdake_ | it violates immutability and the declartive nature of properties | 14:29 |
| sdake_ | of containers that is | 14:29 |
| inc0 | do we care about admins breaking their own cluster? | 14:30 |
| pdb | you can lock down the permissions of the configs to the ansible user | 14:30 |
| sdake_ | yes inc0 | 14:30 |
| sdake_ | inc0 the installation should take precautions to protect the admin from themselves if possible :) | 14:31 |
| sdake_ | if they rm -rf / then what can we do? :) | 14:31 |
| sdake_ | but an admin might think its ok to go mucking with config variables in a live running container | 14:31 |
| sdake_ | which is definately not ok | 14:32 |
| sdake_ | samyaple do you mean it is technically not possible? | 14:32 |
| sdake_ | sorry to be dene here, but i want to get to the root of the discussion with a data container | 14:32 |
| pdb | sdake_: I think some admins want it to be as easy as possible to tweak configs | 14:33 |
| *** vinkman has quit IRC | 14:34 | |
| *** vinkman has joined #kolla | 14:34 | |
| pdb | I understand you want to help prevent people shooting their own foot off but no point going out of the way to limit them either | 14:35 |
| pdb | rebuilding/redeploying containers for every config change is really cumbersome | 14:36 |
| inc0 | especially if we consider things like neutron restarts | 14:36 |
| inc0 | we'll be working on ways to reread configs without restarts, and forcing people to redeploy would be even worse | 14:37 |
| SamYaple | sdake_: yea if yo udelete the volume and recreate it everything has to be restarted | 14:37 |
| SamYaple | which is the same exact issue | 14:37 |
| SamYaple | containers are immutable | 14:37 |
| SamYaple | and for the record, I am not against it, i just went with the flow here. This was only brought back up because people didnt like the admittedly complicated encoded ENV vars | 14:38 |
| SamYaple | the options I see are the ENV vars, or host bind mounts | 14:39 |
| pdb | or both ;) | 14:39 |
| SamYaple | yea I dont think so | 14:39 |
| SamYaple | i mean thats a really different decision | 14:39 |
| SamYaple | it affects the way the containers build too | 14:39 |
| vinkman | Yeah, I would agree mixing the two would be the worst of both worlds… | 14:41 |
| SamYaple | vinkman: technically anyone can do random things with the config anyway. they stil lexist on the host | 14:42 |
| pdb | well at the end of the day the service just needs to be pointed at a config. how that config gets there can be variable | 14:42 |
| SamYaple | pdb: but it changes the deployment method for hte containers | 14:43 |
| pdb | true, and probably a lot of other things | 14:43 |
| SamYaple | no, not much else. But it would double the LOC for the container starting part | 14:44 |
| inc0 | sdake_, quick question about ansible | 14:46 |
| inc0 | why we'd even want to keep crudini when we'll have ansible? | 14:46 |
| SamYaple | sdake_ loves ansible questions! | 14:46 |
| SamYaple | downstream consumes crudini inc0 | 14:46 |
| pdb | I feel there's a lot of admins who will want more control over their configs. The bind mount option also opens up the possibility of using their own orchestration e.g. chef/puppet etc. | 14:47 |
| SamYaple | pdb: sdake_: datavolume for configs wit hthe option of bind mounting? | 14:47 |
| inc0 | or rather, why not prepare config files outside container and push this to container on deploy? | 14:47 |
| inc0 | SamYaple, pdb I mean, instead of making cruds inside container, predefine config file outside and just copy it in | 14:47 |
| inc0 | then puppets and so on will have even easyier time | 14:47 |
| inc0 | and our ansible stuff will just create this file | 14:48 |
| SamYaple | inc0: "predefine" can you expand? | 14:49 |
| inc0 | so. we'll create /tmp/keystone.conf | 14:49 |
| inc0 | for example | 14:49 |
| inc0 | with env vars or ansible or puppet or vim or even emacks | 14:49 |
| inc0 | emacs* | 14:49 |
| inc0 | and all kolla will do is copy this little file to place we want it to be | 14:50 |
| SamYaple | inc0: how does it copy said file | 14:50 |
| inc0 | COPY /said/file /etc/said/file? | 14:50 |
| inc0 | in Dockerfile? | 14:50 |
| SamYaple | thats only at build | 14:50 |
| SamYaple | how will people add what options they want | 14:50 |
| SamYaple | how will you change the config | 14:51 |
| inc0 | hmm...data volume for configs? ;) | 14:51 |
| inc0 | there should be a way to push file into running container? | 14:52 |
| SamYaple | recreating the data volume with each change is cumbersome as technically all files for all containre running on that host would be touched | 14:52 |
| SamYaple | inc0: you can, but thats the worst way to do it | 14:52 |
| inc0 | maybe just VOLUME /tmp/kolla and in start.sh cp /tmp/kolla/keystone.conf /etc/keystone/ | 14:52 |
| inc0 | ? | 14:52 |
| SamYaple | you cant cp from outside the container to inside the container | 14:53 |
| inc0 | or even VOLUME /etc/keystone ? | 14:53 |
| SamYaple | none of this solvess the issue | 14:53 |
| inc0 | mounting etc wouldn't? | 14:54 |
| SamYaple | mounting from where | 14:54 |
| inc0 | host | 14:54 |
| inc0 | host will hold sum of /etc/ of containers | 14:54 |
| SamYaple | thats what we are talking about. "bindmounting" thats what sdake said "those with access" are against | 14:54 |
| SamYaple | that would be my prefered method honestly | 14:55 |
| inc0 | mine too, admins are used to have configs in /etc | 14:56 |
| inc0 | we'll use containers just as app runtime environment, not separation tool | 14:56 |
| inc0 | multitenancy like separation I mean, we keep deps separation, and that's cool | 14:56 |
| *** dasm is now known as dasm|afk | 15:02 | |
| inc0 | allright, out to home, laters | 15:03 |
| *** inc0 has quit IRC | 15:04 | |
| openstackgerrit | Merged stackforge/kolla: Check compose cmd result https://review.openstack.org/177122 | 15:04 |
| sdake_ | samyaple agree on the cumbersome part | 15:05 |
| sdake_ | samyaple i'm thinking the proper word is "slow" :) | 15:05 |
| sdake_ | it creates a new workflow for creating containers which i don't particuarly like | 15:06 |
| sdake_ | inc0 sdake.io | 15:15 |
| sdake_ | read it ;) | 15:15 |
| sdake_ | new toy http://www.stevehuffphoto.com/line-magnetic-219ia-integrated-tube-amp-review-300b-and-845-tube-magic/ on its way to phoenix as we speak | 15:17 |
| sdake_ | should have by friday ;) | 15:17 |
| sdake_ | i a/b blind compared to a 45k tube amp, couldn't tell the difference | 15:20 |
| sdake_ | with a 100k usd preamp+phono stage | 15:20 |
| *** mattt has joined #kolla | 15:20 | |
| pdb | I think the above sounds good on paper, until you tell an admin he has to wait > a few minutes just to turn on verbose in a service :/ | 15:20 |
| sdake_ | pdb you mean the data volumes for /etc? | 15:20 |
| pdb | yes | 15:21 |
| sdake_ | that is the slow part i was referring to | 15:21 |
| sdake_ | the cumbersome part -we can abstract that away | 15:21 |
| pdb | as in hide it? | 15:22 |
| sdake_ | right | 15:23 |
| sdake_ | but performance can't be abstracted | 15:23 |
| sdake_ | performance is what it is ;) | 15:23 |
| pdb | just what I was about to say | 15:23 |
| sdake_ | actually that isn't technically accurate | 15:24 |
| sdake_ | some of it could be abstractedby building a million data containers with all possible options :) | 15:24 |
| sdake_ | but this comes with a new set of problems which are worse on balance imo :) | 15:25 |
| sdake_ | where million is some large number not actually 1 milion :) | 15:25 |
| pdb | :P | 15:25 |
| pdb | I feel it comes back to trying to not let the user screw up their system | 15:26 |
| pdb | Personally I think that's envitable, not sure I'd sacrifice usability just to slow down a cowboy admin ;) | 15:27 |
| pdb | isn't that why python dont have private variables? | 15:27 |
| pdb | *doesn't | 15:28 |
| bmace | it can and will happen, no matter how much you try to protect them. once you make something stupid proof, stupid just gets stronger :) | 15:28 |
| *** absubram has joined #kolla | 15:28 | |
| bmace | having stuff mounted from /etc in the sort of "regular" place does, on the upside, give admins a very similar feel to a traditional openstack deploy so if they have existing tools / procedures more of it seems likely to work for that scenario. | 15:31 |
| bmace | i appreciate the increased lines of code needed to handle both ways. i think sam suggested double, but if that is from 10 lines to 20 lines that isn't too much of a price to pay imo. 1000 to 2000 would be a bit rougher, but i would be a little surprised if it was that much. | 15:32 |
| SamYaple | so a data container with the option of bindmounting is no good? I think that solves the issue nicely | 15:35 |
| SamYaple | i should clarify | 15:37 |
| pdb | SamYaple: no I think that might work | 15:37 |
| sdake_ | exceptions are a way to the dark side | 15:37 |
| SamYaple | bindmounting for the datacontainer only | 15:37 |
| sdake_ | convince me this isn't an exception | 15:37 |
| SamYaple | convince me this is an exception? | 15:38 |
| pdb | sdake_: I could say the same about crudini | 15:38 |
| pdb | ? | 15:38 |
| sdake_ | you mean crudini and serialization is an exception | 15:38 |
| sdake_ | let me address that point, I struggled with this as well | 15:38 |
| sdake_ | it is in Kolla's best interest to have our containers used by as many downstreams as possible | 15:39 |
| sdake_ | this model enables that behavior | 15:39 |
| sdake_ | hence it facilitates our mission | 15:39 |
| sdake_ | it makes us stronger | 15:39 |
| sdake_ | https://www.google.com/search?es_sm=119&q=define+exception&oq=define+exception&gs_l=serp.3..35i39j0i67j0i20j0l7.3491.3661.0.4207.2.2.0.0.0.0.363.363.3-1.1.0....0...1c.1.64.serp..1.1.362.DQFc8WFGyVA | 15:40 |
| sdake_ | it does not result in exclusion it resultts in inclusion | 15:40 |
| bmace | the concern is that for some reason doing the bindmount of the config file is somehow less variable / non-immutable than passing in a bunch of env data that has the same effect on the process in the container? | 15:41 |
| sdake_ | the problem bmace is the data can *change* on the host | 15:41 |
| bmace | it is just two different ways to get exactly the same data into the container, and i think to your point, having the additional way is more inclusive. | 15:41 |
| sdake_ | this is where Kevin Fox's idea comes in | 15:41 |
| sdake_ | which I think I support and is not an exception :) | 15:42 |
| *** sdake_ has quit IRC | 15:42 | |
| *** fabiand has joined #kolla | 15:43 | |
| pdb | the theme in openstack lately seems to be if there's enough people wiling to support something it's a viable option | 15:45 |
| bmace | so most of your concern is, specifically, around config changes underneath a running container? do we have some containers that actually read that stuff post execution? i appreciate to some degree we are concerned about container lifecycle, but it is sort of an obnoxious limitation to say all config changes must be made through a kolla master, which then does all the env push stuff, etc. it greatly limits the freedom / control of the | 15:45 |
| bmace | ostk admins. | 15:45 |
| pdb | there seems to be quite a few who would like to see the bind mounts as an option | 15:45 |
| *** sdake has joined #kolla | 15:47 | |
| *** sdake_ has joined #kolla | 15:48 | |
| sdake_ | bmace power dropped off | 15:49 |
| sdake_ | needed to find a plug | 15:49 |
| sdake_ | where I lost power : [08:41:47] <sdake_>this is where Kevin Fox's idea comes in | 15:49 |
| sdake_ | [08:42:04] <sdake_>which I think I support and is not an exception :) | 15:49 |
| sdake_ | samyaple seemed to indicate it was dancing on the razor blade of what is immutable | 15:49 |
| openstackgerrit | Merged stackforge/kolla: Make kolla script bashate compliant https://review.openstack.org/186433 | 15:50 |
| openstackgerrit | Merged stackforge/kolla: Make setup_docker.sh bashate compliant https://review.openstack.org/186434 | 15:50 |
| openstackgerrit | Merged stackforge/kolla: Make update-build-links bashate compliant https://review.openstack.org/186435 | 15:50 |
| bmace | sure, one can change at start time, one can start at any time.. i'll toss you what little you missed in a PM since everyone else saw it already :) | 15:50 |
| openstackgerrit | Merged stackforge/kolla: Make magnum demo start bashate compliant https://review.openstack.org/186437 | 15:50 |
| pdb | I was basically saying I think if enough people want it and are willing to support something, that thing can be made an option. difference between an option and exception...? um... | 15:50 |
| openstackgerrit | Merged stackforge/kolla: Remove 1000 bashate failures by ignoring .git directory https://review.openstack.org/186438 | 15:50 |
| sdake_ | would appreciate it so i don't have to hunt down the logs | 15:50 |
| *** sdake has quit IRC | 15:52 | |
| sdake_ | [08:51:00] <bmace>so most of your concern is, specifically, around config changes underneath a running container? do we have some containers that actually read that stuff post execution? i appreciate to some degree we are concerned about container lifecycle, but it is sort of an obnoxious limitation to say all config changes must be made through a kolla master, which then does all the env push stuff, etc. it greatly limit | 15:53 |
| sdake_ | yes containers read the data post execution | 15:53 |
| sdake_ | on restart | 15:53 |
| sdake_ | kevin fox's proposal is to fix that so that doesn't happen | 15:53 |
| *** jasonsb has joined #kolla | 15:54 | |
| sdake_ | by copying a bindmounted /etc dir on start into the system, then removing the bindmount | 15:54 |
| pdb | I would read kevin's comment as wanting bind mounts :) | 15:54 |
| SamYaple | sdake_: you cant remove bind mounts like that | 15:54 |
| sdake_ | its not the bindmount I have allergy to, its the changing of the container during runtime | 15:54 |
| bmace | if someone has some setting they want to change on a compute node, and they know that there are no vms on it.. or even that it is safe to do it in the state that they are in at that point.. then i say they should be within their rights to change the config the way they always have, and restart the container. | 15:54 |
| sdake_ | sorry removing the bindmounting file - let me clarify samyaple | 15:54 |
| SamYaple | and /win 1 | 15:55 |
| sdake_ | then we end with two sources of truth bmace | 15:55 |
| bmace | if it is only @restart that the changes are picked up though, it isn't at runtime. | 15:55 |
| bmace | well, it isn't "during" runtime :) | 15:55 |
| *** sdake_ is now known as sdake | 15:56 | |
| bmace | sure.. the truth thing, yeah, we had gotten around that by markup in the config file, like a gui builder would do | 15:56 |
| bmace | we had fields that were marked up so the user knew that it would be overwritten if pushed out by the management process | 15:56 |
| *** daneyon has joined #kolla | 15:56 | |
| sdake | morning daneyon | 15:56 |
| sdake | hey i failed to register for cl in time | 15:56 |
| sdake | got a bone for me to solve that problem | 15:57 |
| sdake | charles forwarded me on to someone else who didn't respond :( | 15:57 |
| sdake | one a container starts, it should enter a immutable state imo | 15:57 |
| sdake | otherwise it looses its declartive property | 15:58 |
| *** jtriley has quit IRC | 15:58 | |
| sdake | I am open to Kevin's idea if the wider kolla community accepts it | 15:59 |
| daneyon | morning sdake | 15:59 |
| daneyon | not sure what i can do to help. let me look into it and see if anything can be done. | 15:59 |
| sdake | the idea being bindmount a file in /etc, cp it in the container, delete it on the host from the container | 16:00 |
| *** jtriley has joined #kolla | 16:00 | |
| sdake | samyaple what are your thoughts on this approach? | 16:00 |
| bmace | as long as it doesn't actually re-read that file after start time imo the behavior doesn't really seem much different than pushing in env vars.. if it picked up changes on the fly, not just container restart i could see that would be odd / dangerous. | 16:01 |
| sdake | right when people talk about bindmounting etc, its the re-read that concerns me | 16:01 |
| sdake | i don't actually care much about the bindmount ;) | 16:01 |
| *** jasonsb has quit IRC | 16:02 | |
| sdake | i think from an implementation perspective it could be racy - too bad there isn't an atomic cp&rm :) | 16:03 |
| sdake | I'm not clear if mv would work in a bindmount situation | 16:03 |
| *** jasonsb has joined #kolla | 16:03 | |
| sdake | daneyon perhaps you can ping rohit and see what my options are? | 16:03 |
| sdake | charles mentioned onsite registration | 16:03 |
| sdake | just need to make sure i can get a explorer pass onsite | 16:04 |
| sdake | pretty sure patrick would freak at a 2k cl expense pass :) | 16:04 |
| daneyon | i think you will be fine with getting your pass onsite. We'll make it happen one way or another. Def no need to get a 2k pass | 16:05 |
| sdake | thanks that takes a bit of worry away :) | 16:05 |
| sdake | i arrive tuesday 9am leave wednesday 7pm | 16:05 |
| daneyon | i'm heading down this afternoon to avoid traffic between 4-7 | 16:06 |
| daneyon | I need to finalize creating a demo for the Netplugin project to help Vipin and team. | 16:07 |
| *** jasonsb has quit IRC | 16:08 | |
| daneyon | sdake, so does this online registration site not work for you: https://www.ciscolive2015.com/portal/startNewRegistration.do | 16:09 |
| sdake | it says registration is closed | 16:09 |
| daneyon | sdake what if you call the support number on that site? | 16:09 |
| SamYaple | sdake: i dont like deleting the host. I dont like making the "re-read" a requirement for the project. I think the default should be immutable, but the option to be able to update the config and have the container pick up those changes should be up to the informed user | 16:09 |
| sdake | oh snap | 16:09 |
| sdake | it looks like its open again :) | 16:10 |
| sdake | let me try again | 16:10 |
| daneyon | OK | 16:10 |
| SamYaple | hey daneyon | 16:10 |
| daneyon | hey SamYaple | 16:10 |
| sdake | samyaple while I dislike taking choices away from the operator, I dislike two sources of truth more | 16:11 |
| sdake | lesser of two evils and all that ;) | 16:11 |
| *** daneyon_ has joined #kolla | 16:12 | |
| SamYaple | the point pdb brought up is a very valid one. new users and admins want to be able to add an option to a config and test it out on one host | 16:12 |
| SamYaple | reguiring ansible for that is like using tnt to open a door | 16:12 |
| *** daneyon has quit IRC | 16:14 | |
| sdake | daneyon do you know if there is a social event tuesday night? | 16:19 |
| sdake | daneyon nevermind found it | 16:21 |
| sdake | i'll make my own social event :) | 16:21 |
| sdake | agree with pdb's point, to that i'd recommend a different approach which is a production vs testing deployment | 16:26 |
| SamYaple | still the same issue, testing or no | 16:27 |
| sdake | would we want production deployments mucking with one node's config? | 16:27 |
| SamYaple | as an admin, thats sorta my job. i do it on a daily basis | 16:28 |
| SamYaple | so yes, thats the answer if it wasn't clear | 16:29 |
| *** rhallisey|pto has quit IRC | 16:31 | |
| openstackgerrit | Jeff Peeler proposed stackforge/kolla: Make config-glance.sh bashate compliant https://review.openstack.org/186463 | 16:34 |
| sdake | jpeeler did I miss one? | 16:34 |
| jpeeler | not sure, it said it needed rebasing so i just clicked the button | 16:34 |
| sdake | oh a rebase | 16:34 |
| sdake | got it | 16:34 |
| sdake | wonder how that happened | 16:35 |
| sdake | i rebased before i submitted sunday the patch stream with the comments fixed | 16:35 |
| jpeeler | once that one goes, i think the rest will follow | 16:35 |
| sdake | since its a rebase and already has two +2's, its good for a workflow +1 | 16:36 |
| jpeeler | yeah, about to do that now | 16:36 |
| sdake | samyaple what if the deployment didn't need mucking with :) | 16:37 |
| sdake | I don't want people to have to be experts on how kolla operates to do their jobs | 16:37 |
| sdake | or containers in general | 16:37 |
| sdake | or even openstack config options | 16:37 |
| sdake | is the use case you want to test out a new feature on one node but not all nodes? | 16:38 |
| SamYaple | perfect worlds are perfect. but you are requiring people to be expects to change a config on one node for testing | 16:38 |
| SamYaple | ive got to disagree on this one. my point in bringing it up was that I am not the only one who wants it and this discussion would be had again | 16:38 |
| sdake | i haven't drawn any lines in the sand :) | 16:39 |
| sdake | i am listening | 16:39 |
| sdake | what I want to understand is the use case | 16:39 |
| sdake | why would an admin want to change the config on one node and not all nodes | 16:39 |
| sdake | you do it on a daily basis, why? | 16:40 |
| SamYaple | use case: I want to change a config option without having to rerun ansible for testing | 16:40 |
| sdake | so you want to test one specific config option in a production cluster? | 16:41 |
| SamYaple | daily basis is anything from turning on debug+verbose for a single service, to adding in some wonky nova option to see if it fixes an issue | 16:41 |
| SamYaple | normally i do this 1: test in lab (if possible) 2: test on one node in environment to verify it works 3: deploy env wide | 16:41 |
| sdake | canary deployment | 16:41 |
| SamYaple | if there is a name for it? | 16:42 |
| sdake | canary = automated | 16:42 |
| sdake | canary deployment = make config changes in one place, if all is good, make in more places, if all is good, make in all the places | 16:42 |
| SamYaple | how does it relate | 16:42 |
| SamYaple | ok | 16:43 |
| *** rhallisey|pto has joined #kolla | 16:43 | |
| sdake | i absolutely want to get there | 16:43 |
| SamYaple | for the record, these is no process that will work _better_ and be more accepted than tweaking a config on the host and running `docker restart <container>` | 16:43 |
| sdake | i think it should be automated - sounds like you think it should be manual | 16:43 |
| SamYaple | you method exludes mine, mine works in conjunction with yours | 16:44 |
| sdake | the canary method doesn't rule out manual config changes | 16:44 |
| sdake | if b works in conjunction with a, a works in conjunction with b :) | 16:45 |
| SamYaple | alright. more succinctly. You say you don't want to use a method so it should be excluded. I say it should be included if it doesn't break your method/add overhead | 16:46 |
| SamYaple | which it doesnt | 16:46 |
| sdake | i just want one source of truth | 16:47 |
| *** jtriley has quit IRC | 16:47 | |
| sdake | if the admin changes something there are two sources of truth | 16:47 |
| sdake | (rather changes something in two places) | 16:47 |
| SamYaple | the one source of truth is the config file. | 16:47 |
| sdake | admin A comes along and changes X, admin b coms along and rechanges X a different way in a different place | 16:47 |
| sdake | i thought the one source of truth is the ansible augmentation and overrides file :) | 16:48 |
| SamYaple | i get it. i disagree. but i get it | 16:48 |
| SamYaple | i think bindmounting and changing the config from the host should be an option, not the default, but an option | 16:48 |
| SamYaple | I can almost gauruntee it would be used by everyone too | 16:48 |
| SamYaple | at least any admin that gets a hold of it | 16:49 |
| sdake | ok i am good with options | 16:49 |
| pdb | +1 on options | 16:49 |
| sdake | as long as it isn't the default and there is a big ass warning say "please don't do this, we warned you so" :) | 16:49 |
| pdb | call it "test mode" or something | 16:49 |
| SamYaple | that I am ok with (and suggested earlier) | 16:49 |
| sdake | samyaple apologies i lost poer so lost some of the context of the convo | 16:50 |
| SamYaple | i would prefer a documentation section on the section dedicated to the pitfalls of the bindmount method | 16:50 |
| pdb | there's still a conversation to be had around the config merging mechanism. which im not convinced is necessary | 16:51 |
| pdb | but might have to leave that for tomorrow | 16:51 |
| sdake | pdb not necessary for which reason | 16:51 |
| SamYaple | pdb: that i need ot hear about though | 16:51 |
| sdake | pdb ok enjoy your rest itme :) | 16:51 |
| sdake | pdb please put comments in the review | 16:51 |
| sdake | so poeple don't have to track down our arguments 6 mo from now on the irc logs :) | 16:51 |
| pdb | makes sense | 16:51 |
| SamYaple | bindmounting would require a config container though | 16:52 |
| sdake | the config merging is to support one of our core use cases though, which is custom configuration | 16:52 |
| sdake | and that is necessary ;) | 16:52 |
| sdake | that is one thing that makes kolla significantly different from every other deployment tool in existence | 16:52 |
| harmw | hi guys | 16:53 |
| sdake | hey harmw welcome to the party! | 16:53 |
| SamYaple | for the record sdake, when done correctly the bindmounting or "test mode" can be turned on and off through ansible at the cost of restarting all containers | 16:54 |
| *** vinkman has quit IRC | 16:54 | |
| sdake | cool like i said, i'm good with options | 16:54 |
| SamYaple | *recreating all the containers | 16:54 |
| sdake | as long as the options that lead to disaster for a deployment are well documented :) | 16:54 |
| *** jtriley has joined #kolla | 16:55 | |
| *** vinkman has joined #kolla | 16:55 | |
| *** dwalsh has quit IRC | 16:56 | |
| harmw | jpeeler: missing openssl... bummer | 16:58 |
| sdake | samyaple the tesst mode bind mounting on off, ike that idea, that way operators can force their admins into their policies based upon our fantastic documentaed warnings :) | 17:00 |
| SamYaple | i only call it test mode for your sake. i think its a valid run mode, when aware of the risks | 17:01 |
| sdake | ok well we should rename it something we can all agree on | 17:02 |
| sdake | rather then test mode - i dont like that name either | 17:02 |
| SamYaple | "hard mode" | 17:02 |
| SamYaple | "old school mode" | 17:02 |
| SamYaple | "cowboy mode" | 17:02 |
| sdake | brings back old memories of world of warcraft ;) | 17:02 |
| SamYaple | probably "legacy mode" | 17:02 |
| sdake | i like cowboy mode ;) | 17:02 |
| sdake | shows we have a sense of humor ;) | 17:03 |
| SamYaple | i like legacy. cowboy still implies unsuitable for production | 17:03 |
| bmace | unprotected? :) | 17:04 |
| SamYaple | legacy says it is an older, less recommended way of doing things. | 17:04 |
| vinkman | So, exposing my total inexperience with Ansible, can Ansible not target a specific server for config changes, is it an all or nothing? | 17:05 |
| SamYaple | thats better than "advanced" or similiar which implies more skill/knowledge is needed | 17:05 |
| *** daneyon has joined #kolla | 17:05 | |
| SamYaple | vinkman: yes and no. it _can_ but if it is a single node it cant use info from other nodes | 17:05 |
| SamYaple | so in the case of haproxy you cant make a change to one haproxy node without touching ALL the nodes | 17:06 |
| SamYaple | because haproxy uses info about each node (ip addresses and what not) | 17:06 |
| SamYaple | I would strongly not recommend it for single changes to configs | 17:06 |
| *** daneyon_ has quit IRC | 17:07 | |
| vinkman | But it is possible to do that for the testing case? | 17:07 |
| sdake | samyaple that is a real bummer I had hoped that would be possible to implement canary deployment | 17:07 |
| *** dims has joined #kolla | 17:07 | |
| SamYaple | it can probably be worked in, but in a very non-ansible type of way and 1bajjillion skpped messages | 17:08 |
| vinkman | I think in general config changes that are node specific would be compute only not really on the controller side of the house... | 17:08 |
| SamYaple | vinkman: think admin use. testing change to an api server that is out of the LB pool | 17:09 |
| SamYaple | permenant changes would be applied through ansible anyway | 17:09 |
| *** dims_ has quit IRC | 17:10 | |
| *** bradjones has quit IRC | 17:10 | |
| *** bradjones has joined #kolla | 17:11 | |
| *** bradjones has joined #kolla | 17:11 | |
| sdake | vinkman if someone wants changes on compute they will want em on controller in the same wy they are accustomed to | 17:12 |
| SamYaple | sdake: i never put [libvirt] changes on the controller or [database] on the compute. what do you mean? | 17:13 |
| *** jmccarthy has joined #kolla | 17:13 | |
| sdake | while we have an active chat going, can folks have a vote on our manifesto - line 5 | 17:17 |
| sdake | https://etherpad.openstack.org/p/kolla-manifesto | 17:17 |
| *** rhallisey|pto has quit IRC | 17:19 | |
| openstackgerrit | Merged stackforge/kolla: Make config-glance.sh bashate compliant https://review.openstack.org/186463 | 17:22 |
| harmw | sdake: done | 17:25 |
| harmw | only L5? or rest as well? | 17:25 |
| harmw | (though I'm seeing quite a lot +1 on the other topics already) | 17:26 |
| sdake | harmw which other topics | 17:26 |
| sdake | you mean down the screen | 17:26 |
| harmw | yup | 17:26 |
| sdake | that was our collaborative "make it yourself" model | 17:26 |
| harmw | hehe | 17:26 |
| sdake | those were merged into one | 17:26 |
| *** pradk has joined #kolla | 17:30 | |
| *** rhallisey|pto has joined #kolla | 17:30 | |
| sdake | rhallisey|pto if your not really on pto plz vote on https://etherpad.openstack.org/p/kolla-manifesto | 17:32 |
| *** jasonsb has joined #kolla | 17:33 | |
| *** daneyon_ has joined #kolla | 17:45 | |
| *** daneyon has quit IRC | 17:48 | |
| *** mstachow has joined #kolla | 17:50 | |
| mstachow | hi :) | 17:50 |
| *** weiyu-001 has quit IRC | 17:52 | |
| *** weiyu-001 has joined #kolla | 17:52 | |
| sdake | daneyon can you send me your cisco lie kolla slides - curious to see what you came up with | 17:54 |
| sdake | mstachow morning fine sir check out https://etherpad.openstack.org/p/kolla-manifesto and vote plz - leae comments if you like - line #5 | 17:55 |
| mstachow | huh no problem :) | 17:56 |
| sdake | dont edit statement directly plz | 17:57 |
| sdake | anyone else that plans to contribute to kolla over the liberty cycle is welcome to vote as well - enjoy ;) | 17:58 |
| sdake | diga u awake at this hour | 17:59 |
| sdake | prad your welcome to vote as well ;) | 17:59 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make config-neutron.sh bashate compliant https://review.openstack.org/186490 | 18:01 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make get-image.sh bashate compliant https://review.openstack.org/189156 | 18:01 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make config-l3-agent.sh bashate compliant https://review.openstack.org/186491 | 18:01 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make config-linuxbridge-agent.sh bashate compliant https://review.openstack.org/186492 | 18:02 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make config-sudoers.sh bashate compliant https://review.openstack.org/186493 | 18:02 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make config-dhcp-agent.sh bashate compliant https://review.openstack.org/186494 | 18:02 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make neutron-server start.sh bashate compliant https://review.openstack.org/186495 | 18:02 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make swift bashate compliant https://review.openstack.org/189166 | 18:02 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make config-nova-compute bashate compliant https://review.openstack.org/186482 | 18:02 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make mariadb config-mysql.sh bashate compliant https://review.openstack.org/186475 | 18:02 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make mysql-entrypoint.sh bashate compliant https://review.openstack.org/186477 | 18:02 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make nova-controller start.sh bashate compliant https://review.openstack.org/186499 | 18:02 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make keystone start.sh bashate compliant https://review.openstack.org/186476 | 18:02 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make config-nova.sh pass bashate gate https://review.openstack.org/186465 | 18:02 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Ignore .tox directory to remove some bashate failures https://review.openstack.org/186464 | 18:02 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make rabbitmq start.sh bashate compliant https://review.openstack.org/186467 | 18:02 |
| openstackgerrit | Steven Dake proposed stackforge/kolla: Make nova-libvirt's start.sh bashate compliant https://review.openstack.org/186466 | 18:02 |
| *** sdake has quit IRC | 18:02 | |
| *** sdake has joined #kolla | 18:02 | |
| sdake | groan | 18:03 |
| sdake | jenkins got busted | 18:03 |
| pradk | sdake, cool, will take a look and vote.. thx for the heads up | 18:04 |
| jpeeler | harmw: yeah, silly problem, but worth fixing | 18:07 |
| harmw | totally :) | 18:07 |
| harmw | just didn't expect openssl would be unavailable on some systems :) | 18:08 |
| jpeeler | i'm using the fedora cloud image | 18:08 |
| harmw | hmk, oh well | 18:08 |
| *** openstackgerrit has quit IRC | 18:09 | |
| harmw | Ill work out a little patch later tonight :) | 18:09 |
| *** openstackgerrit has joined #kolla | 18:09 | |
| harmw | *hopefully | 18:09 |
| jpeeler | no rush | 18:09 |
| *** dwalsh has joined #kolla | 18:12 | |
| *** rhallisey|pto has quit IRC | 18:15 | |
| *** jruano has joined #kolla | 18:15 | |
| *** rhallisey has joined #kolla | 18:16 | |
| *** shardy_ has joined #kolla | 18:21 | |
| *** shardy has quit IRC | 18:22 | |
| sdake | got job spam for https://www.linkedin.com/jobs2/view/54419099?trk=eml-jymbii-organic-job-title&refId=df805575-8209-40c9-b947-0b508136b74b&midToken=AQEm0QXe70O0UA | 18:23 |
| sdake | I must be radioactive ;) | 18:23 |
| openstackgerrit | Michal Rostecki proposed stackforge/kolla: [WIP] Add designate-sink service https://review.openstack.org/189393 | 18:24 |
| *** shardy_ has quit IRC | 18:26 | |
| *** daneyon_ has quit IRC | 18:26 | |
| *** shardy has joined #kolla | 18:27 | |
| sdake | hey shardy | 18:27 |
| harmw | oh my, someone trying to add Sink :) | 18:28 |
| harmw | nice | 18:28 |
| *** mstachow has quit IRC | 18:28 | |
| *** mstachow has joined #kolla | 18:29 | |
| *** rhallisey is now known as rhallisey|pto | 18:32 | |
| nihilifer | yes, I really need containerized sink :) | 18:33 |
| harmw | I'm already reviewing :) | 18:35 |
| *** jtriley has quit IRC | 18:45 | |
| sdake | best part of empire strikes back | 18:45 |
| sdake | "Try? Try Not. Do or do not. There is no try." | 18:45 |
| harmw | hehehe | 18:46 |
| *** jtriley has joined #kolla | 18:49 | |
| *** loth has joined #kolla | 18:54 | |
| openstackgerrit | Merged stackforge/kolla: Ignore .tox directory to remove some bashate failures https://review.openstack.org/186464 | 19:08 |
| *** prad__ has joined #kolla | 19:14 | |
| *** fabiand has quit IRC | 19:18 | |
| openstackgerrit | Merged stackforge/kolla: Make config-nova.sh pass bashate gate https://review.openstack.org/186465 | 19:18 |
| *** prad__ has quit IRC | 19:23 | |
| *** pradk has quit IRC | 19:28 | |
| harmw | nihilifer: you got Sink working though? | 19:31 |
| openstackgerrit | Merged stackforge/kolla: Make nova-libvirt's start.sh bashate compliant https://review.openstack.org/186466 | 19:42 |
| openstackgerrit | Merged stackforge/kolla: Make rabbitmq start.sh bashate compliant https://review.openstack.org/186467 | 19:42 |
| openstackgerrit | Merged stackforge/kolla: Make mariadb config-mysql.sh bashate compliant https://review.openstack.org/186475 | 19:43 |
| openstackgerrit | Merged stackforge/kolla: Make keystone start.sh bashate compliant https://review.openstack.org/186476 | 19:43 |
| openstackgerrit | Merged stackforge/kolla: Make mysql-entrypoint.sh bashate compliant https://review.openstack.org/186477 | 19:43 |
| openstackgerrit | Merged stackforge/kolla: Make config-nova-compute bashate compliant https://review.openstack.org/186482 | 19:43 |
| openstackgerrit | Merged stackforge/kolla: Make config-neutron.sh bashate compliant https://review.openstack.org/186490 | 19:45 |
| openstackgerrit | Merged stackforge/kolla: Make config-l3-agent.sh bashate compliant https://review.openstack.org/186491 | 19:45 |
| sdake | batehate coming to a conclusion yay :) | 19:45 |
| openstackgerrit | Merged stackforge/kolla: Make config-linuxbridge-agent.sh bashate compliant https://review.openstack.org/186492 | 19:46 |
| openstackgerrit | Merged stackforge/kolla: Make config-sudoers.sh bashate compliant https://review.openstack.org/186493 | 19:46 |
| openstackgerrit | Merged stackforge/kolla: Make config-dhcp-agent.sh bashate compliant https://review.openstack.org/186494 | 19:46 |
| openstackgerrit | Merged stackforge/kolla: Make neutron-server start.sh bashate compliant https://review.openstack.org/186495 | 19:46 |
| openstackgerrit | Merged stackforge/kolla: Make nova-controller start.sh bashate compliant https://review.openstack.org/186499 | 19:47 |
| jpeeler | looks like cinder needs fixing | 19:48 |
| sdake | waiting on the cinder merge | 19:49 |
| sdake | and then I think its job done :) | 19:49 |
| jpeeler | once we get everything in, need to make it voting | 19:50 |
| sdake | agree | 19:50 |
| sdake | probably about time to make the functional gate voting as well | 19:51 |
| sdake | seems to work well enough | 19:51 |
| jpeeler | wonder if it's a no no to enable both at the same time | 19:52 |
| *** bmace has quit IRC | 19:56 | |
| harmw | sdake: https://review.openstack.org/#/c/187981/3 your thoughts please | 20:02 |
| harmw | I don't want this to end up in some childish (no offence to anyone here) yes vs no btween just 2 persons :) | 20:03 |
| *** bmace has joined #kolla | 20:07 | |
| openstackgerrit | Michal Stachowski proposed stackforge/kolla: WIP: Galera container https://review.openstack.org/187225 | 20:08 |
| sdake | harmw groan reviewer fatigue | 20:08 |
| sdake | give me 15 minutes to get the monster into my bloodstream | 20:08 |
| harmw | :P | 20:08 |
| mstachow | good night :)! | 20:14 |
| harmw | mstachow: thank for throwing in new stuff to review :) | 20:16 |
| *** mstachow has quit IRC | 20:19 | |
| sdake | harms lgtm for the most part | 20:26 |
| harmw | ok, specifically the single node stuff about hostnames and static id's | 20:27 |
| harmw | am I simply wrong on those? | 20:27 |
| sdake | just difference of opinion | 20:28 |
| sdake | other reviewers may have other opinions | 20:28 |
| harmw | yup | 20:28 |
| sdake | my general rule of thumb is if it solves our problem i'm good with it | 20:28 |
| sdake | when it doesn't we can rework | 20:29 |
| harmw | true, while I'd like to get most stuff worked out up front | 20:29 |
| harmw | whenever possible that is | 20:29 |
| sdake | i'm more focused on output then perfection :) | 20:30 |
| harmw | :P | 20:30 |
| sdake | the hostname static id thing | 20:30 |
| sdake | not sure on that | 20:30 |
| sdake | not a keepalived expert | 20:30 |
| sdake | that is why we require two core reviewers to review a patch | 20:31 |
| sdake | i don't even know what that stuff means ;) | 20:31 |
| sdake | but you asked me to review so I did to the best of my ability | 20:31 |
| sdake | 140 pep errors left to fix ;) | 20:31 |
| sdake | rather bashate errors | 20:31 |
| sdake | yay for progress | 20:31 |
| harmw | my point (in general here) is he's building this to be run on specifically a single dockerhost, wich I'm opposed to since I'd rather have the ability to run a 2nd keepalived to do $whatever (even if that might not even happen anytime soon) | 20:32 |
| harmw | but as I said, I could be striving for the wrong thing here | 20:32 |
| harmw | just want to hear that from someone :) | 20:33 |
| *** shardy_ has joined #kolla | 20:34 | |
| *** shardy has quit IRC | 20:36 | |
| sdake | well its clear we want keepalive | 20:37 |
| sdake | the question is do we want two keepalive on same node or not | 20:37 |
| harmw | ofcourse | 20:37 |
| sdake | i dont see a use case for that | 20:37 |
| sdake | but maybe a different core reviewer does | 20:37 |
| sdake | i've seen stuff hit our repo with four -1 votes before ;) | 20:37 |
| harmw | depends, do we want 1 keepalived per dockerhost to handle everything, or do we wish for multiple? What about using dockerhost-1 for both a production and a testsetup? that would make it have 2 keepalived containers, using (though perhaps not sharing) atleast the same hostname... | 20:38 |
| harmw | but yes, I'm intrested to see what others think :) | 20:39 |
| sdake | just tyring to keep it simple i think mixing dev and prod is a bad idea :) | 20:39 |
| harmw | ofcourse it is :p | 20:39 |
| sdake | and using bad use cases to justify a rationale is not ideal :) | 20:40 |
| *** shardy_ has quit IRC | 20:40 | |
| harmw | but should things break if $operators decides to go that route? | 20:40 |
| sdake | hopefully operators wont have to do that - itwill be automated | 20:40 |
| *** shardy has joined #kolla | 20:40 | |
| sdake | we know docker-proxy is bad for performance wich means only 1 of our containers can run per node in general | 20:40 |
| sdake | i dont need how you would get two nova-apis on the same node for example | 20:41 |
| harmw | ofcourse | 20:41 |
| harmw | but do we want 1 keepalived for everything, or perhaps a 2nd keepalived for just service X? | 20:42 |
| harmw | (1 as in 1 per dockerhost) | 20:42 |
| *** dwalsh has quit IRC | 20:42 | |
| sdake | i think that decision is best left to daneyon | 20:42 |
| sdake | he is the individual leading our ha spec effort | 20:42 |
| sdake | did you see his ha spec? | 20:43 |
| harmw | I'd rather have it solid per design, rather then because we choose to configure it in a specific way | 20:43 |
| sdake | this is a question to ask the experts in that area | 20:43 |
| harmw | good one, I read it a while ago | 20:43 |
| harmw | perhaps I should revisit | 20:43 |
| sdake | https://review.openstack.org/#/c/181983/ | 20:43 |
| harmw | and I should commnt on some multihost spec as wel | 20:44 |
| sdake | please add your comments there re keepalive on multihost | 20:44 |
| sdake | (in the ha spec) | 20:44 |
| harmw | yep, will do | 20:44 |
| sdake | I assume michal is working based upon that draft spec | 20:44 |
| sdake | harmw you do good reviews - not sure how you pick out all these details ;) | 20:46 |
| sdake | re galera implementation | 20:46 |
| harmw | details? | 20:47 |
| sdake | check_vars for example | 20:47 |
| sdake | my brain implodes every time i do a new container review | 20:47 |
| sdake | designate took a double monster to get through ;) | 20:47 |
| harmw | hehe | 20:47 |
| harmw | though I hate this last review, since I'm reading stuff now that I should (and could) have adressed in my first review :p | 20:48 |
| sdake | that is reviewer fatigue | 20:49 |
| sdake | that happens on bit commits | 20:49 |
| sdake | unfortuantely oru containers are big | 20:49 |
| harmw | cinder was big | 20:49 |
| harmw | galera is relatively easy | 20:49 |
| harmw | anyway, bedtime :p | 20:50 |
| sdake | loth are you about | 20:56 |
| *** pradk has joined #kolla | 20:57 | |
| loth | Whats up | 20:58 |
| sdake | loth could you vote on line #5 of https://etherpad.openstack.org/p/kolla-manifesto | 21:02 |
| sdake | semi-final wording of our manifesto | 21:02 |
| loth | Ok | 21:04 |
| sdake | thanks loth | 21:07 |
| loth | np | 21:08 |
| loth | working on a baremetal ansible deployment to get familar with everything | 21:09 |
| *** sdake_ has joined #kolla | 21:19 | |
| *** vinkman has quit IRC | 21:21 | |
| *** sdake has quit IRC | 21:23 | |
| *** vinkman has joined #kolla | 21:24 | |
| *** vinkman1 has joined #kolla | 21:28 | |
| *** vinkman has quit IRC | 21:28 | |
| *** jtriley has quit IRC | 21:29 | |
| *** jruano has quit IRC | 21:38 | |
| jpeeler | quick sanity check: if i do "docker images" and then do docker-compose for a specific service, the created column should match, right | 21:52 |
| jpeeler | i had to specify the image sha in the compose file. i must be doing something wrong... end of day now though | 22:02 |
| *** pradk has quit IRC | 22:08 | |
| sdake_ | use build --release jpeeler | 22:14 |
| sdake_ | --release wlil tag it with latest | 22:15 |
| sdake_ | vs its sha | 22:15 |
| *** absubram has quit IRC | 22:38 | |
| *** dwalsh has joined #kolla | 22:59 | |
| *** bmace_ has joined #kolla | 23:01 | |
| *** bmace has quit IRC | 23:05 | |
| *** daneyon has joined #kolla | 23:10 | |
| *** daneyon_ has joined #kolla | 23:11 | |
| *** daneyon has quit IRC | 23:15 | |
| *** dwalsh has quit IRC | 23:24 | |
| *** bmace_ is now known as bmace | 23:28 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!