Queue EBS storage refresh after cloud inventory is saved #120
Conversation
|
@gberginc yes, this will be the default way of refresh. Full refresh is big and slow, but it's very easy to keep consistent data. |
|
@gberginc it will be enough to increase the MiqQueue count in specs, you are adding a refresh to a Queue, so it has risen +1 The VCR update will be needed when you will add the storage refresh to the spec. |
While parsing volumes immediately after new AWS manager is created, EBS manager failed to get proper links to availability zones, because it was parsing data in parallel to the cloud manager. This patch queues the EBS storage manager parse in the same way as the network manager, i.e. immediately after the cloud inventory is saved, EBS refreshes the data once more. Signed-off-by: Gregor Berginc <[email protected]>
gberginc
force-pushed
the
queue_ebs_refresh_after_cloud
branch
from
01f9136 to
c6e88e5
Compare
|
Checked commit gberginc@c6e88e5 with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 |
|
@Ladas I've updated the queue counts so it should pass (hopefully; while trying to run the test locally, I received authentication errors). With respect to VCR update, I created a WIP PR that adds corresponding EBS manager refreshes. Could you record a new cassette and send it to me so that I can update the specific tests? |
|
@miq-bot add_label euwe/no, enhancement |
|
great 👍, will send you the VCR tomorrow |
While parsing volumes immediately after new AWS manager is created, EBS
manager failed to get proper links to availability zones, because it was
parsing data in parallel to the cloud manager. This patch queues the EBS
storage manager parse in the same way as the network manager, i.e.
immediately after the cloud inventory is saved, EBS refreshes the data
once more.
@miq-bot assign @Ladas
@Ladas I assigned you because there is a todo for you and would like to check if this is still valid way to go.