RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1939281 - aws-vpc-move-ip: Enable eni lookup for AWS shared networks via RAM [RHEL 8]
Summary: aws-vpc-move-ip: Enable eni lookup for AWS shared networks via RAM [RHEL 8]
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: resource-agents
Version: ---
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Oyvind Albrigtsen
QA Contact: Brandon Perkins
URL:
Whiteboard:
Depends On:
Blocks: 1943093 1943095 1943111 1943728
TreeView+ depends on / blocked
 
Reported: 2021-03-15 22:23 UTC by Reid Wahl
Modified: 2023-01-20 10:13 UTC (History)
13 users (show)

Fixed In Version: resource-agents-4.1.1-91.el8
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1939282 1943093 1943095 1943111 1943728 (view as bug list)
Environment:
Last Closed: 2021-11-09 17:27:32 UTC
Type: Feature Request
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github ClusterLabs/resource-agents/commit/b727fe4e 0 None None None 2021-03-15 22:33:33 UTC
Red Hat Knowledge Base (Solution) 5884761 0 None None None 2021-03-16 00:37:55 UTC
Red Hat Product Errata RHSA-2021:4139 0 None None None 2021-11-09 17:28:00 UTC

Description Reid Wahl 2021-03-15 22:23:11 UTC
Description of problem:

Felix from AWS reached out to us to request zStreams for resource-agents commit b727fe4e.
  - https://github.com/ClusterLabs/resource-agents/pull/1549/commits/b727fe4e

As far as I know, we're already getting this into RHEL 8.4 via a rebase on resource-agents 4.7.0. So this BZ is to request that we get it into 8.1.z and 8.2.z (for SAP support) as well as 8.3.z (in order not to skip one).

I'll open a separate BZ for RHEL 7 and leave that to engineering's discretion. On the one hand, it's technically a new feature. On the other hand, the feature is a way of making the RA compatible with a particular type of infrastructure rather than adding new functionality, and it sounds like there's some significant demand for this.


Conversation with Felix in the support case regarding justification:
~~~
AWS:
>> While I understand that this may be a new feature, this is also OK to ship still on RHEL 8.1 and 8.2. Is it possible to request it?
>> 
>> The main reasons behind my ask are:
>> 
>> 1) AWS customers only use these RAs with their SAP Applications, and currently only RHEL 8.1 and RHEL 8.2 are certified for SAP
>> 2) The only "RHEL 8.x for SAP" versions available for customers in AWS Marketplace are 8.1 and 8.2, and we aren't aware of Red Hat's plans to certify 8.3 and later, or even when it will happen. 
>> 
>> In summary, I'm afraid that waiting for RHEL 8.4 will take way too long and we need to improve this timeline to reduce the time to market of some of these features.

RH:
> Maybe. As far as I know, there's no Bugzilla for it, as there's been no demand expressed to us by Red Hat customers so far. But if the absence of this feature is likely to have a negative impact on users, then it may be possible to backport it.
> 
> I don't fully understand the technology involved in this patch, or how widely used it is and whom it's likely to impact. Can you tell us any more about this, so that we can relay the info to the dev team?

AWS:
2) https://github.com/ClusterLabs/resource-agents/pull/1549

This is the most important one and the one that I really really care to be back ported.  Shared VPC is something that customers are starting to use on their AWS deployments to create more sophisticated and easier to manage VPC (network) architectures and topologies, and this patch will allow our common customers to use shared VPC subnets from a different AWS account with their Red Hat HA cluster nodes.

Most of our customers migrating to AWS, or implementing HA cluster for SAP on AWS are still on RHEL 7.x and since there are no upgrade paths from RHEL 7.x to RHEL 8.x in AWS I would like try to keep it as current as possible and where possible still ship small improvements and feature requests like this one.

Customers are requesting this to us (AWS) as since they are mostly using the AWS provided Red Hat images we end up receiving the feedback directly, and this is likely the reason on why you haven't heard of it on your side. Unfortunately, due to strict security and confidentiality policies I'm not allowed to share customer names, but I can say that there is demand and interest of new and existing customers, and some of them have already deployed RHEL 7.x and are simply waiting for this feature to enable their HA cluster, and others decided to move on with the upstream agent version only to enable this feature (regardless of being aware of support policies).
~~~

-----

Version-Release number of selected component (if applicable):

N/A

-----

How reproducible/Steps to reproduce:

I haven't researched how to set up the infrastructure to test this. I'm relaying this request from AWS.

Comment 7 Reid Wahl 2021-04-01 23:54:27 UTC
@fguilher, would you be able to help us with this? Our QE engineer asked:

> I think I'm going to need a test case for this bug as it isn't entirely
> clear to me how this is supposed to work.  The best description I could find
> was in:
> 
> https://github.com/ClusterLabs/resource-agents/pull/1549#issuecomment-
> 682127846
> 
> but even there, I couldn't tell if we are talking about different
> organization accounts, user accounts, VPCs or what.  So, if someone can
> point me to implementation documentation or give me a simple positive test
> case, I should be able to test that plus create negative test cases for it. 


Thanks in advance if so!

Comment 11 Dean Jansa 2021-04-08 17:06:23 UTC
ON_QA bug without Verified:Tested should be in the MODIFIED state.

Comment 13 Dean Jansa 2021-04-15 08:01:06 UTC
ON_QA bug without Verified:Tested should be in the MODIFIED state.

Comment 14 Guilherme 2021-04-15 11:48:05 UTC
Hello, 

I met with the QAE assigned to this BZ and explained the basic architecture and the important things to consider to test this BZ. I'm going to follow up with him in the next few days to ensure we can move ahead with the testing.

In summary, VPC sharing allows multiple AWS accounts to create their application resources, such as Amazon EC2 instances, into shared, centrally-managed Amazon Virtual Private Clouds (VPCs). In this model, the account that owns the VPC (owner) shares one or more VPC subnets with other accounts (participants/consumers) that belong to the same AWS Organization. After a VPC subnet is shared, the AWS accounts which the VPC has been shared with, can launch the EC2 instances (cluster nodes) using these shared VPC subnets. In order to properly test, the proper AWS setup is required, including AWS IAM permissions, AWS Organizations and sharing a VPC using AWS Resource Access Manager (RAM).

This BZ introduces all the code changes required to enable a participants/consumers AWS Accounts to make mutable API calls to the account owning the VPC, and to lookup the EC2 resources correctly.

Basic test cases are:
- Ensure backward compatibility (all scenarios working before this BZ should still work!)
- Ensure no regressions were introduced
- Test the new parameters:
  - lookup_type - either NetworkInterfaceId or InstanceId
  - routing_table_role - required for Shared VPC scenarios

Please, let me know any other questions arrises and I'm available for further discussions.

Comment 16 Dwayne 2021-04-21 15:53:41 UTC
Set Customer Escalation Flag=Yes, per ACE EN-39654.
Per the RH Account team, "This bug at is having a major impact on Toyota's their SAP-Hana implementation and project timeline. This issue has very high visibility at Toyota."

Comment 19 errata-xmlrpc 2021-11-09 17:27:32 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: resource-agents security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:4139


Note You need to log in before you can comment on or make changes to this bug.