Update copy image logic to match create image.

[illfelder]

Image "guestOsFeatures" should behave the same during image copy and creation.

Description

• Unify "guestOsFeatures" logic in image copy and create.
• Moved image copy next to image create because they are highly related.

Status

done, ready for review

Checklist (tick everything that applies)

• Code linting (required, can be done after the PR checks)
• Documentation
• Tests
• ICLA (required for bigger changes)

[erjohnso]

/cc @supertom

[erjohnso]

/cc @supertom

[illfelder]

cc @tonybaloney

[illfelder]

cc @tonybaloney

[illfelder]

Friendly ping?

[illfelder]

Friendly ping?

[supertom]

Sorry for the delay. Looks fine and tests/lint check pass.

We've now duplicated that guest_os_feature check in both the create and copy methods - what do you think about creating a helper function to reduce the duplication (any chance of any other API exposing this somehow)? Also, are there more guest_os_features coming? Should we make a static list?

[supertom]

Sorry for the delay. Looks fine and tests/lint check pass.

We've now duplicated that guest_os_feature check in both the create and copy methods - what do you think about creating a helper function to reduce the duplication (any chance of any other API exposing this somehow)? Also, are there more guest_os_features coming? Should we make a static list?

[illfelder]

I moved the functions together for that purpose and considered writing a helper function. I decided against it for two reasons.

1. I think the logic for the particular feature is limited to those two functions and will not need to be used elsewhere.
2. The two functions where the logic is duplicated (image create and copy) are serving the same purpose and should be combined. I didn't want to deal with combining the functions for this change which is why I left the logic duplicated for now.

We will want to add more guest_os_features in the near future, so it should be a static list. Any suggestions for where I should put that? Define a global variable in the file?

[illfelder]

I moved the functions together for that purpose and considered writing a helper function. I decided against it for two reasons.

1. I think the logic for the particular feature is limited to those two functions and will not need to be used elsewhere.
2. The two functions where the logic is duplicated (image create and copy) are serving the same purpose and should be combined. I didn't want to deal with combining the functions for this change which is why I left the logic duplicated for now.

We will want to add more guest_os_features in the near future, so it should be a static list. Any suggestions for where I should put that? Define a global variable in the file?

[illfelder]

Updated to make the feature a static list.

[illfelder]

Updated to make the feature a static list.

[supertom]

Thanks for adding the list of OS features. I agree, the functions should be combined, but we can deal with that later on. LGTM.

[supertom]

Thanks for adding the list of OS features. I agree, the functions should be combined, but we can deal with that later on. LGTM.

[Kami]

It looks like the same logic is duplicated in ex_create_image method.

It would be great if it can be refactored in a shared utility method to avoid duplication and make maintenance easier.

[illfelder]

I agree - if you take a look at the conversation thread for the pull request, we discuss exactly that change.

[illfelder]

The TL;DR from the conversation was that the duplicated functionality I add will only be used by those two functions, so it doesn't make sense to move it into a helper. The two functions, however, should be combined since they do (essentially) the same thing. That should be done as a separate pull request. Do you have any other concerns before merging?

[illfelder]

Any concerns about merging?

[illfelder]

Any concerns about merging?