nova images list returns new uuid on every start for standard images #513
Comments
|
So as I understand our (private cloud's) present situation, our support team will set up the cloud (with fairly standard flavors honestly) and then upload a bunch of default images to get the customer started. Because it's a private cloud, the customer can obviously use glance like any person deploying vanilla OpenStack might. While our support folk could create images with the same UUID on every cloud, they don't because the names are identical on every cloud and they can use those just as easily. Given that image UUIDs don't change for public cloud, it might make sense to have a more specific plugin for public cloud's image service.
I'm not a mimic developer, but I'm wondering what your specific ask is. Are you merely looking for information? Are you looking for a specific outcome? |
I am looking for public cloud behavior. Or to be clear an installed cloud behavior where same UUID is returned for same standard image across mimic restarts. Currently all autoscale tests are configured with a particular image UUID. None of them work with current code due to different ids across restarts. |
This ticket is a cautionary tale. It's tempting, when writing a Mimic mock, to pre-populate it with data that looks like the data you want to test with, because then the data's already there and your tests don't have to do any work. This was especially apparent on the recent submission about Elasticsearch, #446 . We did that initially with images. Now, we're moving Glance to be more like Compute, and it's breaking stuff that relies upon these hard-coded values. |
|
My thinking right now is that we should create a simple mimic-control-plane endpoint that which you POST to with a single argument, "what kind of cloud", which populates images from a known database of images. Initially we can just have a "rackspace public cloud" value. @manishtomar - would hitting this endpoint be a reasonable amount of effort for the autoscale tests to do to upgrade? |
I don't think this takes any less effort than getting images and using any one of them. I would rather get images. This way it uses openstack API. The effort is about doing this or that in every single test. I'll have to find out how much is the effort.
I agree with this w.r.t returning server ids but I don't think its unreasonable to expect an installed cloud behavior (standard image UUIDs). Even if that comes with some fixed values. If I am writing tests pointing to an installed cloud I don't think there should be necessity in the client to setup the cloud. How about having config option to preload with certain values during startup instead of doing this via control plane? What about flavors and users? Are they going to have similar fate? |
The "pick a cloud" API would be part of Mimic start-up, though. |
Mimic currently doesn't have a config file, and given the mass of gross global state configuration files inevitably bring, I'd like to never add one, if possible. The only thing configured via the command line is whether or not to run in real-time mode or not, and I'd like to move that to a control-plane endpoint as well. The advantage of doing this via control plane rather than via a config file is that anything done via the control plane can be made, at least hypothetically, local to a tenant. So you can talk to any running Mimic server to do a set of tests, as long as you generate a new tenant ID. In fact, if we do ever add a config file, I really want it to just be a canned sequence of requests that get executed against the control plane during server startup; that way we do not succumb to the temptation of creating a "config" module or passing a giant gross dictionary around which might have who-knows-what in it to every function.
I believe so yes. First we have to figure out how exactly you specify these behaviors in a convenient way, though. If anything it was a little premature to randomize these IDs before we solved that problem, so any similar change to flavors (and... what do you mean by "users"? do we pre-generate users anywhere? I thought the client always specified the tenant ID and the server generated them on demand?) really ought to come along with a "put the presets back the way I like them" API first. |
No but users are needed to setup a cloud. Currently mimic doesnt authenticate these users. I was wondering if it will require users to be created before authenticating them. |
|
What about image names? Like "Ubuntu 14.04". Is that Rackspace specific? What if I get image id based on the name? Will they also change in future? I am just trying to think of situations where things can break randomly in the future. |
|
@manishtomar - Ultimately I think that Mimic should start with an empty image store and the client should have to say which one they want by default. At that point you should be able to rely upon both names and UUIDs, once you've identified the flavor of cloud collection you want. |
Huh. So would it work for your use-case to just have Mimic automatically create the images as they're requested? |
|
Like - would the name need to match the UUID, or do you just care that it validates? |
I just care that it validates. I would be fine if image name matches the UUID.
No that wouldn't really help and sorry that's not what I was asking. Currently tenants are created on the fly. I was wondering if anytime in the future the tenants need to be created using some admin/control API before authenticating. If so, then autoscale should be prepared for that also. |
We (untl @lekhajee gets a break from OnMetal testing, I guess "I"?) are currently planning to keep automatic tenant creation the default behavior for the forseeable future. |
Yes the image names are specific to Rackspace, but the image id is unique for each mimic session. Reach runs a large suite of acceptance tests every hour that depends on the image names. So we need the specific image names. I do not believe the image ids that are returned from the API are always the same. We run nightly validation tests comparing image API data versus mimic images. We had to remove the image id test because the image ids were not consistent. |
@glyph @manishtomar what do you think about the client also being able to supply the json for image store. I can imagine a configuration where mimic returns a default image store, but also allows a client to override the default behavior, supplying its own data. This would alleviate some of the issues we have seen where different clients require different specific data. |
|
@tawalton I do think that in principle the client should be able to create some images in the image store. That said, I don't think just specifying the JSON is a good idea. For one thing, the JSON has to be validated, and different views onto the image store (Glance and Nova Images APIs) need to be consistent. For another, Mimic should not support only the rax public cloud, but it should contain the information about the rax public cloud in a repository so that clients do not need to keep updating their own local copy of the image/flavor/etc lists from our public cloud; part of the point of mimic is to serve as such a repository. |
This breaks all the autoscale tests which were written with public cloud in mind. Public cloud returns same UUID for standard images which is expected since it will be configured in consumers of the cloud. Every openstack cloud will behave that way. That is how the openstack API is. On IRC, it was told that mimic's operating model is "new cloud on every startup". I don't see this documented anywhere. If mimic project was started with this philosophy in the beginning and then its consumers can expect the behavior but changing it out of the blue just seems plain unfair. To be fair autoscale should do a better job of following mimic's development and contribute issues/ideas accordingly as and when it happens. But its not always feasible with only one developer.
My understanding of mimic's nova plugin is it is mimicing public cloud which it was until the plugin refactor. I can understand the reasoning for doing this to replicate RPC behavior but even with that it favors the case when consumer/tests expects a new RPC cloud on each startup. If one has to write tests /consume mimic for RPC that has been deployed then mimic should return same UUIDs. I think there should be an option for mimic to behave in either way: "different image ids on each startup" or "same image ids" depending on who its consumer is.
Today mimic returns Rackspace public cloud flavors but any other cloud may return different flavors. I am guessing each RPC install would have different flavors depending on where it is installed. Are there plans of returning new flavors every time? The same goes for users too. Today mimic does not authorize users but in reality a every new cloud would require new users. Does mimic plan to change that part too?
Please note that I am not disagreeing with current behavior. In fact if I was writing tests today, I would not hard code the uuid and instead get images in each test. But I think its unreasonable to expect all clients to do this since that is behavior of an installed cloud.
The text was updated successfully, but these errors were encountered: