aci_rest: change not detected #35041
Comments
|
Files identified in the description: If these files are inaccurate, please update the |
ansibot
added
aci
|
Thanks for reporting this. I have experienced similar problems, but aci_rest relies on this information from the APIC and it seems the APIC is not correctly returning this information to us in every case. If the APIC does not tell us there was a change, there is no practical way aci_rest is able to detect this. This should be reported to Cisco TAC. Can you please open a ticket ? PS I would have expected it to work because aci_rest adds |
ansibot
removed
the
needs_triage
|
I'll try to see if I can get some response from Cisco on this (not sure if I can open a TAC case for my LAB equipment). However as this behavior is consistent across two major releases I guess this is either a major flaw in their software or works as intended. Some further investigations using postman revealed that without
On the flip side this means (and some initial tests with postman confirm this): as long as Examples from Postman: First call (items do not yet exist): Note: Sending exactly the same POST request a second time: Note: Now modifying only one of the two items (changed descr from "asdf" to "fdsa"): Note: |
|
So,
this is according to what the documentation states. The issue you reported was related to the fact that if you provided a different path, there was no change reported even though 1. and 2. were OK. So to me that looks like a bug, albeit a consistent bug (and not a regression). Regarding looking at the imdata content, I am not sure if that's always correct. Currently that is an assumption, although I guess you could open a second ticket to ask if your assumption is always correct. |
|
I'm fairly new to collaborating on open source software, so please excuse if this is not the right place to discuss, or the wrong approach I took. That said - I believe I identified an issue with the aci_rest module which does not work as intended in all possible (but IMO valid) use cases. I also provided examples where this can be seen, as well as a brief root cause analysis. I also provided an idea how the root cause can be addressed (regardless if the root cause is a bug in the APIC REST API or in Cisco's documentation of it - I also reached out to my local Cisco contacts if they can get internal confirmation on this). Just to be sure - you're saying I should raise another issue and ask if the current implementation could be changed to my suggestion? |
|
@marinus81 Your proposed solution is based on an assumption that I don't know if it holds true in all cases. That's why I would much rather stick to the implemented and documented solution rather than to implement a work-around of which we are not certain it will work in every case. Even if that means that aci_rest is as unreliable as the APIC itself for specific payloads. The aci_rest module is a wrapper around the APIC REST API and is affected by any issues with the APIC REST API. So I am not a great fan of trying to fix APIC issues in the aci_rest module. |
|
Let's fix this on the right side, being, on APIC side, can you get me the SR you opened, I'll have somebody in my team yank it and work with engineering on this |
|
@marinus81 I have been playing with your example and this does work too: - name: Create CDP Policies
aci_rest:
host: "{{ apic_hostname }}"
private_key: pki/admin.key
method: post
path: /api/node/mo/uni/infra.xml
content: |
<cdpIfPol adminSt="{{ item.state }}" name="{{ item.name }}" descr="CDP set to {{ item.state }}"/>
with_items:
- "{{ cdp_policies }}"Since you're already in the infra-namespace (dn=uni/infra), I don't think you need to repeat |
|
@rsmeyers I opened a Cisco TAC case for this #683814655 @dagwieers Thanks, indeed this works - i did "repeat" Also just for completeness (and I promise my last statement on this topic ;) - I understand a complete change in implementation logic is not done lightly): Should it every be necessary to revisit this - the suggested alternative implementation of change detection is not just an assumption, but also documented in the official API documentation:
|
|
@marinus81 The assumption being that there are no other objects returned, for other reasons. For example, if there's an error, you get a totalCount > 0 with one or more error messages returned. That's one way additional items are being returned, and maybe there are other (future) changes to this that fulfill the referenced documentation. So to repeat, our implementation relies on 2 documented behaviours. When using
Now both are essential to me for it to work flawlessly, and 2. is failing in some specific cases. The solution is not to become less strict and only rely on one for |
|
@marinus81 I'm working with the current case-owner on this. We will keep you closely updated. |
dagwieers
added
the
waiting_on_vendor
|
If you are affected by this bug, there is a clever workaround you can implement in your playbook (as hinted by @marinus81). Add the following to your aci_rest task: - aci_rest:
method: post
<snip>
register: this
changed_when: this.imdata != []This will only report a change when the APIC returns information, which usually happens when the APIC makes a change to the configuration. |
|
@rsmeyers, has there been any update on this from Cisco? To me it seems like a simple bug to be fixed within ACI. |
|
we are working with engineering on this and evaluating possible fixes in the code |
|
Just stumbled upon this issue with APICs running 2.2(3j) not reporting a change as Changed using |
ansibot
added
support:core
|
@holmahenkel If you can, please open a detailed ticket with Cisco to get your case resolved. |
ansibot
added
support:community
|
Moved to |
|
@gundalow Can you close this ticket? Thanks! |
ISSUE TYPE
COMPONENT NAME
aci_rest
ANSIBLE VERSION
CONFIGURATION
DEFAULT_DEBUG(env: ANSIBLE_DEBUG) = False
DEFAULT_STRATEGY(env: ANSIBLE_STRATEGY) = linear
OS / ENVIRONMENT
N/A
SUMMARY
aci_rest module does not always detect changed config, but reports it as unchanged ("ok:")
STEPS TO REPRODUCE
Depending on how you push the config to APIC the aci_rest module detects it as changed or not:
This example will always report as unchanged:
This playbook works as expected ("ok:" if nothing has changed and "changed:" otherwise)
Note the difference in path: parameter (infra.xml vs. infra/.xml) as well as adjusted content.
EXPECTED RESULTS
In both cases changes to actual APIC config should result in "changed:" status
ACTUAL RESULTS
The reason why the first playbook does not behave as expected is that APIC does not populate the "status=" parameter as expected by the aci_rest module (it will only report change if this parameter is set to either of 'created', 'modified', 'deleted')
(see https://github.com/datacenter/aci-ansible/blob/e87db8f15e34ea7dc2e1b30fd445a4c59561bbc9/library/aci_rest.py#L270-L284)
On the other hand the second playbook runs as expected as returned data from APIC contains (status='modified'):
Given this (weired?) behavior of APIC (I confirmed this behavior is the same on APIC versions 3.0, 3.1 and 2.1), I think the current implementation of aci_changed() might be insufficient.
The text was updated successfully, but these errors were encountered: