| 2011-06-01 14:54:32 |
Gustavo Niemeyer |
description |
Also discussed in the futures of the upgrade-formula hook spec, also came up on irc today.
<SpamapS> hazmat: well that makes perfect sense. in the upgrade hook I can enumerate and do sets right?
<hazmat> SpamapS, not yet
<SpamapS> ok.. because that would be useful
<hazmat> the only real functionality that the upgrade hook offers atm that's different than normal hooks is that its executed first out of the new formula.
<SpamapS> but no, services should be resilient to transience of their related partners..
* zaid_h (~zaid@64.34.151.178) has joined #ubuntu-ensemble
<hazmat> SpamapS, yeah.. i did some discussion of that in the futures section of the upgrade-formula doc
<hazmat> re enumerate and set
<SpamapS> hazmat: its kind of a corner case really
<hazmat> SpamapS, the real issue with it at the moment, is that looks we're tending towards some anonymous relations
<hazmat> SpamapS, i definitely think its realistic
<hazmat> maybe a corner, but for advanced upgrading usage, its a pretty important piece.
<hazmat> by tending to anon relations, i mean the mysql formula for example, can have multiple relations with clients named 'db'..
<SpamapS> The one I worry about is the new config file that needs to be generated.. need to enumerate and basically rejoin every relation.
<hazmat> the identity of those multiple instances of the same name is a question..
<SpamapS> hazmat: sorry I've gone cross eyed again. huh?
<hazmat> at the moment with another command targeting unit relations, i'm treating them as a set, but if we expose to hooks, they have to have some names
<hazmat> SpamapS, say we have two wordpress blogs/services, and they both connect to mysql
<hazmat> now mysql has two relations instances, but they have the same name.
<SpamapS> two services w/ the same name?
<hazmat> SpamapS, two relations with the same name
<SpamapS> so the services are 'blog0' and 'blog1' .. .right?
<hazmat> SpamapS, sure
<SpamapS> mysql has seen them as such and there are two databases?
<hazmat> perhaps we should encode the remote service name in user visible portion of the relation to add a qualifier for enumeration
<hazmat> ^of the relation name
<SpamapS> its sort of the natural order of things
<hazmat> niemeyer, ^ re anon relation addressing
<SpamapS> service_name+relation_name == unique relation id
<hazmat> SpamapS, yeah.. that sounds good to me
<niemeyer> hazmat: ECONTEXT
<niemeyer> hazmat: Let me read back
<SpamapS> hazmat: given that one would be able to enumerate their established relations and have something that can be used to pass to tools to say "relation-list blog0-db" ?
<hazmat> SpamapS, yeah.. probably as RELATION_NAME=blog0-db relation-list
<SpamapS> actually blog0:db would imply it is the :db on blog0's side.. but its really the db on mysql's side isn't it?
<hazmat> yeah.. its the mysql side.
<SpamapS> Well I love the idea of being able to do that
<hazmat> we can reverse the order rel-name/service-name
<niemeyer> hazmat: Ok, in sync again
<niemeyer> hazmat: I don't think we should use the service name anywhere in a relation
<hazmat> niemeyer, even as a transient qualifier?
<hazmat> transient id
<niemeyer> hazmat: It enables people to build custom-logic based on the service name, which is a big killer for the formula concept
<hazmat> hmmm.. it does
<niemeyer> hazmat: We have unique ids for the relation already
<niemeyer> hazmat: The internal ids
<niemeyer> hazmat: They're not semantically meaningful, but that's exactly the idea.. they shouldn't be
<hazmat> niemeyer, are you suggesting we expose them to hooks for the purpose of iteration/transient ids?
<hazmat> niemeyer, cool
<niemeyer> hazmat: Yeah, I think it'd be fine to have, e.g. db-424
<niemeyer> hazmat: Just to enable people to iterate over multiple relations in an upgrade hook or similar
<hazmat> niemeyer, yup.. sounds good.
<SpamapS> Yeah it doesn't matter what the id is, just that a formula can be aware of them on upgrade so that they can list/get all the data out of them. |
Update: Bug #791370 is about having individual relation ids accessible to hooks, and should be handled before this one tackles the iteration aspect.
Also discussed in the futures of the upgrade-formula hook spec, also came up on irc today.
<SpamapS> hazmat: well that makes perfect sense. in the upgrade hook I can enumerate and do sets right?
<hazmat> SpamapS, not yet
<SpamapS> ok.. because that would be useful
<hazmat> the only real functionality that the upgrade hook offers atm that's different than normal hooks is that its executed first out of the new formula.
<SpamapS> but no, services should be resilient to transience of their related partners..
* zaid_h (~zaid@64.34.151.178) has joined #ubuntu-ensemble
<hazmat> SpamapS, yeah.. i did some discussion of that in the futures section of the upgrade-formula doc
<hazmat> re enumerate and set
<SpamapS> hazmat: its kind of a corner case really
<hazmat> SpamapS, the real issue with it at the moment, is that looks we're tending towards some anonymous relations
<hazmat> SpamapS, i definitely think its realistic
<hazmat> maybe a corner, but for advanced upgrading usage, its a pretty important piece.
<hazmat> by tending to anon relations, i mean the mysql formula for example, can have multiple relations with clients named 'db'..
<SpamapS> The one I worry about is the new config file that needs to be generated.. need to enumerate and basically rejoin every relation.
<hazmat> the identity of those multiple instances of the same name is a question..
<SpamapS> hazmat: sorry I've gone cross eyed again. huh?
<hazmat> at the moment with another command targeting unit relations, i'm treating them as a set, but if we expose to hooks, they have to have some names
<hazmat> SpamapS, say we have two wordpress blogs/services, and they both connect to mysql
<hazmat> now mysql has two relations instances, but they have the same name.
<SpamapS> two services w/ the same name?
<hazmat> SpamapS, two relations with the same name
<SpamapS> so the services are 'blog0' and 'blog1' .. .right?
<hazmat> SpamapS, sure
<SpamapS> mysql has seen them as such and there are two databases?
<hazmat> perhaps we should encode the remote service name in user visible portion of the relation to add a qualifier for enumeration
<hazmat> ^of the relation name
<SpamapS> its sort of the natural order of things
<hazmat> niemeyer, ^ re anon relation addressing
<SpamapS> service_name+relation_name == unique relation id
<hazmat> SpamapS, yeah.. that sounds good to me
<niemeyer> hazmat: ECONTEXT
<niemeyer> hazmat: Let me read back
<SpamapS> hazmat: given that one would be able to enumerate their established relations and have something that can be used to pass to tools to say "relation-list blog0-db" ?
<hazmat> SpamapS, yeah.. probably as RELATION_NAME=blog0-db relation-list
<SpamapS> actually blog0:db would imply it is the :db on blog0's side.. but its really the db on mysql's side isn't it?
<hazmat> yeah.. its the mysql side.
<SpamapS> Well I love the idea of being able to do that
<hazmat> we can reverse the order rel-name/service-name
<niemeyer> hazmat: Ok, in sync again
<niemeyer> hazmat: I don't think we should use the service name anywhere in a relation
<hazmat> niemeyer, even as a transient qualifier?
<hazmat> transient id
<niemeyer> hazmat: It enables people to build custom-logic based on the service name, which is a big killer for the formula concept
<hazmat> hmmm.. it does
<niemeyer> hazmat: We have unique ids for the relation already
<niemeyer> hazmat: The internal ids
<niemeyer> hazmat: They're not semantically meaningful, but that's exactly the idea.. they shouldn't be
<hazmat> niemeyer, are you suggesting we expose them to hooks for the purpose of iteration/transient ids?
<hazmat> niemeyer, cool
<niemeyer> hazmat: Yeah, I think it'd be fine to have, e.g. db-424
<niemeyer> hazmat: Just to enable people to iterate over multiple relations in an upgrade hook or similar
<hazmat> niemeyer, yup.. sounds good.
<SpamapS> Yeah it doesn't matter what the id is, just that a formula can be aware of them on upgrade so that they can list/get all the data out of them. |
|
