The way this ordinarily works (for other quotas) is that we bind to before_save in InstanceObserver, and it updates quotas for everything (pool, pool family, etc....) if the state has changed. This normally happens when the object goes to 'pending' after passing through condormatic (namely, in condormatic_instance_create).

The problem is that, at this point (condormatic_instance_create), we haven't yet assigned a provider account. We ostensibly know the provider account -- it's stored in 'found', which is the first match from instance.matches. But we don't actually instance.provider_account_id here; we just enqueue the job in Condor. When Condor has processed the job, dbomatic updates the state and assigns provider_account_id with where the job was actually matched.

Since dbomatic is doing this outside the app, I don't see a way to bind to a callback and update the provider account quota. Here are the options that I can see:

a.) Assign provider_account_id in condormatic_instance_create instead of waiting until it's actually launched by Condor. I'm not entirely clear on how we could end up on another account at this point -- we pass Condor the account credentials of one specific account. So I'm not convinced that setting provider_account_id here (in condormatic_instance_create) is wrong. But I don't know the code well enough to know why we do it this way -- perhaps I'm overlooking a reason why it's preferable to wait to set it?

b.) Update the quota in dbomatic after the instance launches. This is probably the wrong way to go, especially as it's not consistent with the other quotas, which are updated when the instance goes to pending.

c.) Don't set provider_account_id in condormatic_instance_create, but do update the quota. This initially struck me as wrong, since we haven't actually launched it yet. However, this is consistent with how we handle the other quotas -- we update them when the instance goes to pending.

I'm inclined to go with (c), but would very much like a sanity check before proceeding.

(In reply to comment #1)
> a.) Assign provider_account_id in condormatic_instance_create instead of
> waiting until it's actually launched by Condor. I'm not entirely clear on how
> we could end up on another account at this point -- we pass Condor the account
> credentials of one specific account. So I'm not convinced that setting
> provider_account_id here (in condormatic_instance_create) is wrong. But I don't
> know the code well enough to know why we do it this way -- perhaps I'm
> overlooking a reason why it's preferable to wait to set it?
> 
> b.) Update the quota in dbomatic after the instance launches. This is probably
> the wrong way to go, especially as it's not consistent with the other quotas,
> which are updated when the instance goes to pending.
> 
> c.) Don't set provider_account_id in condormatic_instance_create, but do update
> the quota. This initially struck me as wrong, since we haven't actually
> launched it yet. However, this is consistent with how we handle the other
> quotas -- we update them when the instance goes to pending.
> 
> I'm inclined to go with (c), but would very much like a sanity check before
> proceeding.

We discussed this on IRC, and the consensus was that a) or c) would both work.  Given that Matt had already started working on a), we decided to go that route which should work fine.

Fixed in 7c7a56636e0f5f48daf28f990f8f8adb24aca045 but repos haven't been updated yet today.

Verified .

1) created provider account with quota of 2 
2) Pool quota set to 4
3) Instance more than 2 cannot be created.

moving of the blocker

release pending...

release pending...

closing out old bugs

perm close