added extra security to the deletion of aliases & style changes to aliases #12

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
4 participants
@justinhill

Deleting an alias now requires a user to type in the DELETE command, similar to the deleting of indexes for extra security so that aliases aren't deleted accidentally.

I also changed the styling of the aliases to display directly below the index name and to not take an entire table row per alias. If the previous location of the aliases (directly below the info and action dropdowns) is the preferred location for aliases, I also have local changes I can push that restyle them their so that they still can have aliases for different indexes in the same table row.

added extra security to the deletion of aliases
restyled aliases to live directly under the index name for easier readability and to use less space
@mobz

This comment has been minimized.

Show comment Hide comment
@mobz

mobz May 2, 2012

Owner

Hi,
I'm not very keen to accept either of these changes. I originally considered adding the 'DELETE' security to removing an alias, but decided against it because it is easy to undo. If you accidentally delete an alias you can just add it back again using the 'add alias' menu item.

For the compacting aliases I dont want to do that because one of the nice features of aliases is that you can have a single alias against many indicies. This change would make this less obvious, also I have some future plans to make it even easier to manage aliases from this interface, which require the table layout.

I'd be happy to consider a patch which enabled hide/show of the alias rows though.

-B

Owner

mobz commented May 2, 2012

Hi,
I'm not very keen to accept either of these changes. I originally considered adding the 'DELETE' security to removing an alias, but decided against it because it is easy to undo. If you accidentally delete an alias you can just add it back again using the 'add alias' menu item.

For the compacting aliases I dont want to do that because one of the nice features of aliases is that you can have a single alias against many indicies. This change would make this less obvious, also I have some future plans to make it even easier to manage aliases from this interface, which require the table layout.

I'd be happy to consider a patch which enabled hide/show of the alias rows though.

-B

@justinhill

This comment has been minimized.

Show comment Hide comment
@justinhill

justinhill May 3, 2012

For us, deleting an alias, even if for just a minute means the loss of data. We have real-time services that are continuously hitting our indexes and losing any amount of data is not acceptable. Better safe than sorry.

As for the table layout, I hadn't considered aliases for multiple indexes, so I see why you initially went with a table row per alias. One of our elasticsearch instances has over 50 indexes and at some point, every single one of them may have at least 1 alias. Having 50 table rows of aliases between the index names and the node information would make the interface hard to use. Not to mention that with the amount of scrolling we have for the list of indexes, any benefit of having the same alias name in the same table row would be lost because you wouldn't be able to easily see all the indexes at once anyway. I'm not sure hiding them helps really because the aliases are important information.

I realize our usage of elasticsearch may not be typical, but I wanted to give you my reasons behind why these changes are important to us ... the tool is really helpful though, we've gotten a lot of use out of it!

Thanks,
Justin

For us, deleting an alias, even if for just a minute means the loss of data. We have real-time services that are continuously hitting our indexes and losing any amount of data is not acceptable. Better safe than sorry.

As for the table layout, I hadn't considered aliases for multiple indexes, so I see why you initially went with a table row per alias. One of our elasticsearch instances has over 50 indexes and at some point, every single one of them may have at least 1 alias. Having 50 table rows of aliases between the index names and the node information would make the interface hard to use. Not to mention that with the amount of scrolling we have for the list of indexes, any benefit of having the same alias name in the same table row would be lost because you wouldn't be able to easily see all the indexes at once anyway. I'm not sure hiding them helps really because the aliases are important information.

I realize our usage of elasticsearch may not be typical, but I wanted to give you my reasons behind why these changes are important to us ... the tool is really helpful though, we've gotten a lot of use out of it!

Thanks,
Justin

@mobz

This comment has been minimized.

Show comment Hide comment
@mobz

mobz May 3, 2012

Owner

Hi Justin,
Thanks for the response. I actually think your usage of elasticsearch is quite typical (eg 50 indicies or more) and elasticsearch-head does not currently handle this case very well. I'm trying to think of some ways of improving the view in this scenario (for example changing the orientation of the cluster so nodes are across the top and indicies go down. Perhaps you could resubmit your patch but allow the user to control the display if aliases.

Eg have a drop down in the menu bar with the options 'Full', 'Compact', 'None', which would toggle the alias row between the current view, your view and a view with aliases hidden? If you don't feel comfortable with that, please leave this pull request open, and I will try to find time to update it.

Owner

mobz commented May 3, 2012

Hi Justin,
Thanks for the response. I actually think your usage of elasticsearch is quite typical (eg 50 indicies or more) and elasticsearch-head does not currently handle this case very well. I'm trying to think of some ways of improving the view in this scenario (for example changing the orientation of the cluster so nodes are across the top and indicies go down. Perhaps you could resubmit your patch but allow the user to control the display if aliases.

Eg have a drop down in the menu bar with the options 'Full', 'Compact', 'None', which would toggle the alias row between the current view, your view and a view with aliases hidden? If you don't feel comfortable with that, please leave this pull request open, and I will try to find time to update it.

@drawks

This comment has been minimized.

Show comment Hide comment
@drawks

drawks Mar 4, 2013

This pull is awesome, please reconsider accepting it.

drawks commented Mar 4, 2013

This pull is awesome, please reconsider accepting it.

@karussell

This comment has been minimized.

Show comment Hide comment
@karussell

karussell Mar 6, 2013

Contributor

Changing the orientation would be nice. Also having an input field where one can easily filter the indices is an option to get a better and faster understanding for several indices.

Contributor

karussell commented Mar 6, 2013

Changing the orientation would be nice. Also having an input field where one can easily filter the indices is an option to get a better and faster understanding for several indices.

@mobz mobz closed this Aug 20, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment