Skip to content
This repository has been archived by the owner on Nov 9, 2022. It is now read-only.

bootstrap does not remove amps #681

Open
dmcassel opened this issue Oct 25, 2016 · 7 comments
Open

bootstrap does not remove amps #681

dmcassel opened this issue Oct 25, 2016 · 7 comments

Comments

@dmcassel
Copy link
Collaborator

dmcassel commented Oct 25, 2016

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
Copy link
Contributor

RobertSzkutak commented Oct 26, 2016

@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?

@RobertSzkutak RobertSzkutak self-assigned this Oct 26, 2016
@dmcassel
Copy link
Collaborator Author

Sorry, I misstated the problem. Time to edit.

@dmcassel dmcassel changed the title wipe does not remove amps bootstrap does not remove amps Oct 26, 2016
@RobertSzkutak
Copy link
Contributor

RobertSzkutak commented Oct 26, 2016

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
Copy link
Collaborator Author

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
  • Roxy prompts for each role in ml-config, keep or discard?
  • on discard:
    • "should users with this role be removed or drop the role?"
    • delete or modify users as needed
    • delete role
    • remove role specification from ml-config.xml

Likewise for users, amps.

@RobertSzkutak
Copy link
Contributor

RobertSzkutak commented Oct 26, 2016

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
Copy link
Contributor

grtjn commented Jun 7, 2017

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
Copy link
Contributor

grtjn commented Jun 7, 2017

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants