| *** mazzy5098811 is now known as mazzy509881 | 00:10 | |
| *** mazzy5098812 is now known as mazzy509881 | 00:18 | |
| *** mazzy5098814 is now known as mazzy509881 | 00:42 | |
| holtgrewe | jingvar, mgoddard - let me rephrase. Is the following. I boot *all* nodes with PXE and they will be discovered by bifrost/ironic. Some, I might put into etc/kayobe/inventory/hosts, the rest will appear in etc/kayobe/inventory/overcloud. | 06:54 |
|---|---|---|
| jingvar | As I understand autodiscovery is magic | 06:58 |
| jingvar | I use a simple way, bifrost.yaml with ipmi for my servers | 06:59 |
| holtgrewe | Another question, `kayobe baremetal compute rename` - will this work if ipmi_address is set to a DNS name? Or do i have to use IP addresses? The playbook appears to use string equality only... | 07:10 |
| *** amoralej|off is now known as amoralej | 07:57 | |
| opendevreview | Mark Goddard proposed openstack/kayobe master: docs: Improve all-in-one scenario https://review.opendev.org/c/openstack/kayobe/+/797003 | 09:15 |
| opendevreview | Mark Goddard proposed openstack/kolla-ansible stable/xena: docs: Fix python-openstackclient package name and init-runonce path https://review.opendev.org/c/openstack/kolla-ansible/+/817264 | 09:15 |
| opendevreview | Mark Goddard proposed openstack/kolla-ansible stable/wallaby: docs: Fix python-openstackclient package name and init-runonce path https://review.opendev.org/c/openstack/kolla-ansible/+/817265 | 09:15 |
| opendevreview | Mark Goddard proposed openstack/kolla-ansible stable/victoria: docs: Fix python-openstackclient package name and init-runonce path https://review.opendev.org/c/openstack/kolla-ansible/+/817266 | 09:15 |
| opendevreview | Mark Goddard proposed openstack/kolla-ansible stable/xena: Fix octavia doesn't set subnet gateway_ip https://review.opendev.org/c/openstack/kolla-ansible/+/817267 | 09:16 |
| opendevreview | Mark Goddard proposed openstack/kolla-ansible stable/wallaby: Fix octavia doesn't set subnet gateway_ip https://review.opendev.org/c/openstack/kolla-ansible/+/817268 | 09:16 |
| opendevreview | Mark Goddard proposed openstack/kolla-ansible stable/victoria: Fix octavia doesn't set subnet gateway_ip https://review.opendev.org/c/openstack/kolla-ansible/+/817269 | 09:17 |
| opendevreview | Mark Goddard proposed openstack/kayobe master: Ubuntu: add upgrade jobs to gate https://review.opendev.org/c/openstack/kayobe/+/817367 | 09:19 |
| opendevreview | Mark Goddard proposed openstack/kayobe master: Remove chrony cleanup from overcloud host configure https://review.opendev.org/c/openstack/kayobe/+/817279 | 09:27 |
| kevko | hrw: here ? | 09:31 |
| hrw | kevko: there | 09:33 |
| kevko | hrw: I'm trying to understand how tarball of "openstack code" is downloaded and extracted into image ...can you point me ? | 09:34 |
| hrw | let me check | 09:34 |
| kevko | hrw: because I have templates generated and all I can see is only "ADD keystone-base-archive /keystone-base-source" | 09:35 |
| kevko | and I really don't know where it is downloading, extracting ..etc | 09:36 |
| hrw | kevko: check kolla/image/build.py build_image_list() | 09:36 |
| hrw | kevko: and process_source() handles fetching | 09:37 |
| kevko | aaa | 09:37 |
| kevko | thank you :D | 09:37 |
| hrw | yw | 09:37 |
| kevko | is kolla supporting installation from git source ? | 09:38 |
| kevko | i mean ..currently ..out of the box | 09:38 |
| kevko | hrw: because you probably remember that I'm building binary images for our use-case (it's easy to patch a bug in deb package) ... and lastly I've fixed neutron in debian package -> https://salsa.debian.org/openstack-team/services/neutron/-/blob/debian/wallaby/debian/patches/revert-l3-ha-retry-when-setting-ha-router-gw-status.patch | 09:40 |
| hrw | kevko: git clone kolla, cd kolla, pip install -r requirements.txt, ./tools/build.py | 09:41 |
| kevko | hrw: nope, I mean source from git inside docker image | 09:41 |
| kevko | hrw: for example above mentioned neutron | 09:41 |
| hrw | kevko: we do that by default iirc | 09:42 |
| hrw | $ pip list|wc -l | 09:42 |
| hrw | 2013 | 09:42 |
| hrw | ;d | 09:42 |
| kevko | hrw: well process_source is downloading tarball from https://tarballs.opendev.org | 09:43 |
| kevko | so it's archived tagged version ..isn't it ? | 09:43 |
| kevko | but actually not git source .. | 09:43 |
| kevko | or am I missing something ? | 09:43 |
| hrw | fetching tarball of master branch was probably quicker than cloning git repos | 09:44 |
| hrw | and takes less space | 09:44 |
| kevko | ok, makes sense .. | 09:46 |
| hrw | kevko: users are free to edit SOURCES in kolla/common/config.py to point to git repos directly | 09:46 |
| hrw | kevko: fetching tarballs allows us to switch between "HEAD of branch" and versioned tarballs | 09:47 |
| hrw | kevko: we just stopped using versioned tarballs in stable/* branches | 09:47 |
| kevko | yeah, that's clever ..because versioned tarballs are buggy in most cases .. | 09:48 |
| kevko | that's the reason why I'm asking ..i had to patch neutron package in debian ...because we are packaging TAGged version in upstream ... | 09:48 |
| kevko | but bugfixes are released to stable/* branch | 09:48 |
| hrw | using versioned tarballs == need to update from time to time, lack of latest bugfixes | 09:50 |
| hrw | so that's why we moved to 'HEAD of stable/*' tarballs | 09:50 |
| kevko | yeah, clever .. | 09:51 |
| hrw | and that's why at previous PTG we decided to use stable/previous-branch for first weeks of release cycle | 09:51 |
| kevko | i will start to migrate to source probably | 09:51 |
| hrw | or no. that was to avoid additional breakage | 09:51 |
| hrw | kevko: you do not have much choice - binary gets deprecated in Yoga | 09:52 |
| kevko | i know :) | 09:52 |
| kevko | we are delivering images to our client .. | 09:52 |
| kevko | so i have to write some mechanism to strictly report versions of packages per dockerTAG + write some mechanizm which will check built version with potentionally new build version and report bugs fixed etc (from git commits and Closes-Bug) | 09:53 |
| kevko | if you understand me :/ | 09:53 |
| kevko | so we can say, you should update, because report is saying ..this is fixed in stable/* of project * and we can build new images .. | 09:54 |
| kevko | hrw: so what to change to fetch sources via git ? | 09:55 |
| kevko | aaaa - I see, gnocchi is for example downloading via git | 09:56 |
| hrw | kevko: for openstack components you may not change anything. git tarballs are created after commit lands in repo | 09:57 |
| hrw | kevko: will you parse logs for package infos? | 09:57 |
| kevko | well, If i will have some storage with objects - something like TAG -> { package_name: git_url, commit_id } ... then I can write automatic script which will check new commits and will find closes-bug for example | 10:00 |
| kevko | because our clients are quite sensitive to reconfigure,redeploy of containers ... | 10:01 |
| kevko | so I have to have good reason and nice report to show them they have to :P | 10:01 |
| kevko | is it bad idea ? | 10:02 |
| kevko | hrw: and why all is not installed from stable branches ...but only main projects ? | 10:04 |
| hrw | kevko: what you mean by 'all'? | 10:11 |
| kevko | i mean oslo libraries etc | 10:11 |
| hrw | they are version constrained to what stable/* requirements repo says | 10:11 |
| hrw | as they have pypi releases | 10:12 |
| hrw | kevko: check install_pip() macro in docker/macros.j2 | 10:14 |
| kevko | hmm, so if something is fixed in stable branch of some openstack library ..and not released as pypi package ..it's just not installed | 10:14 |
| hrw | yep | 10:18 |
| kevko | That's bad, isn't it? | 10:20 |
| hrw | there has to be a point where we stop | 10:21 |
| hrw | otherwise we start building glibc and kernel | 10:21 |
| kevko | :D - it is still python | 10:25 |
| opendevreview | Adrian Andreias proposed openstack/kolla-ansible master: docs: Install openstack-client with upper constraints https://review.opendev.org/c/openstack/kolla-ansible/+/816076 | 10:45 |
| admin1 | haproxy_ssl_self_signed_regen: false and haproxy_user_ssl_cert and _key is set .. but the playbook still wants to generate the cert .. has something changed/updated in the new version ? | 13:16 |
| admin1 | sorry wrong chat | 13:16 |
| *** amoralej is now known as amoralej|lunch | 13:22 | |
| opendevreview | Adrian Andreias proposed openstack/kolla-ansible master: docs: fix venv path "share/share" https://review.opendev.org/c/openstack/kolla-ansible/+/817432 | 14:02 |
| *** amoralej|lunch is now known as amoralej | 14:06 | |
| holtgrewe | jingvar, do you use bios or uefi boot mode? | 14:37 |
| jingvar | legacy | 14:40 |
| holtgrewe | thanks, good to know | 14:40 |
| jingvar | there no difference in my mind | 14:40 |
| jingvar | it just ironic settings | 14:41 |
| holtgrewe | jingvar, did you configure legacy boot anywhere? | 14:48 |
| yoctozepto | meeting in 10 - mgoddard mnasiadka hrw egonzalez yoctozepto rafaelweingartne cosmicsound osmanlicilegi bbezak parallax Fl1nt frickler adrian-a | 14:50 |
| jingvar | holtgrewe: yes | 14:58 |
| holtgrewe | jingvar, would you tell me where? ;-) | 14:58 |
| holtgrewe | *sigh* I had installed Rocky linux manually in UEFI mode on my dell servers previously... somehow an entry was created in UEFI to boot "rocky linux" but that was not present any more. | 14:59 |
| holtgrewe | After switching to legacy boot in Dell BIOS/iDRAC, I now boot into my properly configured centos 8 stream machines | 15:00 |
| jingvar | stop, which boot do you mean | 15:00 |
| yoctozepto | #startmeeting kolla | 15:01 |
| opendevmeet | Meeting started Wed Nov 10 15:01:35 2021 UTC and is due to finish in 60 minutes. The chair is yoctozepto. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:01 |
| opendevmeet | The meeting name has been set to 'kolla' | 15:01 |
| yoctozepto | #topic Roll-call | 15:01 |
| yoctozepto | \o/ | 15:01 |
| adrian-a | \o | 15:01 |
| mgoddard | \o | 15:02 |
| osmanlicilegi | o/ | 15:02 |
| priteau | o/ | 15:02 |
| ohorecny | o/ | 15:03 |
| hinermar | o/ | 15:03 |
| yoctozepto | welcome all :-) | 15:03 |
| halomiva | o/ | 15:03 |
| yoctozepto | #topic Agenda | 15:03 |
| yoctozepto | * Roll-call | 15:04 |
| yoctozepto | * Agenda | 15:04 |
| yoctozepto | * Announcements | 15:04 |
| yoctozepto | * Review action items from the last meeting | 15:04 |
| yoctozepto | * CI status | 15:04 |
| yoctozepto | * Release tasks | 15:04 |
| yoctozepto | * Yoga cycle planning | 15:04 |
| yoctozepto | * Open discussion | 15:04 |
| yoctozepto | plus the items from the whiteboard for today | 15:04 |
| yoctozepto | which is "Podman" | 15:04 |
| yoctozepto | #topic Announcements | 15:04 |
| yoctozepto | #info Xena RC2 was released | 15:05 |
| yoctozepto | we should be wrapping up Xena as soon as mnasiadka returns from vacations | 15:05 |
| yoctozepto | meaning: releasing the final "first version" of Xena | 15:05 |
| yoctozepto | any other announcements? | 15:05 |
| priteau | There are small fixes in Kayobe that would require an RC3 | 15:06 |
| priteau | Is kolla/kolla-ansible going to have an RC3 too? | 15:06 |
| yoctozepto | priteau: unlikely but it's not an issue | 15:06 |
| priteau | Yes, just curious | 15:07 |
| yoctozepto | ok, guessing no more announcements | 15:08 |
| yoctozepto | #topic Review action items from the last meeting | 15:08 |
| yoctozepto | let me see... | 15:08 |
| yoctozepto | yoctozepto to run the meeting next week | 15:09 |
| yoctozepto | hmm, seems to be happening | 15:09 |
| yoctozepto | mnasiadka to triage security bugs and update them with resolution plan (if needed) | 15:09 |
| yoctozepto | did not happen so needs to happen later when mnasiadka returns | 15:09 |
| yoctozepto | #action mnasiadka to triage security bugs and update them with resolution plan (if needed) | 15:09 |
| yoctozepto | yoctozepto hide properly init-runonce | 15:09 |
| yoctozepto | did not have time | 15:09 |
| yoctozepto | #action yoctozepto hide properly init-runonce | 15:10 |
| yoctozepto | #topic CI status | 15:10 |
| yoctozepto | the whiteboard says green for all supported branches of all our projects | 15:10 |
| yoctozepto | any comments on that? | 15:10 |
| priteau | Kayobe is good at the moment | 15:10 |
| yoctozepto | :-) | 15:10 |
| yoctozepto | thanks | 15:11 |
| yoctozepto | I have seen stuff merging to k and k-a as well so betting all well there as well | 15:11 |
| yoctozepto | I have clenad up the "issue" under k-a | 15:12 |
| yoctozepto | cleaned* | 15:12 |
| yoctozepto | as it was no longer valid | 15:12 |
| yoctozepto | #topic Release tasks | 15:14 |
| yoctozepto | let's see the release cycle plan | 15:14 |
| yoctozepto | xena is wrapping up so let's focus on yoga | 15:14 |
| yoctozepto | #link https://releases.openstack.org/yoga/schedule.html | 15:15 |
| yoctozepto | #link https://docs.openstack.org/kolla/latest/contributor/release-management.html | 15:15 |
| yoctozepto | it's R-20 | 15:15 |
| yoctozepto | no release tasks for this week | 15:15 |
| mgoddard | I jumped the gun a bit and proposed patches to bump previous_release | 15:15 |
| yoctozepto | though I have seen mgoddard proposing stuff for R-17 | 15:15 |
| yoctozepto | indeed | 15:15 |
| yoctozepto | I don't mind, they are quite safe | 15:16 |
| mgoddard | well I think the idea was to try to look like the previous release for a while | 15:16 |
| mgoddard | to avoid breakages | 15:17 |
| yoctozepto | yeah, but this one part essentially makes us upgrade from xena to xena so it's pretty safe | 15:17 |
| yoctozepto | well, we could introduce a bug if we made upgrade=deploy | 15:17 |
| yoctozepto | and did not notice | 15:17 |
| yoctozepto | but otherwise... | 15:18 |
| yoctozepto | anyhow | 15:18 |
| yoctozepto | let's continue | 15:18 |
| yoctozepto | #topic Yoga cycle planning | 15:18 |
| yoctozepto | ok, so it's R-20 in Yoga and we had some glorious plans | 15:18 |
| yoctozepto | we can discuss Podman today as it's in the agenda and the relevant folks are around | 15:19 |
| yoctozepto | I have already commented on the change | 15:19 |
| yoctozepto | #link https://review.opendev.org/c/openstack/kolla-ansible/+/816724 | 15:19 |
| yoctozepto | so it's about moving to using systemd | 15:19 |
| ohorecny | yes, thank you for your comments. Guys from my team need to incorporate them. | 15:20 |
| yoctozepto | indeed :-) if you have comments/questions, please feel welcome to put them on the change | 15:21 |
| ohorecny | So what do you think, how it looks like. Since this change should we support only docker containers managed by systemd? Or also managed by docker? | 15:22 |
| Fl1nt | Hi team! | 15:22 |
| yoctozepto | ohorecny: both first; I suggested to go in even smaller steps with refactoring itself being the first so that we can merge 1:1 functionality in new, more flexible, layout | 15:22 |
| yoctozepto | hi Fl1nt | 15:22 |
| Fl1nt | Sorry for the vanishing, I've been a bit busy lately :( | 15:23 |
| Fl1nt | what's up yoctozepto ? | 15:23 |
| ohorecny | yoctozepto: So you think that both approaches should be supported? And user can choose ? | 15:24 |
| yoctozepto | Fl1nt: we are in the middle of the meeting :-) | 15:24 |
| yoctozepto | ohorecny: I think at least code-wise for a moment they should coexist so that we can weed out weird edge cases | 15:25 |
| Fl1nt | aaaah forget about that TZ daytime switch fuu, thought I would have make it on time for once :( | 15:25 |
| Fl1nt | sorry | 15:25 |
| yoctozepto | Fl1nt: no probs | 15:25 |
| ohorecny | yoctozepto: aha, ok we went by that way that we are moving it under systemd management | 15:27 |
| mgoddard | https://docs.podman.io/en/latest/markdown/podman-generate-systemd.1.html | 15:28 |
| mgoddard | looks like you are using the start/stop approach | 15:28 |
| mgoddard | just wondering what are the merits of the --new approach | 15:28 |
| yoctozepto | mgoddard: "please review the generated files carefully before using them in production" eh | 15:29 |
| yoctozepto | I guess it would be nice to see how they look like | 15:30 |
| yoctozepto | but we should nonetheless control the unit files ourselves like we discussed during the ptg | 15:30 |
| mgoddard | agreed, I'm just looking at what podman will generate for you | 15:31 |
| mgoddard | it gives you two options | 15:31 |
| mgoddard | by default it just starts & stops, as in the proposed patch | 15:31 |
| ohorecny | yes and this is how it is now for docker and merit is that in case of podman we will do it in similar way | 15:31 |
| mgoddard | but if you pass --new, it will create and destroy | 15:31 |
| mgoddard | both docker and podman could use either way | 15:32 |
| ohorecny | mgodard: genereting by using podman we already had implemented in that older big patchset | 15:32 |
| mgoddard | yes, I'm not suggesting we do that | 15:32 |
| mgoddard | I'm just saying, podman team has probably thought about this, let's see what they do | 15:33 |
| mgoddard | and they offer two options | 15:33 |
| mgoddard | so which should we follow? | 15:33 |
| yoctozepto | is the destruction on stop? | 15:34 |
| mgoddard | yes | 15:34 |
| mgoddard | https://docs.podman.io/en/latest/markdown/podman-generate-systemd.1.html#generate-systemd-unit-file-for-a-container-with-new-flag | 15:34 |
| yoctozepto | hmm, sounds like a way to ensure that containers are themselves stateless | 15:34 |
| mgoddard | IIRC ceph-ansible does it that way | 15:35 |
| Fl1nt | yes and it works perfectly tbn | 15:35 |
| ohorecny | yes, that is good point, but it is in future now, when we introduce podman. As we discussed in PTG now we need to support docker with systemd | 15:36 |
| yoctozepto | that's correct | 15:37 |
| yoctozepto | and I've given you hints how to do it best code-structure-wise | 15:37 |
| Fl1nt | ohorecny, you mean lifecycle of containers from systemd units or replace dumb-init with systemd ? | 15:37 |
| mgoddard | it's not necessarily in the future - you can use both patterns with docker and podman | 15:38 |
| ohorecny | Fl1nt: first option | 15:38 |
| yoctozepto | Fl1nt: the first | 15:38 |
| Fl1nt | ok thanks :D | 15:38 |
| mgoddard | perhaps the proposed approach is most similar to what we have today | 15:38 |
| yoctozepto | mgoddard: let's maybe make it optional as well? | 15:39 |
| yoctozepto | I want clean code change with the exact same behaviour except for systemd indirection | 15:39 |
| Fl1nt | just a quick thought about that, as Ansible community.docker collection is able to really well manage containers lifecycle and that podman control containers from systemd units, is that really useful to integrate for docker? | 15:39 |
| mgoddard | Fl1nt: yes | 15:40 |
| mgoddard | exact same ansible code for both | 15:40 |
| Fl1nt | ok | 15:40 |
| yoctozepto | and we need to have more control/interaction with containers than just with the barebones | 15:40 |
| Fl1nt | ansible module let you control everything | 15:41 |
| Fl1nt | from volume to network and vars/etc | 15:41 |
| ohorecny | exactly like mgoddard said, it is not necessary, but in other case we will have much bigger change and "duplicated" code | 15:41 |
| yoctozepto | Fl1nt: yeah, but at the cost of repeating a ton of stuff that we have customised for ourselves | 15:41 |
| Fl1nt | yep unicity is best. | 15:41 |
| Fl1nt | gotcha ^^ | 15:42 |
| mgoddard | ohorecny: one thing that would help: split the change into two parts. 1. refactor module to module_utils 2. make changes | 15:42 |
| Fl1nt | cool initiative about podman indeed :D | 15:42 |
| mgoddard | IMO refactors should not change behaviour | 15:42 |
| ohorecny | Fl1nt: in that other way the patchset will look like this: https://review.opendev.org/c/openstack/kolla-ansible/+/799229 | 15:43 |
| ohorecny | it was our first approach, but too big :( | 15:43 |
| Fl1nt | yep, I kept an eye on it while being away of IRC ;-) | 15:44 |
| ohorecny | mgoddard: ok | 15:44 |
| ohorecny | Guys hinermar and halomiva do you agree? | 15:45 |
| hinermar | Yes | 15:45 |
| ohorecny | they are mostly working on these changes | 15:45 |
| ohorecny | ok, so next step is do some refactoring | 15:46 |
| yoctozepto | basically what I've commented about :-) | 15:46 |
| ohorecny | in case of any questions about review comments please ask directly in change | 15:46 |
| yoctozepto | ok, any other Yoga things to discuss at this stage? | 15:47 |
| ohorecny | yoctozepto: right, thanks again | 15:47 |
| Fl1nt | yoga? | 15:48 |
| Fl1nt | Oh release name ^^ | 15:49 |
| Fl1nt | sorry | 15:49 |
| yoctozepto | ohorecny: you are welcome :-) | 15:49 |
| frickler | is there anything to discuss regarding "drop admin endpoints"? seems most people agreed to do it | 15:49 |
| frickler | so I'd just add a reno and it should be fine? | 15:50 |
| frickler | https://review.opendev.org/c/openstack/kolla-ansible/+/816164 for reference | 15:50 |
| mgoddard | let's do it | 15:51 |
| yoctozepto | TM | 15:52 |
| yoctozepto | and I agree wholeheartedly | 15:52 |
| yoctozepto | though we could somehow help operators clean up | 15:52 |
| yoctozepto | but it's easy to do via a simple script I gues | 15:53 |
| yoctozepto | guess* | 15:53 |
| frickler | yeah, I was just thinking whether to add a script for cleanup that could be ran on demand | 15:53 |
| Fl1nt | aaaah finally that blessed day where admin endpoints disapear !! | 15:53 |
| frickler | I'll try to come up with something | 15:54 |
| mgoddard | +1 for cleaning up | 15:54 |
| mgoddard | I suppose it might cause issues if we do it during the upgrade | 15:55 |
| Fl1nt | yeah, should probably be a post-task | 15:55 |
| frickler | I wouldn't want to do it automatically, yes. but make it easy for operators as a separate step seems a good compromise | 15:55 |
| yoctozepto | well, best to keep it as a helper script | 15:56 |
| yoctozepto | ok, we are nearing the end of time | 15:56 |
| yoctozepto | #topic Open discussion | 15:56 |
| yoctozepto | anything really | 15:56 |
| adrian-a | I think this can be closed as Won't Fix, based on last meeting discussion https://bugs.launchpad.net/kolla-ansible/+bug/1554049 | 15:56 |
| headphoneJames | in Yoga - trying to move towards being able enabling the new system scope policies. | 15:57 |
| yoctozepto | adrian-a: agreed from my side | 15:57 |
| Fl1nt | so I've a discussion topic | 15:57 |
| Fl1nt | since a bit of time now | 15:57 |
| Fl1nt | at work | 15:57 |
| yoctozepto | headphoneJames: and how's that going? | 15:58 |
| headphoneJames | first pass | 15:58 |
| headphoneJames | https://review.opendev.org/c/openstack/kolla-ansible/+/815577 | 15:58 |
| headphoneJames | its ready for comments | 15:58 |
| Fl1nt | we're experimenting with an ansible method that gave us the ability in 1 repo to get both similar mechanisms than kolla/kolla-ansible | 15:59 |
| Fl1nt | would you be interested in? | 15:59 |
| headphoneJames | yoctozepto: The transaction only converts the config for the [keystone_authtoken] section, and not all the configurations for authenticating with other services through keystone. | 15:59 |
| mgoddard | Fl1nt: would be interested to take a look | 16:00 |
| yoctozepto | headphoneJames: ack, sensible tradeoff | 16:01 |
| yoctozepto | ok, out of time | 16:01 |
| yoctozepto | thank you all for participating | 16:01 |
| yoctozepto | #endmeeting | 16:01 |
| opendevmeet | Meeting ended Wed Nov 10 16:01:27 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:01 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/kolla/2021/kolla.2021-11-10-15.01.html | 16:01 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/kolla/2021/kolla.2021-11-10-15.01.txt | 16:01 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/kolla/2021/kolla.2021-11-10-15.01.log.html | 16:01 |
| Fl1nt | ok, so basically, the idea is to follow the initial docker proposition for containers, meaning build > ship > run and so get thos three main common roles plus a specific role per service that call them. | 16:01 |
| frickler | headphoneJames: do you have any plan how to solve the upgrade problem for that? | 16:02 |
| Fl1nt | by doing so we're able to mimic kolla-ansible tools/wrapper but using pure ansible. | 16:02 |
| Fl1nt | I'll try to find a way to publish a skeleton of this idea without leaking intel :D | 16:02 |
| headphoneJames | frickler: no - open to ideas :) | 16:03 |
| Fl1nt | basically it create a "kolla framework" over ansible engine :D | 16:03 |
| mgoddard | Fl1nt: yoctozepto proposed something similar a while back, but I don't think he started it | 16:04 |
| mgoddard | Fl1nt: any reason why you're doing this vs upstream kolla-ansible? | 16:04 |
| Fl1nt | aaaah nice! I'm glad to hear about that :D | 16:04 |
| yoctozepto | mgoddard: not quite the same but making it more frameworky for sure | 16:04 |
| Fl1nt | mgoddard, currently prototyping it and then proposing it later on to kolla, we won't use it as is in prod. | 16:05 |
| yoctozepto | but I changed my responsibilities quite much and can't commit to the original plan | 16:05 |
| yoctozepto | well, more like they were changed for me | 16:05 |
| yoctozepto | but you get the point | 16:05 |
| Fl1nt | mgoddard, basically, I'm not yet working upstream on this framework as I don't want to commit on something that I won't be able to deliver as I'm currently really busy at work. | 16:06 |
| Fl1nt | so I'm using my job time to do that internally while still being able to upstream it later on by sharing the idea and a blueprint ^^ | 16:07 |
| mgoddard | Fl1nt: before you spend your time on this thing, I'd suggest working out if people actually want it | 16:08 |
| Fl1nt | You're right | 16:09 |
| yoctozepto | then go upstream asap | 16:10 |
| yoctozepto | be bold | 16:10 |
| Fl1nt | but I'll still spend time on it as it will be our internal skeleton/framework for everything else from HW deployment (spine/leaf/nodes/compliance) to SW deployment (internal software). | 16:10 |
| yoctozepto | nice | 16:11 |
| Fl1nt | ok, I'll try to find time to create the blueprint. | 16:12 |
| yoctozepto | or just propose a PoC ;-) | 16:13 |
| Fl1nt | ah yeah could be easier tbh | 16:13 |
| mgoddard | Fl1nt: having thought about this more, I'm going to say what I'm actually thinking and what I expect others are too | 17:01 |
| mgoddard | Fl1nt: if you have some time available, rather than building yet another openstack deployment tool, please work with us to help maintain and improve the code we already have | 17:01 |
| *** amoralej is now known as amoralej|off | 18:23 | |
| Fl1nt | mgoddard, I'm in, no worries, just let me know when you need me :D | 18:45 |
| opendevreview | James Kirsch proposed openstack/kolla-ansible master: Add support for LetsEncrypt-managed certs https://review.opendev.org/c/openstack/kolla-ansible/+/741340 | 19:29 |
| opendevreview | Pierre Riteau proposed openstack/kayobe-config-dev master: Synchronise job config with kayobe https://review.opendev.org/c/openstack/kayobe-config-dev/+/817478 | 21:24 |
| *** hrww is now known as hrw | 22:34 | |
| opendevreview | Merged openstack/kayobe master: Ubuntu: add upgrade jobs to gate https://review.opendev.org/c/openstack/kayobe/+/817367 | 22:50 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!