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

Re: oo-install re: disconnected mode?

On Feb 3, 2014, at 17:28 , Luke Meyer <lmeyer redhat com> wrote:

> ----- Original Message -----
>> From: "N. Harrison Ripps" <hripps redhat com>
>> To: "The Dude" <michael mcconachie hotmail com>
>> Cc: dev lists openshift redhat com
>> Sent: Monday, February 3, 2014 10:08:15 AM
>> Subject: Re: oo-install re: disconnected mode?
>> Hey there--
>> On Jan 31, 2014, at 18:01 , The Dude <michael mcconachie hotmail com>
>> wrote:
>>> 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.
>> The intention of 'none' is that no RPM installations should be
>> attempted at all. The system expects that all of the software is in
>> place and just needs to be configured.
> Whoah, we should be clear about this.
> Now... this could have drifted since we defined it, but the original intention of install method "none" was that the system's yum repos are all set up exactly the way desired already -- no modifications needed. But then the RPM install still happens based on those repos.
> So if you can provide all the RPMs in a way that yum can get what it needs (whether internal/external/NFS/local HD/DVD-ROM...), and don't want oo-install to monkey with your yum configuration, but still want it to figure out which RPMs are needed and install those - that's what "none" was for.
> Is that not still the case?

Sorry, I may have mis-stated things. Krishna, can you confirm that what Luke has described above is also true for the puppet module?

>> oo-install needs to be a little smarter in this context; when it
>> sanity checks the system, it will still run a `yum provides` if it
>> finds that you are missing a required executable. I need to drop
>> that behavior for subscription method 'none' and just tell the user
>> - "you are missing ${utility}; go fix it".
>> That said, once oo-install hands the job off to our puppet module,
>> you should see no 'yum' anything for subscription type 'none'.
>> However, I think what you are trying to do is to split the
>> difference. You have a yum repo that you've set up, but for some yum
>> commands, it sounds like yum is trying to contact the mother ship
>> instead of going to your repo. Let us know which yum commands are
>> causing probles for you and we should be able to sort this out;
>> those commands just need to be made to always look for the answers
>> in your local repo.
>>> 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
>>> 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]