Scalable compute services.
Simple object storage.
Run managed Kubernetes clusters.
Tools & Integrations
Automate your infrastructure.
Deploy pre-built applications.
Connect, share and learn
DevOps and development guides
Questions & Answers
Development and systems Q&A
by Justin Ellingwood
Allow us to label floating ips so we know what service/class of machine we need to point it to. For example, a person could enter a subdomain label, or short description of like "primary app server".
This is exactly what we need. Labels are everyone's friends.
Will go a step further, all resources should be able to be tagged.
And by resources, I mean anything that is a resource that I can create/read/update/delete using DropletKit https://github.com/digitalocean/droplet_kit. Right now, I can script the creation of a droplet and floating ip, but I cannot group them together via tag/label so that I can manage them as related resources later (i.e. delete).
A last argument for this, floating ips would greatly benefit from being identified by a logical name (tags/labels would serve this purpose). If I could create a floating ip with a tag/label/name, I could reference it in scripts at a later time by tag/label/name. As it is, I have to create the floating ip, get the ip address and then hard code that into my scripts. This is an issue if I want to run my scripts in multiple data centers where each data center will have a separate and distinct IP address.
@DevQuixote A comprehensive tagging API sounds really useful, as long as one carefully avoid the immediate opportunity to shoot one's self in the foot: how do you describe hierarchy, and how do you avoid introducing segregation with meaningless synonyms? A well-planned API that helped me mitigate these kinds of issues, while allowing me to managed relationships in an intuitive way would be much better, IMO, than a half-cocked, "everything has a new string field." Relationships are more important than objects, especially with horizontal scaling.
Concerning Floating IPs specifically, I'm a bit sceptical. Why wouldn't DNS entries fill this role? They allow both unique naming and semantical categorizing, and their well-established, and already implemented. Even if you don't want to purchase a real domain from a registrar, it is convenient enough to specify a custom DNS server when doing a query by hand (e.g. nslookup mydomain.com ns1.digitalocean.com), or simply by logging in to the website to view the DNS page.
FWIW, I haven't fooled around with the API much. But I suspect it either has DNS querying/management baked-in already, or that it would be relatively simple (if mundane) to add.
"Which of these are the production server again?"
A follow up question to @Jonath Paugh: When I perform maintenance on my production web server, I point the production floating IP at a placeholder server then work on the production server behind another ip until I restore it by pointing the floating ip back to it. It sounds like you're saying someone like me should use DNS for that, but (1) I'm worried about propagation delays where the floating IP seems to be immediate and (2) I use Route 53 which doesn't allow CNAMEs on zone apexes for resources outside of Amazon so I can't rely on names alone. I've got IPs for zone apexes all over my DNS. I can't just point CNAMEs at single A record and update that. Those are my reasons for not using DNS. I know very little about DNS so am I missing something that would help me?
plus one on this. Names are much easier to deal with than addresses.
This would let the domain networking section much easier to use - instead of pointing www.mydomain.com to 40.0.whatever, I could point it to MyDomainFloatingIP just like we do now with named droplets.
You won't be notified about changes to this idea.