Stallion 2 - pictures and daily updates :)
- Thread starter Francisco
- Start date
Yep. I took some ideas from the original one to build the new one. The new one uses bootstraps
framework though so it collapses properly on low resolution devices.
Welcome to the forums and let me know if you catch any glaring bugs/interface suggestions.Going to have a read through the last couple pages, hope it's going well.
That was my focus yesterday. The virtual server overview page got a fairly big overhaul solooks perfect on my Android phone. I am jealous
it properly collapses on other resolutions. It took a bit of getting used to since I removed
one of the columns.
Nothing concrete yet but I think Aldryic is pretty close to getting the WHMCS module completed.Any time you care to drop a release date... I'll be anxiously refreshing my Stallion on said day
Francisco
D. Strout
Resident IPv6 Proponent
For sureI can't wait till the day that billing is integrated - that'll be even better
We'll likely automate 99% of the options too.
Users will put credit on their account and then there will be a billing tab on each virtual server
where they can buy space/ip's/filtered ip's, change plans, or cancel.
If a users account is in fully approved status the upgrades/etc will be automatically approved and assigned.
New VM's ordered will be the same.
Francisco
D. Strout
Resident IPv6 Proponent
/me drools
What about IPv6? I thought you might have mentioned giving each user a /64, then enabling individual address allocation automatically through the CP. Or was that just my imagination? I would think there might be some trouble with that on non-OpenVZ, though...
What about IPv6? I thought you might have mentioned giving each user a /64, then enabling individual address allocation automatically through the CP. Or was that just my imagination? I would think there might be some trouble with that on non-OpenVZ, though...
This is one of those 'early after launch' features that we have planned
To make our lives easier we'll likely do something where when the user requests a /64, it'll be an all or nothing kind of deal. You'd have to return the ip's we randomly assign out and you'd assign yourself out of your /64.We'll have to setup a 2nd router in each location that handles just IPV6 end points but I can use vyatta, etc for that. I really don't want to be binding thousands of subnets on our core router or anything
Francisco
Nope.
It'll be automated. I'll likely add it on the dashboard where it'll list your subnet for each location. If you don't have a sub? You can 'provision' one and it'll do so. If you do have one, it'll link to another page where you can manage the subnet (mass add ip's, pick specific ones (dead.beef 4 lyfe), assign ip's to certain vm's, etc).
I was thinking about trying to add the add controls onto vserver/*/ipaddresses page but I feel it's going to become very crowded and hard to use.
Input?
Francisco
D. Strout
Resident IPv6 Proponent
I don't think it would be too crowded. As I see it, under [...]/ipaddresses, you have the IPv4 "tab", then if a person has a /64 (or two) the IPv6 tab instead of just a number says "/64 x 2" (or whatever) and instead of showing the interface for individual addresses it shows an interface set up for managing the /64. For that I'd like to suggest a "random address" button, which will generate a random address in the /64 to be assigned to the VM.
Also, just a little thing, but IMHO you should show the abbreviated version of IPv6 addresses.
Also, just a little thing, but IMHO you should show the abbreviated version of IPv6 addresses.
For a single virtual server it'd show the /64 for the region that VPS is bound to. Remember, users can't have more than a single /64 per region (for now).
I could likely just add a modal to handle 'specific ip address'. I'll see about making it display the compressed IPV6
Could you add that as a bug to the panel?Francisco
D. Strout
Resident IPv6 Proponent
Whatever way you do it I'm sure it will be brilliantFor a single virtual server it'd show the /64 for the region that VPS is bound to. Remember, users can't have more than a single /64 per region (for now).
I could likely just add a modal to handle 'specific ip address'. I'll see about making it display the compressed IPV6
Francisco
I've added the IPv6 address display bug.
Right now i'm going over things on IRC on how to make the interface easier on mobile devices.Whatever way you do it I'm sure it will be brilliant
We're thinking that the tabs for the sections of /vserver/ should disappear when you're on a mobile device
and instead we should add a dropdown nav in the top nav. We'd rename 'virtual servers' to 'dashboard' or something then have like 'hostname' -> (bunch of menu options).
My biggest issue with the current tabs is they can be hard to click since they wrap on themselves.
I could probably code something to make them compact into a select box and not shove it in the header? That might be nicer.
Francisco
D. Strout
Resident IPv6 Proponent
Well, now you're outside my area of interest. I don't have a really "mobile" device. Even the Kindle Fire I was using earlier was borrowed. My philosophy is that if you're going to be managing your servers, you should do it from a platform where you can see what you're doing
Still, your idea does seem to be slick, collapsing like that. I'm all for it.
Still, your idea does seem to be slick, collapsing like that. I'm all for it.
acd
New Member
Floating IP's isn't quite that...yet
Right now IP's are hard bound to a virtual server. The idea behind floating IP's is that an IP can be bound to multiple VM's w/o issue for the sake of high availability.
Once billing merges we'll likely allow 'moving' of IP's between servers. That's entirely up to Aldryic though.
Francisco
I think if we wanted to allow IP moving we'd need to move to 'pooled bandwidth' between all virtual servers.
So, you buy 5 VPS servers with 500GB each. Your 'pool' would be 2.5TB that can be shared any which way.
By default a vm would come with a user settable "hard cap" of whatever the plan came with. If they want
to make use of the pooling they can simply disable that and bandwidth is used up as needed.
We'd need to likely introduce 2 pools for users. 'Monthly recurring' & 'additional one off usage'. The monthly
pool would reset based on their plans and the one-time stuff would be 'I bought 1TB of additional transit since I need it'.
You'd be able to buy bandwidth against an account or against a virtual server. Against the vserver it would
become part of the accounts recurring transit where as 'buying it against the account' goes to the one-off.
I think I might be confusing people though <_<
Francisco
So, you buy 5 VPS servers with 500GB each. Your 'pool' would be 2.5TB that can be shared any which way.
By default a vm would come with a user settable "hard cap" of whatever the plan came with. If they want
to make use of the pooling they can simply disable that and bandwidth is used up as needed.
We'd need to likely introduce 2 pools for users. 'Monthly recurring' & 'additional one off usage'. The monthly
pool would reset based on their plans and the one-time stuff would be 'I bought 1TB of additional transit since I need it'.
You'd be able to buy bandwidth against an account or against a virtual server. Against the vserver it would
become part of the accounts recurring transit where as 'buying it against the account' goes to the one-off.
I think I might be confusing people though <_<
Francisco