> I'm not sure how we can deploy things out of order, when there is a real > dependency: for instance, it's hard to deploy keystone before the > database. So this means that this would only "work" for some cases, and > break in many other cases, which breaks the principle of least surprise. > > And I'm putting "work" in quotes because the user doesn't even get the > result he expects (in the swift example: keystone won't be used, even if > you deploy keystone afterwards).
"Eventual convergence." The *next* run of the chef-client will make sure that downstream resources will be configured to work with changes to upstream resources. > > > > > I also see what you mean about Glance and Keystone. That's a *bad > > > > thing* if the glance service isn't registered at all in keystone, as > > > > nova still needs to talk to it. That should be broken in two.. I'll > > > > have another look at the code. > > > > > > I just think it's easier to always use keystone in glance ;-) > > > > I haven't tested using keystone and the glance file store. I'd hope that > > glance does not freak out when keystone auth_token is in the pipeline but > > is accessing files. What's your experience? > > For SUSE Cloud, we've always used keystone support in glance. Also, > use_keystone is set to true by default, so I'm pretty sure most of us > have also been testing this without even knowing it ;-) I haven't been working on glance. Filestore works OK? The. Token_auth pipeline doesn't halt/delay glance+filestore? Happy days, _judd
_______________________________________________ Crowbar mailing list [email protected] https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
