Earlier  
Posted Nick Remark
#openstack-nova - 2020-11-11
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
14:37:00 dansmith gibi: if packages or deployment tools want to make something natively work if everything is on the same machine, separating things into config files and passing them on the command line is fine and well within their scope
14:37:03 stephenfin gibi: That was me. It makes more sense, IMO. The entire behavior of the command shouldn't change because of a boolean flag
14:37:11 stephenfin Like 'server show --diagnostics' :-(
14:37:24 owalsh dansmith: that's the plan IIUC
14:37:31 dansmith cool
14:37:35 dansmith now I can get coffee.
14:37:49 owalsh dansmith: but can't fail hard in nova-compute till that's done
14:38:13 gibi dansmith: so we might need to delay merging https://review.opendev.org/#/c/762176/ as it would break more than one deployment engine. As it seems debian also uses a shared nova.conf in the all-in-one-case
14:39:33 gibi stephenfin: I don't say that we should bring back --confirm
14:39:50 stephenfin oh, I know. I'm just explaining my rationale for that change
14:40:08 stephenfin i.e. don't hate me for it :-)
14:40:17 gibi stephenfin: is there a generic problem with this positional argment place used as subcommand name in general
14:40:25 gibi in osc?
14:40:33 dansmith gibi: okay, I'll throw my support on there for it and let you move it forward when appropriate
14:40:51 gibi dansmith: ack. I will summarize the whole thing in an ML post
14:41:04 gibi just to get more attention from the deployer engines
14:41:12 stephenfin gibi: Not really. I mean, if someone hit this corner case I think they could escape the positional arguments
14:41:27 stephenfin e.g. 'openstack server resize -- confirm'
14:41:34 stephenfin (not tested though)
14:41:47 stephenfin I'm sure someone will report the issue if it's really a big deal :-)

Earlier   Later