Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

propagate host's AZ to containers #7795

Merged
merged 3 commits into from
Sep 4, 2017
Merged

propagate host's AZ to containers #7795

merged 3 commits into from
Sep 4, 2017

Conversation

dshcherb
Copy link

Description of change

pad.lv/1684325

Currently a provider-specific AZ is not propagated to containers
deployed on any provider - during container creation an empty
HardwareCharacteristics struct is initialized by a container manager.

It is important for certain applications to have this value exposed as
an environment variable in a hook context so that they can be
configured to be aware of physical placement with respect to failure
domains.

Given that provisioner has an ability to query machine state via
an apiserver facade, it is possible to get an availability zone for a
machine with a given tag. For that a new API call is introduced to query
that information.

QA steps

http://paste.ubuntu.com/25411705/

Documentation changes

Creates a new facade call AvailabilityZone which allows to query that field from hardware characteristics stored in state for a machine identified by a given tag.

Bug reference

https://bugs.launchpad.net/juju/+bug/1684325
https://bugs.launchpad.net/charm-ceph-osd/+bug/1684330

Copy link
Contributor

@howbazaar howbazaar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally OK, but tests needed.

@@ -197,7 +197,7 @@ func AllFacades() *facade.Registry {
)

reg("Pinger", 1, NewPinger)
reg("Provisioner", 3, provisioner.NewProvisionerAPI)
reg("Provisioner", 4, provisioner.NewProvisionerAPI)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need to keep version 3 around as well.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still use the same type as the change is additive so no new facade type is needed AFAIU.

I will add two entries as follows to have both of them in the facade registry:

reg("Provisioner", 3, provisioner.NewProvisionerAPI)
reg("Provisioner", 4, provisioner.NewProvisionerAPI)

}
machine, err := p.getMachine(canAccess, tag)
if err == nil {
hc, err := machine.HardwareCharacteristics()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This creates a new err which won't be written into the Result below if it is != nil

Copy link
Author

@dshcherb dshcherb Aug 31, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -348,6 +348,37 @@ func (p *ProvisionerAPI) Series(args params.Entities) (params.StringResults, err
return result, nil
}

// AvailabilityZone returns a provider-specific availability zone for each given machine entity
func (p *ProvisionerAPI) AvailabilityZone(args params.Entities) (params.StringResults, error) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs a test.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -227,6 +227,27 @@ func (m *Machine) Series() (string, error) {
return result.Result, nil
}

// AvailabilityZone returns an underlying provider's availability zone
// for a machine
func (m *Machine) AvailabilityZone() (string, error) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs a test.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dshcherb
Copy link
Author

Added tests for api client and apiserver sides, plus a feature test with container creation.

Currently trying to figure out a failure in worker/provisioner/container_initialisation_test.go which was not changed in any of the above commits:

go test -test.timeout=1500s github.com/juju/juju/worker/provisioner
...
[LOG] 0:01.010 WARNING juju.provisioner not stopping machine agent container watcher due to error: initialising container infrastructure on host machine: instance data for machine 1 not found [LOG] 0:01.010 ERROR juju.provisioner starting container provisioner for lxd: initialising container infrastructure on host machine: instance data for machine 1 not found container_initialisation_test.go:377: c.Assert(err, gc.ErrorMatches, ".*failed to acquire initialization lock:.*") ... error string = "initialising container infrastructure on host machine: instance data for machine 1 not found" ... regex string = ".*failed to acquire initialization lock:.*"
http://paste.ubuntu.com/25434511/
http://paste.ubuntu.com/25434529/

It looks like the behavior has changed slightly and we are now getting a different error message "instance data for machine not found" instead of ".failed to acquire initialization lock:.".

To me it makes sense as the following step was added that errors out if there is no instance data for machine 1: 601202b#diff-87adff371122a7eaa0e08277c9d11033R266

I suggest we just change the test name and regex.

Dmitrii Shcherbakov added 3 commits August 31, 2017 14:39
pad.lv/1684325

Currently a provider-specific AZ is not propagated to containers
deployed on any provider - during container creation an empty
HardwareCharacteristics struct is initialized by a container manager.

It is important for certain applications to have this value exposed as
an environment variable in the hook context so that they can be
configured to be aware of physical placement with respect to failure
domains.

Given that provisioner has an ability to query machine state via
an apiserver facade, it is possible to get an availability zone for a
machine with a given tag. For that a new API call is introduced to query
that information.
agent and apiserver side tests + a test for availability zone retrieval
and a container AZ test
Given that there is an additional step to retrieve host hardware
characteristics we error out earlier than before and do not receive the
same error message.

For this reason the expected result was changed and the test was
renamed.
@dshcherb
Copy link
Author

!!build!!

@dshcherb
Copy link
Author

http://ci.jujucharms.com/blue/organizations/jenkins/github-check-merge-juju-pl/detail/PR-7795/7/pipeline#step-49-log-1552
FAIL github.com/juju/juju/worker/firewaller 43.618s

Unable to reproduce it locally:

➜  juju git:(develop) ✗ go test -test.timeout=1500s github.com/juju/juju/worker/firewaller
ok  	github.com/juju/juju/worker/firewaller	54.471s

I will retry it one more time.

@dshcherb
Copy link
Author

!!build!!

@dshcherb
Copy link
Author

dshcherb commented Sep 4, 2017

$$merge$$

@dshcherb
Copy link
Author

dshcherb commented Sep 4, 2017

Don't have write access to merge apparently - need somebody else to merge this and #7795

@wupeka
Copy link

wupeka commented Sep 4, 2017

$$merge$$

@jujubot
Copy link
Collaborator

jujubot commented Sep 4, 2017

Status: merge request accepted. Url: http://ci.jujucharms.com/job/github-merge-juju

@jujubot jujubot merged commit 83bde5c into juju:develop Sep 4, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants