cf-charmers team mailing list archive
-
cf-charmers team
-
Mailing list archive
-
Message #00565
Re: [Merge] lp:~johnsca/charms/trusty/cloudfoundry/trunk-webadmin into lp:~cf-charmers/charms/trusty/cloudfoundry/trunk
Ben, see inline replies.
Diff comments:
> === modified file 'cloudfoundry/contexts.py'
> --- cloudfoundry/contexts.py 2014-10-27 19:48:56 +0000
> +++ cloudfoundry/contexts.py 2014-10-29 18:29:23 +0000
> @@ -1,5 +1,6 @@
> import os
> import yaml
> +import time
>
> from charmhelpers.core import host
> from charmhelpers.core import hookenv
> @@ -31,6 +32,12 @@
> rid=rid, unit=unit))
> return list(units)
>
> + def get_first(self, key):
> + return self[self.name][0][key]
> +
> + def get_all(self, key):
> + return [u[key] for u in self[self.name]]
> +
>
> class StoredContext(dict):
> """
> @@ -114,7 +121,7 @@
>
> class UAARelation(RelationContext):
> name = 'uaa'
> - interface = 'http'
> + interface = 'uaa'
> required_keys = ['login_client_secret', 'admin_client_secret', 'cc_client_secret', 'cc_token_secret',
> 'service_broker_client_secret', 'servicesmgmt_client_secret', 'port']
> port = 8081
> @@ -168,6 +175,19 @@
> }
>
>
> +class UAADBRelation(RelationContext):
> + name = 'uaa-db'
> + interface = 'uaa-db'
> + required_keys = MysqlRelation.required_keys
Yeah, it probably should be a subclass, and it should re-use the same interface, since the relation contract is the same.
> +
> + @classmethod
> + def send_data(cls, job_name):
> + # using send_data instead of provide_data to delay it until data_ready
> + data = MysqlRelation()['db'][0]
Actually, no, because it's specifically needing to get data from a different relation (the db / mysql relation) and proxy that data to this relation (uaa-db / uaa-db). Even if this is a subclass, this still needs to explicitly instantiate the MysqlRelation class. This would be *a lot* more clear if we had the global execution_environment-type interface that we were discussing yesterday.
> + for rid in hookenv.relation_ids(cls.name):
> + hookenv.relation_set(rid, data)
> +
> +
> class LoginRelation(RelationContext):
> name = 'login'
> interface = 'http'
> @@ -370,6 +390,7 @@
> @classmethod
> def send_data(cls, job_name):
> # using send_data instead of provide_data to delay it until data_ready
> + time.sleep(120) # hack to ensure migrations are done :(
Ah, I actually didn't notice that this was in here. This isn't actually related to the web admin ui, it was just necessary on the reconciler branch due to differences in timing. Though, it just as well might be nothing but good luck that we've never seen this issue on trunk.
Regarding a better solution, I agree that there's got to be a better way of detecting this, and we definitely should see how it's handled in BOSH. I can't imagine it inspects the DB, and probably amounts to just issuing `monit restart all`s until everything reports as up, which is something we could do, I suppose.
> data = MysqlRelation()['db'][0]
> for rid in hookenv.relation_ids(cls.name):
> hookenv.relation_set(rid, data)
>
> === modified file 'cloudfoundry/services.py'
> --- cloudfoundry/services.py 2014-09-25 15:23:46 +0000
> +++ cloudfoundry/services.py 2014-10-29 18:29:23 +0000
> @@ -271,11 +271,14 @@
> 'jobs': [
> {'job_name': 'uaa',
> 'mapping': {'db': mapper.uaadb},
> - 'provided_data': [contexts.UAARelation],
> + 'provided_data': [contexts.UAARelation,
> + contexts.UAADBRelation],
> 'required_data': [contexts.MysqlRelation,
> contexts.NatsRelation,
> - contexts.UAARelation.remote_view]
> - }
> + contexts.UAARelation.remote_view],
> + 'data_ready': [
> + contexts.UAADBRelation.send_data,
> + ]},
> ]
> },
>
>
--
https://code.launchpad.net/~johnsca/charms/trusty/cloudfoundry/trunk-webadmin/+merge/240033
Your team Cloud Foundry Charmers is subscribed to branch lp:~cf-charmers/charms/trusty/cloudfoundry/trunk.
References