search

rackerlabs / mimic

An API mock service
Other
167 stars 57 forks source link

maybe persist some information across restarts #140

Open glyph opened 9 years ago

glyph commented 9 years ago

It's a bit of a hassle to re-build all necessary state for a test every time Mimic restarts.

On the one hand, it's nice that you have to do this, so you can't have any hard-coded dependencies on long-term state.

On the other, it's a bit annoying, especially when developing Mimic itself, that loading a new version of the code means having to cause the application that you're working on to re-authenticate and start from scratch.

ddunlop commented 9 years ago

Agreed!

A compromise could be a bulk configuration, were with one http request you could setup entities, checks, alarms etc to some known configuration but potentially unknown ids.

glyph commented 9 years ago

@ddunlop thanks for the feedback :). My particular experience with this was debugging a system that made a bunch of stateful requests against Mimic, then I needed to change Mimic's code to help diagnose something. So in that case, bulk configuration wouldn't help because that other system doesn't really know what state it's in.

I'd like to avoid "bulk" configuration, since you can just issue the same sequence of canned requests. Adding a bulk API would mean adding an API divergent from what's actually in the cloud, but that does the same thing, just with fewer HTTP requests.

Maybe if you could POST some tenant-ID and session token information... that's not normally configurable via the API and it would allow one to put back the relevant bits of state.

arpithkp commented 9 years ago

How about having lineage graph that keeps track of activities and taking checkpoint at regular intervals to store information, doing this saves memory as we are not directly storing objects but just graph on how to recreate that object.

glyph commented 9 years ago

Hi @arpithkp, glad to hear you're interested in this :)

There are two issues I see with a "lineage graph" - although I'm not sure I fully understand the data structure you're describing, do you have a reference?

  1. several of the things that Mimic does, such as generating the URL prefixes for the service catalog, are not fully deterministic, so this graph will need to contain information about PRNG state and the passage of time.
  2. you won't be able to build any tools around manipulating the state other than issuing more requests to Mimic. It seems like one of the useful things about having persistent state would be being able to have a snapshot which you could easily visualize or manipulate, potentially in ways that the API doesn't fully expose yet (like adding servers in a particular specific state)

that said, an event log that explains how mimic got to where it is would be super useful as a part of this state.

arpithkp commented 9 years ago

thanks @glyph I just started looking on this lineage graph thing, but I'll keep posted on this.

BenjamenMeyer commented 8 years ago

This would be nice.

I'm trying to setup an environment where we have mimic running in Docker container along with several other things. This could be very useful as it could be done as part of the docker-compose functionality and then testing would just work. We already have to specify all IPs, etc in the docker-compose functionality any way - even if we had to run a curl command. We'll work around it for now, but this would make a nice addition.