<mhoran>
[mhoran@ilectra] ~/arpcli% ./bin/arpcli status --json | grep created_at
<mhoran>
"created_at" : "2009-06-11T08:59:49Z",
<mhoran>
"created_at" : "2010-07-11T09:54:03Z",
<mhoran>
"created_at" : "2019-03-08T21:44:15Z",
<mhoran>
It works! There’s an additional dep not in the README, YAML::PP, and I had to remove the META_MERGE bit from the Makefile.PL since it referenced your home directory (I couldn’t get it to work with my home directory either? Something about invalid URL. IDK,worked when I removed it.)
<mhoran>
up_the_irons: I noticed 2643bda0-6f00-012d-0863-525400972102 is on an old small plan with 1 VCPU vs the current 2 VCPU on all my other VMs. I can’t update it though, I get an error.
<up_the_irons>
Whoa what's this arpcli
<up_the_irons>
mhoran: what's the error?
<up_the_irons>
Oh I see the error now. It's because your custom VNC password does not validate with the new schema. This is some strange libvirt regression that happened at some point...
<up_the_irons>
If you let me reset the password, I can get it working
<up_the_irons>
I got arpcli working too!
<mhoran>
up_the_irons: no problem, go ahead and reset the password!
<todd>
up_the_irons: github.com/toddfries/arpcli .. I went a little token heavy with grok build and maestro'ed it into existence
<todd>
fixed arpcli based on feedback above. sorry 'bout that ;-)
<todd>
I know the api is new. Looking forward to when the roadmap gets to 'add ons' ;-)
<todd>
.. pushed some formatting knits. now 'plans' and 'servers list' looks more aligned ;-)
<up_the_irons>
mhoran: reset commenced! give the VM a hard reboot, then you should be able to change your CPU count
<up_the_irons>
todd: token heavy, hahaha i like this term
<up_the_irons>
Do you mean, the add-ons for CPU/RAM/Disk ?
<up_the_irons>
I've submitted an application to projects.dev for us to be considered for inclusion as a Provider. If anyone wants to recommend us, click "Suggest a provider" there (yes, it's just an email link)
<todd>
up_the_irons: I mis-spoke. My brain acted like an AI. Remembered the tokens, spoke the meaning from the tokens, forgot your term is 'Power Ups' not 'Add Ons'
<todd>
echo "arpnetworks.com rules!" | mail -s "Provider Request" provider-request@stripe.com
<up_the_irons>
Lol awesome echo
<up_the_irons>
todd: I enabled beta features for your account, so you'll now see power ups can be adjusted per VM (CPU/RAM/SSD) in the UI. Not accessible from the API (yet), but we're getting close :)
<todd>
oh. so api feeds ui or ui has its own api. kinda like web for x.com has its own api and "official api" is different?
<todd>
the ultimate flex is to have your ui eat the same api you're giving to us... ;-)
<todd>
if I had one wish it would be to do a hetzner datacenter build in the us and put arpnetworks in charge. I will limit my whines to twice a decade but .. your so reliable .. but I can get egads more ram/disk/cpu for less at hetzner due to their scale I guess .. I just don't have the cash flow to care I'm across the pond.
<todd>
one application I'd love to scale is hostd from sia. earn crypto (Sia Coins, SC) by maintaining a daemon that uses the blockchain to settle contracts and fees for storage. If 1GB < $3/mo it's potentially profitible.
<todd>
of course if you really wanted to go out of this world there's always the new frontier of datacenters (especially after Starship is fully operational).
<todd>
so much 'fun' to be had, so little time!
<up_the_irons>
I actually disagree about the frontend consuming our own API. I intentionally didn't design it that way, because that would make the UI slow, and smell like every React app. I can't stand skeleton loaders. Something invented solely because "kids these days" decided that frontends should be pushed completely to the browser and backends should only serve JSON. Anyway get off my lawn lol
<up_the_irons>
But I understand what you mean in spirit
<up_the_irons>
Doesn't Hetzner have some stuff in the US now...
<todd>
from a consumer, it seems redundant to design one ui way of interacting with the system and another consumer facing api to .. do the same thing .. but with consumer apps in mind ..
<up_the_irons>
If you want cheap specs, definitely go there. I even have some VMs there. It's good if reliability isn't your first priority
<todd>
but I'll believe you when you say that lazy work ethic doesn't match reality well ;-)
<todd>
thats a hezner root server. *shrug*. but I ack the quality difference in immeasurable ways.
<up_the_irons>
I had a server with over 3000 days of uptime on our own platform
<up_the_irons>
Sad I had to turn it off
<up_the_irons>
Run IPFS on Hetzner and you'll be introduced to how big of assholes they are. I finally gave up arguing with them, and shut down my dedicated server there
<todd>
I believe it. vm hosts can do that. the economy of scale of a big datacenter that would reduce pricing is mainly my point at using hetzner as a thing I might even enjoy setting up .. life has that funny way of saying 'no, you got all these other commitments..'
<todd>
I've not had the pleasure of arguing with them. Guess I've not gathered their attention yet. by the time I do I better be earning enough to not care and already diversified my eggs in more than one basket ;-)
<todd>
I've heard stories though. so it doesn't surprise me.
<up_the_irons>
Our API is basically a thin wrapper around the same controllers and services that serve the Phoenix UI. So I think in that sense, we don't have two redundant systems doing the same thing. Otherwise it would be a pain to maintain
<todd>
quality can be measured in "does your plex server get blacklisted by the plex community based on the ASN?" and the answer is "yes. yes it did."
<up_the_irons>
Yeah they have the economies of scale for sure
<up_the_irons>
Yeah that's one hazard :)
<todd>
As a separate but hosting related topic, I offer the following wisdom:
<todd>
1) if you ever want to host a mail server, and are sending mail to google, and let authenticated users that pay you for the service relay through your mail server, watch it like a hawk.
<up_the_irons>
Anyway, to say something good, I think their new console is really nice to use actually. I like that it shows a map of where your servers are haha
<todd>
2) if you ever fail to do so and exceed 5000 messages per day, you will auto get put into 'bulk sender' category with no going back
<up_the_irons>
Ouch
<todd>
3) if you ever get put into 'bulk sender' category, you _must_ now use spf + dkim + dmarc or you loose. every mail rejected, domain gets a bad rap, and even relaying through others that can send to google fails to go through due to domain rep.
<todd>
4) every rejected email counts _against_ your rep. circle of death.
<todd>
I'm right now upgrading a client's systems so they can do dkim and attempt to get out of that trap.
<todd>
oh and the 'postmaster tools' they provide to monitor the situation has a very long ttl on checking dns for updates.
<todd>
'host -t txt _dmarc.example.com' works in the wild any checker sites out there as of 5 mins after I added that to dns. but days later that postmaster.google.com site still shows a big red flag for DMARC as if I didn't do it yet. Grok tried to tell me 7d refresh, I'm hoping not, but looking like its true.
<up_the_irons>
Yeah I had to do that whole dance for several domains, including our own. There's definitely a huge delay.