7 ms·

Tried it. Docker wasn't preinstalled so asked Claude to do it and make sure it's running (supervisord or the likes isn't preinstalled). It neatly did so and "r

by raro11 8mo ago

Tried it. Docker wasn't preinstalled so asked Claude to do it and make sure it's running (supervisord or the likes isn't preinstalled). It neatly did so and "registered" it as a sprite service. Then I exited my session, waiting for the sprite to go idle, but I don't think it ever does.. Still have it active. Don't know how to idle it. Can't tell for sure if this means I'm losing credits as there is no billing usage shown anywhere. Also waiting for the moment where I can launch a sprite from another's checkpoint.

chrismccord 8mo ago
We had a bug where some sprites would fail to properly suspend while entering their suspended state. You're not eating into credits so no worries there. We've been rolling out a fix across the fleet today so you should be seeing proper status soon.
- karmajunkie 8mo ago
  This is great news! If we upgraded our sprite already how long should it take to suspend? I noticed the upgrade earlier and installed it but my sprite is still running.
  - karmajunkie 8mo ago
    ahh finally success—a fresh sprite goes to sleep as it should. unfortunately the original one i created doesn't, so I guess I'm going to have to kill that one off.
ktaraszk 8mo ago
Just use container-os as your runtime image: https://hub.docker.com/r/miget/container-os https://hub.docker.com/r/miget/container-os and you should be good
- zrail 8mo ago
  Could you explain more about how this helps and how one might use a different runtime image on Sprites?
  - redcmd 8mo ago
    I don't think you can choose the runtime image on Sprites, not sure what they are referring to here.
panarky 8mo ago
There's no way to stop sprites from the CLI. Supposedly they auto-stop when inactive. But I've tried multiple times and they don't stop, and it's not just Docker that prevents them from stopping. I created a new sprite and installed ffmpeg. Then exited. Next day I run `sprite ls` and it's been running continuously for 23 hours. No way to tell if I'm being billed for it or not. And the per-hour pricing is extremely expensive. So for now it's `sprite destroy -s spritename`. Maybe I'll check it out again in a few months after the fly team has iterated on this a few times.
- tptacek 8mo ago
  Sprites are active when: * They're servicing an incoming HTTP request. * You're interacting with a console. They're hair-trigger inactive otherwise. They don't bill CPU unless they're active. The idea is that there isn't really any uncertainty about when it's running; when you stop interacting with it it stops metering. This is a new shape for a cloud computing thingy and there'll be snags this week with it, but we don't make our money by billing people for stuff they don't want. We've always gone out of our way not to nickel-and-dime casual users and we're trying hard to find new ways to lean into that here. (Destroying a Sprite you're done with is a perfectly reasonable move; they're disposable.)
  - panarky 8mo ago
    No console activity, no HTTP requests, but it doesn't stop. Can't find any place in CLI or web UI to see how many minutes are charged for CPU, memory, storage. $ sprite ls Sprites in organization <redacted>: ┌────┬───────┬────────┐ │NAME│STATUS │CREATED │ ├────┼───────┼────────┤ │duh │running│ 23h ago│ └────┴───────┴────────┘ Total: 1 sprite(s)
    - threecheese 8mo ago
      My read of his response is that, even though the sprite is in a running state, that doesn’t mean it’s in a billable state given you aren’t connected; that’s not said explicitly, and I’m making an inference, and so it would be helpful if you let us know if you are billed for these hours.
mrkurt 8mo ago
Ok so, "running" sprite status has had some cache consistency issues. You're not being charged for idle sprites, but they may show as "running" even when you're not using them. The UX has improved, and it reliably shows what you expect. Some of the existing sprites need an environment upgrade, but you'll see those improve over the next few days.

by raro11 8mo ago

chrismccord 8mo ago

We had a bug where some sprites would fail to properly suspend while entering their suspended state. You're not eating into credits so no worries there. We've been rolling out a fix across the fleet today so you should be seeing proper status soon.

karmajunkie 8mo ago
This is great news! If we upgraded our sprite already how long should it take to suspend? I noticed the upgrade earlier and installed it but my sprite is still running.
- karmajunkie 8mo ago
  ahh finally success—a fresh sprite goes to sleep as it should. unfortunately the original one i created doesn't, so I guess I'm going to have to kill that one off.

ktaraszk 8mo ago

Just use container-os as your runtime image: https://hub.docker.com/r/miget/container-os https://hub.docker.com/r/miget/container-os and you should be good

zrail 8mo ago
Could you explain more about how this helps and how one might use a different runtime image on Sprites?
- redcmd 8mo ago
  I don't think you can choose the runtime image on Sprites, not sure what they are referring to here.

panarky 8mo ago

There's no way to stop sprites from the CLI. Supposedly they auto-stop when inactive. But I've tried multiple times and they don't stop, and it's not just Docker that prevents them from stopping. I created a new sprite and installed ffmpeg. Then exited. Next day I run `sprite ls` and it's been running continuously for 23 hours. No way to tell if I'm being billed for it or not. And the per-hour pricing is extremely expensive. So for now it's `sprite destroy -s spritename`. Maybe I'll check it out again in a few months after the fly team has iterated on this a few times.

tptacek 8mo ago
Sprites are active when: * They're servicing an incoming HTTP request. * You're interacting with a console. They're hair-trigger inactive otherwise. They don't bill CPU unless they're active. The idea is that there isn't really any uncertainty about when it's running; when you stop interacting with it it stops metering. This is a new shape for a cloud computing thingy and there'll be snags this week with it, but we don't make our money by billing people for stuff they don't want. We've always gone out of our way not to nickel-and-dime casual users and we're trying hard to find new ways to lean into that here. (Destroying a Sprite you're done with is a perfectly reasonable move; they're disposable.)
- panarky 8mo ago
  No console activity, no HTTP requests, but it doesn't stop. Can't find any place in CLI or web UI to see how many minutes are charged for CPU, memory, storage. $ sprite ls Sprites in organization <redacted>: ┌────┬───────┬────────┐ │NAME│STATUS │CREATED │ ├────┼───────┼────────┤ │duh │running│ 23h ago│ └────┴───────┴────────┘ Total: 1 sprite(s)
  - threecheese 8mo ago
    My read of his response is that, even though the sprite is in a running state, that doesn’t mean it’s in a billable state given you aren’t connected; that’s not said explicitly, and I’m making an inference, and so it would be helpful if you let us know if you are billed for these hours.

mrkurt 8mo ago

Ok so, "running" sprite status has had some cache consistency issues. You're not being charged for idle sprites, but they may show as "running" even when you're not using them. The UX has improved, and it reliably shows what you expect. Some of the existing sprites need an environment upgrade, but you'll see those improve over the next few days.