QA (public) » openQA Project (public)

Thank you Oli, would it be possible raise priority for this ticket?without this done, I am afraid, we are not able to take action to change our test machine settings with new secure password for Asset security need.

cachen wrote:

okurz wrote:

As visible for example in https://openqa.suse.de/tests/7971958/file/vars.json newer jobs don't reveal any PASSWORD variable in vars.json anymore.

@cachen @Julie_CAO if you like you can continue with changes to the passwords.

Hello Oli, thank you for your great job! I have noticed the PR was merged and already effected in the example successfully hide HMC_PASSWORD,it should also works for IPMI_PASSWORD which is in same var format.

However I just found IPMI_PASSWORD is still visible in the test http://openqa.qa2.suse.asia/tests/43469/file/vars.json which was finished in couple minutes ago, our local openQA both worker and webui have been upgraded to the latest yesterday and I checked this PR code is in there. Is there anything missed in our deployment? Would you please help to take a look?

Apologize! The PR also effects in Beijing local openQA, IPMI_PASSWORD is not visible in in the test http://openqa.qa2.suse.asia/tests/43469/file/vars.json, the showing PASSWORD is for system in this case.
Thank you Oliver again!

Thank you for bringing that up. We will crosscheck in #114766

okurz wrote:

Thank you for bringing that up. We will crosscheck in #114766

Hi @okurz, I am not authorized to access #114766. Could you grant me access or tell me when the issue will be fixed?

Julie_CAO wrote:

Hi @okurz, I am not authorized to access #114766. Could you grant me access or tell me when the issue will be fixed?

Please try again now

cdywan wrote:

Julie_CAO wrote:

Hi @okurz, I am not authorized to access #114766. Could you grant me access or tell me when the issue will be fixed?

Please try again now

Thank you, @cdywan. I can access it now.

Julie_CAO wrote:

… tell me when the issue will be fixed?

We do not currently plan to work on #114766. We leave it to others to work on this.

okurz wrote:

Julie_CAO wrote:

… tell me when the issue will be fixed?

We do not currently plan to work on #114766. We leave it to others to work on this.

@okurz can you please give an ETA? and Who is the others?

@jstehlik for your information, the task [virtualization][factory-first]deploy virtualization tests in O3 will be stopped until the fix for this password leak issue is deployed to O3. And I have to point, we have spent many effort in the past year to adapting our tests to support the 'factory-first' strategy to having VT test can be covered in O3, and that need many teams and members from IT and QE tools to support and cooperate, however there are so many blockers especially the ipmi backend and security relevant. Now what I can see is the cost(include the hardware investment) is bigger than the benefit, I am wondering we made a wrong decision to accept this requirement and whether we should stop it. How do you think?

cachen wrote:

okurz wrote:

Julie_CAO wrote:

… tell me when the issue will be fixed?

We do not currently plan to work on #114766. We leave it to others to work on this.

@okurz can you please give an ETA? and Who is the others?

ETA for us would be weeks-months. Everyone else is the "others". As this is concerning code only within os-autoinst within special backends it is easier for people not within the SUSE QE Tools team, e.g. you or your team, to contribute this without needing to understand more complicated details like communication between the openQA worker and the backend.

@Jan Stehlík for your information, the task [virtualization][factory-first]deploy virtualization tests in O3 will be stopped until the fix for this password leak issue is deployed to O3. And I have to point, we have spent many effort in the past year to adapting our tests to support the 'factory-first' strategy to having VT test can be covered in O3, and that need many teams and members from IT and QE tools to support and cooperate, however there are so many blockers especially the ipmi backend and security relevant. Now what I can see is the cost(include the hardware investment) is bigger than the benefit, I am wondering we made a wrong decision to accept this requirement and whether we should stop it. How do you think?

In all honesty, the rest of the company can work following "factory-first", it's the core of SUSE's business model and everyone joining SUSE should have that as motivation. It is not the first time you make statements like "we can work until issue XYZ is fixed". If you feel you definitely need a certain thing then you should not rely on other teams to do that for you. Here in the case of some problem specific to the IPMI backend I am confident you can solve that problem within your team with a reasonable amount of work. Let me remind you that for years development of virtualization packages has been going on and existing virtualization tests within openQA based on the qemu backend provide helpful feedback so a viable alternative is always to look further in this area not necessarily needing bare-metal based tests for the complete validation of all relevant features.

okurz wrote:

cachen wrote:

okurz wrote:

Julie_CAO wrote:

… tell me when the issue will be fixed?

We do not currently plan to work on #114766. We leave it to others to work on this.

@okurz can you please give an ETA? and Who is the others?

ETA for us would be weeks-months. Everyone else is the "others". As this is concerning code only within os-autoinst within special backends it is easier for people not within the SUSE QE Tools team, e.g. you or your team, to contribute this without needing to understand more complicated details like communication between the openQA worker and the backend.

@Jan Stehlík for your information, the task [virtualization][factory-first]deploy virtualization tests in O3 will be stopped until the fix for this password leak issue is deployed to O3. And I have to point, we have spent many effort in the past year to adapting our tests to support the 'factory-first' strategy to having VT test can be covered in O3, and that need many teams and members from IT and QE tools to support and cooperate, however there are so many blockers especially the ipmi backend and security relevant. Now what I can see is the cost(include the hardware investment) is bigger than the benefit, I am wondering we made a wrong decision to accept this requirement and whether we should stop it. How do you think?

In all honesty, the rest of the company can work following "factory-first", it's the core of SUSE's business model and everyone joining SUSE should have that as motivation. It is not the first time you make statements like "we can work until issue XYZ is fixed". If you feel you definitely need a certain thing then you should not rely on other teams to do that for you. Here in the case of some problem specific to the IPMI backend I am confident you can solve that problem within your team with a reasonable amount of work. Let me remind you that for years development of virtualization packages has been going on and existing virtualization tests within openQA based on the qemu backend provide helpful feedback so a viable alternative is always to look further in this area not necessarily needing bare-metal based tests for the complete validation of all relevant features.

@okurz, 2 things in your statement are true: we should motivate to 'factory first'(so we invest); my team has technical ability to do it(thanks I have a powerful team). But let me point we all have agreed backend(not just qemu) of openQA are responsible by QE-tools team, so VT squad expects to have tools team's support is reasonable(we have got many support, thank you), and team co-work is needed because each team/individual has their responsibility, it doesn't means "I am a supper man, I can/should do everything". So, it will be helpful if you can stop the thinking and expectation: it can be taken by any others.

cachen wrote:

So, it will be helpful if you can stop the thinking and expectation: it can be taken by any others.

Sure, it can happen that nobody else feels capable to do so and that's fine. So then it's back to "currently not planned".

okurz wrote:

cachen wrote:

So, it will be helpful if you can stop the thinking and expectation: it can be taken by any others.

Sure, it can happen that nobody else feels capable to do so and that's fine. So then it's back to "currently not planned".

It's fine and understandable if Tools team no capable for it in current due to others more urgent tasks, as long as you take it fairly the priority in backlog, as it's a security relevant and pending to others, and like you said it's 'easier for people'.