Open Stack

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.hisashi at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140723/f28f267a/attachment.pgp>