Class libtaskotron.vm.Image has new methods for finding the latest
images in given directory and generating a filename for new image.
Filename convention is <date>_<two digits version>-<release>-<template>.qcow2.
Class libtaskotron.vm.Image has new methods for finding the latest
images in given directory and generating a filename for new image.
Filename convention is <date>_<two digits version>-<release>-<template>.qcow2.
new tests
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
I don't have a good idea who's going to use this and how, so I added some generic comments, please ignore if they're wrong.
libtaskotron/vm.py | ||
---|---|---|
186 | How is this going to get used? Shouldn't image_dir default value be provided by our config file? I wonder if it's useful to have just a wrapper around os.listdir(). | |
198 | You can use ``f23`` to denote values. It is rendered in a different style. | |
211 | I wonder, will this code even be useful in taskotron? I'm not sure what tool will end up generating those images, but this version bumping code probably needs to live there, not in taskotron, and we just need to parse the names. @tflink? We can of course import libtaskotron to call this method, provided it will be possible to do so (not sure how ImageFactory looks like, if we start using it). | |
230 | I see what this generates but adding a comment like # this will create e.g. '03' would not be frowned upon. | |
231–233 | So, what if I want to rebuild yesterday's image and add a patch? Is it a problem, that a newer image exists? Maybe we should not look for latest metadata, but today latest metadata? | |
247 | Please document the return type or add :rtype:. Also please describe the return format - I guess it's a dict with certain keys. | |
265–266 | Personally I'd just return None here. Having no image for certain release is not exactly an error. Thoughts? |
libtaskotron/vm.py | ||
---|---|---|
231–233 | Well, I thought that if we want to rebuild yesterday's image and add patch we will create today's image with that patch... | |
265–266 | Somewhere higher in code will be check for None and raising an exception anyway (I presume that this will be used when task formula says "use the latest image of given release and template"). But since this is not opening/loading of Image, None sounds better, @tflink? |
Minor changes requested
libtaskotron/vm.py | ||
---|---|---|
211 | agreed - it'll be useful but I don't think it'll be useful here. | |
231–233 | I can't think of a reason why we'd want to rebuild an older image without bumping the date in its filename. even if we reverted a change to the image, we'd need to bump the version or delete the to-be-reverted image so that the correct one is found | |
265–266 | agreed - None is OK here. put the "no image found" error handling logic closer to the bits that are looking for the image |
libtaskotron/vm.py | ||
---|---|---|
211 | Ok, should I remove it or should I let it stay here until better location is found? |
libtaskotron/vm.py | ||
---|---|---|
211 | I'd say remove it from this code but keep a copy somewhere else. I'm wary of forgetting about "we should get rid of this at some point" code before anything's actually pushed |
I suspect that we'll be changing this code as we get things deployed but looks good to me for now.
For future code, can you not use dingus for new tests? It's pretty much dead upstream and doesn't work with py3 - I'd like to see us gradually get rid of existing bits and start using unittest.mock
How is this going to get used? Shouldn't image_dir default value be provided by our config file? I wonder if it's useful to have just a wrapper around os.listdir().