Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Looking for some beta testers for our new Wyvern release and KVM services (again). - Page 2
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Looking for some beta testers for our new Wyvern release and KVM services (again).

2»

Comments

  • KuJoe said: I don't want this thread to go any more off topic than it already is.

    No, its not offtopic, you only avoid answer.

  • KuJoeKuJoe Member, Host Rep

    @Bochi said:

    @KuJoe said:

    @Bochi said:
    Hey @KuJoe, are the nearly 16GB of allocated RAM a bug or is this just the setup hidden behind the "KVM-SSD-512M" for testing? :P

    It should be 512MB allocated with a max limit of 16GB. I'll set the max limits to match the RAM for the service.

    Well, this might explain it. :)

    In other news: I added a few IPv6 via the panel (one selected and 10 random ones in a batch).
    It took the panel quite some time to come back and now there is no way to start the server again. Whatever button I hit, it seems to stay offline.
    So I removed all of them, but the VPS still shows as offline and start / stop / restart doesn't seem to have any effect.
    This said, I find the usability at this very point to be kind of a PITA. You can add the v6s in a batch, but you have to remove them one-by-one and everytime the page gets reloaded and you have to navigate to the respective tab again.

    I believe the delay is from having to ping each IP before assigning it to a VPS, I'll look into this to see if I can reduce the delay.

    Can you send me some info about your VPS so I can check to see why it might be offline?

    As for removing the IPv6 addresses, I will look into adding a checkbox system or something but it's harder to run a "bulk" remove since somebody can add hundreds of IPs and then try to remove them all at once which will result in Wyvern timing out and potentially breaking something. I think I might have an idea though but it won't be until down the road.

  • WSSWSS Member

    @KuJoe Why are you bothering to ping the address, first? Why not have them in a nice usable Redis table you can pull/remit to, and a background process which writes to DB?

  • KuJoeKuJoe Member, Host Rep

    @jenkki said:

    KuJoe said: I don't want this thread to go any more off topic than it already is.

    No, its not offtopic, you only avoid answer.

    Yes it's completely off topic for this thread. Sorry.

  • KuJoeKuJoe Member, Host Rep
    edited April 2017

    @WSS said:
    @KuJoe Why are you bothering to ping the address, first? Why not have them in a nice usable Redis table you can pull/remit to, and a background process which writes to DB?

    I blame SolusVM, ever since I used SolusVM I now lose sleep at night thinking IPs are being assigned to multiple clients. For OpenVZ it will throw an error but for KVM it lets both clients use the IP and they each just get packet loss and can sniff the other's traffic. SolusVM was notorious for assigning IPs but not marking it in the database so now I have that fear in the back of my mind that Wyvern will assign an IP and right before it can be updated in the database something breaks and then two clients will get the same IP eventually. SolusVM would assign an IP that was in use for months to a new client and then piss of our old client when their traffic was being sent to somebody else.

    Thanked by 2WSS mikho
  • WSSWSS Member

    @KuJoe said:
    I blame SolusVM, ever since I used SolusVM I now lose sleep at night

    I thank god every day that I'm not (yet) back in this industry. I'm guessing that there's no cohesive way to parse through the Solus DB to see what it currently has set and just setup a background "Did you take my IP" process?

    This reminds me when Someone was having issues with Solus repopulating old data into host settings after migrating them to another node. We never got an answer what or where that came from- but there was a patch that "fixed it". My guess is that they used some magic temp db/file structure to store that to work around a DIFFERENT bug, then forgot to actually fix it.

  • BochiBochi Member

    KuJoe said: Can you send me some info about your VPS so I can check to see why it might be offline?

    Sure, I'll send you a PM shortly.

    @KuJoe said:

    @WSS said:
    @KuJoe Why are you bothering to ping the address, first? Why not have them in a nice usable Redis table you can pull/remit to, and a background process which writes to DB?

    I blame SolusVM, ever since I used SolusVM I now lose sleep at night thinking IPs are being assigned to multiple clients. For OpenVZ it will throw an error but for KVM it lets both clients use the IP and they each just get packet loss and can sniff the other's traffic. SolusVM was notorious for assigning IPs but not marking it in the database so now I have that fear in the back of my mind that Wyvern will assign an IP and right before it can be updated in the database something breaks and then two clients will get the same IP eventually. SolusVM would assign an IP that was in use for months to a new client and then piss of our old client when their traffic was being sent to somebody else.

    But is this really a problem in this case?
    You are assigning a proper /64 anyway and let only choose from that one, so ideally there shouldn't be any conflicts. But better safe than sorry I guess.
    And regarding the timeout: Maybe spawn a background process and simply disable the tab for the time beeing?

    And regarding the API: Any chance for some basic documentation to play around with it?

  • @KuJoe damn I forgot to add my username on the order, sorry KuJoe

  • KuJoeKuJoe Member, Host Rep

    @Bochi said:

    But is this really a problem in this case?
    You are assigning a proper /64 anyway and let only choose from that one, so ideally there shouldn't be any conflicts. But better safe than sorry I guess.

    Right now I just have a single function for checking IPv4 and IPv6 for both OpenVZ and KVM, I can probably break that out into separate functions and disable the pinging requirement for IPv6 since you're right and all of the IPs will be on the same /64.

    And regarding the timeout: Maybe spawn a background process and simply disable the tab for the time beeing?

    I'm planning on doing a rewrite once I get KVM working properly that will offload a lot of the heavy lifting to the nodes themselves which will improve performance but will reduce error checking. If I had a better grasp of AJAX I could make the control panel much better but my knowledge of JS is pretty limited.

    And regarding the API: Any chance for some basic documentation to play around with it?

    Right now it just reports bandwidth usage. Nothing fancy but the framework is there for me to eventually add more functionality to it.

  • jtkjtk Member

    @KuJoe - Should we provide feedback here, to a specific email address, or via your ticketing system?

  • @twiigl said:
    My order got cancelled even I've passed maxmind check, why?

    The only orders I've cancelled have been ones without their LET username in the order notes.

    I guess then it was a problem with whmcs, my browser or something different. Had submitted my details, my number was in wrong format and some fields got cleared, but not all, so maybe also the notes with the let-username.

  • jackbjackb Member, Host Rep
    edited April 2017

    @KuJoe said:

    @WSS said:
    @KuJoe Why are you bothering to ping the address, first? Why not have them in a nice usable Redis table you can pull/remit to, and a background process which writes to DB?

    I blame SolusVM, ever since I used SolusVM I now lose sleep at night thinking IPs are being assigned to multiple clients. For OpenVZ it will throw an error but for KVM it lets both clients use the IP and they each just get packet loss and can sniff the other's traffic. SolusVM was notorious for assigning IPs but not marking it in the database so now I have that fear in the back of my mind that Wyvern will assign an IP and right before it can be updated in the database something breaks and then two clients will get the same IP eventually. SolusVM would assign an IP that was in use for months to a new client and then piss of our old client when their traffic was being sent to somebody else.

    Wouldn't it be quicker to check the ARP cache on the node than to ping? You could probably just pull & cache the ARP cache when you poll a node for its status and check that on the master.

    Thanked by 1WSS
  • To reduce amount of tickets, it might be also a good thing to setup DNS server on the host node as most of the installers try to use gateway IP as DNS server.

  • KuJoeKuJoe Member, Host Rep

    @jtk said:
    @KuJoe - Should we provide feedback here, to a specific email address, or via your ticketing system?

    You can reply here or open a ticket, whichever is easiest for you.

    @jackb said:

    >

    Wouldn't it be quicker to check the ARP cache on the node than to ping? You could probably just pull & cache the ARP cache when you poll a node for its status and check that on the master.

    It might be, I'll look into it. :)

    @MrPsycho said:
    To reduce amount of tickets, it might be also a good thing to setup DNS server on the host node as most of the installers try to use gateway IP as DNS server.

    Thanks for the suggestion but that would require running the DNS servers on the routers and some of the routers we do not have access to.

  • WSSWSS Member

    @KuJoe said:

    @MrPsycho said:
    To reduce amount of tickets, it might be also a good thing to setup DNS server on the host node as most of the installers try to use gateway IP as DNS server.

    Thanks for the suggestion but that would require running the DNS servers on the routers and some of the routers we do not have access to.

    My take on this is anyone too ignorant to read and type in '8.8.8.8', et al, shouldn't have the service, anyhow. Secondly, you could always just forward port 53 on the host itself to a nameserver, but that would likely annoy people who want a local resolver, thus my first point remains.

  • WSS said: My take on this is anyone too ignorant to read and type in '8.8.8.8', et al, shouldn't have the service, anyhow.

    Somehow you are right, but in the same time you forgets that it is a commercial product. The more users, the more profit.

    IMO forwarding to 8.8.8.8 is a good solution. I'm sure that there will be more users taking adventage of it, than users who will get "annoyed" because it's not local.

  • KuJoeKuJoe Member, Host Rep

    @MrPsycho said:

    WSS said: My take on this is anyone too ignorant to read and type in '8.8.8.8', et al, shouldn't have the service, anyhow.

    Somehow you are right, but in the same time you forgets that it is a commercial product. The more users, the more profit.

    Kinda. The more advanced users the more profit, the more novice users the less profit. If users have to open a support ticket for things like DNS servers they probably won't be renewing because the support fees we'd charge them for other simple tasks would make it more expensive than a fully managed service.

    IMO forwarding to 8.8.8.8 is a good solution. I'm sure that there will be more users taking adventage of it, than users who will get "annoyed" because it's not local.

    I will look into this. Once I roll out DHCP in the future it wouldn't be needed though.

  • BochiBochi Member

    @KuJoe said:

    @Bochi said:

    But is this really a problem in this case?
    You are assigning a proper /64 anyway and let only choose from that one, so ideally there shouldn't be any conflicts. But better safe than sorry I guess.

    Right now I just have a single function for checking IPv4 and IPv6 for both OpenVZ and KVM, I can probably break that out into separate functions and disable the pinging requirement for IPv6 since you're right and all of the IPs will be on the same /64.

    Good to hear, that you are thinking about solutions! :)

    Another question regarding v6 at this point:
    Is there anything else to do other than assigning an address and configuring the interface of the VM accordingly?
    Somehow I can't even ping the gateway afterwards...

  • KuJoeKuJoe Member, Host Rep

    @Bochi said:

    Another question regarding v6 at this point:
    Is there anything else to do other than assigning an address and configuring the interface of the VM accordingly?
    Somehow I can't even ping the gateway afterwards...

    You shouldn't have to, I'll check the code though because I think I might know what the issue is.

  • -.- forgot to include my LET username. Should be obvious from my email though.

  • KuJoeKuJoe Member, Host Rep
    edited April 2017

    @sabbo2001 said:
    -.- forgot to include my LET username. Should be obvious from my email though.

    Unfortunately if there are no notes on the order it gets cancelled. Sorry. :(

    You can place a new order with your username though. :)

Sign In or Register to comment.