Open dmcassel opened 7 years ago
@dmcassel I tried a couple combinations of wipe with/without apply-changes=amps and it seemed to wipe whatever's defined in ml-config each time I tried. Do you have a case you can share where it doesn't work?
Sorry, I misstated the problem. Time to edit.
Ah, that makes more sense. How do we handle roles and privileges? Don't those also become orphaned in the Security Database? I'm not sure if it makes sense for Roxy to be responsible for managing assets outside of whats defined in ml-config.
One idea, we could add an attribute to assets in ml-config like: @ignore-bootstrap='true'
which would allow us to only consider these assets when wiping as well as remove them if they exist on bootstrap. Thus, you could effectively deprecate an asset. IMHO, this would be an enhancement opposed to a bug though. And we may as well add @ignore-wipe='true'
support even though I'm not sure it could be used as much more than accident-proofing.
What do you think?
Haven't given much thought to a solution yet, or looked at how we handle roles and privileges. I suspect we have the same problem. Wanted to capture this when I noticed it.
One option (to consider along with your ideas) is to make removing security assets an interactive process:
ml remove role
Likewise for users, amps.
I like where that's going. However, if multiple people are working on a project across multiple environments, how could it make sure that all people remove the correct assets from all environments after ml-config changes from one person are pushed back into a shared repo? I think we'd still need a mechanism to maintain the deprecation in order to ensure its propagated across all environments correctly.
This also occurs when someone decides to change the name of a user, role, amp or whatever. Changing ${app-name}-my-role
into ${app-name}-our-role
is already enough to get an orphaned artifact..
Most sensible thing I could imagine to do in wipe
would be to scan through those Security items, and look for anything starting with ${app-name}-
. If anything is lingering after wipe itself completed, we could warn about it, and suggest to remove it using something like ./ml env wipe --users=my-app-org-user --roles=.... etc
.
An interactive mode to wipe (--interactive
flag?) sounds intriguing too, but perhaps worth a separate ticket..
We could print a similar warning at bootstrap too, actually, though comparing to ml-config..
If you remove an amp from ml-config.xml and then bootstrap, the amp is not removed.
Since amps are written to the Security database, which is likely shared among multiple applications, I'm not sure what a good way to address this is.