sap-oc / crowbar-core Goto Github PK

we tried to preallocate an IP address with:

crowbarctl network hostip allocate PROPOSAL NODE NETWORK RANGE [SUGGESTION]

but it ignored our IP address "SUGGESTION" (IP was not used at all)

example:

crowbarctl network hostip allocate default d00-25-b5-42-50-01.cc-ap-cn-100.cloud.sap storage host 192.168.128.15
{
  "conduit": "intf1",
  "vlan": 412,
  "use_vlan": true,
  "add_bridge": false,
  "mtu": 1500,
  "subnet": "192.168.128.0",
  "netmask": "255.255.255.0",
  "broadcast": "192.168.128.255",
  "ranges": {
    "host": {
      "start": "192.168.128.4",
      "end": "192.168.128.126"
    }
  },
  "router": "192.168.128.1",
  "usage": "storage",
  "node": "d00-25-b5-42-50-01.cc-ap-cn-100.cloud.sap",
  "address": "192.168.128.4"
}

One user of this branch will require the following fixes:

• crowbar#1230
• crowbar#1231

Not doing the backport now as there are still comments to be addressed. But opening the issue to not forget.

hi. following problem: if one creates a proposal with crowbarctl proposal create $barclamp default, than the "deployment:config:environment" values is "$barclamp-base-config". if one creates the proposal via the web UI, the value is "$barclamp-config-default". with "$barclamp-base-config" the deployment of the proposal fails hard

the issue that you get difference json files if you use the crowbarctl cli vs web UI

root@crowbar:~ # crowbarctl backup upload kkk
{"error":"A required parameter is missing"}

In the logs:

I, [2017-07-11T08:29:14.308477 #7692:0x007f810d4048c8]  INFO -- Started POST "/utils/backups/upload" for 127.0.0.1 at 2017-07-11 08:29:14 +0000
I, [2017-07-11T08:29:14.309598 #7692:0x007f810d4048c8]  INFO -- Processing by BackupsController#upload as JSON
I, [2017-07-11T08:29:14.309718 #7692:0x007f810d4048c8]  INFO --   Parameters: {"backup"=>{"file"=>#<ActionDispatch::Http::UploadedFile:0x007f810dc60a30 @tempfile=#<Tempfile:/opt/dell/crowbar_framework/tmp/RackMultipart20170711-7692-1kle4ph>, @original_filename="kkk", @content_type="text/plain", @headers="Content-Disposition: form-data; name=\"backup[file]\"; filename=\"kkk\"\r\nContent-Type: text/plain\r\n">}}
W, [2017-07-11T08:29:14.310127 #7692:0x007f810d4048c8]  WARN -- param is missing or the value is empty: payload
I, [2017-07-11T08:29:14.310572 #7692:0x007f810d4048c8]  INFO -- Completed 406 Not Acceptable in 1ms (Views: 0.1ms | ActiveRecord: 0.0ms)

Right now, only the current domain is allowed, and it may be convienient to allow more domains to be searched.

Right now, only custom A records are allowed.

Fix in stable/3.0 branch at crowbar#993

This creates some confusion, and can also lead to errors (when not using the webui when applying a proposal, since only the webui will remove the node automatically).

The Pull request that fixes this issue is here: #36

• tested
• reviewed by SUSE
• reviewed by SAP

A great example is nova: when the proposal is not changed, but only new nodes are added, it makes no sense to reconfigure the controllers.

@vuntz had a patch specifically for nova (todo: find the link), but it needs to be made more generic.

We see this:

[2017-05-04T15:38:39+00:00] INFO: HTTP Request Returned 500 Internal Server Error: end of file reached
[2017-05-04T15:38:39+00:00] ERROR: Running exception handlers
[2017-05-04T15:38:40+00:00] FATAL: Saving node information to /var/chef/cache/failed-run-data.json
[2017-05-04T15:38:40+00:00] ERROR: Exception handlers complete
[2017-05-04T15:38:40+00:00] ERROR: Net::HTTPFatalError: 500 "Internal Server Error"
[2017-05-04T15:38:40+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2017-05-04T15:38:40+00:00] ERROR: Sleeping for 10800 seconds before trying again

There's an issue for 5 days due to the couchdb database being too big, and it got only noticed now. There should be some monitoring for chef errors that may indicate something really bad. Doing it only on the admin server would be good enough.

It's important to know what batches have been applied, and in each batch, what nodes have been successfully configured.

This could be in a separate log file as a first step.

When rebooting network nodes, they come up without network connection.

The problem: Start of wickedd depends on a running openvswitch. openvswitch needs bond0 to start. But bond0 is being created by wickedd. No bond0 = no openvswitch = no wickedd = no bond0.

The Pull request that fixes this issue is here: #27

• tested
• reviewed by SUSE
• reviewed by SAP

There are some DNS barclamp attributes, that only require changes on the DNS server nodes, not on the DNS clients, e.g. the forwarders.
When applying the DNS proposal it should determine, if it is enough to only run chef on the DNS servers or if really all nodes need to be touched, which takes a huge amount of time.

DHCP is not working between Cassandra node and Admin node. Cassandra requests a DHCP offer from the admin node, but the admin node ignores the request. See attached pcap file.
dhcp-bootp.pcap.zip

When applying, chef reconfigures everything. For instance, when applying nova, the glance config is also converged.

This is not needed, slows down everything and may have side effects.

We forgot nodes, that were in state 'Discovered' and they were still in the network proposal, which prevents us loading the proposal from file, without removing them one by one, reported from the error log.

The issue with convergence is that this makes chef change things on a running system, with potential sideeffects that may result in outages.

So we should instead ensure that we do not depend on chef running to get the config right (on boot for instance) and that one "apply" is enough to get the full config correct.

We use http; main challenge is all the automated provisioning when certificates are not signed by a known authority.

We need a warning before someone applies the updater proposal.