Open Stack

On 11/23/20 7:21 PM, Sean Mooney wrote:
> On Mon, 2020-11-23 at 18:34 +0100, Thomas Goirand wrote:
>> Hi Sean,
>>
>> Thanks for your post.
>>
>> On 11/23/20 2:32 PM, Sean Mooney wrote:
>>> nova need to enforce it as we use the absense or present of the db creads to know
>>> if common code is running in the compute agent or in controller services
>>
>> I'm a bit shocked to read what I've read in this thread, about the
>> double-guess that Nova is doing.
>>
>> The way the Nova team has been describing, this really looks like hacks
>> to hide the internals of Nova, and what the team is asking, is more
>> band-aid for it. Probably things have been done this way to make it
>> easier for the users, but at this point, it feels like we shouldn't
>> attempt to hide facts anymore, and try to have everything explicit,
>> which is going the opposite way of what you describe.
>>
>> Why don't we go the other way around, and get things like a
>> superconductor=true configuration directive, for example?
> this would break upgrades for everyone one of our upgrade constratins
> is you should never have to update your config as part of an upgrade.

There's one way to avoid this. Have 3 values for the config option:
- None: keep old behavior (that would be the default)
- superconductor
- cellconductor

> where config changes are needed we always give you at least 1 cycle to update
> your configs as part of a seperate maintance window.

What I'm proposing just above hopefully addresses your concern.

> it would also force all deployment tools and packages to chagne as we would have
> new portentially incompatible options in config files.

There's no problem on the packaging level. Though truth, there would be
some work on the config management modules, but that's what they are for.

> spcificlly packagers would have to ship different nova config file for supper conductors and cell conductors for that usecase.

Simply put: no. In Debian, we could even provide a debconf prompt to
address the question (I believe I would do that...). Currently, I don't
know any OS that is taking care of doing config file updates anyway.
That's something I've been thinking of for a long time, though it's not
an easy thing to write (in a shell script), and everyone uses config
management systems anyways.

>> On 11/23/20 2:32 PM, Sean Mooney wrote:
>>> it is a bug to have the db cred in the set fo configs passed to
>>> nova-comptue and it has been for years.
>>
>> In such case, detect that it's the nova-compute agent that's running,
>> detect that it has access to db creds, and either:
>> - display a big warning (I would prefer that)
>> - display an error and quit (maybe bad in the case of an all-in-one setup)
>>
>> This is orthogonal to the fact that Nova code is doing a hack (which
>> should be fixed) to check which daemon is currently running in what mode.
> it is not a hack, checking the binary name would be a hack as that is common code
> that shoudl be independnt of what name you give the file on disk.

Right, it shouldn't be based on the filename on disk, but there are many
other ways to implement this. Gibi wrote about having a global CONF
value, that would work. Passing additional parameters to the part of the
code that connects (or not) to the db would be another way (but probably
harder to implement).

>> On 11/23/20 2:32 PM, Sean Mooney wrote:
>>> we could make this just a ERROR log without the hard fail but that
>>> would still not change the fact there is a bug in packages or
>>> deployment tools that should be fixed.
>>
>> Probably. But that shouldn't be upstream author's business on how things
>> are deployed. IMO, in the case of an all-in-one, nova-compute should
>> continue to work and just ignore the db params, and at worse display a
>> huge warning on the logs.
> well there i dissagree the warning/error message is the bare minium we should do 
> and at most we should allow ti to contiue executing and optimally it should stop the service sicne we know
> the config is invalid.

Worst case, this disagreement could be solved by a configuration value,
on by default if you like:

die_if_nova_compute_has_db_access=True

:)

I believe everyone will agree that it's super easy to change such a
config value if you want to deploy all-in-one, and it's probably not
much to ask to someone deploying in a non-standard way.

Cheers,

Thomas Goirand (zigo)