Cleanup adding new jenkins instance for production

[Igor Shishkin]

Hello,

Please remove Username and API Key fields on page of adding new CI instance in production environment:
    https://inventory.infra.mirantis.net/jenkins_ci/new

This could be achieved by adding option in settings.yaml which would turn on and off displaying those fields.
Please don't forget to verify POST data on backend side to strictly do not accept parameters from those fields in case if this option is set to do not show them.

Those fields should not be used in production.

[Alexander Charykov (acharykov)]

Fields are used if Jenkins Instance isn't defined in config file.

[Igor Shishkin (teran)]

@Alexander, as we discussed this data should be used from config files only.
There should not be an ability to specify that data in database because of security reasons.

[Alexander Charykov (acharykov)]

They aren't saved in DB.

[Igor Shishkin (teran)]

As just discussed verbally:
Those fields are used for setting new CI instance avoiding config.
Which refers us to the following:
 * Security impact - it's insecure to store plaintext data in DB.
 * Security impact - based on documentation, your code would update DB data from YAML if it's different, i.e. update plaintext sensitive value in DB.
 * Testing impact - tests won't stay representative until you will be able to have exactly the same flow for all the test cases obtained for real production usage.
 * Reproducibility impact - you won't be able to reproduce instance from the same configs using some configuration from DB.

[Igor Shishkin (teran)]

So I see two choices to solve it at once:
 * Use some kind of parameter(like environment, specifies debug to True and enabling this particular feature in development case) to turn on or off a class of such "development features".
 * Use the the flow from production in your development environments(i.e. YAMLs), which is preferred.

[Alexander Charykov (acharykov)]

We don't write passwords from config to DB.
Reproducibility is impossible without DB dump.
Fields are used for dynamic add of jenkins instances.

[Alexander Charykov (acharykov)]

You are not obliged to create anything in DB by hands, imported would do it for you.

[Igor Shishkin (teran)]

> We don't write passwords from config to DB.
Based on docs - you are.

> Reproducibility is impossible without DB dump.
In current implementation - it's possible by deploying new instance and running importers.

> Fields are used for dynamic add of jenkins instances.
Here's the thing, it should NOT works such way in production.

> You are not obliged to create anything in DB by hands, imported would do it for you.
Here's the thing, importer ONLY should be able to do that.

@Alexander, I've described the reasons and described the ways how to solve it.
Please finally accept the bug.

[Alexander Charykov (acharykov)]

Please read documentation carefully:
> Note that username and API key information from credentials file will not be saved in the database

> Here's the thing, it should NOT works such way in production.
Please create a feature request to add functionality to disable dynamic addition.

Bug about useless fields is incorrect, because fields are used in application. If you don't need then, it doesn't mean everyone also doesn't need them.

[Igor Shishkin (teran)]

@Alexander, this means your are fine with having unrelevant tests(details highlighted above in #4) in your development environment right?

Description updated according your belief.

[Alexander Charykov (acharykov)]

What do you mean by cleanup? Those fields are used and can't be removed.

[Igor Shishkin (teran)]

@Alexander, it's described in bug: "Please remove Username and API Key fields on page of adding new CI instance IN PRODUCTION ENVIRONMENT"

[Alexander Charykov (acharykov)]

I can propose you a configuration parameter which would disable "adding new CI instance IN PRODUCTION ENVIRONMENT".

Create a bug with this feature request. This bug is invalid because fields can't be removed as they are used.

Please don't reopen this bug, simply create a new bug with tag feature.

[Igor Shishkin (teran)]

@Alexander, new bug won't represent the history of that solution.
Description is updated.

[Alexander Charykov (acharykov)]

Please create a new bug.

[[e-mail] (izotov)]

@Alexander, is current bug description valid from your perspective?
If so, I would suggest to process this bug record, instead of creating a new one. Or are there any specific reasons why you are requesting a new bug? Thanks.