Three things Linode should improve upon?
caker
Linode Staff
Thanks,
-Chris
236 Replies
Android app
Moving Fremont to a different DC or getting your own set of UPS racks and generator(s) to power your own servers to show the Fremont network monkeys how things should be done. Maybe at least just let us know what the hell is happening on the Fremont front.
It's a problematic DC. Its location is very important (to me at least), but the DC itself isn't stable (I know it's HE's fault). Were there any improvements on that topic since the last downtime?
Other than that, amazing service, amazing support. Great price.
Less wait time when a host reboots between the boot being added to the queue and the linode actually booting. decentralise the boot process.
DC in australia.
caker
Linode Staff
We (at Linode) know the Fremont issue is a big one, and I'll address that in more detail in a later post.
So, besides Fremont, what else?
Thanks,
-Chris
3. Storage: I'd really love to see some form of storage plan, without changing at all how local storage is currently engineered/packaged for primary Linode use. But external storage packages (say, perhaps, SAN storage in each DC) as an add-on for economical larger storage needs without having to give up too much in convenience/performance would be great.
Disk management: Permit cloning an operating Linode by snapshot-ing the disk images just as backups do. Generate alerts for failed backups.
Accounts: Support multiple billing methods per account, so a different account isn't needed just to handle multiple payment methods. Since some aspects of the service are bounded by account (such as for example, bandwidth pooling/cloning/restorations), having to artificially split Linodes just for billing purposes can interfere with some features. Alternatively, provide some way for multiple accounts to be grouped under some sort of parent account to lump all the Linodes together for system features. Ok, I suppose that's 4 with the backup alerts, but that's a tiny item.
– David
2) I recently did an IP swap. This page notated that it would execute shutdown jobs, which is cool. What I didn't expect was that they would simply not come back up, even despite lassie. Changing this to be either reboot events tied to each other, or at least give me an option to have them come back up automatically after this would be neat.
3) This may not be wanted/used by a huge audience, but having SELinux in the stock kernels might be nice. I'm running the stock CentOS kernel now (which I will probably continue using), but if I had a SELinux enabled kernel when I first worked on changing my linode to CentOS 6 I probably would have just kept with the linode kernels.
Service is great, though. Nice hold music. :)
i know i know, but I'd like to have a cloud here, even if it was small.
i'd fund the rack… we can get 1Gig IP here, but why? start with 100MB. I'll even fund the IP.
Wavecom (telco here put up a cloud in Kona, HI and Honolulu, HI) -
http://wavecomsolutions.com/waveflex/
2) Management of multiple linode
ability to compress / expand display group of linodes
cumulative graph of all node traffic
support ticket node selection alphabetical (not by order purchased)
3) IPs move between data centers
we understand the bgp issues
without NAT
Linode would have to have a private network on the backend
1) Local bulk object storage, along the lines of S3. Must have a robust way to mount as a filesystem (like s3fs), and must support optional direct retrieval by HTTP GET. I think you know what I mean.
2) Better short-term billing options. I'd like to spin up a 4 or 8 GB instance for an afternoon to run a terribly-written script, but I really don't want to have $300 sitting on my Linode account for the next few months after I nuke it. Gotta eat, bro. (I could rewrite the script, but it'd be annoying. I could also ask for a credit card refund, but that sucks for you.)
3) Easier support for distro-provided kernels. I know pv_grub sucks balls through a bull's bojangles six ways from Sunday, but over the past few years, distro kernels have started to become quite decent. A way to automagically do the right things and set up grub in a pointy-clicky fashion would be nice.
I probably have something else even more important than those, but it's late, my mind is toast, and I need to sleep. -rt
p.s.: Alohatone: Linode doesn't start small. One rack would pulverize a 1 Gb/sec link, and at this point, I'd be surprised if a single rack of Linode servers elsewhere in the Pacific quadrant weren't noavail'd within a couple weeks. That said, some sort of Linode-in-ur-house-provisioning-ur-nodes VIP personal on-site cloud delivery service… hmmm.
1) Cheap, large archival disk space, I'd like to back up my home systems in case a fire took out the house. 300 Gigs of slow but usable archival disk space that doesn't count against my bandwidth. 500 Gigs would be nice. I'd be willing to pay let's see, I can get a 1 TB slow USB drive at Fry's for $79.99 so divide that by 24 months (I'd go from monthly to 24 monthly) is $3.33. I'd pay that and you can keep the discount so 24 months @ 480 plus the $3.33 for the extra archival disk space == 560.
I'd pay $560 every two years from now on for the lowest sized Linode with a 1 TB slow archival drive. Do I need that much? No, 16 Gigs would work but I'd have to be very careful what I backed up and I don't want to search through over a decade of data to figure that out.
The above offer depends on item 2).
2) Don't sell Linode. You guys rock a rama.
3) Have lots of fun (learned that from the SuSE camp years ago).
@hoopycat:
… must support optional direct retrieval by HTTP GET. I think you know what I mean.
:-)
If it's mountable and works reasonably well, that's not entirely necessary, since you could put a Linode with a web server in front of it. Granted it's a waste of LAN bandwidth, but it wouldn't kill anyone.
@jebblue:
…
2) Don't sell Linode. You guys rock a rama.
…
This is all I would ask for. Linode outperforms in all areas. Best run business on the Internet.
Like the others have said a mass storage option that we could backup to and mount. Flat rate for a chunk or pay as you go similar to Amazon S3 but with Linodes great service. Perhaps with some guaranteed redundancy. As I understand it the current backup space could be in the same rack so a big failure could result in a total loss of data, including the backups. Excuse my ignorance of the logistics of this option.
I'm in the Newark data center and as far as I know my only downtime has been me hitting the reboot button. Reliability is excellent and support did a great job helping me recover from a crash that was entirely my fault.
Edit: Also, don't sell Linode…
1.) Storage, like everyone else. My requirements are: a.) Cheap.
It would also be neat if it was accessible from the other data centers or maybe even the entire Internet (with transfer fees, obviously). Obviously that also makes mounting less practical – though not impossible? -- but something like SFTP or rsync could work. Or, god forbid, an HTTP API. (Though this is getting into the territory of a separate, different product.) Edit: Wait. If it's mountable, then it's easy to rsync or SFTP to a node that has it mounted. Duh. That doesn't solve it if you want to put it in a data center you don't have a node in, though.
2.) More flexible billing. I'm cheating by listing two things, but oh well: a.) Pro-rating to less than a day. Knowing it costs a wallet-shattering $0.66 to spend three minutes testing iptables rules gives me some sticker shock. b.) Not having to pre-pay so much. I've only needed this once, but it would be nice to be able to run a reasonably large node for a few days without having to move hundreds of dollars around. Edit: I understand if you don't want to make repeatedly deploying nodes for minutes at a time too easy -- 15 minutes of a 512 is less than a cent, after all -- but there are ways around that. For example, having a minimum 3-6 hour commitment charged up front, then billing hourly after that.
3.) I wish the JavaScript prompts when deleting config profiles or disk images specified which one you are about to delete, just to double-check.
Finally, I'm going to cheat again by adding 4.) Greater transparency. You're certainly transparent enough, but not much more than that. You're tight-lipped as can be about future plans, and don't release the reasons for maintenance.
I feel guilty about mentioning this, since my desire for that information is pretty much entirely to satisfy my own curiosity, and as I said, you're 100% transparent enough. But 150% is even cooler, no? (I also feel guilty since there's a decent chance I'll unintentionally spark an argument, or that I'll be shot down for spoutin' unproven, vague nonsense.)
I understand that you don't want to make unnecessary promises about the future that you may later want to back out of, but I wouldn't hold it against you if you changed your mind. (And this doesn't apply to the maintenance thing at all, though for that case I do accept that some things need to be secret.)
Plus, the two times I've been affected by maintenance (both times for beta products, which is entirely acceptable, I hasten to add), the reasons were explained to me. Though the second time there was one 'sorry, that's classified' before someone more senior did discuss it. (And if you read this, Less Senior Person, I hold no ill will towards you!)
cringe, Submit (Yikes, this got long.)
Edit edit edit edit edit: Tweaks, nothing major.
2. Optional management and/or something like cPanel - it's much less hassle if I'm hosting several different sites.
3. Probably not going to happen, but I'd love to hear more information about your setup. I know there are things that are secret, but I'd love to have some info on things like new server hardware (CPU types) and how your network is laid out. (Example:
@Ghan_04:
2. Optional management and/or something like cPanel - it's much less hassle if I'm hosting several different sites.
It's always possible for you to install cPanel – shudder -- on a node yourself, though acquiring the license is an exercise left to the reader.
2) Datacentre in Australia,
A) or some where within Asia. pipenetworks are the leading Datacentre provider in AU.
3) opt-in Managed Service.
A) You pay extra to have a managed service.
1) I CAN HAZ MOAR STORAGE!!??
2) Get HE to fix Fremont, or move/expand to another West Coast datacenter.
3) Anything in the Dashboard that looks like a list should be sortable. The default should be either alphabetical or timestamp-descending, depending on the type of data.
2. FreeBSD.
3. NAS or something similar. Load up a rack of platters and give us a mount point!
1) Cynical hat on here, but customers have been banging-on about more storage availability for years and nothing's come of it….I seem to remember suggesting vps.net-style storage nodes ages ago in the forums and AFAIK it didn't even get a staff acknowledgement.
2) FreeBSD
3. Don't sell out.
Don't change. I don't want you to become Amazon (read: people paying $0.05 for ten minutes of server time, where's the money in that for you?) or anyone else. I love Linode for what it is, the fact that you've got more than enough customers to pay the bills shows this. That's not to say you can sit smugly and never improve (and that you've posted this thread shows you know this. Just keep on being Linode.
A storage solution, as so many others have indicated. I know competing against Amazon isn't easy, but the fact that it would be local and maybe even a mountable FS would mean that I'd pay more than I pay Amazon. Sure, it should run a web server on it (80 and 443) so I could serve directly from it (i.e., storage.example.com for example.com) but make it so it's mountable internally so I can drop files on it without having to do increasingly complex things with my CMS (read: would thus work out of the box with any website thanks to a simple symlink).
2. Cleanup the IRC log directory; whenever there's an issue I always check the current log before joining the channel and it's hard to find amongst the historical files. (basically, auto-archive logs older than a week)
3. Petition DCs to remove port filters, or move out of those DCs if they won't. We should determine what we want filtered, not upstream providers. (this doesn't impact me, but it's a bad thing…)
caker
Linode Staff
@sweh:
1. IP6 enabled by default
It already is (when creating in or migrating into a v6-enabled facility). I also cleaned up the irc log dir.
-Chris
Using Amazon Web Services as a reference point, I think something between S3 and EBS would be ideal.
S3's problem is that it lacks the filesystem semantics we all know and love, making things like s3fs a kludge of the first order. On the other hand, concurrent access is trivial: each operation stands alone, so it doesn't matter if you have a hundred instances reading/writing to the same bucket.
EBS's problem is that it lacks concurrent access. By emulating a block device, this means you can't use "normal" Linux filesystems if you want multiple servers mounting it read/write simultaneously. Also, despite "elastic" being in the name, resizing is not possible without snapshot/restore. Both of these problems can be worked around using LVM and fancy filesystems, but that's not easy, and that's not the Linode Way. I'm off of IRC for a bit (I'll be back on as soon as I'm caught up with coursework ha ha hahaha why am I in the forums oh god I'm going to fail) but I break out in a cold sweat just thinking of someone –forcing a read-write mount of an ext4 filesystem from two Linodes…..
So, something in the middle. Perhaps NFS to a massive NAS, or something involving GlusterFSrsync.netrsync Industries
It would necessarily be slower than local storage, but that's OK, just as long as it's cheaper and won't impact core service reliability.
Anonymous HTTP access (e.g. S3-style static hosting, perhaps integrated with NodeBalancer?) would still be nice, for those folks still using Apache+mod_php, but… eh, screw 'em.
2. Data Center in Netherlands
3. Like some other poster said please dont sell linode
2. Add new articles to Linode Library and Improve existing articles
3. Add more Linux distros and flavors of UNIX (*BSDs, etc).
@Piki:
1. Android App
2. Add new articles to Linode Library and Improve existing articles
3. Add more Linux distros and flavors of UNIX (*BSDs, etc).
Android app is already there! Search Market with "Linode"
2) Storage solution, as others said.
3) Don't change!
@ruchirablog:
Android app is already there! Search Market with "Linode"
Although it's a very good app, it isn't "official" like the iPhone app is.
It's not a huge problem for me, but it would be nice to have more disk space.
I'm personally extremely happy with Linode (Dallas center). Never had a problem that wasn't quickly resolved.
-=-
What would be neat is if each data center ran an update mirror for the various popular distributions that we could configure our update clients to point towards. Do it as IPv6 and if you don't want to be a public mirror, restrict to IPv6 within the data center.
That way all the, say, CentOS installs could update without each one needing to grab the update packages from outside the data center. The mirror would obviously have to download them once, but the installs that have yum configured to use the mirror inside the data center would not be using any external bandwidth.
For CentOS I would mirror 5 and 6 and EPEL for 5 and 6. (EPEL has a lot of useful packages that are not part of CentOS proper - perl modules, etc.)
But that's just a thought, it would be nice but it's not an issue.
There's also Debian (plus flavors), Fedora, etc. - if the data needs of providing local mirrors is too much for the popular distros (or you just don't want to) no biggie.
2)
The ability to clone linodes without shutting down
3)
The ability to turn backups off in the control panel
@waldo:
Android app created and supported by Linode with the same features as the iPhone app. Not to mention it coming from a trusted source. Sorry, but for something like this, I'll never use a 3rd party app. I'd only think about using a 3rd party app if and only if it's open source. But then how do you prove that what is in the app market is compiled with that same code or doesn't have some malicious code in it.
My sentiments exactly.
I don't like closed source apps in general (I do run the fluendo codecs and adobe flash on my desktop, but that's all I can think of)
@FunkyRes:
@waldo:Android app created and supported by Linode with the same features as the iPhone app. Not to mention it coming from a trusted source.
My sentiments exactly.
I don't like closed source apps in general (I do run the fluendo codecs and adobe flash on my desktop, but that's all I can think of)
I hold the same views about the Android app. It uses Linode graphics which could lead someone to think it is official.
@FunkyRes:
What would be neat is if each data center ran an update mirror for the various popular distributions that we could configure our update clients to point towards. Do it as IPv6 and if you don't want to be a public mirror, restrict to IPv6 within the data center.
For what it's worth, for Debuntu users, there are apt-cacher-ng instances on the private network in Dallas, London and Newark. (IPv6 too.)
http://www.linode.com/wiki/index.php/Internal_Services
JshWright, who runs the Dallas and Newark ones, also has a page up about it:
5.) A Linode Bugzilla, or something like it. I feel guilty filing a ticket and paging someone to, say, report a typo on the website, but if I just ping someone on IRC, it'll probably get lost.
@waldo:
Android app created and supported by Linode with the same features as the iPhone app. Not to mention it coming from a trusted source. Sorry, but for something like this, I'll never use a 3rd party app.
I will ditto this paranoia. No offense intended to the author (who I'm pretty sure posts here), but I really can't be 100000% certain that my API key isn't being sent to him to do what he wants. An official app is needed.
4) Local repo mirrors/caches. I don't even care if it counts against my quota, I'm just tired of downloading 20MB+ updates at 5kB/sec because it picked a bad mirror. If I could just hard-code my mirror to be mirrors.kernel.org and then throw a local linode provided squid cache in front of it, I'd be happy. Provide full local content mirrors for $MY_DISTRO and I'd be happier.
What happened during the last Fremont episode was pretty bad. Nothing was posted to the status page yet engineers knew something was up. And we were left to fend through the cesspool that is the Linode IRC channel (so many trolls). Please, please let people know what is happening when there is outages.
2) Cloudflare/Firewall.
Please consider build a Cloudflare/Firewall product that can filter out all of the bad guys before it hits my delicate app servers. I don't want to build/manage the couple (minimum) of Linodes needed for a full redundant firewall solution.
3) Australia data centre at existing prices. Pretty please
(Source of 1.2 TB figure:
@taligent:
Please consider build a Cloudflare/Firewall product that can filter out all of the bad guys before it hits my delicate app servers.
Hmm… perhaps a caching layer as part of NodeBalancer? The underlying high-availability architecture is already there, and it functions as a firewall, albeit a rather special-purpose one.
@taligent:
And we were left to fend through the cesspool that is the Linode IRC channel (so many trolls).
Is that the only time you've been in the IRC channel? If so, I hope it didn't form a permanent impression. There were only about 2 trolls, and 99.98% of the time it's troll-free. (Except for the regulars.;-)
@hoopycat:
Hmm… perhaps a caching layer as part of NodeBalancer? The underlying high-availability architecture is already there, and it functions as a firewall, albeit a rather special-purpose one.
I would suggest a new product e.g. WebBalancer.
Which would be NodeBalancer + firewall + basic request/response caching + ability to show an error page if the app server is down.
e.g. Nginx + Memcached + IPTables.
@waldo:
Android app created and supported by Linode with the same features as the iPhone app. Not to mention it coming from a trusted source. Sorry, but for something like this, I'll never use a 3rd party app. I'd only think about using a 3rd party app if and only if it's open source. But then how do you prove that what is in the app market is compiled with that same code or doesn't have some malicious code in it.
The official app would probably be open source considering the Linode stands for "Linux Node" (Linux IS open source), but the question of if the version on Market uses the same code as the open source version would still stand, and it can hold true for any software – even the packages in Debian, and any Linux user knows that they are fervently against proprietary software.
I would like an official open source app. I don't know if the one on Market is open source or not, I haven't looked into it, but I'd use it only if it is open source, and if it supported everything in Linode manager but arranged for a smart phone
@Mr Nod:
Only 2 suggestions
1) Cynical hat on here, but customers have been banging-on about more storage availability for years and nothing's come of it….I seem to remember suggesting vps.net-style storage nodes ages ago in the forums and AFAIK it didn't even get a staff acknowledgement.
2) FreeBSD
If it was 4 points not 3 i would of defiantly said FreeBSD.
@Piki:
The official app would probably be open source considering the Linode stands for "Linux Node" (Linux IS open source),
Doubtful. The official iPhone app provided by Linode isn't open source, at least I haven't seen mention of where one can download the source from.
@Piki:
but the question of if the version on Market uses the same code as the open source version would still stand, and it can hold true for any software – even the packages in Debian, and any Linux user knows that they are fervently against proprietary software.
No the problem with the version on the Android app market is that is it provided by a 3rd party individual. Not Linode. He may be trust worthy he may not. Unless I personally know him as either a close aquaintence or friend, I wouldn't use it. Unless an Android app is developed, released and supported by Linode I won't use it, open source or not.
I treat access to my Linode account like I do my bank accounts. I trust know one buy myself and the direct entity that I am doing business with.
@Piki:
I would like an official open source app.
We may get an app from Linode, but I doubt it'll be open source. I personally wouldn't care if it's open source or not, only that it's provided and supported by Linode.
@Piki:
The official app would probably be open source considering the Linode stands for "Linux Node" (Linux IS open source)
The issue here isn't linux, it's the linode manager, which is NOT open source. There is an API for access, which the android app uses), but my understanding is that the iphone app does not.
2. Linode site reliability. No one has mentioned this, but every time I lose connection to my Linode (which is in Dallas) I immediately check linode.com, which is unavailable. I assume this is because it is also located in Dallas. I usually check status.linode.com but can't remember if that is down also or not. If this isn't actually an issue and just something weird on my end, ignore this.
3. More frequent blog posts? I know you all don't have "important" news often (mostly every few months) but maybe some more posts about what you're working on or that's coming up for Linode would be nice. I also understand the problems with doing this… Customers start to expect features that end up not working out, or are too time consuming, and your competition knows what you're up to.
4. More important than the above, DON'T SELL OUT!
@mnordhoff:
For what it's worth, for Debuntu users, there are apt-cacher-ng instances on the private network in Dallas, London and Newark. (IPv6 too.)
http://www.linode.com/wiki/index.php/Internal_ServicesJshWright, who runs the Dallas and Newark ones, also has a page up about it:
I'm not ready to go public w/ it but I set up one for CentOS 6 / EPEL on my local linode - but x86_64 only, IPv6 only.
I'll be adding my private repo w/ my custom php builds to it (I keep up with php, I don't like to rely on back-ported patches to versions that go crusty with time), patched RPMs for CVE's not yet patched in upstream updates, and possibly custom ffmpeg (for transcoding between h.264 and theora or vp8 for robust html5
My intent is to use it for customers who buy the product I'm developing and want me to pay me to set them up a Linode to run it. When I'm ready, I suppose I wouldn't mind other Dallas users who want a geographically local server using it, but I'd want to manually allow from their IPv6 in the .htaccess - I don't want to be a public mirror.
But to be honest, if I was another user who didn't know me, I wouldn't trust me to have it synced with upstream updates in timely manner. My customers would be paying me to so they would have contractual recourse if I didn't, but not some random joe.
b) Monitoring Solution with email/sms alerts
c) Android App
@Smark:
2. Linode site reliability. No one has mentioned this, but every time I lose connection to my Linode (which is in Dallas) I immediately check linode.com, which is unavailable. I assume this is because it is also located in Dallas. I usually check status.linode.com but can't remember if that is down also or not. If this isn't actually an issue and just something weird on my end, ignore this.
I think it's something weird on your end. Or, more specifically, in the middle. (Although manager.linode.com usually is in Dallas, so the fate-sharing isn't surprising.)
Install mtr… the next time it happens, gather a --report and compare it to the normal state of affairs. Losing reachability to various places will occasionally happen (things break more than you want to know…), but it shouldn't happen consistently.
tl;dr: it's just you
@waldo:
No the problem with the version on the Android app market is that is it provided by a 3rd party individual. Not Linode. He may be trust worthy he may not. Unless I personally know him as either a close aquaintence or friend, I wouldn't use it. Unless an Android app is developed, released and supported by Linode I won't use it, open source or not. I treat access to my Linode account like I do my bank accounts. I trust know one buy myself and the direct entity that I am doing business with.
If it's open source, you can look at his code, and even compile it yourself. Such is the beauty of open source
@waldo:
We may get an app from Linode, but I doubt it'll be open source. I personally wouldn't care if it's open source or not, only that it's provided and supported by Linode.
@glg:
The issue here isn't linux, it's the linode manager, which is NOT open source. There is an API for access, which the android app uses), but my understanding is that the iphone app does not.
I personally stay away from anything that isn't open source (I'm actually more strict than that, I stick to Free(dom) Software). The only time I used the Linode manager was to attach my domains to my Linode and to deploy my VM. I do everything else directly on the VM via ssh and using F\OSS software.
If they do post an Android app, I will look for the source code first. It's not like they have to design it in a way to show personal data, they can use their own library to handle the encryption (encryption is the only exception to the F\OSS issue, as far as I'm concerned) as long as the rest of the app is F\OSS.
@Piki:
I personally stay away from anything that isn't open source (I'm actually more strict than that, I stick to Free(dom) Software). The only time I used the Linode manager was to attach my domains to my Linode and to deploy my VM. I do everything else directly on the VM via ssh and using F\OSS software.
You are not getting this at all. The android app would be to perform linode manager tasks like rebooting your linode or deploying a new one. The linode manager is not open source, so an app doing more than the API allows (which apparently the iphone app does), would need some stuff that wouldn't be open source.
2> Additional storage
3> Per day billing instead of monthly billing in case of moving to higher linode
3a> pagination in DNS manager
@hoopycat:
@Smark:2. Linode site reliability. No one has mentioned this, but every time I lose connection to my Linode (which is in Dallas) I immediately check linode.com, which is unavailable. I assume this is because it is also located in Dallas. I usually check status.linode.com but can't remember if that is down also or not. If this isn't actually an issue and just something weird on my end, ignore this.
I think it's something weird on your end.
I have a similar issue.
If I ssh into my linode from home but leave the prompt for too long (5 minutes is often enough), the connection drops. Not drops as in I get a timeout message, drops as in the ssh session appears frozen. Happens regardless of which computer at home I am using.
When using same physical computer from my parents house (3 hours from my home) - I can leave a ssh connection idle for eons and the connection is still active.
Something somewhere between my home and Dallas drops the connection in a funny way if data isn't trickling between.
@FunkyRes:
I have a similar issue.
If I ssh into my linode from home but leave the prompt for too long (5 minutes is often enough), the connection drops. Not drops as in I get a timeout message, drops as in the ssh session appears frozen. Happens regardless of which computer at home I am using.
This is most likely a NAT timeout on your home router, rather than anything more central in the network. Try configuring your ssh client for keep-alives (e.g., "ServerAliveInterval" in your ~/.ssh/config) with a short interval, like 60s, and see if that helps.
– David
1) Storage
A lot of storage!
I won't use it for backups, I need it to store my customers data as video, documents, images, etc…
The perfect storage I need may be:
500GB mirrored
networked, just need to mount it and use it. I don't want to reboot the VPS everytime I expand the disk space.
fast enough to support data exchange through internet, so no need to be extremely fast
reasonably priced
:)
2) Offical Android App
An official one, not a third party app
3) You rocks, guys! I don't have a third wish
@Smark:
2. Linode site reliability. No one has mentioned this, but every time I lose connection to my Linode (which is in Dallas) I immediately check linode.com, which is unavailable. I assume this is because it is also located in Dallas. I usually check status.linode.com but can't remember if that is down also or not. If this isn't actually an issue and just something weird on my end, ignore this.
While I haven't experienced this problem (I think it may be on your end), it's worth noting that status.linode.com is not hosted on a Linode-controlled system. It's hosted by TypePad in Oakland, CA. This is an intentional decision, so that status.linode.com is available even if Linode suffers catastrophic failure. As such, if you can't access both linode.com and status.linode.com, it's almost definitely an issue on your end.
1. More storage!
2. Faster boot and shutdown. I've seen it take up to a minute to shutdown my server.
3. Another datacenter somewhere in asia.
@Guspaz:
While I haven't experienced this problem (I think it may be on your end), it's worth noting that status.linode.com is not hosted on a Linode-controlled system. It's hosted by TypePad in Oakland, CA. This is an intentional decision, so that status.linode.com is available even if Linode suffers catastrophic failure. As such, if you can't access both linode.com and status.linode.com, it's almost definitely an issue on your end.
Well, not if the "catastrophic failure" takes out all 5 nameservers…:P
@mnordhoff:
@Guspaz:While I haven't experienced this problem (I think it may be on your end), it's worth noting that status.linode.com is not hosted on a Linode-controlled system. It's hosted by TypePad in Oakland, CA. This is an intentional decision, so that status.linode.com is available even if Linode suffers catastrophic failure. As such, if you can't access both linode.com and status.linode.com, it's almost definitely an issue on your end.
Well, not if the "catastrophic failure" takes out all 5 nameservers…:P
Sure, but even if all the DNS servers went down for a while, it would take a while for the rest of the net to notice (for the same reason changes take a while to propagate). And, of course, there's the twitter feed, although it seems less for status updates and more for customer interaction these days.
@mnordhoff:
Well, not if the "catastrophic failure" takes out all 5 nameservers…
:P
I have been very happy with Linode for the time I have been using it.. My only suggestion is to keep pace with the pricing in the industry.. So either offer more resource for the same money or make the services cheaper..
There are a lot of VPS offerings out there now, some at half the price of the similar Linode offerings..
I know its hard to truly compare providers and I know Linode are good but at a point it becomes hard to ignore the other providers offerings..
@wipeout:
I have been very happy with Linode for the time I have been using it.. My only suggestion is to keep pace with the pricing in the industry.. So either offer more resource for the same money or make the services cheaper..
Believe me, they have.
Just two years ago, you got half of what you get today for the same price, ie. what used to be a Linode 512 (the smallest service plan) was previously a Linode 360, and a few years before that, it was called "Linode 64". Prices haven't changed over the years, so we've gotten even more for our money at each upgrade.
Whenever there's a big plan upgrade (which seems to happen at least once every year), you only have to reconfigure your Linode (if there will be more disk space available) and reboot it.
Linode has been around for a little over 8 years now, and I've been a customer for almost 7 of them (I now have gone up to 3 Linodes total; 2 in Dallas and 1 in London). Based on the customer service and uptime I get for so "little" per month, I don't plan on leaving.
That said, I wouldn't mind a little extra disk space (managed cloud-type storage, like Amazon S3 and Rackspace CloudFiles) for hosting larger files.
@NeonNero:
Believe me, they have.
http://blog.linode.com/category/upgrades/ Just two years ago, you got half of what you get today for the same price, ie. what used to be a Linode 512 (the smallest service plan) was previously a Linode 360, and a few years before that, it was called "Linode 64". Prices haven't changed over the years, so we've gotten even more for our money at each upgrade.
Whenever there's a big plan upgrade (which seems to happen at least once every year), you only have to reconfigure your Linode (if there will be more disk space available) and reboot it.
Linode has been around for a little over 8 years now, and I've been a customer for almost 7 of them (I now have gone up to 3 Linodes total; 2 in Dallas and 1 in London). Based on the customer service and uptime I get for so "little" per month, I don't plan on leaving.
That said, I wouldn't mind a little extra disk space (managed cloud-type storage, like Amazon S3 and Rackspace CloudFiles) for hosting larger files.
While the upgrades are certainly welcome, a typical Linode disk upgrade isn't really going to fix the problem that many of us have; we don't need another 25%, or 33%, or even 100% more disk, because anything beyond that amount will still be prohibitively expensive. We need the ability to get a substantially larger amount at an affordable price if required, potentially and significantly lower performance (a secondary store for bulk storage doesn't need to be as fast as the disk the database runs on, for example).
Right now I really want to be able to keep my ip when moving datacenters so we can easily find a reliable data center as well as test latency without mass changes.
@Alohatone:
I understand and agree with keeping revenues the same and appreciate the added RAM…
Right now I really want to be able to keep my ip when moving datacenters so we can easily find a reliable data center as well as test latency without mass changes.
That's not possible beacause hierarchical addressing (http://www.freesoft.org/CIE/Course/Subnet/3.htm
2. Expand the Linode API, specifically to include the ability to checked used network transfer.
3. Allow delegation of access to other Linode Manager accounts with a granular permissions system. Meaning, user 'alice' can grant user 'bob' full rights to all her Linodes and user 'charlie' only reboot rights to a particular Linode.
Then, a random nice to have for a particular account but not a big deal:
4. Allow other payment methods, like PayPal or pre-authorized direct withdrawal from a checking account.
And my personal pipe dream:
5. Build a datacentre in Thunder Bay, Ontario, Canada and hire me to help run it.
2. freebsd
3. don't sell out
Did I mention freebsd?
1) I wish disk space was a bit cheaper. If you want to run anything on linode that requires a ton of disk space, the price (even for higher plans) becomes unreasonable and rules out Linode as a practical choice. A reasonable suggestion of prices for add-on disk space would be as follows:
20GB - $5/month
50GB - $10/month
$100GB - $15/month (maybe the absolute max add on space?)
2) 1 Free manual backup for every Linode. For those who have the paid backup service, simply allow 2 manual backups (instead of the current one)
3) I like to use the linode dns as my slave server. For slaves, allow us to view the records linode dns currently holds for such domain. Would help me ensure I have it setup right.
I would echo the others about data storage options. Getting resonable sized storage over the web is much slower than it would be to even use a network storage device from the local network.
A official andriod app. I see the comments here about the unofficial one and won't use it. I also have to wonder if the unofficial one since it is using linode graphics is violating copyrights owned by linode on those images.
I would like to see the notices that we get about resources to contain more information. I keep getting notices about disk i/o rate. I don't mind the default threshold, but it would be really cool if these notifications included things like whats using the io (ie iotop), cpu and other things. It may help capture a out of control process (which I am trying to track down).
@NeonNero:
what used to be a Linode 512 (the smallest service plan) was previously a Linode 360, and a few years before that, it was called "Linode 64".
I still remember the Linode 1, those were horrible - you had to edit the hard drive data by hand using little tiny magnets.
James
@zunzun:
I still remember the Linode 1, those were horrible - you had to edit the hard drive data by hand using little tiny magnets.
Indeed… it was long enough ago that the battle cry was for "More Core!", even using the old-style spelling of "moar". Those were the old days.
@Jeremy-J:
3) I like to use the linode dns as my slave server. For slaves, allow us to view the records linode dns currently holds for such domain. Would help me ensure I have it setup right.
For what it's worth, if you enable zone transfers in the DNS manager, you can always do a 'dig @nsX.linode.com. jeremyj.com. axfr" to see that data. (Of course, so can anyone else!)
1. Augment API to enable linodes to be cloned.
I want to have a single tested image that I can use as a basis for nightly backups to be restored to.
Thus each night the standby linode would be cloned from a standardised base install, and the backups restored to that.
I don't want to re-install the entire thing (as versions in repos might change, it will be slower, etc.) I know that I can 'pin' versions in repos, but there is far more to my configurations than just the setup of a repo. Short of reproducing various repos for myself, and packaging up lots of other software into RPMs for those repos (to ensure availability), it would be far less work for me to simply be able to clone linodes and apply the data changes from the backup.
And as there were several people asking for this a couple of years back, I don't feel my request is too obscure
@hoopycat:
(I'll be back on as soon as I'm caught up with coursework ha ha hahaha why am I in the forums oh god I'm going to fail)
I know exactly how you feel >.>.
@hoopycat:
So, something in the middle. Perhaps NFS to a massive NAS, or something involving
, or both. Or maybe the GlusterFS(Not Affiliated With rsync.net) model would work. rsync IndustriesIt would necessarily be slower than local storage, but that's OK, just as long as it's cheaper and won't impact core service reliability.
Anonymous HTTP access (e.g. S3-style static hosting, perhaps integrated with NodeBalancer?) would still be nice, for those folks still using Apache+mod_php, but… eh, screw 'em.
1. That ^, more or less. Cheaper, necessarily slower add-on storage option(s).
2. More/better short-term billing options. There's a handful of things I'd like to be able to test out on Linodes of varying sizes for a day or two at a time, but it's kind of a pain in the ass to do so at the moment.
3. A datacentre in Australia, or at least somewhere in SEA. In all honesty, dealing with the 200ms-ish latency with US servers isn't that bad for the most part, but it does ruin some otherwise cool ideas.
Considering the submarine cables and their rate of failure (which is not low) DCs should be set up at least on every continent. (Asia, Africa, South America, Australia, etc..) I would accept a slightly higher fee for these (remote?) DCs.
@Alohatone:
1) Datacenter in Hawaii
i know i know, but I'd like to have a cloud here, even if it was small.
i'd fund the rack… we can get 1Gig IP here, but why? start with 100MB. I'll even fund the IP.
Wavecom (telco here put up a cloud in Kona, HI and Honolulu, HI) -
http://wavecomsolutions.com/waveflex/ 2) Management of multiple linode
ability to compress / expand display group of linodes
cumulative graph of all node traffic
support ticket node selection alphabetical (not by order purchased)
3) IPs move between data centers
we understand the bgp issues
without NAT
Linode would have to have a private network on the backend
We love the linode "system" - even if the management interface never changes, that's ok with us. I understand its not worth having the ability to move IPs between data centers (while possible, not worth it)….
I really only have 1 request.
Move to a California InterNap Datacenter and get out of HE.net.
@Alohatone:
We love the linode "system" - even if the management interface never changes, that's ok with us.
Never changes? It was completely replaced less than a year ago.
@rtconner:
These Fremont downtimes are making my clients extremely angry at me. They are my only complaint and they are enough to make me second guess linode and make me look at other options again.
2nd that.
@Alohatone:
@rtconner:They are my only complaint and they are enough to make me second guess linode and make me look at other options again.
2nd that.
Yep. I know a hand full of people doing exactly that at this moment. Incredibly disappointing.
2) Manage multiple linode accounts with one login. I'd like the billing for my private VPS separate from any I manage for someone else. I know, the answer to this before was "you can use the api to manage multiple accts", but this is my wishlist, and I'll put what I want on it.
3) domain registration. yeah, this has been asked for before too.
@sirpengi:
1) Ditch centos and include scientific linux. SL has been way better with keeping things up to date, actually has a security team dedicated to testing upstream packages. If it's good enough for the LHC it's good enough for me.
I can't resist; good enough for the LHC? Are you referring to the same group that engineers things that explode occasionally?
I can't comment on the demand for Scientific Linux, but I would imagine there's more demand for CentOS than you believe exists.
@AVonGauss:
I can't comment on the demand for Scientific Linux, but I would imagine there's more demand for CentOS than you believe exists.
The demand isn't for CentOS, the demand is for a RHEL compatible distro. SL satisfies that just fine (and does it better is what I'm arguing).
@sirpengi:
The demand isn't for CentOS, the demand is for a RHEL compatible distro. SL satisfies that just fine (and does it better is what I'm arguing).
Wrong. I don't want SL, I want CentOS. You need to stop telling people what they want.
(Unlike, say, stable releases and security updates. OK, that was a low blow…)
@Piki:
Using only one datacenter is like putting all your eggs in one basket. Best to have a server in at least two or three different physical locations for your important stuff. I doubt Google would have lasted this long with only one datacenter, they'd be lagging to a standstill if they tried that, not to mention all the hackers, and the high possibility of losing service altogether
:)
And on that note, since I can't believe nobody has said it yet, remote backups.
Regards,
Lloyd D.
2. Add second ethernet interface for private network
3. Add ability to manage several accounts from one user id
* More storage please please please~
Pooled storage space: just like bandwidth, storage space could be pooled across all Linodes.
More sensible extras pricing options. Right now, if I wanted to add a year's worth of extra 200 GB/month of bandwidth to my Linode 512, I could either:
- * Add the "+200 GB/month" extra (price: +$240/year)
- Upgrade my Linode 512 to a Linode 1024 (price: +$240/year) One option gives the extra bandwidth.
The other option, for the same price, doubles the bandwidth, and doubles the RAM, and doubles the storage, and moves the Linode to a less crowded server. Why would anyone pick the extra?
@WindPower:
* More storage please please please~
Pooled storage space: just like bandwidth, storage space could be pooled across all Linodes.
More sensible extras pricing options. Right now, if I wanted to add a year's worth of extra 200 GB/month of bandwidth to my Linode 512, I could either:
* Add the "+200 GB/month" extra (price: +$240/year)
- Upgrade my Linode 512 to a Linode 1024 (price: +$240/year) One option gives the extra bandwidth.
The other option, for the same price, doubles the bandwidth, and doubles the RAM, and doubles the storage, and moves the Linode to a less crowded server. Why would anyone pick the extra?
Because the extras can be enabled very quickly, either with a reboot, or in the case of extra transfer, instantly. The bandwidth extra is pointless anyhow, since excess bandwidth as you go is billed at the same price as the extra.
If you need the extra resources long-term, upgrade your linode (which can take a bit longer). If you need them on very short notice, you can temporarily upgrade your linode.
@Guspaz:
@WindPower:
* More storage please please please~
Pooled storage space: just like bandwidth, storage space could be pooled across all Linodes.
More sensible extras pricing options. Right now, if I wanted to add a year's worth of extra 200 GB/month of bandwidth to my Linode 512, I could either:
* Add the "+200 GB/month" extra (price: +$240/year)
- Upgrade my Linode 512 to a Linode 1024 (price: +$240/year) One option gives the extra bandwidth.
The other option, for the same price, doubles the bandwidth, and doubles the RAM, and doubles the storage, and moves the Linode to a less crowded server. Why would anyone pick the extra?
Because the extras can be enabled very quickly, either with a reboot, or in the case of extra transfer, instantly. The bandwidth extra is pointless anyhow, since excess bandwidth as you go is billed at the same price as the extra.
If you need the extra resources long-term, upgrade your linode (which can take a bit longer). If you need them on very short notice, you can temporarily upgrade your linode. I can see instant extras being useful for times when you get slashdotted or something like that, where you do need some extra power and certainly don't want long downtime, but this only lasts a week at most. So why have only monthly and yearly plans for extras? I guess my third wish could then be reformulated as "have more granular pricing options".
1) Add native ext4 support. I'm missing your backup service because you don't support ext4 which I'm using and which is better than old ext3 in almost every aspect.
2) Add write barrier support. It will definitely help with data integrity for people, who run unstable systems or use Freemont data center with built-in reboots
3) Update your recovery distro because it is really very, very outdated. Because of this, I'm using 2gb portion of precious hdd space to house another deployment which I will be able to use in case of emergency to diagnose/repair my production deployment.
@Net-burst:
3) Update your recovery distro because it is really very, very outdated. Because of this, I'm using 2gb portion of precious hdd space to house another deployment which I will be able to use in case of emergency to diagnose/repair my production deployment.
2 gigs? You can fit a bare debian install in like 400 megs.
@Net-burst:
2) Add write barrier support. It will definitely help with data integrity for people, who run unstable systems or use Freemont data center with built-in reboots
:)
Erm… I believed the RAIDs in servers are battery-backed?
@Net-burst:
3) Update your recovery distro because it is really very, very outdated. Because of this, I'm using 2gb portion of precious hdd space to house another deployment which I will be able to use in case of emergency to diagnose/repair my production deployment.
Finnix 100 was, so I wouldn't exactly call it "very, very outdated" quite yet. What's missing from version 100 that's nice to have for recovery? (Aside from the pvops-compatible kernel.) released less than a year ago
@hoopycat:
Finnix 100 was
, so I wouldn't exactly call it "very, very outdated" quite yet. What's missing from version 100 that's nice to have for recovery? (Aside from the pvops-compatible kernel.) released less than a year ago
Hm. Haven't checked it in a while. Last time I used Finnix, it destroyed my ext4 partitions because it had outdated e2fsprogs or something like that…
@OverlordQ:
@Net-burst:3) Update your recovery distro because it is really very, very outdated. Because of this, I'm using 2gb portion of precious hdd space to house another deployment which I will be able to use in case of emergency to diagnose/repair my production deployment.
2 gigs? You can fit a bare debian install in like 400 megs. Barebone install of Arch Linux fits in about 150 megs. But with all needed tools and software it jumps to around 500-750. Rest of space is generally there just in case. For example for when I need to recompile kernel from within recovery deployment.
@rsk:
@Net-burst:2) Add write barrier support. It will definitely help with data integrity for people, who run unstable systems or use Freemont data center with built-in reboots
:)
Erm… I believed the RAIDs in servers are battery-backed? That I dont know. But it wont hurt to have bigger degree of data security.
@Net-burst:
Arch Linux
Understood. Carry on.
@Net-burst:
@rsk:
@Net-burst:2) Add write barrier support. It will definitely help with data integrity for people, who run unstable systems or use Freemont data center with built-in reboots
:)
Erm… I believed the RAIDs in servers are battery-backed? That I dont know. But it wont hurt to have bigger degree of data security.
I'm not an expert in this regard, but as our "disks" are LVM units on top of a RAID that you share with all other Linodes, I believe barrierwould have to require flushing the controller's cache, and kill performance for everyone. And, I believe that battery-backed controllers exist for exactly this reason - to make data safe without need to flush caches.
One nice service would be "Pretend to be a cracker and look for vulnerabilities." I.e., someone would check my Linode for me and make sure there aren't any security flaws.
It probably could be automated via a script.
For example, I was SHOCKED at how many people try to grab phpmyadmin, which I never installed. It would have been nice to hear "Hey! Don't use phpmyadmin!"
@Smark:
2. Linode site reliability. No one has mentioned this, but every time I lose connection to my Linode (which is in Dallas) I immediately check linode.com, which is unavailable. I assume this is because it is also located in Dallas. I usually check status.linode.com but can't remember if that is down also or not. If this isn't actually an issue and just something weird on my end, ignore this.
I've had a linode in Dallas for 6+ months and it is very solid. I monitor with multiple services that watch the server every minute from multiple locations around the world (i.e. pingdom, wasitup) and I've had almost no interruptions in service (besides a couple short outages that were my fault; e.g. config errors, os level issues). I saw a couple 3 to 4 minute network glitches this summer, where my server stayed up and running, but I could not reach the network for a couple minutes. I think both of those were in the middle of the night. I have no idea how wide spread the glitch was, it's possible it was just the host I was on, though as mentioned, my linode didn't go down.
I just wanted to say that if there are / were any problems with Dallas, they are / were very infrequent and very short.
Jamie
@fsk:
I'm a relatively new UNIX admin. I've never been root before.
One nice service would be "Pretend to be a cracker and look for vulnerabilities." I.e., someone would check my Linode for me and make sure there aren't any security flaws.
Google SATAN
Make sure you know what you are doing, it is easy to start violating hosts and networks you don't have the right to access or probe.
@sirpengi:
3) domain registration. yeah, this has been asked for before too.
imo… There is no reason for Linode to get into registration. There are many good registrars out there right now.
I'm using Moniker, though I think they cater to people that have more than just a few domains. I only pay a tiny amount higher than what the registrar pays for domains. There isn't much profit in domain registrations, many of the registrars use domain registration as a loss leader for their other services.
I think to make domain registration worth it for linode to do, they would likely have to charge more than you would pay at other registrars.
Jamie
@hoopycat:
@Net-burst:Arch Linux
Understood. Carry on.
You may not believe it, but Arch is quite good server platform and is used quite frequently by russians as such. Also, if you look closely, you will see that almost all VPS providers provide not only Debian/Ubuntu/CentOS but also Arch and Gentoo. Heck, Google uses Gentoo quite frequently. Their ChromeOS is entirely based on Gentoo:)
@rsk:
I'm not an expert in this regard, but as our "disks" are LVM units on top of a RAID that you share with all other Linodes, I believe barrierwould have to require flushing the controller's cache, and kill performance for everyone. And, I believe that battery-backed controllers exist for exactly this reason - to make data safe without need to flush caches.
I'm also not an expert, but if VM just suddenly shuts down or hangs, you will have corrupted data if you had write event to file system, that wasn't flushed. And this can happen to anyone because inside VM disk writes are also cached. Battery-backed RAID is needed to sustain integrity of RAID itself and flush all data from cache of RAID itself. But we also have VM cache:)
@Net-burst:
I'm also not an expert, but if VM just suddenly shuts down or hangs, you will have corrupted data if you had write event to file system, that wasn't flushed. And this can happen to anyone because inside VM disk writes are also cached. Battery-backed RAID is needed to sustain integrity of RAID itself and flush all data from cache of RAID itself. But we also have VM cache
:)
The combination of journaling filesystems and the BBU RAID should prevent any filesystem corruption, but you could certainly have application level data that did not make it to the disk if it was only held in in-memory buffers (at any level) at the time of failure. But that's the application's fault, as without application flush requests, there's never any guarantee about data consistency on media.
On any system, those applications that require such consistency should be handling it themselves with explicit flushing, and nothing you can impose externally can correct things if they don't. Consistency has to start at the top, from the application. Databases (at least ACID-compliant ones), for example, usually have their own level of journaling which is flushed prior to writing any actual record data. (I suppose arguably that case could then be considered corruption on restart, but the database will just replay the journal and no data will be lost) Even a simple logging application needs to use flush if it wants any assurance that the data has been written, regardless of what's happening beneath it at system level. The flush may not turn out to be sufficient, but it's required.
The problem with modern disks, and what write barriers were introduced to help address, is that the disks themselves may cache and reorder data writes, so that even when the filesystem driver believes it has written data to its journal or in proper order (which the application level flush is then trusting to mean its data is on physical media), it may only exist in the drive's cache, and a sudden outage may end up with that data never making it to the disk media. The write barrier prevents the filesystem driver from writing any further data until the disk guarantees prior data has hit the media successfully (and assuming the disk isn't fibbing, which some have in the past). Unless you're on an LVM volume, which I believe does not currently pass barrier requests through to the media.
However, the BBU on the arrays in the Linode case solves this in a separate way. It's there to ensure that at a minimum any data currently held by its cache is persisted until the following reboot, at which point it will be immediately written to media prior to any other operations. So (at least theoretically) there's no way for data not to reach media once the filesystem driver has handed it to the drive array, and barriers would offer no particular benefit, except likely slowing down the application while it waits in a shared environment for the data to be written to media. Some early measurements had the hit as high as 30% for some workloads and I don't think that was even in a shared environment. Now, the BBU isn't quite an absolute guarantee (it could fail, or the disks could be offline longer than it can maintain the cache - probably a few days at most) but it's pretty darn good, and the most critical applications will have their own way of dealing with actual corruption in such rare cases, ala databases above.
Perhaps a more succinct way to think of it is that barriers were introduced when you couldn't trust your disks, but rather than barriers, a BBU just lets you trust your disks again. And without the performance hit barriers introduce.
While I'm not 100% sure, I also don't believe barriers have any impact on the point of higher level application data consistency since applications would still need to have flushed their internal data (otherwise the filesystem driver might not yet have chosen to write the data itself). The barrier option in ext4 for example, affects the journal commit record (and data sent to the disk prior to that point), but not unflushed in-memory cache data. So appropriate flushing is needed barrier or not. I'd certainly want any application whose consistency I cared about to be written to explicitly flush data it required to be stored.
– David