feat: Added levels of connectivity to connect command #179

jirihnidek · 2024-12-09T16:39:31Z

Card ID: CCT-1005
First step of levels of connectivity
When connect command is used, then it is possible to
enabled or disable three features using command line
options --enable-feature or --disable-feature. Following
features are supported
- content
- analytics
- remote-management
Added checks for allowed combination of CLI options
Modified UI little bit to be able to visualize that
feature was not started
Output to JSON format is still supported
When machine readable format is used, then add information
about enabled/disabled content to generated JSON file
When machine readable output is used, then list of
enabled/disable features is added to the generated JSON doc
Unified UI for colorful and not colorful mode
Changed UI for disconnect command to looks similar to connect command
Connecting looks like this in interactive mode:

Connecting localhost to Red Hat.
This might take a few seconds.

Features preferences: [✓]content, [✓]analytics, [✓]remote-management

 [✓] This system is already connected to Red Hat Subscription Management
  [✓] Content ... Red Hat repository file generated
  [✓] Analytics ... Connected to Red Hat Insights
  [✓] Remote Management ... Activated the yggdrasil service

Successfully connected to Red Hat!

Manage your connected systems: https://red.ht/connector

jirihnidek · 2024-12-09T16:41:18Z

Open question:

How should we list enabled/disabled features in generated JSON document?
Current output looks like this:

{
    "hostname": "localhost",
    "uid": 0,
    "enabled_features": [
        "analytics",
        "remote-management"
    ],
    "disabled_features": [
        "content"
    ],
    "rhsm_connected": true,
    "content_enabled": false,
    "insights_connected": true,
    "yggdrasil_started": true
}

Another possible solution could be following:

{
    "hostname": "localhost",
    "uid": 0,
    "features": {
        "enabled": [
            "analytics",
            "remote-management"
        ],
        "disabled": [
            "content"
        ],
    },
    "rhsm_connected": true,
    "content_enabled": false,
    "insights_connected": true,
    "yggdrasil_started": true
}

Or we can introduce something like this. This has potential to add there more attributes in the future:

{
    "hostname": "localhost",
    "uid": 0,
    "features": {
        "content": {
            "enabled": false,
        },
        "analytics": {
            "enabled": true,
        },
        "remote-management": {
            "enabled": true,
        },
    },
    "rhsm_connected": true,
    "content_enabled": false,
    "insights_connected": true,
    "yggdrasil_started": true
}

TODO:

Allow to enabled/disable features in interactive mode, when user has to input username & password (this should be part of another PR)

m-horky

The patch seems solid. I won't comment much on the code itself; we'll likely see further changes done in near future as we stabilize it before new features come.

The output seems to jump around, were the two spaces intentional?

$ rhc connect --disable-feature analytics
...
 [✓] Connected to Red Hat Subscription Management
  [✓] Content ... Red Hat repository file generated
 [ ] Analytics ... Connecting to Red Hat Insights disabled
  [✓] Remote Management ... Activated the yggdrasil service

When disconnecting, Insights reported status 1 even though we should have detected we're (already) unregistered:

 [✓] Deactivated the yggdrasil service
 [𐄂] Cannot disconnect from Red Hat Insights: exit status 1
 [✓] Disconnected from Red Hat Subscription Management

The same goes for disconnection: with nothing connected in the first place, the output doesn't say yggdrasil wasn't enabled in the first place. That's a non-blocking note, but it feels strange.

$ rhc connect --enable-feature remote-management --disable-feature remote-management
cannot enable feature: "remote-management": feature "remote-management" explicitly disabled

Are we able to display something prettier and more human-understandable? Non-blocking note, may be addressed later.

m-horky · 2024-12-17T13:06:35Z

connect_cmd.go

+			if uiSettings.isMachineReadable {
+				connectResult.EnabledFeatures = append(connectResult.EnabledFeatures, feature.ID)
+			}
+			featuresStr = append(featuresStr, "["+symbolOK+"]"+feature.ID)


I think there should be a space between the checkbox and the text.

I would like to have some white space between checkbox and the text too, but standard "space" is IMHO too long and final line could be confusing at the first glance:

Current behavior:

Features preferences: [✓]content, [ ]analytics, [ ]remote-management

Proposed behavior:

Features preferences: [✓] content, [ ] analytics, [ ] remote-management

