© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
Hmm... well, look at the code from the past year:
Grizzly:
https:/
Folsom:
https:/
Essex was the same way, my point is that it seems that if the manager it expecting the model_update (which yes is the same as the export) it's probably correct to return the model update. Also the fact is that the task-flow code does the same thing that the old manager code has been doing for quite some time so I certainly wouldn't say it's a bug in the task-flow code.
Finally... just because a percentage of drivers failed to implement this in the past, it was never an issue because we didn't do things like general iscsi attaches during create operations, so nobody cared. Also for quite a while we explicitly called export at the end of the create method (even though this seems a bit redundant). Now however, we actually rely on attach before create finishes and drivers that didn't implement what the manager expects (such as Nexenta in this case as well as a number of others) fail.
Fact is there was some sloppiness here, personally I don't see the objection to the driver setting up the export at create time, why have an unnecessary second call back out to the driver?
That being said, for now rather than trying to fix the drivers that don't return the expected information on create it would be better to add the explicit export call if the model update isn't present. I'll look at submitting a fix for that tomorrow.
Thanks!