On 02/28/2014 04:12 PM, Jerome Martin wrote: > A couple of other things might happen here, but out of the top of my > head, that's the rough process. > > Now, this whole system is open to discussion. Should I move the > reference check to pre-commit instead of enforcing that at config > statement load time ? Are there some checks that the user should be > able to relax for flexibility reasons ? The guideline I use for now is > that you should be able to compose a configuration one one system, > dump it and load it on a production system, and only commit it there. > So all system-specific checks should be done during pre-commit, before > we compute the commit execution plan, the non-system specific checks > being done at load time (hence the reason why object references are > checked early). > IMO, there definitely should be an interface to override the checks, for flexibility to users. Not just for some, but all. I think checks at pre-commit stage is the Right Thing to do. Because we are talking storage here. PS: I haven't much looked at your code. My comments are based only on what I've understood from the emails. In real world, the typical steps to initializing a new configuration is to restart the service. When users do that, and if the new configuration is faulty, it brings in uninvited downtime. By introducing whatever possible checks, at pre-commit stage, you are at least mitigating that downtime. Apache (configtest) and Samba (testparm) are good examples of services that ensure their configurations are valid. >>> BTW Ritesh, as a package maintainer, what do you thinks would be the >>> best in the eventuallity we want to include rtslib + the lio cli only: >>> rename the rtslib package into say 'lio', including all API + the cli, >>> or split it in two packages (but the cli one would be tiny) ? >> Today, for the packages available in Debian, apart from targetcli, >> OpenStack (python-cinder) is the other suite that has a dependency on >> rtslib. Your library has been out for some time now, so I'm not sure who >> else have consumed it. >> >> As a package maintainer, it wouldn't cost me much as I can still derive >> both the packages from the same source archive (irrespective of the >> rename), provided the library interfaces remain the same. >> >> I'd suggest you merge them to one, name it as rtslib, and ship the tiny >> lio CLI along with it. > > Mmmh. One problem here is the init sequence. With the lio cli, no need > for lio-utils anymore. The initscript will be included too. So that > new rtslib+configAPI+lio cli package would conflict with lio-utils, > which is required by the current targetcli, which also ull configshell > BTW. So it would make it impossible to install both > targetcli+lio-utils and a lio-cli enabled rtslib, which I think we > should support at least during some migration period, and for > side-to-side debug/testing. I really don't know how to best do it, or > I should leave all of that up to package maintainers? This should be doable by using the 'Provides: ' packaging attribute in dpkg. No ?? RPM might have a similar header ?? I'd suggest delegation of the transition task to package maintainers. Please just ensure to keep the module library interface intact. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System
Attachment:
signature.asc
Description: OpenPGP digital signature
