Operating System: All
Platform: All

> forced to reconfigure a user's password on subsequent puppet runs

Understood, but can you elaborate how doing this is an issue?

What I mean is: Who cares if a configuration tool like puppet just overwrites a uid/pwd, instead of being "smart" and first check if it is (in)valid and only then change it? It's not going to be "faster", or anything like that, so why not just KISS ? Just curious.

> if we could use idmtool to test a login

Would ODL be running or not at the point you'd like to use idmtool for this? If it is, then the simplest would be to just fire off a HTTP REST call using the uid/pwd for basic auth to see if it's valid... could that work for what you're after?

(In reply to Michael Vorburger from comment #1)
> > forced to reconfigure a user's password on subsequent puppet runs
>
> Understood, but can you elaborate how doing this is an issue?
>
One of the issues is it restarts opendaylight. Is it necessary to restart ODL to pick up the changes for a new user or password change? Perhaps we can simply remove that from puppet-opendaylight if not. A smaller issue is we should not reconfigure the password everytime we run puppet if possible.

> What I mean is: Who cares if a configuration tool like puppet just
> overwrites a uid/pwd, instead of being "smart" and first check if it is
> (in)valid and only then change it? It's not going to be "faster", or
> anything like that, so why not just KISS ? Just curious.
>

Well that is the entire philosophy of puppet, check resources and only configure when necessary. It is true this is a minor thing, but if everyone did this then it would end up costing a lot of cycles in puppet. More important is the ODL restart issue.

> > if we could use idmtool to test a login
>
> Would ODL be running or not at the point you'd like to use idmtool for this?
> If it is, then the simplest would be to just fire off a HTTP REST call using
> the uid/pwd for basic auth to see if it's valid... could that work for what
> you're after?

No we cannot assume ODL is running with this.

> Is it necessary to restart ODL to pick up the changes for a new user or password change?

YES! Very much so. It's even more than just to "pick up" - if you use the CLI tool to write to the idmlight.db file, while ODL runs, that's almost certainly going to corrupt it... because ODL also keeps that H2 DB file open.

> More important is the ODL restart issue.

OK, then let me look into adding support for this .. let us first agree on a "micro spec", right here in-line in this bug? Looking at https://wiki.opendaylight.org/view/AAA:Changing_Account_Passwords#Change_Password_When_ODL_is_Not_Running, if I understand you correctly what you would like is a new CLI switch, let's call it... -cp / --checkPassword? So you presumably you would want to be able to do like:

java -jar $KARAF_HOME/bin/aaa-cli-jar-0.5.0-SNAPSHOT-jar-with-dependencies.jar -cp trozet -p secret

and if "secret" is "trozet"'s password, then the tool would print "OK", and return 0, but if it's not it would print "NOK" and return some negative value? Could you confirm that this is your requirement?

> No we cannot assume ODL is running with this.

But something still doesn't quite make sense to me: If ODL is not running, then you don't have a restart issue - you can just reset the uid/pwd while it's not running, and then start. And if it is running, then the best is to use a HTTP REST call, to verify.

(In reply to Michael Vorburger from comment #3)
> > Is it necessary to restart ODL to pick up the changes for a new user or password change?
>
> YES! Very much so. It's even more than just to "pick up" - if you use the
> CLI tool to write to the idmlight.db file, while ODL runs, that's almost
> certainly going to corrupt it... because ODL also keeps that H2 DB file open.
>
> > More important is the ODL restart issue.
>
> OK, then let me look into adding support for this .. let us first agree on a
> "micro spec", right here in-line in this bug? Looking at
> https://wiki.opendaylight.org/view/AAA:
> Changing_Account_Passwords#Change_Password_When_ODL_is_Not_Running, if I
> understand you correctly what you would like is a new CLI switch, let's call
> it... -cp / --checkPassword? So you presumably you would want to be able to
> do like:
>
> java -jar
> $KARAF_HOME/bin/aaa-cli-jar-0.5.0-SNAPSHOT-jar-with-dependencies.jar -cp
> trozet -p secret
>
> and if "secret" is "trozet"'s password, then the tool would print "OK", and
> return 0, but if it's not it would print "NOK" and return some negative
> value? Could you confirm that this is your requirement?
>
yeah that would be great.
> > No we cannot assume ODL is running with this.
>
> But something still doesn't quite make sense to me: If ODL is not running,
> then you don't have a restart issue - you can just reset the uid/pwd while
> it's not running, and then start. And if it is running, then the best is to
> use a HTTP REST call, to verify.

So the thing is puppet is declarative. You specify resources you want to be configured and declare their state/configuration. In this case we have an custom resource that is labeled as idm configuration. We want to limit this resource provider to interact with the idm directly is one reason not to use a curl. In addition, using a curl request means going over a network stack and depending on that ODL is up and REST access is working. We could hit a false failure saying that the password is not set correctly due to a network or ODL issue, rather than the password is not set correctly. We currently use the idm tool to query if a user already exists, I think it is best to do the same thing with the password as the DB is the direct source of truth as far as what is configured.

https://git.opendaylight.org/gerrit/#/c/60049/

This works in stable/carbon, confirmed by downstreams like OPNFV Apex using it extensively in deployments.