*** amoralej|off is now known as amoralej | 08:08 | |
DK4 | when doing the quickstart in kolla i get an error at the pip3 install of kola itself: ERROR: Command errored out with exit status 128: git clone -q https://opendev.org/openstack/kolla-ansible /tmp/pip-req-build-qtdndaab Check the logs for full command output. | 08:11 |
---|---|---|
opendevreview | Mark Goddard proposed openstack/kolla-ansible stable/xena: Specify log file name for Nova API https://review.opendev.org/c/openstack/kolla-ansible/+/818905 | 08:52 |
opendevreview | Mark Goddard proposed openstack/kolla-ansible stable/victoria: Specify log file name for Nova API https://review.opendev.org/c/openstack/kolla-ansible/+/818906 | 08:53 |
mnasiadka | mgoddard, yoctozepto, hrw: https://review.opendev.org/c/openstack/releases/+/818882 - seems monasca-grafana build has failed on the publish job - but all the other images have been pushed. | 10:38 |
mgoddard | mnasiadka: ack | 10:41 |
mnasiadka | I guess we don't really care? | 10:41 |
ijustr | hello, wondering if this is the right place to ask a kayobe question to the community :) i'm able to deploy openstack with controllers, compute and storage nodes but as soon as we try to deploy 2 separate network hosts it fails with "msg": "Required network 'internal' (Default network) is not mapped to this host; Required network 'internal' (API network) is not mapped to this host; Required network 'public' (External | 10:47 |
ijustr | network) is not mapped to this host; Required external network 'external' is not mapped to this host". Followed https://docs.openstack.org/kayobe/wallaby/control-plane-service-placement.html#control-plane-service-placement-network-hosts, as we playing around with Wallaby at the moment. | 10:47 |
jingvar | You should walk thoght the network model | 10:56 |
ijustr | from this page? https://docs.openstack.org/kayobe/wallaby/configuration/reference/network.html | 10:56 |
hrw | mnasiadka: we dropped monasca-grafana in April... | 10:57 |
jingvar | just write out wich network, host , interface | 10:57 |
ijustr | here on irc? | 10:58 |
jingvar | ijustr: start from the end :) | 10:58 |
ijustr | in etc/kayobe/inventory/controllers/network-interfaces | 11:00 |
ijustr | br_interface: "{{ controller_extra_network_interfaces[0] }}{{ br_bridge_ports[0] }}" | 11:01 |
ijustr | br_bridge_ports: | 11:01 |
ijustr | - eth1 | 11:01 |
ijustr | provision_oc_interface: eth0 | 11:01 |
ijustr | oob_oc_interface: "{{ br_interface }}.{{ oob_vlan }}" | 11:01 |
ijustr | internal_interface: "{{ br_interface }}.{{ internal_vlan }}" | 11:01 |
ijustr | storage_interface: "{{ br_interface }}.{{ storage_vlan }}" | 11:01 |
opendevreview | Pierre Riteau proposed openstack/kolla-ansible stable/xena: Fix wrong opts in cyborg.conf https://review.opendev.org/c/openstack/kolla-ansible/+/818907 | 11:01 |
ijustr | public_interface: "{{ br_interface }}.{{ public_vlan }}" | 11:01 |
ijustr | external_interface: "{{ br_interface }}.{{ external_vlan }}" | 11:01 |
ijustr | tunnel_interface: "{{ br_interface }}.{{ external_vlan }}" | 11:01 |
ijustr | nah that's not good :P | 11:01 |
opendevreview | Pierre Riteau proposed openstack/kolla-ansible stable/wallaby: Replace auth_uri with www_authenticate_uri https://review.opendev.org/c/openstack/kolla-ansible/+/818908 | 11:03 |
opendevreview | Pierre Riteau proposed openstack/kolla-ansible stable/victoria: Replace auth_uri with www_authenticate_uri https://review.opendev.org/c/openstack/kolla-ansible/+/818909 | 11:04 |
ijustr | I'll fork the config repo and send a compare link instead for overview of our config might be a good idea | 11:06 |
mnasiadka | hrw: in Ussuri? | 11:10 |
hrw | ah. sorry | 11:10 |
hrw | (kolla) 12:23 (s) marcin@puchatek:kolla$ for branch in ussuri victoria wallaby xena;do git switch stable/$branch;git up;kolla-build-images.sh centos source monasca-grafana test-monasca-grafana-$branch;done | 11:23 |
hrw | let me check does it work at all in any branch | 11:23 |
mnasiadka | it seems it fails on c entos | 11:28 |
hrw | built in victoria | 11:33 |
hrw | no idea what goes wrong | 11:43 |
ijustr | https://github.com/openstack/kayobe-config/compare/stable/wallaby...ist-international:stable/wallaby with this config we get the error pasted before (is not mapped to this host) | 11:54 |
jingvar | I'm not sure that {{ br_bridge_ports[0] }}" sould works | 12:10 |
jingvar | I think etc/kayobe/inventory/group_vars/controllers/network-interfaces rendered as jinja template, and {{ br_bridge_ports[0] }}" is undefined for the render, because br_bridge_ports is in template body | 12:13 |
ijustr | it seems to render just fine for kayobe-config/etc/kolla/inventory/overcloud/host_vars/controller0, there's data rendered from template, and it works correctly if not trying to separate the network nodes, but I can hard code it and run again | 12:14 |
jingvar | if you want to use a variable in template yuo should define it in level up, I mean as hostvariable | 12:14 |
jingvar | I don't like use variables which are defined somewhere later | 12:16 |
ijustr | updated conf and running again | 12:16 |
jingvar | just add ansible debug and check varibales for the host | 12:17 |
jingvar | external networks etc | 12:17 |
ijustr | the -vvvv to the command? | 12:17 |
ijustr | same error hardcoded | 12:18 |
jingvar | no, insert debug code into failed playbook | 12:18 |
ijustr | I'm not that familiar with ansible to to translate that into what to write and where :) | 12:19 |
ijustr | I'm guessing where is in this file venvs/kayobe/share/kayobe/ansible/kolla-ansible.yml the the task that fails, in this case 'Set Kolla Ansible host variables' | 12:22 |
*** hrww is now known as hrw | 13:00 | |
opendevreview | Martin Hiner proposed openstack/kolla-ansible master: Refactor of kolla_docker into module_utils https://review.opendev.org/c/openstack/kolla-ansible/+/817954 | 13:01 |
DK4 | is there something wrong with the mariadb backup enable? FAILED! => {"action": "mysql_user", "changed": false, "msg": "(1064, \"You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'BINLOG MONITOR ON *.* TO 'backup'@'%'' at line 1\")"} | 14:14 |
mnasiadka | mgoddard mnasiadka hrw egonzalez yoctozepto rafaelweingartne cosmicsound osmanlicilegi bbezak parallax Fl1nt frickler adrian-a - Kolla meeting in 10 | 14:50 |
mnasiadka | #startmeeting kolla | 15:01 |
opendevmeet | Meeting started Wed Nov 24 15:01:04 2021 UTC and is due to finish in 60 minutes. The chair is mnasiadka. 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 |
mnasiadka | #topic rollcall | 15:01 |
frickler | o/ | 15:01 |
adrian-a | \o | 15:02 |
mgoddard | \o | 15:02 |
mgoddard | mnasiadka: where is that ping list from? | 15:03 |
mnasiadka | mgoddard: from the wiki, we still haven't merged the docs change I think | 15:03 |
mnasiadka | o/ | 15:03 |
headphoneJames | o/ | 15:05 |
adrian-a | https://wiki.openstack.org/wiki/Meetings/Kolla#10_minute_warning | 15:06 |
mnasiadka | #topic agenda | 15:06 |
mnasiadka | * Review action items from the last meeting | 15:06 |
mnasiadka | * CI status | 15:06 |
mnasiadka | * Release tasks | 15:06 |
mnasiadka | * Yoga cycle planning | 15:06 |
mnasiadka | * Bootstrap servers in Kayobe (mgoddard) | 15:06 |
mnasiadka | * Open discussion | 15:06 |
mnasiadka | #topic Review action items from the last meeting | 15:06 |
mnasiadka | mnasiadka to triage security bugs and update them with resolution plan (if needed) | 15:07 |
mnasiadka | yoctozepto hide properly init-runonce | 15:07 |
mnasiadka | not forget to go through backports for stable branches (L248 on Whiteboard) and do stable releases afterwards. | 15:07 |
mnasiadka | mnasiadka to EOL rocky and stein for both kolla and kolla-ansible | 15:07 |
mnasiadka | I didn't triage sec bugs | 15:07 |
mnasiadka | I have raised the EOL change and sent a mail to ML | 15:07 |
mnasiadka | yoctozepto is not here, but I don't think he did his | 15:07 |
mnasiadka | Has anybody gone through backports? I guess not... | 15:08 |
mgoddard | not I | 15:09 |
mnasiadka | Then not | 15:09 |
mnasiadka | #action mnasiadka to triage security bugs and update them with resolution plan (if needed) | 15:09 |
mnasiadka | #action yoctozepto hide properly init-runonce | 15:09 |
mnasiadka | #action not forget to go through backports for stable branches (L248 on Whiteboard) and do stable releases afterwards. | 15:09 |
mnasiadka | #topic CI Status | 15:09 |
mnasiadka | We've had a fail on publish jobs for centos in Ussuri (monasca-grafana failed) | 15:10 |
mnasiadka | hrw was looking at rebuilding it, but I think it suceeded on his end | 15:11 |
mnasiadka | I'll check as well, and if it works, then it was just a one off... (and Ussuri is EM anyway) | 15:12 |
mnasiadka | CI Status on the whiteboard looks green as grass | 15:12 |
mnasiadka | #topic Release tasks | 15:13 |
mnasiadka | it's R-18 now | 15:13 |
mnasiadka | R-17 was Switch source images to current release | 15:14 |
mnasiadka | mgoddard: are those changes merged? I remember you raised those? | 15:14 |
mgoddard | R-17 is next week :) | 15:14 |
mgoddard | they didn't get merged IIRC | 15:15 |
mnasiadka | Ah, right | 15:15 |
mnasiadka | Can we get them marked as priority changes? | 15:16 |
mgoddard | We may as well wait for next week now | 15:16 |
mnasiadka | Sure | 15:17 |
mnasiadka | So let's move on | 15:17 |
mnasiadka | #topic Yoga cycle planning | 15:17 |
mnasiadka | I've sent out the email regarding Kolla plans for next cycle, let's wait a bit more for replies - I know Fl1nt promised one (and some others promised to send replies) | 15:18 |
mnasiadka | Is there any particular feature we'd like to discuss today? | 15:19 |
mgoddard | How is the yoga feature list looking? | 15:19 |
mnasiadka | I started tidying it up and will populate it in the whiteboard, so that's a valid question mgoddard ;-) | 15:21 |
mgoddard | yeah, would be nice to have something to iterate on | 15:22 |
mnasiadka | Ok, I'll make that my priority for this week. | 15:22 |
mgoddard | should we formalise the process of updating/maintaining versions? | 15:22 |
adrian-a | I assume this can be dropped as CentOS will be deprecated: https://bugs.launchpad.net/kolla/+bug/1946801 | 15:23 |
mnasiadka | mgoddard: do you mean stable minor releases? | 15:24 |
mgoddard | I think we don't have a very standard way of deciding when we should update things like OS distros, core component versions (mariadb, rabbitmq) and tooling (ansible) | 15:24 |
mnasiadka | adrian-a: no, that is for both binary and source - but we may fix it by not using RDO packages. | 15:24 |
adrian-a | ok | 15:25 |
mgoddard | adrian-a: let's not make any assumptions until we have a final decision on the future of images | 15:25 |
mnasiadka | mgoddard: that's correct, we could think of having some rules | 15:25 |
hrw | mnasiadka: monasca-grafana failed in ussuri, worked in victoria | 15:25 |
mgoddard | I suppose rules might help, e.g. can't update things after R-X | 15:26 |
mnasiadka | Especially after deprecating/dropping binary - we would not be so tied to upgrading OS distros as we currently are with CentOS | 15:26 |
mnasiadka | true | 15:26 |
mgoddard | I was thinking more about encouraging conversations at certain points in a release cycle about what we might need to update | 15:27 |
* hrw off, sorry | 15:27 | |
yoctozepto | o/ (sorry, I got lost in some analysis and forgot the meeting) | 15:27 |
yoctozepto | (oh my, two sorries at once) | 15:28 |
mnasiadka | Ok then, one thing is updating Ansible - this can be more or less predicted even at PTG level | 15:28 |
mgoddard | hrw tags in yoctozepto | 15:29 |
mnasiadka | Probably OS distro upgrade is similar | 15:29 |
mgoddard | hopefully, yes | 15:29 |
yoctozepto | mgoddard: :D | 15:29 |
yoctozepto | ok, so we have upgrade to mariadb 10.6 as we planned | 15:30 |
yoctozepto | but the change just landed randomly | 15:30 |
yoctozepto | upgraded* | 15:30 |
mgoddard | right, that's what I'm saying | 15:30 |
mnasiadka | And then new RabbitMQ/MariaDB/infrastructure_software releases should not be done late in the cycle, often OS distro upgrade dictates those versions | 15:30 |
mnasiadka | And especially MariaDB/RabbitMQ upgrades should be done early in the cycle to see what issues will we get in CI for the next couple of months | 15:31 |
mgoddard | so maybe we need a standard PTG topic for this, and then a release process point mid-cycle to discuss again | 15:31 |
mnasiadka | But RabbitMQ and MariaDB are now from their own repositories, so we have more control over them. | 15:31 |
yoctozepto | yeah | 15:32 |
yoctozepto | is rabbitmq upgradable btw? | 15:32 |
mnasiadka | You ask me :) | 15:32 |
yoctozepto | I think they have been on 3.8 for a long time | 15:32 |
yoctozepto | yeah, there seems to be 3.9 already | 15:32 |
adrian-a | we have a rule in another project where we update 3rd parties as first task after a stable release (or as early as possible), this way we have a full cycle to discover issues | 15:32 |
yoctozepto | do we want to touch it? | 15:32 |
mnasiadka | Do we need some part of the Kolla contributor docs with standard topics that should be discussed over PTG and then revisited in mid-cycle? | 15:32 |
yoctozepto | we could use that | 15:33 |
yoctozepto | (re: docs) | 15:33 |
mgoddard | +1 | 15:34 |
mnasiadka | Ok, any volunteer to start the docs change? | 15:34 |
yoctozepto | now that's a harder question | 15:35 |
mnasiadka | Well, I need to update the weekly meetings docs change, so I can start that one | 15:36 |
mnasiadka | #action mnasiadka post a patch for docs - standard topics that should be discussed over PTG and then revisited in mid-cycle | 15:36 |
* yoctozepto cheering mnasiadka on | 15:36 | |
mnasiadka | While we're at tooling - ansible-core 2.11 is out, Ansible 5 (the collection of collections and so on) will be out somewhere mid December - are we bumping this cycle? | 15:38 |
mnasiadka | ups, I mean ansible-core 2.12 | 15:39 |
yoctozepto | if it works with core 2.12, then I'm all in | 15:39 |
yoctozepto | or otherwise | 15:39 |
mnasiadka | Well, Python 3.8 is a hard requirement ;-) | 15:39 |
yoctozepto | if we can keep the compats sane | 15:39 |
yoctozepto | ah well | 15:39 |
mgoddard | ah, difficult for centos 8 | 15:40 |
yoctozepto | for sure we don't want to make it a minimum | 15:40 |
mnasiadka | Yes, even for Stream | 15:40 |
mnasiadka | But we could set it as maximum | 15:40 |
yoctozepto | but let's test it | 15:40 |
yoctozepto | indeed | 15:40 |
mnasiadka | Ok, I'll add it to the list of priorities for Yoga | 15:41 |
mnasiadka | #action mnasiadka Add ansible-core 2.12 to the list of Yoga priorities | 15:41 |
mnasiadka | ok, any other Yoga topics? | 15:41 |
yoctozepto | yeah, rabbitmq | 15:42 |
yoctozepto | do we want to bump it since we can? | 15:42 |
mgoddard | how new is it? | 15:42 |
yoctozepto | 3.9.023 July 2021 | 15:42 |
mnasiadka | 3.8 End of General Support is 31 January 2022 | 15:42 |
mnasiadka | so do we have any option not to? | 15:42 |
yoctozepto | 3.9.1020 November 2021 | 15:42 |
mgoddard | ok, let's go | 15:42 |
mgoddard | it can't get much worse :D | 15:43 |
mnasiadka | #action mnasiadka Add rabbitmq 3.9 to the list of Yoga priorities | 15:43 |
mnasiadka | ;) | 15:43 |
mnasiadka | anything else? | 15:43 |
yoctozepto | 1 General Support means patch releases that are produced regularly based on feedback from all users. | 15:43 |
yoctozepto | 2 Extended Support means security patches and high-severity issues reported by users with a commercial license. | 15:43 |
yoctozepto | just a note it's not THAT BAD ;-) | 15:43 |
mnasiadka | I don't have a commercial license ;-) | 15:43 |
yoctozepto | nothing else from me | 15:43 |
yoctozepto | mnasiadka: yeah, but utterly broken releases will still get fixed as well as sec issues | 15:44 |
yoctozepto | anyhow, let's bump since it's sensible | 15:44 |
mnasiadka | yoctozepto: I don't want to count how many times did I do full RabbitMQ wipe to get it back to working state, and couldn't find a bug that caused that ;-) | 15:45 |
mnasiadka | #topic Bootstrap servers in Kayobe (mgoddard) | 15:45 |
yoctozepto | mnasiadka: precisely, so what are you worrying about even? :D | 15:45 |
mnasiadka | mgoddard: stage is yours | 15:46 |
mgoddard | thank you | 15:46 |
mgoddard | tl;dr: I'm working on copying the baremetal role from kolla-ansible into kayobe | 15:47 |
mgoddard | some background | 15:47 |
mgoddard | Ansible error handling is tricky | 15:47 |
mgoddard | #link https://github.com/markgoddard/ansible-experiments/tree/master/14-error-handling | 15:47 |
mgoddard | The use case is: allow a 'kayobe overcloud host configure' command to execute to completion in the face of some host failures, or even missing hosts | 15:48 |
mgoddard | The relevant part of the problem here is that kayobe mixes its own playbooks and kolla-ansible bootstrap-servers in that command | 15:49 |
mgoddard | so if any hosts fail during the kayobe playbooks, we don't run bootstrap-servers | 15:49 |
mgoddard | some less important reasons for doing this: | 15:50 |
yoctozepto | ( mgoddard: on the linked github page some "echo $?" are missing return value ) | 15:50 |
mgoddard | it can be a bit clunky/hairy to specify tags/limit to this command, since it mixes kayobe & kolla playbooks | 15:51 |
mgoddard | and some parts of bootstrap-servers are duplicated in kayobe already | 15:51 |
mgoddard | finally, some of this code could use a clean up | 15:51 |
opendevreview | Radosław Piliszek proposed openstack/kolla-ansible master: [WIP] Add Ansible 5 aka core 2.12 support https://review.opendev.org/c/openstack/kolla-ansible/+/819135 | 15:52 |
* yoctozepto does not use kayobe but mgoddard's monologue is sensible | 15:52 | |
mnasiadka | mgoddard: I remember we spoke about moving some tasks to separate role than baremetal (e.g. docker) | 15:53 |
mgoddard | the reason I bring this here today is to find out whether there is interest in sharing this code between kolla-ansible and kayobe | 15:53 |
mnasiadka | But I'm worried about copy'ing - e.g. maintaining it in both places - maybe we should create a ,,Kolla'' Galaxy collection? | 15:53 |
mgoddard | or should I just copypasta | 15:53 |
yoctozepto | mgoddard: copypasta sounds bad | 15:53 |
mgoddard | I think a kolla collection would be ideal, it's just whether we want to create and maintain that thing | 15:54 |
yoctozepto | what is your plan about sharing the code? could we standardise something? | 15:54 |
psuedo | o/ | 15:54 |
mgoddard | it would also be a bit more effort to make the code work in both codebases | 15:54 |
yoctozepto | hmm, but then again; what does a collection bring over being in kolla-ansible? | 15:54 |
yoctozepto | I mean, except for distribution :D | 15:55 |
mgoddard | well, what it brings to k-a is benefitting from me spending some time on it | 15:55 |
mnasiadka | Well, I think we can't just leave it in kolla-ansible repo and distribute it to kayobe in the same time? ;-) | 15:56 |
mgoddard | I probably wouldn't keep the two in sync if each had a copy | 15:56 |
yoctozepto | mnasiadka: does not kayobe install kolla-ansible? | 15:56 |
mnasiadka | yoctozepto: in a kolla-ansible venv | 15:56 |
mnasiadka | (separate from kayobe venv) | 15:56 |
yoctozepto | yeah, but, as I said, what's the difference except for distribution means? | 15:57 |
mgoddard | I see your point, yoctozepto | 15:57 |
mgoddard | it could probably be made to work by fudging the role path | 15:57 |
mgoddard | I would be a bit concerned about changes to the role breaking kayobe | 15:58 |
frickler | could add a cross-project job for that? | 15:59 |
yoctozepto | ^ precisely | 15:59 |
mgoddard | we could, and only trigger it on changes to the role | 15:59 |
yoctozepto | I mean, best to integrate closely | 15:59 |
yoctozepto | collection could be trickier in fact | 15:59 |
mgoddard | what'why the resistance to the collection? | 15:59 |
mnasiadka | tricker for kolla-ansible (we would need to add support for that) | 15:59 |
mgoddard | s/what'// | 15:59 |
mnasiadka | in kayobe that's a standard | 16:00 |
yoctozepto | mgoddard, mnasiadka: can we test with in-flight/depends-on patches and a collection? | 16:00 |
yoctozepto | if yes, then it's no brainer and let's just go collection :-) | 16:00 |
mgoddard | sure, if it's maintained in opendev | 16:00 |
mgoddard | we have talked about using ansible-core and collections for kolla-ansible before | 16:01 |
mnasiadka | yup | 16:01 |
mnasiadka | so a collection it is? | 16:02 |
yoctozepto | ok, then it all makes sense to me | 16:02 |
yoctozepto | yeah, seems so | 16:02 |
opendevreview | Doug Szumski proposed openstack/kolla-ansible master: Support copying static Vendordata file into Nova API container https://review.opendev.org/c/openstack/kolla-ansible/+/819140 | 16:02 |
mgoddard | #link https://review.opendev.org/c/openstack/kayobe/+/818290 | 16:03 |
mgoddard | that's the initial PoC | 16:03 |
mnasiadka | ok then | 16:04 |
mnasiadka | mgoddard: will you handle the addition repo creation and creating a collection? | 16:04 |
mgoddard | I will | 16:05 |
mnasiadka | Ok then, seems like another priority for Yoga, initiated on Kayobe side, but affecting Kolla-Ansible | 16:05 |
mnasiadka | And I think we went a bit over time. | 16:06 |
mnasiadka | Thanks for the meeting :) | 16:07 |
mnasiadka | #stopmeeting | 16:07 |
mnasiadka | #endmeeting | 16:07 |
opendevmeet | Meeting ended Wed Nov 24 16:07:07 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:07 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/kolla/2021/kolla.2021-11-24-15.01.html | 16:07 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/kolla/2021/kolla.2021-11-24-15.01.txt | 16:07 |
opendevmeet | Log: https://meetings.opendev.org/meetings/kolla/2021/kolla.2021-11-24-15.01.log.html | 16:07 |
mnasiadka | egh | 16:07 |
yoctozepto | #stopallthemeetings | 16:07 |
yoctozepto | thanks mnasiadka for chairing :-) | 16:07 |
mgoddard | mnasiadka: btw I'm updating hte meetings doc | 16:08 |
opendevreview | Pierre Riteau proposed openstack/kayobe master: Build overcloud host image directly with DIB https://review.opendev.org/c/openstack/kayobe/+/772609 | 16:08 |
opendevreview | Mark Goddard proposed openstack/kolla master: docs: weekly meetings page https://review.opendev.org/c/openstack/kolla/+/815494 | 16:08 |
mnasiadka | mgoddard: ok, then I'll not update it ;) | 16:09 |
opendevreview | Michal Nasiadka proposed openstack/kolla-ansible master: openvswitch: move from docker exec to openvswitch_db https://review.opendev.org/c/openstack/kolla-ansible/+/819143 | 16:14 |
opendevreview | Pierre Riteau proposed openstack/kayobe master: Build overcloud host image directly with DIB https://review.opendev.org/c/openstack/kayobe/+/772609 | 16:21 |
opendevreview | Pierre Riteau proposed openstack/kayobe master: Build overcloud host image directly with DIB https://review.opendev.org/c/openstack/kayobe/+/772609 | 17:23 |
hrw | INFO:kolla.common.utils.nova-base:INFO: This is taking longer than usual. You might need to provide the dependency resolver with stricter constraints to reduce runtime. If you want to abort this run, you can press Ctrl + C to do so. To improve how pip performs, tell us what happened here: https://pip.pypa.io/surveys/backtracking | 17:32 |
hrw | INFO:kolla.common.utils.nova-base:INFO: pip is looking at multiple versions of oslo-upgradecheck to determine which version is compatible with other requirements. This could take a while. | 17:33 |
hrw | hm.. | 17:33 |
hrw | and this 'a while' is long | 17:33 |
yoctozepto | mgoddard, mnasiadka: ansible-core 2.12 seems worky with k-a :-) | 17:46 |
yoctozepto | ~> https://review.opendev.org/c/openstack/kolla-ansible/+/819135 | 17:46 |
opendevreview | Radosław Piliszek proposed openstack/kolla-ansible master: CI: Test minimum and maximum supported ansible versions https://review.opendev.org/c/openstack/kolla-ansible/+/817925 | 17:49 |
opendevreview | Radosław Piliszek proposed openstack/kolla-ansible master: [WIP] Add Ansible 5 aka core 2.12 support https://review.opendev.org/c/openstack/kolla-ansible/+/819135 | 17:50 |
*** amoralej is now known as amoralej|off | 17:51 | |
opendevreview | Radosław Piliszek proposed openstack/kolla-ansible master: [DNM] Fully test new Ansible https://review.opendev.org/c/openstack/kolla-ansible/+/819152 | 17:52 |
hrw | ok, restart helped | 17:59 |
opendevreview | Radosław Piliszek proposed openstack/kolla-ansible stable/wallaby: Specify log file name for Nova API https://review.opendev.org/c/openstack/kolla-ansible/+/817059 | 18:04 |
hrw | meh. | 18:15 |
hrw | pip lacks some good way to check which package requires other | 18:16 |
hrw | nova -> pypowervm -> futures | 18:17 |
hrw | and futures is py2/3 | 18:17 |
hrw | and futures is py2, pypowervm is py2/3 | 18:18 |
hrw | and pypowervm needs futures only on python 3.6 | 18:20 |
hrw | https://github.com/powervm/pypowervm/pull/17 so removing it is in progress | 18:23 |
hrw | uf | 18:23 |
hrw | once that done centos source builds should be quick again | 18:27 |
* hrw out | 18:29 | |
opendevreview | Merged openstack/kolla-ansible stable/xena: Specify log file name for Nova API https://review.opendev.org/c/openstack/kolla-ansible/+/818905 | 19:27 |
opendevreview | Merged openstack/kolla-ansible stable/victoria: Specify log file name for Nova API https://review.opendev.org/c/openstack/kolla-ansible/+/818906 | 19:27 |
daryll | Hi Folks. I'm setting up my first cluster. I've got a 1 control & 1 compute and everything seems to deploy. When I run my test instance, it can't allocate a port. Digging into ovs ports, I think the tunnel may not be setup between the nodes. Any ideas? | 19:47 |
gueswhat | guys? is not possible to install kolla without ip assigned to interface for external neutron interface ? thats weird, why do i need to assign ip to that interface at the first place .... ( rabbitmq will fail ... ERROR: epmd error for host openstack: address (cannot connect to host/port) ) | 21:54 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!