| opendevreview | Kien Nguyen proposed openstack/kolla-ansible master: [masakari] Add support for consul monitoring driver https://review.opendev.org/c/openstack/kolla-ansible/+/934590 | 07:23 |
|---|---|---|
| yosef | mnasidaka: Hi, can you check out these ? 1. add election-timer to ovn: https://review.opendev.org/c/openstack/kolla-ansible/+/934106 2. ovn relay: https://review.opendev.org/c/openstack/kolla-ansible/+/929646 | 09:04 |
| yosef | mnasiadka: . | 09:05 |
| opendevreview | Kien Nguyen proposed openstack/kolla-ansible master: [masakari] Add support for consul monitoring driver https://review.opendev.org/c/openstack/kolla-ansible/+/934590 | 09:52 |
| opendevreview | Kien Nguyen proposed openstack/kolla-ansible master: [masakari] Add support for consul monitoring driver https://review.opendev.org/c/openstack/kolla-ansible/+/934590 | 10:05 |
| SvenKieske | mnasiadka: someone pointed out via IRC that the commands in the docs are now in the wrong order, after the CLI rewrite: https://docs.openstack.org/kolla-ansible/latest/user/operating-kolla.html#kolla-ansible-cli I guess that's a fair point. Just wanted to notify you, in case someone could quickly update the docs from your team maybeß | 12:01 |
| SvenKieske | s/ß/?/ | 12:01 |
| EugenMayer440180 | SvenKieske beside the upgrade docs, which might matter the most by far, the need to fix docs is bigger. There are wrong usages all across the docs be it tls and other docs that are all affected by this. But i guess covering the upgrade notes first would help most of the people | 12:22 |
| opendevreview | Will Szumski proposed openstack/kayobe master: WIP: CI: Test interface bounce https://review.opendev.org/c/openstack/kayobe/+/934643 | 12:23 |
| SvenKieske | EugenMayer440180: Feel free to submit a patch and/or bug report, it's always appreciated. I might not have time in the near future to fix these myself. doc patches somehow always lag a little bit behind :) | 13:07 |
| shermanm | so, I've got a proof of concept working now that uses docker buildx and remote layer caches to speed builds up. would there be interest in an RFE? | 17:00 |
| opendevreview | Jay Jahns proposed openstack/kolla master: Allow specification of a key type https://review.opendev.org/c/openstack/kolla/+/934681 | 17:26 |
| opendevreview | Jay Jahns proposed openstack/kolla-ansible master: Add key type for letsencrypt certificate https://review.opendev.org/c/openstack/kolla-ansible/+/934683 | 17:42 |
| EugenMayer440180 | SvenKieske sorry to be a party pooper - if it would be github, i would have created a PR already, but opendev is so cumbersome, so complicated (even though i have a account) so that i really opt out any contributions (code wise) | 17:59 |
| EugenMayer440180 | shermanm buildx uses a remote cache by default? Sure you have to provide --cache-from (and you should pull yourself since buildx fails to do so form time to time) - but generally it is build in | 18:02 |
| shermanm | of course, just the part of making it play nicely with kolla | 18:02 |
| EugenMayer440180 | shermanm be sure to make yourself comfortable with the potentials bugs with unproper layer invalidation | 18:02 |
| EugenMayer440180 | buildx made a lot things faster, but mostly for the price inconsistency and buggy behavior. I wish i could tell it oterhwise | 18:03 |
| shermanm | my use case was really to speed up builds in our CI. you can already get "ok" caching if you rebuild on the same build host, but with (non-buildx) docker it's difficult to populate that cache initially | 18:04 |
| shermanm | so I'm really comparing "default local layer cache" to "remote buildx layer cache" | 18:05 |
| shermanm | I'm assuming a "release" build would still want to be done without caches for the reasons you mention | 18:05 |
| EugenMayer440180 | https://github.com/moby/buildkit/issues/1388 - this one has never been solved | 18:06 |
| EugenMayer440180 | and the issue does not create an inconvinience - it does no longer build what you expect. It's a huge issue | 18:07 |
| shermanm | interesting, do you know if it affects podman as well? | 18:08 |
| EugenMayer440180 | cannot tell, we still build under containerd mainly | 18:08 |
| EugenMayer440180 | https://docs.docker.com/build/cache/backends/#backends what is the remote-cache you are talking about. Sounds like the usual registry cache i know about, or is there more to it? | 18:09 |
| shermanm | right now i'm using registry-cache, as the source, with inline-caching as the destination. But i've also done some tests with local directory caching, and the github-actions cache | 18:10 |
| shermanm | with podman I've had good luck with registry-caches, unfortunately the python library being used for it in kolla does not expose the `cache_to` argument | 18:10 |
| EugenMayer440180 | without buildx you just need to ensure to pull the from image everytime you build and not rely on build to do it. That did not really change to much with buildx, usaully you should still pull, or it becomes unrelyable way to often. But buildx builds in general are a lot faster | 18:11 |
| shermanm | yeah, with my proof of concept, I can build the main, infra, aux profiles in about 4 minutes on a fresh builder machine | 18:11 |
| EugenMayer440180 | pull the from and the target image | 18:11 |
| EugenMayer440180 | you usually, if building tags, build something like FROM foo and then -t fqdn:branch-<branch> -t fqdn:<build-nr> | 18:12 |
| EugenMayer440180 | and then, you try to always pull FROM and fqdn:branch-<branch> before every build | 18:13 |
| EugenMayer440180 | but yes, using cache-to is really nice too, but in the end, using a very similar concept (branch or pr scoping) | 18:14 |
| shermanm | it very much needs a rebase onto upstream/master, and some cleanup, but I've got my branch here: https://github.com/ChameleonCloud/kolla/pull/14 | 18:20 |
| opendevreview | Felipe Figueroa Vergara proposed openstack/kolla-ansible master: Configures `s3_store_cacert` glance_store variable https://review.opendev.org/c/openstack/kolla-ansible/+/934696 | 22:19 |
| shermanm | EugenMayer440180_, one of the other things that could be interesting is the ability to pass multiple build contexts. Right now for plugins and additions, they're assembled in a tmp working directory, and this can impact caching | 22:34 |
| shermanm | but we might be able to just pass them as a list of contexts to the builder and avoid that | 22:35 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!