Hacker News Reader

Comment by panarky | Hacker News Reader

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.

View on HN

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.)

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)

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.

There needs to be a way to see how much it is being used then and not simply the life of the Sprite.

You can. There’s a usage dashboard

Where is it?

I think the idling feature still needs some work. I created one over the weekend that hasn't idled once, and I've run several tests with sprites that have nothing in them—just `sprite create` and log out, just to see what happens (which unfortunately is nothing, left alone it keeps on running as well.)

I love the idea and most of the execution, I've really enjoyed getting my first sprite configured just the way I want it. It just needs the idling feature to work as advertised before I think I can use it as cost-effectively as it promises.

> Sprites are active when: * They're servicing an incoming HTTP request. * You're interacting with a console.

They are advocated as Linux machines. How about daemons then, or cron jobs? What semantics can we expect from them?

What does "when you stop interacting with it" mean? Closing all TCP connections? When CPU usage drops to below some threshold?

For what it's worth, CPU pricing is based on CPU util. A sprite sitting idle CPU costs almost nothing, even when "active".

So is it similar to railway in this context?

Yeah. My sprites never idled inspite of having nothing running in them and had to be destroyed. Ideally there should be two settings

1. A timeout after the last console session is exited 2. Force idle using the CLI

Just tried it again. Creation took a very long time, then errored.

    $ sprite version
    sprite version v0.0.1-rc30

    $ sprite create quk

     Error creating sprite: failed to create sprite: Post "https://api.sprites.dev/v1/sprites": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

But despite the error, the sprite was apparently created, and it runs continuously.

    $ sprite ls
    Sprites in organization <redacted>:

    ┌────┬───────┬────────┐
    │NAME│STATUS │CREATED │
    ├────┼───────┼────────┤
    │quk │running│14m ago │
    └────┴───────┴────────┘

    Total: 1 sprite(s)

Get a console in your sprite. Run “screen”. Run a loop in there : while date; do sleep 1; done. Detach screen and exit the session. Wait a few minutes and go back into the sprite. Reattach screen. You’ll see a gap in the timestamps.

They do suspend even when they say they are “running”.

Reply on news.ycombinator.com