| *** ysandeep|out is now known as ysandeep | 05:55 | |
| admin1 | morning | 07:30 |
|---|---|---|
| *** ysandeep is now known as ysandeep|afk | 08:17 | |
| rohit02 | hi team,could you please help me with document for openstack ansible installation on baremetal instead of lxc-container.what changes do i need? | 08:51 |
| noonedeadpunk | rohit02: just a sec | 09:00 |
| noonedeadpunk | you need to set `no_containers: true` on openstack_user_config: https://opendev.org/openstack/openstack-ansible/src/branch/master/etc/openstack_deploy/openstack_user_config.yml.aio.j2#L46 | 09:01 |
| noonedeadpunk | I think in this case you can also skip defining provider_networks | 09:01 |
| noonedeadpunk | and just define neutron variables isntead | 09:01 |
| rohit02 | noonedeadpunk:Thanx for sharing the info | 09:33 |
| *** ysandeep|afk is now known as ysandeep | 10:42 | |
| gokhanisi | hi folks, I am trying to achieve following https://paste.openstack.org/show/b9xvAtn4uxbbMSxBPmdW/. how can I seperate cloud admin and domain admin? Do I need to modify keystone policies? | 11:35 |
| noonedeadpunk | gokhanisi: well, it depends on version of openstack you're using. as iirc starting with Yoga, polices are already adjusted to understand system-scopes | 12:22 |
| gokhanisi | noonedeadpunk, I am using Victoria | 12:23 |
| noonedeadpunk | though still not for all services. At very least heat is troublesome | 12:23 |
| noonedeadpunk | there's huge work being done lately to improve rbac | 12:23 |
| noonedeadpunk | there's selected community goal, that I think done 85% now for projects: https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html | 12:24 |
| noonedeadpunk | like check system personas vs domain vs project here https://docs.openstack.org/keystone/latest/admin/service-api-protection.html#system-personas | 12:25 |
| noonedeadpunk | but before Y i think the only way to get same achieved is really massive adjustments of policies | 12:26 |
| noonedeadpunk | So if you need that functionality I'd really consider checking out Yoga first, as upgrade might be way simpler and easier then messing up with policies, and then with upgrade review all of them and if they not interfere with new scopes | 12:27 |
| noonedeadpunk | As matter of fact we did upgrade from V to X directly and it was quite smooth, except nova part (we had to manually update rpc version in database as otherwise nova conductor and compute were failing because of chicke-egg) but it is likely fixed already | 12:29 |
| mgariepy | hmm interesting. | 12:31 |
| mgariepy | V to X :D | 12:31 |
| gokhanisi | thanks noonedeadpunk, the best option seems trying this after upgrade yoga. Firsly check it on devstack. I am planning to upgrade my env asap | 12:32 |
| noonedeadpunk | you can also check on aio :D | 12:32 |
| noonedeadpunk | but yeah, devstack will also work | 12:33 |
| mgariepy | aio is better :D | 12:33 |
| noonedeadpunk | ^ | 12:33 |
| noonedeadpunk | mgariepy: yeah, we always jumping through releases. And now it's supported behaviour, but the problem is we've chosen "unlucky" release, as first supported upgrade through release will be Y -> AA. So we need either to do X->Y->AA or X->AA and I'm a bit scared about last option noe | 12:34 |
| noonedeadpunk | *now | 12:34 |
| noonedeadpunk | might be because nobody know what will be in AA now | 12:35 |
| mgariepy | i did a jump only once. | 12:35 |
| mgariepy | back in kilo... | 12:35 |
| mgariepy | but i guess i'll try the V > X > Y > AA or V > W > Y > AA | 12:36 |
| gokhanisi | ok, noonedeadpunk aio is better but now I have a ready devstack machine so choose firstly check it on devstack :) | 12:37 |
| noonedeadpunk | I'm inclined to do X>AA tbh. ENOTIME for other options. But I'm really not sure right now about OS support and more interestingly Python version support. As on Y our 22.04 support is experimental for reasons | 12:38 |
| noonedeadpunk | and AA now marked for python 3.10 minimum | 12:39 |
| noonedeadpunk | But I will check this out with TC today I believe | 12:39 |
| frickler | ftr Y->AA isn't guaranteed to work yet, it's just experimental. AA->CC will be the first official SLURP | 12:39 |
| noonedeadpunk | yes, that's true. But we still want to add grenade jobs, right? | 12:42 |
| noonedeadpunk | So basically we need to preserve some OS that will be supported between Y and AA anyway | 12:42 |
| noonedeadpunk | (and python version) | 12:42 |
| frickler | yes, that's part of the experiment. | 12:42 |
| noonedeadpunk | so basically we need to run granade either on focal or on jammy. | 12:43 |
| noonedeadpunk | and I guess that's the thing that I'm not sure about, as jammy was released after Yoga | 12:50 |
| noonedeadpunk | And projects hardly tested it I guess. So more logical to have focal grenade job for N+2 | 12:51 |
| frickler | so that would mean that projects would need to keep ensuring py38 is working. or move from py38 to py39 on focal? | 14:09 |
| *** ysandeep is now known as ysandeep|dinner | 14:19 | |
| noonedeadpunk | Well, keeping py38 likely easier then backporting py3.10 to Y? | 14:34 |
| *** dviroel_ is now known as dviroel | 14:55 | |
| *** ysandeep|dinner is now known as ysandeep | 15:18 | |
| *** ysandeep is now known as ysandeep|out | 15:33 | |
| prometheanfire | looks like 22.04 support for Z won't make it? | 18:39 |
| noonedeadpunk | prometheanfire: we have already experimental support of 22.04 for Y | 19:52 |
| noonedeadpunk | I think major issue there right now is ceph support | 19:52 |
| noonedeadpunk | other then that it should be fine to try out | 19:53 |
| *** dviroel is now known as dviroel|biab | 19:55 | |
| prometheanfire | ya, saw the experimentalness of it, also, using ceph :P | 20:14 |
| *** dviroel|biab is now known as dviroel | 20:51 | |
| *** dviroel is now known as dviroel|afk | 21:33 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!