Incorrect IP is returned when wrong registrstion credentials are used

[mmalina]

When you start cdk 2.1 with wrong credentials stored in SUB_USERNAME and SUB_PASSWORD, vagrant up will fail at this:
==> default: Registering box with vagrant-registration...
Invalid username or password. To create a login, please visit https://www.redhat.com/wapps/ugc/register.html
Registering to: subscription.rhn.redhat.com:443/subscription

Then service-manager returns this:
$ vagrant service-manager env

# docker env:
# Copying TLS certificates to /Users/rasp/jbossqa/cdk2.1/cdk2.1.rc5/components/rhel/misc/shared_folder/rhel-ose/.vagrant/machines/default/virtualbox/docker
# Set the following environment variables to enable access to the docker daemon running inside of the vagrant virtual machine:
export DOCKER_HOST=tcp://10.0.2.15:2376
export DOCKER_CERT_PATH=/Users/rasp/jbossqa/cdk2.1/cdk2.1.rc5/components/rhel/misc/shared_folder/rhel-ose/.vagrant/machines/default/virtualbox/docker
export DOCKER_TLS_VERIFY=1
export DOCKER_API_VERSION=1.21

# run following command to configure your shell:
# eval "$(vagrant service-manager env)"

Where is this IP coming from? The normal IP is 10.1.2.2 as is set up in the Vagrantfile:
PUBLIC_ADDRESS="10.1.2.2"

See also this related JIRA:
https://issues.jboss.org/browse/JBIDE-22609

[hferentschik]

10.0.2.15 always exist. This IP is actually correct - within the VM :-) It is not a routed IP. I guess if registration fails, something goes wrong and the 10.1.2.2 interface does not created and afaik our scripts rely on the last interface returned by hostname (or some other command).

The deeper lying issues are, however, imo with vagrant-registration

• Prompt to continue without subscription if user entered invalid username/password adb-vagrant-registration#80
• User should have more than one try to fill username and password adb-vagrant-registration#44

The registration should be more interactive and more fault tolerant. Also, in the case of the CDK we should imo terminate the bootstrap, if we don't get valid credentials. That would also prevent the problem above. The latter lies actually in our powers and could be implemented as part of this issue. Even though it is more likely a Vagrant configuration which lives in adb-developer-bundle.

[coolbrg]

@hferentschik

Also, in the case of the CDK we should imo terminate the bootstrap, if we don't get valid credentials.

We need to actually come up with actual flow. Right now its quite confusing and also not well documented IMO.
What I found is:

• If registration success, then you can acess everything, update dnf, run openshift, docker
• If registration fails, then you cannot access openshift, docker etc
• If skip registration, then you can access openshift, docker

Now not sure. Hence, we need to finalize the behavior and document it.

[mmalina]

