Ubuntu Pastebin

Paste from beisner at Mon, 7 Mar 2016 14:28:20 +0000

Download as text
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
====>  Gerrit git fetch refspec  <=======================
BASE_NAME: keystone
CO_DIR: /var/lib/jenkins/checkout/keystone
 - Removing existing checkout @ /var/lib/jenkins/checkout/keystone
 + Cloning https://review.openstack.org/openstack/charm-keystone --> /var/lib/jenkins/checkout/keystone
Cloning into '/var/lib/jenkins/checkout/keystone'...
 + Fetching refs/changes/29/289229/2
From https://review.openstack.org/openstack/charm-keystone
 * branch            refs/changes/29/289229/2 -> FETCH_HEAD
 + Checking out FETCH_HEAD
 . git branch:
* (detached from FETCH_HEAD) 0b58651 Enable Keystone v3 API
  master                     cd22777 Enable Xenial-Mitaka amulet test target.
  remotes/origin/HEAD        -> origin/master
  remotes/origin/master      cd22777 Enable Xenial-Mitaka amulet test target.
 . git reflog:
0b58651 HEAD@{0}: checkout: moving from master to FETCH_HEAD
cd22777 HEAD@{1}: clone: from https://review.openstack.org/openstack/charm-keystone
 . git log:
commit 0b5865112d6498f4c1f915777fbd88867c50f507
Author: Liam Young <liam.young@canonical.com>
Date:   Mon Mar 7 09:10:53 2016 +0000

    Enable Keystone v3 API
    
    This changes enables the Keystone v3 api. It can be toggled on and off via the
    preferred-api-version option.
    
    When services join the identity-service relation they will be presented with a
    new parameter api_version which is the maximum api version the keystone charm
    supports and matches what was set via preferred-api-version.
    
    If preferred-api-version is set to 3 then the charm will render a new
    policy.json which adds support for domains etc when keystone is checking
    authorisation. The new policy.json requires an admin domain to be created and
    specifies that a user is classed as an admin of the whole cloud if they have
    the admin role against that admin domain.
    
    The admin domain, called admin_domain, is created by the charm. The name of
    this domain is currently not user configurable. The role that enables a user to
    be classed as an admin is specified by the old charm option admin-role. The
    charm grants admin-role to the admin-user against the admin_domain.
    
    Switching a deployed cloud from preferred-api-version 2 to
    preferred-api-version 3 is supported. Switching from preferred-api-version 3 to
    preferred-api-version 2 should work from the charm point of view but may cause
    problems if there are duplicate users between domains or may have unintended
    consequences like escalating the privilege of some users so is not recommended.
    
    Change-Id: I8eec2a90e0acbf56ee72cb5036a0a21f4a77a2c3

commit ca9592f3c46a8dc2598d51cbd9a094f2b650c392
Author: James Page <james.page@ubuntu.com>
Date:   Wed Mar 2 11:04:09 2016 +0000

    Resync charm-helpers
    
    Change-Id: I4273d65d255553fda0cd4bb6ed0d643539755735
 . git tags:
error: RPC failed; result=56, HTTP code = 0
fatal: The remote end hung up unexpectedly
Build step 'Execute shell' marked build as failure
Archiving artifacts
Finished: FAILURE
Download as text