| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-11-11 | |||
| 13:14:36 | owalsh | and docs I expect | |
| 13:15:12 | owalsh | sean-k-mooney: can we use something other than CONF.api_database_connection to determine the cell scope? | |
| 13:15:36 | sean-k-mooney | not really | |
| 13:15:49 | sean-k-mooney | we could but i dont think we should | |
| 13:16:15 | sean-k-mooney | from a donwstream point of view we shoudl be fixing this in osp 13 as well | |
| 13:16:31 | sean-k-mooney | certenly in 16.1/16.2 | |
| 13:17:01 | owalsh | sean-k-mooney: yea, not concerned about this in tripleo, it's the other use cases | |
| 13:17:33 | sean-k-mooney | we had agreed not to block this in stable by the way | |
| 13:17:40 | tkajinam | my concern here would be that this is now breaking puppet jobs because we need new config file structure to start nova services in a single node | |
| 13:17:44 | sean-k-mooney | we are only going to make it a hard error on master/wallabyt | |
| 13:17:53 | sean-k-mooney | so packages have all of wallaby to update | |
| 13:18:21 | sean-k-mooney | we are going to backprot the patch below it which logs a warning to stable | |
| 13:20:01 | tkajinam | you mean that you will add some fall back mechanism ? | |
| 13:20:06 | sean-k-mooney | tkajinam: we could potentially delay merging the blocker patch a few week to give puppet-nova some time to update it be i think we should still merge it this cycle without a deprecation notice since it has not been supprot for a very long time but we can add an upgrade warning | |
| 13:20:14 | sean-k-mooney | its already proposed | |
| 13:20:50 | sean-k-mooney | https://review.opendev.org/#/c/762175/1/nova/utils.py | |
| 13:21:28 | sean-k-mooney | the bottom ptach catches the db not allowed excption and converts it to a warning. then does the local cell lookup | |
| 13:21:37 | tkajinam | from puppet perspective we need to know how distros change their default file structure | |
| 13:21:43 | sean-k-mooney | owalsh: tkajinam | |
| 13:21:52 | tkajinam | sean-k-mooney, yeah. that's what I exactly expected | |
| 13:22:09 | sean-k-mooney | right so that is goign to be backported to stable | |
| 13:22:16 | owalsh | sean-k-mooney: ack | |
| 13:22:21 | sean-k-mooney | ast patch will only be on master | |
| 13:22:33 | sean-k-mooney | * the last | |
| 13:22:52 | owalsh | sean-k-mooney: hard fail can't merge till rpms/debs/puppet are updated | |
| 13:23:09 | sean-k-mooney | well on the deb front its not using nova.conf | |
| 13:23:18 | sean-k-mooney | https://salsa.debian.org/openstack-team/services/nova/-/blob/debian/victoria/debian/nova-compute.init.in | |
| 13:23:33 | sean-k-mooney | the only deamon arge is nova-compute.conf | |
| 13:23:44 | sean-k-mooney | we wont use nova.conf if that is passed | |
| 13:23:50 | owalsh | but does it exists? | |
| 13:23:52 | tkajinam | what happens if /etc/nova/nova-compute.conf does not exist ? | |
| 13:23:57 | sean-k-mooney | it would only fall backk to nova.conf if its not there | |
| 13:24:05 | tkajinam | I guess nova picks up /etc/nova/nova.conf by default | |
| 13:24:31 | sean-k-mooney | so by default it will use policy in code, then nova.conf if nova-compute.conf is not there | |
| 13:24:44 | sean-k-mooney | * default in code not policy | |
| 13:25:01 | tkajinam | the question here would be whether nova-compute.conf is created by default when we install nova-compute package. | |
| 13:25:24 | tkajinam | sean-k-mooney, yeah I remember there is a logic to search some files... | |
| 13:25:44 | sean-k-mooney | not search | |
| 13:25:55 | tkajinam | oops, sorry | |
| 13:25:56 | sean-k-mooney | nova will use nova.conf if its in /etc/nova/ | |
| 13:26:08 | sean-k-mooney | if you pass a config file it only looks at that | |
| 13:26:30 | sean-k-mooney | so there is a default file location that we check otherwise you have to say where it is | |
| 13:26:56 | tkajinam | by --config-file option in the command line | |
| 13:27:02 | sean-k-mooney | yep | |
| 13:27:19 | gibi | sean-k-mooney: the default file search algo is in oslo.config https://github.com/openstack/oslo.config/blob/68cefad313bd03522e99b3de95f1786ebea45d4b/oslo_config/cfg.py#L281 | |
| 13:27:51 | sean-k-mooney | oh | |
| 13:27:53 | sean-k-mooney | so https://github.com/openstack/oslo.config/blob/68cefad313bd03522e99b3de95f1786ebea45d4b/oslo_config/cfg.py#L293-L298 | |
| 13:28:13 | sean-k-mooney | ok so it check a cople of other location byu default | |
| 13:28:18 | sean-k-mooney | for the nova.conf | |
| 13:28:19 | tkajinam | ahh yeah | |
| 13:28:34 | tkajinam | that's what I used to check | |
| 13:29:45 | sean-k-mooney | so i think the path forward is to merge and backport the first 2 patch and send a mail to the list that we intend to merge the last one but delay it till say m1 or m2 | |
| 13:30:09 | sean-k-mooney | to give packagers and installers time to catch up on there grizzly homework | |
| 13:30:43 | gibi | I can summarize this to an ML post | |
| 13:30:54 | tkajinam | lol, but indeed > grizzly homework | |
| 13:32:30 | tkajinam | once packaging team publishes the change for that then I'll update puppet-nova . | |
| 13:32:55 | tkajinam | but I'm a bit concerned with some feedback about this hard requirement since it can affect some existing deployments. | |
| 13:33:15 | sean-k-mooney | it should only affect them on upgrade though | |
| 13:33:42 | tkajinam | agreed | |
| 13:33:55 | sean-k-mooney | if they are using an installer i dont think most will see it | |
| 13:34:06 | sean-k-mooney | kolla has fixed this since queens | |
| 13:34:22 | sean-k-mooney | we can fix ooo im not sure what osc does | |
| 13:34:49 | sean-k-mooney | * osa not osc | |
| 13:35:16 | sean-k-mooney | so osa and charms would be the two other major installer to update | |
| 13:35:17 | tkajinam | I think it depends on the architecture they support | |
| 13:35:35 | tkajinam | if they support collocation of nova-api and nova-compute then they should create a separated file | |
| 13:35:44 | sean-k-mooney | well not really in that you jsut need a different config | |
| 13:35:47 | sean-k-mooney | yep | |
| 13:36:01 | sean-k-mooney | most contaierised installer shoudl be creating a seperate file per contaienr already | |
| 13:36:27 | sean-k-mooney | so in those cases it can continue to be called nova.conf if they like | |
| 13:37:10 | sean-k-mooney | the best pratcie for such installs is to allway bind mount in your config externally or via something like a k8s config map | |
| 13:44:38 | sean-k-mooney | so this is the problematic line in the current deb files https://salsa.debian.org/openstack-team/services/nova/-/blob/debian/victoria/debian/nova-common.postinst.in#L189 | |
| 13:45:11 | tkajinam | gibi, thx. would be nice if we can have some discussions triggered by that | |
| 13:45:15 | sean-k-mooney | and https://salsa.debian.org/openstack-team/services/nova/-/blob/debian/victoria/debian/nova-common.postinst.in#L220-225 | |
| 13:46:24 | sean-k-mooney | although that will not run on install jsut configure and reconfigure | |
| 13:47:14 | sean-k-mooney | anyway i better go do something else for a while | |
| 13:47:59 | tkajinam | that looks like a step needed only in controller nodes | |
| 13:48:20 | tkajinam | but I'm not so familiar with debian stuffs that I can say some options here :-P | |
| 13:49:18 | sean-k-mooney | ya same personally i really dislike both deb and rpm way of sepcifying things. im vaugly familar with both but find both equally off putting to learn more about them | |
| 14:07:20 | gibi | stephenfin: what is the way to shelve offload a server via openstack client? (now I force myself to always use osc) | |
| 14:24:02 | stephenfin | gibi: oh, that's a gap | |
| 14:24:10 | stephenfin | you've got shelve but not offload | |
| 14:24:15 | stephenfin | I'll add it :-) | |
| 14:24:16 | gibi | at least I did not find it | |
| 14:24:25 | gibi | stephenfin: thanks! | |
| 14:30:35 | stephenfin | gibi: Does 'openstack server offload' make sense, or should I go with 'openstack server shelve offload' like novaclient? | |
| 14:30:37 | stephenfin | I think the latter is a bit confusing because it suggests it both shelves and offloads, as opposed to offloading an already shelved instance | |
| 14:30:45 | stephenfin | However, maybe the former is missing context too? | |
| 14:31:09 | gibi | hm | |
| 14:31:54 | gibi | it is similar to openstack server resize confirm | |
| 14:32:05 | gibi | so I would go with opentack server shelve offload | |
| 14:32:08 | stephenfin | that's a good point | |
| 14:32:18 | stephenfin | server shelve offload it is | |
| 14:32:21 | gibi | :) | |
| 14:34:25 | dansmith | gibi: I haven't fully caught up, but I do _not_ want to have multiple configs for different services | |
| 14:34:36 | dansmith | gibi: glance has multiple configs for different reasons and it's a nightmare, IMHO | |
| 14:34:56 | stephenfin | I really wish we could use hyphens. 'server-resize confirm' makes way more sense to me | |
| 14:35:02 | gibi | dansmith: I would also not make a different config just to support all-in-one deployments | |
| 14:35:56 | gibi | stephenfin: we have openstack server resize --confirm but that is deprecated in favor of server resize confirm | |
| 14:36:14 | dansmith | gibi: definitely | |