[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: oo-install re: disconnected mode?



On Feb 7, 2014, at 10:41 PM, The Dude <michael mcconachie hotmail com> wrote:

> 
> On 02/05/2014 04:53 PM, N. Harrison Ripps wrote:
>> Hey there--
>> 
>> On Wed, 2014-02-05 at 21:48 +0000, The Dude wrote:
>>> Hi all,
>>> 
>>> I might have found something of interest concerning the new
>>> oo-installer (in regards to disconnected mode).  If you try to use it
>>> to install one broker, and one node -- the broker will install, and
>>> the node install fails.
>>> 
>>> Having two putty sessions open (I know,  I know. My clients forces me
>>> to use winblows..) I was able to capture the oo_install.pp files
>>> in /tmp before the installer blows them away. Taking a look in them, I
>>> noted that the broker is setting the  to 'none' but the node .pp file
>>> still contains the link to go out to the openshift stable repo to find
>>> packages.
>> This is great information, thanks! Can you tell me which puppet config
>> parameters in the node config file are wrong? I don't need the values,
>> just need to know which specific settings aren't being set correctly.
> 
> Hi H--
> 
> I finally got around to doing this.  It's the "repos_base" field. I noticed that you dropped a new installer a day after this thread, so it may be mute at this point.

Hey—was the field set differently between the two puppet configurations? Was it omitted in the problematic node config?

>>> I was able to do an AIO, but it's missing a ton of packages.  I was
>>> missing many of the oo-* commands, as well as the openshift-console
>>> stuff. It was missing ActiveMQ, and mlocate.  I had to manually
>>> install all of the openshift-* packages, and all the rubygems
>>> manually.  After doing that the rest fell inline.  Also notable, I was
>>> able to get oo-accept-broker, and all the other tests to work (of
>>> course) simply b/c they were looking for deps.
>>> 
>>> Have a good day,
>>> Michael J. McConachie | keys.fedoraproject.org | PubKey: 0xEDE583C4
>>> NOTE: The information included and/or attached in this electronic mail
>>> transmission may contain confidential or privileged information and is
>>> intended solely for the addressee(s). Any unauthorized disclosure,
>>> reproduction, distribution or the taking of action in reliance on the
>>> contents of the information are strictly prohibited. If you have
>>> received the message in error, please notify the sender by reply
>>> transmission and delete the message without copying, disclosing or
>>> forwarding.
>>> 
>>> 
>>> 
>>>> From: michael mcconachie hotmail com
>>>> To: nhr redhat com
>>>> CC: dev lists openshift redhat com
>>>> Subject: RE: oo-install re: disconnected mode?
>>>> Date: Fri, 31 Jan 2014 23:01:23 +0000
>>>> 
>>>> Hi Team,
>>>> 
>>>> Harrison: Thanks for your hard work on this. I downloaded, and
>>> tested the new 01/28/2014 portable installer. I was able to install a
>>> broker after your '--use-existing-puppet' additions. Although, when
>>> trying to use oo-install to install nodes, something seems amiss.
>>>> In the interest of adding node(s) to an existing broker (via
>>> oo-install):
>>>> When I use oo-install to add a node to an existing env, it bombs. It
>>> successfully ssh's to the node, and applies the puppet pieces. It does
>>> some work and reports a completed install with no errors. If I do a
>>> concurrent tail of /var/log/messages on the node (as the oo-installer
>>> is running from a different machine) I can see it attempt to set NTP
>>> time sources, and it yum installs some packages and deps before
>>> closing the SSH connection and reporting a successful install. Its
>>> definitely doing work, and then being told to stop at some point.
>>>> I rolled back the VM with snapshots, and tried again. This time with
>>> the pure puppet approach, and no oo-install wrapper. I built a quick
>>> node.pp based off of the puppet
>>>> guide, and attempted a 'puppet apply --verbose node.pp'. It bombed
>>> via erroring out after trying to reach out to the real world to
>>> calculate
>>>> deps, and download them. (In node.pp I tried setting the
>>> install_method
>>>> to 'yum', and 'none'. Both yield the same effect.)
>>>> 
>>>> So, I am wondering: does oo-install do a global replace on the repos
>>> vars concerning
>>>> all of Krishna's puppet pieces, to keep them from reaching out to
>>> the
>>>> real world? I know you can set it to 'yum' or 'none', and setting it
>>> to
>>>> 'none' seems to meet my needs of reaching out to an internal repo
>>> for
>>>> installing rpms.
>>>> 
>>>> All that to say I am looking to see if anyone has ideas for a semi
>>> automated install (outside of my scripting it all - which I'm about to
>>> just do, and give back to the community)? The reason for all of this,
>>> pertaining to subj: line is that I need to accomplish an install, in
>>> an
>>>> environment which is ENTIRELY disconnected from the internet. If
>>> one
>>>> were to have a requirement, where they were disallowed INTERNET
>>> ACCESS
>>>> of any kind, and the only method of getting binaries, was to import
>>> them
>>>> manually - and have the VM's in question communicate on their own
>>> internal network(s) - how would they install openshift using the
>>> currently available puppet manifests, and repos?
>>>> Is it possible that we can craft hooks for oo-install to have the
>>> puppet work in a --disconnected mode?  (Yaml file, or some variable
>>> that is set to determine the software sources)
>>>> What I have done:
>>>> 
>>>> --Import and Create a FC19 + Updates repo
>>>> --Import and Create an OSO3 repo
>>>> --Import and Create a puppet-openshift_origin git repo; installed it
>>> into /etc/puppet/modules/openshift_origin as we do for regular
>>> deployments
>>>> --Import and Create an openshift-origin git repo (for later use if I
>>> wanna go from source..)
>>>> --downloaded, and installed oo-installer + all deps for using
>>> oo-installer
>>>> I have a broker, and 4 nodes. They can all see each other. They are
>>> all updated, and have their rpm and git repos in place and usable.
>>>> I have a good, working broker - from what I can tell thus far.
>>>> 
>>>> Happy weekend to all of us.
>>>> 
>>>> 
>>>> --Mike
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ----------------------------------------
>>>>> Subject: Re: oo-install re: disconnected mode?
>>>>> From: nhr redhat com
>>>>> Date: Tue, 28 Jan 2014 16:11:15 -0500
>>>>> CC: dev lists openshift redhat com
>>>>> To: michael mcconachie hotmail com
>>>>> 
>>>>> 
>>>>> On Jan 28, 2014, at 15:01 , The Dude
>>> <michael mcconachie hotmail com> wrote:
>>>>>> ----------------------------------------
>>>>>>> Subject: Re: oo-install re: disconnected mode?
>>>>>>> From: nhr redhat com
>>>>>>> Date: Tue, 28 Jan 2014 14:43:08 -0500
>>>>>>> CC: dev lists openshift redhat com
>>>>>>> To: michael mcconachie hotmail com
>>>>>>> 
>>>>>>> Hey there--
>>>>>>> 
>>>>>>> On Jan 28, 2014, at 14:39 , The Dude
>>> <michael mcconachie hotmail com> wrote:
>>>>>>>> Hi List,
>>>>>>>> 
>>>>>>>> I have an environment that is disconnected from the internet. I
>>> need to install OSO.
>>>>>>>> So I:
>>>>>>>> 
>>>>>>>> -stood up openshift-origin, puppetlabs, fedora, and
>>> fedora-updates YUM repos internally. They all work as expected, and I
>>> can install from them.
>>>>>>>> -stood up a clone of the 'puppet-openshift_origin' git repo,
>>> and was able to clone into '/etc/puppet/modules/openshift_origin'
>>>>>>>> -have a broker, and a few nodes installed, updated, and
>>> configured (ready to install OSO via oo-install).
>>>>>>>> -oo-install portable installer is on the broker, and works as
>>> expected.
>>>>>>>> I wanted to ask if anyone knows of a way to tell oo-installer
>>> to **NOT** try to clone into the www facing puppet repos, and to use
>>> the local one instead. As a workaround for the yum stuff, I told it to
>>> use 'none' to allow them to be resolved locally (I have the repos
>>> already setup.) per the oo-install docs.
>>>>>>>> The issue is, that it appears the installer is trying to
>>> execute 'puppet module {list,update,install}' commands, and it's also
>>> reaching out to 'https://forge.puppetlabs.com' for some bits. I dug
>>> into the originator.rb file, and hacked at it but it made no
>>> difference. Anyone have any ideas?
>>>>>>> Your timing is good :-) I am working on some fixes around the
>>> puppet module today. I can add a flag to oo-install that tells
>>> originator.rb to skip the puppet checks and assume that the module is
>>> already in place.
>>>>>> Howdy H --
>>>>>> 
>>>>>> Aah, this is fantastic news. Glad to hear it. Thanks for the
>>> update.
>>>>> The installer is updated. The "--use-existing-puppet" flag will do
>>> what you want, but be warned that it doesn't check to make sure that
>>> you -really- have the puppet module installed; it just tries to run
>>> the `puppet apply` command and fails if the module isn't there.
>>>>>> PS: the only other noteworthy item is that I'm saw the unknown
>>> function error for 'ensure_resource'. Changing it to 'ensure' didn't
>>> help either.
>>>>>> PSS: from what I could tell, my error was for basic_auth, and had
>>> nothing to do with the kerberos.pp mentioned in the last 24 hours.
>>>>>> 
>>>>>> -- M
>>>>>> 
>>>>>> 
>>>>>>>> 
>>>>>>>> Thanks for your time team,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Michael J. McConachie
>>>>>>>> 
>>>>>>>> NOTE: The information included and/or attached in this
>>> electronic mail transmission may contain confidential or privileged
>>> information and is intended solely for the addressee(s). Any
>>> unauthorized disclosure, reproduction, distribution or the taking of
>>> action in reliance on the contents of the information are strictly
>>> prohibited. If you have received the message in error, please notify
>>> the sender by reply transmission and delete the message without
>>> copying, disclosing or forwarding.
>>>>>>>> _______________________________________________
>>>>>>>> dev mailing list
>>>>>>>> dev lists openshift redhat com
>>>>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>>>> _______________________________________________
>>>>>> dev mailing list
>>>>>> dev lists openshift redhat com
>>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>> 
> 
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]