openshiftdemos / openshift-ops-workshops Goto Github PK

after installation is complete, the command # oc get nodes gives the IP addresses as names for nodes instead of displaying the given hostnames/instance names.

The lab instructions don't warn the student about accepting the self-signed certificate or why it's happening.

https://github.com/openshift/openshift-cns-testdrive/blob/master/tests/defaultproj_template_automation.yml#L9

This should be "to use project request template"

classes - 'OpenShift Test Drive for Administrators' and
'ocp-admin-testdrive-master-branch'
are not being built successfully when opening the AWS console. The CloudFormation service shows the error of 'create_failed'

Since deploying CNS requires a basic understanding of some OpenShift components (services, pods, routes, etc) it makes sense to have the app management lab come before the cns-deploy lab.

#125 introduced an error -- the admonition block uses the wrong delineator (- instead of =)

workshopper URLs are pointing to master branch at the moment in several file locations. Re-route to production before go-live.

- name: Checking status of all the nodes to be 'Ready' command: oc get -o jsonpath='{.status.conditions[?(@.reason=="KubeletReady")].type}' node {{ item }} with_items: - "{{ groups.nodes }}" register: status_of_node failed_when: "'Ready' not in status_of_node.stdout"

@kmurudi we cannot rely on the hostnames from the ansible inventory. They are different to the hostnames used by OpenShift. I suggest we use openshift_facts.yml supplied with openshift-ansible to determine the hostname.

Currently the lab guide asks the user to create the file. This file should ideally be precreated or just present in the repo.

Instead of presenting the user with the prompt:

[cloud-user@{{MASTER_HOSTNAME}} ~]$ heketi-cli node list | grep ca777ae0285ef6d8cd7237c862bd591c

Please just have the command:

heketi-cli node list | grep ca777ae0285ef6d8cd7237c862bd591c

This makes copy/paste out of the lab guide much easier, especially for blocks of commands.

Syntax taken from https://github.com/osevg/workshopper-content/blob/b1d50492022fd7071962507ac2a102a749dbc57c/configmap.adoc does not appear to work:

In this lab, you will replace the environment variables provided in the link:databases[previous labs] and use a ConfigMapinstead to configure thenationalparks application.

Currently we just offer to the user to explore the quotas and limits without much real direction. It could be good to add some more specific examples to show the evaluator what happens in practice.

Lab module 5 "Pruning data" requires that a sample application (currently assuming cake-php) was deployed and updated multiple times in a namespace called "sampleapp" in Lab Module 4 ("Cluster Management Basics")

Currently we have:

                MASTER_EXTERNAL_FQDN="master.${AWS::AccountId}.${PublicHostedZone}"
                MASTER_INTERNAL_FQDN="master.internal.${PublicHostedZone}"

We probably should also add the master public IP address, since that's what we are going to tell people to SSH into. This also means that, once they find the lab guide, they don't have to worry about going back to the Qwiklab interface to find the IP address.

We should introduce a WaitConditionHandle in the CFN template to signal CREATE_COMPLETE only when all resources are provisioned and stood up, which includes:

• all nodes are online and reachable via SSH
• IdM's LDAP service is reachable on port 389
• IdM's setup routine has produce ca.crt
• lab guide URL is reachable

While indicated in the docs, for the purposes of the test drive we don't need to include it.

The following ldif file should be dropped onto the IDM server during environment provisioning:

dn: uid=system,cn=sysaccounts,cn=etc,dc=auth,dc=internal,dc=aws,dc=testdrive,dc=openshift,dc=com
changetype: add
objectclass: account
objectclass: simplesecurityobject
uid: system
userPassword: bindingpassword

Just after provisioning IDM, and before doing any of the user creation, we should execute the following command:

ldapmodify -x -D 'cn=Directory Manager' -w ldapadmin -f /path/to/sysaccount.ldif

Then, we need to change the /etc/ansible/hosts file that gets deployed to use the above DN and password in place of the existing one.

This will at least prevent us from being locked out entirely when the "too many failed logins" error occurs.

We also need to update /home/cloud-user/groupsymc.yaml as well, as this appears to have auth information in it, too.

For the user to be able to use ansible-playbook and access the config.yml playbook from the openshift-ansible git repository, it should be present in the master host. The inventory file is present but the ansible playbook needed to run the advanced installation is not.

Also, two instances present of node01 in the list of EC-2 Instances

When adding nodes to the OpenShift cluster or nodes to the CNS topology it's best to use different Ansible inventory files to avoid side-effects of additional groups during OpenShift installation.

If we don't do the installation with LDAP for auth, it means the admin has to re-run the installer (albeit with -t master) later. This is a little bit... awkward.

