While your correct that a chassis replacement can avoid data rebalancing in the FQDN case if you update DNS, 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.
--John On Jul 23, 2014, at 6:27 PM, Osanai, Hisashi <osanai.hisa...@jp.fujitsu.com> wrote: > > I would like to discuss this topic more deeply. > > I understand we need to prepare DNS systems and add a lot of operational > complexity and burden to use the DNS system when we use FQDN in Ring files. > > However I think most datacenter have DNS systems to manage network resources > such as ip addresses and hostnames and it is centralized management. > And you already pointed out that we can get benefit to use FQDN in Ring files > with some scenarios. > > A scenarios: Corruption of a storage node > > IP case: > One storage node corrupted when swift uses IPs in Ring files. An operator > removes > the node from swift system using ring-builder command and keeping the node > for > further investigation. Then the operator tries to add new storage node with > different ip address. In this case swift rebalance all objects. > > FQDN case: > One storage node corrupted when swift uses FQDN in Ring files. An operator > prepares > new storage node with difference ip address then changes info in DNS systems > with > the ip address. In this case swift copy objects that related to the node. > > If above understanding is true, it is better to have ability for using FQDN > in Ring > files in addition to ip addresses. What do you think? > > On Thursday, July 24, 2014 12:55 AM, John Dickinson wrote: > >> However, note that until now, we've intentionally kept it as just IP >> addresses since using hostnames adds a lot of operational complexity and >> burden. I realize that hostnames may be preferred in some cases, but this >> places a very large strain on DNS systems. So basically, it's a question >> of do we add the feature, knowing that most people who use it will in >> fact be making their lives more difficult, or do we keep it out, knowing >> that we won't be serving those who actually require the feature. > > 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