noonedeadpunk | mornings | 08:49 |
---|---|---|
noonedeadpunk | so about skyline... | 08:49 |
noonedeadpunk | I was thinking during the nigh about that, and I guess we have 2 options kinda. Either install skyline-console from the pypi, as I see they do upload relevenat content there, or do build with yarn | 08:49 |
noonedeadpunk | and if we do build - should we do that on skyline hosts, or maybe utilize repo for storing static content... | 08:50 |
noonedeadpunk | (and building it) | 08:50 |
noonedeadpunk | as anyway we somehow need to build it once and distribute after | 08:50 |
noonedeadpunk | or build it with yarn and then get wheels out of this.... | 08:53 |
jrosser | morning | 08:57 |
jrosser | so when i looked at doing the source build, it was extremely slow and it also used a really large amount of ram | 08:58 |
jrosser | but it does seem that there are not particularly frequent releases of skyline-console to pypi, and being able to build from source with fixes applied is really a huge bonus, imho | 08:59 |
noonedeadpunk | yeah | 09:12 |
noonedeadpunk | so maybe we should do both.... | 09:12 |
noonedeadpunk | as like for metal deployment, I would kinda hate having all that mess around | 09:13 |
opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Switch service repos to track 2024.1 https://review.opendev.org/c/openstack/openstack-ansible/+/914188 | 09:18 |
noonedeadpunk | but yes, it was super slow on building.... | 09:19 |
ThiagoCMC | About building Python projects, and other projects as well. I'm curious... Have you folks considered building regular Debian packages? Perhaps maintaining Ubuntu PPA repositories? For example, it's fairly easy to make a Debian package out of a Python project with stdeb. | 09:26 |
ThiagoCMC | Morning! =P | 09:26 |
noonedeadpunk | no, why | 09:28 |
ThiagoCMC | To avoid building things locally mid-deployments? | 09:29 |
noonedeadpunk | there're distro maintainers who do that | 09:29 |
noonedeadpunk | so... what's bad in that? | 09:29 |
noonedeadpunk | I mean, back in the days we builded all together at the very beginning, but it was a disaster, as each project that failed building was failing all rest | 09:30 |
noonedeadpunk | and also building python wheels is not the same as do packaging | 09:30 |
noonedeadpunk | and make it reliable cross-distro | 09:30 |
noonedeadpunk | and care about both deb, rpm and whatever else | 09:31 |
noonedeadpunk | and again - this is pretty much done by uca/rdo already | 09:31 |
noonedeadpunk | and then - the only official opensatck deliverable are python packages as of today | 09:33 |
noonedeadpunk | that is what under governance. | 09:34 |
noonedeadpunk | I think, we could actually have some logic to just install from pypi without a need of having wheels build, when SHAs are checked out to some tag rather then SHA | 09:35 |
noonedeadpunk | so, out of https://github.com/jrosser/openstack-ansible-os_skyline/commit/82b1f5a5e6eff9df441c96677e0aa6d578bc8552#diff-7ae20663f88c2ee2e49e28cecf7c0eeb99efdb53ec0faf27c0a50ce3dcaf2370 we indeed can install yarn at least from distro repos. we don't need to get it through nvm at least... | 09:41 |
noonedeadpunk | it's in default repo for ubuntu and in epel for EL | 09:41 |
noonedeadpunk | so, building skyline through yarn took ~300s in my aio | 09:45 |
jrosser | did you watch the memory usage during that? | 09:46 |
noonedeadpunk | cpu only.... | 09:46 |
noonedeadpunk | and it was one core thing | 09:46 |
noonedeadpunk | also, I was able to build them for specific path, ie /skyline | 09:47 |
noonedeadpunk | pretty much question I'm wondering now, if it's worth trying to have static files just on repo container, or get wheels and install to skyline... | 09:49 |
jrosser | we can make a tgz if thats simpler | 09:49 |
noonedeadpunk | I guess what I'm thinking about now, that nginx is quite nice for serving static files due to caching | 09:50 |
noonedeadpunk | so if we wanna get rid of nginx on skyline hosts - better to rely less on them? dunno | 09:50 |
noonedeadpunk | but I don't really like idea of jsut serving skyline from repo. that sounds messy | 09:52 |
noonedeadpunk | you'll get quite surprise if decide to rebuild repo as quite "stateless" thing | 09:53 |
noonedeadpunk | yeah, ok | 09:53 |
noonedeadpunk | maybe we indeed don't need to involve repo at all and you're right here | 09:54 |
noonedeadpunk | just archive/synchornize | 09:55 |
jrosser | we can do the build on the repo perhaps and bundle up a tar file or something | 09:55 |
jrosser | becuase always there will be the issue to store the built stuff somewhere and distribute it to N skyline hosts | 09:55 |
noonedeadpunk | yeah | 09:56 |
noonedeadpunk | that's why I thought about wheels at the first place - I guess it should be possible to just define a local path through file:// or smth instead of git | 09:56 |
jrosser | ah well we could always just have a different path under /var/www/repo for this | 09:57 |
jrosser | alongside the python build | 09:57 |
noonedeadpunk | yeah | 09:57 |
noonedeadpunk | and that's where I was - we can just point proxypass to repo from skyline nginx :D | 09:58 |
jrosser | hah lets not do that :) | 09:58 |
noonedeadpunk | that was terrible idea :F | 09:58 |
noonedeadpunk | s/F/D | 09:58 |
* noonedeadpunk spent quite some time downstream lately lol | 09:59 | |
noonedeadpunk | ok, will come up with smth shortly | 10:00 |
noonedeadpunk | I have 1 thing about https://review.opendev.org/q/topic:%22osa/messaging_improvements%22 I was not sure about if it's worth doing or not | 10:01 |
noonedeadpunk | specifically - if it's worth defining a variable to define notification topics to be in-use | 10:01 |
noonedeadpunk | and do that for all roles more or less | 10:01 |
noonedeadpunk | as what I've spotted was some weird things in roles like neutron | 10:02 |
noonedeadpunk | https://opendev.org/openstack/openstack-ansible-os_neutron/src/branch/master/templates/neutron.conf.j2#L256-L263 | 10:02 |
noonedeadpunk | from one side - this close to never gonna be overriden | 10:03 |
noonedeadpunk | from other, for things using deisgnate, like nova it looks even more weird | 10:03 |
noonedeadpunk | https://opendev.org/openstack/openstack-ansible-os_nova/src/branch/master/templates/nova.conf.j2#L48-L55 | 10:04 |
noonedeadpunk | at the end I decided to leave this thing alone, but dunno | 10:05 |
noonedeadpunk | I was checking on billing panels like fleio, which require ceilometer but also rely on notifications | 10:05 |
noonedeadpunk | they don't need to have different topics as they define a pool | 10:06 |
noonedeadpunk | but I can imagine something that wants both things to work and just consume different topics... | 10:06 |
noonedeadpunk | anyway | 10:06 |
jrosser | andrewbonney: do you have any thoughts on the notiifcations topic there ^^ | 10:38 |
jrosser | we possibly use some of these for the usage stats? | 10:39 |
noonedeadpunk | any thought on how to detect resulting wheel name? :D | 11:14 |
noonedeadpunk | maybe indeed packing as tar is easier after all.... | 11:14 |
noonedeadpunk | just thinking on how to avoid build during each time and detect if it's needed or not | 11:17 |
*** jamesdenton__ is now known as jamesdenton | 12:32 | |
jamesdenton | o/ | 12:34 |
noonedeadpunk | \o/ | 12:48 |
andrewbonney | re: notifications, we're using the default 'notifications' topic but nothing custom that I can see | 14:10 |
noonedeadpunk | andrewbonney: and you don't have ceilometer installed? | 14:22 |
andrewbonney | We do have it installed, but in a minimal fashion, we're only using the notifications agent, not any of the polling parts | 14:26 |
andrewbonney | And we only have Nova notifications enabled | 14:26 |
noonedeadpunk | I guess my question was a bit towards - if it might be important to have variable to enable notifications, but keep ceilometer group empty | 14:28 |
noonedeadpunk | as this what defines globally if notifications should be sent at all | 14:29 |
noonedeadpunk | but yah, I see | 14:29 |
noonedeadpunk | #startmeeting openstack_ansible_meeting | 15:00 |
opendevmeet | Meeting started Tue Mar 26 15:00:12 2024 UTC and is due to finish in 60 minutes. The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
opendevmeet | The meeting name has been set to 'openstack_ansible_meeting' | 15:00 |
noonedeadpunk | #topic rollcall | 15:00 |
noonedeadpunk | o/ | 15:00 |
jamesdenton | o/ | 15:03 |
noonedeadpunk | #topic office hours | 15:05 |
noonedeadpunk | first of all - I've seen there's a NTTData folk asking for AIO help in ML | 15:05 |
noonedeadpunk | I saw that but didn't have time to reply, so mostly bringing this in as a reminder :) | 15:05 |
noonedeadpunk | since yesterday I had quite some progress on logic building skyline with yarn | 15:06 |
jamesdenton | Saw that this morning, but i think an AIO in AWS might not give them the output they're looking for. | 15:06 |
noonedeadpunk | I haven't read their current issue... | 15:06 |
jamesdenton | Nice! Not sure if you saw jrosser's original commit, but it had yarn bits | 15:06 |
jrosser | i did see that and i thought there was confusion about AWS not allowing vlans | 15:07 |
jrosser | but afaik inside an AIO that should be completely OK | 15:07 |
NeilHanlon | o/ | 15:10 |
noonedeadpunk | o/ | 15:10 |
noonedeadpunk | Actually question to you NeilHanlon - did you have a chance to check if we still really need lxc-templates-extra? | 15:11 |
noonedeadpunk | jrosser: Yeah, inside AIO perimiter that should be fine indeed | 15:11 |
noonedeadpunk | not really if they want to extend inside AIO though | 15:12 |
jrosser | yes, indeed | 15:12 |
NeilHanlon | i didn't get a chance to check on that, no :( | 15:14 |
jamesdenton | noonedeadpunk FWIW that EC2 thread is an extension of a thread you're on already @ [Bobcat][Ansible][AIO] how to inspect lxc logs | 15:16 |
noonedeadpunk | Yeah, I just didn't had a chance to read through carefully their reply :( | 15:17 |
NeilHanlon | i'm adding it back to my todos... i lost it somewhere | 15:17 |
noonedeadpunk | sure, no worries :) | 15:17 |
noonedeadpunk | today I've also pushed switch to 2024.1 branch, and it looks quite broken right now: https://review.opendev.org/c/openstack/openstack-ansible/+/914188 | 15:18 |
noonedeadpunk | moreover, we need to decide on how we wanna act with inactive projects | 15:19 |
noonedeadpunk | like senlin, murano and sahara | 15:19 |
noonedeadpunk | should we drop playbooks but leave roles? | 15:19 |
noonedeadpunk | should we drop inventory? | 15:19 |
noonedeadpunk | (env.d files) | 15:19 |
jrosser | so i guess it is a question of what we want to happen on new vs existing deployments | 15:20 |
noonedeadpunk | yeah | 15:21 |
jrosser | the smallest change would be to remove the playbook and env.d parts so that these inactive projects do not get into new deployments | 15:21 |
noonedeadpunk | as eventually, I guess we should just keep existing ones using old versions | 15:21 |
noonedeadpunk | while prohibit for new ones | 15:21 |
jrosser | and then existing deployments will be ok, but need a releasenote saying that their project X is no longer updated and deployers need to decide if to keep or remove it | 15:22 |
noonedeadpunk | but that means we should keep SHAs to..... to what? | 15:22 |
noonedeadpunk | or just drop them and let them install from master? | 15:22 |
jrosser | if we remove the platybook then the installation gets frozen effectively for that service | 15:23 |
noonedeadpunk | also, removing playbook kinda hit me, that then they can't also operate it in any way on old version | 15:23 |
noonedeadpunk | like change config or anything | 15:23 |
jrosser | maybe we are more subtle then and just remove it from setup-openstack | 15:23 |
noonedeadpunk | yeah... | 15:24 |
noonedeadpunk | ok, sounds fair enough - remove env.d, do not branch, remove SHA defenition, remove playbook from setup-openstack | 15:24 |
noonedeadpunk | write reno | 15:25 |
noonedeadpunk | document in contribtor docs | 15:25 |
noonedeadpunk | I will make it as a follow-up tosha bump to 2024.1 | 15:25 |
noonedeadpunk | talking about which - that's the reason: https://zuul.opendev.org/t/openstack/build/27485728c1ef402198e50a05438860ca/log/logs/host/glance-api.service.journal-10-32-01.log.txt#246-256 | 15:26 |
jrosser | that sounds reasonable | 15:26 |
noonedeadpunk | huh, why it even tries sqlite.... | 15:28 |
jrosser | thats the default | 15:29 |
noonedeadpunk | https://opendev.org/openstack/glance/commit/309ca3aec26b6dd49b8d955c4900a5c390d14537 that looks kinda related | 15:29 |
jrosser | https://opendev.org/openstack/glance-specs/src/branch/master/specs/2024.1/approved/glance/centralized-cache-db.rst | 15:30 |
noonedeadpunk | um, okay | 15:32 |
noonedeadpunk | what worker_self_reference_url should be then.... | 15:33 |
noonedeadpunk | Like really backend one on mr-mgmt? | 15:33 |
noonedeadpunk | As I'm afraid it can be exposed to end users? | 15:34 |
noonedeadpunk | feels like would be better idea to implement my_ip or smth instead.... | 15:36 |
noonedeadpunk | as indeed - it feels to be exposed in image metadata? https://opendev.org/openstack/glance/src/branch/master/glance/api/v2/images.py#L287-L307 | 15:37 |
noonedeadpunk | ok, I kinda don't understand that.... | 15:38 |
jrosser | what even is this for | 15:39 |
noonedeadpunk | for direct-import | 15:40 |
noonedeadpunk | https://opendev.org/openstack/glance/src/branch/master/glance/api/v2/images.py#L434-L438 | 15:40 |
noonedeadpunk | so I guess, it assumes that backend is publicly available directly | 15:40 |
noonedeadpunk | rather then be behind LB | 15:40 |
noonedeadpunk | and glance IRC is just dead as well... | 15:44 |
jrosser | this also seems to say that glance api hosts call each other on the backend http interfaces | 15:46 |
noonedeadpunk | I'm also looking at glance, and it feels that we don't really need an RPC for it | 15:50 |
noonedeadpunk | just notifications | 15:50 |
jrosser | before we are out of time i wanted to ask about the unmaintained branches | 15:51 |
noonedeadpunk | sure | 15:51 |
jrosser | they are pretty much totally broken | 15:51 |
noonedeadpunk | they are | 15:51 |
jrosser | and do we want to put any effort into some/any of these? | 15:51 |
noonedeadpunk | We need to merge them without CI and fix on unmaintained I think | 15:51 |
noonedeadpunk | As currently they're trying to pull master dependencies | 15:51 |
noonedeadpunk | since stable were dropped, so zuul just don't know what to pull in | 15:52 |
noonedeadpunk | I;ve spawned Xena locally and it failed just on rabbit then | 15:56 |
jrosser | yeah, i think this was the case before the branch names changed | 15:58 |
noonedeadpunk | yeah | 15:58 |
noonedeadpunk | so feels that Xena is kinda way to go for others | 15:58 |
spatel | I am running Xena and want to upgrade to next possible release :) | 15:59 |
noonedeadpunk | Was going to iterate on that once done with some other things | 15:59 |
noonedeadpunk | #endmeeting | 16:07 |
opendevmeet | Meeting ended Tue Mar 26 16:07:20 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:07 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/openstack_ansible_meeting/2024/openstack_ansible_meeting.2024-03-26-15.00.html | 16:07 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/openstack_ansible_meeting/2024/openstack_ansible_meeting.2024-03-26-15.00.txt | 16:07 |
opendevmeet | Log: https://meetings.opendev.org/meetings/openstack_ansible_meeting/2024/openstack_ansible_meeting.2024-03-26-15.00.log.html | 16:07 |
noonedeadpunk | it's about time spatel :) | 16:07 |
spatel | Should I go to Yoga or Zed from Xena? | 16:08 |
spatel | Any issue with OSA ? | 16:08 |
jrosser | spatel: you've read all about a bunch of the stable branches being renamed from stable/<...> to unmaintained/<...> | 16:09 |
jrosser | this is new openstack-wide policy, not the choice of OSA | 16:10 |
spatel | https://releases.openstack.org/ | 16:10 |
spatel | I am reading them here | 16:10 |
jrosser | yes but the branch names in git are actually changed | 16:10 |
jrosser | which is a total breakage situation for us | 16:10 |
spatel | Hmm! | 16:12 |
spatel | I will give it a try on in LAB first but I have urgency to upgrade from Xena to Zed | 16:12 |
jrosser | if it is urgent / important for you then you should really consider supporting OSA with engineering effort | 16:13 |
jrosser | and i mean not just for this, but in general | 16:13 |
spatel | Yes! agreed and I am here for that. My 2 datacenter running on OSA and new one running on kolla. | 16:14 |
spatel | Last few month I am damn busy in setting up new DC. | 16:14 |
spatel | Give me little time and get out of mess then I will be back to OSA engineering work :) | 16:15 |
opendevreview | Jonathan Rosser proposed openstack/openstack-ansible-os_glance master: Add worker_self_reference_url to glance-cache.conf https://review.opendev.org/c/openstack/openstack-ansible-os_glance/+/914275 | 16:15 |
spatel | noonedeadpunk I have question for you, How are you running multi region datacenter? I meant sharing keystone or totally isolated POD design? | 16:16 |
noonedeadpunk | spatel: I'd say yoga and then antelope | 16:16 |
spatel | Hmm! ok I will setup lab for OSA to upgrade yoga | 16:16 |
noonedeadpunk | spatel: well, depends.... Like current setup does have totaly isolated design and then panel on top managing intial project/user creation across regions | 16:17 |
noonedeadpunk | though looking into keycloack setup, though there're some downfalls with it | 16:17 |
spatel | I see, your portal create account on all the region to keep project name in sync | 16:17 |
jrosser | this all depends what you want to actually achieve through shared/isolated keystone | 16:17 |
noonedeadpunk | spatel: and domain, yes | 16:18 |
noonedeadpunk | as we running multi-domain which is just /o\ with keycloack | 16:18 |
noonedeadpunk | but lately I got quite... nice design in my head I'm eager to try somewhere :D | 16:19 |
spatel | We are planning to open new DC in other region so looking for some idea. | 16:19 |
noonedeadpunk | so idea is, to have "standalone" keystone setup, with stretched galera over DCs | 16:19 |
noonedeadpunk | where each DC will have 1 galera instance and multiple keystone backends | 16:19 |
spatel | I was thinking create some automation to create user/project etc.. on both region and keep them isolated to make upgrade etc.. simple | 16:19 |
noonedeadpunk | internal services will connect to local keystone, users via anycast to closest one | 16:20 |
spatel | noonedeadpunk In stretch design I am always worry about upgrade :( | 16:20 |
noonedeadpunk | keystone does not do very intense writing to galera, so I'm not too concerned.... | 16:21 |
spatel | If all components are isolated then easy to upgrade and no need to worry about dependency | 16:21 |
noonedeadpunk | well, in this design main concern is galera clustering I guss | 16:21 |
jrosser | noonedeadpunk: do you mean have a local galera cluster for the services and a different stretched one just for keystone? | 16:21 |
noonedeadpunk | yes | 16:21 |
jrosser | yeah makes sense | 16:21 |
noonedeadpunk | and was thinking to have arbitrator (garbd) as well | 16:22 |
jrosser | so that should pretty much deal with upgrade troubles | 16:22 |
noonedeadpunk | in case having like 2 or 4 regions - then swapn garbd elsewhere | 16:22 |
noonedeadpunk | (would need to work on that in our role though) | 16:22 |
jrosser | i think we had a situation like that where the entire of everything was 2x redunadancy for keycloak (and happy like that) except for galera which needed 3 | 16:23 |
jrosser | so we had a arbitrator off to the side to fix that | 16:23 |
noonedeadpunk | yeah... | 16:23 |
jrosser | but now with newer keycloak you cant do that and it needs to be 3x everything | 16:23 |
noonedeadpunk | I guess it depends in keycloack is source of truth? | 16:24 |
noonedeadpunk | as if it's some freeipa behind it... | 16:24 |
jrosser | it was more that the clustering thing was changed at some point and 2 was not a good number any more | 16:24 |
noonedeadpunk | well. even numbers of memebers were never great for figuring out split-brains | 16:25 |
NeilHanlon | yeah i do think they stopped allowing the active/standby model and went to 'true' clustering.. or, something along those lines | 16:25 |
noonedeadpunk | ah, ok | 16:25 |
noonedeadpunk | yeah, then it makes sense | 16:25 |
noonedeadpunk | actually, I guess now we can release source_ip balancing for glance ? | 16:27 |
opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Switch service repos to track 2024.1 https://review.opendev.org/c/openstack/openstack-ansible/+/914188 | 16:27 |
jrosser | i saw there was still a switch in there for https on/off based on uwsgi | 16:28 |
jrosser | is that still a thing? | 16:28 |
noonedeadpunk | you mean - if uwsgi still breaks ? :) | 16:28 |
noonedeadpunk | I guess it's not for ceph anymore | 16:28 |
jrosser | https://github.com/openstack/openstack-ansible-os_glance/blob/master/defaults/main.yml#L352-L354 | 16:29 |
noonedeadpunk | but if uwsgi is not used - still no ssl is possible | 16:29 |
noonedeadpunk | we changed the default: https://github.com/openstack/openstack-ansible-os_glance/commit/d0f6fd67cc732f0847b027a2bb136fc8dcde72b1 | 16:29 |
noonedeadpunk | but I guess the switch you've pointed to is still true? | 16:30 |
noonedeadpunk | as it was related to eventlet service not having ssl options | 16:30 |
noonedeadpunk | ok, so the only thing left - how to make yarn build idempotent (detect if its needed or not) | 17:04 |
jamesdenton | Well, i think the yarn build would be dependent on new or changed files being copied in to src/ ? | 17:28 |
jamesdenton | s/would/could | 17:28 |
noonedeadpunk | jamesdenton: well, no... | 17:28 |
noonedeadpunk | as it does change files.... | 17:28 |
noonedeadpunk | so they will be always changed kinda | 17:29 |
jamesdenton | every time you run the build it would regenerate, right? | 17:29 |
noonedeadpunk | yep | 17:29 |
jamesdenton | with a new timestamp in the file names | 17:29 |
noonedeadpunk | but then state of the repo is always "changed" | 17:29 |
noonedeadpunk | or well. | 17:29 |
noonedeadpunk | maybe I'm not getting your idea | 17:29 |
noonedeadpunk | But how to detect from which version it was generated in fact? | 17:30 |
noonedeadpunk | as we need to trigger build each time SHA changes? | 17:30 |
jamesdenton | well, i was considering only running 'build' the first time or in the event of an actual override to the files in the src/ directory - including logos, text, etc. But hadn't given it a ton of thought | 17:31 |
noonedeadpunk | yeah, logic I'm coming up with is really /o\ | 17:54 |
spatel | noonedeadpunk How does shared galera cluster design work between two region? doesn't it lock DB if two different instance try to insert stuff in same DB table? | 18:11 |
ThiagoCMC | It's interesting to see "Current Emerging Technology Projects", like Skyline is being introduced, and sad to see "Current Inactive Projects" especially Senlin. I remember that AutoScaling features moved from Heat to Senlin, and now Senlin is dead... How do you folks play with AutoScaling in OpenStack these days? Also, how to track the "Active Project", or "Active-but-almost-inactive" Projects (trends)? It seems bad to plan long-term | 18:18 |
ThiagoCMC | without looking at the current trends in the OpenStack Components you chose to rely on. | 18:18 |
noonedeadpunk | I guess just stackalytics.io and see trends of contributions.... | 18:22 |
noonedeadpunk | but also - not so active != inactive - it could be just stable :) | 18:23 |
noonedeadpunk | ThiagoCMC: us autoscaling actually dropped from heat? | 18:26 |
noonedeadpunk | I don't see any deprecation notice or anything: https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Heat::AutoScalingGroup | 18:27 |
ThiagoCMC | https://wiki.openstack.org/wiki/Heat/AutoScaling - "There is now a separate autoscaling API project, Senlin." | 18:27 |
noonedeadpunk | well, but that was never dropped from heat I guess? | 18:28 |
noonedeadpunk | not 100% sure | 18:28 |
ThiagoCMC | Not sure lol | 18:28 |
ThiagoCMC | Sad to see Senlin going away, I think it's very cool! | 18:28 |
noonedeadpunk | I thnk Senlin was also tracking metrics to determine WHEN to scale | 18:29 |
noonedeadpunk | and Heat needs to be triggered by smth through webhook | 18:29 |
noonedeadpunk | yeah | 18:29 |
ThiagoCMC | TBH, I've never played with AutoScaling in OpenStack, Ceilometer/AODH/gnocch/etc is too complicated... And Senlin died... | 18:29 |
noonedeadpunk | well, it's not gone yet | 18:29 |
noonedeadpunk | so if there;s any interest - you can step in and return it to active state for the next cycle :) | 18:30 |
ThiagoCMC | :-D | 18:30 |
ThiagoCMC | Sounds like the time is now! | 18:30 |
noonedeadpunk | yeah, indeed | 18:30 |
noonedeadpunk | as basically what is required - to keep track of dependency changes and keep CI passing testing | 18:31 |
noonedeadpunk | so it's not that much work after all | 18:31 |
noonedeadpunk | but if there's no interest from anyone - community project die then... | 18:31 |
noonedeadpunk | (or just hypothetical interest) | 18:31 |
noonedeadpunk | like yeah, it's cool to have that, but is it even used.... | 18:32 |
noonedeadpunk | or even needed in k8s era | 18:32 |
ThiagoCMC | Exactly, k8s seems to be gaining a lot of momentum. | 18:33 |
ThiagoCMC | jrosser, so, here's how I'm deploying OSA AIO 2023.2 with Jammy+Bobcat+Reef (still using Ceph Ansible `stable-7.0`, as you suggested): https://paste.opendev.org/show/bJXKfhUBNstPINNL4xo9/ | 18:35 |
noonedeadpunk | well, we totally should add some vars to control pinning betterin alogned manner | 18:39 |
ThiagoCMC | That would be cool! | 18:40 |
ThiagoCMC | Basically, if I want Ubuntu+UCA (as much as possible), using "distro" everywhere, then, I'd like to disable those APT Pinnings in OSA. | 18:42 |
noonedeadpunk | yeah | 18:44 |
noonedeadpunk | I will try to push couple of patches for that tomorrow | 18:44 |
noonedeadpunk | and will ping you to try them out :D | 18:44 |
ThiagoCMC | You guys are the best. | 18:45 |
jrosser | well we might not want to just remove the pins | 18:47 |
jrosser | we should prefer a particular repo and version | 18:47 |
ThiagoCMC | Sounds better lol | 18:48 |
noonedeadpunk | I said variables to control that | 18:48 |
noonedeadpunk | so yeah, not removing pins, but control them better | 18:48 |
jrosser | ah ok yes | 18:48 |
jrosser | it was kind of emergency fix before so making that more obvious would be great | 18:48 |
noonedeadpunk | sorry if I sounded harsh - didn't mean to | 18:48 |
noonedeadpunk | and also some more vars for mariadb isntallation | 18:49 |
jrosser | ThiagoCMC: I *think* it was UCA that added a new ceph release into an existing Openstack version, something like that | 18:50 |
ThiagoCMC | Yeah, it seems Ceph Reef was late into UCA with Bobcat, bad timing... | 18:51 |
ThiagoCMC | I wanna test that MariaDB from "distro"! =P | 18:52 |
ThiagoCMC | Maybe go with it... | 18:52 |
opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_skyline master: Install skyline-console through yarn https://review.opendev.org/c/openstack/openstack-ansible-os_skyline/+/914405 | 19:54 |
noonedeadpunk | jrosser: jamesdenton so, I came up with that ^ | 19:54 |
noonedeadpunk | tested 3 scenarios locally and they all seem to work: 1 isntall from pypi, build yarn with wheels, build without wheels... | 19:54 |
noonedeadpunk | but a bit /o\ of logic and will hardly recall wtf is going there in a month | 19:55 |
noonedeadpunk | also would be interesting to look at jobs. | 19:57 |
opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible master: [Feature] Add skyline deployment capability https://review.opendev.org/c/openstack/openstack-ansible/+/859446 | 19:57 |
opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_glance master: Add worker_self_reference_url to glance-cache.conf https://review.opendev.org/c/openstack/openstack-ansible-os_glance/+/914275 | 19:59 |
opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_glance master: Add worker_self_reference_url to glance configuration https://review.opendev.org/c/openstack/openstack-ansible-os_glance/+/914275 | 19:59 |
jamesdenton | jrosser i will take a look! | 20:07 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!