Ah, I missed that you said the systems had tags in the title.
Then that explains it. If the machine has a tag that defines kernel options, the global ones aren't used. This is true for both 2.9 and 3.0, so no regression there.
Also, if the machine doesn't have a tag, the global kernel options are used. This is true in both 2.9 and 3.0.
Yes, Alberto changed get_effective_kernel_options(), to not get the default kernel options from the DB config. But get_effective_kernel_options() is always called with the default kernel options as default_kernel_opts, which does get returned if no tags match. Just like in 2.9.
I agree that this is confusing. But considering the are "default" kernel parameters, it implies that you can override it somehow. So I do think the behavior makes sense for 3.0, but at some point we should revisit how we handle kernel parameters.
Ah, I missed that you said the systems had tags in the title.
Then that explains it. If the machine has a tag that defines kernel options, the global ones aren't used. This is true for both 2.9 and 3.0, so no regression there.
Also, if the machine doesn't have a tag, the global kernel options are used. This is true in both 2.9 and 3.0.
Yes, Alberto changed get_effective_ kernel_ options( ), to not get the default kernel options from the DB config. But get_effective_ kernel_ options( ) is always called with the default kernel options as default_ kernel_ opts, which does get returned if no tags match. Just like in 2.9.
I agree that this is confusing. But considering the are "default" kernel parameters, it implies that you can override it somehow. So I do think the behavior makes sense for 3.0, but at some point we should revisit how we handle kernel parameters.