registering a cli opt on a filter object doesn't actually work
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
oslo.config |
Fix Released
|
Medium
|
Tong Da |
Bug Description
Registering a CLI option using cfgfilter doesn't work. This is logical, but we have an API for doing it and I think we probably want to just delete it.
Given this program:
#!/usr/bin/env python
from oslo.config import cfg
from oslo.config import cfgfilter
import sys
c = cfg.CONF
c(sys.argv[1:])
f = cfgfilter.
f.register_
cfg.
)
)
print f.myflag
Running it I get:
Traceback (most recent call last):
File "./cli_
help='turn on myflag',
File "/home/
return self._fconf.
File "/home/
result = f(self, *args, **kwargs)
File "/home/
raise ArgsAlreadyPars
oslo.
If I move the call to parse the CLI arguments to a point after the filter option is defined:
#!/usr/bin/env python
from oslo.config import cfg
from oslo.config import cfgfilter
import sys
c = cfg.CONF
f = cfgfilter.
f.register_
cfg.
)
)
c(sys.argv[1:])
print f.myflag
Then running the command without any options gives me the option value, but trying to actually use the flag gives an error:
usage: cli_with_filter.py [-h] [--config-dir DIR] [--config-file PATH]
cli_with_
Changed in oslo.config: | |
importance: | Undecided → Medium |
status: | New → Triaged |
Changed in oslo.config: | |
assignee: | nobody → Tong Da (tongda) |
Changed in oslo.config: | |
milestone: | none → 1.12.0 |
status: | Fix Committed → Fix Released |
It seems that registering cli opt after the original ConfigOpts is parsed is meaningless. So I think it would make more sense to throw an exception if the registered opt is an unknown opt, otherwise, it should behave similar to import_opt() when registering a known opt.