Disallow saving incorrect storage node credentials



  • I think that credentials put into storage management for a node ought to be checked for validity. And if they are invalid, they shouldn’t be stored and a warning message displayed for why and what to do.


  • Senior Developer

    @wayne-workman and @george1421 this has been added for 1.6. I’m not going to try adding it to 1.5 as it is a bit of work to add the tests and the return information is at best rudimentary in 1.5.



  • Agree with George, “Storage Node Create Successful” is alone confusing. How about “Storage Node Created With Warnings”


  • Moderator

    @tom-elliott If I can suggest here: The “storage node create success” is a bit confusing with a yellow/orange color. I might suggest “Storage Node Create Warning” if you are using the yellow/orange color to signal trouble ahead. Yes it was created successfully, but it didn’t work as expected is what I would interpreter the message and color to indicate. Then of course red sign would be everything failed.


  • Senior Developer

    I think this looks a little better, as it warns the user in a more appropriate fashion.
    0_1526097790969_e714a9e5-f1e7-4cc3-94a9-ff8febae58d0-image.png



  • @tom-elliott That would be perfect, just to inform the user that something might be wrong.


  • Senior Developer

    Something similar to?:
    0_1525997414681_90ba1fe9-719c-4b1e-8017-a9458fab1042-image.png


  • Senior Developer

    I could see us adding a warning if a node cannot connect. However, I am in agreement with @Tom-Elliott that straight up preventing credential entering would cause more issues than it would solve.


  • Senior Developer

    I’ll add why I say this is not a good approach beyond what i just described.

    What if you want to create your storage node before your node is actually setup? Yes, sometimes, people want to have things setup Before they’re ready to use. (For example, should we not allow manual creation of hosts because they didn’t go through the inventory or registration process? Should we make “capture” define the image during the capture process because only then do we know that the image will be usable and viable? Should we ping and test validity of printers when creating them and not allow them to be added if you cannot actually print to them?


  • Senior Developer

    Sorry, this is too complex to add. While programmatically it’s easy, it’s not up to US to determine the viability and usability of a password.

    We have set some “sane” defaults. For example, fog generates a random user’s password on installation. This password is relatively secure in that the password is randomly generated. This means the password is SET FOR THE USER. What the user does before or after this is complete is outside of the realm of FOG’s necessity. Let’s say you create the FOG user password P@33W0rd!, but you keep typing in P@33w0rd! does this mean fog should fail to create a node because of one letter? I don’t think so, it should be up to you, the user making the entry, to ensure the information is correct.

    Somebody else wants to add in the checks for this, by all means, but this isn’t something I feel we should do for you. That’d be like trying to say we shouldn’t allow you to edit any facet of FOG simply because it’s too error prone.



  • Intercepting errors is always a good thing.



  • Bumping this.


 

549
Online

5.4k
Users

12.6k
Topics

118.7k
Posts