search

projectatomic / vagrant-service-manager

To provide the user a CLI to configure the ADB/CDK for different use cases and to provide glue between ADB/CDK and the user's developer environment.
GNU General Public License v2.0
18 stars 16 forks source link

Incorrect IP is returned when wrong registrstion credentials are used #299

Open mmalina opened 8 years ago

mmalina commented 8 years ago

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 commented 8 years ago

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

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 commented 8 years ago

@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:

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

mmalina commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

LalatenduMohanty commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

@LalatenduMohanty @bexelbie : There is an issue https://github.com/projectatomic/adb-vagrant-registration/issues/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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@LalatenduMohanty @bexelbie Ya I meant that only :smile: . 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 commented 8 years ago

+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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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:

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 commented 8 years ago

So I think we should do the following:

robstryker commented 7 years ago

Hey guys, any update on this?

coolbrg commented 7 years ago

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

mmalina commented 7 years ago

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

coolbrg commented 7 years ago

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

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

LalatenduMohanty commented 7 years ago

@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.