I am thinking we may wish to install with LDAP auth out of the box.

• it won't affect the system:admin special user
• verification of installation can then include a simple "oc login" as a user
• module 2 can become LDAP setup and group manipulation
• module 3 can become CNS installation and configuration

Thoughts?

@cooktheryan
@dmesser

Although these things aren't designed to be run more than once... if it fails it means something is really wrong...

when running the automation/tests in a single playbook, the inventory is loaded on playbook start. When the test of items in the fact new_cns_nodes_internal_fqdn is executed against the group cns, Ansible hasn't learned of these hosts yet, so this test fails...

In a fresh, successfully finished deployment I cannot login as an IdM user. It yields "Internal error occurred: unexpected response: 500". In the system logs I can see: "logging error output: "Error: LDAP Result Code 53 Unwilling To Perform: Too many failed logins.".
This behavior is not consistently reproducible but appears every 10-20 deployments. Thoughts?

This provides for a more accurate simulation of what the end user is doing.

It's actually not really doing the right thing at present.

https://github.com/openshift/openshift-cns-testdrive/blob/master/tests/ldap-groupsync_verification.yaml#L9

We have content littered in several locations. If a script, file, or etc. needs to be used during the exercises, it should go into the repo in the support folder. For generated files that will be used (like the groupsync config), the write_files section of cloud-init should be relocated such that this repo is cloned first, and then the files are written out.

The nodes04-06 are not added to the cluster so the play applying labels fails.

TASK [label storage nodes] ****************************************************************************************************************************************************************************************
Wednesday 09 August 2017  20:29:09 +0000 (0:00:00.683)       0:03:28.568 ****** 
failed: [localhost] (item=node04.internal.aws.testdrive.openshift.com) => {
    "changed": true, 
    "cmd": "oc label node/node04.internal.aws.testdrive.openshift.com storagenode=glusterfs", 
    "delta": "0:00:00.221782", 
    "end": "2017-08-09 20:29:09.802963", 
    "failed": true, 
    "item": "node04.internal.aws.testdrive.openshift.com", 
    "rc": 1, 
    "start": "2017-08-09 20:29:09.581181"
}

STDERR:

Error from server (NotFound): nodes "node04.internal.aws.testdrive.openshift.com" not found

Host names in Lab module 1 are generic and hard-coded. The lab guide should state the correct internal hostnames of the respective instances.

@kmurudi

`TASK [Checking if all the groups have been created by 'oc adm groups sync'] *********************************************
Tuesday 25 July 2017 11:13:28 -0400 (0:00:00.547) 0:00:00.637 **********
failed: [master.unset.ocp-admin.aws.openshifttestdrive.com] (item=ose-users) => {
"changed": true,
"cmd": [
"oc",
"get",
"group",
"ose-users"
],
"delta": "0:00:00.201054",
"end": "2017-07-25 11:13:29.162421",
"failed": true,
"item": "ose-users",
"rc": 1,
"start": "2017-07-25 11:13:28.961367"
}

STDERR:

Error from server (NotFound): groups "ose-users" not found`

Happens after successful execution of ldap_automation.yml

more information will be needed to determine which volume is the correct postgresql volume in the Explore the Underlying CNS Artifacts section. The command outputs will also need to be updated.

The current test relies on the output of "oc version" being a guaranteed api:

https://github.com/openshift/openshift-cns-testdrive/blob/master/tests/installation_verify.yml#L17

This should probably be two tests.

using this command to run installer-
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/byo/config.yml

always stops at the mentioned task and then have to stop and run the playbook again..gets deployed second time though.

groupsync.yaml gets generated at cloud-init stage but has the LDAP bindDN and baseDN hard as well as the idm URL hard-coded.

Best to deploy in generic form with placeholders and then replace it as part of a post-deploy playbooks that runs at cloud-init stage on the master. Similarly done with the LDAP urls in /etc/ansible/hosts and the inventory_ldap_auth.yml playbook.

https://github.com/openshift/openshift-cns-testdrive/blob/master/packer/roles/registry-mirror/vars/main.yml

We should add docker.io/siamaksade/mapit to the packer role for completeness.

Perhaps call it app-management

When doing lab automation and verification we need to have access to the environment specific variables. E.g. the device name of the CNS bricks, the default routing suffix for OCP, the name of the project that we create for CNS? Some of this info could be just hard-coded in the lab guide and the automation but we may want to externalize that for easy updates later.

For the lab guide we are writing this info into /etc/sysconfig/workshopper on the guide node. But tests will likely need to be running from the master node, to get /etc/ansible/hosts as a second source for info.

What is the best way to get environment-specific information?