That looks fine to me, I wouldn't worry too much.

m-horky · 2024-12-17T13:06:41Z

connect_cmd.go

+			if uiSettings.isMachineReadable {
+				connectResult.DisabledFeatures = append(connectResult.EnabledFeatures, feature.ID)
+			}
+			featuresStr = append(featuresStr, "[ ]"+feature.ID)


I think there should be a space between the checkbox and the text.

Same comment here.

m-horky · 2024-12-17T13:22:23Z

Or we can introduce something like this. This has potential to add there more attributes in the future:

{
    "hostname": "localhost",
    "uid": 0,
    "features": {
        "content": {
            "enabled": false,
        },
        "analytics": {
            "enabled": true,
        },
        "remote-management": {
            "enabled": true,
        },
    },
    "rhsm_connected": true,
    "content_enabled": false,
    "insights_connected": true,
    "yggdrasil_started": true
}

I like the nested approach. Would it make sense to move the _connected, _enabled keys into the features map?

"features": {
  "content": {
    "enabled": true,
    "connected": true,
  },
  "analytics": {
    "enabled": true,
    "connected": false,
  },
  ...
}

subpop

One small change I think we can make. I will test the behavior of this branch and follow up with another review.

subpop · 2025-01-02T16:25:35Z

rhsm.go

+	var enabledContentStr string
+	if enableContent {
+		enabledContentStr = "true"
+	} else {
+		enabledContentStr = "false"
+	}


I believe this could be simplified into a single Sprintf statement, using the Stringer implementation of the bool type.

Suggested change

var enabledContentStr string

if enableContent {

enabledContentStr = "true"

} else {

enabledContentStr = "false"

}

enableContentStr := fmt.Sprintf("%v", enableContent)

subpop · 2025-01-02T16:53:22Z

main.go

@@ -157,6 +157,16 @@ func main() {
 					Usage:   "register with `KEY`",
 					Aliases: []string{"a"},
 				},
