4047be1966
Patch Set 7: > > I was just thinking that another Alternative Implementation > (which > > would also be much simpler) would also be to use --labels along > > with a boolean flag, e.g. (--merge-labels) where > --merge-labels=False > > (default) would give us the current behaviour of replacing all > > inherited labels and --merge-labels=True would update inherited > > labels with labels supplied via existing --labels input. This > would > > work for auditing because we would know the policy used to arrive > > at the final set of labels supplied to Heat but we would need to > > add a boolean field to the DB and additionally, existing labels > > field e.g. at the cluster scope could be used to store the labels > > supplied by the user at this scope. Let me know your thoughts. > > I say this because if we are implementing a behaviour where a user > is only allowed to supply --labels or --override-labels field, this > introduces a new column in the database where only one of them is > ever used. This is the same as using the same column and using a > boolean toggle. maybe remove your +2? Patch-set: 7 Label: Code-Review=0 |
||
|---|---|---|
| 2e0ca280764223774375541df468d30b9f97de02 | ||
| aff480bf84211cb6ef890fd45789eba8f4d6b119 | ||
| c9583abfd06bf6f7020fe6ff90188189fd460087 | ||
| e8f0225341bf9246af5bcc315ef0c49abc532439 | ||
| ebe4b83fd07cfbae9732bd1aa30c995603864404 | ||
| f5fb92ca8a38f6b0010acc8011a60bd8d883ac08 | ||