Oh I totally agree with what you are saying. A DNS change may be lower cost than running Swift config/management commands. At the very least, ops already know how to do DNS updates, regardless of it's "cost", where they have to learn how to do Swift management.
I was simply adding clarity to the trickiness of the situation. As I said originally, it's a balance of offering a feature that has a known cost (DNS lookups in a large cluster) vs not offering it and potentially making some management more difficult. I don't think either solution is all that great, but in the absence of a decision, we've so-far defaulted to "less code has less bugs" and not yet written or merged it. --John On Jul 23, 2014, at 10:07 PM, Osanai, Hisashi <osanai.hisa...@jp.fujitsu.com> wrote: > > Thank you for the quick response. > > On Thursday, July 24, 2014 12:51 PM, John Dickinson wrote: > >> you can actually do the same today >> with the IP-based system. You can use the set_info command of >> swift-ring-builder to change the IP for existing devices and this avoids >> any rebalancing in the cluster. > > Thanks for the info. > I will check the set_info command of swift-ring-builder. > > My understanding now is > - in the FQDN case, an operator has to do DNS related operation. (no whole > rebalancing) > - in the IP case, an operator has to execute swift's command. (no whole > rebalancing) > > I think that the point of this discussion is "swift's independency in case of > failure" > and "adding a lot of operational complexity and burden". > > I think that recovery procedure in the FQDN case is common one so it is > better to have the ability for using FQDN in addition to ip addresses. > What do you think of this? > > +----------------------+----------------------+-------------------+ > | | In the FQDN case | In the IP case | > +----------------------+----------------------+-------------------+ > |Swift's independency |completely independent|rely on DNS systems| > +----------------------+----------------------+-------------------+ > |Operational complexity| (1) | (2) | > |(recovery process) | simple | a bit complex | > +----------------------+----------------------+-------------------+ > |Operational complexity| DNS and Swift | Swift only | > |(necessary skills) | | | > +----------------------+----------------------+-------------------+ > > (1) in the FQDN case, change DNS info for the node. (no swift related > operation) > (2) in the IP case, execute the swift-ring-builder command on a node then > copy it to > all related nodes. > > Best Regards, > Hisashi Osanai > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