Thanks for the details, Hardy. I agree that terminating the VM would make sense - better to have nothing than something half working (I wonder if we have any requirements for offline usage = no access to rhn servers, but that's another topic). And that would make it easier for Rob to react to this in the eclipse tooling.

[hferentschik]

If registration fails, then you cannot access openshift, docker etc

That's most likely what @mmalina sees

If skip registration, then you can access openshift, docker

Right, but you cannot build anything, at least not if you use images from the Red Hat registry. The docker daemon somehow hooks into the registration. Also you could not run any yum commands, etc

Now not sure. Hence, we need to finalize the behavior and document it.

+1

I agree that terminating the VM would make sense

I think this is the best option. Might need some work in vagrant-registration. Maybe we need a 'exit on registration failure' flag. We should create an issue there and link to here. @mmalina could you do this?

[jeffmaury]

See https://issues.jboss.org/browse/JBIDE-22725?focusedCommentId=13288804&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13288804

[LalatenduMohanty]

@mmalina @hferentschik @budhrg CDK is a free tool for developers. So IMO we should not be restricting (from CDK point of view) user for anything if the registration fails. However the restriction will come eventually from the subscription manager in terms of access to certain things e.g. yum install/update if the VM is not registered properly.

[bexelbie]

@LalatenduMohanty +1

Can we start OpenShift without registration? Could we delay the registration until the end of setup and configuration? Could we background it and make it the last thing we report and reprompt as needed?

[coolbrg]

@LalatenduMohanty @bexelbie : There is an issue projectatomic/adb-vagrant-registration#63 in vagrant-registration to perform register/unregister through command.
The flow could be:

1. vagrant up
2. user skip registration/failed
3. services should be running properly instead of skipped/failed registration (my proposal)
4. optionally user can register later with 'register' command.

Could we delay the registration until the end of setup and configuration?

I found that it is the first hook which gets executes when ssh is ready (code here).
There is separate implementation for Libvirt though. Probably, there might be some valid reason here and we may need to discuss with original authors if we want to change it place of execution.

[LalatenduMohanty]

The flow could be:

1. vagrant up
2. user skip registration/failed
3. services should be running properly instead of skipped/failed registration (my proposal)

• User can register later with vagrant vagrant-registration register command.

Sounds good me to cc @budhrg @bexelbie

[LalatenduMohanty]

Could we delay the registration until the end of setup and configuration? Could we background it and make it the last thing we report and reprompt as needed?

I like the idea too. +1

[bexelbie]

While I believe that adding vagrant service-manager [un]register is a great idea, I think we still need to support multiple automated and part of startup flows.

[LalatenduMohanty]

vagrant service-manager [un]register

@bexelbie I think @budhrg meant vagrant vagrant-registration [un]register . IMO we should not move registration/unregistration to VSM. Can you guys please explain little more about it and its value addition.

[coolbrg]

@LalatenduMohanty @bexelbie Ya I meant that only 😄 . My bad, I should have clarified that.

I hope we are talking about value addition of vagrant vagrant-registration [un] register here. It provide way to register from host directly instead of user going into VM, do register and then come out of it and perform oc related operations.
In case of successful registration, user can able to unregister from host directly if he/she wants.

Now, this will make clear that in either failed/skipped registration we need to make sure every services related to CDK is running.
Right now there is this issue (vsm #299 where we are discussing) which is breaking docker connections and moreover openshift environment variables are even not shown in env command.

[mmalina]

+1 I like the idea of being able to start all the services even without registering. It helps also in the event that you accidentally set your SUB_PASSWORD incorrectly - today you have to stop your box, fix the password and start again. It would be nice if you could just register later.

[naina-verma]

@LalatenduMohanty ,

I have tried one use case in which i come across the same output,

1. Copied Vagrantfile (form rhel-ose) and create a new folder place Vagrantfile (rhel-ose ) into it
2. Do vagrant up for both
3. Now, you will see one of them occupied 10.1.2.2 and another one 10.1.2.15
   This case i have observed in recent Vagrant file with virtual box

[bexelbie]

I am good with not having registration in vsm. I would like to see support retained for both vagrantfile/automatic reg and manual reg with the box able to boot without regard to registration status.

[hferentschik]

So where are we on this issue? Apart from changes to vagrant-registration, do we know why if the credentials are wrong, the output of vagrant-service-manager is wrong?

For what it's worth, imo it is the vagrant-registration which needs to abort the bootstrap here. If the user has registration enabled and tried to provider username/password, either via CLI or environment variables, vagrant up should abort, if the credentials are wrong. This is, however, a vagrant-registration issue.

[hferentschik]

On a side note, I think moving vagrant-registration code into vagrant-service-manager is not such a bad idea. In fact I was toying with the same idea for Landrush. The benefits are:

• Reduced amount plugins to install for the user
• Single stop plugin for all ADB/CDK VM related
• Easier to maintain and develop (only have to plan/release/maintain) a single plugin

In the case of Landrush for example we only use a small part of its functionality. Internalizing this into service-manager would allow us to just focus on the functionality we need.

This would mean of course the service-manager codebase would grow quite considerably and also contain a lot of different "things", but I think there is some virtue in this.

[hferentschik]

So I think we should do the following:

• Determine what is causing the issue described in the original bug report
• Create an issue in vagrant-registration to abort bootstrap on failed registration
• Create a discussion around creating a "rule the world" service-manager by pulling in functionality from other plugins used by ADB/CDK

[robstryker]

Hey guys, any update on this?

[coolbrg]

@robstryker , We are no longer maintaining the project now as we have migrated to minishift.

[mmalina]

@budhrg are you aware that cdk 2.x is officially supported until 2019? who is maintaining it then?

[coolbrg]

are you aware that cdk 2.x is officially supported until 2019?

@mmalina Need to confirm. Sorry I was not aware of it.

[LalatenduMohanty]

@budhrg are you aware that cdk 2.x is officially supported until 2019? who is maintaining it then?

@mmalina the current version of CDK is only supported and that would be CDK 3.0. Not sure if you are confusing with Devstudio.