+				&cli.StringSliceFlag{
+					Name:    "enable-feature",
+					Usage:   "enable feature during connection",


Using the backtick notation in the usage string will encode it in help output,
making the output consistent with other, existing flags.

Suggested change

Usage: "enable feature during connection",

Usage: "enable `FEATURE` during connection",

subpop · 2025-01-02T16:53:43Z

main.go

+				},
+				&cli.StringSliceFlag{
+					Name:    "disable-feature",
+					Usage:   "disable feature during connection",


Suggested change

Usage: "disable feature during connection",

Usage: "disable `FEATURE` during connection",

subpop · 2025-01-02T17:01:10Z

rhsm.go

 	if err := privConn.Object(
 		"com.redhat.RHSM1",
 		"/com/redhat/RHSM1/Register").Call(
 		"com.redhat.RHSM1.Register.RegisterWithActivationKeys",
 		dbus.Flags(0),
 		orgID,
 		activationKeys,
-		map[string]string{},
+		map[string]string{"enable_content": enabledContentStr},


When I try to register with my activation key, I get the following error:

[link@lima-rhel-10 rhc]$ sudo ./builddir/rhc connect -o 12671438 -a developer Connecting lima-rhel-10 to Red Hat. This might take a few seconds. Features preferences: [✓]content, [✓]analytics, [✓]remote-management [𐄂] Cannot connect to Red Hat Subscription Management [𐄂] Skipping generation of Red Hat repository file [𐄂] Skipping connection to Red Hat Insights [𐄂] Skipping activation of yggdrasil service Successfully connected to Red Hat! Manage your connected systems: https://red.ht/connector The following errors were encountered during connect: TYPE STEP ERROR ERROR rhsm cannot connect to Red Hat Subscription Management: error: Unknown arguments: dict_keys(['enable_content'])

Does the D-Bus method RegisterWithActivationKeys not accept 'enable_content' as
a parameter option? If so, does this mean that we cannot opt out of content if
registering with an activation key?

@subpop Good point. I am working on the fix fix for rhsm.service. It should be simple.

The PR for subscription-manager created: candlepin/subscription-manager#3488

connect_cmd.go

subpop · 2025-01-07T14:40:48Z

Or we can introduce something like this. This has potential to add there more attributes in the future:

{
    "hostname": "localhost",
    "uid": 0,
    "features": {
        "content": {
            "enabled": false,
        },
        "analytics": {
            "enabled": true,
        },
        "remote-management": {
            "enabled": true,
        },
    },
    "rhsm_connected": true,
    "content_enabled": false,
    "insights_connected": true,
    "yggdrasil_started": true
}

I like the nested approach. Would it make sense to move the _connected, _enabled keys into the features map?

"features": {
  "content": {
    "enabled": true,
    "connected": true,
  },
  "analytics": {
    "enabled": true,
    "connected": false,
  },
  ...
}

I like this as well. Putting both "connected" and "enabled" inside the JSON object seems like the most scalable approach.

jirihnidek · 2025-01-07T15:09:37Z

@m-horky @subpop OK, it seems we have consensus that we will use the third variant of proposed JSON format.

BTW: We can do big changes of JSON format ATM, because it hasn't been shipped in any official release. We can drop content_enabled, insights_connected and yggdrasil_started and move all information to features, because insights_connected would be duplicate of features["analytics"].connected. I'm also proposing to not use connected keyword, but I would use word successful, because word connected does not make much sense e.g. for feature content

{
    "hostname": "localhost",
    "uid": 0,
    "rhsm_connected": true,
    "features": {
        "content": {
            "enabled": false,
            "successful": true,
        },
        "analytics": {
            "enabled": true,
            "successful": false,
        },
        "remote_management": {
            "enabled": true,
            "successful": true,
        },
    },
}

* Card ID: CCT-1005 * First step of levels of connectivity * When connect command is used, then it is possible to enabled or disable three features using command line options --enable-feature or --disable-feature. Following features are supported - content - analytics - remote-management * Added checks for allowed combination of CLI options * Modified UI little bit to be able to visualize that feature was not started * Output to JSON format is still supported, but it was modified. * When machine readable format is used, then information about features could be following: { "hostname": "localhost", "uid": 0, "rhsm_connected": true, "features": { "content": { "enabled": true, "successful": true }, "analytics": { "enabled": true, "successful": false, "error": "some error message" }, "remote_management": { "enabled": false, "successful": false } } }

Archana-PandeyM · 2025-01-09T10:01:28Z

Hi, this is my first attempt to get hands on for this feature. When I am trying to enable only one feature I still see everything getting enabled, for example I am trying to enable only content but all three feature are enabled. This should not happen, I should not need to mention disable-feature explicitly-

`[root@kvm-01-guest13 ~]# rhc connect --username ******* --password ******* --enable-feature content
Connecting kvm-01-guest13.lab.eng.brq2.redhat.com to Red Hat.
This might take a few seconds.

Features preferences: [✓]content, [✓]analytics, [✓]remote-management

 [✓] Connected to Red Hat Subscription Management
  [✓] Content ... Red Hat repository file generated
  [✓] Analytics ... Connected to Red Hat Insights
  [✓] Remote Management ... Activated the yggdrasil service

Successfully connected to Red Hat!

Manage your connected systems: https://red.ht/connector
[root@kvm-01-guest13 ~]#`

jirihnidek · 2025-01-09T11:59:38Z

Hi, this is my first attempt to get hands on for this feature. When I am trying to enable only one feature I still see everything getting enabled, for example I am trying to enable only content but all three feature are enabled. This should not happen, I should not need to mention disable-feature explicitly-
[root@kvm-01-guest13 ~]# rhc connect --username ******* --password ******* --enable-feature content
Connecting kvm-01-guest13.lab.eng.brq2.redhat.com to Red Hat.
This might take a few seconds.

Features preferences: [✓]content, [✓]analytics, [✓]remote-management

 [✓] Connected to Red Hat Subscription Management
  [✓] Content ... Red Hat repository file generated
  [✓] Analytics ... Connected to Red Hat Insights
  [✓] Remote Management ... Activated the yggdrasil service

Successfully connected to Red Hat!

Manage your connected systems: https://red.ht/connector

The intention of --enable-feature FEATURE was originally little bit different. By default some features could be disabled and this CLI option would only enable one specific FEATURE.

In theory we can change behavior of --enable-feature, but your proposed behavior could be also considered confusing in some situation. @subpop What do you thing?

Archana-PandeyM · 2025-01-09T12:17:00Z

@subpop @jirihnidek I have one more concern, when rhc connect is run without --enable-feature or --disable-feature then by default connectivity level should be “level 2: analytics” (Did this requirement change overtime, not sure so I am just highlighting )

`[root@kvm-01-guest13 ~]# rhc connect --username ********  --password *******
Connecting ******************* to Red Hat.
This might take a few seconds.

Features preferences: [✓]content, [✓]analytics, [✓]remote-management

 [✓] Connected to Red Hat Subscription Management
  [✓] Content ... Red Hat repository file generated
  [✓] Analytics ... Connected to Red Hat Insights
  [✓] Remote Management ... Activated the yggdrasil service

Successfully connected to Red Hat!

Manage your connected systems: https://red.ht/connector

`

subpop · 2025-01-09T14:49:40Z

The intention of --enable-feature FEATURE was originally little bit different. By default some features could be disabled and this CLI option would only enable one specific FEATURE.

In theory we can change behavior of --enable-feature, but your proposed behavior could be also considered confusing in some situation. @subpop What do you thing?

I don't like the idea of --enable-feature implicitly disabling all features except for the named one. That is not intuitive. --enable-feature should only enable a feature that is not enabled. If it is passed, naming a feature that is already enabled (by default or via dependency resolution), it should be a no-op. In the current circumstances, where all features are enabled by default, it's a meaningless flag, but if we change the defaults (as a result of the comment above) or add new features that are not enabled by default, it will become a more meaningful flag.

@Archana-PandeyM In the current design, to accomplish what you were trying to do, you would need to disable the features you don't want: --disable-feature analytics --disable-feature management.

subpop · 2025-01-09T14:52:22Z

@subpop @jirihnidek I have one more concern, when rhc connect is run without --enable-feature or --disable-feature then by default connectivity level should be “level 2: analytics” (Did this requirement change overtime, not sure so I am just highlighting )

rhc today enables all three levels by default, so the design here maintains that. I'll check with Christian if he has any expectation around changing the default enabled features.

m-horky requested changes Dec 17, 2024

View reviewed changes

subpop requested changes Jan 2, 2025

View reviewed changes

jirihnidek force-pushed the jhnidek/connect_levels_of_connectivity branch from 170304e to bd93706 Compare January 7, 2025 22:23

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: Added levels of connectivity to connect command #179

feat: Added levels of connectivity to connect command #179

jirihnidek commented Dec 9, 2024 •

edited

Loading

jirihnidek commented Dec 9, 2024 •

edited

Loading

m-horky left a comment

m-horky Dec 17, 2024

jirihnidek Jan 7, 2025

m-horky Jan 7, 2025

m-horky Dec 17, 2024

jirihnidek Jan 7, 2025

m-horky commented Dec 17, 2024

subpop left a comment

subpop Jan 2, 2025

subpop Jan 2, 2025

subpop Jan 2, 2025

subpop Jan 2, 2025

jirihnidek Jan 6, 2025

jirihnidek Jan 6, 2025

subpop commented Jan 7, 2025

jirihnidek commented Jan 7, 2025 •

edited

Loading

Archana-PandeyM commented Jan 9, 2025 •

edited

Loading

jirihnidek commented Jan 9, 2025

Archana-PandeyM commented Jan 9, 2025

subpop commented Jan 9, 2025

subpop commented Jan 9, 2025

	Usage: "enable feature during connection",
	Usage: "enable `FEATURE` during connection",

	Usage: "disable feature during connection",
	Usage: "disable `FEATURE` during connection",

feat: Added levels of connectivity to connect command #179

Are you sure you want to change the base?

feat: Added levels of connectivity to connect command #179

Conversation

jirihnidek commented Dec 9, 2024 • edited Loading

jirihnidek commented Dec 9, 2024 • edited Loading

m-horky left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

m-horky commented Dec 17, 2024

subpop left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

subpop commented Jan 7, 2025

jirihnidek commented Jan 7, 2025 • edited Loading

Archana-PandeyM commented Jan 9, 2025 • edited Loading

jirihnidek commented Jan 9, 2025

Archana-PandeyM commented Jan 9, 2025

subpop commented Jan 9, 2025

subpop commented Jan 9, 2025

jirihnidek commented Dec 9, 2024 •

edited

Loading

jirihnidek commented Dec 9, 2024 •

edited

Loading

jirihnidek commented Jan 7, 2025 •

edited

Loading

Archana-PandeyM commented Jan 9, 2025 •

edited

Loading