Update keeper module #33
Conversation
- Added static method for validating uuid4 - Added simple check, that continues keeping default flavors in openstack without deleting - Remove strong constraint. Reason: https://github.com/openstack-dev/pbr/blob/e0d26741/pbr/packaging.py#L915
ivanovmi
force-pushed
the
fix_flavor_removing
branch
from
4b74db0 to
2a79bb9
Compare
| @@ -119,6 +120,10 @@ def get(self, client_name, resource_name, param=None, func=None, | |||
| else: | |||
| probe = getattr(el, param)(*args, **kwargs) | |||
|
|
|||
| if (resource_name == "flavors" | |||
There was a problem hiding this comment.
I think it's not quite right place to it, that changes affects all the get operations for flavors.
As I remember default flavors have specific names, so what if make a change in main.py on 82 line just for getting that bunch of flavors? That way only default flavors could appear in cache and not the user created flavors if they got here. For getting them you can use even the same admin_keeper.get() operation with filter function for a specific line of flavor names) And after that you can look at how cirros avoid to being deleted by the name in spam_factory.py on 454 line, and do the same :)
There was a problem hiding this comment.
@FromZeus Hi, thank for review! I think that hardcoding a bunch of names is a wrong way :)
But, also i think that I can move validate_uuid method to spam_factory module, and iterate over list of flavors - and if id of flavor is uuid - we can remove this flavor. This allow us doesn't to break our cloud, and doesn't disrupt logic of keeper.get() method
Reason, why I using uuid validation - because standard flavors creates with custom id (not uuid) and our flavors will be created with auto-generated uuid
There was a problem hiding this comment.
Hey :) Hm... What if somebody will create a custom flavor by hands, so that flavor will have uuid too, then while validating of uuid that flavor will be deleted. Is this possible situation?
There was a problem hiding this comment.
Possibly yes :)
But if we hardcode some parameters, this will be wrong too (from my POV).
As possible solution, we can save current state to db, and duplicate this info for more safety. Or, we can change mechanism with assigning custom id, like spamo-{iteration_number}, and keep resource, if id doesn't start with spamo
There was a problem hiding this comment.
Sure, if you could just pass an id which will contain spamo- as prefix and then just check it in spam_factory.py delete method of flavor that would be a better solution :)
There was a problem hiding this comment.
I'm agree with the use of the defined prefix for all resources to be able to remove them whenever we want.
There was a problem hiding this comment.
All the resources have already a distinguish as a placement to the cache thus they could be cleaned up with spamostack --clean all for example. But flavors are an exception in sense the default flavors placed to cache for initial usage. So there is no need to use that prefix for all the resources or is there?
default flavors in openstack without deleting
https://github.com/openstack-dev/pbr/blob/e0d26741/pbr/packaging.py#L915