ct same code was working before, something their side has changed
<mgz> it may be that we now need to do something different, but it would be good to find out what they changed
<arosales> mgz, if you can point me to an error message I can pass it their way
<arosales> error message that would indicate azure is failing as they can still provision instances
<arosales> be right back
<mgz> is's basically MissingOrIncorrectVersionHeader, but we may still need to trace exactly what we're sending in the case it fails
<mgz> hm... I have an idea
<sinzui> mgz, I discussed azure APIVersion with utlemming in #juju.
<sinzui> mgz, I just tried a global change of the APIVersion is gwacl by setting the date to today. All I accomplished was making bootstrap fail faster
<rogpeppe2> dimitern: how's your knowledge of charm upgrade semantics?
<sinzui> I will try some alternate dates
<mgz> sinzui: too many jujus. I see that log now. did you also catch the earlier discussion here on it between wallyworld and rvba?
<sinzui> I read it without full comprehension
<mgz> well, rvba tried an alternate date and it didn't help
<sinzui> mgz, fab, I will stop this line of inquiry
<mgz> I do still worry about the whole on-some-requests-but-not-others aspects
<mgz> could still be our http stack screwing up I guess, would be nice to wireshark and confirm the exact bits we send for the working vs non-working api calls
<dimitern> rogpeppe, good
<rogpeppe> dimitern: i'm trying to upgrade a charm that's in an error state, but it doesn't seem to be upgrading
<rogpeppe> dimitern: from my reading of the logic in ModeHookError, it should allow upgrading in that case
<rogpeppe> dimitern: ah, i get it now - i didn't use the upgrade-charm --force flag
<dimitern> rogpeppe, right!
<dimitern> rogpeppe, also, there's resolve --retry on the unit that's in an error state
<rogpeppe> dimitern: yeah, i knew about that
<rogpeppe> dimitern: i was just confused by the fact that the new charm had been downloaded, but the unit wasn't using it
<rogpeppe> cool, it all works no