marklogic-community / roxy

Deployment tool for MarkLogic applications. Also provides optional unit test and XQuery MVC structure
Other
87 stars 66 forks source link

bootstrap does not remove amps #681

Open dmcassel opened 7 years ago

dmcassel commented 7 years ago

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.

RobertSzkutak commented 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?

dmcassel commented 7 years ago

Sorry, I misstated the problem. Time to edit.

RobertSzkutak commented 7 years ago

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?

dmcassel commented 7 years ago

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:

Likewise for users, amps.

RobertSzkutak commented 7 years ago

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.

grtjn commented 7 years ago

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..

grtjn commented 7 years ago

We could print a similar warning at bootstrap too, actually, though comparing to ml-config..