Open Stack

Hello Dmitriy,

Thank you for your prompt reply! We appreciate your input on this, and will review internally.


Thank you,


Kelsi Parenteau, PMP, PMI-ACP, CSM

Senior Project Manager

d: 586.473.1230 I m: 313.404.3214



 <https://www.linkedin.com/company/wsm-international>  [cid:39748af2-b062-4a28-a022-8e401d5457a1]

[cid:ecd3d72c-daba-452c-8b29-968cd5fc710a]  [cid:e9d44c60-dd78-4d77-8ae0-532692e2dd99]

________________________________
From: Dmitriy Rabotyagov <noonedeadpunk at ya.ru>
Sent: Monday, April 4, 2022 11:15 AM
To: Kelsi Parenteau <k.parenteau at connectria.com>; openstack-discuss at lists.openstack.org <openstack-discuss at lists.openstack.org>
Cc: Tina Wisbiski <t.wisbiski at connectria.com>; Yuliia Romanova <y.romanova at connectria.com>; Alexander Yeremko <a.yeremko at connectria.com>
Subject: Re: plain text config parameters encryption feature

[EXTERNAL] This email came from an external sender

Hi there.

Sorry, I totally missed that email, since we usually use tags to address specific teams, so please, use "[${PROJECT}]" in topic if you address a ML to specific group in future:)

1. There bunch of issues with code proposed, actually, which have been commented: [1] and neither of them were reflected in any way since 10 December. Gerrit Code-Review [2] system is a point where proposed code is being reviewed by Core Reviewers. Which it has been done in quite timely manner if you reffer to timestaps in patch of topic.
Why I said about ansible module, because current proposed solution is not idempotent and is hard to maintain. As if you want to fix or change smth in script that manages vault tokens, you will need to edit it in every role that uses it, which is really hard to manage.On the contrary ansible module is being managed from single place, so you just call it from role and don't need to do duplicate code for each role.
Also, current solution would create a new vault secret each time role runs even when secret already has been stored which is not idempotent way. Not saying about other 8 comments and that patches were never passing CI.
So from my perspective solution requires some effort before it can be considered as ready one. And are we quite picky when it comes to code quality that we merge.

2. According to OpenStack Releases guidelines [3], new features are not eligible for being backported. Also branches you;re mentioning are under Extended Maintenance which means only security patching is generally provided for them.
However, OpenStack-Ansible is flexible enough. So you should be able to deploy older OpenStack code with recent roles. We define SHA for services that are being deployed by OSA using SHAs [4], so technically it should be possible to use Yoga version of OpenStack-Ansible and override OpenStack version to Stein to get stein version of OpenStack services deployed.
It could be quite tricky in practice though, since we could drop some required variables that are now deprecated, but in most cases it can be fixed trivially. So what I'm saying that technically there's a way to use your code from master for older versions.

As Jonathan mentioned, we're quite open for communication in #opnestack-ansible channel on IRC.

[1] https://review.opendev.org/c/openstack/openstack-ansible-os_glance/+/814865<https://review.opendev.org/q/topic:bp%252Fprotecting-plaintext-configs>
[2] https://review.opendev.org/
[3] https://docs.openstack.org/project-team-guide/stable-branches.html#maintained
[4] https://opendev.org/openstack/openstack-ansible/src/branch/master/playbooks/defaults/repo_packages/openstack_services.yml

04.04.2022, 17:33, "Kelsi Parenteau" <k.parenteau at connectria.com>:
Good morning Openstack,

I hope this message finds you well. I wanted to follow up from Alex's last email below to help to clarify our questions here. We're reaching out to ask your reviewers for their feedback on what had changed on your side during our course of work. https://review.opendev.org/c/openstack/openstack-ansible-os_glance/+/814865

We had been working with your team over many months, and had been tracking to commit the code upstream. We were not sure why the Openstack reviewers had not brought up this potential concern for us earlier on in our discussions to be addressed.

Can you please advise us why that particular comment regarding the requirement for this to be an ansible plugin stops us from being able to commit the code?

We look forward to your feedback here, and would be happy to schedule a call as well to talk this through. Please let us know if you have any questions.






Thank you,







Kelsi Parenteau, PMP, PMI-ACP, CSM

Senior Project Manager

d: 586.473.1230 I m: 313.404.3214








________________________________
From: Alexander Yeremko <a.yeremko at connectria.com<mailto:a.yeremko at connectria.com>>
Sent: Tuesday, March 29, 2022 4:10 PM
To: openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org> <openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>>
Cc: Tina Wisbiski <t.wisbiski at connectria.com<mailto:t.wisbiski at connectria.com>>; Kelsi Parenteau <k.parenteau at connectria.com<mailto:k.parenteau at connectria.com>>; Yuliia Romanova <y.romanova at connectria.com<mailto:y.romanova at connectria.com>>
Subject: plain text config parameters encryption feature

Dear OpenStack community,

we are developing plain text config secrets encryption feature according to the next specification:

https://specs.openstack.org/openstack/openstack-ansible-specs/specs/xena/protecting-plaintext-configs.html

We started from Glance OS service and submitted two patchsets already:

https://review.opendev.org/c/openstack/openstack-ansible-os_glance/+/814865

Now we have two questions that we need to clarify to proceed our work on that feature and finish our development:

1. Is it correct that we need to develop more patchsets to rework some logic of encryption mechanism according
to comment to 'files/encypt_secrets.py' script that arised at the second patchset (PatchSet 2) dated Nov/30/2021 ?
Comment is by Dmitry Rabotyagov: "We _really_ should make it as an ansible plugin and re-work logic"

2. We wish to have such feature in previous releases also, not just in upcoming Yoga or Zed.
Stein, Train and Victoria - it would be excellent to have plain text secrets encryption with these releases also.
So question is how is it possible to use our feature in those releases also? Can we push some backports to those releases openstack-ansible repo?

Could someone be so kind and give us answers?

Best regards and wishes,
Alex Yeremko
This E-Mail (including any attachments) may contain privileged or confidential information. It is intended only for the addressee(s) indicated above. The sender does not waive any of its rights, privileges or other protections respecting this information. Any distribution, copying or other use of this E-Mail or the information it contains, by other than an intended recipient, is not sanctioned and is prohibited. If you received this E-Mail in error, please delete it and advise the sender (by return E-Mail or otherwise) immediately. Any calls held by you with Connectria may be recorded by an automated note taking system to ensure prompt follow up and for information collection purposes, and your attendance on any calls with Connectria confirms your consent to this. Any E-mail received by or sent from Connectria is subject to review by Connectria supervisory personnel.


--
Kind Regards,
Dmitriy Rabotyagov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220404/195d2dce/attachment-0001.htm>