#juju-dev 2012-07-09
<Aram> morning.
<rog> fwereade: mornin'!
<rog> fwereade: ping
<fwereade> rog, heyhey!
<fwereade> rog, nice holiday?
<rog> fwereade: lovely, thanks, although the weather... left something to be desired
<rog> fwereade: i'd forgotten just how lovely and wild cornwall actually is
<fwereade> rog, ha, yes, I have been hearing such reports
<fwereade> rog, lovely
<rog> fwereade: we had no problem finding places to park up "al fresco"
<rog> fwereade: i'm a bit sad though 'cos i managed to splash sea water on my phone on the last day and it's died
<rog> fwereade: losing some nice photos with it
<fwereade> rog, aw, bad luck :(
<rog> fwereade: and probably other stuff too that i haven't thought about. not to mention 300 quid's worth of phone :-(
<rog> fwereade: annoying thing is that all the stuff's probably still in there ok, i just can't get at it!
<fwereade> rog, quite so :(
<rog> fwereade: anyway, i was looking at environs/config
<fwereade> rog, well, I guess once it's dead you can take it to bits ;p
<fwereade> rog, ah, yes
<rog> fwereade: true, but i'll probably just find a flash chip - not easy to hook it up to anything
<rog> fwereade: there was a reason why parsing was separate from opening
<rog> fwereade: (gustavo seems keen to remove the distinction)
<fwereade> rog, cool, go on?
<fwereade> rog, wait I don't think that's what he wants
<rog> fwereade: no?
<fwereade> rog, getting a Config is still separate from getting an Environ and I expect it to remain so
<rog> fwereade: it looks to me like he wanted validaton to take place at Open time
<rog> "
<rog> The translation onto a struct type, though, and the further validation
<rog> of the configuration itself should still be done in the same style
<rog> done today, except inside EnvironProvider.Open.
<rog> "
<rog> fwereade: but perhaps i'm misunderstanding
<fwereade> rog, heh, perhaps I was too
<fwereade> rog, because I'm not sure what he means by "further" there
<rog> fwereade: i think he's suggesting that *all* the current validation take place in EnvironProvider.Open
<rog> fwereade: which means that if you have an environs config with several sections, each section will only be validated if you open it.
<rog> fwereade: i dunno, perhaps that's actually ok.
<fwereade> rog, I think that aspect particularly is in fact a win
<rog> fwereade: oh?
<fwereade> rog, I am still not 100% sold on the rest of it, but I am soldiering through and hoping all will become clear
<fwereade> rog, just because I have ballsed up the configuration of environment X I should not lose access to environment Y
<rog> fwereade: hmm, if that's what we want, then gustavo's comments make sense. although i'm not sure there's any need for a config type at all in that case.
<rog> fwereade: we can just use a map
<rog> fwereade: and i'm not sure when we'd ever use ValidateConfig
<fwereade> rog, ConfigSet.Get, env-set, secrets upload
<fwereade> rog, but, yes, I understand your reaction, the provider-internal struct types now seem pretty pointless
<rog> fwereade: could you expand on the above ( ConfigSet.Get, env-set, secrets upload)
<fwereade> rog, (and ValidateConfig does kinda assume that you can get a Config from an Environ in the first place)
<fwereade> rog, those are the times we want to change environment config
<fwereade> rog, but, well, I am not really in a position to give a robust defence of these choices
<rog> fwereade: we can easily change a config by setting elements in the map, i think.
<fwereade> rog, yeah, but those changes need to be validated somehow
<rog> fwereade: that's what EnvironProvider.SetConfig would do, no?
<rog> fwereade: ah, before we put the new config into the state?
<fwereade> rog, yeah, the idea is that the SetConfig is too late
<fwereade> rog, I dunno, this API does feel like it will be more awkward in some situations and less so in others
<fwereade> rog, I thought it was great having the EnvironConfig interface
<rog> fwereade: has any of the code for env-set or secrets upload already been written?
<fwereade> rog, not really
<fwereade> rog, I had the bulk of it written (and, I thought, quite nice), but...
<rog> fwereade: is the idea behind env-set that you can change any of the environ config settings live
<rog> ?
<fwereade> rog, some of them
<fwereade> rog, name, type, ec2 region etc must not change
<rog> fwereade: oh, and what's ConfigSet.Get ?
<fwereade> rog, ConfigSet is EnvironsConfig or whatever the environments.yaml-wrapper was called
<fwereade> rog, ie the point at which configs enter the system
<rog> fwereade: i see. i'm not sure how that relates to ValidateConfig though.
<fwereade> rog, ValidateConfig will be called as part of it (with nil for a first argument)
<rog> fwereade: hmm, i realise i don't understand how ValidateConfig is supposed to work
<fwereade> rog, I dunno, it really doesn't feel to me like it's been thought through properly, but I'm experiencing notable internal conflict between just-implement-what-was-asked-for and but-I-think-it-hasn't-been-thought-through-fully
<rog> fwereade: what's the "new" argument?
<fwereade> rog, it always validates new, and returns something based on it, with possible tweaks (ensure region is set; fix the authorized-keys-path malarkey)
<fwereade> rog, if old is not nil, it also checks need-to-be-immutable fields against old
<rog> ah
<fwereade> rog, it still doesn't feel quite like the right fit to me
 * rog looks through code
<TheMue> Morning btw
<fwereade> rog, but I do not in general have niemeyer's foresight, so I am trying to reserve judgment and follow the spirit of what he seeks
<rog> TheMue: yo!
<fwereade> rog, if you wish to take it up with him I will observe thediscussion with great interest, though
<fwereade> TheMue, heyhey
<TheMue> rog: The two weeks are already over?
<rog> fwereade: AFAICS your environs/config proposal didn't have equivalent functionality to ValidateConfig, or am i missing something?
 * TheMue thought it only has been one so far.
<rog> TheMue: yes, in the blink of an eye!
<fwereade> rog, no it didn't -- I was going to add a ValidateReplacement method to the EnvironConfig interface
<fwereade> rog, I felt that having providers only ever emit validated EnvironConfigs was a great feature
<fwereade> rog, now any bozo can create a *Config from whatever junk they have lying around in their scope
<Aram> morning rog.
<Aram> already back? :).
<rog> Aram: hiya
<fwereade> rog, hopefully it will be apparent enough that this is not actually a very helpful thing to do
<rog> fwereade: with niemeyer's proposal, i really don't see what advantage the config type has over just using a map.
<fwereade> rog, but it seems reasonably sane to have SetConfig call ValidateConfig under the covers anyway so we shouldn't e able to screw it up too badly
<fwereade> rog, I am not the right person to give helpful insight into the advantages of niemeyer's proposal
<fwereade> rog, perhaps it will suddenly click with me
<rog> fwereade: hmm, it does seem a bit like churn for the sake of it
<fwereade> rog, but it doesn't feel to me like the simplest or most expedient way to go about it
<fwereade> rog, well, what I *originally* wanted to was to have State.EnvironConfig and associated methods return and use actual EnvironConfigs
<fwereade> rog, and it's perfectly easy to do this, and to have real instances which I know for sure are valid, in every possible circumstance, bcause they're backed by a real struct type that can only be created by code inside that specific environ
<rog> fwereade: currently, there's no way of turning an EnvironConfig back into a map, i think.
<rog> fwereade: wouldn't that be a disadvantage of the above?
<fwereade> rog, yeah, but we need that one way or another and it's trivial
<fwereade> rog, the EnvironConfig itself can be responsible for producing a map that will unpack back to an identical instance
<rog> fwereade: it's just one more thing to get consistent (every time you add an environ field, you have to add code to go in the opposite direction)
<rog> fwereade: in gustavo's proposal, the translation is always one way, and i think that could work ok.
<rog> fwereade: network probs?
<fwereade> rog, apparently so
<fwereade> rog, did I miss anything?
<rog> fwereade: last two things i said:
<rog> [08:59:29] <rog> fwereade: it's just one more thing to get consistent (every time you add an environ field, you have to add code to go in the opposite direction)
<rog> [09:00:09] <rog> fwereade: in gustavo's proposal, the translation is always one way, and i think that could work ok.
<rog> fwereade: last thing i saw from you: [08:59:23] <fwereade> rog, the EnvironConfig itself can be responsible for producing a map that will unpack back to an identical instance
<fwereade> rog, ha, our timelines are somewhat divergent
<fwereade> <fwereade> rog, yeah, but we need that one way or another and it's trivial
<fwereade>  rog, the EnvironConfig itself can be responsible for producing a map that will unpack back to an identical instance
<fwereade> <fwereade> rog, don't we have to do that regardless?
<fwereade>  rog, they're stored in /environment as maps, so we have to have some way to turn a config into a map, like it or now
<fwereade> rog, I think it would be a really good thing if each env's idiosyncratic config-handling code were isolated behind a Config interface
<fwereade> rog, it seems to me that different static types for configs with very different behaviour is a good thing because we don't have to smoosh the config-handling code across various bits of the relevant Environ and EnvironProvider types
<fwereade> rog, as it is the only opportunity we have to turn it into a struct type is at SetConfig time, at which point its usefulness as a struct seems to me to be somewhat limited
 * fwereade at this point looked at the code again and remembered something else, and went off along a new train of thought
<fwereade> rog, and now I'm not sure what to do about environments without secrets
<fwereade> rog, offhand it seems to me that an environ without secrets is not intrinsically an invalid thing
<fwereade>  rog, ie you don't need to have secrets locally if the env already has them
<fwereade> rog, but maybe that's a case we don't care about
<fwereade> rog, hmm, do we have any rational basis for expecting the control-bucket to be public?
<rog> fwereade: do we expect it to be public?
<fwereade> rog, I didn't think so
<fwereade> rog, so that then means we *do* need auth to even get a StateInfo out of an environ
<fwereade> rog, and an Environ is not actually valid or useful in any way without its secrets
<fwereade> rog, this is inconvenient wrt possible future needs (let someone manipulate your env without giving them your AWS keys? can't be done)
<rog> fwereade: agreed.
<fwereade> rog, but maybe I should just not worry about that at the moment
<fwereade> rog, however this breaks my mental model a little
<rog> fwereade: there's no particular reason that it must be the *same* secret, i suppose
<fwereade> rog, I had been thinking the right thing to do was to allow an environ to exist without secrets, because I don't like the idea of an environ config delivered by the system that is not actually valid
<fwereade> rog, true, but that's still a bunch of stuff to manage
<rog> fwereade: when are we creating a partially valid environ?
<fwereade> rog, state.Initialize seems sensible
<fwereade> rog, IMO we should be pushing everything in the config that isn't a secret at bootstrap time
<rog> fwereade: why's that?
<fwereade> rog, consider default-series
<rog> fwereade: i have a suspicion that that might make several things more complex without much benefit, but please persuade me otherwise!
<rog> fwereade: go on
<fwereade> rog, if we start an env with a given default-series, and then change our environments config, it is IMO unhelpful to suddenly swap out the environment's default-series justbecause we're doing our first explicit deploy
<rog> fwereade: that's true of the environ secrets too.
<rog> fwereade: i think it might be more reasonable just to document that the environ config gets frozen at first deploy
<fwereade> rog, but  there is a purpose to that and it doesn't lead to apparent random inconsistencies assuming the keys are validin the same situations
<fwereade> rog, so, env-set shouldn;t work until we've deployed?
<rog> fwereade: then we don't need to have anything that distinguishes secret from non-secret
<rog> fwereade: hmm.
<rog> fwereade: actually, i think env-set should work, but it should freeze the environment first
<rog> fwereade: so we could say that the first command *after* bootstrap freezes the env
<fwereade> rog, ok, actually, that works nicely
<fwereade> rog, kinda :/
 * fwereade arranges thoughts
<fwereade> rog, default-series in particular seems to me to act oddly there
<fwereade> rog, as an example of an env setting that has a tanglible effect on the bootstrap machine
<rog> fwereade: because it affects which bootstrap machine is chosen?
<fwereade> rog, and that it seems somewhat surprising to overwrite that arbitrarily, givn that the expectation want to set up, AIUI, is that environments.yaml settings will not be pushed by random operations
<fwereade> rog, and that changes to environments.yaml will not in general have any effect on a running environment
<rog> fwereade: i think that it's ok to say that bootstrap is special, and that environments.yaml is frozen on the first command after bootstrsap
<rog> fwereade: and that's a reasonable and comprehensible model
<fwereade> rog, I would prefer not to encourage the idea that it's sane or meaningful to alter environments.yaml after bootstrap
<rog> fwereade: otherwise people might well say "why is default-series different from aws secret keys?"
<rog> fwereade: i agree, but we do have the reality that we *have* to push some of the environ config after bootstrap
<fwereade> rog, because the secrets are unique in that we need them to do *anything* with the env, even get the bootstrap machine's id from the storage
<fwereade> rog, valid secrets are a prerequisite ofr doing *anything*; and so, transparently pushing known-valid secrets when none already exist in state prevents users from having to actually think about it at all
<rog> fwereade: am i right in thinking there's only one secret key that we need to push?
<rog> fwereade: (for ec2, at any rate)
<fwereade> rog, I guess the access key id is not technically a secret
<rog> fwereade: yeah
<rog> fwereade: here's a possible (maybe crackful) thought
<rog> fwereade: outside of environs, we just use map[string]interface{}
<rog> fwereade: then
<rog> fwereade: we provide EnvironsProvider.ValidateConfig(old, new map[string]interface{}) error
<rog> fwereade: and we say that any key containing the string "secret" is secret
<rog> fwereade: so it's trivial for provider-agnostic logic to filter out secret keys
<rog> fwereade: of course, this assumes that other provider types use the string "secret" in their secret keys...
<fwereade> rog, I have had thoughts roughly along those lines
<fwereade> rog, not specifically including the secret stuff
 * fwereade reserves judgment
<rog> fwereade: if we go this way, then the environs/config package isn't required at all, i *think*
<rog> fwereade: oh no, it is
<rog> fwereade: to avoid the loop
<rog> fwereade: except...
<rog> fwereade: there's no need for state to call ValidateConfig
<rog> fwereade: so there's no need for a cyclic dependency.
<rog> fwereade: so no need for environs/config, i think.
<fwereade> rog, I think I may just be overly paranoid about people dumping random crap into /environments
<fwereade> rog, this is at the heart of my desire to have the state methods that manipulate environ configs work with actual environ configs
<rog> fwereade: we can still check that!
<fwereade> rog, but not within state
<rog> fwereade: state is internal
<rog> fwereade: we still have control over where the environ config gets into the system
<rog> fwereade: env-set
<rog> fwereade: environs.Open
<rog> etc
<rog> fwereade: and those places can do the checking
<fwereade> rog, so we have a bunch of state methods that validate what they're given, and one that pushes all responsibility for validation onto the various clients
<rog> fwereade: state methods validate what they can.
<rog> fwereade: we can state explicitly that the environment pushed into the state is not validated by the state
<rog> fwereade: that may even be a good thing actually
<fwereade> rog, ofc we can, doesn't stop it feeling sloppy to me
<fwereade> rog, we may as well say that state is internal and so there's no need to validate anything we put into it
<fwereade> rog, we can always trust the client code we write to do the right thing, after all
<rog> fwereade: it's a trade-off - i *think* that it's not worth creating a new package for
 * fwereade maintains a studiously straight face
<rog> fwereade: there are lots of ways we can create invalid content inside state, i thinl
<rog> s/thinl/think/
<fwereade> rog, like what?
<rog> fwereade: like we could do OpenPort("tpc", 45)
<fwereade> rog, instructive example
 * fwereade ponders
<fwereade> rog, I think the distinction there is that there is no global source of truth we can use to validate against the set of protocols we know about elsewhere in the system
<fwereade> rog, in the environment case we can do so, and it doesn't feel like much work to me
<fwereade> rog, but look, this is not an especially productive conversation because I keep falling back to describing my own perspective on the problem
<fwereade> rog, which is to all intents and purposes irrelevant because you the perspective that is most relevant is niemeyer's, and my internal niemeyer sim is not an outstanding predictor of the real niemeyer's thought
<rog> fwereade: it seems to me that there are several levels of verification we have on the state
<rog> :-)
<fwereade> rog, I think I do have to step back and sketch everything out again :)
<rog> fwereade: i'm looking at niemeyer's paste, and it seems to me that his environs/config is trivial
<rog> fwereade: and not really worth it
<rog> fwereade: each of the different methods on config.Config just return a particular field of the map
<fwereade> rog, look, yes, I am somewhat sympathetic to that point of view; if the prevailing opinion is that the content of /environment is a free-for-all and we can handle that then map[string]interface{} is perfectly sufficient
<fwereade> rog, however at the moment I am somewhat without compass and it has become apparent that I need to chart the differences between my perspective and niemeyer's in some detail so I can actually proceed usefully
<rog> fwereade: i'm sympathetic to this point of view of niemeyer's: "
<rog> There are very
<rog> few places through which configuration get into the system, and the
<rog> configuration should be validated right there.
<rog> "
<rog> fwereade: so the content of /environment is only a free-for-all if we treat it as such
<fwereade> rog, my concern is that if we can then at some stage we will
<rog> fwereade: and placing the validation outside of state means that everything else becomes simpler.
<rog> fwereade: (the fewer places with registered global state the better, i think)
<rog> fwereade: the idea behind State isn't, i think, that we design it such that it can express *exactly* the things we can do in juju, but that it's a nice convenient abstraction layer that expresses *at least* the things we can do in juju.
<rog> fwereade: when we start making things more complex so that we can get more verification in State, i think we're going a little too far.
<rog> fwereade: it's a convenience for our own use, and i don't think we need to be bound by it.
<fwereade> rog, I just don't see how requiring explicit validation outside of Config objects *actually* makes things simpler
<fwereade> rog, it just means we need to do lets of external messing about with maps and typecasting
<rog> fwereade: it means we don't need a new package with separate global registration
<fwereade> rog, if that's the only objection then that can be worked around
<rog> fwereade: really? i thought that was inherent to the cyclic-dependency-breaking nature of environs/config.
<fwereade> rog, oh wait, maybe not
<fwereade> rog, no, it means we need a provider to get a config and there's no way around it
<rog> fwereade: yup
<rog> fwereade: i'm not sure where you think all the messing around with maps and typecasting will go
<fwereade> rog, my perspective just clicked around a notch
<rog> :-)
<fwereade> rog, I can restrict the messing around to only the bits that are directly concerned with the struct type
<rog> fwereade: not sure i understand
<fwereade> rog, ok, this perspectives STM to assume that ValidateConfig will directly construct struct types from its *Config (or map) params
<fwereade> rog, will manipulate those as required
<fwereade> rog, and then return a fully validated one
<fwereade> rog, as a new *Config (or map)
<rog> fwereade: i don't think there's any need to return a validated config.
<rog> fwereade: is there?
<rog> fwereade: isn't the "new" argument supposed to be valid?
<fwereade> rog, how are we meant to know that?
<rog> fwereade: isn't that what ValidateConfig checks?
<fwereade> rog, yeah, a valid user-specified config may still require manipulation
<fwereade> rog, (1) region must never change at runtime, so we should bake in the value in case an update changes the default region
<rog> fwereade: that's why we pass in the old config, no?
<fwereade> rog, (2) authorized-keys-path should not exist on the server -- if it does it's evidence of total crazkfulness on our part
<fwereade> rog, and we should therefore remove it and sub in a correct authorized-keys setting
<rog> fwereade: how does the provider know that it's on a server or not?
<fwereade> rog, right! it shouldn't have to -- it shouldn't even see anything that could indicate a difference
<fwereade> rog, the actual configuration setting is authorized-keys -- authorized-keys-path is a convenient alternate way of setting it
<fwereade> rog, the environment should not have to care even slightly about what filesystem it happens to be running on, or even I guess whether it is ;)
<rog> hmm
<rog> fwereade: i see. what we get out of environments.yaml isn't what we put into the state.
<rog> yuck
<fwereade> rog, yeah, I have this total conviction that they are two distinct things and we could make our lives easier by distinguishing them in code
<fwereade> rog, but that has not received a lot of traction
<fwereade> rog, to tweak what you said: what we get out of environments.yaml isn't what fwereade personally thinks we put into the state.
<fwereade> rog, I guess we could just have the field and not bother to look at it when it might not be valid, but that seems pretty crackful itself
<fwereade> to me
<rog> fwereade: mutating authorized-keys-path makes sense.
<rog> fwereade: this *was* my idea for how ValidateConfig would work: http://paste.ubuntu.com/1082463/
<fwereade> rog, yeah, I think it needs a little more
<rog> fwereade: the problem with making client-side and server-side config two different things is that they are really very similar!
<fwereade> rog, sure
<rog> fwereade: hmm, against my previous inclination, perhaps we should just have Environ.Config to return a configuration map from an opened environ
<fwereade> rog, but if we had struct types we could just serialize/deserialize the struct types with yaml for storage, and *only* ever let valid struct types into the system, and only bother with the fancy stuff when loading a user config
<fwereade> rog, yeah, that feels to me like a sensible thing
<rog> fwereade: that means we'd need two versions of the deserializing code, which seems somewhat like overkill to me.
<rog> fwereade: also, we can't deserialize directly from a config code, i think.
<rog> s/code/node/
<fwereade> rog, one which just blats the yaml direct into a struct, and one that contains all the pre-validation and tweaking etc?
<fwereade> rog, oh? why not?
<fwereade> rog, I would imagine we could just blat it straight into a *whateverConfig
<rog> fwereade: because yaml.Unmarshal takes a []byte
<rog> fwereade: not a map[string]interface{}
<fwereade> rog, yes, this also depends on the separate global config registry so that we can have the configs directly responsible for what is stored
<fwereade> rog, which I know you don;t like
<rog> fwereade: the *only* reason that i made config parsing separate from config opening was so that a config file would get validated completely.
<rog> fwereade: and actually, that's still possible with ValidateConfig
<fwereade> rog, I don't actually see the benefit of refusing to work with env X because env Y is broken
<rog> fwereade: you may well be right. in which case i'm very happy to live without passing around configurations as structs.
<rog> fwereade: i'm happy to have state never call into environs
<fwereade> rog, yeah, I know :)
<rog> fwereade: it seems like a reasonable separation of concerns to me
<rog> fwereade: BTW does state actually need to know anything that goes on inside the environ config at all?
<rog> fwereade: for instance, does the state need to know that environ name, default series or type?
<fwereade> rog, only if we care about its validity -- and I still think we do/should but I think I have been pretty comprehensivelyoverruled on that one
<rog> s/that/the/
<fwereade> rog, certainly default-series
<rog> fwereade: of course we care about its validity...
<fwereade> rog, yes, but it has been argued that we can trust the clients
<rog> fwereade: they're our clients, so can we trust ourselves?
<fwereade> rog, and therefore at that specific point we merely assume validity, rather than worrying about it
<rog> fwereade: yea
<rog> h
<rog> fwereade: what does state use default-series for?
<fwereade> rog, IMO no, of course we can't trust ourselves ;p
<fwereade> rog, deploy command
<fwereade> rog, and the only sane place to get it is from state
<rog> fwereade: the deploy command isn't in state, is it?
<fwereade> rog, how is it going to get the default series *except* from state?
<rog> fwereade: i'm not suggesting that the default series isn't store inside state,
<rog> stored
<rog> fwereade: but that state has no reason to get default-series (or any environ config attribute) itself
<rog> fwereade: i.e. for the purposes of the state package, the environ config is opaque
<fwereade> rog, well there was talk of a state.DefaultSeries a while back but I think that would indeed want reevaluation in the light of the current direction
<fwereade> rog, it all comes down to how much we trust ourselves, and I have found that *not* trusting myself is frequently a winning strategy
<fwereade> rog, I am happy to follow the collective wisdom on this point but I have not successfully internalised the attitude that the decision follows from
<rog> fwereade: it's a trade-off as always IMHO. i've also found that keeping things as simple as possible is good.
<rog> fwereade: it's also a matter of how easy it is to verify the trust
<rog> fwereade: in this case, i think there are only a very few places that need verification.
<fwereade> rog, yeah, I know -- I'm just saying it's a tradeoff I would make differently, and that makes it harder because my complexity-predicting heuristics lead me in a different direction to that I am consciously aiming for
<rog> fwereade: here's a representation of my current thinking: http://paste.ubuntu.com/1082500/
<rog> fwereade: oops, EnvironConfig should have gone there
<fwereade> rog, was wondering about that
<fwereade> rog, not implausible, I'm just trying to think through the consequences of a slightly different shape
<rog> davecheney: hiya!
<Aram> what's the difference between Test and TestPackage in Gocheck?
<Aram> s/in/for/
<davecheney> rog: howdy mate
<davecheney> had a good holiday ?
<rog> davecheney: that i have
<rog> davecheney: just trying to get up to speed with all the stuff that's happened while i've been gone...
<rog> davecheney: how're the agents these days?
<rog> davecheney: did you manage to get that branch working?
<rog> Aram: i don't understand your question
<Aram> rog: the function used to integrated gocheck tests into gotest sometimes is named Test, sometimes TestPackage.
<Aram> any particular meaning to that?
<rog> Aram: it looks like Test is standard
<rog> Aram: but it doesn't matter too much
<Aram> ok.
<davecheney> rog: yup, it's waiting on final approval now
<rog> davecheney: yay!
<rog> davecheney: so the machine agent is actually starting new machines now?
<rog> davecheney: i mean the PA of course
<davecheney> rog: no
<davecheney> sadly not
<davecheney> we're still stuck at the 'who pushes the secrets' problem
<rog> davecheney: ah, of course.
<niemeyer> Gooood Mondays!
<Aram> hey hey
<rog> niemeyer: yo!
<niemeyer> rog: Welcome back!
<rog> niemeyer: i was discussing the newly proposed environs/config package with fwereade earlier
<rog> niemeyer: i think i'm broadly in agreement with your take on it
<niemeyer> rog: That's great.. I think we're all in agreement then, phew
<rog> niemeyer: i'm not sure that the actual package pulls its weight though
<niemeyer> rog: The package is needed for the state package to not have a dependency on environs
<rog> niemeyer: i was wondering about something like this: http://paste.ubuntu.com/1082729/
<rog> niemeyer: i'm not sure
<rog> niemeyer: i think the main reason for the dependency was so that state could call back into environs to verify the config
<rog> niemeyer: but your proposal does away with that
<rog> niemeyer: and hence, i *think*, the need for a new package
<niemeyer> rog: Yes, and state still wants to return a Config
<niemeyer> rog: Despite the fact it won't be validating
<rog> niemeyer: it could just return a map[string]interface{}
<niemeyer> rog: Yes, it could be less nice, but it can be nicer too
<rog> niemeyer: which can then be validated outside state
<niemeyer> rog: There's no need to validate what's coming out of state
<niemeyer> rog: It was validated when going in
<rog> niemeyer: oh yes, that's true
<rog> niemeyer: if we *do* have a config package, i also wondered if it was really worth hiding the map.
<rog> type Config map[string]interface{}
<rog> might be more transparent
<niemeyer> rog: I think it is, because we don't want code to be fiddling with the map in principle
<rog> niemeyer: ok, fair enough
<niemeyer> rog: Nor using stock methods (DefaultSeries) from the map
<rog> niemeyer: i don't mind m["default-series"].(string) too much
<rog> niemeyer: but i see your point too
<niemeyer> rog: I do mind, because it's just as easy to write m["default-seres"].(string)
<rog> niemeyer: presumably we'd also need config.New(attrs map[string]interface{}) (*Config, error) too?
<rog> niemeyer: with a config package, i might suggest something like this: http://paste.ubuntu.com/1082741/
<niemeyer> rog: Yeah, that sounds good
<niemeyer> rog: Yeah, that looks mostly ok.. the Validate method needs to return a new config, though, because the proposal is to have config being immutable for now
<rog> niemeyer: why does validate need to return a new config?
<rog> niemeyer: isn't the new config already valid?
<niemeyer> rog: The transition from -keys-path to -keys will be done there
<rog> niemeyer: i thought that could be done by Environ.Config
<niemeyer> rog: Doing SetConfig/Config so we can get a proper configuration is awkward.. validation sounds like the proper place to do it
<rog> niemeyer: it seems like Validate is doing more than just validation here.
<niemeyer>   Validate \Val"i*date\, v. t. [See {Valid}.]
<niemeyer>      To confirm; to render valid; to give legal force to.
<rog> niemeyer: and i'm not sure that we would ever need to do SetConfig then Config to get a valid configuration - wouldn't we always Open the environ first.
<rog> ?
<niemeyer> That's validation.
<niemeyer> rog: Not necessarily.. we can change the configuration without going through a re-open cycle
<rog> niemeyer: the "?" was to be added to the end of my sentence...
<niemeyer> rog: Sorry, ok, that's the answer htne :)
<rog> niemeyer: so Validate is the same as Open(old) followed by SetConfig(new) followed by Config?
<niemeyer> rog: No.. validate is definitely not the same as Open
<rog> niemeyer: i'm trying to get a handle on the different checks performed by Validate vs Open
<Aram> man, how annoying the misinformation on #go-nuts can be. "regexp needs an overhaul", "yes, it's very bad on the shootout", etc.
<rog> niemeyer: because, presumably Validate does some checks that are currently performed by Open, such as opening the ssh provider key
<niemeyer> rog: What does opening a key mean?
<niemeyer> Aram: Ouch
<rog> niemeyer: i mean opening the authorized-keys-path and reading it, so that it can transmute it into authorized-keys
<niemeyer> rog: Well, yes, I just mentioned that above
<niemeyer> rog: Another one is the validation of whether a region can change, for example, and the hardcoding of the region name
<niemeyer> rog: region: "" => region: "us-east-1"
<rog> niemeyer: something like this, perhaps? http://paste.ubuntu.com/1082778/
<niemeyer> rog: Yeah, except it should be called Validate as we've been agreeing on
<rog> oops, yeah
<rog> niemeyer: as for secrets, how about when the environment is initially uploaded, all keys containing the string "secret" are excised.
<rog> ?
<rog> niemeyer: alternatively...
<niemeyer> rog: That's a great idea, but it's unfortunately too late
<rog> niemeyer: we don't upload the environment at all until the first command after bootstrap.
<niemeyer> rog: Too late as in we have a configuration format right now that people are used to
<rog> niemeyer: are there secret keys in other providers that are called different things?
<rog> niemeyer: i guess so.
<rog> niemeyer: i should look at orchestra etc
<rog> niemeyer: another alternative: http://paste.ubuntu.com/1082789/
<niemeyer> rog: That doesn't seem like a good place to do this
<rog> niemeyer: where are you thinking is a good place?
<niemeyer> rog: We should look at the problems we have relative to secrets, and try to address those, but for now it sounds like we're good to go with the first change
<rog> niemeyer: sounds good
<niemeyer> rog: When you have a moment would you mind to file your flight details in the sprint page?
<niemeyer> rog: Otherwise you may miss a room :-)
<rog> niemeyer: ok, will do
<rog> niemeyer: hmm, i'm not allowed to view the page, it seems
<niemeyer> rog: You have to login
<rog> niemeyer: i was logged in. perhaps i was logged in as the wrong user... will try again. sadly my phone is dead, with all my login details with it :-(
<niemeyer> rog: Everyone in Canonical must necessarily have access to this wiki
<niemeyer> rog: I don't think you can have two users there even
<rog> niemeyer: ah, yes, i've now logged in. apparently i've got two valid logins.
<niemeyer> rog: I doubt it
<niemeyer> rog: This is associated to your Launchpad account, and it's tightly controlled
<rog> niemeyer: there was a mix up. i thought they'd sorted it out, but it seems not.
<rog> niemeyer: i've got two valid launchpad ids
<rog> niemeyer: but only one is associated with the right canonical perms
<niemeyer> rog: Well, apparently one of them doesn't work? :-)
<rog> niemeyer: it works for some things...
<niemeyer> rog: Sure, it can work for anything that is not the internal wiki :)
<rog> niemeyer: this was the post i got from someone in admin: https://pastebin.canonical.com/69677/
<rog> niemeyer: it probably not surprising i was confused
<rog> s/it/it's/
<niemeyer> rog: Indeed
<niemeyer> Sounds messed up
<rog> niemeyer: yeah. i'm not sure i really understand the underlying auth model.
<rog> niemeyer: done.
<niemeyer> rog: Cheers
<rog> TheMue: hey, seems like we're sharing flights!
<TheMue> *click*
<TheMue> rog: Nice, should try to get seats together.
<TheMue> niemeyer: How free are you for reviews today? With https://codereview.appspot.com/6345072/ in I would propose my firewall tomorrow for a first look. Right now I'm doing the tests, all service related ones are green, now I start with the machin related ones.
<niemeyer> TheMue: I was just about to ping you to talk about your eod email the other day and see how things are going
<niemeyer> TheMue: But I decided not to because lunch is waiting
<niemeyer> TheMue: I'm definitely available for reviews + talk on it
<niemeyer> TheMue: In ~1h
<TheMue> niemeyer: Fine, the watcher in the review above should be simple.
<niemeyer> TheMue: Super, let's catch up in a moment then
<niemeyer> bbs
<TheMue> ok
<rog> niemeyer: what was the name of that logging web service you mentioned a while back?
<niemeyer> rog: https://papertrailapp.com/
<rog> niemeyer: thanks. i'd been grepping the logs and googling "logging as a service" but failed to dig it up
<niemeyer> rog: No worries
<niemeyer> TheMue: Yo
<niemeyer> TheMue: ping?
 * rog is off for the day. i hope to get something more done than just catching up tomorrow!
<niemeyer> rog: Have a good one
<TheMue> niemeyer: pong
<niemeyer> TheMue: Hey
<niemeyer> TheMue: Going over your CL now.. do you want to catch up something around it?
<TheMue> niemeyer: No, it's only needed for the one containing the firewall. That one is almost done (some tests missing) and I would like to propose is tomorrow morning.
<niemeyer> TheMue: Super
<TheMue> niemeyer: I've needed some time to get behind it, but it's nice to see in the tests how it fits together.
<niemeyer> TheMue: Neat!
<niemeyer> TheMue: That's always a good sign
<niemeyer> TheMue: I thought the watcher tests had been moved to a nicer location (out of state_test.go) with fwereade_'s modification?
<TheMue> niemeyer: It has been watcher_test.go before. William moved them to the types where you retrieve them from. And This one is retrieved directly from State,
<niemeyer> TheMue: I see.. there's WatchMachines there indeed
<niemeyer> TheMue: Might be good to at least put them next to each other
<niemeyer> TheMue: Perhaps pulling WatchMachines down to the end
<TheMue> niemeyer: Geed idea.
<niemeyer> TheMue: The use of idx in the test is a bit awkward
<niemeyer> TheMue: Well.. I guess it's fine
<niemeyer> TheMue: Bothers me a little that it only works for a single change, but I guess it's ok
<niemeyer> TheMue: LGTM with doc suggestions only
<TheMue> niemeyer: Cheers
<TheMue> niemeyer: Will do it tomorrow, wife want's me now. ;)
<niemeyer> TheMue: Enjoy man
<TheMue> niemeyer: Thx, cu.
<niemeyer> TheMue: Cheers
<niemeyer> Will have a walk outside.. back later
<niemeyer> davecheney: Morning!
<davecheney> niemeyer: howdy
<davecheney> just on the phone
<niemeyer> davecheney: About // TODO(rogerpeppe) change upstart.Conf.Cmd to []string so that
<niemeyer> davecheney: This is going in with this CL, apparently?
<niemeyer> davecheney: Ah, you've based off of his branch
<davecheney> niemeyer: yes
<davecheney> that is somethign rog identified, i guess he is going to look at it
<davecheney> but I can do so if you like
<niemeyer> davecheney: Please just drop it.. that code is fine. THere's no quoting necessary for it to work correctly
<davecheney> understood
<niemeyer> davecheney: Actually, hold on
<niemeyer> davecheney: The %q there is bogus.. that's probably what it is referring to
<niemeyer> davecheney: I suggest using something simpler, such as "'%s'"
<niemeyer> davecheney: No address should contain single quotes in them, so this should be fine
<niemeyer> davecheney: It's also not something we're getting through user input, which might turn it into an issue
<niemeyer> davecheney: Sent a review on https://codereview.appspot.com/6347044
<davecheney> thanks, still on the phone
<davecheney> will check in a sec
<niemeyer> davecheney: Cheers.. there just a couple of minors from the previous where we seem to misunderstand each other. Otherwise we can move on
<davecheney> awesome, i'll review those now
<niemeyer> and a plain LGTM on the other one.. good stuff.
<davecheney> niemeyer: in related news, are you able to add mramm to the golang gophers
<davecheney> and also juju-dev on lp
<davecheney> i noticed he was missing from those groups ?
<niemeyer> davecheney: You mean ~juju?
<niemeyer> (there's no juju-dev, I think)
<davecheney> niemeyer: yes, i think I do, he should probably be in the same groups I am in so he can receive moar email
<niemeyer> Done adding to ~juju
<niemeyer> davecheney: Haha :)
<davecheney> niemeyer: just submitting my fix branch that fixes a bug on lp[
<davecheney> this will be interesting to see how the integration works
<niemeyer> davecheney: hm? bug in lp?
<niemeyer> Which lp?
<davecheney> no no, a bug that was registered to lp:goamz project
<davecheney> actually no, the bug is on juju-core
<davecheney> i have another branch for the goamz work
<davecheney> what i meant is this is the first time submitting a -bug via lbox
<davecheney> niemeyer: in related news, i had a quick go at using gocov on juju-core
<davecheney> it works, but is quite buggy
<davecheney> niemeyer: this was the goamz bug, https://bugs.launchpad.net/goamz/+bug/1021515
<niemeyer> davecheney: Ah, I see.. your first message got here corrupted (it said "lp[")
<niemeyer> davecheney: As one of the tasks for the sprint, I'd like to try to get the lifecycle logic correct in mstate, state, and the provisioning agent (which is our most complete agent to date)
<niemeyer> davecheney: making it consider alive/dying/dead semantics
<niemeyer> davecheney: Just something to boil up in your mind meanwhile
<davecheney> niemeyer: yes, i have been pondering on that since last week
<niemeyer> Phew.. review queue empty again
<davecheney> nice work
#juju-dev 2012-07-10
<davecheney> niemeyer: i'm sorry to say, but somehow you reviewde an old diff
<niemeyer> davecheney: Uh oh..
<niemeyer> davecheney: Let me check it again
<davecheney> niemeyer: two secs, i'll run the test and push the latest branch
<niemeyer> davecheney: Okay
<davecheney> niemeyer: done, https://codereview.appspot.com/6347044
<niemeyer> davecheney: I did not review an old version.. I replied to your comment, which means it sticks in the location where the first comment was made
<niemeyer> davecheney: I said "This should be in a test by itself", and then provided details of how to do so neatly. You mentioned "Done", and I said "Apparently not.", because the latest version didn't have a test by itself
<davecheney> niemeyer: ok, that was my mistake. but I am now very confused
<niemeyer> davecheney: What's up?
<davecheney> is there still an outstanding todo on that branch, or is it all resolved ?
<niemeyer> davecheney: The outstanding items IMO are in that last review I sent
<niemeyer> davecheney: We're clearly talking across each other, so I'm not sure about what's the status quo
<niemeyer> davecheney: The items I mentioned seem valid to me, and you didn't implement nor object to them
<davecheney> niemeyer: with the exception of someone repairing the environment when the RemoveMachine fails, I belive I have addressed everything else
<davecheney> please correct me if i am mistaken
<niemeyer> davecheney: <niemeyer> davecheney: I said "This should be in a test by itself", and then provided details of how to do so neatly. You mentioned "Done", and I said "Apparently not.", because the latest version didn't have a test by itself
<davecheney> niemeyer: ok, i understand now, i read that as 'this should be in _the_ test itself'
<davecheney> I will redo
<niemeyer> davecheney: As I mentioned there, this can use BootstrapOnce to avoid rebootstrapping
<wrtp> davecheney, fwereade_: mornin'
<fwereade_> wrtp, heyhey
<fwereade_> davecheney, if you're around, also heyhey
<davecheney> wazzup!
<davecheney> wrtp: thanks for your review
<davecheney> patchset 12 has tests that work
<wrtp> davecheney: np.
<davecheney> including a full mock using a PA running in process
<wrtp> davecheney: ah, cool.
<davecheney> I can repropose it as a followup CL
<wrtp> davecheney: but that went?
<davecheney> gustavo didn't like it
<davecheney> as it wasn't a real test
<davecheney> once this branch is merged i'll propose them again and we can discuss it some more
<wrtp> davecheney: hmm. seems pretty much like a real test to me. maybe there's something i missed.
<wrtp> davecheney: was that from gustavo's comment on line 23 here: https://codereview.appspot.com/6347044/diff2/1:5003/environs/ec2/suite_test.go?column_width=80 ?
<davecheney> wrtp: no, gustavo felt that testing against ec2 local test with a mocked PA didn't test anyhting
<davecheney> wrtp: it'll be easier for me to repropose after this branch is (finally) submitted
<wrtp> davecheney: that's a bit odd. especially as it means none of the testing code in this CL is exercised.
<wrtp> davecheney: anyway, go with what he says...
<TheMue> morning
<davecheney> howdy
<davecheney> anyway gents, i'm taking a break for a bit
<davecheney> i'll see you in a few hours for a pow wow
<fwereade_> low on sleep last night, popping out for some sunshine
<fwereade_> grar, work is beguiling and distracting; *really* popping out now
<TheMue> fwereade_: dcc pleas a bit sun, we've got only clouds here.
<wrtp> i've got to go for a dentist's appointment now. hopefully i'll be back in time for the meeting, even if i might have difficulty speaking.
<Aram> moin.
<fwereade_> Aram, heyhey
<TheMue> Moin Aram
<niemeyer> Good mornings!
<davecheney> bonjour
<TheMue> niemeyer: Heya
<fwereade_> niemeyer, heyhey
<niemeyer> Is it party time?
<davecheney> yes please
<davecheney> who has the invite ?
<niemeyer> I'll do it
<niemeyer> Done
<Aram> a minute....
<TheMue> Lunchtime
<Aram> meh, both T400 and T410 are overheated by the flash in G+ Hangouts.
 * Aram needs a new laptop, maybe.
<TheMue> Aargh, sometimes too stupid. :O Returned from function after err == nil. *sigh*
<TheMue> Yay, tests are green, now remove some debugging statements and propose it.
<TheMue> So, https://codereview.appspot.com/6374047 is in.
<niemeyer> Lunch time!
<wrtp> TheMue: i'm looking at it. for some reason i seem to be losing all initial messages to codereview (presumably you did propose it without -wip), so thanks for the heads up.
<wrtp> TheMue: ping
 * niemeyer waves
 * wrtp waves good night to niemeyer
<niemeyer> wrtp: Are you heading off?
<wrtp> niemeyer: i have to, yes, sorry.
<niemeyer> wrtp: No need to be sorry.. have a pleasant time there :)
<wrtp> niemeyer: just been looking through TheMue's firewall code.
<niemeyer> wrtp: Oh, sweet
<niemeyer> wrtp: How does it feel?
<wrtp> niemeyer: not entirely sure.
<niemeyer> wrtp: Cool, have you made comments on it?
<wrtp> niemeyer: i'm toying with the idea that a more centralised approach might be simpler and easier to understand
<wrtp> niemeyer: only superficial comments so far
<niemeyer> wrtp: Thanks for that.. I'll have a look later
<wrtp> niemeyer: anyway, still thinking, see ya tomorrow!
<niemeyer> wrtp: Cheers!
<niemeyer> Feeling some post-lunch sleepiness.. will lay down for a while to get through the rest of the day in better shape.
<niemeyer> Back soon
<niemeyer> Aram: ping
<Aram> niemeyer: pong
<niemeyer> Aram: Yo
<Aram> hey
<niemeyer> Aram: Just a sync up on this: "Fantastic, I never liked this, however, I only emulated what we have in state now."
<Aram> yes
<niemeyer> Aram: I don't think Machine.String returns "machine-%d" today, does it?
<Aram> niemeyer: no, it doesn't, you were right. machine-%10d is the machinekey, which is used directly by state tests.
<niemeyer> Aram: Aha, super
<niemeyer> Aram: This is actually wrong too
<niemeyer> Aram: There's no reason to not do what you're doing there
<niemeyer> Aram: LGTM
<Aram> niemeyer: thanks.
<Aram> niemeyer: http://bazaar.launchpad.net/~gophers/juju-core/trunk/view/head:/state/state_test.go#L172
<Aram> that's the machinekey, isn't it?
<niemeyer> Aram: Well, it is, but look at the actual operation going on there
<niemeyer> Aram: zkConn.Children
<niemeyer> Aram: It's ignoring the abstraction we put in place entirely
<Aram> yes.
<niemeyer> Aram: To be honest, I'd rather not have this kind of test at all, but then we have to guarantee correctness without poking at internals like this which may be tricky in some cases.
<Aram> I agree.
<niemeyer> Aram: https://codereview.appspot.com/6345056/ ready to go in too.. thanks!
<Aram> niemeyer: thanks, I'll push it and the three others that are pending on after I submit the one I'm working ATM.
<niemeyer> Aram: Sweet
#juju-dev 2012-07-11
 * davecheney waves
<wrtp> davecheney, fwereade, TheMue: mornin' all
<fwereade> wrtp, davecheney, TheMue: heyhey
<davecheney> wrtp: morning
<davecheney> wrtp: i reapplied the local ec2 tests and was pleased to discover none of the tests were broken
<davecheney> but that was just pure luck
<davecheney> as I there were blindly being changed
<wrtp> davecheney: great!
<davecheney> wrtp: you may not think so when you discover why I needed to add UseLocalStateInfo
<wrtp> davecheney: why's that?
<wrtp> (to LiveTests, presumably?)
<davecheney> wrtp: ec2test is hard coded to hand back DNS names machines in the form i-NNN.example.com
<wrtp> davecheney: well ec2test is there to be changed for tests' convenience...
<wrtp> davecheney: but maybe there's no convenient way of changing it
<davecheney> wrtp: I tried for a while
<davecheney> given how inception like jujutest is
<davecheney> there is no way to easily access the underly ec2test
<davecheney> or even know it is being used
<davecheney> have a good evening
<davecheney> i've gotta fly
<Aram> hello.
<TheMue> Aram: Hi
<TheMue> Aram: Took a deeper look into mstate and really like it.
<Aram> great :).
 * TheMue diggs into environs to get a better idea of where get_machine_provider() is or will be in Go and to better integrate a new firewall approach into the provisioning agent
<wrtp> TheMue: ping
 * Aram is off for a few hours.
<TheMue> wrtp: pong
<wrtp> TheMue: i wonder if we could have a chat about the firewall code
<wrtp> TheMue: not right now though... i've just got involved in fixing another bug
<TheMue> wrtp: for sure
<wrtp> TheMue: 15 minutes or so
<wrtp> ?
<TheMue> wrtp: ok, I'm currently start with smaller chunks
<wrtp> TheMue: i think it's worth working out what the overall structure might look like (without actually doing it)
<TheMue> wrtp: yeah, there have to be changes from the old approach
<wrtp> TheMue: currently you've got several independent agents all doing their own thing, and i think that's potentially problematic
<wrtp> TheMue: i'm wondering whether it might be better to funnel all events into a central goroutine that keeps track of the state and issues port open/close requests.
<niemeyer> Good morning all
<TheMue> niemeyer: hello, just had half a doomsday here. lots of rain.
<niemeyer> TheMue: Heya
<niemeyer> TheMue: Woohay :)
<TheMue> So, have to step out shortly for the dentist, they just called me if I wonna come earlier. Should not last long.
<niemeyer> TheMue: Awesome, good luck there
<wrtp> niemeyer: small bug fix for you. should fix the charm store upload process. https://codereview.appspot.com/6344105
<wrtp> niemeyer: good morning, BTW!
<niemeyer> wrtp: Heya
<niemeyer> wrtp: Neat!
<hazmat> g'morning
<hazmat> wrtp, cool
<hazmat> fwiw.. i think there two charms that applies to atm, there's a larger listing of other charms that don't appear in the charm store here.. http://jujucharms.com/tools/store-missing
<hazmat> niemeyer, does the charm store require maintainer?
<niemeyer> hazmat: Not yet
<hazmat> hmm.. ok for several charms that's the only thing clint's lint/proof tool reports, so its unclear what the issue is with them
<hazmat> niemeyer, how do you like gce?
<niemeyer> hazmat: Great stuff
<wrtp> niemeyer: what happens currently if two charms in the same container each open the same port?
<wrtp> hazmat: ^
<wrtp> i suppose i should really ask what *should* happen in that case?
<niemeyer> wrtp: They conflict
<niemeyer> wrtp: and will always continue to conflict
<wrtp> niemeyer: there's an error?
<niemeyer> wrtp: A single container is a single port namespace
<wrtp> niemeyer: open-port fails?
<niemeyer> wrtp: Oh, no, that should work
<hazmat> at a juju level currently there is not, at a system level the port binding is an error
<niemeyer> wrtp: Well.. I don't know if it "should" work, but I bet it "will" work
<wrtp> hazmat: so a charm shouldn't open-port until it's actually bound the socket?
<hazmat> wrtp, not nesc.
<wrtp> niemeyer: i quite like the idea that a given port is "owned" by a particular unit.
<wrtp> niemeyer: then open-port by another unit would give an error
<hazmat> wrtp, it could be reserving port for future exposed usage
<niemeyer> wrtp: +1
<niemeyer> wrtp: Specifically in the case of subordinates, right?
<wrtp> niemeyer: absolutely
<niemeyer> wrtp: Cool, makes sense
<wrtp> niemeyer: i've been going over the firewall semantics
<hazmat> sounds good, detect errors structurally instead of runtime undetected failures.
<wrtp> niemeyer: and that would make sense.
<wrtp> hazmat: yeah
<imbrandon> shoud ports be part of the units metadata then, instead of in an arbitrary hook
<imbrandon> so its owned from the getgo
<wrtp> imbrandon: that's a much-discussed question...
<hazmat> imbrandon, that discussion viewpoint is part of the ml archive on this topic
<imbrandon> ahh
<wrtp> imbrandon: i wasn't actually suggesting that though
<hazmat> to date though, nothing is actually using dynamic ports
<wrtp> imbrandon: i intended to suggest that open-port would take ownership of a given port, if possible.
<imbrandon> right, not much does , incomming wise iirc
<imbrandon> wrtp: right, but what if it cant, the charm would need logic to handle that right ?
<imbrandon> and maybe try another port
<wrtp> imbrandon: yup.
<wrtp> imbrandon: if you're deploying two charms which want to use the same port, there's no way around that
<imbrandon> right
<wrtp> TheMue, niemeyer, fwereade_: here's a pseudocode sketch of a slightly different approach to the firewall management code: http://paste.ubuntu.com/1086303/
<TheMue> *click*
<niemeyer> wrtp: Can you talk me through it?
<wrtp> niemeyer: ok
<niemeyer> wrtp: Is this a worker.. what's unit/machine/etc
<wrtp> niemeyer: so, we've got one central goroutine that has a coherent idea of the current state of the system (with regard to ports)
<wrtp> niemeyer: this is to be started by the provisioning agent.
<fwereade_> wrtp, that looks broadly sensible to me
<niemeyer> wrtp: Okay, so it is a worker
<wrtp> niemeyer: yeah.
<TheMue> wrtp: we have two kinds of service changes: adding/removing and exposed flag.
<wrtp> niemeyer: and it *probably* will work ok when run concurrently with itself, assuming a sensible implementation of Open and ClosePort in the provider
<niemeyer> wrtp: machine/unit/etc are local structs, I assume, rather than representing changes to state.Unit/etc
<fwereade_> wrtp, I presume portManager is something separate, with state, that worries about EC2 errors and suchlike and keeps retrying on errors?
<wrtp> niemeyer: yes
<niemeyer> wrtp: cool
<niemeyer> wrtp: Re-reading with that info
<wrtp> niemeyer: portManager was my name for the main loop
<wrtp> niemeyer: but it would be restarted on errors, yes
<fwereade_> wrtp, it was also the thing that had OpenPort and ClosePort called on it
<wrtp> fwereade_: oh, sorry, i've got two portManagers!
<fwereade_> wrtp, if that's an env I'm a little uncertain
<wrtp> fwereade_: no, portManager is intended to be an environs.Instance
<fwereade_> wrtp, ah-ha, ok, sorry
<wrtp> there is actually a problem
<fwereade_> wrtp, but still... any errors there will surely mean that we have to keep retrying, there, until we succeed... right?
<wrtp> fwereade_: i guess so.
<TheMue> wrtp: sounds good so far, only the missing differentiation between adding/removing and exposing of services
<niemeyer> wrtp: The data coming from the change on line 38 looks curious
<fwereade_> wrtp, that feels a little icky to me but not enough to sink the concept :)
<wrtp> niemeyer: yes, i glossed over that bit
<wrtp> niemeyer: since we're waiting for many watchers at once, we have a goroutine for each watcher that adds context to the change passed on the channel, then sends to a single channel.
<wrtp> niemeyer: so where the pseudocode says "add port watcher...", it implies setting up a goroutine to do that too
<wrtp> niemeyer: but those goroutines don't mess with the state at all
<wrtp> the main problem i can see currently is that there needs to be another phase at the start
<wrtp> where we need to interrogate the currently open ports and close them if they need to be.
<wrtp> fwereade_: it's possible that we might want another layer, being a proxy for a machine, that deals with retrying port changes for that machine.
<fwereade_> wrtp, yeah, something like that
<TheMue> wrtp: right now the real state is retrieved from the provider and compared to the state informations
<wrtp> TheMue: if OpenPort and ClosePort are idempotent, i'm not sure that's necessary.
<wrtp> s/idem/each idem/
<TheMue> wrtp: would be the better solution, indeed
<wrtp> it's entirely possible that this scheme is crackful though. i just thought i'd give it as a talking point.
<wrtp> one thing that's not currently taken into account is that the instance for a machine can change
<TheMue> wrtp: today the fw is notificated when services are added. those get an exposed watcher. if exposed, a unit watcher is set up. and those are watching the units ports. *sigh* deeply nested.
<niemeyer> wrtp: Looks very sensible
<wrtp> TheMue: i didn't see any point in watching services that have no machines, so i add the service watcher only when necessary
<wrtp> niemeyer: thanks
<TheMue> wrtp: sounds reasonable
<niemeyer> wrtp: Have you seen this: https://codereview.appspot.com/6333067/
<wrtp> niemeyer: no. will look.
<niemeyer> wrtp: Cool, it's good to sync up with Dave on that, since they both seem to be overlapping
<wrtp> niemeyer: looks pretty compatible to me
<wrtp> niemeyer: i *think* the environ watching would go inside the same loop
<niemeyer> wrtp: It is compatible so far for sure. I'm just saying that they're both supposed to implement the same functionality, so synchronizing is important
<niemeyer> wrtp: Or we'll end up with two people working on the same thing
<wrtp> niemeyer: definitely. i wasn't actually proposing to write this code - TheMue is there already.
<niemeyer> wrtp: Perfect, thanks
<wrtp> niemeyer: this was borne out of my looking at TheMue's initial stab, which was invaluable for me to see what actually needed to be done.
<niemeyer> wrtp: Super
<niemeyer> wrtp: Thanks for diving into this. Very useful.
<TheMue> niemeyer: If the firewall is only used by provisioning, is it worth to create an own service?
<wrtp> TheMue: hopefully this will be useful input to your next steps, and perhaps we have a better idea of what we might be aiming for
<TheMue> wrtp: Yes, thx.
<wrtp> TheMue: i think it should be a file within the provisioning agent
<TheMue> niemeyer: There are two connection points in the provisioner.
<wrtp> s/a file/implemented in a file/
<TheMue> wrtp: The PA starts the provisioner. And there is a loop where today the machines are watched. In the Py code here also services are watched.
<TheMue> wrtp: So I would see it as a non-exported type for the provisioner (same package, own file).
<wrtp> TheMue: yup
<wrtp> TheMue: that's what i was trying to suggest
<TheMue> wrtp: h5
<wrtp> TheMue: h5
<niemeyer> TheMue: It is worth creating a *worker*, yes
<niemeyer> wrtp: I'd prefer to have this as an independent worker
<niemeyer> wrtp: It's functionality is completely unrelated to the rest of the provisioner
<wrtp> niemeyer: a separate executable?
<niemeyer> wrtp: No
<niemeyer> A different worker, not a different agent
<wrtp> niemeyer: a separate goroutine with the PA?
<wrtp> niemeyer: (that's what i had envisaged)
<wrtp> s/with the/within the/
<niemeyer> wrtp: Yes, and a different package under juju-core/worker/firewaller
<niemeyer> wrtp: I only disagreed with "a file within the provisioning agnet"
<wrtp> niemeyer: ah, i hadn't seen juju-core/worker
<wrtp> niemeyer: presumably a CL waiting to land
<niemeyer> wrtp: It's currently named juju-core/service, but that's wrong and we should rename ASAP
<niemeyer> wrtp: No, we've agreed that was the best nomenclature, and Dave had stuff in progress that he wanted to push forward without distractions. Sounded sensible
<wrtp> niemeyer: yes, that all sounds very sensible
<wrtp> niemeyer: now i understand what you mean by "worker" :-)
 * TheMue too
<TheMue> niemeyer: Today the notification about added/removed services or machines is done by the PA (in Py). The according code fragments in Go are in the provisioner worker.
<TheMue> niemeyer: So should the provisioner call those two exported methods in future too or better setup own watchers to work standalone?
<wrtp> here's a version with logic for dealing with instance ids coming and going: http://paste.ubuntu.com/1086373/
<wrtp> TheMue: i think they'd each set up their own watchers
<wrtp> TheMue: it's a little less efficient, but nicer structurally
<TheMue> wrtp: sounds more clear, yes. better maintainable
<niemeyer> TheMue: Sorry, I don't get the question
<niemeyer> TheMue: As a hint, though, the Python structure of provisioner+firewaller is not an example to be followerd
<niemeyer> followed
<TheMue> niemeyer: Yes, that's what I've done with the first approach.
<TheMue> niemeyer: Do so the FW only needs two public methods for the PA.
<TheMue> niemeyer: But it leads to this nested structure.
<TheMue> niemeyer: So as an own worker with own watchers it's definitely better.
<niemeyer> TheMue: Yeah, that's the direction we should follow
<niemeyer> TheMue: and *small branches*, with *tests*, please!
<TheMue> niemeyer: Yeah, I only have still problems to propose something when it does nothing. And the nested structure of todays FW lead fast to this amount of code, sorry.
<TheMue> niemeyer: So I now will already propose code with stubs.
<niemeyer> TheMue: Thanks a lot
<niemeyer> TheMue: As a hint, try to write tests with the code, rather than getting it ready and then testing
<niemeyer> That's lunch time.. biab
<wrtp> niemeyer: do you think we should do the same thing with security groups as the python version (i.e. one security group per instance) ?
<wrtp> niemeyer: i've been wondering about ways to do better (e.g. one security group per combination of ports)
<wrtp> niemeyer: the latter uses as many security groups as machines in the worst case, but the usual case would be many fewer, i think.
<niemeyer> wrtp: There's no way to do different
<niemeyer> wrtp: Security groups can only be defined at instance creation time
<wrtp> niemeyer: oh darn it! i'd forgotten that
<niemeyer> wrtp: I wish it worked as well
<wrtp> niemeyer: originally i had environs.Instance.OpenPort and ClosePort, but i'm thinking that doesn't map very well to how it works. perhaps environs.Environ.OpenPort(machineId int) would be better.
<wrtp> niemeyer: thoughts?
<wrtp> anyway, gotta go. see y'all tomorrow!
<niemeyer> wrtp: In case you read this, yes, that's how it currently works in Python too
<niemeyer> flaviamissi: Hey!
<flaviamissi> niemeyer: hi!
<niemeyer> flaviamissi: Just now I was looking at the auth problem
<niemeyer> flaviamissi: I think I can reproduce it
<niemeyer> flaviamissi: Should be fixed in a moment hopefully
<flaviamissi> niemeyer: good! I debugged it, but I couldn't get anywhere...
<flaviamissi> niemeyer: you have something that can be causing this problem in mind?
<niemeyer> flaviamissi: Not yet, but should have something in a bit :)
<niemeyer> flaviamissi: It's not hard to find this kind of inconsistency between EC2 & similars
<niemeyer> unfortunately
<niemeyer> flaviamissi: Even between *regions* of EC2, sometimes there are inconsistencies
<flaviamissi> niemeyer: hmmm, first time i've seen something like that, good to know though
<flaviamissi> niemeyer: I'm really curious about what is causing that problem, if you can let me know when you find something, I would really appreciate that :)
<niemeyer> flaviamissi: Oh yeah, I'll certainly let you know
<flaviamissi> niemeyer:  thanks :)
<niemeyer> flaviamissi: It's the path
<niemeyer> flaviamissi: The endpoint path, more specifically
<niemeyer> I'll have a fix in a moment
<niemeyer> Works!
<flaviamissi> niemeyer: putz!
<niemeyer> :)
<flaviamissi> niemeyer: We didnt think about it...
<flaviamissi> niemeyer: really great. Thanks a log
<flaviamissi> lot*
<niemeyer> flaviamissi: My pleasure
<flaviamissi> niemeyer: is the change in trunk yet?
<flaviamissi> niemeyer: well, i'll leave now, when you merge it with trunk i'll try it :)
<niemeyer> Come on Launchpad.. why you don't like me
<niemeyer> Dinner time
#juju-dev 2012-07-12
<wrtp> fwereade_: mornin'!
<fwereade_> wrtp, heyhey
<wrtp> fwereade_: how's tricks?
<fwereade_> wrtp, not too bad
<wrtp> fwereade_: BTW are you getting the initial mail for each codereview proposal?
<wrtp> fwereade_: i'm not, and i can't see what's going wrong. i've just been through all my mail filter patterns and can't see any likely candidate.
<fwereade_> wrtp, hmm, yes, it looks like I am in general
<fwereade_> wrtp, maybe something about LP?
<wrtp> fwereade_: i'm getting the initial '[Merge]' mail, but those [Merge] mails are so noisy i archive them immediately.
<wrtp> fwereade_: the strange thing is i see any replies
<fwereade_> wrtp, ah, ok, that is weird then
<wrtp> fwereade_: so the first thing i'll know about any CL is when someone replies to it
<wrtp> yeah, it's odd, and quite annoying actually
<fwereade_> wrtp, yeah, I bet :(
<wrtp> fwereade_: hmm, the odd thing is i do see *some* initial emails. Aram's and gustavo's seem to come through ok.
<fwereade_> wrtp, heh that's even weirder
<wrtp> fwereade_: i wonder if there's a way to check in launchpad what messages it's sent me
<fwereade_> wrtp, I doubt that sort of thing specifically is logger
<TheMue> Morning
<fwereade_> wrtp, I bet we all have a subtly different combination of LP settings, and memberships of various things
<fwereade_> TheMue, heyhey
<wrtp> fwereade_: can you think of a CL you've replied to recently that i wasn't involved in?
<wrtp> TheMue: yo!
<fwereade_> wrtp, I don't think I have done much of that lately :(
<wrtp> fwereade_: hmm. TheMue?
<TheMue> wrtp: What?
<wrtp> TheMue: (i'm trying to work out why i'm not seeing some emails from launchpad)
<wrtp> TheMue:  can you think of a CL you've replied to recently that i wasn't involved in?
<TheMue> wrtp: Have to look, but have to change systems fir it.
<wrtp> TheMue: any CL that someone else created and you replied earlier than me would do too
<TheMue> wrtp: If so, then mostly Williams CLs.
<wrtp> TheMue: one example would be good, if you could, thanks!
<wrtp> TheMue: here's an updated version of my firewaller sketch, BTW. http://paste.ubuntu.com/1087489/
<wrtp> TheMue: i realised that tracking machine instance ids was unnecessary, because the OpenPort/ClosePort functions should operate on Environ with a machine id rather than on an environs.Instance.
<TheMue> wrtp: Great, thx, will today integrate it into the firewaller outline of dave
<wrtp> TheMue: good plan
<wrtp> TheMue: i'm not sure of a good way to build it up bit by bit though. i can't think of any useful tests for the intermediate stages.
<TheMue> wrtp: That has been my prob with the first approach.
<TheMue> wrtp: Now I'll use stubs for intermediate CLs
<wrtp> TheMue: i suppose you could put hooks in for the intermediate stages, to be removed later. but writing tests only to delete them later seems a bit wrong.
<TheMue> wrtp: No, the tests shall be the right ones and make the right asserts
<wrtp> TheMue: yeah, and the problem is that the only observable side-effects of this code are the calls to OpenPort/ClosePort
<TheMue> wrtp: But while they first may get constants it will get more and more live with each iteration
<wrtp> TheMue: which won't happen until all the rest is there.
<TheMue> wrtp: So the tests verify the impl
<TheMue> wrtp: See the current approach. I've used an interface and a mock for call verification.
<wrtp> TheMue: the first stage AFAICS is to get the machine watcher done. but there are no calls to anything when the machine watcher fires, so no verification to do AFAICS
<wrtp> TheMue: i suppose you could put in a fake call to OpenPort for the time being, to be changed later.
<TheMue> wrtp: Yep, that's what I meant. The Py firewall gets a provider and I reduced it to the three methods of the PortManager interface. Will see how I can temoporarilly inject something similar here and remove it later.
<wrtp> TheMue: i'm doing the port manager implementation in ec2, and i think the Environ port manager interface might look something like this: http://paste.ubuntu.com/1087531/
<TheRealMue> wrtp: So, changed client.
<wrtp> TheMue: did you see my message a few seconds ago?
<wrtp> oh yeah, you should've
<TheMue> wrtp: About the port manager interface? Yes, just looking at it
<wrtp> TheMue: in fact, scratch that, i think it's not easy to implement well in ec2
<TheMue> wrtp: So SetPorts() would ensure that only the passed ports are open afterwards?
<wrtp> TheMue: yeah, but i think it's wrong
<wrtp> TheMue: i think this is better: http://paste.ubuntu.com/1087535/
<TheMue> wrtp: Today the FirewallManager retrieves the current real state, compares it to the wanted state and builds the diffs to explicitely open and close the ports.
<wrtp> TheMue: i don't think it needs to do that
<wrtp> TheMue: apart from at the very beginning
<TheMue> wrtp: ???
<TheMue> wrtp: The new interface matches exactly to that.
<wrtp> TheMue: it only needs to do the diff once, when the firewaller starts up, i think.
<wrtp> TheMue: from then on it knows the "real" provider state, and can just apply OpenPorts and ClosePorts methods as the State changes
<wrtp> TheMue: i.e. it will need to call Ports once only
<TheMue> wrtp: Understand, yes.
<TheMue> wrtp: In todays model the provisioner called individual methods after each service and machine change, so a different approach
<wrtp> TheMue: yes - the difference is that, if you follow my sketch, we keep track of the state in one place, so we know exactly what's going on at all times
<wrtp> TheMue: BTW the reason that SetPorts is a bad idea is that the ec2 primitives are AuthorizeSecurityGroup and RevokeSecurityGroup - there's no way to set the entire set of permissions of a security group at once.
<wrtp> fwereade_, TheMue: what do you think should happen to a machine's open ports if it's restarted on a different instance?
<wrtp> niemeyer: ^
<wrtp> niemeyer: mornin' BTW
<fwereade_> wrtp, hmm, given that that *can* happen... are we not in a situation where we *cannot* depend on our local state to know what ports are really open?
<fwereade_> wrtp, this is not a solution but it does maybe feel like a fundamental problem with the maintain-local-state approach...
<fwereade_> niemeyer, morning
<wrtp> fwereade_: as currently conceived, the machine's open ports are independent of its instance
<wrtp> fwereade_: but currently when a new instance is started, it ensures that the machine's group has no permissions
<fwereade_> wrtp, I think that is a restatement of the problem?
<fwereade_> wrtp, the *obvious* answer is to put a watch on a machine's instance ID, but I'm not sure it's a *good* one
<wrtp> fwereade_: yeah, i think that's right
<fwereade_> wrtp, however I don;t think we have any other way of telling
<fwereade_> wrtp, wait a mo
<fwereade_> wrtp, is it easy to reuse the security group from the original machine?
<wrtp> fwereade_: i think perhaps it's up to the provisioner to change the port settings for a machine when it starts an instance
<wrtp> fwereade_: it *doesn* use the security group from the original machine
<wrtp> s/doesn/does/
<wrtp> fwereade_: but currently it will zero the perms when the instance starts
<fwereade_> wrtp, ah, but it clears it out?
<wrtp> yeah
<wrtp> fwereade_: i'm thinking that it shouldn't
<fwereade_> wrtp, hmmmmmmm, so, consider the lifecycle of the unit agent on the new machine
<fwereade_> wrtp, that will start up, open ports, blah blah
 * wrtp is considering
<fwereade_> wrtp, won't it Just Work already?
<fwereade_> wrtp, I think it might :)
<wrtp> fwereade_: it would *if* all the security groups from a previous instance of the environment had been destroyed
<wrtp> fwereade_: but i'm not sure we can guarantee that
<wrtp> fwereade_: thus i think that when starting a new instance, the PA should perhaps call Ports and ClosePorts to clear out any old cruft
<wrtp> s/starting a new instance/starting a new machine/
<wrtp> fwereade_: i *think* that would solve the problem
<wrtp> niemeyer_: yo!
<TheMue> wrtp: Kind of CloseAllPorts() sounds good, yes
<wrtp> TheMue: env.ClosePorts(m, m.Ports())
<wrtp> TheMue: (with error checking of course :-])
<fwereade_> wrtp, I'm confused: I thought you said that the perms *were* zeroed whenever we start an instance
<wrtp> TheMue: that's essentially what it does now, behind the scenes
<wrtp> fwereade_: they are, by the ec2 environ
<wrtp> fwereade_: but that means we can create a new instance for an existing machine
<fwereade_> wrtp, ok, so what doesn't already do the Right Thing?
<TheMue> wrtp: You can't pass m.Ports()
<wrtp> TheMue: m.Ports would return an error
<wrtp> oops, env.Ports(m) of course
<fwereade_> wrtp, if and when that machine needs some ports opened, it'll do an open-port in a hook, and... oh
<fwereade_> wrtp, the unit will say "meh, those ports are already open, no state changes here!"
<wrtp> fwereade_: this was the source of my original question
<wrtp> fwereade_: i'm not sure what behaviour we *want* here
<wrtp> fwereade_: perhaps a new instance *should* always come up with no open ports
<fwereade_> wrtp, so actually we need the unit agent to realise when *it* is being started on a fresh machine, and clear out its own ports to begin with, so the Right Thing happens when the hooks reopen them
<fwereade_> wrtp, I think new instances should certainly come up with no open ports
<fwereade_> wrtp, I'm pretty sure the difficulty is at the unit agent level
<wrtp> fwereade_: given that the PA is starting the new instance, it's in a good position to clear out the ports first
<fwereade_> wrtp, I thought that always happened already?
<TheMue> wrtp: Exactly
<wrtp> fwereade_: it does currently, but i wasn't sure if it should
<fwereade_> wrtp, I guess that ideally this *should* be done by the PA rather than by the environ
<wrtp> fwereade_: i'm now thinking the current behaviour is correct
<wrtp> fwereade_: well, yeah
<wrtp> fwereade_: that would seem better
<fwereade_> wrtp, because then we won't need every single environ to mess with ports on instance start
<wrtp> fwereade_: well, the same code will be executed - it'll just be called from the PA
<wrtp> ahh, but...
<fwereade_> wrtp, yeah, but we only have to write it once instead of N times
<wrtp> this all interacts with the firewall code
<fwereade_> wrtp, and the firewall code will then get an inaccurate view of state?
<wrtp> because the firewall is keeping track of what ports are supposed to be open
<wrtp> fwereade_: yeah
<fwereade_> wrtp, I don't *think* it matters if we depend on the UA doing the Right Thing wrt closing all ports when it starts up on a fresh machine
<TheMue> wrtp: that's its task
<wrtp> fwereade_: actually, i think you're right
<wrtp> fwereade_: if the UA does it, we have no problems
<wrtp> fwereade_: and the firewaller doesn't have to keep track of instance ids
<fwereade_> wrtp, yep, think so
<wrtp> fwereade_: then *all* port opening and closing is done via the state open/close port
<fwereade_> wrtp, yeah, exactly
<fwereade_> wrtp, the firewaller can watch that alone and it'll catch up when it becomes important to
<wrtp> fwereade_: and the environ won't clear out ports when starting a new instance
<fwereade_> wrtp, the environs should still clear out ports
<fwereade_> wrtp, ah wait
<wrtp> yeah
<wrtp> there's a difficulty
<wrtp> no, it's ok i think
<wrtp> fwereade_: the PA clears out ports when it starts a new *machine*
<wrtp> fwereade_: because machine ids are never reused
<wrtp> fwereade_: thus we ensure that all new machines start in a known state, and the firewaller can track them properly.
<fwereade_> wrtp, I think that clearing them at *instance* start time is the Right Thing: I don't see any benefit to keeping the ports open while launching the machine
<fwereade_> wrtp, the UA will clear out the desired ports in state when it comes up
<fwereade_> wrtp, and at that point the firewaller will be back in sync
<wrtp> fwereade_: yes, that sounds reasonable
<wrtp> fwereade_: if *slightly* tricksy
<wrtp> fwereade_: i think StartInstance should document that the ports for the machine id will be closed when it's called.
<fwereade_> wrtp, honestly this feels like a job for an Environ struct type that tells an internal EC2-or-whatever env to (1) StartInstance, (2) CloseAllPorts
<fwereade_> wrtp, StartInstance having to magically mess with ports in every provider STM like a recipe for bugs
<wrtp> fwereade_: s/struct type/function/ ?
<fwereade_> wrtp, IMO having the real environ accessible for people to mess with is similarly a recipe for bugs, but YMMV
<wrtp> fwereade_: my mileage does :-)
<wrtp> fwereade_: tbh i'd be happy for the PA to implement that logic
<fwereade_> wrtp, IMO `env.StartInstance(...` rather than StartInstance(env, ...` not not sufficiently obviously a bug
<wrtp> fwereade_: it's very straightforward, and then there's no hidden interaction between StartInstance and ClosePorts.
<wrtp> fwereade_: nothing else calls StartInstance
<wrtp> afaik
<wrtp> fwereade_: so there's really no need for another layer
<fwereade_> wrtp, we'll see
<wrtp> fwereade_: for the time being, i'll implement Ports, OpenPorts and ClosePorts, and remove the port closing logic from StartInstance
<wrtp> fwereade_: i think that should be sufficient
<niemeyer_> wrtp, fwereade_: Heya!
<wrtp> niemeyer_: does that sound reasonable?
<fwereade_> niemeyer_, heyhey
<niemeyer_> wrtp: Sorry, I wasn't following
<niemeyer_> wrtp: Breakfast made a lot of sense, though :-)
<wrtp> lol
<fwereade_> wrtp, IMO any situation in which you're saying "a call to Foo must be immediately followed by a call to Bar" is a bug waiting to happen
 * fwereade_ shrugs
<wrtp> niemeyer_: perhaps you could read over the recent conversation
<wrtp> fwereade_: only in the context of the provisioner is that true
<niemeyer_> wrtp: Will definitely do, but I have to take Ale to work first, as she's starting in a few minutes.. I'll be back soon, though
<fwereade_> wrtp, and on bootstrap?
<wrtp> niemeyer_: np
<wrtp> fwereade_: that's just a specialised kind of provisioning :-)
<fwereade_> wrtp, as you like
<wrtp> fwereade_: we're only talking about 3 lines of code in two places here...
<TheMue> wrtp: line 24 of http://paste.ubuntu.com/1087489/, how would you manage the watcher of all units for a machine? based on your outline I only see one per machine.
<fwereade_> wrtp, one of which you apparently forgot about
<fwereade_> wrtp, bug waiting to happen
<wrtp> fwereade_: there are many bugs waiting to happen :-)
<fwereade_> wrtp, which is why in general I prefer to make the ones I can see unpossible ;p
<wrtp> TheMue: there's one units watcher per machine. then line 36 starts a new watcher for any new unit on a given machine
<wrtp> fwereade_:
 * wrtp finds that less bugs come from less code
<TheMue> wrtp: ah, so I misunderstood the plural sentence
<fwereade_> wrtp, I don't think we're going to convince one another here
<wrtp> TheMue: yeah by "machine units watcher" i meant a watcher to watch the units on a given machine
<TheMue> wrtp: That definitely makes more sense
<wrtp> fwereade_: you're probably right :-|
<TheMue> wrtp, fwereade_: have to be afk for a moment, once again daddy-daughter-taxi
<wrtp> fwereade_: there's just as many bugs waiting to happen with a Environ shim BTW - you'd need to remember to insert the shim that does the StartInstance magic.
<wrtp> fwereade_: and then that shim wouldn't strictly implement environs.Environ, because it would do magic on StartInstance...
<fwereade_> wrtp, yeah, environs.Environ is IMO the wrong thing to be exposing
<fwereade_> wrtp, but I am not interested in reachitecting anything we don't *have* to at this stage
<wrtp> fwereade_: the wrong thing to be exposing to what?
<fwereade_> wrtp, so let's just drop it :)
<wrtp> fwereade_: np
<wrtp> fwereade_: i'm interested in your thoughts though
<fwereade_> wrtp, they're not really relevant at this stage -- we made the decision to stick all the common stuff into the EC2 provider ages ago
<wrtp> fwereade_: the common stuff can easily be factored out later while retaining the same environs.Environ interface.
<wrtp> fwereade_: i think
<fwereade_> wrtp, we'll worry about that when we have to
<wrtp> fwereade_: my thought too
<niemeyer_> fwereade_, wrtp: I'm not sure I undertand what's the last consensus, despite the fact I've read the backlog
<wrtp> niemeyer_: as i understand it, the consensus is this:
<wrtp> niemeyer_: 1) we add these methods to environs.Environ: http://paste.ubuntu.com/1087700/
<fwereade_> wrtp, niemeyer_: clear all provider ports on instance start; clear all state ports on UA start; firewaller will catch up when it needs to
<fwereade_> wrtp, niemeyer_: AIUI ;)
<wrtp> niemeyer_: 2) we change the ec2 StartInstance so that it doesn't automatically clear out machine ports
<niemeyer_> LOL
<niemeyer_> Looks like there's no consensus indeed
<wrtp> niemeyer_: we're not in conflict there
<wrtp> niemeyer_: the question is *where* the provider ports get cleared out
<niemeyer_> "clear all provider ports on instance start" != "change the ec2 StartInstance so that it doesn't automatically clear out machine ports"
<wrtp> niemeyer_: 3) make the PA clear out ports when it starts a new instance
<wrtp> niemeyer_: this is so that there's no behind-the-scenes interaction between StartInstance and the open ports
<wrtp> niemeyer_: but i'm happy for StartInstance to be documented as closing any machine ports too
<wrtp> niemeyer_: 4) make the UA clear out state ports on unit start
<niemeyer_> Huh
<wrtp> niemeyer_: oops.
<niemeyer_> That seems to turn a trivial issue into a multi-faceted problem on three different entities
<wrtp> niemeyer_: 3) make the PA clear out ports when it starts a new *machine*.
<wrtp> niemeyer_: what does?
<niemeyer_> 1+2+3+4
<niemeyer_> What's the issue we have?
<niemeyer_> wrtp: (1) looks good, btw
<wrtp> niemeyer_: one issue is: what happens when the PA starts a new instance for a machine that had an instance before?
<wrtp> niemeyer_: open ports are attached to machines, not instances
<niemeyer_> wrtp: Not exactly
<wrtp> niemeyer_: and it would be nice if the firewaller doesn't have to track instances
<niemeyer_> wrtp: Both contain data about it
<niemeyer_> wrtp: But, ok..
<niemeyer_> wrtp: The provisioner doesn't care about ports at all
<niemeyer_> wrtp: It's not its problem
<wrtp> niemeyer_: there is a problem
<niemeyer_> wrtp: Ok.. go on
<wrtp> niemeyer_: if the provisioner starts a new instance for a machine, we want to close all the ports for that machine
<wrtp> niemeyer_: probably
<niemeyer_> wrtp: No, we don't
<wrtp> niemeyer_: although we could choose not to
<niemeyer_> wrtp: Machines should be started with no open ports
<wrtp> niemeyer_: fwereade_ thought we should. i'm on the fence.
<niemeyer_> Sorry
<niemeyer_> Bad term
<niemeyer_> wrtp: Instances should be started with no open ports
<wrtp> niemeyer_: exactly
<niemeyer_> wrtp: That's a problem for the environment to solve
<wrtp> niemeyer_: so we want to close all the ports for the existing machine
<wrtp> niemeyer_: in the state
<niemeyer_> wrtp: No!
<niemeyer_> wrtp: The state is something else!
<wrtp> niemeyer_: so we'd have a machine in the state with open ports, but the instance would have no open ports?
<niemeyer_> wrtp: This was just about the environment itself..
<niemeyer_> wrtp: I think I'm missing the actual issue
<niemeyer_> wrtp: Yeah, I was missing indeed.
<niemeyer_> wrtp: Okay
<niemeyer_> wrtp: So there are two separate issues
<niemeyer_> wrtp: One of them concerns management of ports of the instance.. the other about management of ports in the state
<wrtp> yup
<niemeyer_> wrtp: Which one are we talking about?
<wrtp> both
<wrtp> niemeyer_: how they interact with each other
<niemeyer_> wrtp: Okay, so can we please separate them up
<niemeyer_> wrtp: Not really.. they are independent issues
<wrtp> niemeyer_: there is no management of ports of the instance
<niemeyer_> wrtp: !?
<wrtp> niemeyer_: there is management of ports of the *machine*
<wrtp> niemeyer_: OpenPorts(machineId int, ports []state.Port) error
<niemeyer_> wrtp: Oops
<niemeyer_> wrtp: Yeah, just now I realize that.. this seems wrong
<niemeyer_> wrtp: Environ manages instances, not machines
<wrtp> niemeyer_: so we manufacture a new security group every time we start a new instance?
<niemeyer_> wrtp: Is there any other way?
<niemeyer_> wrtp: We talkeda about this yesterday
<wrtp> niemeyer_: well, currently we name the instance group after the machine id
<wrtp> niemeyer_: but i think you're suggesting that we don't do that
<niemeyer_> wrtp: I'm suggesting something else.. I'm suggesting that Environ manages instances, not machines. Do we agree on that?
<wrtp> niemeyer_: currently the Environ uses the machine id for some things
<niemeyer_> wrtp: Do we agree on that?
<wrtp> niemeyer_: "manages", yes.
<niemeyer_> wrtp: Okay, thanks
<wrtp> niemeyer_: but setting the ports for a machine isn't "managing" the machine, i think.
<niemeyer_> wrtp: So the question is what interface makes sense given that. I understand the ec2 implementation does certain things a given way
<niemeyer_> wrtp: It's managing the instance information for sure
<wrtp> niemeyer_: the ec2 implementation is a fairly close reflection of the python implementation in this respect
<niemeyer_> wrtp: It's controlling the firewall data associated with the instance
<wrtp> niemeyer_: currently it's controlling the firewall data associated with the *machine*
<niemeyer_> wrtp: Not really
<wrtp> niemeyer_: because the security group is named after the machine, not the instance
<niemeyer_> wrtp: The firewall data associated the machine is controlled via state
<niemeyer_> wrtp: It's not doing anything with that
<wrtp> ?
<niemeyer_> ?
<niemeyer_> Can't answer that :)
<wrtp> :-)
<wrtp> i could also say "the firewall associated with the machine is controlled by the provider"
<niemeyer_> wrtp: Machine lives in *State
<niemeyer_> wrtp: Everythign about the Machine is controlled via *State
<wrtp> ok, s/machine/machine id/
<niemeyer_> wrtp: Instance is the name we give to a provider's virtual machine
<niemeyer_> wrtp: Environ.OpenPort manages the Instance, not the Machine
<niemeyer_> wrtp: That's what I'm trying to  point out
<wrtp> niemeyer_: in the ec2 implementation that's not true
<niemeyer_> wrtp: In all environs/* implementations, that is true
<wrtp> niemeyer_: because the security group is associated with the machine id, not the instance id
<niemeyer_> wrtp: That's completely irrelevant.. we could name it as "abacate"
<wrtp> niemeyer_: and there can be several instances for a given machine id
<niemeyer_> wrtp: It's still associated with the Instance, and it's still managing the firewall for the Instance
<niemeyer_> wrtp: Machine is an abstraction we decided on for referring to the *State information
<wrtp> niemeyer_: originally, i had Instance.OpenPort
<wrtp> niemeyer_: but that seems wrong
<niemeyer_> wrtp: Yes, and you changed that to make it more convenient
<wrtp> niemeyer_: not more convenient, more true to reality
<niemeyer_> wrtp: The fact we use machine ids on the security group name is an implementation detail.. the fact we have to *use* security groups like that is also an implementation detail
<niemeyer_> wrtp: In the future this will live within the instance
<wrtp> niemeyer_: in that case, the Environ interface must change
<wrtp> niemeyer_: because the PA won't be able to control it from outside
<niemeyer_> wrtp: Yes, it will have to change eventually, by simply losing these methods
<wrtp> niemeyer_: exactly.
<wrtp> niemeyer_: so for the time being, this is what we've got - the ports for an instance are managed by changing attributes associated with the machine id, not the instance.
<niemeyer_> wrtp: But disagreeing that Environ controls Instances is a blocker on that conversation.. we StartInstance, we StopInstance, we ask for Instance and AllInstances..
<wrtp> niemeyer_: i certainly didn't disagree that Environ controls Instances
<niemeyer_> wrtp: That may be the best way to move forward, but it's hard to get there if we can't even agree on obvious facts
<wrtp> niemeyer_: the issue of the interaction of machine id and the Environ is a tricky one
<wrtp> niemeyer_: why are we passing the machine id into StartInstance at all?
<niemeyer_> wrtp: To get the machine id into the state initialization
<niemeyer_> wrtp: That was the real reason it got there
<wrtp> niemeyer_: so maybe it *is* wrong that the instance's security group is named after the machine id
<wrtp> niemeyer_: (but it's going to be a bit awkward to come up with new unique names)
<niemeyer_> wrtp: I see it merely as an implementation convenience as we need something unique per machine
<wrtp> niemeyer_: per machine or per instance?
<niemeyer_> wrtp: This is completely hidden away from the interface
<niemeyer_> wrtp: Per instance, sorry
<niemeyer_> wrtp: I also see it as a nasty hack we have to do for AWS
<wrtp> niemeyer_: currently, it's *not* unique per instance
<wrtp> niemeyer_: sure
<wrtp> niemeyer_: i agree it's not great.
<niemeyer_> wrtp: Surely it must be unique.. a security group name is unique, and we have one security group per instance..
<wrtp> niemeyer_: we can have multiple instances using the same security group
<wrtp> niemeyer_: if they're started with the same machine id
<wrtp> niemeyer_: there's nothing in the Environ API that prevents that
<niemeyer_> wrtp: Oh, you mean if there are multiple environments in a single AWS account?
<niemeyer_> wrtp: Fuck, that's a bug
<wrtp> niemeyer_: no
<wrtp> niemeyer_: if i call StartInstance(1); StartInstance(1)
<niemeyer_> wrtp: Oh, wait.. the security group has the env name in it too
<wrtp> niemeyer_: yeah
<niemeyer_> wrtp: Oh, sure.. that'd be broken usage of the environment
<wrtp> niemeyer_: if i do the above, i'll get two instances sharing the same security group
<wrtp> niemeyer_: not necessarily, if the first instance has stopped for some reason
<wrtp> niemeyer_: and the PA is restarting it
<niemeyer_> wrtp: Stopped or destroyed?
<wrtp> niemeyer_: crashed
<niemeyer_> wrtp: Crashed and destroyed or crashed and stopped?
<niemeyer_> wrtp: Both are possible
<wrtp> niemeyer_: crashed and stopped.
<wrtp> niemeyer_: but you're going to say that the PA won't restart in that case, right?
<niemeyer_> wrtp: That means the instance is still alive
<niemeyer_> wrtp: Yes, it shouldn't
<wrtp> [11:44:30] <wrtp> niemeyer_: there's nothing in the Environ API that prevents that
<wrtp> it's just a convention upheld by the PA
<niemeyer_> wrtp: Sure.. I don't undertand what your underlying point is, though. This is our backyard.. are you suggesting we implement a second *State within the environment?
<niemeyer_> wrtp: Just so we can control the correct use of *State?
<wrtp> niemeyer_: which is why i thought it might be better to make the environ API better reflect the reality of what's underneath
<wrtp> niemeyer_: (and as a bonus, it makes the firewaller code easier)
<niemeyer_> wrtp: Sorry, I can buy that.. that's completely unrelated to the point above, though
<wrtp> niemeyer_: i'm suggesting that the OpenPorts calls associate ports with machine ids, not instances, because that's what's actually going on underneath
<niemeyer_> wrtp: "Environ has an unsafe API, thus we can make the API simpler to use" makes no sense to me
<wrtp> niemeyer_: then the API isn't unsafe
<wrtp> niemeyer_: because it's not trying to pretend that ports are associated directly with instances.
<niemeyer_> wrtp: How come? You're saying we can have multiple machines associated with a single security group, and then we associated ports with whatever machine is using, and that's fine!?
<niemeyer_> wrtp: This is going in a pretty strange direction
<niemeyer_> wrtp: If our implementation can't control the association between security group and instance correctly, that's a MAJOR PROBLEM.
<wrtp> s/multiple machines/multiple instances/ and yes, that's ok i think
<wrtp> niemeyer_: our implementation controls the association between security group and port, not between instance and port. that's the basic difficulty.
<niemeyer_> wrtp: Agreed. Cool, that's a good baseline
<wrtp> niemeyer_: the "bonus" above is that the firewaller wouldn't need to keep track of every machine's allocated instance, because all it needs to change is the ports associated with a *machine* not an instance.
<niemeyer_> wrtp: machine.InstanceId()? How is doing that any harder than using a machine id?
<wrtp> niemeyer_: FWIW the open_port code in the python version takes an instance as an argument but only ever uses the machine id
<wrtp> niemeyer_: because the instance id can come and go
<wrtp> niemeyer_: so it's one more thing to track
<wrtp> niemeyer_: i had a sketch version of the firewaller code that did that
<wrtp> http://paste.ubuntu.com/1087751/
<niemeyer_> wrtp: We don't have to "track" that, I think.. if the instance id "goes", everything inside it is gone too.
<wrtp> vs: http://paste.ubuntu.com/1087753/
<wrtp> niemeyer_: yes, so that firewaller needs to know when that happens, right?
<wrtp> niemeyer_: and it needs to know when the machine is allocated a new instance id too
<niemeyer_> wrtp: No, the firewaller only needs to know when a new port is opened or closed, and act accordingly to open and close ports in the environment, as far as I understand it.
<niemeyer_> wrtp: StartInstance creates an instance with zero open ports
<niemeyer_> wrtp: What will open the ports in the state are the units that run within that instance that was started
<niemeyer_> wrtp: That's what the firewaller must react to
<wrtp> niemeyer_: i think i see a problem with that
<wrtp> niemeyer_: so... an instance gets destroyed; the PA notices that and allocates a new instance. the firewaller is thus far blissfully unaware, right?
<niemeyer_> wrtp: Yes
<niemeyer_> (I'm supposing, at least)
<wrtp> niemeyer_: on the new instance, the UA starts up, notices that some ports are open that shouldn't be, so it closes them. it then runs the start hook, which opens some ports again
<wrtp> niemeyer_: the new ports and the old ports are identical, so the firewaller might see no change
<wrtp> niemeyer_: but given that we're operating on the instance, not the machine, that would mean we won't have changed the firewall settings for the new instance
<niemeyer_> wrtp: This problem exists irrespective of what the API looks like. Semantically, these ports should be closed. It's not fine to say "Oh, it's the same machine so I'll just leave stuff open.."
<wrtp> niemeyer_: i don't think the problem exists if ports are associated with a machine id
<wrtp> niemeyer_: the problem with the above is that the ports on the new instance won't be opened
<niemeyer_> wrtp: Again, it is not fine to start the new machine with open ports, despite the fact the unit didn't open it
<wrtp> niemeyer_: i wasn't suggesting that we did
<niemeyer_> <wrtp> niemeyer_: the new ports and the old ports are identical, so the firewaller might see no change
<niemeyer_> wrtp: This exists no matter what the API looks like.. I don't know what you are suggesting then
<wrtp> niemeyer_: a suggestion is that StartInstance is documented to close all the ports for its machine id
<niemeyer_> wrtp: s/machine id/started instance/
<wrtp> niemeyer_: no, that's the difficulty.
<niemeyer_> wrtp: Okay, clearly I'm missing what it is.. what is the difficulty in closing the ports for an instance?
 * wrtp tries to get his head in order :-)
<wrtp> niemeyer_: suppose we had an implementation of Environ that really did associate ports with instances directly
<wrtp> niemeyer_: as the API would suggest
<wrtp> niemeyer_: in that case, we *need* to adjust the firewall settings on a new instance when a machine's instance changes
<wrtp> niemeyer_: so we'd need to track the instance id for a machine to do that
<wrtp> niemeyer_: we *could* do that
<niemeyer_> wrtp: We do track instance id for machines. We also do need to adjust the firewall setting on the new instance, both to ensure it has no ports open when it started, and also to ensure that the units get a clean state when they get up.
<niemeyer_> wrtp: Both of these are already true, and we're not even talking about the API.
<wrtp> niemeyer_: the PA and the UA can do that between them. the PA to adjust the ports before it starts a new instance, the UA to make the state hold what it should.
<niemeyer_> wrtp: That sounds good.. the PA should simply zero out all ports on *state* specifically (not the Environ) when starting the instance
<wrtp> niemeyer_: one problem with having the firewaller doing it is that it the machine will be started and running before the firewaller gets around to closing the ports
<wrtp> niemeyer_: ah, yes
<wrtp> niemeyer_: that sounds good
<wrtp> niemeyer_: there's still a race, but i'm sure that in any reality we know, it'll be won by the firewaller
<Aram> hey,
<niemeyer_> wrtp: Indeed. We can be pragmatic for now and just have a TODO in the code saying it'd be extremely weird to have that race happening.
<niemeyer_> wrtp: It's also easy to avoid the race in the future when we choose to
<wrtp> niemeyer_: nevertheless, doing things this way does mean we don't *necessarily* have to track instance ids in the firewaller
<wrtp> niemeyer_: yeah
<wrtp> Aram: hiya
<niemeyer_> wrtp: Right, and we can still have the Environ interface operating in terms of instances
<wrtp> niemeyer_: aargh!
<niemeyer_> wrtp: Heh
<niemeyer_> wrtp: Sorry, you won't convince me that
<niemeyer_> environ.OpenPort(machineId)
<wrtp> niemeyer_: if the Environ interface OpenPort and ClosePort methods operate on instances, then we *do* have to track instance ids in the firewaller
<niemeyer_> is so much better than
<niemeyer_> id, err := machine.InstanceId()
<niemeyer_> environ.OpenPort(instance)
<TheMue> wrtp: When the PA sets the instance id for a machine this could be watched so we know the old one for closing and the new one for opening.
<wrtp> environ.OpenPort(machineId) is operating on a machine! there's no instance there...
<niemeyer_> wrtp: Gosh..
<TheMue> Aram: Hi
<niemeyer_> wrtp: This is getting repetitive
<wrtp> niemeyer_: v sorry
<niemeyer_> wrtp: Machine leaves in *State
<niemeyer_> lives
<niemeyer_> wrtp: To change a *Machine OpenPorts, you need to use the *State
<wrtp> niemeyer_: that OpenPort sig had "machineId" in it
<wrtp> niemeyer_: ok, i see your p.o.v.
<wrtp> niemeyer_: i'll rephrase
<niemeyer_> wrtp: The Environ manages *Instances
<niemeyer_> wrtp: Only *Instances..
<wrtp> environ.OpenPort(machineId) isn't operating on an instance! there's no instance there...
<niemeyer_> wrtp: It's an implementation detail that an AWS security group uses a Machine.Id in its name
 * TheMue prefers the instance id too as it's the representation of the physical instance
<niemeyer_> wrtp: As soon as we bless this code base as Good, we'll have a massive number of new providers popping by
<wrtp> TheMue: the difficulty is that the underlying environ isn't actually changing an attribute on the instance...
<niemeyer_> wrtp: Despite this being a silly argument, I don't want to screw up on that interface, because then I'll have to argue with everybody else about this
<wrtp> niemeyer_: ok...
<wrtp> niemeyer_: so why aren't you suggesting Instance.OpenPort(port) ?
<niemeyer_> Power outage.. on batteries
<wrtp> niemeyer_: crossed fingers
<niemeyer_> wrtp: As I mentioned earlier, it *sounds* to me like the implementation is simpler, given the nature of an Environ is, to have it on its interface
<niemeyer_> wrtp: We're generally talking to the front wall
<niemeyer_> wrtp: I definitely wouldn't have a strong argument against Instance.OpenPort, though
<wrtp> niemeyer_: say we had a new provider that *did* associate ports directly with instances, our implementation could break, i think.
 * TheMue 's wife calls for lunchtime, but thankfully I've catched up the discussion until here. It's very helpful.
<wrtp> niemeyer_: well, in fact, your suggested interface makes that not easy, i think
<wrtp> niemeyer_: because the provider would have to maintain its own mapping from machine id to instance id
<niemeyer_> wrtp: Yes
<niemeyer_> TheMue: Have a good one
<wrtp> niemeyer_: it would be nice to be able to adjust the open ports for a machine *before* calling StartInstance
<niemeyer_> wrtp: The provisioner worker can certainly do that
<niemeyer_> Shit.. no break started to beep
<niemeyer_> UPS, that is
<wrtp> niemeyer_: eek
<wrtp> hmm, dubious looking test failure:
<wrtp> runtime: signal received on thread not created by Go.
<wrtp> FAIL	launchpad.net/juju-core/state	8.222s
<TheMue> iiihks
<wrtp> TheMue: i can't reproduce it, sadly
<TheMue> wrtp: there are two cgos: goyaml and gozk. maybe in there
<wrtp> i also got a store test failure:
<wrtp> server_test.go:63:
<wrtp>     s.checkCounterSum(c, []string{"charm-info", curl.Series, curl.Name}, false, 1)
<wrtp> server_test.go:83:
<wrtp>     c.Errorf("counter sum for %#v is %d, want %d", key, sum, expected)
<wrtp> ... Error: counter sum for []string{"charm-info", "oneiric", "wordpress"} is 0, want 1
<wrtp> which also succeeded when i tried it again
<wrtp> :-(
<TheMue> Doesn't sound good.
<wrtp> TheMue: just ran all the tests again and they all worked :-(
<TheMue> wrtp: Monitored your memory, maybe a hanging process
<TheMue> ?
<wrtp> TheMue: i don't *think* so.
<Aram> wrtp: also seen that failure.
<Aram> in gozk, I recall.
<Aram> hopefully it'll go away as we move away from Zk and cgo.
<wrtp> Aram: +1
<niemeyer> wrtp, Aram, TheMue, fwereade_: I'll attend that MongoDB conference in SÃ£o Paulo tomorrow, and will be heading there this afternoon
<fwereade_> niemeyer, cool, have fun
<niemeyer> fwereade_: Thanks!
<wrtp> niemeyer: ok, have a good one
<Aram> niemeyer: have a good one, will you give a talk?
<niemeyer> Aram: Yeah
<wrtp> niemeyer: did you manage to get your demo thing working?
<wrtp> niemeyer: with the X million documents...
<niemeyer> wrtp: It's working, but still requires a few last minute fixes
<niemeyer> wrtp: and I need slides too
<wrtp> niemeyer: minor trivialities :-)
<niemeyer> Planning on doing that on the trip today.. not smart, but the week was rushy
<wrtp> niemeyer: i hope your laptop battery is working again
<niemeyer> wrtp: Yeah, thankfully I got a new one in SF
<TheMue> niemeyer: Will your slides later be at SlideShare?
<niemeyer> wrtp: It's great to have a laptop again rather than a mobile desktop :-)
<niemeyer> TheMue: I'll surely put them up somewhere
<wrtp> niemeyer: how much did you end up paying?
<TheMue> niemeyer: Great, appreciate it.
<niemeyer> wrtp: Just under 100 USD IIRC
<wrtp> niemeyer: that's loads better than the UK price.
<niemeyer> wrtp: Yeah, it was really a lot cheaper
<niemeyer> wrtp: and with the Prime thing, good delivery in a couple of days for free
<niemeyer> hazmat: I don't have the slides up yet, but I can surely put them up somewhere if you'd like to use them
<wrtp> niemeyer: initial dummy implementation of port opening, if you have time to have a look: https://codereview.appspot.com/6349097/
<wrtp> fwereade_: ^
<niemeyer> wrtp: Didn't we just agree to do it with *Instance?
<wrtp> [12:34:31] <niemeyer_> wrtp: I definitely wouldn't have a strong argument against Instance.OpenPort, though
<wrtp> i thought that meant you'd prefer it to be on machine id
<niemeyer> wrtp: OpenPorts(machineId int
<hazmat> niemeyer, that would be great
<niemeyer> wrtp: That's not instance.OpenPort at all
<niemeyer> hazmat: COol, will do
<wrtp> niemeyer: indeed, it sounded like you'd prefer for it *not* to be Instance.OpenPort
<wrtp> [12:33:54] <niemeyer_> wrtp: As I mentioned earlier, it *sounds* to me like the implementation is simpler, given the nature of an Environ is, to have it on its interface
<niemeyer> wrtp: Yes, I'd prefer for it to be Environ.OpenPort indeed.. environ.OpenPort(inst, ports)
<wrtp> niemeyer: huh? if it's just a method that takes an instance as argument, why not just have it as a method on that instance?
<niemeyer> wrtp: LOL
<niemeyer> <wrtp> [12:34:31] <niemeyer_> wrtp: I definitely wouldn't have a strong argument against Instance.OpenPort, though
<TheMue> funny
<wrtp> niemeyer: if it's environ.OpenPort, i think it should take a machine id. if it takes an instance, then i think it should be an instance method.
<niemeyer> wrtp: Those two things are completely unrelated
 * TheMue would like Instance.OpenPorts(ports) or Environ.OpenPorts(instanceId, ports)
<niemeyer>         StopInstances([]Instance) error
<niemeyer>         Destroy(insts []Instance) error
<niemeyer> etc
<TheMue> ah
<TheMue> wrtp: Yep, then Environ.OpenPorts(instance, ports)
<wrtp> niemeyer: [12:28:38] <niemeyer_> environ.OpenPort(machineId) is so much better than [...] environ.OpenPort(instance)
<wrtp> niemeyer: those are only like that because they take multiple instances
<wrtp> niemeyer: if you could only stop a single instance at a time, i'd have done Stop()
<niemeyer> wrtp: Heh
<niemeyer> wrtp: You're doing the journalistic thing of quoting part of a sentence and inverting its meaning
<niemeyer> Jul 12 08:28:30 <niemeyer_>     wrtp: Sorry, you won't convince me that
<niemeyer> Jul 12 08:28:37 <niemeyer_>     environ.OpenPort(machineId)
<niemeyer> Jul 12 08:28:48 <niemeyer_>     is so much better than
<wrtp> niemeyer: i think i must have understood the wrong meaning to start with!
<niemeyer> Jul 12 08:29:00 <niemeyer_>     id, err := machine.InstanceId()
<niemeyer> Jul 12 08:29:07 <niemeyer_>     environ.OpenPort(instance)
<niemeyer> wrtp: That's what I said.
<wrtp> i don't see the connection between the last two lines
<niemeyer> wrtp: Doesn't matter.. it's still not ok to invert the meaning of what I said
<wrtp> niemeyer: that wasn't my intention, honest!
<wrtp> niemeyer: you seemed to like OpenPort taking a machine id
<wrtp> niemeyer: rather than an instance id
<wrtp> niemeyer: so that's what i implemented
<niemeyer> wrtp: Okay, so let's try to agree on things rather than manipulating quotes
<niemeyer> wrtp: The environment deals with instances
<wrtp> niemeyer: do you like "environ.OpenPort(machineId)" or not?
<niemeyer> wrtp: not machines
<niemeyer> wrtp: Giving an environment a machine id for it to figure which instance is associated with is wrong
<niemeyer> wrtp: Forget the implementation of EC2.. we're designing the API
<wrtp> niemeyer: ok, so i totally don't understand what you meant by that sentence above...
<niemeyer> wrtp: Forget it
<wrtp> niemeyer: done
<wrtp> niemeyer: i'll put OpenPort as a method on Instance as i'd first intended, ages ago
<niemeyer> wrtp: Let's try to understand each other rather than quotes from the past
<TheMue> wrtp: To keep the environment consistent it should handle with instances, no machine ids.
<niemeyer> wrtp: That sounds fine
<niemeyer> wrtp: and elegant in fact
 * TheMue likes a consistent interface (not in the sense of a go interface)
<wrtp> niemeyer: the very first cut at environs/interface.go had it that way :-)
<wrtp> niemeyer: it's not *quite* so easy for the firewaller to mock though.
<niemeyer> wrtp: If the firewaller has a machine, it can query the instance from the environment and use it
<wrtp> niemeyer: sure, it's not hard. in fact, if it just uses the dummy environ for tests, it might be trivial.
<wrtp> niemeyer: oh, there's a problem
<wrtp> niemeyer: currently i can't find the machine id from the instance
<niemeyer> wrtp: Okay, I was waiting for that.. let's see if it's what I think
<niemeyer> wrtp: Yeah, bingo
<wrtp> niemeyer: i *can* do it, of course
<wrtp> niemeyer: by querying the security groups for the instance
<niemeyer> wrtp: We can definitely have a parameter of machineId in the instance to make the implementation simpler
<niemeyer> Sorry
<niemeyer> wrtp: We can definitely have a parameter of machineId in the instance method to make the implementation simpler
<wrtp> niemeyer: in which method, sorry?
<niemeyer> wrtp: Instance.OpenPort
<wrtp> niemeyer: i guess
<TheMue> niemeyer: So Instance.OpenPorts(machineId, ports)?
<niemeyer> wrtp: We're arriving in the same design we have in Python
<wrtp> TheMue: yeah
<niemeyer> wrtp: Except the method is on Instance
<TheMue> niemeyer: Indeed
<niemeyer> Which sounds fine
<TheMue> Ah, Mark is there
<wrtp> niemeyer, TheMue: here's what i've got currently
<wrtp> http://paste.ubuntu.com/1088025/
<niemeyer> wrtp: Cool.. I'd still prefer to not have machineId there, but that'd be unnecessary purism at this point
<niemeyer> wrtp: s/should/must/
<niemeyer> wrtp: Otherwise, +1 to move forward with it
<wrtp> niemeyer: i think that in dummy, i'll put the port map inside the instance, just to keep us honest.
<wrtp> niemeyer: (in the proposal, the port map was in the state, to match ec2's implementation)
<wrtp> niemeyer: does that sound reasonable?
<niemeyer> wrtp: +1
<wrtp> niemeyer, TheMue, fwereade_: hopefully this does the job: https://codereview.appspot.com/6349097/
<TheMue> wrtp: First quick look is fine to me
<wrtp> TheMue: thanks
<fwereade_> wrtp, indeed, looks sensible I think, I'll try to give it a closer look a bit later
<niemeyer> wrtp: LGTM with a point for consideration
<wrtp> niemeyer: if we change that, i should change it all the way through.
<wrtp> niemeyer: the intention was that the ops channel says that an operation is about to happen, not that it *has* happened
<wrtp> niemeyer: thus it's ok to send on the channel outside of the lock
<wrtp> niemeyer: thanks for the review BTW!
<niemeyer> wrtp: I think it's problematic for the reason stated
<niemeyer> wrtp: and we already have operations within the lock elsewhere
<wrtp> niemeyer: yeah, i hadn't noticed that StartInstance sends within the lock.
<wrtp> niemeyer: i was wary of deadlock, but it's probably ok
<niemeyer> wrtp: If we ever face a deadlock, it'd probably be safer to do it afterwards, rather than before
<niemeyer> wrtp: So that waits that get unblocked and act on state find what they exepct
<niemeyer> expect
<wrtp> niemeyer: maybe i should defer the channel send
<wrtp> niemeyer: so that it happens even when there's an error
<niemeyer> wrtp: Well, or just unlock earlier
<wrtp> niemeyer: yeah, that looks ok given that hardly anything actually returns an error.
<niemeyer> wrtp: Yeah, and if it panics we'll know it
<wrtp> niemeyer: the only awkward bit is the "environment is already bootstrapped" error
<wrtp> niemeyer: which will have to duplicate the send
<wrtp> niemeyer: because some tests rely on receiving the operation even though there's an error. perhaps that should change though.
<wrtp> niemeyer: tbh, i'm going to try sending within the lock. it makes the code easier to maintain, and there's no reason it should deadlock.
<niemeyer> wrtp: Sounds good
<niemeyer> Alright guys, lunch time
<niemeyer> I'll head to SÃ£o Paulo after lunhc
<Aram> have fun niemeyer.
<niemeyer> Aram: Cheers!
 * niemeyer leaves.. see you soon
<wrtp> fwereade_: am looking at your "train wreck" BTW
<fwereade_> wrtp, cheers
<wrtp> fwereade_: ping
<fwereade_> wrtp, talk if you wish, but I'm in a meeting, expect slow replies
<wrtp> fwereade_: k
<wrtp> fwereade_: i think that ec2.environProvider.ComposeConfig could be quite a bit simpler
<wrtp> fwereade_: and other bits too, but in general, i think it's really not such a train wreck
<fwereade> wrtp, thanks, good to hear, I'm calling it a day now though :)
<wrtp> fwereade: ok, have a good evening.
<wrtp> fwereade: BTW Embassytown is awesome
#juju-dev 2012-07-13
<wrtp> davecheney: hiya
<wrtp> davecheney: FYI here's a sketch of the possible firewall-management code: http://paste.ubuntu.com/1089246/
<wrtp> davecheney: (we discussed it when you weren't around)
 * davecheney reads wrtp 
<wrtp> davecheney: actually, i realise that i didn't update it for the most recent version of the OpenPorts API: http://paste.ubuntu.com/1089282/
<davecheney> wrtp: on da phone, hang on
<wrtp> davecheney: np
<davecheney> wrtp: that propsal looks good
<wrtp> davecheney: cool
<davecheney> open question, are you, i and frank all trying to eat the same elephant ?
<davecheney> this is simlar to the branch be proposed on wednesday
<wrtp> davecheney: i hope so
<wrtp> davecheney: this was a response to frank's proposal
<davecheney> he was approaching it from the state side, which sort of makes sense because in the py version there is a state.FirewallManager
<wrtp> davecheney: i'm not quite sure why he did it actually, as it's really just part of the PA, but it was useful for focusing all the issues in one place
<wrtp> davecheney: ah!
<davecheney> but it does exactly that, although simpler
<wrtp> davecheney: i hadn't quite got that it was in state
<davecheney> for every machine or unit, it registers a callback (it == firewall manager)
<davecheney> then does (stuff) when that callback fires
<wrtp> davecheney: the main difference is that in the python version, it checks the "real" state every time.
<davecheney> in some ways in twisted it's simpler
<davecheney> in our version we need to start and manage a watcher goroutine
<wrtp> davecheney: whereas this CL keeps track of the state and only issues OpenPort/ClosePort requests at well-defined times
<davecheney> this is the <-serviceChange bit ?
<wrtp> davecheney: yeah. there's only one central goroutine that manages the whole thing
<davecheney> wrtp: here is the problem i see
<wrtp> davecheney: i had difficulty keeping track of all the potential state interactions when there were multiple independent goroutines operating on it.
<davecheney> if we have N port watchers, how do we funnel all those change messages into a single channel ?
<wrtp> davecheney: easy
<wrtp> davecheney: just start a goroutine for each watcher
<davecheney> can we pass a channel to watchPort ?
<davecheney> yup, goroutine that watches the watcher and forwardst he messages (means more tomb.Tombs ..)
<wrtp> davecheney: which prepends some data and sends on a central channel
<wrtp> davecheney: i think we can get away without any more tombs
<davecheney> wrtp: i'd like to try
<davecheney> nothing wrong with tomb
<davecheney> but less of everything is better, when there are going to be a lot of these port watchers
<wrtp> davecheney: the only thing wrong with tomb is that it's more heavyweight than necessary sometimes
<davecheney> wrtp: i have to step out for a few hours, but will be online from ~8/9 my time this evening
<wrtp> davecheney: ok
<wrtp> davecheney: i think that all the mux goroutines can watch the same tomb
<davecheney> wrtp: that would be excellent, because the most likely cause of them wanting to die is the firewaller goroutine exiting
<davecheney> also, http://codereview.appspot.com/6333067/
<davecheney> i imagine this would be a valid chassis for your proposal ?
<wrtp> davecheney: absolutely
<wrtp> davecheney: frank is now working on integrating my sketch with your chassis
<davecheney> wrtp: could I ask for some of your time today to get a run through of that chassis
<wrtp> davecheney: definitely
<davecheney> it doesn't do anyhthing at the moment so the amount of review should be minimal
<davecheney> especially at is a carbon copy of the provisioner
<davecheney> which makes me wonder if some of the dulication can be factored out
<wrtp> davecheney: it looks fine to me at first glance
<davecheney> but that is not important right now
<davecheney> wrtp: just got an email from minux, he sent me a photo out front of building 47 on the google campus with some of the go team
<wrtp> davecheney: cool. link?
<davecheney> i'll forward it
<davecheney> wrtp: in ya gmail
<wrtp> davecheney: rob looks very blues brothers
<wrtp> davecheney: thanks, BTW
<davecheney> wrtp: have a good one, be online later
<wrtp> davecheney: how long?
 * wrtp can't remember time zones!
<wrtp> davecheney: np, just worked it out
<wrtp> davecheney: i'll be around
<wrtp> fwereade_, TheMue: mornin'
<fwereade_> wrtp, TheMue: similarly :)
<fwereade_> wrtp, so, what am I doing in ComposeConfig that I don't need to? :)
<wrtp> fwereade_: i have an idea, but i haven't quite been able to make it work yet
<fwereade_> wrtp, yeah, my experience has been that it's a bit harder than it sounds like it should be ;)
 * fwereade_ looks sadly at this morning's conflicts
<wrtp> fwereade_: here's what i what i'm trying: http://paste.ubuntu.com/1089407/
<fwereade_> wrtp, hmm, interesting
<wrtp> fwereade_: but there's a problem.
<fwereade_> wrtp, I felt that we were doing so much with the maps that the internal types just complicated matters
<wrtp> fwereade_: both the provider config and the config config require fields that have defaults provided by the other.
<wrtp> fwereade_: so the initial config.Compose fails because it hasn't got a default-series
<fwereade_> wrtp, yeah, indeed, it's fiddly
<wrtp> fwereade_: i like the security that the internal type buys us
<wrtp> fwereade_: it doesn't seem right that core after the initial configuration is still type coercing
<wrtp> s/core/code/
<fwereade_> wrtp, agreed, very much so; but converting back and forth between dicts and internal types *all the damn time*, because the composition api needs dicts (or at least divt-backed configs) seems even worse
<wrtp> fwereade_: i'm not sure
<fwereade_> wrtp, and niemeyer seems very convinced that an enviroment config "really is" a map
<wrtp> fwereade_: outside of a provider, yes
<fwereade_> wrtp, I consider that argument to be utterly invalid, it's as much a map as every single other type in the system
<wrtp> fwereade_: inside a provider, it's a known thing
<fwereade_> wrtp, that is a serialization format, surely? just like for every other type in the system that we serialize..?
<wrtp> fwereade_: the difficulty is that it's not just a serialisation format - it's a serialisation that we want to process, rather than just unmarshal.
<TheMue> wrtp, fwereade_ : Oh, sorry, morning from my side too. Just had received my malt #29, a Laphroaig Cask Strength Batch 004 *yummy*
<wrtp> TheMue: don't drink it all this morning!
<TheMue> wrtp: hehe, no, will open it this evening
<fwereade_> wrtp, well, I see no good reason not to just marshal/unmarshal the type as a real type once we know what it is, and to handle *all* the funky processing at user input time
<fwereade_> TheMue, nice
<wrtp> fwereade_: what about secrets?
<wrtp> fwereade_: i.e. how can we marshal the type without some info?
<wrtp> fwereade_: also, SetAttr
<wrtp> fwereade_: we need to be able to set environment attributes, but just marshalling and unmarshalling doesn't easily allow that
<fwereade_> wrtp, I'm not sure I follow your concerns
<fwereade_> wrtp, the secrets thing maybe needs a little bit of rearrangement
<fwereade_> wrtp, but then I've been asked not to think about secrets for now anyway
<fwereade_> wrtp, and the type could surely handle user-defined config files, and env-set command data, in the same way?
<wrtp> fwereade_: part of the cause of the current issues, i think, is the way that concerns about the config are divided between the config package and the provider package
<wrtp> fwereade_: if the provider did it all, i don't think there would be so much of a problem.
<fwereade_> wrtp, wouldn't that just mean that we need to duplicate everything in config across every provider?
<fwereade_> wrtp, I am maybe taking this whole situation a little personally
<fwereade_> wrtp, because the very first thing I did when I joined the team was to unpick the ec2 provider so we could actually use the common bits in orchestra
<fwereade_> wrtp, and it was not easy
<wrtp> fwereade_: of course, you'd need to be careful about consistency across providers, but that's true in any case
<wrtp> fwereade_: i don't think it would mean that we'd need to duplicate everything.
<fwereade_> wrtp, and what I see in go is a wilful refusal to heed the lessons of the python port -- it feels like a deliberate decision was made to replicate a known mistake in the python :/
<wrtp> fwereade_: there would be some duplication, yes, but anything substantial could be factored out and put in the environs package
<wrtp> fwereade_: that's always been the intention
<wrtp> fwereade_: if the providers are in charge, they can choose what shared bits to use from the environs package
<wrtp> fwereade_: (readAuthorizedKeys being one example)
<wrtp> s/the intention/my intention/
<wrtp> s/the environs package/any package we choose to put shared bits in/
<fwereade_> wrtp, I just don't see how it's a good idea from any perspective except the let's-just-hack-it-together-quickly one
<fwereade_> wrtp, which I thought it was our avowed intention to avoid
<wrtp> fwereade_: which code duplication are you particularly thinking of here?
<fwereade_> wrtp, all the bootstrap/could-init stuff, default-series and authorized-keys, things like we discussed yesterday with ports handling on instance start
<fwereade_> wrtp, the prts handling I agree was not well factored in the python
<wrtp> fwereade_: prts?
<fwereade_> wrtp, sorry, ports
<wrtp> ah
<wrtp> fwereade_: it has always been my intention to move environs/ec2/cloudinit.go to environs/cloudinit.go when it's needed
<wrtp> fwereade_: it was designed to be used by any package (hence the "providerType" field)
<wrtp> s/package/provider/
<wrtp> fwereade_: same with readAuthorizedKeys
<fwereade_> wrtp, and so what we end up with is bits of common code mixed in with provider-specific code, and a big nasty surprise waiting for us when we try to actually use them elsewhere
<fwereade_> wrtp, I suspect you are going to say it's ok to duplicate all the structural code (ie doing the right things at the right time) across the providers
<wrtp> fwereade_: i think we end up with providers having a coherent interface and using what is necessary to fulfil that interface
<wrtp> fwereade_: the tests will test that we've got the structural stuff right
<wrtp> fwereade_: and it will all end up nicely clear and understandable, i hope
<fwereade_> wrtp, I hope you're right
<fwereade_> wrtp, IMO you've severely underestimated the subtleties
<wrtp> fwereade_: maybe i have. i put my faith in encapsulation :-)
<fwereade_> wrtp, and duplication :/
<TheMue> wrtp: Did you thought about this way http://paste.ubuntu.com/1089445/ to send all machnine unit changes to the firewaller?
<wrtp> fwereade_: we're guessing about that. yes, there will be code similarities between providers, but i'm hoping there won't be significant duplication
<TheMue> wrtp: So the main loop of the firewaller handles all like you porposed.
<wrtp> TheMue: not quite
<wrtp> TheMue: one mo
<fwereade_> wrtp, sorry, I'm just feeling generally negative about things because, wtf, this whole config saga
<wrtp> fwereade_: i totally understand
<fwereade_> wrtp, honestly I'm thinking it's all sunk costs, fuck it, just use a map throughout
 * wrtp resists, but is perhaps weakening. seems a pity but...
<fwereade_> wrtp, the trouble is this is *another* week pissed up the wall
<wrtp> fwereade_: agreed
<wrtp> fwereade_: let's just do it
<fwereade_> wrtp, "let's return actual configs from State.EnvironConfig"; "sounds good"; for {"ok, I'll give it a go"; "no, not like that"} :/
<wrtp> fwereade_: :-(
<fwereade_> wrtp, and all I wanted to do was to fix state.Initialize so I could fix the high-priority default-series bug that was assigned to me, pulling me away from the unit agent stuff
<wrtp> TheMue: something like this perhaps? http://paste.ubuntu.com/1089457/
<wrtp> fwereade_: yeah, it's gone a bit out of control
<wrtp> TheMue: it's important that the changes on the channel include the information about what the change is about.
<wrtp> TheMue: slightly more accurate: http://paste.ubuntu.com/1089462/
<TheMue> wrtp: ah, thx
<TheMue> wrtp: funnily it will drive the whole stuff into the same complexity direction as before, but with a cleaner interface
<wrtp> TheMue: the important difference is that the state is only managed in one goroutine
<wrtp> TheMue: stuff like that machine loop goroutine is just a conduit - it does nothing active
<wrtp> TheMue: and that, i think, makes everything easier to reason about
<TheMue> wrtp: yip
<wrtp> TheMue: http://www.youtube.com/watch?v=SPPS8vExLmE :-)
<TheMue> wrtp: ;) yip
<Aram> hey.
<wrtp> Aram: yo
<wrtp> fwereade_: ping
<TheMue> Aram: Hi
<wrtp> fwereade_: i know it's way too late, but once i thought of this idea, i had to try it out. it feels much nicer to me, but it might be total crack. http://paste.ubuntu.com/1089617/
<fwereade_> wrtp, thanks -- I'll try to look at it this pm, but cath's away and I'll be with laura :( (well, :) as well, but you know ;))
<wrtp> fwereade_: if you want to declare your train wrecked and you like this idea, i'd be ok to take the flak from here if you like.
<wrtp> fwereade_: ok
<fwereade_> wrtp, it's appreciated, I'll think on it :)
<fwereade_> wrtp, thanks :)
<wrtp> fwereade_: that code passes the dummy tests BTW
<wrtp> fwereade_: although i haven't added a test for default-series
<TheMue> Hmm, starting with useful tests without blowing the whole stuff up isn't simple.
<wrtp> fwereade_, davecheney, TheMue: here's an configuration alternative. it feels quite a bit cleaner to me than env-config-trainwreck. i wonder what you think: https://codereview.appspot.com/6343107/
<wrtp> i *think* it provides as much flexibility as the other, but doesn't require nearly as much messing around with maps
<wrtp> the heart of the proposal is in https://codereview.appspot.com/6343107/diff/1/environs/interface.go
<TheMue> wrtp: Could you enlighten me, what is this "authorized-keys" stuff in config.go?
<wrtp> TheMue: authorized-keys is a standard environment setting across all providers
<wrtp> TheMue: it's also possible to use authorized-keys-path, which gives the name of a file containing the authorized keys
<wrtp> TheMue: the authorized keys are ssh keys
<TheMue> wrtp: per config entry?
<wrtp> TheMue: yeah
<TheMue> wrtp: ok, understand
<wrtp> TheMue: that is, each config entry can have a different set of auth keys
<TheMue> wrtp: How variable is the config scheme?
<wrtp> TheMue: as variable as we want to make it
<TheMue> wrtp: In the sense of "per software version", not in the sense of "how much possibilities this software has", sorry.
<wrtp> TheMue: currently the fields i've put into config.go are a good guess at common functionality
<wrtp> TheMue: i guess we'd want to keep things backwardly compatible
<TheMue> wrtp: ok, otherwise I would use direct yaml or json marshalling of a strcut scheme representing the configuration
<TheMue> wrtp: but if we need this generic approach it't ok
<wrtp> TheMue: we can't do that, because each provider has a different set of attributes
<wrtp> TheMue: config.go is an attempt to factor out some common functionality between providers.
<TheMue> wrtp: so the config types have to be defined per provider. today he also as to know, which configuration variables he retrieves from the config, so it's kinda hard coded
<wrtp> TheMue: only the common functionality is hard coded
<TheMue> wrtp: and the names of variables a provider accesses
<wrtp> TheMue: but each provider knows which attributes it supports, of course
<TheMue> wrtp: that's what I mean, exactly
<wrtp> TheMue: how could the provider get its configuration data otherwise?
<TheMue> wrtp: Kind of ReadConfig(filename, &myTopStruct), internally simply using an unmarshalling of e.g. json
<wrtp> TheMue: but myTopStruct has to hard code the fields names in just the same way
<wrtp> s/fields/field/
<wrtp> TheMue: but also, there are several sections in the file, each with a different provider and a different set of attributes. i don't know how the above could work with that
<TheMue> wrtp: yes, indeed, only the generic part is simpler
<TheMue> wrtp: in both ways we can have runtime errors, yes
<wrtp> TheMue: what would the type of myTopStruct look like?
<TheMue> wrtp: that depends on the provider
<wrtp> TheMue: you don't know the provider before you read the file
<wrtp> TheMue: we're using the schema package to do a similar kind of thing.
<wrtp> TheMue: it doesn't marshal to a struct sadly
<wrtp> s/marshal/unmarshal/
<TheMue> wrtp: ok, I see
<Aram> "<pnielsen> Aram: technically both can modify the struct, but one will be modifying copies, the other one will be modifying the "original""
<Aram> I hate such redundant and pointless "corrections" on IRC.
<Aram> read between the lines!
<TheMue> Aram: *lol*
<rogpeppe> TheMue, Aram, fwereade_: a code review if anyone cares for it: https://codereview.appspot.com/6344113
<rogpeppe> TheMue: it's the implementation of OpenPorts etc that the firewaller code will use
<fwereade_> rogpeppe, I'm very unlikely to get to that, but I really like the approach you took on the config stuff
<rogpeppe> fwereade_: really? cool.
<fwereade_> rogpeppe, I think it has unexamined fiddlinesses (in the review) but it's still going to be way way nicer
<rogpeppe> fwereade_: i felt it was a bit of a last-ditch attempt, but after trying to work with it, i was tending to agree with you about the train wreck
<rogpeppe> fwereade_: ah, a review! you're a lovely man.
<rogpeppe> fwereade_: it definitely needs lots more tests - i didn't want to waste any more time on it if it was a dead end.
<fwereade_> rogpeppe, IMO, s/last-ditch attempt/fantastic diving save/
<rogpeppe> fwereade_: BTW should authorized-keys be optional in general?
<fwereade_> rogpeppe, I think we always need it
<fwereade_> rogpeppe, otherwise we can't connect to state
<rogpeppe> fwereade_: but should the fields be optional?
<rogpeppe> fwereade_: (assuming we can fetch something from $HOME)
<fwereade_> rogpeppe, input-wise, yes, but a Config with empty authorizedKeys should be an error I think
<rogpeppe> fwereade_: agreed
<rogpeppe> fwereade_: ah, and that's why i put authorized-keys everywhere
<rogpeppe> fwereade_: because we can't rely on any being in the testing user's home
<fwereade_> rogpeppe, yeah
<fwereade_> rogpeppe, that has tripped up a fair number of users I know about
<fwereade_> rogpeppe, so, probably, a whole bunch more that never said anything ;)
<rogpeppe> fwereade_: it's awkward to make the dummy provider add a authorized-keys default
<rogpeppe> fwereade_: i wonder if we should set $HOME=/tmp/something in every test suite
<fwereade_> rogpeppe, +1
<fwereade_> rogpeppe, c.MkDir() anyway
<rogpeppe> fwereade_: yeah
<rogpeppe> func init() {os.Setenv("HOME", "/dsvfkdsalewnfcldsakj") } :-)
<fwereade_> haha
<rogpeppe> fwereade_: should default-series be optional?
<rogpeppe> fwereade_: (defaulting to environs.CurrentSeries, if so, presumably)
<fwereade_> rogpeppe, I think that's OK to get from there, yeah
<rogpeppe> fwereade_: "
<rogpeppe> it shouldn't
<rogpeppe> even be possible to look at a Conn's Environ's config, because it is likely to
<rogpeppe> be wrong.
<rogpeppe> "
<rogpeppe> what do you mean by that?
<rogpeppe> i'm off for the weekend.
<rogpeppe> have a great weekend everyone!
#juju-dev 2012-07-14
<fwereade_> rogpeppe, ping
<fwereade_> davecheney, ping
<fwereade_> davecheney, rogpeppe: if either of you is around, this is entirely trivial: https://codereview.appspot.com/6405043
<fwereade_> davecheney, rogpeppe: and I would really appreciate being able to slip it in this w/e
<fwereade_> davecheney, rogpeppe: no behaviour changes at all
<rogpeppe> fwereade_: just a code move?
<rogpeppe> fwereade_: if so, LGTM
<rogpeppe> (i'm not around!)
<fwereade_> rogpeppe, yeah
<fwereade_> rogpeppe, tyvm
#juju-dev 2012-07-15
<fwereade_> ah-HA
<fwereade_> ConfigNode sometimes writes new content when no changes have happened
 * fwereade_ has a satisfied
<Aram> moin.
<fwereade_> Aram, heyhey
#juju-dev 2013-07-08
<wallyworld> davechen1y: hey, as ocr, could you please look at https://codereview.appspot.com/10858043/ and https://codereview.appspot.com/10854043/. With the latter, thumper and I both would like to keep both assignment policies fwiw
<davechen1y> wallyworld: /me looks
<wallyworld> ty
<davechen1y> wallyworld: i take no position on two policies or one
<davechen1y> as you and thumper are the ones doing the work, i think you get final say
<davechen1y> the rest is between you and your maker
<thumper> ta
 * thumper defers continued work, and goes back to land and fix
<thumper> local provider pipeline is currently eight branches
<thumper> although the last one is empty
<thumper> time to bring that down a little.
<thumper> a reason not to use iOS: https://twitter.com/satefan/status/354046461383688193
 * thumper wonders which trusted roots we have in ubuntu
<davechen1y> about 150 at last count
<thumper> holy shit
 * thumper wonders how many are NSA plants
<davechen1y> fucktonnes
<thumper> heh
<davechen1y> prety sure the china post office one is in there
<thumper> haha
 * thumper sighs
<thumper> wow MITM attacks all round
<thumper> https://code.launchpad.net/~thumper/juju-core/move-cert-gen-to-config/+merge/173117/comments/387671  ?!?!
<davechen1y> out of disk space ?
<thumper> dunno, awaiting jam
<thumper> davechen1y: how do I find the OS that we are running on using go?
<davechen1y> runtime.GOOS
<davechen1y> runtime.GOARCH as well
<thumper> ta
<thumper> wallyworld: do we have existing storage smoke tests?
<thumper> somewhere?
<wallyworld> um. maybe in jujucore tests, or individually in each provider. can't recall
<wallyworld> if there are some in jujucore tests, then perhaps none are explicitly needed
<wallyworld> thumper: Testpersistence exists
<wallyworld> i think your provider will be run with that test if you have plugged in the common env tests
<thumper> wallyworld: where is that?
<wallyworld> environs/jujutest/tests.go
<wallyworld> davechen1y: thanks for the review
<davechen1y> wallyworld: don't thank me, i didn't doa  very good job
<wallyworld> davechen1y: with the checkers import, the discussion about it happened after i made the code change
<wallyworld> i left it as is so it could be changed all in one go
<wallyworld> you gave a +1 which is what i needed to unblock, so it was a good job :-)
<wallyworld> thumper: if policy is clean and/or empty and constraint is lxc, and no clean/empty container found, do you think it should create the required new container on an existing instance, or go to the trouble of creating a whole new instance to host the container?
<thumper> wallyworld: that is an interesting question
<wallyworld> and one i need to answer :-)
<wallyworld> me thinks by default it should shive the new container on an existing instance
<wallyworld> and we maybe provide a way to alter that behaviour
<thumper> how would you tell it not to?
<thumper> I think here we are hitting the limit of shit we should care about
<wallyworld> yes
<thumper> and that we should move from there into the world of letting the user decide with their custom deployment script
<wallyworld> i think if the user wants a new instance, they should use that assignment pokicy
<wallyworld> AssignNewMachine
<wallyworld> if they use AssignClean(Empty), it will create a new container if required on an existing instance
<wallyworld> perhaps we can have a max containers per instance setting?
<thumper> that may make sense
<wallyworld> or just rely on hardware characteristics to help us control it
<thumper> can we defined the assignment policy as a deploy time constraint yet?
<wallyworld> if when an instance is "full", don't add more to it
<wallyworld> not yet. soon :-)
<wallyworld> next branch i think
<thumper> yeah, hardware characteristics I think
<thumper> until we add magic++
<wallyworld> i do like the max containers idea though
<wallyworld> we may want to limit it even if hardware allows it
<wallyworld> s/we/users
<wallyworld> thumper: wtf. got all these cannot find package errors from the go bot
<thumper> wallyworld: me too
<wallyworld> :-(
<thumper> wallyworld: waiting for jam
<wallyworld> yep. if he weren't online in a bit, i'd ssh in to have a look
<wallyworld> might be a known issue perhaps
<jam> thumper-afk: fixed
<jam> wallyworld: Hopefully I fixed it. It looks like jujud stopped being able to talk to the master server, and when it came back online, it reinstalled the charm
<wallyworld> ok, will try again, thanks
<dimitern> morning all!
<rvba> jam: Hi, could you please update gwacl in the landing environment? (No backward-incompatible changes have landed.)
<thumper> fwereade: ping
<thumper> fwereade: I'm going to go organise dinner, will check back later
<jam> rvba: sorry about the delay, will do
<rvba> jam: no worries, ta!
<jam> rvba: from r146 => r166
<rvba> jam: great, thanks again.
<jam> hey dimitern, I hope you enjoyed Euro Pycon
<dimitern> jam: hey, yeah it was useful and interesting
<dimitern> jam: and it would've been even better if I didn't try upgrading to saucy and bricked my laptop
<dimitern> jam: had to reinstall raring, and now what mongodb did I need to install - which ppa was it?
<jam> dimitern: I still use the tarball, but there is: https://launchpad.net/~juju/+archive/experimental
<jam> ouch on the Laptop. I'm a bit surprised.
<jam> The quality stuff has generally been a lot better for running beta
<dimitern> jam: thanks
<jam> dimitern: I have quite a few infrastruture-y patches related to API and consumers of the API. I'd be happy to get some feedback and go over them with you.
<dimitern> jam: well, it turned out I choose a really bad time to do it - there were problems with video drivers (i'm using the fglrx proprietary ones) and some mixup with proposed packages breaking unity
<jam> I'm hoping some of them will make new workers easier to bring up.
<dimitern> jam: cool, i'd like to know these
<jam> dimitern: yeah, I use proprietary drivers as well, If you don't need 3D then the "radeon" driver is often pretty stable.
<dimitern> jam: btw - I did add-apt-repository ppa:juju/experimental and now I install mongodb - will it get it from there?
<jam> dimitern: so probably the biggest change is doing a bit more standardizing on NotifyWatcher connected to the API, which can then use a api.NotifyWatcher on the client side, and a worker/NotifyWorker which is designed around workers that trigger based on that watcher.
<dimitern> jam: well the thing is - after the upgrade everything went black - even ttys ctrl+alt+f1 didn't respond
<jam> dimitern: for mongodb, you need to 'apt-get update' frist
<jam> first
<jam> so it sees the new PPA
<jam> then it should, provided the PPA is "newer"
<jam> dimitern: ouch
<dimitern> jam: ok
<dimitern> jam: i'm thinking of continuing with the deployer stuff - i didn't see progress on that
<jam> dimitern: We want to focus on getting one agent fully into the API, which deployer works for that.
<jam> I think deployer is NotifyWatcher based as well.
<jam> (old EntityWatcher)
<jam> dimitern: also, this is particularly trivial, and dfc has LGTM'd it on Launchpad: https://codereview.appspot.com/10871045/
<dimitern> jam: yeah, probably, will take a look
<jam> dimitern: I realize william is in UK, but have you seen him around this morning?
<jam> I wanted to get fwereade's feedback on the basic design I've been doing, to see if it matches what he and I talked about.
<fwereade> jam, dimitern, heyhey
<dimitern> jam: no i haven't
<dimitern> fwereade: hey
<dimitern> fwereade: took the car for a ride on sunday btw :)
<jam> I'm going to restart IRC real quick, as notifications aren't working. bbiab
<fwereade> dimitern, cool, thanks
<jam> fwereade: I trust the wedding was beautiful and your weather is pleasant?
<fwereade> jam, it indeed was, and... yeah, the weather's still ok too :) that's nice
<fwereade> jam, sorry, hadn't looked
<jam> fwereade: so probably the big one as far as design goes is: https://codereview.appspot.com/10978043/
<jam> which is creating a NotifyWorker structure
<jam> to match the NotifyWatcher
<fwereade> jam, cool, I'm just going through https://codereview.appspot.com/10939043/ now
<jam> fwereade: great. Certainly needed before the other one.
<jam> I did end up consuming the initial event in the API Server, and then triggering a local event in the client Watcher
<TheMue> jam: just reviewing it
<TheMue> jam: already seen the usage inside the cleaner and i lie it
<jam> TheMue: thanks. I'm quite happy with how it shaped up.
<jam> The workers had a lot of "interact with the system" logic tied up with "do my actual work", and I'm hoping this decouples it nicely.
<jam> fwereade: by the way, you still have https://code.launchpad.net/~fwereade/juju-core/errors-cleanup/+merge/168928 sitting around. Is it bitrotten/landed in trunk but not in "old trunk", ?
<dimitern> jam: so now (3.5h from now) is the combined blue+core standup, right?
<fwereade> jam, that branch is somewhat bitrotten I'm afraid :/
<jam> dimitern: my clock says 2.5 hours
<dimitern> jam: oh, right, yes
<jam> mgz: also, just a quick status check on https://code.launchpad.net/~danilo/juju-core/python-env-fails/+merge/171997
<jam> ISTR it was failing while running on the bot (lovely hangs causing 600+s timeouts.
<TheMue> jam: you've got a review for the 10978043
<jam> TheMue: thanks
<dimitern> guys, i'm getting multiple test failures on trunk - http://paste.ubuntu.com/5854870/
<thumper> dimitern: have you updated gwacl?
<thumper> i think it had work recently
<dimitern> thumper: yes, all of the 3rd parties
<jam> thumper: they just had me update it on the bot today, but the compat one was a while ago.
<jam> dimitern: "Bad record MAC" is what happens when you use a packaged mongo, IIRC.
<jam> You can try putting the tarball mongo in your path, and see if that fixes it.
<dimitern> i had to reinstall raring after a failed upgrade to saucy (but /home was unaffected), so I may still need some packages installed (I already installed what was obvious, like git, mongodb from the ppa)
<jam> dimitern: the env is already bootstrapped is a follow-on failure because the previous test didn't clean itself up.
<dimitern> jam: I did add the ppa, then update, then install mongodb, but it sill got the wrong one (the one in the archive is 2.2.4, which is newer than the ppa one - 2.2.3+ssl2)
<dimitern> ha it seems I didn't manage to uninstall the 2.2.4 mongo properly
<dimitern> how can I install the ppa version of mongo? it has the same name, different version
<jam> dimitern: there is some way to force it something like "apt-get install mongodb==2.2.3+ssl2" but I'm not 100% sure on that bit.
<dimitern> jam: hmm apt-get is too strict, I had to specify it as sudo apt-get install 'mongodb=1:2.2.3-0ubuntu2+ssl2'
<jam> fwereade: A Watch call returns the initial event.... Is a bit confusing when an event doesn't have any actual content. To *me* the fact that we are doing "out := w.out" in the loop means we are generating an event locally which wasn't explicitly sent from remote.
<fwereade> jam, I think the viewpoints are basically equivalent
<fwereade> jam, I see it as "empty event sent, nothing actually regenerated"
<fwereade> jam, but it's academic really
<jam> fwereade: you're right that it makes more sense on watchers that actually transmit content, as you would have a field and have to save the content for a while until someone polled for it.
<jam> (the Result object has to hold that state, which gets cached a bit on the client Watcher object until it can get rid of it with the out <- content statement.
<fwereade> jam, yeah, the only reason I'm pushing that viewpoint is to make the similarity clear
<jam> fwereade: I tweaked the comments. Now who can we get to follow up review it ? :)
<fwereade> jam, dimitern's back :)
<jam> dimitern: https://codereview.appspot.com/10939043/ looks more imposing than I think it really is. It moves some code around so that we can pull out Watcher
<jam> as an API object
<dimitern> jam: will look once I resolve my issue with mongo - it seems the ppa doesn't have amd64 deb for raring (only - other series have both i386 and am64 available) - there is an option to retry the build on LP, but it says it'll destroy history etc. - should I do it? wish davecheney was around to ask
<jam> dimitern: go ahead and retry, it kills the failure log, etc. But since it failed to build, I think we can just retryi it.
<jam> nobody is actively debugging the failure
<jam> it is claimed it was "Cancelled Build"
<jam> dimitern: it is a bit concerning that it took "Finished on 2013-04-19                    (took 2 days, 13 hours, 40 minutes, 24.0 seconds)"
<dimitern> jam: scheduled for retry in 16 minutes
<jam> and was cancelled.
<jam> so there may be an explicit problem with that build
<dimitern> jam: probably wasn't "finished" but canceled instead
<jam> dimitern: right. I just mean it sat in the building state for 2 days before someone had to manually notice and cancell it.
<jam> We should try to keep an eye on it.
<dimitern> jam: yeah
<dimitern> jam: will look at your branch now, while waiting
<dimitern> jam: ah, it's william's actually
<dimitern> jam: ah, no - the sidebar or rietveld is confusing sometimes
<dimitern> jam: reviewed
<jam> TheMue: fwereade: I've responded to both of your feedback on https://codereview.appspot.com/10978043/
<dimitern> jam: i'll take a look at that as well
<dimitern> (while still waiting for the mongodb build)
<jam> fwereade: for 'tools' package. I would be fine calling the top level thing 'agent'. The key bits I care about are:
<jam> a) it is environ agnostic
<jam> b) it hides more of the details from callers, so they don't have to track something like 'dataDir'.
<jam> dimitern: to quote William, "EnvironConfigWatcher should never have been implemented"
<jam> it exposes too many secrets
<jam> that shouldn't be exposed in the API
<jam> things might to think about stuff that is *in* the environ config
<jam> but they shouldn't get the whole thing out. (AIUI)
<dimitern> jam: ah, i see
<fwereade> jam, responded
<fwereade> jam, and I'm +1 on your (a) and (b), I absolutely think it's a good change
<fwereade> jam, just quibbling about package placement
<fwereade> jam, dimitern: so, on thursday I tried about 3 times to impose some consistency on the params package and every time it felt like it was running away with me
<jam> fwereade: :)
<fwereade> jam, dimitern: but I'm going to try again today
<dimitern> fwereade: +1
<fwereade> jam, dimitern: and if it ends up a huge ugly conflicty change I can at least get it in front of you for sanity checking
<dimitern> fwereade: sgtm
<fwereade> jam, dimitern: and if I do it ~right then I hope we'll be able to share stuff like the underlying code for machiner.Life and deployer.Life (and for more facades in the future)
<fwereade> dimitern, since you weren't there, one important bit I thought I should run by you is...
<fwereade> dimitern, ...implementing the API in terms of Tag where possible rather than name/id/whatever's relevant to the particular entity
<fwereade> dimitern, is there anything obviously stupid about that?
<dimitern> fwereade: well, it has advantages, but the main thing is we'll need to slightly modify the code that uses the api to accomodate that - not terribly high a price though
<fwereade> dimitern, there's enough dancing back and forth between id and tag in jujud already that I think it might work out a win in the end
<fwereade> dimitern, it's more crap over the wire that we don't really need though
<dimitern> fwereade: and it's still not too late to impose this api-wide change i think
<fwereade> dimitern, yeah, and there STM to be a bunch of things api-wide that don't really look consistent, and I'd like to force a bit of that before we fossilize
<dimitern> fwereade: sounds good
<dimitern> fwereade: what happened with the magical bulk ops at the rpc layer?
<fwereade> dimitern, when rog proposed those I rejected them because it forced domain-object-style at the rpc layer
<dimitern> fwereade: are we still doing the bulk ops as originally agreed: array-of-structs as args, arrays-of-structs as results (incl. errors and results at the same place)?
<fwereade> dimitern, yes, I think so
<fwereade> dimitern, haven't seen any controversy there
<dimitern> fwereade: cool!
<jam> fwereade: well I'm on board with it, and rogpeppe is on vacation :)
<jam> fwereade, dimitern: I would clarify that it is a struct-of-array-of-structs as args and struct-of-array-of-structs as results.
<jam> So it is ApiFunction(args params.Type) (params.ResultType, error)
<jam> not
<dimitern> jam: yes
<jam> ApiFunction(args []params.Type) ([]params.ResultType, error)
<dimitern> jam: of course
<jam> dimitern: well, there have been times when wrapping the array in a struct seemed silly
<jam> but fwereade and I discussed it and it does make sense.
<jam> Since it gives us nice wiggle room if we want to extend the api at all.
<dimitern> jam: and in addition, the rpc layer supports that only - you cannot have (args []type) as it is now
<dimitern> jam: please wait for my review before landing https://codereview.appspot.com/10978043/
 * fwereade bbiab
<jam> dimitern: I responded to https://codereview.appspot.com/10939043/
<jam> I'll do fwereade's requests and then wait for your review.
<dimitern> jam: cheers!
<dimitern> jam: reviewed
<jtv> Reviewers needed, hopefully for a "trivial" vote: https://codereview.appspot.com/10858049
<dimitern> jtv: looking
<jtv> thanks
<dimitern> jtv: LGTM, trivial
<dimitern> jtv: make simplify does that? seems pretty smart :)
<jtv> Thanks dimitern, for your vote and your compliment.  :)
<jtv> It's not particularly smart, but it does free you from the distraction.
<dimitern> jtv: i might give it a go
<jtv> Do it regularly.  :)  It won't find much, but that makes it all the easier.
<dimitern> jtv: are you familiar with lp-propose and lp-submit aaron did?
<jtv> Or "make format" for a regular formatting run.  We may choose to integrate them.
<jtv> Yes, I used to use those... but it's been a while.
<dimitern> jtv: there was a talk in oakland that these two now support rietveld as well, so can be used instead of lbox
<dimitern> jtv: which i'd acclaim
<jtv> A step in the right direction, yes...  It may save us some work on the Tarmac integration.
<jtv> Also, I haven't seen those bzr plugins ignore errors like I have lbox.  :)
<dimitern> jtv: exactly, and better integration with LP
<jam> fwereade, dimitern: Is this actually better? https://codereview.appspot.com/10858049/patch/1/1003
<jam> double nesting of brackets tends to be more confusing for me.
<jam> I guess it is more apparent when they are on separate lines.
<dimitern> jam: i think so yes - no need to repeat the type when the slice has it explicitly anyway
<fwereade> jam, yeah, +1
<jam> dimitern: responded
<jam> I think that means enough LGTMs for both api-watchers and notify-worker to land
<dimitern> jam: thanks
<dimitern> mongodb in the ppa for raring/amd64 built successfully
<jam> dimitern: nice... now will it pass the test suite.
<dimitern> jam: hopefully - trying now :)
<jam> dimitern: standup in 10 min, just in case the clock sync wasn't working.
<dimitern> jam: yep, will be there - hangout from the link in the calendar, right?
<jam> yep
<jam> making a coffee myself, should be there on time, thougd.
<jam> though
<jam> fwereade: re: "tools" as a package. I'm happy to have the ToolsManager as an interface in an agent package. The big concern is having it outside of "environs/". Do you feel it is better just to move environs/agent to a top level package?
<fwereade> jam, +100
<jam> fwereade: also, now that my queue has been flushed, I'm reminded of the patch I'm having trouble with.
<fwereade> jam, oh yes?
<jam> specifically, trying to test the client side of an Upgrader.WatchAPIVersion()
<jam> afaict, I'm setting up the test identically to the one on the server-side of the api, and the state side
<jam> but afaict the lowest level watcher isn't firing
<jam> (the one with the actual watch on the DB)
<fwereade> jam, is it possible you're using a different *state.State, and so not seeing the effect of a sync?
<fwereade> jam, what if you set the timeout to 6s?
<jam> mgz: poke
<jam> fwereade: I thought JujuConnSuite shares the state
<jam> between the two sides
<jam> I'll have to look into that
<jam> because yes, after 5s the test passes.
<jam> mgz: In case you're just not seeing it: https://plus.google.com/hangouts/_/f497381ca4d154890227b3b35a85a985b894b471
<TheMue> mramm: ping
<mramm> TheMue: pong
<dimitern> i think this might be an actual bug: http://paste.ubuntu.com/5855203/ (i updated goamz and there were changes)
<TheMue> mramm: Germanys interest in Juju grows. I've been asked if I want to talk at the http://webtechcon.de (German) about Juju
<TheMue> mramm: and maybe also write about it in one of the magazines of the publisher behind this conference
<dimitern> installed mongo 2.2.0 from the tarball, as specified in the readme and all other tests pass
<mramm> cool
<mramm> TheMue: sounds awesome
<TheMue> mramm: yep, cloud and devops is a trending topic
<TheMue> mramm: so we'll see how we can get our part of this cake :D
<dimitern> also, anybody seen this? 2013-07-08 12:03:21 WARNING juju.environs.config config.go:429 unknown config field "future"
<TheMue> dimitern: so far not seen, can you isolate the test?
<dimitern> TheMue: trying now
<dimitern> it seems to be related to danilos branch about py-juju and juju-core compatibility checks about the environment config
<jam> dimitern: I've seen a fair number of WARNINGs while the test suite is running. nothing that fails the suite, though.
<dimitern> jam: all these warnings are valid, but I think we need to be able to suppress them for tests
<dimitern> jam: the tests themselves are about checking unknown keys
<jam> dimitern: agreed, I don't think the test suite should put stuff onto stdout/stderr
<dimitern> aha! found it
<dimitern> wallyworld: changed goamz in r37 to support EC2_ env vars as fallbacks for AWS_ ones, and the test sets both AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY to "", but does not set the fallbacks
<dimitern> and i have both set because of openstack tests
<dimitern> i'll file a bug and propose a fix
<fwereade> dimitern, whoops, "future" was my branch
<fwereade> dimitern, didn't realise it pooed to stderr
<dimitern> fwereade: it does only when there's a failure
<dimitern> fwereade: or when you run with -gocheck.v actually
<dimitern> jtv: ping
<jam> dimitern: wrt https://code.launchpad.net/~dimitern/juju-core/062-fix-bug-1198936/+merge/173486
<jam> Do we need to update other bits of the test suite infrastructure?
<jam> Or do we clear those out elsewhere already?
<dimitern> jam: well, this is the only test that uses this behavior that i can see - all the others pass
<dimitern> i'm having issues with lbox now.. panics on "redirect blocked" after login to rietveld. I had a patch that fixed this, but alas after the reinstall got lost
<jam> dimitern: I thought that was one of wallyworld's patches to lbox ?
<jam> might also be a go version.
<dimitern> jam: it's a go version issue definitely, still using 1.0.3, but I might need to switch to 1.1.1 just to build lbox
<jam> dimitern: I'm using go 1.0.3 for lbox
<dimitern> jam: haven't seen any patches by wallyworld to lbox in the commit log
<jam> dimitern: it didn't land, but he had proposed it, IIRC
<jam> dimitern: most likely it was a patch to goetveld
<jam> dimitern: https://code.launchpad.net/~wallyworld/goetveld/auth-cookie-fix perhaps?
<jam> but that one is merged, so maybe not.
<dimitern> jam: i'll just re-get lbox and its reqs to see if it solves it
<jam> fwereade: worker/resumer/resumer.go . Is it worth implementing time.After as a watcher so that it can re-use the NotifyWatcher code? time.After can make a pretty trivial NotifyWatcher if we want to go that route.
<jam> though it is arguably the same amount of code we would be saving
<jam> fwereade: http://bazaar.launchpad.net/~jameinel/juju-core/upgrader-api-client-watcher/revision/1400# is my answer to make testing not have to wait 5s for the Sync to occur.
<jam> It exposes a helper on DummyEnviron that allows you to trigger e.state.apiState.Sync()
<jam> which is then exposed to JujuConnSuite.
<jam> fwereade: is it terrible to do?
<jam> I felt it was slightly better than giving you raw access to e.state.apiState object.
<jam> (you can click on expand all)
<jtv> dimitern: what's up?
<fwereade> jam, sorry, back from lunch
<dimitern> jtv: can you send me the patch I gave you for lbox to fix the error I got (you got it too)
<jam> fwereade: no rush, I'm done for tonight.
<jtv> dimitern: where is it?
<dimitern> jtv: i think if you do bzr diff in $GOPATH/src/launchpad.net/lbox/ you should see it (if you haven't committed)
<fwereade> jam, offhand it's no worse than anything else in the dummy environ ;p
<fwereade> jam, and at least it's in the service of saner testing :)
<jtv> dimitern: no diff... I'm on r57, last committer is Roger.  Not sure what patch you're talking about.
<dimitern> jtv: maybe geotveld then?
<dimitern> geotveld
<jtv> goetveld
<dimitern> yep
<jtv> Never messed with that
<jtv> dimitern: is this a conversation you had with someone else maybe?
<dimitern> jtv: what go version are you using?
<dimitern> jtv: could be, it was some months ago
<jtv> dimitern: go 1.0.2 .
<dimitern> jtv: I see
<dimitern> mramm: can you send me the kanban link please?
<dimitern> (for the hangout)
<dimitern> TheMue: or you? ^^
<dimitern> fwereade: ^^ ?
<dimitern> are we doing the kanban meeting now?
<TheMue> dimitern: no kanban now
<TheMue> dimitern: only the one at 1:30pm
<dimitern> TheMue: ah, ok, thanks
<TheMue> dimitern: we've consolidated it ;)
<dimitern> TheMue: nice! about time :)
<TheMue> dimitern: yep, I like it too
<dimitern> https://codereview.appspot.com/11002043
<dimitern> so I managed to fix my broken lbox by compiling it under 1.1.1
<dimitern> jam: can you please LGTM it in rietveld now? sorry for the trouble
<dimitern> TheMue: can you take a look as well ? ^^
<TheMue> dimitern: sure
<TheMue> dimitern: lgtm
<dimitern> TheMue: thanks
<mramm> Hey, I just wanted to point out an e-mail thread that needs a response: Chris.Frantz is trying to get juju working
<mramm> https://bugs.launchpad.net/juju-core/+bug/1178328
<_mup_> Bug #1178328: error: cannot log in to admin database: auth fails <ui> <juju-core:Incomplete> <https://launchpad.net/bugs/1178328>
<ackk> hi, counld anyone please have a look at https://code.launchpad.net/~ack/juju-core/uuid-in-environment-info/+merge/173485 ? it's a pretty trivial change
<fwereade> ackk, reviewed, LGTM; dimitern, would you take a quick look please?
<ackk> fwereade, thanks!
<fwereade> ackk, just hold off until there's a second review, then set commit message and approve (or ping one of us if you can't)
<ackk> fwereade, cool, thanks, will it be merged automatically?
<fwereade> ackk, yeah
<dimitern> fwereade: looking
<dimitern> ackk, fwereade: reviewed
<ackk> dimitern, thanks
<ackk> dimitern, fwereade I can't set "approved", could you please do it?
<dimitern> ackk: will do
<fwereade> ackk, done
<dimitern> :)
<ackk> tnx
<dimitern> ackk: have you tried running the full test suite before proposing that change?
<dimitern> ackk: i mean like "go build ./... && go test ./..." in juju-core/ ?
<ackk> dimitern, oh I think I ran a different command, let me try to reproduce the failure
<dimitern> ackk: it was a temporary failure, it's merged now once I reapproved it
<dimitern> anyone willing to look at a really trivial review? https://codereview.appspot.com/10858050/
<mgz> will have a look dimitern
<dimitern> mgz: hey, cheers
<fwereade> dimitern, LGTM
<dimitern> fwereade: cheers, landing then
<ackk> dimitern, thanks
<ackk> dimitern, I got the same error in trunk before the merge, fwiw
<dimitern> ackk: we have occasionally these intermittent test failures - if you happen across one of them after running the full tests multiple times and it occurs more than once, please file a bug and tag it as "intermittent-failure" (but search first if it's already reported)
<ackk> dimitern, ok
<Beret> hmm
<ahasenack> how does juju-core find the bootstrap node ip? I have a case where it has two ips, and juju status is trying to connect to the "wrong" one
<ahasenack> nova list lists the bootstrap node running, and with an IP in each network. I don't see a way to control which IP juju will use
<ahasenack> pyjuju seems to pick the correct one (could be luck)
<mgz> ahasenack: possibly bug 1188126?
<_mup_> Bug #1188126: Juju unable to interact consistently with OpenStack/Quantum deployment where tenant has multiple networks configured <juju:New> <juju-core:Triaged> <https://launchpad.net/bugs/1188126>
<ahasenack> mgz: looks like it, even though no quantum is being used in this case
<mgz> probably not then
<mgz> similar issue though, currently juju-core is pretty network ignorant
<ahasenack> mgz: I think I found it in the code
<ahasenack> state/api/apiclient.go
<ahasenack> func Open(info *Info, opts DialOpts) (*State, error) {
<ahasenack>     // TODO Select a random address from info.Addrs
<ahasenack>     // and only fail when we've tried all the addresses.
<ahasenack>     // TODO what does "origin" really mean, and is localhost always ok?
<ahasenack>     cfg, err := websocket.NewConfig("wss://"+info.Addrs[0]+"/", "http://localhost/")
<ahasenack> it's always the first address that it picks
<thumper> morning
<ahasenack> good morning
<thumper> fwereade: you up?
<fwereade> thumper, heyhey, more or less
<fwereade> thumper, how's it going?
<thumper> just clearing lots of email :)
<utlemming> wallyworld: what is the noun for changing the simplestream location in the Juju yaml?
<wallyworld_> utlemming: is this for an openstack deployment?
<utlemming> wallyworld_: yes, I want to test a merge of HP and EC2 simple streams
<utlemming> wallyworld_: i.e. start publishing the simple streams for HP
<wallyworld_> utlemming: for openstack, if you want custom simplestreams metadata, you put the json files in a directory "streams/v1/index" off the public bucket
<wallyworld_> the public bucket is specified using the "public-bucket-url" config key
<wallyworld_> so where the tools tarballs are, add the "streams/v1/index" container under that location
<arosales> wallyworld_, fyi utlemming is working on the "official" simple streams for HP.
<wallyworld_> \o/
<arosales> wallyworld_, utlemming builds the Ubuntu cloud images we put on certified public clouds
<wallyworld_> arosales: will that include the new tools metdata?
<utlemming> wallyworld_, arosales: looks like I still have a bug to shake out, though
<arosales> utlemming, and wallyworld_ is working on the simple stream implementation in Juju :-)
<arosales> hopefully that helps with introductions :-)
<utlemming> wallworld_: my beta index is http://people.canonical.com/~ben if you're interested
 * wallyworld_ is interested
<arosales> wallyworld_, I don't think that index has the tools in it yet
<arosales> wallyworld_, but I think it could if you and utlemming sync up
<wallyworld_> arosales: ok. i'm keen to progress that bit. scott was away last week so it's stalled till he gets back
<arosales> utlemming, actually if you include the tools in your index we could test out your index file by a simple juju environment yaml update
<arosales> utlemming, is your man then :-)
<arosales> utlemming, also works closely with smoser
<wallyworld_> arosales: utlemming: we had sort of decided to have potentially separate urls for the tools and image metadata. so two separate index files
<wallyworld_> the tools and image metadata index files will likely live in the same place but don't have to
<arosales> wallyworld_, would you have another env yaml file for each index?
<arosales> ie public-bucket-url?
<wallyworld_> arosales: no, potentially a separate config key
<wallyworld_> yes
<arosales> so perhaps public-bucket-cloud-url and public-bucket-tool-url ?
<arosales> or something like that?
<wallyworld_> yes, something like that
<wallyworld_> arosales: for CPC, it will just be the same location for both i *think*
<wallyworld_> but having separate urls allows different folks to maintain the tools and image metadata if required
<arosales> it could very well live at the same location, but juju would need to find two different index files at that location, correct?
<wallyworld_> yes
<arosales> ok
<wallyworld_> arosales: are you ok with that approach?
<arosales> wallyworld_, that seems like a sane approach. Did you envision CPC data living at http://cloud-images.ubuntu.com/
<arosales> utlemming, sound ok to you ^
<arosales> wallyworld_, but generally a +1 from me on having two streams for tools and image data
<wallyworld_> arosales: i thuink the image metadata would go there but smoser envisisaged the tools metadata living in a charms related url now that i think about it
<arosales> having the flexibility for that to be the same URL or different ones only seems like a value add plus too
<wallyworld_> arosales: utlemming: as soon as I have some tools metadata files to work with, i'll do the juju code ti plug it in
<arosales> wallyworld_, btw I *think* the current HP public bucket doesn't have AZ2 or AZ3 info init
<arosales> s/init/in it/
<wallyworld_> arosales: yes, correct. i just did that as a quick thing to get us going
<arosales> I get a precise image not found when trying to deploy to AZ2 or AZ3
<arosales> ok
<wallyworld_> arosales: the correct images can easily be added
<arosales> I ran into that in a project that just had AZ2 configured per HP support suggestion
<arosales> work around it by using AZ1
<wallyworld_> but sounds like we are really close now anyway
<arosales> pending when simple streams and tools are available if it is easy it would be worth while to add az2 and az3 info
<wallyworld_> yes indeed. that was my expecation at least - that the image metadata update process would include all reuired regions
<wallyworld_> arosales: utlemming: once this is fully done, for CPC, *no* public-bucket-url info will be needed in the user's env yaml
<wallyworld_> it will "just work"
<wallyworld_> hopefully :-)
<arosales> wallyworld_, ack
<arosales> juju should already have pre knowledge of what the simple stream data is for cpc
<wallyworld_> yes, it looks at cloud-images....
<wallyworld_> but public bucket still needed for tools
<wallyworld_> we also need to improve the tooling for setting up private clouds
<arosales> gotcha
<wallyworld_> but that is being worked on
 * thumper sighs
<thumper> damn frustrating tests..
 * thumper tries to work out just how many hoops to jump through is too many
#juju-dev 2013-07-09
<bigjools> does juju assume all machine units have a different IP?
<wallyworld_> i think so
<thumper> bigjools: assume in what way?
<bigjools> thumper: I don't know the nature of the assumptions, I just need to know if it does as it affects how we'd implement some Azure stuff
<bigjools> Azure is not a "flat" service
<thumper> bigjools: I don't think anything is indexed on IP
<thumper> however it does use the address to talk to the machines
<bigjools> yeah I figured
<thumper> it is what is propagated between units in relations
<thumper> there is some work pending which mgz is starting around machine addressability
<thumper> to remove some of the assumptions
<thumper> and have clear expectations
<thumper> bigjools: so touch base with mgz for more info
<bigjools> Azure gives multiple VMs the same IP address and load balances unless you do things differently
<thumper> ?!
<bigjools> thumper: right thanks - Gavin was talking to him already
<thumper> you should be fine then :)
<bigjools> In Azure, you get this sort of structure: Service -> Deployment -> VM / VM / ...
<bigjools> each "service" has its own IP
<bigjools> rather than the VM
<jtv2> Any reviewers in the house?  I've got a big one waiting: https://codereview.appspot.com/11027043
<bigjools> way to attract reviewers :)
<jtv2> Any worse than the built-in "please take a look"?  :)
 * thumper does a mega move
<bigjools> Can anyone help with this panic in the stdlib please? http://play.golang.org/p/zRZh_cXGy9
 * davecheney looks
<bigjools> I think I was doing the wrong thing to what I need anyway, but I thought it was interesting that I can panic it :)
<davecheney> it's because you're trying to marshall a []string into
<davecheney> <somethign name="..." />
<davecheney> where ... is whatever []string marshalls too in xml
<bigjools> yes I was expecting <node name="cgf" name="dfgfdg"/>
 * davecheney scratches
<davecheney> head
<davecheney> i dunno if that is valid xml
<davecheney> two secs
<bigjools> might not be
<davecheney> i don't think it is
<davecheney> but it's a shit poor error message in that case
<bigjools> what I really wanted was an array of <something name="foo">
<bigjools> thanks for looking
<davecheney> bigjools: np
 * davecheney ponders http://www.w3.org/TR/REC-xml/#attdecls
<davecheney> it's been a while since i've had to read this train wreck
<bigjools> XML is the spawn of satan anyway
<davecheney> bigjools: so youi wanted
<davecheney> <div>
<davecheney>   <something name="foo" />
<davecheney>    <something name="bar" />
<bigjools> yes
<davecheney> </div>
<bigjools> I have that now
<davecheney> ok
<bigjools> by making a sub-struct array
<davecheney> yup, that is the solution
<davecheney> the impdendence mismatch between XML and Go is pretty high
<davecheney> Gustavo did some work to make it less crap before 1.0 shipped
<bigjools> it has raised some eyebrows
<davecheney> but it's still margian
<davecheney> marginal
<bigjools> you can't use attr with chains, either :(
<davecheney> chains ?
<bigjools> xml:Node1>Node2
<davecheney> there is a syntax
<davecheney> it is certainly non intuative
<bigjools> ie `xml:"Node>SubNode,attr"`
<davecheney> i think that is a bridge too far
<davecheney> i don't go in that package much
 * bigjools idly wonders if xpath would have been less of a shit sandwich
<davecheney> I believe our man in Brazil might have a solution to that
<davecheney> http://blog.labix.org/2013/06/07/efficient-xpath-for-go
<davecheney> not tried yet
<thumper> review incomming $ bzr diff -r branch::parent | wc -l
<thumper> 2315
<thumper>  59 files changed, 348 insertions(+), 363 deletions(-)
 * davecheney shrieks 
<thumper> this branch has a high likelyhood of clashing with someone
<davecheney> i guess that is how you got your nick
<thumper> davecheney: I bit the bullet for jam
<thumper> davecheney: this branch kills state.Tools
<jam> ;
<thumper> and makes everything use tools.Tools
<thumper> and moves agent/tools.go into tools/agent.go
<thumper> lbox is currently working out the diff
<thumper> jam: I wanted to mess around with tools a little
<thumper> jam: in particular, uploading pre-built tools for the local provider
<thumper> into the local storage
<thumper> so I needed to refactor a few methods anyway
<thumper> seemed stupid to do it in the old place
<thumper> Rietveld: https://codereview.appspot.com/11028043
<jam> thumper: per the request from fwereade he really likes the idea of an "agent" top level package, rather than a "tools" one.
<thumper> entirely mechanical
<jam> So I was going to pull environs/agent top level and replace tools with it.
<jam> Though still have agent/Tools instead of state/Tools.
<thumper> jam: well... someone can change the files later
<thumper> this is done
<thumper> lots of tests fixed
<thumper> jam: well, the work is half done
<thumper> baby steps, no?
<thumper> I have to admit, the review looks impressive
<jam> thumper: rather than having to do 2 massive conflicty changes like this, can you just 'bzr mv tools agent' and then use 'agent.Tools' everywhere in your patch, but otherwise leave it the same?
<jam> We don't have to move the rest of the agent stuff
<jam> just call it agent.Tools so we don't have to have a mass rename again.
<jam> thumper: or would you rather see tools.Tools *and* and agent/* package?
<thumper> jam: there are lots of other tools methods too
<thumper> jam: I'm happy to have agent
<thumper> jam: as long as it doesn't bring in dependencies on environs or state
<jam> thumper: I definitely want to nuke state.Tools, I'm just trying to figure out what the best we can replace it with for now, so we can hopefully avoid changing 50+ files again :)
<thumper> jam: just moving the dir will cause more problems
<thumper> as there are some places that have environs/agent and tools
<jam> thumper: right, so don't move the dir. This is more about "replace state.Tools with something better" and agent/ as a top level package probably makes more sense than tools/ (I think)
<thumper> if you want s/tools/agent/ it will have to wait for tomorrow
<jam> thumper: np, I'll look at your patch and bring it up with William today, so we can settle it out.
<jam> I sort of like "tools.Tools"
<thumper> I think agent.Tools makes more sense IMO
<jam> but I think there is more than just tools that we want to cluster there.
<thumper> jam: except heaps of tests has local variables called tools
<jam> thumper: yeah
<jam> and Tools is pretty generic
 * thumper nods
<jam> so agent.Tools makes it clear it is the jujud stuff
<jam> not just any thing
<thumper> I have to go put on some veg and rice
<thumper> later folks
<jam> thumper: later
<rvba> jam: Hi Johnâ¦ sorry to bother you with this againâ¦ but could you pleaseâ¦ update lp:gwacl again :)  (This time I'll send an email to the list as well because we won't update gwacl in the next few daysâ¦ hopefully).
<jam> rvba: updating from 166 to 168, does that sound correct?
<rvba> jam: yep. ta.
<jam> rvba: for https://code.launchpad.net/~rvb/juju-core/az-destroy/+merge/173657 this is one of those cases where with mocking, if something changes will we notice?
<jam> rvba: looking at something like "buildDestroyServiceResponse", you are describing what gwacl does under the covers, which certainly feels like a test that should be in gwacl.
<jam> Would it make more sense to mock the gwacl layer itself, and assert what functions in gwacl are being called?
<rvba> jam: as I said on the MP, checking which requests have been done is indeed a tradeoff: it forces you to know what gwacl does under the covers to some extendâ¦ but it's better than mocking the gwacl layer because if a method changes it's behavior in any significant way, the tests will fail.
<jam> rvba: but isn't that what the gwacl tests are for? It feels like if you have to fix something in gwacl, causing it to change its behavior, you then have to fix the tests (without actually fixing the juju-core code).
<jam> (eg, a False Positive test failure)
<rvba> jam: that's right, it's a bit clumsy in that regardâ¦ but I'm not sure mocking the gwacl layer entirely is feasible.
<jam> rvba: well 'feasible' means it would probably have to be designed from the start as 'interface' things that you then swap out for something different.
<jam> Not necessarily feasible at this point.
<dimitern> jam: hey
<jam> you can't really monkey patch in go, so you need to build in the abstraction layer
<jam> hi dimitern
<rvba> Right.
<rvba> We've used that pattern in some cases.
<jam> rvba: though to be fair, often abstraction layers leave you with really nice decoupled and coherent code :)
<dimitern> jam: i don't think the changes to deployer would've caused the issues reported upgrading 1.10->dev
<dimitern> jam: i tested that specifically live on ec2
<jam> dimitern: It was more being hopeful that we had an answer to why upgrade failed rather than thinking it would really fix it.
<dimitern> jam: hmm.. actually come to think of the tests i did - it was 1.11 -> 1.11.2, so don't know about 1.10 -> 1.11.2
<rvba> jam: the problem with the design you suggest is that, ultimately, it means you are creating a test double in the provider's code.  So it might work nice and clean (compared to the testing strategy we have in place now) at first and then turn into a hairy piece of code that is awkward to maintain, especially in the provider's testing code (as opposed to on gwacl's side).
<jam> rvba: sure, I'd certainly rather see a hypothetical double exist in gwacl than maintained in juju-core. I'm just trying to get a handle on what the tests add vs failure modes, etc.
<jam> r
<jam> rvba: if you mock at the wrong level, all you end up with is "the code looks like the code"
<jam> at the same time, you do want to end up with "things are hooked up in a sane manner".
<rvba> jam: Don't get me wrong, I think you've got a valid point.  But what we've done here is a tradeoff that stemmed from our experience with the MAAS provider where we decided to create a full test double in the GO MAAS lib.
<rvba> The testing code of the provider was nice an clean.  But the amount of work required to develop and maintain a test double in gomaasapi wasn't worth it.
<rvba> At least that was our conclusion :).
<jam> rvba: reviewd: https://codereview.appspot.com/11034044/
<jam> mgz: poke
<rvba> jam: ta!
<mgz> jam: hey
<jam> mgz: wow, I actually get to see you during a day :)
<jam> well, hear from you at least
<mgz> yeah, trying to get ack on earlier footing
<mgz> *back
<dimitern> fwereade: ping
<fwereade> dimitern, pong
<dimitern> fwereade: you wanted to talk about the deployer api stuff?
<fwereade> dimitern, ah yeah
<fwereade> dimitern, can we do a g+in 10 mins or so please?
<dimitern> fwereade: sure, just ping me when you're free
<jam> fwereade: State.Sync() vs State.StartSync() can I get some context as to what they mean?
<fwereade> jam, both cause the state to get the latest content from the transaction log
<jam> (what the difference is in practical)
<fwereade> jam, StartSync returns immediately; Sync doesn't return until all events have been delivered by the watcher package
<jam> fwereade: so I think I understand that Sync() waits for it to complete before you do your assertions, and StartSync does not.
<jam> fwereade: but I don't quite understand why worker/uniter/filter_test.go uses both
<fwereade> jam, note that this does not *necessarily* imply that all consequences have come to pass, though
<fwereade> jam, we usually StartSync before things we don't expect to happen and Sync before things we do
<jam> fwereade: is there a way to write a generic fuction that can be passed a  "<- chan Type" ?
<jam> I know I can write <-chan interface{}
<jam> But I don't think you can pass a <-chan Type as that parameter
<jam> right?
<fwereade> jam, afraid not, as far as I'm aware
<fwereade> dimitern, hey, I forgot to say I merged api-use-entities; did you have a moment to review api-life-result?
<dimitern> fwereade: just reviewed
<fwereade> dimitern, cheers dude
<dimitern> fwereade: it seemed a bit weird not to have Machine.Refresh() anymore
<fwereade> dimitern, if it's not used, I don't want it cluttering up the api
<fwereade> dimitern, cost of reimplementing it one day is dwarfed by the mental load on everybody of keeping it around
<dimitern> fwereade: it was to be used by the provisioner I think
<dimitern> fwereade: but yeah, fair point
<fwereade> dimitern, I *think* the usage profile is different there
<fwereade> dimitern, and will probably go by another facade regardless
<dimitern> fwereade: yeah
<jam> fwereade: provisioner also uses WatchEnvironConfig
<jam> which I know you wanted to change, though *I* don't immediately know how to restrict it.
<dimitern> jam: but that's bound to change
<fwereade> jam, all I expect is that we'll use your WatchFor watcher and directly get the EnvironConfig when it's needed
<dimitern> jam: I think the idea is to have a notifywatcher for that and then call EnvironConfig() to read it when changed
<fwereade> dimitern, and jam's already implemented that watcher ;)
<dimitern> fwereade: yep!
<jam> fwereade: fairy nuff
<jam> fwereade: I'd like to get your input on: https://codereview.appspot.com/11035043/
<jam> As far as having a testing/* object for testing how a channel is operating
<jam> (akin to state/testing/NotifyWatcherC but for things that aren't Watcher objects.)
<jam> In theory NotifyWatcherC could be implemented in terms of the testing/* object, but I didn't go that far)
<fwereade> jam, I think that's very nice, even if I needed to reread curryResolvedMode when I encountered it
<fwereade> jam, I'd be +1 on extending it in that direction
<jam> fwereade: from what I can tell, go1.1 has some more Select/Chan based stuff in reflect, which would let us get around writing currying functions.
<jam> but I didn't want to dig into that until it was actually useful :)
<fwereade> jam, quite right too (and it'll be interesting to see how much of a difference that makes... it's nice that reflection exists, but I've never really felt the code that uses it is particularly clean or expressive)
<jam> fwereade: yeah, reflect seems to mostly gain you "1 function to handle many types" , which interface{} mostly gets you
<jam> except when it doesn't like channels
<jam> but go 1 didn't have reflected channels :)
<jam> fwereade: if you can think of a better name than NotifyAsserterC I'm happy to change it, btw.
<jtv2> Any reviewers available?  I need a second review for https://codereview.appspot.com/11027043/
 * fwereade shrugs -- if you think of a better one then go for it :)
<fwereade> jtv2, ack
<jtv2> thx
<dimitern> jam: wow, one of those 100+ files +1/-0 lines reviews
<jam> dimitern: fortunately most of those +1 is a blank line :)
<jam> dimitern: might be a case where it is easier to review on Launchpad.
<jam> dimitern: I'm not too concerned about getting them all perfect, just getting them 'good' so people will crib from existing ones.
<dimitern> jam: i'll take a look on lp
<jam> though "j j j j j j j j j j j j " isn't too hard to type :)
<jam> but does take a lot of page reloads
<dimitern> jam: so not all gocheck refs are changed to "gc"
<jam> dimitern: I didn't get to that part, just changing the ordering of imports, and clarified that we want to do "gc"
<jam> that is going to touch a lot more content, rather than just imports
<dimitern> jam: yeah, good point
<jam> I also didn't get to the other 280 files.
<jam> fwereade: http://paste.ubuntu.com/5858056/ is what a trivial folding-into-WatcherC looks like
<jam> the primary differences:
<jam> a) It will always call c.State.Sync() even for AssertNoChange
<jam> (when not Lax)
<jam> b) The naming of AssertNoChange vs AssertNoReceive
<jam> means that it proxies the call
<jam> c) We lose the "watcher did[not do] something" in error messages
<jam> because NotifyAsserter talks about channels.
<jam> worth it?
<dimitern> jam: do we now have the StringsWatcher we talked about?
<jam> dimitern: no
<jam> dimitern: I thought that was on your plate :)
<dimitern> jam: ah, i see :)
<dimitern> jam: i was wondering whether to implement the UnitsWatcher in apiserver or do something more generic
<dimitern> fwereade: what do you think? ^
<dimitern> in any case it can be done i 2 steps, which is easier for me anyway
<jam> dimitern: I think for the params adding a StringsWatcher interface, and then implementing UnitsWatcher in terms of that.
<jam> since LifeCycleWatchers are going to want it as well, right?
<dimitern> jam: hmm or implement UW and then extract an iface from it :)
<jam> dimitern: so the steps I did were: (1) add a state/* interface (NotifyWatcher) (2) add a corresponding api/params NotifyWatcher interface along with NotifyWatcherResult, etc. (3) add a client-side implementation of api/watcher/notifyWatcher, (4) Add a worker/NotifyWorker to consume these things into actions.
<jam> you should be able to do something quite similar for StringsWatcher
<dimitern> jam: yeah, except it's a little foggy what should it have right now
<jam> which might help break it down into steps to complete and get landed. I was generally working on 1-2 branches at a time to make sure that the design was reasonable
<jam> dimitern: IMO StringsWatcher interface is just NotifyWatcher with a different Changes()
<dimitern> jam: I should be able to copy most of the the notifywatcher, except for inital event handling and changes
<jam> dimitern: right
<dimitern> jam: and then LifecycleWatcher and UnitsWatcher will use StringsWatcher interface
<jam> dimitern: we *could* go with an ObjectWatcher that had: Changes() <-chan interface{}
<dimitern> jam: let's not do that just now :)
<jam> but generic channels are a bit hard (as seen by my recent patch)
<fwereade> dimitern, jam, yeah, let's make it Strings
<jam> dimitern: right: func  NewLifecycleWatcher(...) StringsWatcher
<jam> IMO
<dimitern> fwereade: Strings?
<dimitern> fwereade: you mean StringsWatcher or?
<fwereade> dimitern, StringsWatcher over the API, yeah
<jam> dimitern: StringsWatcher rather than ObjectWatcher
<dimitern> fwereade, jam: oh yeah, absolutely
<fwereade> jtv2, reviewed
<jtv2> thanks fwereade
<fwereade> dimitern, jam: if I were to say "relation tags", what would spring to mind?
<dimitern> fwereade: i see where are you going :)
<jam> fwereade: I'd be making something up, but a handle for a single relation
<jam> *or* a relations endpoints defined in terms of tags
<fwereade> dimitern, jam: the main issue is that relation keys (may) contain spaces, and this doesn't fit well with our existing taggery
<dimitern> fwereade: relation-wordpress:db-mysql:server ?
<dimitern> fwereade: should the spaces matter? after the "relation-" prefix anything valid goes
<fwereade> dimitern, I fear that - is valid in relation name as well as service
<fwereade> dimitern, fair point, maybe spaces in tags are ok, but if feels a little bit off
<jam> fwereade: sure, but we still prefix it
<dimitern> fwereade: so how about @ or $ or # or some other separator?
<jam> it is true that any-given-string may accidentally match
<jam> but as long as we only actually pass a real Tag into a Tag field
<fwereade> dimitern, jam: I was wondering how you guys would feel about relation-%d
<jam> it must have the "start-" be unique
<dimitern> fwereade: ah, actually better
<dimitern> fwereade: not worse than machine-% anyway
<jam> fwereade: how are relations addressed currently, just by id?
<fwereade> jam, ha, well, they have an id and a key
<dimitern> jam: internally; otherwise by name
<fwereade> jam, the key is derived from the endpoints
<jam> fwereade: relationDoc struct {Key string `bson:"_id"`}
<fwereade> jam, stringed in a canonical order, separated by spaces
<fwereade> jam, yeah, exactly
<dimitern> fwereade: "derived" is the tricky part
<jam> I think that means they have a "Key" which is acutalyl an id
<jam> but I guess they also have an Id
<jam> ugh
<dimitern> implies ordering
<fwereade> jam, tell me about it
<jam>  fwereade: so does that mean that "Key" as derived from endpoints is actually indexed by Mongo (because it is the _id), but Id as an int is not?
<fwereade> jam, it is
<jam> that would be the only reason I can think of to settle what reference to use in a tag
<jam> something that can be looked up via index
<jam> so relation-%d is fine, as long as %d is indexed, IMO
<fwereade> jam, Id is, er, probably not indexed, but should be
<dimitern> the id is unique and unambiguous
<jam> fwereade: I guess that is what our 2k service tests are for, right?
<dimitern> what it's not is "user-friendly"
<jam> dimitern: I don't think anyone is going to be manually entering them, are they?
<fwereade> dimitern, yeah, good point, I think that swings it even if it's not the nicest
<jam> They will be discovered via api requests.
<fwereade> jam, dimitern: and relation keys are somewhat unfriendly to enter anyway
<dimitern> jam: no, but these ids are only internal and never displayed (hmm maybe in hook env vars only)
<jam> fwereade: relation keys seem far harder to *type* because of the derived nature
<fwereade> jam, dimitern: what with having to know all names and roles and that
<fwereade> dam, yeah
<fwereade> jam, dimitern: hmm, *except*
<dimitern> fwereade: if there is a way to convert id to name in a tool it doesn't matter really
<fwereade> jam, dimitern: the LifecycleWatcher uses _id, therefore Key, and it would be nice to be able to easily convert watcher results into tags
<dimitern> just relation-name <id> returns derived name and copy/paste that if you need it?
<fwereade> dimitern, I think the human-readability is a bit of a red herring maybe
<fwereade> dimitern, in charms there's a different vocabulary (sigh) derived from the id
<dimitern> fwereade: well, for display purposes we're not using either anyway
<jam> fwereade: lifecyclewatcher could be taught to return Tags in the api...
<dimitern> fwereade: we use verbose yaml dump
<fwereade> jam, yeah, I am wondering about that
<fwereade> jam, but the same consideration applies to some degree at least
<fwereade> jam, it should be convenient to convert them
<jam> fwereade: as in, you should be able to convert them without a db query? Though aren't they used to query the db?
<fwereade> jam, and with state/watcher we're stuck with _id-based watches at the lowest level
<dimitern> jam: you don't need a db query - you already have all the services in the relation struct, so RelationTag can be simply implemented
<fwereade> jam, most of them probably will be, yeah, but having to read the whole object to get an id that we can subsequently use to read it again feels, er, suboptimal
<jam> fwereade: well the API is intended as a point of Abstraction so we don't have to worry about what is in the DB quite as much.
<fwereade> jam, dimitern, relation.Tag is easy whatever we choose, Key and Id are both present
<fwereade> jam, ah, hmm, nice theory, practical concern
<fwereade> jam, I don't think we can depend on the db docs still existing when we want to convert
<dimitern> fwereade: why didn't we have relation tags before? there wasn't any need for them through the api?
<fwereade> jam, so we my be stuck with Key-based ones
<fwereade> dimitern, yeah, can't auth as *or annotate* a relation
<fwereade> jam, dimitern: so I think we're stuck with Key
<dimitern> fwereade: why would we ever need to auth as a relation?
<fwereade> dimitern, quite
<fwereade> dimitern, that's why it's not an auther
<dimitern> not even an otter :D
<fwereade> dimitern, but we never annotate them either, which is how this never got considered
<fwereade> ;p
<dimitern> fwereade: hmm.. that might be useful i guess for the gui
<fwereade> dimitern, jam: what's the worst that can happen if we put a " " in a tag, I wonder
<fwereade> dimitern, maybe, but they didn't do it because they didn't need it afaik
<jam> fwereade: the worst? Someone uses it in a shell script and it splits on the extra space.
<dimitern> fwereade: spaces are scary.. c'mon it's not 70s anymore
<jam> And that causes rm -rf to run on their personal machine
<jam> and that causes them to go on a killing spree triggering a nuclear war
<dimitern> any script should assume spaces might be present and use ""
<jam> fwereade: The only legitimate concern I would have is the charm using shell case
<jam> I don't know that relation-tag would even be exposed there.
<fwereade> dimitern, jam: *that* won't happen because the charm doesn't see tags
<fwereade> dimitern, jam: but the spectres yu raise still bug me
<dimitern> fwereade: can't we simply s/ /_/ or something?
<fwereade> dimitern, jam, hmm, maybe
<dimitern> both ways
<fwereade> dimitern, jam, I have a horrible feeling we don't restrict relation names much :/
<jam> fwereade: it wouldnt' be guaranteed unique if you munge it.
<dimitern> intelligently ofc - check for existence of the result
<jam> relationship_foo and relationship foo
<dimitern> fwereade: +1 to that
<jam> fwereade: the transports we currently use for talking about stuff are all space-safe.
<jam> "JSON" string, etc.
<jam> shell is the only place I can think of that could be a problem.
<dimitern> fwereade: we should at least restrict spaces and a few other chars we could use as separators
<fwereade> jam, dimitern: yeah, I'll try to check that out
<fwereade> jam, dimitern: it's grown beyond what I should do in this CL anyway
<dimitern> fwereade: proposal: restrict " ", "@" and/or "#" in relation names?
<fwereade> jam, dimitern: will surprise us when we hit the uniter facade
<fwereade> dimitern, I'd much rather restrict it harder, to basically what we have in service names
<dimitern> even "/" as we use it already as a separator
<dimitern> fwereade: ah, good point
<fwereade> dimitern, weird to have those in rel tags when we sub them out in unit tags
<dimitern> give the people too much freedom in name choices and all hell breaks loose ;)
<fwereade> dimitern, jam: future plans: restrict charm relation names, implement relation tags with s/ /$some_forbidden_char/
<fwereade> dimitern, today plans: ignore relation tags
<dimitern> fwereade: sgtm
<jam> fwereade, dimitern: I'd like a second pair of eyes on something with cmd/jujud/upgrade.go. It has this fancy "delayedTomb()" logic, that AFAICT isn't actually doing anything.
<jam> it is designed that if delayedtomb->Dying is set, it sleeps for a time and then calls actualtomb->Kill()
<jam> however, the delayed tomb is only a local variable
<dimitern> jam: where?
<jam> cmd/jujud/upgrade.go
<jam> look for tomb := delayedTomb()
<dimitern> ok
<jam> I don't see anything that could try to stop tomb rather than lots of stuff that would stop Upgrader.tomb
<jam> anyway, I'm done for today. I was just trying to see if I needed to mimic that code, but it doesn't seem to actually be used.
<dimitern> jam: it looks fishy
<jam> dimitern: if it set self.tomb or something like that, then I could see it being used
<dimitern> jam: and it's used in several places as noDelay(), but i'm yet to figure out why
<jam> dimitern: it might be that I mixed the order around.
<dimitern> jam: hmm
<jam> So if someone calls Kill on Upgrader.Kill() it takes a while to actually call tomb.Kill
<jam> so the download loop takes 5 min to respond to a Stop request
<dimitern> jam: i'm not sure but in live tests i observed a lot less than that
<jam> ah, the idea is that Runner will see a task fail (which actually fails because we need an upgrade) so we still allow this task to download new tools.
<jam> dimitern: upgraderDelay is a var that is probably overridden in tests
<dimitern> jam: seems likely
<dimitern> jam: anyway, have a good evening then
<fwereade> jam, oh, christ, that stuff
<fwereade> jam, I don't think it's necessary with a sanely configured worker.Runner
<fwereade> dimitern, jam: you know how any error in any task takes down every task?
<fwereade> dimitern, jam: the kill delay was a "solution" to that problem
<dimitern> fwereade: i thought we were changing this with the task runners though?
<dimitern> fwereade: aahh
<fwereade> dimitern, jam: so that an upgrade that caused some task to error didn't prevent us from being able to upgrade away from the broken code
<fwereade> dimitern, jam: now we can implement tasks independently I think it's entirely redundant
<fwereade> dimitern, jam: that's not to say there aren't failure cases
<fwereade> dimitern, jam: but there always were anyway
<dimitern> fwereade: cool, so we can get rid of it once we use the runner
<fwereade> dimitern, +1
<fwereade> jam, btw, did you see that mail on the lists yesterday? short version is that we somehow installed the wrong mongodb... was wondering if you had any insight into this
<fwereade> or mgz for that matter ^^
<fwereade> dimitern, btw, https://codereview.appspot.com/11041043 is what I was talking about earlier, that I hope implements half the Deployer's methods
<dimitern> fwereade: cool, will take a look in a bit
 * dimitern needs to step out for 20m
<dimitern> fwereade: reviewed
<fwereade> dimitern, cheers
<ackk> hi, does anyone know what could be the issue here: http://pastebin.ubuntu.com/5858644/ ? It only happens if I deploy a charm from a local repo
<dimitern> ackk: can I see the config.yaml of the charm in question?
<ackk> dimitern, it's a checkout of lp:~landscape-charmers/charms/precise/landscape-client/trunk , no changes
<ackk> dimitern, I also tried with a very basic charm, that only logs hooks
<ackk> dimitern, fwiw, "juju deploy cs:~landscape-charmers/precise/landscape-client" works
<dimitern> ackk: and you're using juju-core tip?
<ackk> dimitern, yes
<dimitern> ackk: and with the basic charm the same happens?
<ackk> dimitern, as of 10 minutes ago, at least :)
<ackk> dimitern, yes
<dimitern> ackk: is ./charms a directory where you're running it?
<ackk> dimitern, yes, I also tried absolute paths and "." from the directory itself
<dimitern> ackk: can you paste the output of "du -h --all" inside the charms dir?\
<ackk> dimitern, http://paste.ubuntu.com/5858663/
<dimitern> ackk: and you don't have JUJU_REPOSITORY env var set?
<ackk> dimitern, nope
<dimitern> ackk: just a sec
<ackk> dimitern, it seems something strange with that dir, I just tried checking out in a different repo dir and it worked
<dimitern> ackk: ah :)
<ackk> dimitern, maybe something related to .bzr ?
<dimitern> ackk: shouldn't matter but might be
<dimitern> ackk: can you please test it with .bzr inside and if you repoduce it, please file a bug
<ackk> dimitern, so the .bzr is only inside the landscape-client dir, but I can't reproduce it outside of that dir. Maybe it's just messed up...
<ackk> dimitern, thanks for the help
<dimitern> ackk: nevertheless, panics like this are really bad - if you manage to backtrack your steps and reproduce it in a bug report will be really awesome!
<ackk> dimitern, sure, I'll try
<dimitern> ackk: tyvm
<fwereade> ackk, would you paste the config.yaml please?
<fwereade> ackk, it's definitely the same in both cases?
<ackk> fwereade, for landscape-client local and cs: charms? yes, it is. It has something to do with that dir specifically
<ackk> fwereade, dimitern oh wait I got it, the other charm (not the one I was deploying) had an empty config.yaml, removing it made it work
<fwereade> ackk, that is technically an invalid config then... but it should be an error, not a panic, I think
<fwereade> (well obviously it shouldn't be a panic)
<fwereade> (but part of me is saying that a config with out an "options" key is, well, just a config without options, and should maybe warn but not error... any takers?)
<dimitern> fwereade, ackk: yeah, that was what I was thinking of - Unmarshl in charm.ReadConfig returns an uninitialized Options map and that panics in the range loop around line 104 in charm/config.go
<fwereade> dimitern, I think it's an uninitialized *Config, but yeah
<dimitern> fwereade: yeah in fact
<fwereade> dimitern, annoying that an empty file unmarshals into a nil pointer without error
<dimitern> fwereade: I still think a bug report is in order
<ackk> dimitern, yeah, what confused me is that the issue was actually in a different charm in the same repo, I didn't expect it to be relevant
<fwereade> dimitern, I'm not sure it's actually a bug, I suspect it's annoying-but-coherent behaviour
<dimitern> ackk: well, at some point when we read the repo I *think* we scan all charms and this might be the issue
<ackk> dimitern, I see
<dimitern> fwereade: a panic like this surely deserves a bug and some handling?
<fwereade> dimitern, definitely
<fwereade> dimitern, (blast, that was a pastebin link not a bug link)
<fwereade> dimitern, ackk, I'll do one, thanks
<ackk> fwereade, dimitern  thank you
<dimitern> fwereade: we might want to audit all places we Unmarshal stuff like that for similar issues
<dimitern> ackk: thanks for catching this
<fwereade> dimitern, +1,x2
<dimitern> fwereade: CleanupWatcher seems a candidate for unexporting and migrating to NotifyWatcher
<fwereade> jam, have a word with jam about it, I think he mentioned that too
<dimitern> fwereade: ok
<TheMue> gnah!
<TheMue> remember - tests don't work if you create temporary directories but don't use them
<dimitern> fwereade, TheMue: a simple review? https://codereview.appspot.com/11044043/
<TheMue> dimitern: *click*
 * dimitern bbiab
<fwereade> dimitern, LGTM, one bit to fix
<TheMue> ah, it passed, yeah
<TheMue> dimitern: oh, btw, yes, from my side an lgtm too.
<dimitern> fwereade, TheMue: thanks!
<dimitern> abentley: hey
<abentley> dimitern: Hey.
<dimitern> abentley: I wanted to ask you about the rietveld-enabled versions of lp-propose and lp-submit - where can I find them?
<abentley> dimitern: It was at https://code.launchpad.net/rvsubmit, but you may not be able to access it because the commercial license has expired.
<abentley> dimitern: It submits only.  It does not propose.
<dimitern> abentley: so the idea was to use lbox propose, and rvsubmit later, so you don't have to set LP commit message, set bugs to committed (if linked) and approve the MP?
<abentley> dimitern: Right, except that it doesn't do the bugs.  I think those get set automatically when the branch is merged, but I could be wrong.
<dimitern> abentley: well, bugs are no big deal anyway, not so many we're dealing with right now (we will at some point though :) - btw I can access it on LP - so is it a bzr plugin or a separate script?
<abentley> dimitern: It's a plugin.
<dimitern> fwereade: I don't really get why srvLifecycleWatcher should be renamed to srvStringsWatcher?
<dimitern> abentley: i'll try it out, cheers
<abentley> dimitern: Do you have Tarmac running now, then?
<fwereade> dimitern, everywhere up from state we should be dropping the distinctions, surely?
<dimitern> fwereade: do you also mean changing Lifecycle* types to Strings* types - in params, etc.?
<dimitern> abentley: yep, for some weeks now - and working even :)
<fwereade> dimitern, probably, yes, although I'd forgotten it had got that far, I'm fine doing it in stages if that's where a sane line seems to you to be
<dimitern> fwereade: quick g+ ?
<fwereade> dimitern, sure
<dimitern> fwereade: https://plus.google.com/hangouts/_/5faf4d98498233fe5228a813ee7bda05c5c2a20c?authuser=0&hl=en
<jam> dimitern: you mean https://codereview.appspot.com/10876048/ ? (CleanerWorker ?)
<dimitern> jam: not really - i meant just replace CleanupWatcher with NotifyWatcher in state
<jam> abentley, dimitern: Tarmac will set bugs to Fix Committed when it merges the code if they are linked on LP to the MP (which happens if you do it directly, via lbox ,or with commit --fixes)
<jam> dimitern: ah sorry, was thinking the wrong side.
<jam> I have Workers on the brain
<dimitern> jam: that last part I didn't get - what's commit --fixes?
<jam> 'bzr commit --fixes lp:1234556'
<jam> will set bzr metadata that Launchpad will notice and associate your branch to a bug
<dimitern> jam: oww - how awesome is that :)
<dimitern> jam: btw, if you haven't landed that CL yet, consider adding that change to state?
<dimitern> fwereade: ping?
<jam> I landed the CleanerWorker already
<abentley> jam: There's also lp-link-bug, but that's in the lpreview_body plugin.  I should probably fix that.
<dimitern> jam: ah, but you have i see
<jam> dimitern: I think you could just change line 1229, with "func (st *State) WatchCleanups() NotifyWatcher" because *CleanupWatcher is already a NotifyWatcher in spirit
<dimitern> jam: yep something like that
#juju-dev 2013-07-10
<davecheney> can anyone help me make the juju-core build recipe dependent on a ppa
<davecheney> is taht possible ?
<davecheney> arosales: did jamespage say we could use his PPA via a LP build recipe ?
<davecheney> first signs are that this is not possible
<m_3> davecheney: looking
<davecheney> m_3: s'ok i figured it out
<m_3> I think it's a separate
<m_3> ah, cool
<davecheney> m_3: arosales bigjools is there a way to get this bumpedup ?
<davecheney> https://code.launchpad.net/~dave-cheney/+recipe/juju-core
<davecheney> 6-7 hour build delay before I find out if it worked
<bigjools> davecheney: I no longer have da powahs, go to the internal ops channel and ask nicely
 * davecheney practices best asking for things smile
<bigjools> davecheney: also you get get a permanent boost on a nominated PPA by also asking nicely
<m_3> davecheney: dunno
<bigjools> s/get get/can get/
<bigjools> I approve of your LP avatar
<m_3> davecheney: might be worth the time setting up pbuilder-dist... you'll at least know in short order for archs and series that you target
<bigjools> indeed, pbuilder should be used for build testing, NOT launchpad
<davecheney> bigjools: i need to move to having a proper source build, not lp build recipes
<davecheney> they are crutch
<bigjools> it's a piece of piss to do it all from a recipe locally
<bigjools> recipes make it easy
<m_3> my fav is the 'merge-part'... ahem
<m_3> sorry... s/merge-part/nest-part/
<m_3> that's the icky one
 * bigjools imagines davecheney's "best asking for things smile" to look a bit like Sheldon Cooper's
<davecheney> bigjools: yes, but with more sincerity
<bigjools> wallyworld: do you have affinity group stuff in openstack?
<wallyworld> not sure tbh
<wallyworld> never had cause to use it
<bigjools> trying to work out whether the azure solution we're going with needs to worry about it
<wallyworld> i'll ask martin tonight
<bigjools> the way juju works seems to assume your env is one group
<bigjools> if that's not the case then we have a problem
<wallyworld> there's only one state server right now
<bigjools> yeah
<wallyworld> but that will change with HA
<bigjools> when is that coming?
<wallyworld> "soon"
<wallyworld> i think it's next after API work
<wallyworld> can't recall exactly
<bigjools> ok ta
<bigjools> should be ok... I think
<wallyworld> actually, in sept
<wallyworld> after manual provisioning
<davecheney> faaaaaaaaaaaaaaaark
<davecheney> 2013-07-10 04:00:46 ERROR juju supercommand.go:234 command failed: cannot start bootstrap instance: no "precise" images in ap-southeast-2 with arches [amd64 i386]
<davecheney> error: cannot start bootstrap instance: no "precise" images in ap-southeast-2 with arches [amd64 i386]
<davecheney> how the fuck did that happen
<davecheney> precise	server	release	20130502	ebs	amd64	ap-southeast-2	ami-9d4bdba7	aki-31990e0b		paravirtual
<davecheney> precise	server	release	20130502	ebs	i386	ap-southeast-2	ami-9f4bdba5	aki-33990e09		paravirtual
<davecheney> precise	server	release	20130502	instance-store	amd64	ap-southeast-2	ami-9b4bdba1	aki-31990e0b		paravirtual
<davecheney> precise	server	release	20130502	instance-store	i386	ap-southeast-2	ami-4f4bdb75	aki-33990e09		paravirtual
<davecheney> they really are there, I promise
<davecheney> wallyworld: is ec2/image.go used anymore
<davecheney> or has it been replaced byt he stuff in environs/instances ?
<davecheney> can anyone bootstrap at the moment ?
<davecheney> I keep getting 2013-07-10 04:56:52 ERROR juju supercommand.go:234 command failed: cannot start bootstrap instance: no "precise" images in us-west-1 with arches [amd64 i386]
<davecheney> error: cannot start bootstrap instance: no "precise" images in us-west-1 with arches [amd64 i386]
<davecheney> ffs, every time I go to use juju is broken
<davecheney> about to call instances.FindInstanceSpec with images []
<davecheney> FindInstanceSpec: matchingTypes [{ m1.small [amd64 i386] 1 1740 80 0xe3bc50 0xc210000510} { m1.medium [amd64 i386] 1 3840 160 0xe3bc50 0xc210000518} { c1.medium [amd64 i386] 2 1740 183 0xe3bc50 0xc210000560} { m1.large [amd64] 2 7680 320 0xe3bc50 0xc210000520} { m2.xlarge [amd64] 2 17408 495 0xe3bc50 0xc210000548} { m1.xlarge [amd64] 4 15360 640 0xe3bc50 0xc210000528} { m3.xlarge [amd64] 4 15360 700 0xe3bc50 0xc210000530} { c1.xlarge [amd6
<davecheney> FindInstanceSpec: possibleImages []
<davecheney> 0 images are passed as candidates...
<wallyworld> davecheney: it's used, but only as glue logic between ec2 provider and simplestreams
<wallyworld> davecheney: sounds like the metadata that has been set up for ec2 is out of date
<davecheney> wallyworld: i think it is the cost data
<davecheney> ec2/image.go ~ line 60
<davecheney> nothing is making it through that filer
<wallyworld> let me look
<davecheney> wallyworld: http://paste.ubuntu.com/5860638/
<wallyworld> davecheney: at first look, it seems very weird since there's no constraints to exclude instance types
<wallyworld> davecheney: it would be good to see some more tracing, especially the value of matchingImages around line 33 of ec2/image.go
<wallyworld> and also images from line 38
<davecheney> dialing connection 20 cloud-images.ubuntu.com:80
<davecheney> findInstanceSpec: matchingImages []
<davecheney> none
<wallyworld> hmmmm
<davecheney> wallyworld: is it broken for you ?
<davecheney> i tried other series' and regions
<wallyworld> davecheney: well, i bootstrapped an ec2 env this morning from source
<wallyworld> different region though i think, let me check
<davecheney> ap-southeast-2 and us-west-1 at broken for me at least
<wallyworld> i used the default, us-east-1
<davecheney> trap for young players, us-east-1 always works
<davecheney> nope, us-east-1 doesn't work for me
<wallyworld> davecheney: the fact that matchingImages is [] means that there is a mismatch between the simplestreams metadata and the hard coded regions and endpoints in the aws lib
<wallyworld> well, that's my theory
<davecheney> goamz is up to date
<wallyworld> since the metadata parsing process is to load up all simplestreams metadata and filter out the stuff that doesn't have the same region and endpoint as defined in goamz
<wallyworld> i'll boot up an env again and see what happens
<wallyworld> davecheney: fails for me now. worked this morning
<davecheney> bloody hell
<wallyworld> davecheney: and it appears simplestreams metadata was recently updated
<wallyworld> davecheney: http://cloud-images.ubuntu.com/releases/streams/v1/
<wallyworld> those timestamps would be UTC
<wallyworld> so last update was 2 hours ago i think
<wallyworld> davecheney: i'll dig into it have see what i find. i'm not blaming the metadata yet. need evidence first :-)
<davecheney> shit, 14:02 ws when I first noticed it
<davecheney> it must have _just_ broken then
<davecheney> actaully about 15 minutes before hand
<davecheney> but I spent that time facepalming
<wallyworld> hmmm. i'll see what i can find
<davecheney> wallyworld: it *looks* like there is a ap-southeast-2 (and other) region defined in the streams data and index files
<wallyworld> yes it dos
<wallyworld> does
<wallyworld> there's nothing obviously wrong that jumps out at me
<davecheney> 2013-07-10 06:11:01 WARNING juju.environs.ec2 image.go:43 no matching image meta data for constraints: &instances.InstanceConstraint{Region:"us-east-1", Series:"precise", Arches:[]string{"amd64", "i386"}, Constraints:constraints.Value{Arch:(*string)(nil), Container:(*instance.ContainerType)(nil), CpuCores:(*uint64)(nil), CpuPower:(*uint64)(0xc2100dad98), Mem:(*uint64)(nil)}, Storage:(*string)(0xc210280fd0)}
<davecheney> WHOA, loggo doesn't output warnings without -v
<wallyworld> davecheney: some tracing shows that juju thinks the index file is missing some data
<wallyworld> but to my eye, the data is there, so looking further
<davecheney> â¯Â°â¡Â°ï¼â¯ï¸µ â»ââ»
<wallyworld> huh?
<jam> davecheney: 'juju' never output anything without '-v', that behavior was preserved when we switched to loggo.
<davecheney> jam: that sucks
<jam> In a "lets change one thing at a time" sort of way
<davecheney> that is a suckful experience
<jam> davecheney: agreed.
<jam> And it was intended to change
 * davecheney writes a shitty gram to list
<jam> at least by a few of us
<jam> wallyworld: any chance we have an archive of the contents of simplestreams, so we can compare to what it used to be, and maybe seen an obvious way it was generated differently?
<wallyworld> i wish :-)
<wallyworld> that would be too easy
<wallyworld> i don't think we have the previous copies
<wallyworld> could be wrong
<jam> wallyworld: it is worrying that there is no fallback/archiving done for important info like this.
<wallyworld> jam: there might be, *I* just am not aware of it
<jam> wallyworld: so given there is json sjson and json.gpg, is json.gpg just a --detach-sign, and sjson just an inline sign?
<wallyworld> yes
<jam> wallyworld: it is clear that the archives aren't being put in an "old/" or a "$DATE/" sort of directory
<jam> which is probably what I would like to see.
<wallyworld> agreed
<jam> wallyworld: I think in theory the history is in the file itself, right? With the problem that it gets regenerated from scratch with whatever the current logic is.
<wallyworld> yes
<wallyworld> jam: davecheney: the index file is wrong
<davecheney> wallyworld: \o/
<wallyworld> it doesn't contain an "index" map key
<wallyworld> i'll email the relevant people
<wallyworld> clearly our processes nd to be fixed
<wallyworld> there should be a staging area where new metadata is vetted
<wallyworld> using some acceptance tests
<jamespage> davecheney, you figure out the dependencies are between PPA's right?
<davecheney> jamespage: yes sir I did
<davecheney> hopefully it'll bake correctly this afternoon
<jamespage> also mgz copied those binaries to https://launchpad.net/~juju/+archive/golang
<davecheney> ahhhhhhhhhh
 * davecheney shakes fist at LP for having *three* names for things
<davecheney> url, name and description
<davecheney> ffs
<jam> jamespage: from what I see in that page, it looks like 1.1.1 is officially in saucy's archive?
<jamespage> jam: it is indeed
<jamespage> (uploaded it yesterday)
<jam> jamespage: great! Did you get the multi-arch stuff sorted out?
<jam> (last I saw there was failures to build  go on i386 or something)
<jamespage> jam: no - thats still pending - I just pushed a new version based on the packaging currently in saucy
<jamespage> jam: there are still some issues with CGO and the approach that the debian maintainer is taking re cross compiling
<jam> jamespage: so it is asking the amd64 builder to cross compile an i386 binary?
<jam> (or something to that effect)
<jamespage> jam: actually its the other way round - i386 builds the compilers and runtimes for all archs
<jamespage> not sure I'm 100% comfortable with that
<jam> jamespage: that sounds problematic for i386 to build an amd64 arch
<fwereade> wallyworld, the diff for https://codereview.appspot.com/10777044/ is very dirty, would you take a look at it please?
<jamespage> jam: maybe but cross compilation is a feature of golang
<jamespage> jam: so long as the required cross build headers are present it should work
<jam> good morning fwereade
<fwereade> jam, heyhey
<TheMue> hmm, the bootstrap_test in cmd/juju fails intermittent
<fwereade> TheMue, bug it please (and please fix it if it's reasonably easy to do so)
<fwereade> jam, just looking at SyncAPIServerState
<fwereade> jam, is that really the only way to get at the *State backing the api server?
<TheMue> fwereade: yep, will first propose my sync-tools and then investigate. seems to be only if my system is under load by parallel tasks.
<fwereade> TheMue, cheers
<fwereade> jam, I can believe it is, I was just not even aware that the api server was running in the dummy environment
<fwereade> jam, and it kinda feels like there's something rather surprising there
<fwereade> frankban, heyhey, reviewed, please let me know what you think
<fwereade> jam, (there are also perspectives from which it makes sense ofc)
<frankban> fwereade: cool, thanks
<fwereade> jam, https://codereview.appspot.com/10890047/ reviewed
<jtv2> fwereade: I put off my StartInstance/Bootstrap refactoring to give Tim time to finish his, but I have another good one for you.  Got a moment for a video chat?
<fwereade> jtv, sure, would you start one please?
<jtv> Coming right up.
<jtv> fwereade: https://plus.google.com/hangouts/_/77dc830b0aa56248e9ccb3151e2e92e99cb4427c?hl=en-GB
<jam> fwereade: sorry about the delay, I was out getting groceries. But yes the actual server machine you are running is started as part of dummyenviron.Bootstrap()
<jtv> Does that even work on the dummy provider!?
<jam> And that isn't returned anywhere that I could obviously see.
<jam> jtv: It is running in-process
<fwereade> jam, yeah, that makes some sort of sense... even though the fact that we're running hacked-up half bits and pieces of a bootstrap and a machine agent is really just crazy
<jam> fwereade: certainly it isn't what *I* expected.
<fwereade> jam, all I'd known about was the hacked-up bootstrap
<jam> I would have thought JujuConnSuite would have been starting it locally and retaining a reference to it, rather than indirectly via Bootstrap
<fwereade> jam, yeah, that would be the sane thing to do
<jam> fwereade: so, I'm perfectly happy to change the code so that the back-door exposes the full state.State object
<jam> and then we shove that on the test suite.
<jam> I'm not 100% sure what to do about the State connection we have, which is an independent connection to the mongodb
<jam> we could just replace it
<jam> so the lines in JujuConnSuite for  "s.State = NewConn()" would be replaced with "s.State = ExtractStateConnFromEnvironment()"
<jam> or whatever we call that thing.
<jam> That means the tests for API Server also use the same State object
<jtv> Anybody free to review a refactoring across the providers?  Cleans up the interaction between environments and their storage: https://codereview.appspot.com/11087043
<jam> fwereade: for https://codereview.appspot.com/10890047/diff/5001/state/apiserver/upgrader/upgrader_test.go?column_width=80
<jam> Does defer AssertStop() interact if you directly call AssertStop() at the end of the test?
<jam> I like the "make sure it is stopped even if these assertions fail"
<fwereade> jam, AssertStop should be safe repeatedly, because Stop should also be
<jam> I'm worried about "AssertClosed" leaving us in a state where AssertStop fails accidentally.
<fwereade> jam, won't help in cases where we expect an error out of stop
<jam> I'll put it back, if it fails, I'll take it out. :)
<fwereade> jam, ok :)
<fwereade> jam, I think AssertClosed should be independent
<fwereade> jam, I'm not sure about smooshing all possible state conns together though
<fwereade> jam, we definitely need access to the API one but I'd prefer to extract that to a sensible place so we have a bit more clarity on what's in play before we make sweeping changes
<dimitern> fwereade: hey, can you take a look at this please? https://codereview.appspot.com/10944044
<fwereade> dimitern, ack
<dimitern> jam: you too maybe? since it's watcher stuff ^^
<fwereade> dimitern, LGTM with comment on the description
<dimitern> fwereade: thanks, I'll try to accomodate this at client-side on the next CL
<fwereade> dimitern, great
<dimitern> fwereade: the picture is somewhat unclear yet though
<fwereade> dimitern, the easy way to do it is to s/LifecycleWatcher/StringsWatcher/ on the client side and be done with it
<dimitern> fwereade: that's where the StringsWatcher (in params) interface will come into play (client-side), right?
<fwereade> dimitern, yeah, but it shouldn't be in params
<dimitern> fwereade: ah, so you're saying to have only one concrete implementation at client-side, rather than an interface and multiple implementations?
<fwereade> dimitern, and tbh... api/watcher.NotifyWatcher and api/watcher.StringsWatcher both seem to be like perfectly reasonable concrete types, no interface hackery required
<fwereade> dimitern, they'll still implement those interfaces just fine, but we don't need to declare them
<dimitern> fwereade: ok, then I can get rid of the NotifyWatcher interface in params and do the rename in this CL?
<fwereade> dimitern, sure, that works for me
<dimitern> fwereade: cool
 * fwereade bbiab
<jam> fwereade: so one concern is how to lable the thing. "StateBeingUsedByAPIServer" is a bit long :)
<fwereade> jam, heh, and APIState is taken
<fwereade> jam, if api were called api maybe things would be saner, but that's a big change
<fwereade> jam, BackingState? at least it's compact
<jam> dimitern, fwereade:  so for StringsWatcher, I'd certainly want to see something that looks a bit more like NotifyWatcher, where you pass in the *WatchResult and get back a running StringsWatcher
<jam> the existing code makes the Watch call for you
<fwereade> jam, but doesn't collide, and with a comment it'd make some sense
<jam> which means that the client side API is a bit tangled.
<fwereade> jam, agreed, as soon as we need an implementation, which is imminent
<jam> fwereade: StateInAPIServer ?, but BackingState is reasonable.
<fwereade> jam, dimitern: for the purposes of this CL I think the implementation should be left alone though
<fwereade> jam, your call
<dimitern> jam: should there be worker/stringswatcher as well for it?
<jam> fwereade: usually multiple threads in IRC can be resolved because you are talking to a different person. Hard when it is all the same. :)
<jam> dimitern: If you think there is commonality worker/stringsworker could be really nice, as it then lets you decouple the "I'm watching something from" "Here's what I do when it changes"
<fwereade> dimitern, I'm not sure yet
<fwereade> dimitern, would you mail thumper for an opinion on how well it'll fit with the provisioner? if that will really have to be tortured to make it fit, then no
<fwereade> dimitern, because deployer will be the only implementation for the forseeable... oh wait
<fwereade> dimitern, minunits handling
<dimitern> fwereade: yeah
<fwereade> dimitern, ok, that's a yes, and if the provisioner can fit it too it'll be a nice bonus
<fwereade> dimitern, thanks
<jtv> Sorry to interrupt... anybody free to review a refactoring?  It cleans up the interaction between providers and Storage: https://codereview.appspot.com/11087043
<fwereade> and fwiw it is very nice, and simple to review :)
 * fwereade really off for a bit now
<dimitern> jtv: looking
<jam> dimitern: so we had Cleaner and Machiner and a few of them that used the Notify pattern. I *like* splitting things out to separate concerns. But as William said, if it can't actually be reused it isn't worth writing.
<jtv> Thanks dimitern!
<jam> I did develop NotifyWorker in tandem with changing Cleaner so I would know the design fit.
 * jtv runs errand
<jam> jtv: is https://codereview.appspot.com/11087043/patch/6001/7023 actually being used? It looked like everything already had an implementation.
<dimitern> jtv: reviewed
<dimitern> jam: btw the :12345 - my bad :) I was testing and there were some failures and I don't actually remember why I did it, but it shouldn't have landed
<dimitern> jam: I think it was to be able to monitor the exact server that was launched
<jam> dimitern: interestingly enough, the Machiner one was already gone by the time we noticed the failures in UpgradeWatcher. It took me a bit to figure out where it came from.
<dimitern> jam: yep it came from there
<jam> dimitern: yeah, except it doesn't actually work, because the server that is launched is running inside the Environ.
<jam> which is what I'm working on exposing a bit now.
<jam> TheMue: can you include a paste of the failing test https://bugs.launchpad.net/juju-core/+bug/1199698 ?
<_mup_> Bug #1199698: intermittent test failure in BootstrapSuite <juju-core:New for themue> <https://launchpad.net/bugs/1199698>
<dimitern> fwereade, jam: updated as discussed: https://codereview.appspot.com/10944044/
<jam> dimitern: +1
<dimitern> jam: good to land you think?
<TheMue> jam: sure
<dimitern> jam: moving that outside of params was fwereade's request and I like it as well
<jtv> jam: I used them in the dummy provider, localstorage, or both â can't remember which.
<jtv> Thanks for looking at my branch, people!
<TheMue> jam: right now I have no more test run without a failure :(
<jam> jtv: what I saw at least looked like you might have wrote that first and not realized we had implementations, but if it is used, its fine to keep it.
<TheMue> jam: the failing tests are the --upload-tools tests
<jam> TheMue: something to keep in mind for future reports. It is hard to see context in case someone else tried to pick up the failures.
<jam> TheMue: interesting. Might be a platform bug.
<jam> I think "--upload-tools" forces precise always
<jam> (recent change)
<jam> so if you are running on precise, you only upload 1 tool
<jam> if you are not
<jam> then you upload at least 2
<jam> "recent" as in a month ago or so.
<jam> jtv: I need to teach you enough API so you can do some quid-pro-quo :)
<jtv> jam: I'll check, because of course I can always have mis-remembered.  :)  IIRC the dummy and localstorage both lacked a deleteAll equivalent.
<TheMue> jam: but I already had runs where it is working
<jam> jtv: https://codereview.appspot.com/11036043/ is a pretty straightforward rename of a package if you want to give it a look.
<TheMue> jam: and the test case which is failing (8, 9 or 10) is changing from run to run
<jam> TheMue: that is very strange.
<TheMue> jam: exactly
<jtv> jam: coming...  But be warned: I'm a notorious nit-picker.  :_
<jtv> :)
<jtv> Oh, that's quite a lot â let me just polish off what I have in flight first.
<jam> jtv: it is big, but all mechanical
<jam> mv environs/agent => agent/
<jtv> Good, I'll put any heavy lifting for my branch's follow-up into its own branch, and review yours first.
<fwereade> dimitern, reviewed
<jam> fwereade: I responded to https://codereview.appspot.com/10890047/
<jam> It now opens up BackingState
<dimitern> fwereade: cheers
<jam> fwereade: https://codereview.appspot.com/10944044/ ...  I would *really* like to see things that are working on the API *not* import juju-core/state
<jam> so while we could use the interface from there
<jam> it means we also expose all the raw state stuff
<jam> vs just knowing "we don't import state in this module"
<jam> thoughts?
<jam> (it is why I created an interface rather than re-using the existing one)
<fwereade> jam, I'm only thinking of worker/cleaner really, that's still using state
<jam> fwereade: well, let me finish Upgrader, and Cleaner is quite tempting :)
<jam> but fair enough
<fwereade> jam, uniter is strictly higher priority I think
<fwereade> jam, I'm firmly +1 on keeping state imports out of packages that use the API though
<fwereade> jam, sorry if that wasn't clear
<jam> sure, but uniter is complex, Cleaner is like 1 API change :)
<dimitern> rv-submit is awesome! it makes using rietveld+lp+tarmac the same as lbox submit does!
<dimitern> I recommend all of you to try it out - no need to set commit message in LP, set the MP to approved, etc. it even updates the [r=reviewers line] correctly
<fwereade> dimitern, nice
<jam> fwereade: yeah, version_test.go was the first time I've ever seen: import "." anywhere.
<dimitern> install it just with: bzr branch lp:rvsubmit ~/.bazaar/plugins/rvsubmit
<jam> I didn't know it worked
<jam> but there was "version.*" in the test suite.
<jam> dimitern: well, sort of correctly:  R=fwereade, fwereade, jameinel, jameinel
<jam> If we used Launchpad's "Approve" tarmac would be picking the R= line correctly as well
<dimitern> jam: that's because it counts all LGTMs
<dimitern> jam: that could be improved - but it's better than having [r=dimitern] only ;)
<jam> dimitern: right, it just needs to dedupe them. Though I'd rather put the time in fixing tarmac to understand LGTM as well.
<dimitern> jam: any idea what's this: https://code.launchpad.net/~dimitern/juju-core/066-apiserver-stringswatcher/+merge/173896/comments/389246
<jam> fwereade: 2 design things about upgrader-api-worker. (1) I thought of a way to do the delayed shutdown with a LifesupportRunner. Since the goal is that an outside signal is delayed, but an inside signal is immediately shutdown. I won't implement it yet, but I think it can fit nicely if we want it.
<jam> fwereade: but (2) The Upgrader wants to wait on 2 channels, 1 for the new versions, and 1 for when the download completes.
<jam> I could re-implement all of the NotifyWorker locally just to get another channel
<jam> or I could expose a "Handlers may request 1 extra <-chan interface{} to wait on"
<jam> then Handlers can multiplex any waiting they want to do onto that channel
<jam> does that seem a reasonable design?
<jam> Or should I just go with "ignore NotifyWatcher for now"
<fwereade> jam, thinking
<jam> dimitern: I think it is that rv-submit is setting Approved state without setting the Approved revision field.
<dimitern> jam: hmm so I can see a patch to fix this
<dimitern> and the reviewers dedups
<jam> fwereade: with a WatchExtra() <-chan interface{} => HandleExtra(interface{})
<jam> fwereade: then things based on NotifyWatcher can handle as many actual channels as they want, they just need to add context on in and out
<jam> alternatively, I'm not sure Upgrader would suffer terribly if it just blocked until it finished downloading the current thing.
<fwereade> jam, heh, that latter one feels like a nice gordian knot solution
<fwereade> jam, but I'm having some difficulty properly picturing the WatchExtra/HandleExtra in practice so I may just be dumb today
<jam> fwereade: right now, SetUp() returns a Watcher, we could have it also return a "<-chan interface{}"
<jam> or we could have inside the main loop
<jam> select { case <-watcher.Changes(): ... case <-handler.WatchExtra())
<fwereade> jam, can you think of other use cases? feels a bit situational to me right now...
<jam> fwereade: Provisioner also has one primary watcher (I think) but then a few other side things going on.
<jtv> jam: branch reviewed.
<fwereade> jam,yeah, but that's stringswatcher-based
<jam> jtv: thx
<pavel> Hhello, just now I had an interesting case. A week ago my teammate used juju bootstrap in the same EC2 zone, but with different control-bucket and security credentials. Today I run juju bootstrap with my own control-bucket and security credentials. And when I run juju destroy-environment both bootstrap nodes were terminated.
<pavel> We have separate credentials within one AWS account.
<pavel> Is this correct behavior?
<jam> pavel: I *think* if you name your environments differently it won't step on eachother, but instances that get deployed are labeled by environment name, not by control bucket.
<pavel> yeah... I thought that exactly this was the case
<pavel> But it's frustrating I think
<jam> fwereade: your stream is frozen.
<jtv> jam: how do I run a live test?
<jam> jtv: cd environs/ec2; source ~/.ec2creds; go test -amazon
<jtv> Thanks.
<jam> for whatever values of ec2 credentials you want to use
<jam> or
<jam> cd environs/openstack
<jam> go test -live
<jam> though you also need your Canonistack credentials, etc.
<jtv> Is there no way to do this against the local or dummy provider?
<jam> jtv: all the providers run them against the test doubles if you just do "go test ./..."
<jam> except azure doesn't implement a double
<jtv> Ah OK, so then "make check" should be enough.
<jam> right
<mgz> jam: prereq/bot question
<mgz> I marked my branch that fixes tests on danilo's having his as a prereq
<jam> mgz: to avoid landing snafus, approve and wait for prereq, then approve post
<jam> if you can't do that
<jam> you can mark prereq as merged
<jam> and land the second
<mgz> does this mean his needs to land first... in which case that was a mistake, because the bot will reject it as the tests don't pass without both...
<mgz> ah, neat hack, will try that
<jam> mgz: right, you can set the MP status to Merged, and then the bot will let you land the second one.
<dimitern> abentley: hey, I found 2 issues while testing rvsubmit
<abentley> Oh, what?
<dimitern> abentley: it seems it's not setting ApprovedRevision and also should remove duplicates in approvers list (e.g. if X has 2 LGTMs it appears twice)
<mgz> ah, right, I also ran into both of those :)
<mgz> dimitern is a better user than I for reporting
<abentley> dimitern: I'm surprised I have to specify approved revision-- why doesn't it default to the current revision like the UI does?
<dimitern> abentley: it seems to be required by the go-bot (or tarmac)
<dimitern> abentley: see here https://code.launchpad.net/~dimitern/juju-core/066-apiserver-stringswatcher/+merge/173896/comments/389246
<abentley> dimitern: I'm not disagreeing, I'm just saying it's dumb that launchpad makes me do extra work to set the approved revision.
<jam> abentley: I'm guessing the GUI grabs the current revision from some data on the page when it submits the request
<jam> but it is explicitly sending it, rather than just setting approved.
<jam> abentley: because if your page is out of date
<jam> the approved revision is out of date
<jam> abentley: I've done 'bzr push' and then marked it approved on the page, and the bot tells me the wrong revision is approved. (Because I didn't reload the page after Launchpad noticed the updated branch)
<jam> ah, I scared him off :(
<dimitern> :)
<jam> abentley: https://launchpad.net/+apidoc/devel.html#branch_merge_proposal
<jam> It looks like "revid" is an optional field
<jam> to setStatus
<jam> and the webpage is grabbing reviewed_revid and passing it into queued_revid
<jam> I've certainly had cases where I had an old MP view, and didn't refresh after "bzr push" and then tarmac tells me "there are additional revisions that have not been reviewed"
<abentley> jam: Do you have any thoughts about whether I should look at the local tip or just always use Launchpad's tip?
<jam> abentley: you mean the one on the review page, the one on lp:~branch-i-pushed; vs WT.revision?
<jam> ... page, or the one...
<abentley> jam: I mean the branch on the user's computer vs the one on codehosting.
<jam> abentley: I would say the one you intend to approve is probably your local revision, the one you are actually approving is the one on lp:~...
<jam> if we are going to look up the one on lp:~... it is probably worth comparing that value to the local one.
<jam> abentley: 'lbox submit' would do the push, though. Is that something we should put into rvsubmit ?
<jam> so local rev should end up matching lp rev
<jam> mgz, dimitern: I could use a second review of https://codereview.appspot.com/10890047/
<jam> I'm off for now, though I'll probably be back later tonight.
<dimitern> jam: lookinh
<mgz> jam: looking
<abentley> jam: Since the branch on Launchpad has been approved, it seems a bit weird to automatically push.
<abentley> jam: Though of course, some approvals are really conditional.
<jtv> jam: I added that test you asked for by the way: https://codereview.appspot.com/11108043
<jam> abentley: sure, though certainly the bzr process was that you might ask for tweaks, and the person submitting would do a tweak and submit. Which is mostly how we're doing LGTM.
<jam> jtv: review
<jam> reviewd
<jtv> thanks
<abentley> dimitern: Why are there multiple LGTMs for X?
<jam> abentley: conditional LGTM from one, followed by larger refactorings, leading to a follow up push and re-review
<dimitern> abentley: because i think the approvers list is sorted, but dupes are not removed
<jam> dimitern: I think he is asking why someone would possibly LGTM 2 times
<abentley> jam: right.
<dimitern> abentley: ah, right - yes, the reason is as jam explained
<dimitern> abentley: happens sometimes with longer-lived MPs that undergo a refactoring mid-way to landing, so need second approval
<dimitern> jam: you have a review
<mgz> is bug 1130209 still relevent? we take mongo from distro now, no?
<_mup_> Bug #1130209: we need a mongodb compiled for i386 <mongo> <package> <juju-core:Triaged> <https://launchpad.net/bugs/1130209>
<jtv> ...Precise?
<dimitern> mgz: we have both amd64 and i386 builds in the ppa, but none of them seem to work
<fwereade> dimitern, api-common-life is merged now
<dimitern> fwereade: cool
<dimitern> fwereade: i wanted to ask you do you think EnsureDead and Remove should be combined and should this be done throughout?
<dimitern> fwereade: actually the machine uses only EnsureDead, the deployer needs both so far
<fwereade> dimitern, I *think* that a Remove that also does an EnsureDead will also be useful for the provisioner
<fwereade> dimitern, however an EnsureDead that does not remove will be required for machiner and uniter
<dimitern> fwereade: i see
<fwereade> dimitern, (deployer and provisioner both have responsibility for units/machines that may be dying and not yet deployed/provisioned; in both cases they want to fast-forward to destruction
<fwereade> )
<fwereade> they're really annoyingly similar at heart
<dimitern> fwereade: so if we call it Remove wouldn't that be confusing? how about EnsureRemoved?
<dimitern> (from state package's point of view and those familiar with it)
<fwereade> dimitern, yes from state package POV, not so sure from api POV
<fwereade> dimitern, the clients gosh-darn want that thing removed and don't really care otherwise
<dimitern> fwereade: well, as long as there never is a Remove method that doesn't do both in the api, we'll be fine
<fwereade> dimitern, fair point
 * fwereade thinks
<dimitern> fwereade: otherwise we'd better call it EnsureDeadAndGone or something :)
<fwereade> dimitern, I kinda feel that the implementations of similar methods on different facades are not an issue
<fwereade> dimitern, it's two facade-specific questions I guess
<dimitern> fwereade: we'll see soon enough anyway
<fwereade> dimitern, yeah, often it just takes implementing it and seeing how much the implementation bugs you :/
<dimitern> fwereade: exactly :)
<abentley> dimitern: I've updated the plugin.  Could you try it again?
<dimitern> abentley: will do in my next MP, thanks!
<abentley> dimitern: You're welcome.
<fwereade> ha, found the upgrade bug
<dimitern> fwereade: oh, what is it?
<fwereade> it is the initial watcher event -- the selector wasn't picking up machines with an unset containertype, just an empty containertype
<fwereade> as soon as trunk code has changed a machine it's fine
<fwereade> before then it's not reported so we think the instance is not associated with anything
<fwereade> verifying it actually works
<dimitern> fwereade: hmm
 * fwereade really hates waiting for machines to come up
<hazmat> is juju working with ec2 atm?  it can't seem to find an image (trunk from 12hrs ago) http://pastebin.ubuntu.com/5861907/
<hazmat> specifying default-image-id in env.yaml generates a warning
<mgz> hazmat: nope, the cloud images data got changed which breaks things
<mgz> ...we should really put that in the topic or summat
<hazmat> mgz, any workarounds?  you mean the simple metadata stream data? the tab separate file looks like its still the same ie https://cloud-images.ubuntu.com/query/precise/server/released.current.txt
<fwereade> hazmat, it should be fixed
<fwereade> hazmat, there was a problem with the simplestreams, index.sjson was pointing to unsigned product files and we didn't like that
<fwereade> hazmat, 1.10 still uses that cloud-images path, trunk uses simplestreams
<fwereade> dimitern, TheMue: review of https://codereview.appspot.com/11116043 ? very small change, disproportionately useful
<dimitern> fwereade: looking
<hazmat> fwereade, cool, looks like its working
<dimitern> fwereade: reviewed - should this be linked to the upgrade bug? does it fix it?
<fwereade> hazmat, thanks for confirming
<fwereade> dimitern, yeah, good point, thank you
<fwereade> jam, you still around?
<fwereade> TheMue, no joy on the bootstrap tests?
<TheMue> fwereade: no, absolutely no luck
<fwereade> TheMue, would you link me the bug while you review https://codereview.appspot.com/11116043 please? I'll see if anything springs to mind
<TheMue> fwereade: you've got a 2nd lgtm
<TheMue> fwereade: the bug is the https://bugs.launchpad.net/juju-core/+bug/1199698
<_mup_> Bug #1199698: intermittent test failure in BootstrapSuite <intermittent-failure> <juju-core:In Progress by themue> <https://launchpad.net/bugs/1199698>
<TheMue> fwereade: I'm trying to follow the call flow, so far I don't see a race here.
<TheMue> fwereade: ha, while typing this I have one idea, one moment.
<TheMue> fwereade: bingo, all passed, will try with a little change
<fwereade> TheMue, I know what it is
<fwereade> TheMue, we're uploading more files at bootstrap than we were before
<fwereade> TheMue, so once we've checked that the expected N were uploaded, we proceed with the test, even though bootstrap hasn't necessarily finished
<TheMue> fwereade: hmm, dunno
<TheMue> fwereade: but what changed the behavior here is the setting of GOMAXPROCS
 * TheMue slaps himself
<dimitern> fwereade: deployer facade v1 - not sure about the auth stuff yet, but take a look please: https://codereview.appspot.com/11117043
<TheMue> fwereade: *crash*
<fwereade> TheMue, hmm, I may be wrong, but I'm suspicious -- didn't someone just land something that wrote differently on bootstrap?
<fwereade> TheMue, oo, you've broken something hard? nice
<TheMue> fwereade: yes, with GOMAXPROCS=1 it works, but with 4 as I had before it fails
<fwereade> dimitern, sorry, there's been a misunderstanding: reviewed
<dimitern> fwereade: ah, you mean Remove is on units
<dimitern> (facepalm)
<dimitern> :) ofc
<fwereade> dimitern, no worries, I know how it is :)
<fwereade> dimitern, just remember to use up-to-date state, because I think the auth.entity is likely in general to be stale
<fwereade> dimitern, and we need it to know about the right set of units
<dimitern> fwereade: that's what I needed to ask
<fwereade> dimitern, the *easy* way is to start a WatchUnits on that machine and see what comes out of the first event
<dimitern> fwereade: where does the getcanchange comes in? i've yet to do the setpassword, so apart from there - should it be used elsewhere?
<fwereade> dimitern, the logic behind getCanChange will be needed in Remove as well
<fwereade> dimitern, I think (open to argument ofc) that the right thing to do is to figure out the set of entities we're allowed to operate on as soon as we're asked to operate on at least one
<dimitern> fwereade: when that?
<dimitern> fwereade: in WatchUnits? or in NewDeployerAPI?
<fwereade> dimitern, both way too early
<fwereade> dimitern, just after `if len(request.Entities) == 0 { return }`
<dimitern> fwereade: so after getting the unit from state
<fwereade> dimitern, I don't think we should be speculatively getting units, no
<fwereade> dimitern, I think we should only pay the roundtrip for the entities we know we need
<fwereade> dimitern, so we pay an upfront cost to discover what entities we're allowed to operate on
<dimitern> fwereade: hmm.. so once we know we have entities to operate on (in Remove only) we create the auth func? put it where though
<fwereade> dimitern, g+?
<dimitern> fwereade: was about to suggest, yeah, will start one
<dimitern> fwereade: https://plus.google.com/hangouts/_/34b4267f6a46cb41a76fd05f6dc398f7409f94c4?authuser=0&hl=en
<jamespage> fwereade, question - should I be raising bugs for anything I find different CLI api wise between juju and juju-core
<fwereade> jamespage, yes please; there may be a very small number we don't want to support but in general we want to be entirely compatible
<fwereade> TheMue, ok, it is not exactly what I thought it was
<fwereade> TheMue, but try waiting for uploads+1 OpPutFiles
<fwereade> TheMue, I think that will actually make the test more reliable than ever before
<jamespage> fwereade, sorry - another question
<jamespage> is the cli in juju-core intentionally extremely quiet?
<fwereade> jamespage, ...sort of
<jamespage> its quite disconcerting
<fwereade> jamespage, bugs pointing out that this is actually crap will help us to get it done though
<jamespage> fwereade, on it
<fwereade> jamespage, because actually providing useful feedback is a little less trivial than one might hope
<fwereade> jamespage, although just providing *some* by default would probably be a good idea regardless of ugliness like irrelevant logging badges
<jamespage> fwereade, agreed - bugs raised
<fwereade> jamespage, thanks
<TheMue> fwereade: yep, will do
<jamespage> mgz, are we going to be able to get a juju-core release uploaded to saucy this week?  AFAICT the 1.1.1 stuff is working OK from PPA's
<jamespage> and we have 1.1.1 in saucy....
<jamespage> mgz, just give me the source and I'm primed to go!
<dimitern> jamespage: whoohoo! 1.1.1 in saucy really? cool!
<jamespage> dimitern, yep
<fwereade> jamespage, that's awesome; and so, hopefully, but not tomorrow, there are two notable problems I have just found :/
<fwereade> (log is filled with api failure spam, and lxc-not-installed spam, after upgrading; bugs forthcoming, need to characterise them better)
<mgz> jamespage: I'll send an email to the list now
<mgz> *1.11 btw
<mgz> fwereade: can you target those bugs against 1.11 on launchpad?
<fwereade> mgz, will do
<jam> dimitern, fwereade: I can't land https://codereview.appspot.com/10890047/ because moving api.NotifyWatcher means that state/api/upgrader/upgrader needs to import api (in order to return an api.NotifyWatcher). But api needs to import upgrader/upgrader
<jam> because api.State.Upgrader() returns an Upgrader instance
<jam> That is why I had put it in params before
<mgz> jamespage: bug 1194022 is fixreleased?
<_mup_> Bug #1194022: Please bump golang version to 1.1.1 <golang (Ubuntu):New> <https://launchpad.net/bugs/1194022>
<jam> do we have a better solution?
<fwereade> jam, any problem dropping the interface and returning a concrete api/watcher.NotifyWatcher type from api/watcher funcs?
<dimitern> jam: why does api need to import upgrader?
<jam> dimitern: because api.State has attributes that return the facades
<dimitern> fwereade: yes, in fact there is a problem
<jam> it does the same for api.State.Machiner() etc.
<fwereade> dimitern, bother :)
<fwereade> dimitern, what's that?
<dimitern> fwereade: i tried that but it didn't work because of state interfaces
<dimitern> fwereade: used in workers
<fwereade> dimitern, sorry, expand please
<jam> fwereade: state/api/state.go imports all the sub packages
<jam> machiner
<jam> machineagent
<jam> upgrader
<fwereade> dimitern, doesn't the concrete type satisfy that interface?
<dimitern> fwereade: let me check the exact line
<fwereade> dimitern, thanks
<jam> fwereade: so at present, state/api/watcher/watcher.go imports state/api because it wants to return an api.NotifyWatccher
<dimitern> fwereade: the problem was cleanup worker in SetUp needed to return a concrete type out of the state watcher
<dimitern> jam: well, I don't see big problem with moving api/interfaces.go in api/params/interfaces.go
<jam> we could turn state/api/watcher notifyWatcher public
<fwereade> jam, yeah, that's what I'm suggesting
<jam> dimitern: well, you then have params.NotifyWatcher, which I thought was what we were avoiding
<fwereade> dimitern, I do, they have nothing to do with the params over the wire
<dimitern> jam: well, fwereade was mostly against it
<fwereade> dimitern, the cleanup worker doesn't use the api
<dimitern> fwereade: but uses watchers, which now use interfaces
<dimitern> fwereade: aah, now i got your remark that the workers should use state interfaces!
<fwereade> dimitern, haha :)
<dimitern> fwereade: yeah, i was thinking "aren't we moving towards using the api anyway - why depend on state if it's gonna go away" :)
<fwereade> dimitern, jam, and if *that* still causes problems somehow
<fwereade> dimitern, jam, then I think the answer is for notifyworker to use its own damn copy of the interface, because the problem is that it's being used for state things but pretending it's all about api things
<dimitern> jam, fwereade: so basically get rid of the api/interfaces and inside workers use state interfaces for watchers
<fwereade> dimitern, so it happily accepts both a state.NotifyWorker and a concrete *api/watcher.NotfiyWatcher
<jam> dimitern: except we don't want to end up there. fwereade and I both agree that we *really* want to switch to not import state in things using the API, and state/api/watchers *consume* the api.
<fwereade> dimitern, I want to use api interfaces in code implemented against the api, and state interfaces in code implemented against state
<jam> fwereade: initial results look like NotifyWorker is ok with Upgrader returning a state/api/watcher/NotifyWatcher
<jam> well *watcher.NotifyWatcher
<jam> pointer receiver and all that
<fwereade> jam, ok, cool
<dimitern> fwereade: my confusion was: won't the workers *eventually* use only the api as well?
<fwereade> dimitern, eventually, yes, but that particular worker is as low on the priority list as it can be
<dimitern> fwereade: ok, better one at a time, sure
<jam> fwereade, dimitern: Do you want to eyeball that change? https://codereview.appspot.com/10890047/
<dimitern> jam: looking
<jam> https://codereview.appspot.com/10890047/diff2/11001:17001/state/api/watcher/watcher.go
<jam> and https://codereview.appspot.com/10890047/diff2/11001:17001/state/api/upgrader/upgrader.go
<jam> pretty much just exposing the type, and then changing what package I get it from.
<fwereade> jam, LGTM
<dimitern> jam: me too
<jam> thx
<dimitern> (as long as the tests pass ofc)
<dimitern> ;)
<jam> yeah, I ran the tests that were particularly relevant (all state/api and worker)
<mgz> is bug 1199680 critical for release, and is it in fact fixed? (the linked branch is merged)
<_mup_> Bug #1199680: upgrade-juju fails from 1.10 to trunk <juju-core:In Progress by fwereade> <https://launchpad.net/bugs/1199680>
<dimitern> jam: please run them all, just in case
<jam> dimitern: that's what go-bot is for :)
<fwereade> mgz, it is and it is
<mgz> ace.
<jam> mgz: fwereade patch is up
<dimitern> jam: ah, we're getting sloppy now then, ok ;)
<jam> d
<jam> dimitern: I'm just not waiting 8 minutes to submit something and wait 15 minutes for it to merge.
<jam> as long as I have high confidence that it will pass
<jam> it is 9:30pm here and all :)
<dimitern> jam: i'm still afraid of breaking the build, so I still run them pretty much 10-20 times a day (after each pull, after merge, etc.)
<mgz> fwereade: have you filed the other issues you had as blockers yet?
<jam> dimitern: I run subsets of them far more than that
<dimitern> mgz: i think the biggest blocker still is the ppa mongo not working
<mgz> that's not relevent for saucy, no?
<dimitern> mgz: I don't think there's even a build for saucy?
<jam> fwereade: also to confirm, with 1.10 upgrading to trunk, you didn't have any specific other upgrade issues?
<jam> nice catch, btw
<fwereade> jam, I didn't spot anything else
<jam> I'm curious how you debugged it
<fwereade> jam, sorry to say there's only one step... I said to myself "hmm, that sounds like the initial event might be empty"; so I logged the initial event and defanged the actual instance-stopping, tried it out and, yep, empty event
<fwereade> jam, which led me directly to the members field of that lifecyclewatcher and *d'oh!*
<fwereade> jam, so, er... female intuition?
<jam> fwereade: guy who has his head deep in watcher and db interation intuition is my guess
<fwereade> details details :)
<jam> fwereade: so for the Deployer tests, https://codereview.appspot.com/11117043/patch/1/1004 If I understand you correclty, we need to add a bunch of units to a machine, (and maybe some units on another machine)
<jam> and then test that you can Watch the units on your machine, but not the other one
<jam> so https://codereview.appspot.com/11117043/patch/1/1003 "Remove" shouldn't be thinking it has a list of machines to remove, but a list of Units ?
<fwereade> jam, yep, exactly
<fwereade> jam, also needs subordinates to be checked
<fwereade> jam, but, can I pull you away from that to take a look at https://bugs.launchpad.net/juju-core/+bug/1199915 please?
<_mup_> Bug #1199915: api cannot connect, fills deployed machine log with spam <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1199915>
<jam> fwereade: it should? or should not? be able to do something with them?
<fwereade> jam, units assigned to that machine, directly or indirectly, should pass permissions checks for the machine's deployer
<jam> fwereade: not seen on just installing trunk directly?
<fwereade> jam, I'm afraid I haven't done that today, it's all been upgradey
<jam> fwereade: k, I wasn't sure if there were child deployers, but I think that was something where you pulled deployer out of uniter, right?
<jam> fwereade: np
<fwereade> jam, yeah
<fwereade> jam, sorry I didn't get to characterise it better, but I'll need to be off shortly and I wanted to let you know about it before tomorrow
<jam> fwereade: so our Authorizer (today) doesn't have fancy stuff like "is recursively the machine running the given unit". It also doesn't have AuthUnitAgent which we'll need for Upgrader.
<jam> fwereade: I'll give it a look, thanks for pointing it out
<fwereade> jam, and I am currently much exercised by fricking https://bugs.launchpad.net/juju-core/+bug/1190715
<_mup_> Bug #1190715: unit destruction depends on unit agents <juju-core:In Progress by fwereade> <https://launchpad.net/bugs/1190715>
<fwereade> jam, because rog went on holiday without adding the cleaner worker
<jam> fwereade: that is, we have a cleaner worker implemented, but it isn't integrated?
<fwereade> jam, yeah, my integrating it was that patch with the somewhat questionable mocking that I thought was better than nothing, but that collided with roger's connect-to-the-api patch
<fwereade> jam, so I bowed out and left the integration in his hands, but I think it got pushed aside by... whatever that non-critical branch that's sitting in review is :/
<jam> fwereade: so is it as approximately simple as adding a line 152 in cmd/jujud/machine.go inside StateWorker ?
<fwereade> jam, yeah basically
<fwereade> jam, but I feel obliged to actually test it
<fwereade> jam, so Cleaner gets a (sigh) side effect test
<fwereade> jam, and Resumer gets no test, but a comment indicating why
<fwereade> jam, and maybe one day we'll factor that lot cleanly enough that we can test it without SAN damage
<jam> fwereade: so for bug 1190715, this is on the root machine, or on the worker machines?
<_mup_> Bug #1190715: unit destruction depends on unit agents <juju-core:In Progress by fwereade> <https://launchpad.net/bugs/1190715>
<jam> sorry, wrong one
<jam> bug 1199915
<_mup_> Bug #1199915: api cannot connect, fills deployed machine log with spam <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1199915>
<fwereade> jam, that was on the bootstrap node
<fwereade> jam, as a possible shortcut, consider what actually gets written into the conf's API info in a 1.10 bootstrap
<fwereade> jam, ha, I bet I know
<fwereade> jam, 1.10 used the same password for both, but only rewrote the stateinfo one to match the new password it set for itself
<jam> oldapipassword
<fwereade> jam, (I might be wrong ofc, but I *think* all we do is write oldapipassword and use the fact that we used it as reason to change it)
<fwereade> jam, ok that was very poorly expressed
<fwereade> jam, I should read the code I suppose
<jam> fwereade: well, you are allowed to hand things off to other people :)
<jam> I think I at least have your train of thought
<fwereade> jam, no I think that maybe we never even set oldapipassword
<jam> fwereade: in a fresh but running install it is set to ""
<jam> with trunk
<fwereade> jam, ok, and that doesn't logspam?
<jam> oldapipassword="" and I can see active Pinger requests on the RPC
<jam> 2013-07-10 17:51:08 DEBUG juju codec.go:103 rpc/jsoncodec: <- {"RequestId":5,"Type":"Pinger","Request":"Ping","Params":
<jam> so *that* is spammy because we ping every 30 seconds or so and every request generates 2 log entries
<jam> but it isn't failing to connect.
<jam> and it is DEBUG level
<fwereade> jam, ok, well that is good news :)
<fwereade> jam, it's probably just an upgrade issue then
<jam> fwereade: except now I have to figure out how to get a copy of the 1.10 tools :)
<jam> well, 1.10 juju binary
<jam> precise never had it, and the PPA has already pushed out 1.11.2 which means it doesn't expose 1.10.0 anymore (I think)
<fwereade> jam, heh, I hadn't actually updated it from the PPA
<mgz> jam: should all still be in the ec2 bucket, no?
<fwereade> mgz, not the client binary
<jam> mgz: ec2 bucket holds jujud
<jam> not juju
<fwereade> jam, oh for frickin' repeatable builds
<mgz> oh, joy
<jam> http://archive.ubuntu.com/ubuntu/pool/universe/j/juju-core/
<jam> mgz: fwereade ^^
<dimitern> fwereade: bug 1199680 is just committed, not yet released, right?
<_mup_> Bug #1199680: upgrade-juju fails from 1.10 to trunk <juju-core:Fix Released by fwereade> <https://launchpad.net/bugs/1199680>
<jam> the archive is long lived
<jam> even if ppa's are not
<mgz> dimitern: technically, doesn't matter too much
<jam> they wouldn't let us delete stuff from like Hardy
<dimitern> mgz: it might matter for the release manager (ha!) :)
<fwereade> dimitern, I consider it released, because it's a problem with trunk
<dimitern> fwereade: well, just marked it as committed - should I revert it?
 * fwereade shrugs and thinks it's pretty academic in this case
<dimitern> fwereade: i'm ready with the remover
<dimitern> fwereade: if you're still here 10 more minutes, can you take a look (just about to propose)
<jam> mgz: "use of closed network connection" with the 1.10 binary...
<mgz> guuu
<fwereade> dimitern, go for it
<jam> mgz: it worked on second attempt
<jam> heisenbugs and all that
<fwereade> dimitern, and you can take a look at https://codereview.appspot.com/10825044/ while I do, brb
<dimitern> fwereade: sure - there it is: https://codereview.appspot.com/11125043 (disregard the typo in the title - will fix it to Remover before submitting)
<dimitern> mgz, jam: I'd appreciate a look from you as well, if still around
<dimitern> ^^
<mgz> sure
<jam> ugh, "juju --version" broke "juju upgrade-juju" because we now have "--version" defined in 2 places.
<jam> Why didn't the test suite catch this?
<mgz> >_<
<jam> mgz: and of course --version is a global defined as a BoolVar, and "upgrade-juju --version" is a local defined as a StringVar...
<jam> *but* it panics in gnuflag
<jam> which is a terrible traceback.
<mgz> the test suite doesn't run real binaries, which has been a shortcoming in several places...
<jam> mgz: well, it would have caught this, if we had an entry in main suite that tried to install the 'upgrade-juju' subcommand
<jam> the issue is that the args for subcommands aren't added to be processed until you request one of them.
<jam> So "juju upgrade-juju -h" actually panics
<jam> mgz: I wouldn't be terribly surprised to not see a test that "juju upgrade-juju" actually works, even without the "actually run the binary" testing.
<fwereade> dimitern, LGTM, just trivials
<fwereade> ,
<fwereade> mgz, jam, dimitern: sorry, I have to be away now
<dimitern> fwereade: thanks!
<dimitern> fwereade: reviewed as well
<fwereade> dimitern, cheers
<jam> dimitern: why rename results => result?
<jam> Given the return value is containing a plural slice
<dimitern> jam: well, my original intent was to call all bulk result vars "result", since it's a single result struct
<dimitern> jam: i mean you're returning not an array, but a struct which has the array inside
<dimitern> jam: so result.Results or result.Errors seems better
<jam> dimitern: at the top level, you're right there is only one object, but it still feels like a collection of results to me. Though I can't say a feel terribly strongly either way.
<dimitern> jam: it made more sense to me at least in singular, but i can change it back if someone feels strongly against it (roger's not around ;)
<jam> dimitern: as long as each person touching the code doesn't decide to change them all to their way, I don't actually care. It isn't exposed in the external, they are just local variables.
<dimitern> jam: yeah, certainly
<jam> dimitern, mgz: https://codereview.appspot.com/11124044/  Unfuck 'juju upgrade-juju'
<dimitern> jam: looking
<jam> it is just reverting what I just landed
<jam> dimitern: thanks ^^
<dimitern> jam: Remove is a write action - and the func is canRemove
<jam> dimitern: well the func was "canRead" which is obviously wrong. What is the actual auth level control?
<jam> can you remove something but not otherwise modify it?
<jam> write it, etc.
<jam> ?
<dimitern> jam: i changed it canRemove and getCanRemove respectively
<dimitern> jam: do you mind if it stays like that?
<jam> dimitern: I'm slightly concerned about having 20 different "canAddOneLine" "canAppend" "canOverwrite" "canTruncate" that really all just are the difference between "can I view this thing" and "can I modify this thing"
<jam> dimitern: canRemove is fine, as long as it actually has a different auth model than "canModify"
<dimitern> jam: ok, canModify it is then
<jam> dimitern: maybe you know. What causes the api to login with password vs oldpassword?
<dimitern> jam: when it's about to change the password
<dimitern> jam: at first connect
<dimitern> jam: i *think*
<jam> dimitern: I have to shut down for tonight, but I can confirm bug #1199915
<_mup_> Bug #1199915: api cannot connect, fills deployed machine log with spam <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1199915>
<jam> It spins trying to connect with oldpassword
<jam> though on the successful case, It asks to set the password to something new, which doesn't seem to be stored in agent-0.conf
<jam> so I don't know how it expects to login again.
<dimitern> jam: the idea is to connect with the hash of the original agent conf password, then change it and set old to ""
<dimitern> jam: but it's pretty convoluted, i'll take a look tomorrow
<dimitern> i'm off as well
<dimitern> see ya'all tomorrow ;)
<wallyworld> fwereade: hiya, did you have a chance to look at those code reviews?
<davecheney> hello - we finally have a goo 1.11.2 build
<davecheney> i'm just uploading the tools now and doing a test release
<davecheney> then i'll bump the version and try to tag it
<davecheney> wallyworld_: is it possible to bzr branch from a specific revno ?
<davecheney> ie, I want to take rev 1414 as release-1.11.2
<davecheney> /s/take/tag
<wallyworld_> davecheney: i think so, i'll have to check th exact syntax
<wallyworld_> i think it's -c
<wallyworld_> nope
<bigjools> -r
<wallyworld_> i just tried -r and it still pulled in all 1414 revisions
<wallyworld_> ah cobzr stuffs it up
<davecheney> wallyworld_: that doens't surprise me
<davecheney> so, bzr branch -r 1414 lp:juju-core mybranch ?
<wallyworld_> davecheney: yeah, i really need to go back to using straight bzr like i did for lp
<wallyworld_> yes
<davecheney> wallyworld_: thanks for fixing the simple streams snafu
<davecheney> looks like we'll have a release today
<wallyworld_> np
<wallyworld_> i didn't rrally fix anyhting :-)
<wallyworld_> really
<davecheney> wallyworld_: well, you know who to throw tables at to get it fixed
<davecheney> ahasenack: is probably right, we need more logging to show where that happened
<wallyworld_> guess so :-)
<wallyworld_> yes
<davecheney> i'm working on a branch now to show WARNINGs by default
<davecheney> but that means we also show ERRORs by defulat
<bigjools> bzr help revisionspec
<davecheney> we used to quench everything
<wallyworld_> davecheney: i've also sent emails to set up a meeting to put in place processes so this doesn't happen again
<davecheney> wallyworld_: +1
<davecheney> and that has upset the test cases, a lot
<wallyworld_> yes, i am not surprised
<wallyworld_> davecheney: i really think logging should be separate from our CLI
#juju-dev 2013-07-11
<davecheney> wallyworld_: https://code.launchpad.net/~dave-cheney/juju-core/134-tag-release-1.11.2/+merge/174087
<davecheney> ^ tagging, mark II
 * wallyworld_ takes a look
<davecheney> thumper still got man flu ?
<wallyworld_> davecheney: out of curiosity, i listed the current tags on trunk and there's some weird ones there. nothing resembling a juju release
<davecheney> they look like old juju 0.6/7 tags
<davecheney> blame gustavo
<wallyworld_> ok. and we haven't tagged 1.10 etc?
<wallyworld_> seems kinda strange not to have tagged the releases
<davecheney> wallyworld_: yes, this is suckful
<davecheney> i'm trying to redeem myself
<wallyworld_> you don't need to try too hard. you are always pushing to get proper processes in place which i fully agree with
 * davecheney blushes
<wallyworld_> davecheney: sorry for making your pocket all wet
<davecheney> oh, i thought I had a drinking problem
<wallyworld_> that's not mutually exclusive :-)
<davecheney> wallyworld_: can I try submitting this tag change ?
<davecheney> see if it works this time ?
<wallyworld_> sure. i've not used bzr to create tags before. i think it will work
<davecheney> wallyworld_: related, https://docs.google.com/a/canonical.com/document/d/1eeHzbtyt_4dlKQMof-vRfplMWMrClBx32k6BFI-77MI/edit
<davecheney> wallyworld_: https://code.launchpad.net/~dave-cheney/juju-core/134-tag-release-1.11.2/+merge/174087
<davecheney> merged fine, but not tag :(
<wallyworld_> bigjools: any hints? ^^^^^^
<bigjools> wallyworld_: wat?
<wallyworld_> see the backscroll. davecheney wants to tag a rev for the 11.2 release. he added a tag locally, pushed up a mp, merged, but the tags didn't get copied in
 * bigjools looks
<bigjools> it's not merged
<wallyworld_> bigjools: davecheney: the mp says merged though, doesn't it?
<bigjools> it does, but if you look at the branch history, it's not
<wallyworld_> so what would cause that?
<bigjools> because not all the revisions were copied - the tag was not on the top revision
<bigjools> more to the point there's no tag on r1415 but there is one on r1414 which is dimiter's rev
<bigjools> ie the tag was put on a revno that is already merged
<bigjools> rather than the empty commit
<davecheney> bigjools: how would you do it ?
<davecheney> i used
<davecheney> bzr tag ; bzr commit --unchanged
<wallyworld_> i assume the command run locally was bzr tag -r 1214 blah?
<bigjools> commit first then tag
<bigjools> tag works on committed revnos
<bigjools> you can see what you did on here: http://paste.ubuntu.com/5863584/
<bigjools> can you bzr tag lp:juju-core directly?
<bigjools> just tag the revision you just landed
<davecheney> bigjools: i don't think we can, Go bot owns everything
<wallyworld_> davecheney: didn't you want to tag rev 1214?
<davecheney> wallyworld_: no
<wallyworld_> davecheney: if your ssh keys are registered, you can commit directly to juju-core
<bigjools> davecheney: should work though, your key is on it
<davecheney> wallyworld_: ok, i'll do that
<bigjools> don't commit again
<bigjools> just tag
<bigjools> bzr tag -d lp:juju-core
<bigjools> with a -r of course
<davecheney> bigjools: right-o, thanks
<bigjools> nae prob
<fwereade> davecheney, oh hell, I thought mgz was handling 1.11.2... there are a couple of open issues aimed for that milestone
<fwereade> wallyworld_, sorry I fell asleep, I'll do your reviews now
<davecheney> fwereade: ok, how should I fix this ?
<wallyworld_> fwereade: no hurry. it's the middle of the night for you. just do them later!
<wallyworld_> fwereade: btw, will have add-unit with force machines up for review soon
<fwereade> davecheney, depends how far the release has progressed -- if it's done, but just includes bugs we hoped it didn't, I'm fine doing another for 1.11.4 tomorrow I guess?
<fwereade> wallyworld_, yeah, but I've just woken up, may as well do something useful
<davecheney> fwereade: i've beent trying to release this fucker for two weeks
<davecheney> we can always do another release
<davecheney> we can do as many as we like
<fwereade> davecheney, yeah, indeed
<davecheney> the next release number is 1.11.3
<davecheney> but see https://docs.google.com/a/canonical.com/document/d/1eeHzbtyt_4dlKQMof-vRfplMWMrClBx32k6BFI-77MI/edit#
<fwereade> wallyworld_, crap, what "containertype" is set on a new environ machine?
<wallyworld_> fwereade: ""
<fwereade> wallyworld_, ah ok, that does make sense, I expected it to be "none" for a moment
<wallyworld_> all new machines which are not containers get ""
<wallyworld_> none is only for constraints
<wallyworld_> add-unit force machine is up https://codereview.appspot.com/10962046
<fwereade> wallyworld_, cool, I have a review of https://codereview.appspot.com/11019044/ up, I may have misunderstood some things
 * wallyworld_ looks
<wallyworld_> fwereade: afaik, deployment constraints for stuff like mem are not yet supported - there is a todo in the deploy command
<wallyworld_> hence there's no work done with those in th assignment policies right now
<fwereade> wallyworld_, please, what is the difference between a "deployment" constraint and a "provisioning" constraint?
<fwereade> wallyworld_, you keep talking as if there's a distinction but I don't see one
<wallyworld_> sorry, i might be confused. isn't provisioned related to starting a machine?
<wallyworld_> and deployment related to deploying a charm
<fwereade> wallyworld_, sure -- but what's the distinction from the POV of the constraints?
<fwereade> wallyworld_, (deployemtn is a very hairy and overloaded word in juju land :/)
<fwereade> wallyworld_, constraints are still constraints and still expected to apply, whether to a new machine or an existing one
<wallyworld_> not sure what is meant by POV of constraints. right now, when a unit is deployed, constrints are ignored
<fwereade> wallyworld_, sure, but that's just a bug, right?
<wallyworld_> yes
<fwereade> wallyworld_, not a fundamental distinction
<wallyworld_> but this mp is not aout fixing that bug
<wallyworld_> since when it was started, not hardware characteristics were there
<wallyworld_> or so i recall
<wallyworld_> the rest of the constraints is coming
<wallyworld_> this mp is just for th contsainer stuff
<fwereade> wallyworld_, yeah, I see... I worry that this puts the cart before the horse a little
<wallyworld_> only for a short time, and it is not advertised functionality - it's an interim step that is useful to us as developers
<wallyworld_> helps greatly to progress the container work
<wallyworld_> as soon as the hardware for bootstrap machine is done, i'm onto this next step
<wallyworld_> it allows us to more easily sort out the addressability work
<wallyworld_> fwereade: with the mongo query you question - you suggested an alternative but i did reply saying i didn't think it would work. the machineDoc doesn't have any "children" attribute and mongo doesn't support cross document queries
<wallyworld_> hence i need to read in the containers and do a $nin
<wallyworld_> it sucks balls but that's mongo for you
<fwereade> wallyworld_, ha, that would make sense then
<wallyworld_> sadly it appears so :-(
<wallyworld_> fwereade: replied to your comments
<wallyworld_> also, the AddMachineParams is used outside of constraints for add-machine etc
<wallyworld_> so it's ContainerType attribute makes sense
<fwereade> wallyworld_, ok, that's seeming clearer now
<wallyworld_> \o/
<fwereade> wallyworld_, I have a couple of comments on https://codereview.appspot.com/10777044/ -- thoughts?
 * wallyworld_ looks
<fwereade> wallyworld_, (there probably is a good reason, I just can't see it, and because I can't see it the drawbacks seem stark)
<wallyworld_> fwereade: the "--force-machine lxc" syntax is analogous to "add-machine lxc". it means to create a new container on a new instance
<wallyworld_> note i got rid of the leading "/" for add-machine lxc
<fwereade> wallyworld_, yeah, I think the problem is in the implicit creation via these paths, not just the syntax xhosen to do it
<wallyworld_> but we want to support "--force-machine 25/lxc" ?
<wallyworld_> which creates a new container on machine 25
<fwereade> wallyworld_, and ctype is ignored if mid == "" in AddUnits anyway
<fwereade> wallyworld_, yeah, I think so
<wallyworld_> ok, i'll fix that. sorry, i've got so many branches on the go with tweaks in each i may have lost track a bit
<fwereade> wallyworld_, I know the feeling :)
<fwereade> wallyworld_, sorry, though, I'm not quite clear which bit you'll be fixing
<wallyworld_> 1st branch (clean assignment policy): pass in entire constraints struct and for now just use container type
<wallyworld_> instead of just passing in container type. less churn later
<fwereade> +1
<wallyworld_> 3rd branch (add unit force machine): disallow "lxc" and defer splitting up of force machine spec
<fwereade> wallyworld_, I think that's the second branch
<fwereade> wallyworld_, but that sounds perfect :)
<wallyworld_> i think its the 3rd
<wallyworld_> let me check, just gotta switch back to it
<wallyworld_> pipeline is
<wallyworld_>    clean-policy-container
<wallyworld_>    force-machine-containers
<wallyworld_> *  add-unit-force-machine
<fwereade> wallyworld_, it's force-machine-containers; I haven't looked at the 3rd branch yet but so long as it follows what we just discussed I'll be happy :)
<wallyworld_> ah sorry, was getting ahead of myself
<wallyworld_> 3rd one adds force machine to add-unit
<wallyworld_> similar to 2nd
<fwereade> wallyworld_, cool
<fwereade> wallyworld_, if you don't mind I will not look at that one right away because the most obvious comment will be "make it like the second one"
<wallyworld_> sure, np. thanks for the input
<fwereade> wallyworld_, cheers
 * fwereade is just glad he's ~up to date with your reviews before your eod, roughly
 * fwereade will be back a bit later
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: dimitern | Bugs: 6 Critical, 79 High - https://bugs.launchpad.net/juju-core/
<jam> fwereade: when do you sleep? :)
<jam> dimitern: care to chat about when the password stuff triggers? I'm trying to sort out why the api is spinning after an upgrade. I have a thought, but I don't have as much depth here.
<dimitern> jam: sure, as far as I can help
<jam> dimitern: so we have a field OldAPIPassword, but that field is not referenced anywhere in the code. Can you confirm it has never been used?
<jam> I think there was a discussion as to whether we have 2 passwords or just 1 for API vs direct State access
<jam> I don't quite know what the current state is.
<jam> or what is was in 1.10
<dimitern> jam: if it's not used now that's new to me - it used to be used for the inital connection / password changing dance
<jam> dimitern: agent/agent.go line 227 has "info.Password = info.OldPassword"
<jam> Nothing in there touches APIPassword or OldAPIPassword
<dimitern> jam: it's passed in agent conf on bootstrap i think
<dimitern> jam: and then just changed
<jam> dimitern: so, a small bit of confusion before clarity. There is agent.Conf which has OldAPIPassword in it, which is never used (that I can see)
<jam> there is also an *optional* APIInfo pointer
<jam> which can contain something which holds Password and OldPassword
<dimitern> jam: if you take a look at machine.SetPassword - roger's recent changes made it call SetMongoPassword as needed
<jam> api.Info doesn't have a spot for "OldPassword"
<dimitern> jam: because at bootstrap time there's no api yet
<jam> dimitern: so on fresh install of trunk, in agent.conf, I have: oldpassword: "", stateinfo: password: XXX, apiinfo:password: XXX where XXX is the same
<jam> dimitern: on an upgrade, I have: oldpassword: Something, stateinfo: password: somethingdifferent, apinfo:password: ""
<jam> I have the feeling we need to use stateinfo.password for the apinfo.password
<jam> because the code is looping trying to connect with oldpassword and failing.
<dimitern> jam: seems correct yes - api and state passwords should match
<jam> dimitern: so what I *think* happened, in 1.10 we would bootstrap, create the agent.conf without an api password. The State connection would connect, and then immediately change the password, but it doesn't record that fact in the API password, only the stateinfo.password
<dimitern> jam: seems likely, because iirc at that time api password changing was not working correctly
<fwereade> jam, dimitern: as far as I'm aware stateinfo and apiinfo duplicate the same information, apart from the addresses
<dimitern> fwereade: yes, or they should at lest
<dimitern> least
<jam> fwereade: as in, we should just ignore APIInfo.Password and always use StateInfo.Password ?
<fwereade> dimitern, yeah, this is why I bitch and moan about these sorts of OAOO violations
<fwereade> jam, i suspect that's actually worth a try... but probably not sane long-term
<jam> what about the vestigial Conf.OldAPIPassword
<dimitern> oaoo ?
<fwereade> dimitern, Once And Only Once
<dimitern> aah
<fwereade> jam, on balance I think I would not have a problem with a tweak to agent.Conf that effectively dropped all of apiinfo apart from the addresses
<jam> fwereade: is the thought that eventually we don't want to allow direct state access, so we actually want to drop the StateInfo side of that file?
<jam> :w
<fwereade> jam, but agent.Conf itself is kinda weird, what with how it serializes itself and all
<fwereade> jam, yeah, basically
<fwereade> jam, stateinfo is now authoritative but will one day be very infrequently used
<fwereade> jam, using stateinfo solves a problem today but we'd need to do something like always read from stateinfo, and write to both, and still apply liberally fancy footwork to dance through the next upgrade
<fwereade> jam, so... I dunno, I said yes above but probably not for pure or defensible reasons
<fwereade> jam, some of this is academic because apparently dave did a release last night
<fwereade> jam, I think we should at least be aiming for another one, imminently, that *can upgrade* from 1.10 without devastation
<fwereade> jam, and consider that one for promotion to 1.12
<jam> fwereade: so it isn't hard to change agent.OpenAPI to notice that Conf.APIInfo.Password isn't set but Conf.StateInfo.Password is set
<jam> though my immediate result is that it may not be enough
<fwereade> jam, yeah, I feel like there is probably no shortage of edge cases in play
<jam> fwereade: is there a way to get juju to re-read its agent.conf without killing it?
<fwereade> jam, heh, it doesn't do that anyway? well that sucks
<jam> fwereade: afaict I can change it, and it keeps trying with the old content
<fwereade> jam, oh, ffs
<fwereade> jam, the original plan was that we store the separate bits in separate files, and make agent.Conf an accessor for those files, precisely so that agents could update parts of their own conf without falling over
<fwereade> jam, eg so that we can write out state info gleaned from the api and then have our state worker come up because, yay, valid information just appeared
<jam> fwereade: so ATM, the only place that reads the agent conf is at the beginning of cmd/jujud/machine.go: MachineAgent.Run()
<jam> so if there is something that restarts the Agent.Run() it will reread it
<jam> I *think* restarting the API is being done by the runner
<fwereade> jam, IIRC the justification for not doing that was that the possible errors from reading the conf repeatedly were a hassle and dirtied up the api or something
<fwereade> jam, yeah, if the conf is just read once in Run() it's useless for that purpose
 * fwereade has already used up his daily quota of heavy sighs
<dimitern> fwereade: can lend you some, if you need ;)
<fwereade> haha :)
<fwereade> ok, it could be worse; there could be snakes in here with me
<dimitern> :D - with that weather?
<fwereade> dimitern, I seems to have had the uk's two weeks of nice weather since I arrived
<fwereade> jam, so, ok, some sort of change to agent conf has to be in the offing
<dimitern> fwereade: ah, cool - summer time then
<fwereade> jam, because sooner or later we *will* want to rewrite parts of it
<jam> fwereade: I know that today it has a fair amount of cruft in it. But as you say, lets get something that *can* upgrade from 1.10 :)
<fwereade> jam, and when we do that we either have to mess around locking access to it, or we need to break it up into parts that can be read independently
<fwereade> jam, so I leave it up to your judgment what to actually do about it today
<fwereade> jam, dimitern, tyvm for reviews
<dimitern> fwereade: yw
<jam> fwereade: happy to, you always return the favor.
<fwereade> jam, the reason for the repeated startsyncs is the separate state objects... the agentState.Sync ensures that the appropriate event has been delivered to the apiserver's watcher, and at some point after that it will change in the local state
<jam> fwereade: I *really* wish we encoded agent cert differently in the file, it is so hard to read manually.
<fwereade> jam, tell me about it
<jam> fwereade: a simple base64 into a string
<jam> so nice
 * fwereade knows, he really does
<fwereade> jam, you know it'd be even nicer if we just put the cert and key files up directly and manipulated them on the instance
<fwereade> jam, we put that same data up in far too many ways
<fwereade> jam, I think there's another copy with the cert and key concatenated for use by the mongodb server itself
<jam> fwereade, dimitern: so without touching juju-1.11* I tried just editing agent.conf so that it had the same password for agentinfo.password as stateinfo.password. I can see it trying to login, fail, fall back to oldpassword, also fails.
<jam> Is there a reason to believe that StateInfo.password should be different from APIInfo.password ?
<jam> would there be some other field that didn't get set properly?
<dimitern> jam: i'd look in the agent conf rendering in cloud init
<fwereade> jam, last time I asked roger (because I get nervous about this stuff periodically) he said they should be the same
<jam> fwereade: on a fresh trunk install, they are the same
<jam> and it works
<jam> I'm trying to figure out if that password is stored somewhere
<jam> differently in the db, for example
<fwereade> jam, but, upgraded: the state one works, the api one is missing, and the state password doesn't work for the api?
<jam> internally we check entity.PasswordValid which compares utils.PasswordHash(password) to entity.PasswordHash
<jam> fwereade: correct
<jam> fwereade: so I'm thinking that the "I'm connecting to the DB" password is stored in a mongo config, vs the "I'm a Machine-0 agent" is stored inside the DB
<fwereade> jam, that should indeed be the case
<jam> and 1.10 is setting the Mongo password, but not the contents of the entity in the DB
<fwereade> jam, perhaps we were at one stage setting only the mongo password?
<jam> so, essentially, the entity *has* no password in the db.
<jam> inside the db
<fwereade> jam, that sounds very plausible
<jam> and we don't know what the password could be, because we only store password hashes.
<jam> fwereade: so how do we unbreak it?....
<jam> if entity.PasswordHash == "" any password is valid?
<jam> fwereade: as an aside, did we sort out how to install lxc on upgrade?
<jam> as the other 'we can't upgrade' bug
<fwereade> jam, that strikes me as insanity
<fwereade> jam, we did not, because I fell asleep yesterday before talking to thumper
<jam> fwereade: and he's been sick anyway, I believe. Maybe we'll catch him at the standup.
<fwereade> jam, ah ok
<jam> fwereade: here are some issues: We can't change the 1.10 upgrade code. So even if we said "while you upgrade, set these values" it only works when upgrading from trunk, not too trunk.
<jam> So we need a hook at first run of a new binary?
<fwereade> jam, I'm having a ciggie before the standup, brb
<jam> np
<jam> mostly just thinking outloud
<jam> fwereade: confirmed. m.doc.PasswordHash == ""
<fwereade> jam, balls
<fwereade> jam, ok we can fix that, we have a state connection
<jam> fwereade: where does that happen?
<jam> MachineAgent.Run() calls MachineAgent.FixAllTheUpgradeBreaks() ?
<fwereade> jam, basically yeah :/
<jam> mgz: team meeting? https://plus.google.com/hangouts/_/bf3f4cfe715017bf60521d59b0628e5873f2a1d3
<wallyworld_> fwereade: so if you are able to +1 the current 3 branches (or indicate what needs fixing), i'll get tim to do another +1 tomorrow so i can land
<fwereade> wallyworld_, I think what we agreed this morning is fine, I'll add to those CLs
<wallyworld_> fwereade: ty. i've updated the first 2. i need to port the changes forward to the 3rd
<fwereade> wallyworld_, awesome, tyvm
<wallyworld_> np
<mgz> yeay, we have a whole bunch of new public ips for canonistack!
<mgz> it breaks a few things in juju, but hey
<dimitern> fwereade, jam, TheMue: https://codereview.appspot.com/10949046 - deployer facade (done properly this time, i hope)
<TheMue> fwereade: I added the race detection report to the issue. to me it looks like the calling of MgoSuite.SetUpTest() and MgoSuite.TearDownTest() dislike the working in parallel.
<jam> fwereade: just to get your pre-implementation approval before I spend a lot of time on it. We want to add a cmd/jujud/agent.go function which is called something like EnsureValidConfiguration(agent, st *state.State) and that gets called at the beginning of MachineAgent.Run() and ?UnitAgent?.Run()
<TheMue> dimitern: you've got a review
<dimitern> TheMue: thanks
<TheMue> dimitern: yw
<jam> dimitern: reviewing, I'll have some comments.
<dimitern> jam: sure
<dimitern> fwereade: ping
<jtv1> Is there an easy way to verify in gocheck that a multi-line text contains a particular substring?  I tried Matches in multi-line mode but it only seems to work if my pattern occurs in the *first* line of the text.
<dimitern> jtv: prepend '(*|\n)' before the regexp
 * jtv tries
<jtv> dimitern: that fails to parse...missing argument to repetition operator: `*`
<dimitern> jtv: sorry, see this: 	c.Assert(err, ErrorMatches, "(.|\n)*cannot allocate a public IP as needed(.|\n)*")
<dimitern> jtv: ErrorMatches (and Matches I think) prepend '^' and append '$' to the regexp, so this is a way around it
<jtv> Oh ffs...
<jtv> Thanks for pointing that one out...  pretty horrible to leave that kind of subtlety undocumented!
<dimitern> jtv: tell me about it!
<dimitern> jtv: spend half a day to discover that at the time
<jtv> Well then I'm very, very glad that I ran into you.  :-)
<dimitern> ;) np
<jam> dimitern: I'm going to publish my comments, though I want to chat with you about them because I realize I'm *slightly* off in my statements.
<dimitern> jam: ok
<jam> dimitern: so the fundamental thing, is you are generating the set-of-all-units at construction of DeployerAPI time.
<jam> which I think is too early.
<jam> A MachineAgent will be running a long time.
<jam> and it will get units added and removed as time goes on
<dimitern> jam: so getAuthFunc gets called every time an entity is about to be accessed, so we get a fresh list of units that are relevent
<jam> it won't be re-connecting to the API during that time.
<jam> dimitern: your getAuthFunc only checks the set I think
<jam> ah maybe you're right. It looked like it was canned, but I guess the the outer function returns the inner.
<dimitern> jam: no the function it returns only checks the set, but the set is constructed in the beginning of each Remove, SetPasswords or Life calls
<jam> dimitern: so... can we add some tests in deployer_test about the specifics of removing
<jam> so that we know we got our getAuthFunc right?
<dimitern> jam: sounds reasonable, will do
<dimitern> jam: and no, probably WatchUnits is not the best way to get them, but it certainly is the easiest
<dimitern> jam: otherwise, i have to get all principals, for each one get all subs, and then construct the list
<dimitern> jam: william suggested using the watcher as a simpler way to do the same
<jam> dimitern: k. It still feels a bit strange to me. I think the timeout comment still applies.
<dimitern> jam: i can try relying on the initial changes set and not timeout, but blocking seems even worse
<dimitern> jam: in production code especially
<jam> dimitern: (a) timeout of 50ms is way to slow in a real deployment, (b) Given our assumptions about initial event on watchers blocking doesn't seem that bad.
<jam> If it actually blocks, we've got code level problems, right?
<jam> not "oh the database is busy now".
<dimitern> jam: not sure, that's why i'd like fwereade opinion on that
<dimitern> jam: i can change it to block, no problem
<fwereade> dimitern, sorry, breakfasting
<fwereade> dimitern, reading back
<jam> fwereade: you know that you're not allowed regular body functions like eating sleeping or going to the bathroom, right? You're barely allowed to smoke :)
<dimitern> :D
<jam> dimitern: so if the initial Changes event blocks (hard, as in never completes), it would be because our assumption about changes works is wrong
<jam> dimitern: If it just takes a while (2s, 5min) it is because the database is heavily loaded.
<dimitern> jam: so you propose to use LongWait if we need timeouts?
<fwereade> jam, dimitern: ...and so if that's blocking hard, probably so would an explicit get-and-collect
<jam> I could argue for some "unreasonably long" timeout, but that would probably be minutes.
<jam> not even 500ms
<jam> fwereade: I would expect so, yes.
<jam> fwereade: I'm roughly ok using changes as a shortcut for the get+collect because we know changes already has that logic.
<fwereade> jam, dimitern: do you feel it's unreasonable to depend on a guaranteed first event (which may ofc be a channel close in case of error...)?
<dimitern> fwereade: so what's gonna be - blocking read or longer timeout?
<jam> I just think we shouldn't timeout, or should take *much* longer to timeout.
<fwereade> jam, dimitern: yeah, I would prefer to trust the underlyng watcher to do what it should
<jam> dimitern: I slightly prefer blocking read in a "less chance we got this tunable parameter wrong"
<dimitern> fwereade, jam: ok, will change it to blocking then
<jam> dimitern: I hope I'm getting the concept of when to timeout across. Timeout is useful for detecting when you have bad *code*. That means you want to do it in testing. In production you should have already caught the bad code and fixed it, so you can just trust the thing is written correctly (And if it isn't write more tests :)
<jam> dimitern: and then on things that are genuinely uncertain
<jam> like network access
<jam> does that make sense?
<jam> fwereade: you're welcome to correct my thought if you feel differently.
<jam> (I'm certainly willing to debate it)
<dimitern> jam: the worst thing that can happen is, we'll just return late from the method calling getAuthFunc, with an error
<fwereade> jam, that makes sense to me at least in this case
<jam> (13:51:49) jam: fwereade: just to get your pre-implementation approval before I spend a lot of time on it. We want to add a cmd/jujud/agent.go function which is called something like EnsureValidConfiguration(agent, st *state.State) and that gets called at the beginning of MachineAgent.Run() and ?UnitAgent?.Run()
<jam> since you were out
<fwereade> jam, ah sorry
<fwereade> jam, that sounds plausible to me though
<jam> k
<jam> fwereade: manager meeting in 15, right?
<jam> Can I get anything productive done in that time...
<fwereade> jam, oh, god, already, bah
<dimitern> guys, since I'm the OCR today, I'll take a look at the review queue after I land this branch of mine
<jtv> dimitern: I've got some fun ones lined up for you.  :)
<dimitern> jtv: cool :) keep 'em coming
<jam> jtv: do we need to update gwacl on go-bot for your patch to land?
<jam> https://code.launchpad.net/~jtv/juju-core/az-customdata/+merge/174157
<rvba`> jam: yes
<rvba> jam: but don't update right now, you need the fix in jtv's branch to cope with the changes in gwacl.
<jtv> rvba: I figured it'd be either yours or mine, doesn't matter which lands first.  :)
<jam> rvba: do they need to land in lockstep?
<rvba> jtv: it will be yours.
<jtv> jam: rvba's branch and mine?  No, they're decoupled otherwise.
<jam> (the branch can't land without the update but the update can't be done without the branch)
<jam> jtv: gwacl + juju-core
<jtv> But whichever comes first will also necessitate a gwacl update.
<rvba> jam: that's right.
<jtv> So yes, as soon as mine lands, we'll need the gwacl update.
<jam> jtv: actually, as soon as yours is scheduled for landing
<jtv> That works for me too.  :)
<jam> jtv: which means I (or someone likes me) needs to be pinged when you are ready to mark it APproved
<jam> jtv: that's my question about lock-step
<jam> if you can land the code, and then update gwacl, or the reverse it is much easier to do
<jtv> Yes...  unfortunately gwacl upstream is already updatd.
<jtv> *updated.
<jam> jtv: dependency changes are rougly equivalent to db schema changes in LP
<jtv> Yes I understand.
<jtv> dimitern: allenap` had a better way to get multi-line regex matching...  The "s" flag.  It makes newlines match "."  For example, "(?s).*foo.*" looks for any instance of "foo" in the input.
<dimitern> jtv: if it works, great
<dimitern> jtv: with the ^$ already in plce
<dimitern> place
<jam> fwereade, dimitern: Beta1 freeze is August 29th, so 4 months into the cycle.
<jam> Alpha 2 will be July 25th.
<dimitern> cool, soon then
<dimitern> fwereade: ping
<dimitern> abentley: hey, after the changes rvsubmit works fine, just the approvers list could still be duplicated
<abentley> dimitern: I don't understand that.  The approvers are represented as a set, so they can't have duplicates.
<fwereade> dimitern, pong
<abentley> dimitern: Could you point me at the case where this happened?
<dimitern> abentley: I don't know how, but my previous MP had that - 2 LGTMs from 2 people and the list in the commit message contained twice each reviewer name
<dimitern> fwereade: can you take a look please? https://codereview.appspot.com/10949046/
<abentley> dimitern: Can you please give me a link so I can check them out?
<dimitern> abentley: http://bazaar.launchpad.net/~go-bot/juju-core/trunk/revision/1417
<abentley> dimitern: Please give me a link to the merge proposal or the reitveldt code review, not to the branch.
<dimitern> abentley: it's in the commit message, sorry: https://codereview.appspot.com/10944044/
<abentley> dimitern: When I run "bzr rv-submit https://code.launchpad.net/~dimitern/juju-core/066-apiserver-stringswatcher/+merge/173896", it wants to append R=fwereade, jameinel to to bottom, which doesn't give any duplicates.  Did you maybe run rv-submit against this branch before I fixed the duplicate problem?
<dimitern> abentley: ah, sorry - this was before, haven't tested for duplicates after the fix, just ensured the approved revision is set and the bot is happy
<dimitern> abentley: will try it out by adding an extra lgtm next time i land
<abentley> dimitern: Sorry, what?  Were you saying the bug still exists without testing whether the bug exists?
<abentley> dimitern: I fixed the duplicates bug yesterday because you pointed it out.
<dimitern> abentley: no, i looked at the patch and it seemed so, sorry
<abentley> dimitern: Okay.
<dimitern> abentley: didn't claim i've seen the bug, was just asking if it was fixed as well
<dimitern> abentley: thanks again for the quick fix
<abentley> dimitern: I thought you were saying the bug still existed when you said "the approvers list could still be duplicated".
<dimitern> abentley: bad phrasing on my part
<abentley> dimitern: Okay.
<fwereade> dimitern, reviewed, let me know your thougts
<dimitern> fwereade: cheers
<dimitern> fwereade: i don't get why block the removal of alive units?
<fwereade> dimitern, because the deployer gosh-darn-well ought to be deploying them, not trashing them
<fwereade> dimitern, and the provisioner should be doing the same thing in the same situation
<dimitern> fwereade: and if we want to remove something that's stuck?
<fwereade> dimitern, it's not the deployer's responsibility to make a unit dying, but it's the deployer's responsibility to lead it to the grave once it is
<jam> dimitern: fwereade: I'm proposing a patch now which fixes bug #1199915 . It isn't perfectly tested, but I did do a live upgrade test, and it does fix the existing bug
<_mup_> Bug #1199915: api cannot connect, fills deployed machine log with spam <juju-core:Triaged by jameinel> <https://launchpad.net/bugs/1199915>
<fwereade> dimitern, we tell the system we want to remove it by making it dying, not alive
<jam> ugh, wrong one
<jam> I fixed the LXC bug
<jam> bad me
<jam> bug #1199913
<_mup_> Bug #1199913: upgrade from 1.10 to trunk cannot deploy containers <juju-core:Triaged> <https://launchpad.net/bugs/1199913>
<fwereade> dimitern, stuckness is I think orthogonal here
<dimitern> fwereade: ok, fair enough
<dimitern> fwereade: i'd prefer not to do the AssignedUnitNames in this CL though
<dimitern> fwereade: (and I though you said you won't mind the watcher approach ;)
<jam> fwereade, dimitern: https://codereview.appspot.com/10986044/
<fwereade> dimitern, yeah, I think I reiterated there that I don't *mind* it but it would probably still be better as a direct state method; twas a rumination not really a request
<dimitern> fwereade: ok ;)
<fwereade> jam, reviewed
<dimitern> jam: reviewed as well
<rvba> dimitern: Hi! May I add another review to your queue? https://codereview.appspot.com/11166043
<dimitern> rvba: sure, will get to it a bit later
<rvba> dimitern: ta!
<jam> fwereade: so there is fslock, but the actual path to lock is pretty hard to get at. Thoughts?
<jam> fwereade: and yes, MachineAgent will be broken on non-debian-based platforms, but it already is today.
<jam> And whatever we do to make Container a bit happier there *should* give us a guide for apt-get install.
<jam> (I'm hoping )
<jam> Sure RH will be different
<jam> but until we actually support RH.
<jam> mgz mentioned trying to have cloud-init do the work, but we looked at it, and it isn't really designed around calling as a script
<fwereade> jam, the path isn't that hard is it? it's relative to dataDir I thought
<jam> fwereade: "what" dataDir?
<fwereade> jam, *the* dataDir :)
<fwereade> jam, it's a global lock for all units
<fwereade> jam, they all get to it relative to dataDir, ie, usually /var/lib/juju
<fwereade> jam, this may be messy actually :/ we do *not* want the machine agent to go down and wait on that lock while a unit finishes running a long hook. blast
<dimitern> fwereade: should I change the Remover to refuse removing alive entities?
<fwereade> dimitern, yes please, it should just be an additional check once you've got the unit
<dimitern> fwereade: I never have a unit - I need to amend the Remover to have Life() as well
<dimitern> fwereade: (the interface)
<fwereade> dimitern, ha, good point
<dimitern> fwereade: i'm embedding a lifer into the remover
<fwereade> dimitern, I don't think that's too much of an issue in practice? perfectc
<dimitern> fwereade: but since both embed tagger, would that be an issue?
<fwereade> dimitern, just embed lifer instead of tagger
<fwereade> dimitern, it's coherent
<dimitern> fwereade: ah! yes
<fwereade> dimitern, remove only currently makes sense for lifecycle entities anyway
<jam> fwereade: we could use it in a strictly advisory way.
<jam> Try to grab it
<jam> if we fail, still try to install lxc
<jam> worst case, the apt-get install fails
<jam> and we are in the same boat
<jam> best case, we prevent a race
<jam> so try for eg 1 minute
<fwereade> jam, I forget how fslock works, is it plausible that we could grab it before restarting?
<fwereade> jam, and release it after handling upgrade changes on startup?
<jam> fwereade: no, because we don't control the old code.
<fwereade> doh
<jam> fwereade: remember 1.10 is the thing triggering the upgrade
<jam> fwereade: if we had hooks during upgrade, we could tell it to install lxc before restarting :)
<fwereade> jam, ok, sgtm
<fwereade> jam, indeed :)
<jam> fwereade: I updated the CL: https://codereview.appspot.com/10986044/  I'm testing it now, but since I'm "not working in the evening" I figured I would solicit feedback before I finish.
<jam> dimitern: ^^
<dimitern> jam: will look soon
<jam> dimitern, fwereade: confirmed that it solves bug #1199913
<_mup_> Bug #1199913: upgrade from 1.10 to trunk cannot deploy containers <juju-core:Triaged> <https://launchpad.net/bugs/1199913>
<dimitern> jam: great!
<jam> I'm off again (for dinner), I will definitely try to check back in tonight. (I only have 3 more working days before I go on vacation, so I'll try to put in some overtime :)
<fwereade> jam, LGTM
<dimitern> jam: LGTM with 1 comment
<dimitern> fwereade, jam: updated https://codereview.appspot.com/10949046
<fwereade> dimitern, need to take a break for a bit I'm afraid
<dimitern> fwereade: sure, when you can; i can use a break myself
<teknico> marcoceppi: hi, some improvements (hopefully :-) ) to your discourse charm: https://code.launchpad.net/~teknico/charms/precise/discourse/add-cheetah-pkg-misc-fixes/+merge/174248
<marcoceppi> teknico: thanks! I've been hoarding progress on the charm, so this is a good excuse to update the remote branch
<teknico> marcoceppi: you're welcome!
<teknico> marcoceppi: if you don't mind me asking, any specific reason the charm is written in shell script, rather than something saner? :-)
<marcoceppi> teknico: I hack faster in shell :)
<teknico> marcoceppi: oh, I see. It must be painful ;-)
<hazmat> mramm, so re current state of containers
<mramm> hazmat: sure...
<hazmat> mramm, we can create them with add-machine 0/0 but how do we deploy to them or is that post local provider?
<hazmat> is that just going to be a constraint for containerized deploys
<mramm> juju deploy wordpress --force-machine
<mramm> with syntax like 0/lxc1
<mramm> the spelling of all that is up for debate with william and mark tomorrow morning
<hazmat> ic
<hazmat> thanks
* ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: - | Bugs: 6 Critical, 80 High - https://bugs.launchpad.net/juju-core/
<fwereade> mgz, ping
<fwereade> mgz, if you're around, do you know offhand how we push tools to hp cloud on release?
<_thumper_> morning
<thumper> mramm: hi there, I'm semi-functional
<thumper> mramm: so working, but not up to full speed
<mramm> gotcha
<mramm> glad to see you are feeling better!
 * thumper sighs
<thumper> fwereade: ping
<thumper> I guess I wasn't able to articulate why I didn't want the agent stuff merged with tools
<thumper> while it is useful in some way
<thumper> it again brought in all the state and api dependencies
<thumper> which we were trying to get away from
<thumper> the whole point of tools.Tools was to be able to use it *without* importing state
 * thumper thinks on how to untangle
 * thumper wonders how to defer this horrible problem
<thumper> we suck as a team at dependency management
<thumper> the whole interface segregation principle is violated throughout the code
<thumper> with willful abandon
 * thumper has import loops again...
<thumper> due to this lack of segregation
 * thumper thinks
 * thumper gives up on this
 * fwereade hears thumper loud and clear
<fwereade> thumper, hi, btw, hope you're on the mend
<thumper> I think I am
<thumper> just not fully there yet
<fwereade> thumper, glad to hear it, we've been missing you
<thumper> fuzzy head and all that
<fwereade> thumper, don't overdo it :)
 * thumper smiles
<thumper> I'm going to try to work out how to get local tools synced for the local provider without having to build them
<thumper> I have a plan
<fwereade> thumper, frank is not currently working on auto-sync-tools but may do very soon, so please let him know if you start work on it
<fwereade> thumper, sounds like it may be at risk of collision
<thumper> ack
<m_3_> does anybody know what happened to update-alternatives in juju-core-1.11.2-3~1414~raring1
<thumper> m_3_: nope, perhaps dave does, he should be around soon
<m_3_> ack... thanks
#juju-dev 2013-07-12
<wallyworld> niemeyer: how do i set construct a mgo txn to insert a record with an assert stating that there can be no other records already existing with a particular field set to foo?
 * thumper waves at wallyworld
<thumper> wallyworld: summary of my day: it's all shit
<wallyworld> hi there. feeling better?
<thumper> not really
<wallyworld> :-(
<thumper> but starting to feel guilty
<wallyworld> not your fault you're sick
<thumper> no, I know
<wallyworld> i can fill you in a bit later what i've been doing. i want to get some stuff finished first
 * thumper nods
<niemeyer> wallyworld: There's no way to assert on a whole collection at the same time
<wallyworld> niemeyer: ok, thanks. i was afraid of that. i'm finding mongo to be quite limiting in ways like this. i think i've found a workaround
<niemeyer> wallyworld: np
<niemeyer> wallyworld: This isn't MongoDB itself, btw.. this is a restriction on the txn mechanism
<wallyworld> ah ok
<wallyworld> same effect for the developer though :-)
<niemeyer> wallyworld: Yeah, only difference is that I take the blame alone :)
<wallyworld> which means you can fix also :-P
<wallyworld> thumper: did you want a catchup?
<thumper> wallyworld: sorry, was in town for an appt
<wallyworld> https://plus.google.com/hangouts/_/d3f48db1cccf0d24b0573a02f3a46f709af109a6
<jtv> jam: could you update the landing machine's gwacl?
<dimitern> jam1: ping
<dimitern> fwereade: ping
<fwereade> dimitern, sorry, I'm incommunicado for the next hour, sabdfl meeting
<dimitern> fwereade: ooh, good luck then ;)
<dimitern> mgz: you around?
<dimitern> guys, I need to get to the tarmac machine, but couldn't seem to find the mail with the details how to do it
<dimitern> wallyworld: around?
<wallyworld> for a bit. got soccer soon
<dimitern> do you know the tarmac machine's address?
<wallyworld> dimitern: um, yes. let me check. i have a credentials file
<dimitern> wallyworld: when jam1 sent them my pgp key was screwed, so i couldn't decrypt them, but i updated it since
<wallyworld> dimitern: so you have the crdntials?
<wallyworld> i just do a nova list and ssh to machone-o
<wallyworld> dimitern: i just sent you th credentials again but i'm not sure if the key is used is valid
<dimitern> wallyworld: thanks, will check
<wallyworld> fwereade: after your meeting https://codereview.appspot.com/11208044
<dimitern> wallyworld: it says "Error - secret key needed to decrypt message"
<wallyworld> dimitern: hmmm. i will pm you
<dimitern> wallyworld: ok
<jam1> dimitern: jtv: did you get it sorted out?
<jtv> Hi jam1 â I don't know, was still waiting for a reply.  :)
<jam1> it looked like dimitern was trying to do it
<jtv> That was very kind of him.  :-)
<jam1> if you haven't landed your code yet, I can give it a look
<dimitern> jam1: hey, not really - I found out the machine, but it seems none of my ssh keys work (trying ssh 10.55.63.160 with the sshebang doesn't work)
<jtv> Ouch.
<jam1> dimitern: 160 is the juju bootstrap node, you need 190
<dimitern> jam1: ah!
<dimitern> jam1: still the same
<jam1> dimitern: are you going to "ubuntu@10...." ?
<jam1> "dimitern" isn't allowed, but your ssh key should be registered for the "ubuntu" user
<jam1> maybe not... strange
<jam1> 1 sec
<jam1> dimitern: dimitern@kubrik is now there
<dimitern> jam1: let me try
<dimitern> success!
<jtv> I hope my other branch will finish its landing *just* in time...  :)
<dimitern> jam1: now if i can find the $GOPATH..
<jam1> dimitern: sudo su - tarmac ; cd $HOME/trees/src/launchpad.net/gwacl
<dimitern> jam, jtv: ok, gwacl is now updated
<jtv> Thanks!
<dimitern> thanks jam, I need to do it once at least, now I'll know :)
<TheMue> dimitern: thx for lgtm, that has been fast ;)
<dimitern> TheMue: yw :)
<dimitern> fwereade: when you're done, please take a look at https://codereview.appspot.com/10949046/
<fwereade> dimitern, wallyworld, frankban: I'm afraid your reviews will have to wait until later today, I have a couple of things I need to work through with some urgency
<dimitern> fwereade: ok, please ping me when done
<fwereade> dimitern, will do
<dimitern> jam, fwereade, mgz, wallyworld: standup?
<mgz> dimitern: doh
<wallyworld> fwereade: how did your meeting go?
<fwereade> wallyworld, lots of interesting ideas
 * dimitern lunch
<dimitern> fwereade: still busy?
#juju-dev 2013-07-14
<thumper> \o/ small milestone passed
<thumper> machine agent for the bootstrap "machine" of the local provider starts and works (after more munging)
 * thumper works on next step, getting the identity for containers working
#juju-dev 2014-07-07
<thumper> anyone? https://github.com/juju/juju/pull/247
 * thumper remembers that axw and wallyworld are in the states this week
<davecheney> thumper: https://github.com/juju/juju/pull/248/files
<davecheney> waigani: https://github.com/juju/juju/pull/248
<waigani> davecheney: LGTM
<davecheney> waigani: thank
<thumper> davecheney, waigani: https://github.com/juju/juju/pull/249
<davecheney> FUCK
<davecheney> + exit 0
<davecheney> All passed, sending merge
<davecheney> /tmp/hudson6791049747065303228.sh: line 44: /home/ubuntu/jenkins-github-lander/bin/lander-merge-result: No such file or directory
<davecheney> /tmp/hudson6791049747065303228.sh: line 44: /home/ubuntu/jenkins-github-lander/bin/lander-merge-result: No such file or directory
<davecheney> Build step 'Execute shell' marked build as failure
<davecheney> Description set: davecheney 128-update-ssh-terminal
<davecheney> build bot is broken
<davecheney> thanks gz
<davecheney> thanks for testing that
<thumper> :(
<thumper> davecheney: is the bot completely stuffed?
<thumper> like... nothing will land?
<thumper> because that would kinda suck
<davecheney> yes
<davecheney> that
<davecheney> thumper: also, the bot isn't reporting the build failure
<thumper> double :(
<davecheney> +1 to making changes on a friday night
<mwhudson> hm
<mwhudson> i wonder why juju thinks these mustang board only have 1 cpu each
<mwhudson> "hardware: arch=arm64 cpu-cores=1 mem=16061M"
<waigani> davecheney: is this fixed from your crypto update: https://bugs.launchpad.net/juju-core/+bug/1261780
<_mup_> Bug #1261780: go 1.1.2 TLS-enabled client does not accept our CACert <security> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1261780>
<waigani> davecheney: or is it likely to be fixed?
<thumper> davecheney: merged \o/
<thumper> davecheney: well, yours was... waiting for mine
<jam> vladk: you're cutting out a bit, do you want to drop your video?
<jam> dimitern: I have to go help my wife for a sec, back in a couple of minutes
<dimitern> jam, that's ok, i'll be late 15m as well, sorry
<jam> dimitern: k, I'm there now, but I'll just sit around until you get here
<jam> dimitern: also a reminder that you're OCR today
<TheMue> morning
<jam> dimitern: so I set up the 360 reviews for yourself and Frank. I can't actually set one up for myself, but you should have something that you can interact with.
<jam> they have a specific step-by-step of questions to answer.
<dimitern> jam, thanks, will have a look later
<TheMue> dimitern: as OCR one quick PR https://github.com/juju/juju/pull/252 , only about renaming a dir inside /doc
<dimitern> TheMue, looking
<TheMue> dimitern: is a bit in context of the 250 PR by Jesse ;)
<dimitern> TheMue, why contribution and not contrib?
<dimitern> TheMue, it might mean contribution or contributions
<TheMue> dimitern: couter question, why abbreviating if thereâs no need?
<dimitern> TheMue, i'd prefer the plural form unless this will be the only document in that directory
<TheMue> dimitern: renaming it to contributions sounds reasonable, yes
<dimitern> TheMue, LGTM, thanks
<TheMue> dimitern: ok, will change to plural, convinced :)
<dimitern> :)
<davecheney> win14
<jam> dimitern, TheMue, vladk, voidspace: we should also remember that today is the start of a cycle, so we want to be thinking about how we're going to break down the next 2 weeks of work.
<dimitern> jam, right, IPv6 is still a priority?
<jam> dimitern: yeah, AFAIK that's still the plan is to just focus on IPv6 support and push that through
<dimitern> jam, all right then
<rogpeppe> anyone able to rubberstamp this PR, please? it just updates the charm store to use the new package path, gopkg.in/juju/charm.v2
<rogpeppe> dimitern, jam: ^
<dimitern> rogpeppe, which one?
<rogpeppe> dimitern: https://github.com/juju/charmstore/pull/12
<rogpeppe> dimitern: ta!
<jam> rogpeppe: I'm actually not confident in using gopkg.in, I've heard some reservations as it adds a dependency on another 3rd party website that may have some uptime issues.
<dimitern> rogpeppe, liiking
<rogpeppe> jam: we've discussed this a fair amount, and there seemed to be general agreement it was ok
<jam> rogpeppe: if so, then you already have LGTM from frankban
<rogpeppe> jam: we did it together, so that's kinda not really sufficient :-)
<dimitern> rogpeppe, LGTM
<rogpeppe> dimitern: thanks
<jam> dimitern: TheMue: and michael's gone this week for katco's induction sprint, right?
<dimitern> jam, yes, fwereade is gone this week as well
<TheMue> jam: yep
<dimitern> jam, will you be available tomorrow @9 UTC for a g+ with the some of the maas and server teams re juju+maas networking?
<jam> dimitern: I can try, I might have to run an errand at that time, but if I don't I'll happily be there.
<jam> I think I'll be back by then
<dimitern> jam, great, i'll send the invite
<jam> TheMue: i accidentally deleted our meeting for today, but obviously we already had it :)
<TheMue> jam: hehe, I had the alert in my mailbox
<jam> TheMue: dimitern: vladk: standup
<rogpeppe> dimitern, urulama, jam: large-but-mechanical branch that updates juju-core to use the new charm package API: https://github.com/juju/juju/pull/253
<rogpeppe> reviews appreciated before the branch bit-rots...
<dimitern> rogpeppe, will take a look in a bit
<urulama> rogpeppe: why are all bundles turned into CharmArchive, but in juju/conn.go in 207 Bundle is just an Archive?
<urulama> rogpeppe: also in state/api/client.go in line 629 ... if this is because of BundleArchives in the future, is this "Archive" any type (bundle or charm) or must it be called BundleArchive?
<bodie_> morning all :)
<natefinch> morning
<natefinch> a lot of the US devs are in a room in Lexington, MA
<rogpeppe> urulama: ArchiveTo is a method that can apply equally to charms or bundles
<rogpeppe> urulama: and it does the same thing in both cases (write the contents as a zip file to the given file)
<rogpeppe> urulama: so I think it makes sense to call it the same thing (it's possible we might want to make an interface that includes that method in the future)
<rogpeppe> urulama: does that make sense to you?
<mattyw> rogpeppe, ping?
<rogpeppe> mattyw: pong
<mattyw> rogpeppe, quick one - I was searching the juju api for any command that will let me find it a machine id exists
<mattyw> from a client command
<mattyw> looks like status/ fullstatus is all there is for now
<rogpeppe> mattyw: one mo, let me look
<bac> hi sinzui, are you familiar with bug 1316174 ?
<_mup_> Bug #1316174: 'precise-updates/cloud-tools' is invalid for APT::Default-Release <juju-core:Triaged> <https://launchpad.net/bugs/1316174>
<rogpeppe> mattyw: i think you're probably right
<sinzui> bac, a precise machine that will be localhost must add the ctools archive, or the juju stable archive.
<bac> sinzui: i don't think juju/stable is sufficient.
<sinzui> bac. When it was clear many precise users were getting modern juju, but not using modern deps from ctools, I copied the lxc and mongo deps to the juju stable ppa
<sinzui> bac, yes
<sinzui> bac,  which juju are you using?
<bac> sinzui: 1.20
<sinzui> bac? My rebuild?
<bac> which i got from juju/stable and still see the issue.  i can bring up my precise vm and confirm
<sinzui> bac, "apt-cache madison juju-local" to be certain
<sinzui> bac For 3 hours, precise and saucy had a juju-local packages with the wron mongo deps
<bac> sinzui: i do not have access to the precise VM i used on friday so i cannot say for sure what i had installed.
<sinzui> okay
<sinzui> bac 1.20.0-0ubuntu1~12.04.2~juju1 (note the .2 after the series) is the one that was built to replace the broken version
<sinzui> bac: Your vm does need juju stable ppa to get the right mongo. The bug doesn't affect many people anymore, so I was wondering if your machine got unlucky and saw the old package from Thursday
<bac> sinzui: i don't think so.  i have the juju-local you saw.  http://paste.ubuntu.com/7760165/
<bac> s/saw/referenced/
<bac> sinzui: did you get a chance to look at the paste ^^ ?
<sinzui> bac, does the machines have the archive? In the pastebin example, Juju will only install from mongodb from that archive.
<sinzui> sudo add-apt-repository cloud-archive:tools
<sinzui> oh, 2.4.9 in now in the tools. Maybe I need to backport that to juju stable
<bac> sinzui: adding that archive produces the same output as i pasted.
<sinzui> interesting in a bad way bac
<sinzui> bac, does the machine have precise-updated enabled?
<bac> sinzui: yeah.  fwiw, i discovered this doing QA for juju-quickstart.  if we discover juju is not installed we install juju-core and juju-local from juju/stable.  if local on precise requires other repos we need to document that.
<sinzui> bac: agreed
<alexisb> so perrito666, wwitzel3 did you guys have a place to sleep last night?
<wwitzel3> alexisb: yeah, they let perrito666 in his room and I just let them auth my card.
<wwitzel3> alexisb: email this morning says it should be all sorted out now :)
<alexisb> heh
<perrito666> alexisb: I slept on the street :p
<alexisb> nothing like spending 24+ hours in the airport just to sleep on the street
<perrito666> alexisb: nah, they authorized a part of the fee on my card until the card locked them and then they trusted someone from the company would call this AM
<perrito666> btw, non us people http://www.usatoday.com/story/news/nation/2014/07/06/airport-security-electronic-devices-dhs-tsa-johnson/12266639/
<perrito666> you better charge your things before leaving
<cmars> good morning juju land. looks like i'm reviewing today! :)
<TheMue> hmpf, my local provider doesnât start anymore
<jcw4> cmars: yay; wanna look at https://github.com/juju/names/pull/12 ?
<jcw4> :)
<cmars> jcw4, sure, next on my list
<jcw4> cmars: ta
<mgz> anyone know if rick_h__ is working today?
<TheMue> jam: short info, endpoint error is also on local
<dimitern> TheMue, jam, vladk, https://github.com/juju/juju/pull/254 - dummy IPv6 support
<perrito666> why is coludinit log in /var/log, shoulnt it be /var/log/juju/cloud-init-output.log instead?
<TheMue> dimitern: oh, cool, will take a look
<dimitern> TheMue, ta!
<mgz> perrito666: cloud-init isn't juju specific
<jrwren> mgz: rick_h__ is out today, back tomorrow
<perrito666> mgz: tx
<mgz> jrwren: thanks!
<TheMue> dimitern: youâve got a review :)
<dimitern> TheMue, thanks!
<dimitern> TheMue, yeah, that net.JoinHostPort taking a string port sucks :)
<TheMue> dimitern: vladk and I still had comments. while answering to his comment I found a possible problem.
<dimitern> TheMue, yes?
<TheMue> dimitern: IMHO a missing slash when building a URL.
<TheMue> dimitern: storage.go line 157
<dimitern> TheMue, the slash is part of s.path
<dimitern> TheMue, I haven't changed that and the tests still work
<TheMue> dimitern: ah, good to know, thanks
<dimitern> TheMue, np :)
<TheMue> dimitern: and the squeare brackets come with JHP()
<dimitern> TheMue, yep
 * dimitern needs to step out
<jcw4> Thanks cmars ; I have this pending change in juju https://github.com/johnweldon/juju/commit/50dc10fdc4575e0eee0743545541c2a2a174d42f
<jcw4> cmars: which might address your questions on https://github.com/juju/names/pull/12
<cmars> jcw4, thanks, taking a look to see how it will all fit together
<jcw4> tx
<mgz> axw: https://github.com/juju/jenkins-github-lander/pulls
<rogpeppe> here's a PR to add some external verification to charm bundles. anyone care to take a look? https://github.com/juju/charm/pull/11
<rogpeppe> mgz, natefinch, wwitzel3, voidspace: ^
<mgz> anyone know why we have build-essential in our Makefile dependencies? Just for gccgo?
<wwitzel3_> sinzui: I thought I saw a LP regression get linked the other day, something that I had worked on.
<sinzui> mgz, to get make...ha ha
<sinzui> mgz, build-essential predates gccgo. CI installs it separately to get make
<mgz> sinzui: okay, I'll just remove it then I think, really don't want to be installing x11-common and such like when we don't need to
<sinzui> wwitzel3, what do you think you worked on?
<sinzui> wwitzel3, This is the short list of open regressions https://bugs.launchpad.net/juju-core/+bugs?search=Search&field.importance=Critical
<wwitzel3_> sinzui: thanks
<wwitzel3_> sinzui: none of that is anything I worked on, so it might of already been resolved .. William pinged me on something right before I left for the long weekend and I've forgotten what it was.
<wwitzel3_> sinzui: I just remember it was a regression. (or I thought it was)
<sinzui> wwitzel3, https://launchpad.net/juju-core/+milestone/1.19.4 lists the closed bugs from a few weeks ago
<sinzui> wwitzel3, All open regressions https://bugs.launchpad.net/juju-core/+bugs?field.tag=regression
<mgz> wwitzel3, voidspace: the answer to the question, <http://paste.ubuntu.com/7761193/>
<mgz> sinzui: can we throw in --no-install-recommends as well...
<sinzui> mgz, interesting...that is why I keep removing tk
<perrito666> could anyone ptal https://github.com/juju/juju/pull/256 ?
 * sinzui wont let tk, java, or erlang back on to his computer
<wwitzel3> sinzui: thanks for the links
<mgz> sinzui: so, my instinct is to s/build-essential/make/ in the job, and add the --no-install-recommends and remove build-essential in the Makefile
 * perrito666 imagines sinzui with a religious icon shouting "out you devil" to his computer
<sinzui> mgz, +1
<sinzui> mgz, you may want to look at run-unit-tests and fix the other makefile issues for i386
<mgz> yeah, I see some dodgy seds :)
<jcw4> cmars: I addressed your comment on https://github.com/juju/names/pull/12
<cmars> jcw4, got it. about to approve, with some comments on the WIP branch
<cmars> thanks
<jcw4> cmars: perfect... if you like I can open a WIP PR so you can more easily comment
<cmars> jcw4, that'd be great, thanks
<jcw4> cmars: https://github.com/juju/juju/pull/257
<jam> wwitzel3: Do you know about http://irclogs.ubuntu.com/2014/07/03/%23juju-dev.html ?
<jam> wwitzel3: going to Friday: http://irclogs.ubuntu.com/2014/07/04/%23juju-dev.html
<jam> wwitzel3: wwit
<jam> wwitzel3:https://launchpad.net/bugs/1289316%3E
<_mup_> Bug #1289316: lxc not installed from ubuntu-cloud.archive on precise <lxc> <maas> <precise> <regression> <juju-core:Fix Released by wwitzel3> <https://launchpad.net/bugs/1289316>
<perrito666> jam: wwitzel3 is currently afk working with Ian
<jcw4> jam: you can add anchors for the timestamp: http://irclogs.ubuntu.com/2014/07/03/%23juju-dev.html#t02:24
<cmars> jcw4, commented, I wonder if some of the parsing functions in state/action.go should go in names. what do you think?
<jcw4> cmars: let me look; In my mind I've been trying to keep the names and the state package conceptually separate, and make sure that names doesn't need to know anything about the internals of state
<cmars> jcw4, ah, that makes sense. if you're just working with a naming convention in these methods though, maybe that is general enough to go in names?
<cmars> s/methods/functions/
<perrito666> so I have backup and restore packages and there are a bunch of things that both share, what is recommended, do I create a utils package for those? or do I define them in one of the 2 and then import them from the other?
<perrito666> natefinch: voidspace mgz thoughts?
<jcw4> cmars: yeah; maybe I can abstract it enough that it's not state specific
<cmars> jcw4, see if it makes sense & feels right. if not, i'm ok with landing https://github.com/juju/names/pull/12 as is
<jcw4> tx cmars
<wwitzel3> thank you jam
<mgz> sinzui: <https://github.com/juju/juju/pull/258> <https://code.launchpad.net/~gz/juju-ci-tools/drop_build_essential/+merge/225879>
 * sinzui looks
<mgz> I have just push --overwrittedn a tyop in the lp branch
<sinzui> mgz, r=me and merged...check that tip is as you expect
<jcw4> cmars: on the one hand none of the other Tags make an effort to keep the internal representation of _id separate from the public id
<jcw4> cmars: but in this case fwereade also made it clear that the internal representation of the action id shouldn't be exposed
<jcw4> cmars: I've treated those duplicated functions as coincidentally the same rather than fundamentally the same
<cmars> jcw4, fair enough
<jcw4> cmars: but I've also simplified the actionId on the state side now so that it's clean enough to use as the public Id
<mgz> sinzui: thanks! tip looks good, pulled on the jenkins master.
<jcw4> cmars: If it seems okay with you I'll land the names change as it is and keep the possibility of sharing some of the parsing functions in the backlog?
<katco> https://github.com/juju/juju/pull/259
<mgz> katco: trade you, https://github.com/juju/juju/pull/258
<cmars> jcw4, perfect, thanks. i've lgtm'd
<jcw4> cmars: ta
<katco> mgz: LGTM, with reservations ;)
<hasues> Does the instructions in juju-core's README.md on Github pull from -head?  I'm trying to deploy juju, but when i run "juju generate-config" it gives a panic.
<perrito666> hasues: they do, can you pastebin the panic please?
<hasues> perrito666:   http://pastebin.com/fEA2Zp70
<perrito666> hasues: is that linux?
<jcw4> PTAL https://github.com/juju/juju/pull/257
<voidspace> here's that article on go that mgz recommended: https://plus.google.com/u/1/+JonathanLange/posts/Mv5V4r7m9nN
<voidspace> here's that article on go that mgz recommended: https://plus.google.com/u/1/+JonathanLange/posts/Mv5V4r7m9nN
<mgz> voidspace: :P
<voidspace> mgz: I'm sorry
<jcw4> mgz: I thought voidspace was throwing you under the bus a bit with that link
<jcw4> :-)
<voidspace> jcw4: only deliberately....
<jcw4> haha
<perrito666> hasues: ?
<rick_h__> mgz: howdy, this around the lander stuff? /me saw some pull requests but been in the wood without interwebs
<mgz> rick_h__: yeah, I've put up pull requests for all the changes I make to the lander for juju, if you could find a mo to look at them that'd be ace
<mgz> we do a few things differently to juju-gui (mostly around the tests not running till the merge is actually flagged), hopefully the proposals should make that clearer for you
<wwitzel3> wallyworld_: https://github.com/wwitzel3/juju/compare/019-environmentserver
<hasues> perrito666: Yes, it was Linux.  Sorry for the delay
<perrito666> hasues: may I know the version?
 * perrito666 smells a bug
<hasues> perrito666: Of linux or go?
<perrito666> hasues: linux
<hasues> perrito666: Gentoo
<hasues> perrito666: kernel 3.15.0
<hasues> perrito666: Go version 1.2
<mgz> hasues: that's your issue then... you'll need to teach our versions code about gentoo
<rick_h__> mgz: cool will definitely give a look
<hasues> mgz: noted.
<mgz> hasues: see version/osversion.go
<hasues> mgz: Thanks, I was browsing for something of that nature :)
<waigani> alexisb: morning
<alexisb> hey there waigani
<alexisb> on my way
<alexisb> waigani, are you on?
<waigani> alexisb: i was... connection just dropped
<waigani> alexisb: give me 2min
<alexisb> k
<thumper> mramm: oh hai
<thumper> mramm: weren't we going to have a talk earlier?
 * thumper tries to distract himself with work
<lazyPower> thumper: any idea why local provider bootstrap would exit cleanly on utopic, but the api state server wont stay started? It's not even creating the machine-0.log, so it never finishes the init phase before it bails.
<thumper> lazyPower: not off the top of my head
<thumper> lazyPower: but if mongo failed to start, the machine agent wouldn't
<thumper> lazyPower: check the juju-db
<lazyPower> juju-monogd is started
<lazyPower> if you want to follow along - its happening in #juju on canonical irc
<lazyPower> i'm stumped
<thumper> lazyPower: I have a call shortly, but could help after
<wallyworld> thumper: yo
<thumper> davecheney: around?
<thumper> wallyworld: hey
<rick_h__> thumper: how goes?
<thumper> rick_h__: hey
<rick_h__> thumper: hey, back from the woods with no interwebs. Will do my best to get the emails/docs you need from me during work day tomorrow
#juju-dev 2014-07-08
<thumper> menn0: thanks for that bomb
<thumper> not
<menn0> thumper: sorry :)
<waigani> menn0: funny man :)
 * thumper -> lunch
<menn0> thumper, waigani: I initially going to make my email an "isn't it interesting that Dropbox is using Go too" email but couldn't resist when I saw that they had an errors package too.
<menn0> from my brief look, juju/errors seems far more complete
<jcw4> anyone comfortable answering fairly specific watcher implementation questions right now?
<davecheney> waigani: you're OCR
<davecheney> https://github.com/juju/testing/pull/19
<davecheney> +1, or -1
<waigani> davecheney: why not: MgoServer *MgoInstance ?
<davecheney> why make a pointer when we don't need to ?
<davecheney> MgoServer = &MgoInstance{}
<davecheney> is the same as
<davecheney> var MgoServer MgoInstance
<jcw4> what is Aram Havarneanu's irc nick?
<jcw4> (I'm going down the committer list for state/watcher.go, sorted by total commits)
<davecheney> jcw4: aram doesn't work for canonical any more
<jcw4> davecheney: thanks... you're coming up :) you're 7th in the list
<davecheney> jesus
<davecheney> that's scraping the bottom of the barrel
<davecheney> reminds me of a friend
<jcw4> haha
<davecheney> who bills himself as Canberra's 7th best Blues DJ
<jcw4> git log --format=%an state/watcher.go | sort | uniq -c | sort -nr
<jcw4> davecheney: lol
<jcw4> It looks like rogpeppe1 is offline for the last hour
<jcw4> TheMue: online?
<davecheney> jcw4: rog is in the UK
<davecheney> themue is in germany
<jcw4> davecheney: can you feel the cold breath?
<davecheney> jcw4: maybne you should just ask your question :)
<jcw4> okay...
<davecheney> jcw4: it's winter in australia, i have my own cold breath
<jcw4> davecheney: in the state watchers we have a common idiom
<jcw4> w.out is some sort of changes channel
<jcw4> in the watcher loop we have a local var of the same channel type
<jcw4> we expose w.out via a (w* ..Watcher) Changes() api
<davecheney> mmm
<jcw4> when new changes are detected, we assign w.out to the local out var
<davecheney> jcw4: can you point me to an example in the source ?
<jcw4> in state/watcher.go, any loop() implementation
<jcw4> I happen to be looking at actionWatcher around line 1596
<jcw4> one of the select cases in the loop detects a read from the out channel
<davecheney> http://dave.cheney.net/2014/03/19/channel-axioms
<davecheney> the trick is here
<davecheney>                 case out <- ids.Values():
<davecheney>                         ids = &set.Strings{}
<davecheney>                         out = nil
<davecheney> the last line basically says,
<jcw4> davecheney: right, that's what I'm getting to
<davecheney> remove this case from the select loop
<jcw4> davecheney: until a new change comes in right?
<davecheney> uip
<davecheney> yup
<jcw4> k.
<jcw4> so that's all context
<davecheney> that is the only place that assigns out again
<jcw4> my problem is
<jcw4> Changes() reads directly from w.out
<davecheney> mmm
<jcw4> so, for some reason, if I initially load the changes collection, the first read doesn't hit the out <- changes.Values() case
<waigani> davecheney: var MgoServer MgoInstance: MgoServer has type MgoInstance (not *MgoInstance) - it is a zero initialised value, not a pointer. Correct? And arn't pointers cheaper to pass around than values?
<davecheney> waigani: we're never passing it around
<waigani> oh
<jcw4> and then the consumer of the watcher gets the same changes the second time it reads w.Changes()
<davecheney> jcw4: ok
<jcw4> thereafter it works as expected
<jcw4> (I believe)
<davecheney> you're probably right
<davecheney> i don't know what "if I initially load the changes collection"
<davecheney>  means
<davecheney> waigani: nobyd is passing MgoServer around, it's a package level variable
<davecheney> a singleton (if we used that word)
<jcw4> before the for { select {...}} loop I pre-load changes that occurred before the watcher was started
<jcw4> into the local changes set.Strings collection
<jcw4> davecheney: i.e. the expectation is that when you start a new Actions collection, you'll get an initial event notification of all the pending actions, and thereafter you'll be notified when new actions are added
<davecheney> jcw4: that sounds like the expected watcher pattern
<jcw4> what's happening is the pending actions are getting sent twice
<thumper> davecheney: you are in error (a little)
<thumper> davecheney: sorry, missed some context
 * thumper steps away
<jcw4> davecheney: I just wonder if the local out var that we're using for signalling by setting to nil when the event is read shouldn't be an actual member on the watcher, and *that* is the channel exposed by Changes()
<jcw4> davecheney: otherwise we just say; duplicate initial events are to be expected... deal.
<davecheney> jcw4: can you show some code ?
<davecheney> i'm just not feeling it
<jcw4> davecheney: :)
<jcw4> davecheney: I don't blame you
<jcw4> davecheney: gimme a couple minutes
<waigani> davecheney: right. So the definition of passing something = having a receiver for it in a func sig? Why are there no benefits to making a package level var a pointer?
<davecheney> ok, i'll answer the second part first
<davecheney> there is no justification for making it a pointer
<davecheney> so why ?
<davecheney> why allow the possiblity for someone to set it to nil
<davecheney> when we don't need to
<davecheney> the first part
<davecheney> i don't follow
<davecheney> can you say your first question again pls
<waigani> davecheney: when do we get value from using a pointer instead of the value?
<davecheney> if I want to give you a copy of something, i pass by value
<davecheney> if I want to give you a reference to my thing, I pass a pointer
<waigani> yep
<davecheney> but this is not entirely related to the receiver of a method
<davecheney> type V struct {}
<davecheney> func (v *V) F() { fmt.Println("%p", v) }
<davecheney> func main() { var v V ; v.F() }
<davecheney> F is defined on a *V, not V
<davecheney> but Go will altomatically take the address of v if needed,
<davecheney> so if you have a V and that V is addressable, go will do this
<davecheney> (*v).F()
<davecheney> in short: you don't need to declare everything as a pointer type just to call pointer methods on it
<davecheney> (there are exceptions, but they do not apply in this case)
<waigani> oooh
<jcw4> davecheney: fwiw, my test code seems to deadlock
<waigani> I didn't realise, I thought v.F() would fail because it's the wrong type
<davecheney> waigani: so, back at the change
<davecheney> where we had
<davecheney> var MgoServer = &MgoInstance{}
<waigani> yep
<davecheney> that is declare a new MgoInstance value, take it's address and assign that to MgoServer
<davecheney> var can write
<davecheney> var MgoServer MgoInstance
<thumper> davecheney: alternatively though, if you have a *V, it will not dereference to pass to a receiver of type (v V)
<thumper> davecheney: right?
<davecheney> thumper: false
<thumper> oh?
<davecheney> that is the same as saying
<davecheney> v1 := *v
<davecheney> v1.SomeValueMethod()
<thumper> hmm...
<davecheney> lemmie check that
<thumper> I thought it didn't
<davecheney> http://play.golang.org/p/VrpMKUYmwe
<jcw4> davecheney: I'm going to think more on these things... thanks for your help; I know I didn't articulate my question clearly :)
<davecheney> jcw4: show code, receive clarity
<waigani> davecheney: So, just to check I've got the point: There is no point making MgoServer a pointer because, being a package level var, we are by default always referencing the same value whenever we use the var?
<davecheney> yes, that is true
<davecheney> but I don't think explains the point
<jcw4> davecheney: the more I look at it the more I'm convinced the problem is elsewhere http://paste.ubuntu.com/7762857
<davecheney> there is no point in making the MgoServer a pointer, because there is no point in making it a pointer
<waigani> lol
<davecheney> jcw4: as i read it
<davecheney> line 3 is ht eonly place where you can take things out of w.out
<davecheney> and line 36 is the only place you can put them into w.out
<jcw4> davecheney: okay; I kept reading line 36 as the case when w.out was being read
<davecheney> jcw4: you can write line 17 as
<davecheney> var out chan<- []string = w.out
<davecheney> if you like
<davecheney> that may make it clearer
<waigani> davecheney: btw what is OCR? I think image parsing when I read that
<davecheney> On Call Reviewer
<davecheney> i didn't make that one up
<davecheney> blame, fwre
<jcw4> davecheney: I see to explicitly state it as a write only channel?
<waigani> oh shit, am I OCR?
<davecheney> waigani: yup
<waigani> man...
<davecheney> jcw4: if that helps explain what is going on
<davecheney> the watcher code is subtle and confusing
<jcw4> davecheney: it does clarify my understanding of that loop, but I'm still baffled as to how two calls to Changes() can return the same initial set of id's
<jcw4> davecheney: only the first two calls
<davecheney> the most subtle bit is the way we only allow one change event to escape the watcher at a time
<davecheney> jcw4: does your merge function work ?
<jcw4> davecheney: yes
<jcw4> I'll show code
<jcw4> davecheney: http://paste.ubuntu.com/7762872
<davecheney> why is everyone passing *set.Strings ?
<davecheney> unrelated
<davecheney> but sort of related
<davecheney> a set.Strings is a map
<davecheney> and maps are already refernce values
<jcw4> davecheney: I thought of that when I read your other comments
<davecheney> unrelated
<davecheney> save it for another day
<jcw4> davecheny :)
<davecheney> jcw4: are you sure line 43 is every true ?
<jcw4> davecheney: ever true?
<davecheney> if id, ok := id.(string); ok {
<davecheney> if id isn't a string
<davecheney> then your merge function won't behave as expected
<davecheney> oh
<davecheney> there is a check
<davecheney> good
<davecheney> id' write that as
<jcw4> davecheney: afaik it is *always* a string, but if not it should die
<davecheney> switch id := id.(type) {
<davecheney> case string:
<davecheney>  // do string things
<davecheney> default:
<jcw4> davecheney: +1
<davecheney>   fmt.Errorf("id is not of type string, got %T", id)
<jcw4> davecheney: my tests that pass : http://paste.ubuntu.com/7762882
<davecheney> barf
<davecheney> how about just testing the function in isolation
<davecheney> you don't even need to make it a method
<davecheney> it can just be a function
<jcw4> you mean testing the merge() ?
<davecheney> yup
<jcw4> davecheney: that test is the overall watcher test, which seems to correctly handle queued actions before the watcher is started
<jcw4> this whole issue came up because bodie_ 's tests were failing: https://github.com/binary132/juju/blob/752f0b9232f7ef05b45a0efde7ba40cc4578409e/state/apiserver/uniter/uniter_test.go#L803-L825
<jcw4> davecheney: I feel like I'm sucking you into my mess, and I need to isolate the problem further first
<davecheney> jcw4: the solution to that problem is to
<davecheney> log and issue, one per open question
<jcw4> davecheney: like a launchpad bug issue?
<davecheney> jcw4: yup
<davecheney> if there isn't an isue
<davecheney> then it never happene
<davecheney> afaiac
<jcw4> davecheney: okay - your clarification on the channels helped; thank you!
<davecheney> jcw4: np
<davecheney> i don't think i helped
<jcw4> davecheney: it did help; but I think I am looking in the wrong place for the problem
<davecheney> waigani: jcw4 https://github.com/juju/juju/pull/262
<davecheney> thumper: OH MY GOD
<thumper> davecheney: whazzup?
<davecheney> state/watcher.go +751
<jcw4> davecheney: that actually is related to my problem I think
<jcw4> davecheney: if I do var out chan []string = nil, then bodie_'s tests actually pass, but my state ones fail, and I'm pretty sure my state ones are right
<jcw4> davecheney: (in actionsWatcher, not relationUnitsWatcher)
<jcw4> davecheney: I assume your deity name in vain use was about using out:=w.out and then immediately assigning it to nil?
<davecheney> jcw4: yup
<jcw4> :)
<davecheney> if that is actually part of the code
<davecheney> rather than just being lazy and not figuring out the right declaration for out
<davecheney> i'm a monkey's uncle
<jcw4> davecheney: I assumed it was just being lazy; hence my attempt to copy it used the var out chan []string = nil instead  :)
<davecheney> :emoji hmmm
<davecheney> waigani: jcw4 https://github.com/juju/juju/pull/263
<thumper> davecheney:  this assignment: id := id.(type)
<thumper> davecheney: can you explain what it does exactly?
<thumper> why does it reassign back into id?
<davecheney> the id inside the scope of the switch _case_ will be the asserted type
<davecheney> so the inner id shadows the outer id
<thumper> I find that a little confusing that you are effectivly changing "id" to mean the "type of id"
<thumper> I'd rather have a different name for it
<davecheney> true, but consider the alternative
<davecheney> swich id1 := id.(type) {
<davecheney> case string:
<davecheney>  // do something with id1
<davecheney>  // do something else with id1
<davecheney>  // copy some code from another place an use id by mistake
<davecheney>  // oh fuk
<thumper> hang on...
<thumper> I think I get it now
<davecheney> id inside the switch case shadows the original declaration of id
<thumper> ok
<thumper> right, id is still id
<thumper> but it has a defined type
<thumper> not interface
<davecheney> yup
<davecheney> yup
<thumper> ok
<thumper> I'm good then
<davecheney> cool
<davecheney> i agree it is a bit gross to deliberably shadow id
<davecheney> shadowing is contentious
<thumper> I agree it is better than the alternative
<davecheney> but in this case, when you _want_ id to be of type string, or whatever
<davecheney> by shadowing the outer declaration you avoid the footgun of having that other id declaration floating around
<thumper> I found it mildly confusing to work out what was the actual switch on
<thumper> as it doesn't appear clear
<thumper> to start with
<davecheney> you can also say (a bit piously)
<davecheney> i've asserted that id _is_ a string, so it should act like a string
<davecheney> but that sort of statement isn't helpful
<davecheney> ok, time for some lunch I think
<menn0> thumper: thanks for the review. Comments addressed: https://github.com/juju/juju/pull/214
<thumper> kk
<thumper> looking
<lifeless> if that case was a separate function, you wouldn't blink twice about the id parameter being a specific type
<menn0> thumper: thanks very much
<thumper> np
<davecheney> [LOG] 0:25.779 DEBUG juju.testing starting mongo in /mnt/tmp/test-mgo283910080
<davecheney> [LOG] 0:25.780 DEBUG juju.testing found mongod at: "/usr/bin/mongod"
<davecheney> [LOG] 0:25.797 DEBUG juju.testing tls.Dial(127.0.0.1:60070) failed with dial tcp 127.0.0.1:60070: connection refused
<davecheney> [LOG] 0:25.798 DEBUG juju.testing tls.Dial(127.0.0.1:60070) failed with dial tcp 127.0.0.1:60070: connection refused
<davecheney> [LOG] 0:25.865 DEBUG juju.testing started mongod pid 15989 in /mnt/tmp/test-mgo283910080 on port 34290
<davecheney> [LOG] 0:25.871 DEBUG juju.testing starting mongo in /mnt/tmp/test-mgo188237343
<davecheney> [LOG] 0:25.872 DEBUG juju.testing found mongod at: "/usr/bin/mongod"
<davecheney> [LOG] 0:25.959 DEBUG juju.testing started mongod pid 16032 in /mnt/tmp/test-mgo188237343 on port 32859
<davecheney> [LOG] 0:25.965 DEBUG juju.testing starting mongo in /mnt/tmp/test-mgo157584114
<davecheney> [LOG] 0:25.966 DEBUG juju.testing found mongod at: "/usr/bin/mongod"
<davecheney> [LOG] 0:26.053 DEBUG juju.testing started mongod pid 16076 in /mnt/tmp/test-mgo157584114 on port 58000
<davecheney> [LOG] 0:26.058 DEBUG juju.testing s
<davecheney> the test is using the WRONG versino of mongodb
<davecheney> unless I am mistaken, the test should be using
<davecheney> our special juju-mongodb, right ?
<thumper> um...
<thumper> I think it looks for either
 * thumper shrugs
<davecheney> the replica set tests are getting worse
<davecheney> replicaset_test.go:69:
<davecheney>     c.Assert(err, gc.IsNil)
<davecheney> ... value *mgo.QueryError = &mgo.QueryError{Code:0, Message:"couldn't initiate : can't find self in the replset config my port: 60785", Assertion:false} ("couldn't
<davecheney>  initiate : can't find self in the replset config my port: 60785")
<davecheney> [LOG] 0:12.884 DEBUG juju.testing killing mongod pid 27146 in /tmp/test-mgo432122435 on port 60785 with killed
<davecheney> [LOG] 0:12.891 DEBUG juju.testing killing mongod pid 26447 in /tmp/test-mgo041410420 on port 40386 with killed
<jcw4> davecheney: fwiw, my problem earlier is related to the fact that in the state/apiserver/uniter tests the StartSync() method is called on the watcher which forces the watcher to load new events from the database, rather than waiting for notifications from the transaction log
<davecheney> :\
<davecheney> i'm not sure either of those is a correct solution in the formal sense of the word
<davecheney> sounds like choosing the right hammer
<jcw4> :)
<jcw4> davecheney: I remember fwereade saying handling duplicate events should be expected
<jcw4> but when you're trying to write tests that are deterministic it's good to know all the paths that cause events
<jcw4> :)
<TheMue> morning
<jam> morning TheMue
<jam> thanks for updating the calendar dimitern, I was running to eat before the alternate meeting time, but now I can relax a bit.
<dimitern> jam, :) yeah, some mix-up happened
<TheMue> jam: heya,Iâm fighting with the bootstrap/endpoints bug. have been able to simulate it exactly once (first run), all other tries, even when removing everything, succeeded ???
<jam> TheMue: I feel like its a race condition, so I would put sleeps in with what seems appropriate times. (either delay starting the API server, or delay the mongo start, or... ?0
<jam> TheMue: were you able to get a traceback or any more information from the first failure?
<TheMue> jam: yep, thatâs my current approach. I once had troubles with the dbus too, error seems to come here from mongo.
<TheMue> jam: no, only the wonderful output: ERROR EOF :(
<jam> TheMue: so if you grep labix.org/mgo/v2 for "EOF" you can see a bunch of tests that assert it:
<jam>         // With strong consistency, it fails again until reset.
<jam>         err = session.Run("serverStatus", result)
<jam>         c.Assert(err, Equals, io.EOF)
<TheMue> jam: thanks for the hint, will take a look here too
<jam> TheMue: so it appears that EOF happens when the connection to mongo is broken, and you must issue a session.Refresh() in order to recover from it.
<jam> now... *what* would be causing us to disconnect from mongo? Maybe the new ensureMongoServer code?
<jam> Maybe ensureMongoServer is running while the API server is already up?
<jam> causing us to reset our connections.
<jam> If that seems true at all, then I would say we should not be starting the API server until ensureMongoServer has been run.
<jam> TheMue: Nothing concrete here, but IIRC, ensureMongoServer restarts the mongo db into single-user mode so that it can set up proper admin credentials before restarting again.
<vladk> dimitern: what do you think about https://github.com/juju/juju/pull/255
<dimitern> vladk, looking
<dimitern> vladk, that looks fine, but we need the networker in place
<rogpeppe> looking for a review of this, please. anyone able to take a look? https://github.com/juju/charm/pull/11
<rogpeppe> dimitern, jam, TheMue, urulama: ^
<dimitern> rogpeppe, how about peer relations?
<rogpeppe> dimitern: you can't make peer relations explicitly
<rogpeppe> dimitern: so i *think* it's ok to just ignore them
<dimitern> rogpeppe, so there can be no case in which the peer relation definition won't work?
<rogpeppe> dimitern: yeah
<TheMue> rogpeppe: reviewed
<rogpeppe> TheMue: thanks!
<TheMue> rogpeppe: yw
<rogpeppe> dimitern: are you reviewing the branch, BTW?
<dimitern> rogpeppe, sorry, got distracted and now i need to be in a call
<rogpeppe> dimitern: ok
<jam> dimitern: maas call
<jam> ?
<jam> dimitern: sorry I have to go pick up my son, apparently my wife didn't realize I had a call, bb in about 30 min...
<dimitern> jam, sure, np
<jam> dimitern: back
<tasdomas> does the firewaller run on the machine agent only or on the state server as well?
<rogpeppe> dimitern, TheMue, jam: next one in the sequence, review appreciated: https://github.com/juju/charm/pull/12
<TheMue> rogpeppe: will take a look
<rogpeppe> TheMue: thanks!
<TheMue> rogpeppe: reviewed
<rogpeppe> TheMue: thanks!
<Egoist> why juju when i try to deploy charm from local, takes somekind of old code, no the new one, that I changed?
<dimitern> Egoist, what commands are you running exactly?
<Egoist> juju deploy --repository="path to repo" local:precise/"charm name"
<Egoist> full example:
<dimitern> Egoist, it will help if you do $ tree /path/to/local/repo
<Egoist> dimitern: Why tree?
<dimitern> Egoist, the revision to deploy is discovered from the local repo dir by walking it recursively
<dimitern> Egoist,  if the subdirs in the repo are in an unexpected order, the wrong revision will be picked, but you can always specify an explicit revision
<dimitern> Egoist, i.e. juju deploy --repository /path/to/repo local:precise/mycharm-5
<Egoist> what do you mean by unexpected order?
<dimitern> will pick mycharm with revision 5 from the repo
<Egoist> what with something like this:
<Egoist> juju deploy --repository="charms" local:precise/mongodb
<dimitern> Egoist, unexpected, as in you might have multiple copies of the charm in the repo, some with duplicated revisions but different code inside
<Egoist> but i have only one copy of the charm
<Egoist> does it matter?
<dimitern> Egoist, when you run that, it should tell you Added charm local:precise/mongodb-42
<dimitern> Egoist, that's why I asked to see a paste of the repo structure
<Egoist> whait i past you it
<Egoist> wait*
<dimitern> Egoist, thanks
<dimitern> please use paste.ubuntu.com or something similar, not directly in the channel :)
<Egoist> charms/
<Egoist> âââ precise
<Egoist>     âââ mongodb
<Egoist>         âââ charm-helpers-sync.yaml
<Egoist>         âââ config.yaml
<Egoist>         âââ copyright
<Egoist>         âââ hooks
<Egoist>         âÂ Â  âââ charmhelpers
<Egoist>         âÂ Â  âÂ Â  âââ core
<Egoist>         âÂ Â  âÂ Â  âÂ Â  âââ hookenv.py
<Egoist>         âÂ Â  âÂ Â  âÂ Â  âââ host.py
<Egoist>         âÂ Â  âÂ Â  âÂ Â  âââ __init__.py
<Egoist>         âÂ Â  âÂ Â  âââ fetch
<Egoist>         âÂ Â  âÂ Â  âÂ Â  âââ archiveurl.py
<Egoist>         âÂ Â  âÂ Â  âÂ Â  âââ bzrurl.py
<Egoist>         âÂ Â  âÂ Â  âÂ Â  âââ __init__.py
<Egoist>         âÂ Â  âÂ Â  âââ __init__.py
<Egoist>         âÂ Â  âââ config-changed
<Egoist>         âÂ Â  âââ configsvr-relation-changed
<Egoist>         âÂ Â  âââ configsvr-relation-joined
<Egoist>         âÂ Â  âââ database-relation-joined
<Egoist>         âÂ Â  âââ hooks.py
<Egoist>         âÂ Â  âââ install
<Egoist>         âÂ Â  âââ mongos-cfg-relation-broken
<davecheney> nooooooooooooooo
<Egoist>         âÂ Â  âââ mongos-cfg-relation-changed
<Egoist>         âÂ Â  âââ mongos-cfg-relation-joined
<Egoist>         âÂ Â  âââ mongos-relation-broken
<Egoist>         âÂ Â  âââ mongos-relation-changed
<Egoist>         âÂ Â  âââ mongos-relation-joined
<Egoist>         âÂ Â  âââ replica-set-relation-changed
<Egoist>         âÂ Â  âââ replica-set-relation-joined
<Egoist>         âÂ Â  âââ start
<Egoist>         âÂ Â  âââ stop
<Egoist>         âââ icon.svg
<Egoist>         âââ Makefile
<Egoist>         âââ metadata.yaml
<Egoist>         âââ README.md
<Egoist>         âââ revision
<Egoist>         âââ scripts
<Egoist>         âÂ Â  âââ volume-common.sh
<Egoist>         âââ templates
<Egoist>         âÂ Â  âââ backup.py.tpl
<Egoist>         âââ tests
<Egoist>             âââ 00-setup
<Egoist>             âââ 100_configs.test
<Egoist>             âââ 10-unit.test
<Egoist>             âââ 200_deploy.test
<Egoist>             âââ get-unit-info
<dimitern> that'll take a while..
<Egoist>             âââ test_write_log_rotate_config.py
<Egoist> dimitern: tree with charm
<Egoist> why
<TheMue> ouch
<Egoist> "nooooooooooooooo"?
<dimitern> <dimitern> please use paste.ubuntu.com or something similar, not directly in the channel :)
<TheMue> Egoist: use pastbin or similar
<Egoist> ok, sorry
<dimitern> Egoist, right, so now what's in the revision file?
<Egoist> 30
<dimitern> Egoist, and when you run juju deploy --repository charms local:precise/mongodb what's the output?
<dimitern> Egoist, try adding --debug before --repository as well and paste the full output please
<dimitern> vladk, jam, standup?
<jam> dimitern: brrt
<Egoist> dimitern,
<Egoist> dimitern, http://pastebin.com/9XDmiEyq
<dimitern> Egoist, so what's the problem?
<dimitern> Egoist, it seems you've deployed this charm 7 times in the same environment
<dimitern> Egoist, each time you deploy from a local repo, the revision in the charm is used, if possible, if not an unique revision for the environment is picked
<Egoist> but when i make changes in code, juju don't see it, and use some kind of old code
<dimitern> Egoist, that's right, because you need to run juju upgrade-charm
<Egoist> like i add log("something") to code, it doesn't appear
<dimitern> Egoist, not deploy, after you change the charm code in the local repo
<Egoist> if not deploy then what?
<dimitern> Egoist, juju upgrade-charm
<dimitern> Egoist, try juju help upgrade-charm
<dimitern> Egoist, you deploy once, and then upgrade when you need to, otherwise, you can run juju destroy-service mondodb && juju deploy --repository charms local:precise/mongodb
<dimitern> Egoist, but the latter takes more time and it's generally not recommended over using upgrade-charm
<jam> dimitern: Egoist: if you want to use deploy (because you want to wipe what you have/are testing your deployment/etc) does "juju deploy --upgrade" work better at seeing the newer code?
<dimitern> jam, deploy --upgrade is deprecated and useless right now with the api
<Egoist> dimitern: Even if I make juju upgrade-charm i still don't see newer code :/
<dimitern> Egoist, try running juju upgrade-charm --debug mongodb and paste the output?
<dimitern> Egoist, use the same --repository charms argument to upgrade-charm as well
<Egoist> dimitern, http://pastebin.com/JsTHXsyh
<dimitern> Egoist, what's test?
<Egoist> it's mongodb i just call it test
<dimitern> Egoist, is that the name of your service running the mongodb charm>
<dimitern> ok
<Egoist>  yes
<dimitern> Egoist, ok, so does juju status show any errors or issues?
<Egoist> i remove every service i have, and deploy mongodb charm with new code, and it still dont see newer code
<Egoist> and i have relation problem, that i want to fixed using this newer code
<dimitern> Egoist, can you paste the unit-test-0.log to see what's going on during upgrade-charm and deploy? you can use juju scp 0:/var/log/juju/unit-test-0.log .
<Egoist> ERROR exit status 1 (scp: /var/log/juju/unit-test-0.log: No such file or directory)
<Egoist> i have something like this, but when i ssh to machine, this file is exists
<dimitern> Egoist, try juju ssh 0 and then go to /var/log/juju - see what logs are in there (if you removed the service the log might be missing, so in that case can you repeat the steps you did before and get the unit log?)
<Egoist> dimitern, http://pastebin.com/bsrE7deT
<dimitern> Egoist, is this the log after running just deploy?
<Egoist> i think yes
<Egoist> should i execute juju upgrade-charm?
<dimitern> Egoist, so yes please, and paste the log again - but before that, add a log message in config-changed hook to make sure the code has changed or not
<Egoist> dimitern: Look, this is after code changed http://pastebin.com/msGX03VP
<Egoist> nothing changed, i add log("Fresh Code")
<dimitern> Egoist, that can't be the full log
<dimitern> Egoist, I can't even see the upgrade process starting
<Egoist> this is log i've got after execut juju upgrade-charm ...
<dimitern> Egoist, ok, but it's not the full log, where's the rest?
<Egoist> dimitern: http://pastebin.com/6CqS7Aup
<dimitern> Egoist, and what were the exact juju commands you run on your machine locallly?
<Egoist> juju upgrade-charm --repository=charms/ test
<dimitern> Egoist, ok, it seems the issue is deeper, can you please file a bug against juju-core and attach the logs and the output of juju deploy --debug and juju upgrade-charm --debug and juju status to the report?
<Egoist> dimitern: yes, of course
<perrito666> morning people
<dimitern> Egoist, thanks!
<Egoist> dimitern: you mean report bug on launchpad? right?
<dimitern> Egoist, yes, https://bugs.launchpad.net/juju-core/
<wwitzel3> wallyworld_: http://gitfu.wordpress.com/2008/04/20/git-rerere-rereremember-what-you-did-last-time/
<stokachu> what is the use case for setting up mongo replication with a local provider?
<perrito666> hey people, our licence is LGPL but most of our files (all but 3) have a header that say AGPL, this is something to be fixed right?
<rogpeppe> next stage in bundle support - bundle directory reading. anyone fancy taking a look? https://github.com/juju/charm/pull/13
<Egoist> I have a question about openstack and juju
<rogpeppe> dimitern, TheMue, perrito666, wwitzel3, natefinch: ^
<Egoist> why juju create security groups for everyu instance
<Egoist> ?
<rogpeppe> Egoist: it's so that it can manage the exposed ports for each instance individually
<rogpeppe> Egoist: because ec2 does not allow changing the security groups of an instance after it has been started
<rogpeppe> Egoist: you can work around this if you need to
<rogpeppe> Egoist: there's an environments.yaml setting called "firewall-mode", which you can set to "global" which will cause juju to use only a single security group for all instances
<rogpeppe> Egoist: it will mean though that some instances may expose a port that you don't want to be exposed
<tasdomas> natefinch, could you take a look at https://github.com/juju/juju/pull/239 ?
<Egoist> rogpeppe, thank you
<stokachu> https://bugs.launchpad.net/juju-core/+bug/1338179 <- took me 4 minutes to bootstrap with local provider
<_mup_> Bug #1338179: juju 1.20.x hangs at bootstrap <bootstrap> <cloud-installer> <local-provider> <juju-core:New> <https://launchpad.net/bugs/1338179>
<TheMue> rogpeppe: btw, doing your review
<rogpeppe> TheMue: tyvm
<perrito666> natefinch: could you review my tar push so I can merge it?
<perrito666> since its your repo :p
<natefinch> perrito666: haha ok
<TheMue> rogpeppe: btw, did we agrred on the multiline arguments with return values in the next line notation? seen it several times in your code today, just wondering.
<rogpeppe> TheMue: i don't think there was eventual consensus. i just try to write nice looking code
<TheMue> rogpeppe: it still feels strange :)
<rogpeppe> TheMue: the lines were getting too long otherwise
<TheMue> rogpeppe: multiline args are ok for me too, but I still put the return values on the same line as the last arg
<TheMue> rogpeppe: seems I need to familiarize myself with that notation
<rogpeppe> TheMue: doing it this way means you can edit all arguments the same way (similar to the way we'd format a multiline slice)
<TheMue> rogpeppe: yep
<TheMue> rogpeppe: itâs only new, so it catched my eyeâs
<rogpeppe> TheMue: are you still reviewing?
<TheMue> rogpeppe: almost done
<perrito666> natefinch: I am sort of blocked by that review :p
 * perrito666 adds pressure
 * rogpeppe sympathises with perrito666
 * rogpeppe wishes github understood prereqs
<perrito666> rogpeppe: I have nate next to me, beats prereqs
<wallyworld_> don't you mean "beat up" nate?
<rogpeppe> wallyworld_: :-)
<perrito666> wallyworld_: not yet
<wallyworld_> oh, but it will be fun
<perrito666> wallyworld_: well I feel sort of in debt, I could not be typing without his help
<wallyworld_> yeah, but that was yesterday, today is a new day
<TheMue> rogpeppe: youâve got a review
<rogpeppe> TheMue: ta!
<perrito666> wallyworld_: well he saw what I did with the old kb, he can figure what is in it for him
<wallyworld_> lol
<rogpeppe> next in line for BundleArchive - some stuff so that we can more easily reuse some code that was in CharmArchive: https://github.com/juju/charm/pull/14
<rogpeppe> TheMue, dimitern, perrito666, wallyworld_: review appreciated
<wallyworld_> rogpeppe: in the middle of some hacking/reviewing here at the sprint, but can review soonish if no one gets to it
<rogpeppe> wallyworld_: ta!
<wwitzel3> natefinch, axw, wallyworld_: https://github.com/juju/juju/pull/269
<axw> wallyworld_: https://codereview.appspot.com/106490043
<rogpeppe> wallyworld_: change made as requested (i think)
<rogpeppe> wallyworld_: are you still reviewing?
<natefinch> rogpeppe: we were at lunch, he'll be back at his laptop in a minute
<rogpeppe> natefinch, wallyworld_: np
<wallyworld_> rogpeppe: +1, thanks for making the changes
<rogpeppe> wallyworld_: ta
<rogpeppe> wallyworld_: last remaining branch, if you have some time to look: https://github.com/juju/charm/pull/15
<wallyworld_> rogpeppe: sorry, busy pairing right now, can try and look later
<perrito666> go complains when I try to use bytes.Buffer as a writer, I suspect I chose the wrong type or am missing something, ideas?
<rogpeppe> wallyworld_: thanks
<perrito666> fixed
<rogpeppe> perrito666: *bytes.Buffer
<perrito666> rogpeppe: yup
<rogpeppe> perrito666: usual idiom is: var buf bytes.Buffer; foo(&buf)
<perrito666> rogpeppe: that is the way I took
<perrito666> voidspace: link?
<voidspace> perrito666: link to what?
<perrito666> the xkcd/nasa thing
<voidspace> perrito666: http://xkcd.com/1337/
<katco> http://xkcd.com/378/
<katco> be a real programmer.
<voidspace> perrito666: http://blog.xkcd.com/2014/05/30/isee-3/
<wallyworld_> axw: https://bugs.launchpad.net/juju-core/+bug/1338179
<_mup_> Bug #1338179: juju 1.20.x slow bootstrap <bootstrap> <cloud-installer> <local-provider> <status> <juju-core:Triaged> <https://launchpad.net/bugs/1338179>
<wallyworld_> natefinch: https://bugs.launchpad.net/juju-core/+milestones
<wallyworld_> sinzui: ping
<perrito666> natefinch: https://github.com/juju/utils/pull/9 last time I move it :p
<sinzui> hi wallyworld_
<wallyworld_> sinzui: hey, we're almost in the same timezone this week :-) we need to cut a 1.20.1 release this week if possible. can i schedule that with you?
<wallyworld_> we still need to verify some fixes, and assign bugs to milestone etc
<wallyworld_> just wanted to give you a heads up
<wallyworld_> we will be committing fixes to the 1.20 branch
<sinzui> wallyworld_, I can do it any day this week.
<wallyworld_> sinzui: is CI set up still to run the tests on the 1.20 branch for when we commit to it?
<sinzui> wallyworld_, yes...it have been testing the branch since last week
<wallyworld_> sinzui: great thank you, i'll ping you in X days when we are ready to look at cutting the release
<ericsnow> voidspace: http://mumak.net/stuff/your-code-sucks.html
<voidspace> axw: https://code.launchpad.net/~mfoord/juju-core/slow-replset/+merge/221709
<wallyworld_> perrito666: https://bugs.launchpad.net/bugs/1336967
<_mup_> Bug #1336967: Restore doesn't <backup-restore> <ec2-provider> <openstack-provider> <regression> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1336967>
<thumper> waigani, menn0, davecheney: I'm about to get a call for a reference check, hoping it will be done by 11
<thumper> I told them to call back in 15 minutes 20 mintues ago
<thumper> not sure when they are going to call
<menn0> thumper: np.
<thumper> waigani, menn0, davecheney: although they still haven't called, so lets do the standup on time, and if they call I'll just drop off
<thumper> here is the call
<thumper> done
<davecheney> thumper: waigani menn0 I have two PR's for names.Tag changes waiting for revie
<davecheney> if you have the time today
<menn0> davecheney: I will try to get to them soon. I might have to head out for a bit soon though.
<waigani> davecheney: I'll also put it on the list to do today - if someone does not beat me to it
<davecheney> kk
#juju-dev 2014-07-09
<davecheney> waigani: i'm looking at your style guide PR
<davecheney> have you pushed the latest version ?
<waigani> davecheney: give me 5 - just about to push latest
<waigani> davecheney: just writing an example
<davecheney> waigani: ok, protip, don't comment on the review saying "i've done this", unless you've pushed the code
<davecheney> it's confusing
 * thumper agrees
<davecheney> sorry, i know this is yet another github fail
<davecheney> and it requires you to juggle responding to comments and pushing branches concurrently
<davecheney> but it is what it is
<davecheney> thumper: https://github.com/juju/juju/pull/244/files
<davecheney> i need advice on how to handle this
 * thumper loks
<thumper> davecheney: kick it up
<thumper> davecheney: email alexisb and mramm
<thumper> they will say what is good or not
<thumper> I'm not sure what our agreement is
<davecheney> thumper: will do
<davecheney> same
<thumper> school holidays are cramping my style
 * thumper will be in and out for the afternoon
<davecheney> thumper: consider yourself nagged about a policy of using the juju/errors package
<thumper> davecheney: I just pass that nagging on to fwereade
<thumper> :)
<davecheney> thumper: then everything is going swimmingly
<thumper> heh
<davecheney> hey, being a reviewer does suck
<davecheney> you cant' edit the title or the labels
<davecheney> :(
<gsamfira> davecheney: but its very much appreciated :)
<waigani> davecheney: sorry for the confusion. It's up now.
<davecheney> waigani: oh man
<davecheney> you just undid all the stuff I said to drop
<davecheney> shit man
<davecheney> i wanna land this today
<davecheney> i'm going to write some comments
<davecheney> you're going to do what i write
<davecheney> then we're going to merge this
<davecheney> ok ?
<waigani> davecheney: ok
<menn0> davecheney: I wish you hadn't hit merge on my PR... I was about to push an extra unit test (as per my comment)
<davecheney> menn0: sorry
<menn0> davecheney: it just means I have to do another tiny PR with the test change
<davecheney> menn0: ok
<menn0> davecheney: https://github.com/juju/juju/pull/273
<davecheney> menn0: what does \d{14} do ?
<davecheney> i'm not used to that form
<menn0> "\d" == "[0-9]"
<jrwren> 14 digits
<menn0> {14} means "exactly 14 of the last thing"
<jrwren> \d will match utf8 digits as well, in most regex engines
<menn0> you can also do {A,B} which means between A and B of the last thing
<davecheney> yeah, thati's what I thought
<davecheney> but how does \d{14} assert that it's 7 bit ascii
<menn0> davecheney: the fact that we're checking the entire string exactly with a regex that only allows characters that are 7-bit ascii
<menn0> I hadn't heard of the UTF-8 digits thing
<menn0> it's not mentioned in the docs: https://code.google.com/p/re2/wiki/Syntax
<davecheney> menn0: change looks good
<davecheney> but the comment doesn't match the description
<davecheney> would it be simpler to say, the backup file must be juju-backup_NNNNNNNNNNN
<davecheney> or something like that
<menn0> davecheney: yeah, I did consider that the comment could be confusing ... I just want to make sure that future changes ensure that the filename remains 7-bit ascii
<menn0> maybe I'll add a more explicit test...
<davecheney> menn0: you keep saying 7 bit ascii
<davecheney> but don't you mean juju-backup_14decimals ?
<menn0> davecheney: juju-backup_14decimals happens to also be 7-bit ASCII :)
<menn0> that's what I'm getting at
<menn0> obviously it's not clear enough
<menn0> let me rework the PR a little
<davecheney> ok
<davecheney> there are 117 other valid ascii symbols that also fit in the 7 bit range
<jrwren> https://code.google.com/p/re2/wiki/Syntax has an [:ascii:] character class for that.
<davecheney> waigani: did you push that PR again ?
<jrwren> e.g.  \d matches ï¼
<jrwren> [0-9] does not match ï¼
<wallyworld> davecheney: bug 1336891 - can that be fixed by changing our code like in other cases so as not to have to have the backported compiler fix?
<_mup_> Bug #1336891:  intermittent panic: runtime error: invalid memory address <gccgo> <ppc64el> <juju-core:Triaged> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1336891>
<menn0> davecheney: look again please: https://github.com/juju/juju/pull/273
<davecheney> wallyworld: no
<davecheney> wallyworld: we need the compiler fix to land
<menn0> davecheney: I've removed mention of 7-bit ASCII
<davecheney> menn0: LGMT
<menn0> davecheney: the test now checks what is actually important and only accepts a minimal set of characters
<davecheney> that amkes much more sense
<wallyworld> davecheney: ok, i was asked to check because john "fixed" other issues like that by tweaking our code not to tickle the bug
<davecheney> wallyworld: matt sent me the dmesg output
<bigjools> which one of you guys is working on LXCs?
<davecheney> this is the runtime bug we were hitting several months ago
<davecheney> bigjools: that's thumper-afk
<bigjools> ta
<menn0> davecheney: cheers. merging now.
<wallyworld> davecheney: ok, thanks, will update the bug
<davecheney> wallyworld: are we talking about different bugs ?
<wallyworld> davecheney: the bug i typed above
<davecheney> i just put an update on the bug i think we're talking about
<davecheney> wallyworld: same bug
<davecheney> see comment #9
<wallyworld> davecheney: ah sorry yes, my browser copy was out of date
<wallyworld> thanks
<davecheney> :sad chrome
<menn0> jrwren: are you sure \d matches unicode digits? http://play.golang.org/p/fyInDC26-W
<menn0> jrwren: you've got me curious :)
<thumper> bigjools: whazzup?
<bigjools> thumper: there's a new API call coming in the next release that allows you to get a static IP
<bigjools> maas release, I mean
<bigjools> so I figured you might want that for containers
<thumper> bigjools: nice, but that is networking, so dimeter :)
<bigjools> heh
<thumper> but handy, thanks
 * bigjools watches hot potato flung to Malta
 * thumper blows on his hands
<thumper> phew
<sebas5384> did somebody make some benchmarking into the lxc conatiners created by juju-local ?
<sebas5384> *containers
<thumper> sebas5384: at some time... yes
<thumper> why?
<sebas5384> thumper: hey o/
<sebas5384> because i'm running php using a drupal charm
<sebas5384> and I did a benchmarking script
<sebas5384> better say, i execute a benchmarking script in php
<sebas5384> and it seems that its at least 4 or 5 seconds more than the host
<thumper> which version?
<sebas5384> http://www.php-benchmark-script.com/
<sebas5384> php5.3
<thumper> version of juju
<sebas5384> same version in the two machines
<sebas5384> ohh
<sebas5384> the last stable one
<thumper> 1.18?
<sebas5384> that one
<sebas5384> its strange because there are no constraints
<waigani> davecheney: pushed again now
<sebas5384> thumper: maybe is something about filesystem ...
<davecheney> waigani: ta
<davecheney> food, then review
<thumper> sebas5384: the lxc containers are being treated exactly like machines, they do apt-get update/upgrade at the start (for that version)
<thumper> sebas5384: not surprising they are the same
<sebas5384> well yeah, but why then php is slower into the lxc containers :/
<jcw4> davecheney, actionWatcher refactor related to our discussion yesterday : https://github.com/juju/juju/pull/275
<davecheney> jcw4: ta
<jcw4> davecheney: pushing one quick change in 15 seconds
<jcw4> davecheney: okay; updated
<davecheney> jcw4|afk: sorry mate, thats a -1 from me
<stokachu> do i pass a 0 to ToMachineSpec in the ServiceDeploy api in order to have it automatically deploy to a new machine?
<stokachu> or do i need to add-machine and deploy to that machine via the api
<davecheney> stokachu: well, i'd start with ""
<davecheney> and i'd open a bug that the documetation on that method is crap
<stokachu> or will setting NumUnits to 1 make it deploy to a machine whether allocated or not?
<stokachu> ok lemme try these options first
<stokachu> then ill create a bug
<davecheney> stokachu: you cannot specify a number of units less than 1
<stokachu> so right now if i set the numunits to 1 the ServiceDeploy will just deploy the charm without assigning it to a machine
<stokachu> new or one allocated (local provider)
<davecheney> stokachu: sorry, i can't help you
<davecheney> i tried reading the documentatoin but is it crap
<stokachu> lol it is kind of difficult to use the api with the docs :(
<stokachu> on a brighter note ive got a python3 juju client working pretty well https://github.com/Ubuntu-Solutions-Engineering/macumba
<davecheney> \o/
<stokachu> gonna use this for the openstack installer
<stokachu> davecheney, hah, setting ToMachineSpec = "" worked :|
<davecheney> possibly if you don't supply that tag in the json message, you'd get the same effect
<stokachu> i think i tested that and it didnt work, lemme try again
<stokachu> ah my mistake that does work
<stokachu> davecheney, ty
<davecheney> ha
<davecheney> if cannot afford to provide ToMachineSpec then one will be provided for you.
<stokachu> lol
<jcw4> davecheney: it sounds like my description of the solution is the problem right?
<jcw4> davecheney: let me try again and see if it makes more sense
<davecheney> ok
<waigani> davecheney: https://github.com/juju/juju/pull/267 has merge conflicts
<waigani> according to gh
<davecheney> waigani: ta
<davecheney> i'll repropose
<davecheney> someone must have landed something over night
<davecheney> not surprising
<jcw4> davecheney: I updated the PR message, should I update the actual git commit message with the same details too?
<davecheney> jcw4: nah, nobody reads those
<davecheney> well, maybe not nobody
<jcw4> davecheney: lol
<davecheney> but it's fn hard to get access to them
<davecheney> from the PR screen
<davecheney> jcw4: good PR message
<jcw4> davecheney: tx
<davecheney> my repl set tests are getting worse and worse
<davecheney> [LOG] 0:37.995 DEBUG juju.testing tls.Dial(127.0.0.1:47092) failed with dial tcp 127.0.0.1:47092: connection refused
<davecheney> replicaset_test.go:163:
<davecheney>     s.dialAndTestInitiate(c, root, getAddr(root))
<davecheney> replicaset_test.go:69:
<davecheney>     c.Assert(err, gc.IsNil)
<davecheney> ... value *errors.errorString = &errors.errorString{s:"cannot get replica set status: can't get local.system.replset config from self or any seed (EMPTYCONFIG)"} ("cannot
<davecheney>  get replica set status: can't get local.system.replset config from self or any seed (EMPTYCONFIG)")
<davecheney> never seen that error before
<davecheney> i assume it's a race setting up the repl set
<jcw4> tx davecheney ; I'll address the comments that I think are correct.  If you'd like to review my responses on the others and let me know if they make sense to you?
<davecheney> jcw4: ok
<menn0> davecheney: Backups in environment storage: https://github.com/juju/juju/pull/278
<menn0> davecheney: reviewing your PRs now
<davecheney> ta
<menn0> davecheney: LGTM for #265
<davecheney> menn0: ta
<davecheney> menn0: i added a lot of snotty comments on your PR
<davecheney> in general it looks good
<menn0> davecheney: thanks for looking. I'm just responding now.
<menn0> davecheney: I've responded to your snotty comments. Some answers from you are required.
<menn0> davecheney: :-p
<menn0> davecheney: thanks. any thoughts on the first comment?
<davecheney> menn0: waiting for you to push a new revision
<davecheney> also, i just fixed a bug in my PR
<davecheney> when someone calls
<davecheney> back.Backup("some password", "", ...)
<davecheney> that is user is ""
<bigjools> dimitern: around?
<dimitern> bigjools, yeah, barely (need coffee :)
<bigjools> dimitern: well get some coffee and then I can show you Cool New Stuffâ¢
<menn0> davecheney: I see the fix in your PR. Should that mongo connection field even be called Tag?
<menn0> it's all about the user that's connection to mongo
<menn0> is it really a tag?
<menn0> s/connection/connected/
<bigjools> dimitern: dogwalking, speak in a bit
<davecheney> menn0: it's not a user
<davecheney> well
<davecheney> you say user, you think human
<davecheney> but we say tag
<davecheney> as in 'some actor in the juju universe'
<davecheney> now, some tagable things don't make sense to have credentials to talk to mongo
<davecheney> like networks and environments
<davecheney> but machines and units do
<davecheney> menn0: i agree this is apeshit crazy
<menn0> davecheney: I get what tags are about... I guess what I'm missing is what our mongo DB usernames look like
<davecheney> which is why i'm trying to fix it
<davecheney> "user-admin"
<davecheney> "machine-0"
<davecheney> "unit-mysql-1"
<davecheney> ^ these are mongo usernames
<menn0> right. so we are using tag strings as mongo username
<menn0> I didn't realise that.
<davecheney> it gets so much more horrible
<davecheney> "" < this is the admin user
<menn0> your change makes sense now
<menn0> davecheney: I've pushed updated revs for my PR
 * menn0 nods.
<menn0> davecheney: related topic: does it annoy you that it's Backup(password, tag, ...) and not Backup(tag, password, ...)?
<davecheney> menn0: no
<davecheney> it annoys me that it creats a temporary file on disk when this shoud return a io.Reader
<davecheney> but that is for another day
<menn0> davecheney: shouldn't it /take/ an io.Writer instead of returning a io.Reader? I don't see how it can return an io.Reader without either holding the entire backup in RAM or using a temp file.
<dimitern> bigjools, sure
<davecheney> menn0: you can do it either way
<davecheney> you have goroutines, remember
<davecheney> but you are correct, passing the http response write to backup would be simpler
<davecheney> i was thinking some odball io.Pipe thingy
<menn0> davecheney: that PR has an extra rev for a one line fix to the existing code that I noticed btw
<TheMue> morning
<bigjools> dimitern: so got 5 mins
<bigjools> ?
<dimitern> bigjools, sure
<bigjools> dimitern: I added an API in maas 1.6 so you can claim an IP
<bigjools> apparently this is useful to you?
<dimitern> bigjools, great! so we can reserve container addresses explicitly
<bigjools> yes
<bigjools> will point you at a doc, one sec
<dimitern> bigjools, how does it work? does the api call return the address it allocated?
<bigjools> yes
<bigjools> dimitern: so api calls are:
<bigjools> GET /api/1.0/ipaddresses/
<bigjools> to list ones you reserved
<bigjools> POST /api/1.0/ipaddresses/ takes op=release or op=reserve
<bigjools> and I shall dig up more concrete representations of the data you get back in a moment when I can find the damn thing
<dimitern> bigjools, thanks
<dimitern> bigjools, is this advertised via the capabilities/version api call?
<bigjools> dimitern: good question
<bigjools> dimitern: oh HA, I already sent you an email on the 2nd about this
<bigjools> with the API description
<bigjools> dimitern: the latest beta package for 1.6 is in ppa:maas-maintainers/testing
<dimitern> bigjools, sorry, it seems I've missed it
<bigjools> subject "proposed release 1.6.0"
<bigjools> I'll forward it again
<dimitern> bigjools, i'll look into the api docs, cheers
<bigjools> well there's no docs yet, it's just an email
 * bigjools EODs
<bigjools> bye
<rogpeppe> dimitern, wallyworld, jam, davecheney: any chance of a review of https://github.com/juju/charm/pull/15 please?
<TheMue> rogpeppe: looking
<rogpeppe> TheMue: thanks
<TheMue> rogpeppe: nice one, +1
<rogpeppe> TheMue: thanks!
 * TheMue uses the time for reviews when his tests run
<TheMue> jam: ping
<jam> TheMue: yes?
<TheMue> jam: Iâm still at the bootstrap/endpoint issue, because I came a step nearer
<TheMue> jam: but I donât find a solution, maybe youâve got an idea
<jam> TheMue: so we've had a second report of it, so it does sound like something that is a reasonably serious issue in 1.20. It might be associated with some people saying it took *minutes* for mongo to initialize
<TheMue> jam: I can simulate it, when I consume some time between ensureMongo and openState
<jam> wallyworld and axw think that mongo delay is because of the oplog, which they had a patch for
<jam> TheMue: so that triggers it?
<TheMue> jam: yes, tried other cases, but no error. but when adding just some seconds between those too steps I get the same error on local
<jam> TheMue: so the fix (IMO) is that we shouldn't let things like the API actually respond to requests until we have a backing DB
<jam> so something like the "afterUpgradeStep" stuff does today.
<jam> though you might run it by axw or wallyworld since I think they've touched the code most recently
<TheMue> jam: thought in this directy too, yes
<TheMue> jam: ok, will contact them
<jam> TheMue: btw, congrats to Germany... I don't know how they smashed it so hard, but kudos
<TheMue> jam: thanks, we had a lot of fun yesterday evening, and have been astonished on our own
<TheMue> jam: I expected a close fight, maybe 1:0. but 7:1, wow
<TheMue> Wow, need a few seconds, a weird JS almost killed my machine.
<dimitern> vladk, jam, standup?
<TheMue> jam: never done this on LP before. how do I merge https://code.launchpad.net/~niedbalski/golxc/fix-1329049/+merge/225584 and are any steps regarding our dependencies required?
<jam> TheMue: I believe the process for golxc (not managed by a bot) is that you: "bzr co lp:golxc; bzr merge $THEMUESCODE; go test ./...; bzr commit -m "merge $THEMUES most awesome of patches"
<jam> TheMue: actually, the first step you need is to create a kanban card :)
<TheMue> jam: ok, ok, will do this now :D
<TheMue> jam: so, can continue, card exists 8)
<vladk> dimitern, jam: interfaces file in MaaS: https://docs.google.com/a/canonical.com/document/d/18okVil9JGJgGxNlig5Gk8wwtNDSoXtT-Qta6B7gxTI8/edit#
<dimitern> vladk, thanks, will take a look
<jam> TheMue: there is a slight "it depends" which matters on how you have Bazaar set up locally.
<jam> but basically, you want to turn your $GOPATH/src/launchpad.net/golxc back into a pristine trunk
<jam> merge your code into it
<jam> run the test suite,
<jam> commit it, and then push it back to launchpad
<jam> vladk: thx
<Egoist> Hello
<Egoist> is it possible that juju don't use containers on openstack?
<TheMue> jam: thx for your help, eâthing worked fine as wanted
<jam> TheMue: great
<jam> Egoist: "is it possible" you don't have to use containers with openstack, though openstack itself is doing virtualization, right?
<jam> (IIRC, LXC is one of the possible ways that openstack creates virtual machines.)
<axw> katco: #1319475
<_mup_> Bug #1319475: Juju should support new signing format <ec2-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1319475>
<perrito666> I just notices that I didnt see a few of natefinch comments
<alexisb> dimitern, jam : I sent you both a note on IPv6 I need a response asap
<dimitern> alexisb, sure
<alexisb> thanks dimitern
<perrito666> ok natefinch axw I think I addressed all the comments
<natefinch> perrito666: link me again?
<alexisb> wallyworld, ping
<wallyworld> hi
<perrito666> natefinch: ln -s natefinch ./natefinch
<perrito666> natefinch: anything else?
<perrito666> https://github.com/juju/utils/pull/9/files
<wallyworld> alexisb: i think i know what you're going to ping me about
<alexisb> Hi there wallyworld - well done to the team for whipping through a bunch of bugs
<alexisb> on this bug:
<alexisb> https://bugs.launchpad.net/juju-core/+bug/1338179
<_mup_> Bug #1338179: juju 1.20.x slow bootstrap <bootstrap> <cloud-installer> <local-provider> <status> <juju-core:Fix Committed by axwalk> <juju-core 1.20:Fix Committed by axwalk> <https://launchpad.net/bugs/1338179>
<alexisb> was there an actual fix?
<alexisb> given we couldnt repo?
<wallyworld> alexisb: yes, the size of the mongo oplog file was reduced
<axw> (for local only)
<alexisb> are we sure that addresses the bug that was reported?
<wallyworld> alexisb: it was deduced that that was the most likely cause of the extra 2 minutes of bootstrap time
<wallyworld> alexisb: no
<alexisb> ok, thanks
<wallyworld> but it was the most likely and plausible cause
<alexisb> just want to make sure I report back the status correctly
<wallyworld> sure
<alexisb> wallyworld, I could use about 30 minutes of your time today if you can spare it
<TheMue> wallyworld: so it may also fix lp:1338511?
<alexisb> I need an education on bootstrap stuff for the SRE proposal
<wallyworld> bug 1338511
<_mup_> Bug #1338511: api-endpoints fails if run just after bootstrap <landscape> <juju-core:In Progress by themue> <juju-core 1.20:Triaged> <https://launchpad.net/bugs/1338511>
<wallyworld> TheMue: we are looking tat that now
<wallyworld> alexisb: sure, any time
<TheMue> wallyworld: can simulate it on local when consuming some time between ensureMongo and openState
<alexisb> wallyworld, I will send you an invite
<wallyworld> TheMue: thanks, we're looking to see if the previous fixes have helped and what else needs to be done
<TheMue> wallyworld: great, Iâve got to thank
<axw> TheMue: you mean the error occurs when you add a sleep between those two things? or adding the sleep stops it from happening?
<axw> I'm able to get the EOF just about time I bootstrap && api-endpoints
<TheMue> axw: on local I had it only once, since then no more. but when adding a sleep between those two I get it consistently
<axw> huh, weird.
<axw> TheMue: thanks
<TheMue> axw: yw
 * TheMue listens and looks outside, weâve got a warning for heavy thunderstorms
<bodie_> would love a quick LGTM on https://github.com/juju/juju/pull/163 -- it's a little overripe
<bodie_> ( mgz ?)
<TheMue> Now it starts
 * bodie_ is jealous of TheMue 
<bodie_> We had a great one earlier this week -- some of the largest bolts I've ever seen
<bodie_> one must have been about a block away
<alexisb> sinzui, when are we targeting the 1.20.1 release?
<wallyworld> when the devs get their stuff together :-)
<sinzui> alexisb, Ahead of schedule...When I created the milestone, last week, I set 2014-07-17.
<wallyworld> hopefully today we will have the final change committed
<alexisb> sinzui, I am not trying to push, I just want to set expectations from those asking
<sinzui> alexisb, I will release when CI passes the fixes. Maybe tomorrow, more likely Friday
<wallyworld> we will not get the restore stuff done, but there's fixes that we must release asap
<alexisb> sinzui, ack
<sinzui> alexisb, We can say before Tuesday...and I may have jury duty that day
<alexisb> lol
<alexisb> wallyworld, is the plan to release the restore stuff in 1.20.2?
<wallyworld> alexisb: yeah, unless we can somehow make it done for 1.20.1
<wallyworld> alexisb: ordinarily we could delay 1.20.1, but the fixes we need to release are critical
<alexisb> ok, cool, thanks for the info guys, sorry I am behind :)
<alexisb> wallyworld, I agree that 1.20.1 has enough critical fixes we need to get it out as soon as we can
<wallyworld> alexisb: especially since the users can't even bootstrap a maas env etc
<sinzui> wallyworld, my new stable release rule is to set the next release 2 weeks after the last release. We aren't committing to it, but users can see the milestone and know we are thinking about it
<wallyworld> sinzui: +1 to that. in this case we are pulling the trigger early due to those bugs
<wallyworld> sinzui: so maybe we could even target 17/7 for the 1.20.2 release still
<sinzui> yep, and we look good because we delivered early
<wallyworld> \o/
<wallyworld> so stable releases a week apart
<wallyworld> just this once
<wwitzel3> wallyworld: https://github.com/wwitzel3/juju/tree/020-policy-deployer
<katco> axw: https://github.com/crowdmob/goamz
<alexisb> jam, I will be late to the cloudsigma call
<katco> niemeyer: hey, got a sec?
<niemeyer> katco: Heya, sure
<katco> i was beginning to look at implementing v4 of AWS sigs
<katco> and i happened upon a fork w/ the code written: https://github.com/crowdmob/goamz
<katco> i saw that you had made some commits; trying to figure out what the best path forward is... bringing this back into the project proper, or letting this fork go? opinions?
<niemeyer> katco: I don't really have a great opinion on the subject, mainly for lack of information
<niemeyer> katco: I don't know how that fork has changed in comparison to what we have at goamz, or which incompatibilities were made
<niemeyer> katco: I know we have fundamental issues in goamz's API which need fixing, though
<niemeyer> katco: I've been wishing to work on goamz2 for some time, and even started to solve a few orthogonal problems that are dependencies of a better API
<niemeyer> katco: But haven't started the v2 proper yet
<niemeyer> katco: I do know how it should look like, though
<katco> niemeyer: gotcha
<katco> niemeyer: so it sounds like, best not to merge this work back in; it appears to have changed significantly enough that a v2 from you would be duplicate work
<niemeyer> katco: It's not that.. I don't know what "this work" comprehends
<niemeyer> katco: I do know that if they're just improvements on top of the current API, they are not solving the real issues
<niemeyer> katco: Well, that's not correct either, sorry
<niemeyer> katco: They are not solving the fundamental issues which v2 ought to..
<niemeyer> katco: (certainly solving *someone's* real issues)
<axw> niemeyer: right now we're just interested in implementing the v4 signing algorithm (to support cn-north-1, I think?)
<jcw4> niemeyer: is your vision for v2 captured where I can read it?
<axw> +1
<niemeyer> jcw4: I have talked before in written form.. just need to find the notes
<jcw4> cool
<niemeyer> jcw4: The basis is that we have a static API that prevents access to underlying information of what is an extending API
<niemeyer> jcw4: We need a mechanism that both offers arbitrary new fields to be injected in requests, and arbitrary new fields to be pulled from answers
<jcw4> hmm, and gracefully handling 'schema' differences?
<niemeyer> My plan is to have a two-layered approach, similar to what I've done in the Launchpad package (lpad), but not quite exactly it
<niemeyer> So that we have a static layer offering comfortable access to functionality, which sits on top of a dynamic layer which offers access to anything
<niemeyer> and they both can be used together, rather than having to opt for one or the other
<jcw4> niemeyer: +1 I see
<niemeyer> This allows people to get unblocked quickly when they face limitations, instead of having to fork every time
<jcw4> the dynamic layer sounds like it could possibly be abstract enough to be reused in different APIs?
<niemeyer> axw: If the fork has v4 implemented, we should merge it in
<niemeyer> axw: Just need to see if the contribution agreement was signed
<niemeyer> jcw4: Yes, definitely
<niemeyer> jcw4: Part of the dynamic layer is xmlpath
<niemeyer> jcw4: Or rather, based on it
<niemeyer> jcw4: That's why it was written, in fact
<jcw4> very interesting
<katco> niemeyer: apologies; at a sprint, and lots of unrelated talk in the room :p
<niemeyer> jcw4: But I never moved forward with the rest of the plan
<jcw4> niemeyer: priorities I guess, but it does sound useful and cool
<katco> niemeyer: so you're proposing to only merge the v4 code in from the fork?
<niemeyer> katco: Well, I'm just proposing that if v4 is indeed necessary and it is in the fork, we should merge it assuming that whoever wrote it signs the contribution agreement
<niemeyer> katco: I'm not saying "just" that
<niemeyer> katco: It really depends on what else is at stake
<katco> niemeyer: understood. the only snag i can see is that the way they're doing signing is quite different (i.e.: better) than how we are doing it atm
<katco> niemeyer: so it would be a drop-in replacement.
<katco> niemeyer: and then there's the contributor question; maybe it's just easier to dupe the change and wait on your v2
<katco> niemeyer: i'll get some more input from the team, and we'll make a decision. tyvm for your input :)
<niemeyer> katco: Thanks for asking
<axw> TheMue: I've gotten to the bottom of the EOF error, and have a fix. Going to reassign to myself
<TheMue> axw: great, good to hear. will make the maas folks happy
<axw> TheMue: would you please review this tiny change? https://github.com/juju/juju/pull/279
<axw> oops, I left a debug statement in
<TheMue> axw: ping me when itâs removed
<axw> TheMue: fixed
<TheMue> axw: ok, looking
<TheMue> axw: no?!? that easy?
<axw> TheMue: indeed :)
<TheMue> axw: fantastic, +1, reviewed
<axw> thanks
<TheMue> axw: yw, Iâve got to thank you
<sinzui> wallyworld, the functional-backup-restore tests failed for the 1.20.1. Either we fix it soon or we give up and say no stable release of juju ever supported backup
<wallyworld> sinzui: that functionality is still being worked on
<sinzui> fab
<wallyworld> sinzui: perrito666 is the man to bug :-)
<perrito666> wallyworld: oh that was so managerial :p
<wallyworld> restore is being translated from bash -> go
<wallyworld> and with the rewrite, robustness etc added
<perrito666> wallyworld: sinzui I am sprinting once again on this thing
<wallyworld> sinzui: it will be ready for 1.20.2, perrito666 promises
<perrito666> wallyworld: I swear you are growing pointy hear
<perrito666> sinzui: please remind me, --ha or --ha-backup?
<perrito666> nevermind
<perrito666> found it
<sinzui> wallyworld, perrito666. Don't make those promises. Not because I don't have faith in your skills, but restore was broken by HA development...someone else is always breaking this feature. I don't think unit tests can be written to prevent a HA change from breaking restore an hour after you fix it.
<sinzui> perrito666, --backup and --ha-backup as of today :(
<wallyworld> sinzui: i forgot the smiley before, here it is now :-)
<TheMue> So, last job of today before looking football again (to see whoâll be our competitor on Sunday) a PR https://github.com/juju/juju/pull/281
 * TheMue waves a good bye to the channel o/
<axw> enjoy :)
<TheMue> axw: thx, will do
<wallyworld> axw: https://github.com/juju/juju/pull/282
<axw> wallyworld: looking
<thumper> mramm: you around?
<mramm> yes
<thumper> mramm: got time to chat?
<mramm> thumper: sure
<mramm> https://plus.google.com/hangouts/_/canonical.com/mark
<waigani> thumper: I want to setup a fake pub key to test. I've got keysDir := c.MkDir(). Now, I want to copy testing/sshdata/authorized_keys/id_rsa.pub into it. Are there any test helpers I should be using?
<thumper> waigani: not sure, take a look at the auth keys tests
<thumper> see if there is something reusable there
<waigani> thumper: good point, ok
<waigani> thumper: next question. I'm not sure how to create a failing test. ProvisionMachine will always succeed, even if you pass it a non-standard path to check for keys - even if that path does not exist. It just tries to find keys to upload and if it can't it continues on without them.
<thumper> waigani: mock out the api
<waigani> thumper: okay, and check that the file path being passed in is found?
<thumper> waigani: well, what are you trying to test?
<waigani> thumper: that ProvisionMachine will upload a public key passed to it, that is not in ~/.ssh
<thumper> bug reference?
<waigani> thumper: https://bugs.launchpad.net/juju-core/+bug/1270466
<_mup_> Bug #1270466: allow specifying a key when doing manual provisioning <manual-provider> <ssh> <juju-core:Triaged by waigani> <https://launchpad.net/bugs/1270466>
<waigani> the fix is straight forward
<thumper> waigani: can you push your branch as it is to github so I can see it?
<waigani> thumper: sure
<waigani> thumper: sorry here is the diff https://github.com/waigani/juju/compare/manual-prov-key
<waigani> thumper: I have not touched the CLI part yet obviously, but that will just be adding an extra flag/arg to pass in the key
 * thumper looks
<waigani> actually, maybe I should be adding the test to authkeys
<waigani> actually, custom keys have already been covered in authkeys tests...
<thumper> if the adding of custom keys has already been tested elsewhere, don't do it again
<waigani> right
<thumper> the real test is that the right key is read, and passed through
<waigani> yep, I don't see that actually being tested in authkeys
<waigani> so I'll copy testing/sshdata/authorized_keys/id_rsa.pub into a tmp location and pass that in and check that it gets read
#juju-dev 2014-07-10
 * thumper off to visit the vet, bbl
<davecheney> lucky(~/src/github.com/juju/juju/environmentserver/authentication) % vim authentication.go
<davecheney> lucky(~/src/github.com/juju/juju/environmentserver/authentication) %
<davecheney> why does this new package have ZERO tests ?!?
<davecheney> why is there a whole package for one file
<davecheney> and two types !?!
<davecheney> no, not two type
<davecheney> two functions
<rick_h__> davecheney: because it's waiting for you to write the rest of it?
<rick_h__> :)
<davecheney> rick_h__: i didn't add that
<davecheney> me is frustrated with the proliferation of tiny packages
<davecheney> ffs people, this isn't java
<davecheney> menn0: https://github.com/juju/juju/pull/284
<davecheney> small PR for your lunchtime perusal
<menn0> davecheney: will look right after this meeting (if it happens)
<davecheney> oh shit
<davecheney> i was going to take a screenshot of the hangout screen that showed 12:05
<davecheney> but the it ticked over to 12:06
<davecheney> and it didn't hav the ring to it
<davecheney>         info.SetAPICredentials(configstore.APICredentials{
<davecheney>                 User:     apiInfo.Tag.Id(),
<davecheney>                 Password: apiInfo.Password,
<davecheney>         })
<davecheney> ohh,
<davecheney> here is an intersting one
<davecheney> we have a Tag, so "user-dave"
<davecheney> but the api credentials being written down will be "dave"
<davecheney> so that User field cannot be used to turn back into a tag
<thumper> yeah, that is all fucked up
<thumper> anyway...
<thumper> I've touched that I think
<davecheney> where do those credntials go ?
<thumper> those are stored in the .jenv file
<davecheney> if the thing at the other end is doing
<davecheney> names.ParseUserTag
<davecheney> that is ok
<thumper> it isn't
<davecheney> if it's doing
<davecheney> names.ParseTag
<davecheney> then it's wrong
<davecheney> ok, comment added anyway, i'll come back to it after I've fixed the compile errors
<thumper> I think it is doing neither
<davecheney> thumper:
<davecheney>         var environUUID string
<davecheney>         if apiInfo.EnvironTag != nil {
<davecheney>                 tag, err := names.ParseEnvironTag(apiInfo.Tag)
<davecheney>                 if err != nil {
<davecheney>                         return err
<davecheney>                 }
<davecheney>                 environUUID = tag.Id()
<davecheney>         }
<thumper> yep
<davecheney> so, if the environtag _is_ set, then ignore it and use the id of the apiInfo.Tag ...
<davecheney> o_O
<thumper> ah wat?
<thumper> I misread the code
<thumper> that is all sorts of fucked up
<thumper> pretty sure it should be using EnvironTag ...
<davecheney> yup
<davecheney> thumper: do you want me to land a quick branch to fix this before doing some more wholescale changes ?
<thumper> yeah, I think that would be good
<davecheney> ok, two secs
<thumper> davecheney: if it makes you feel better, I'm down in the trenches of weird/shitty code too
<davecheney> \o/
<davecheney> thumper: menn0 https://github.com/juju/juju/pull/285
<thumper> davecheney: there are no tests?
<davecheney> don't appear to be
<thumper> how silly of me... a test would have shown it wasn't working
<davecheney> didn't run the whole test suite
<davecheney> just go test ./juju/api
<thumper> davecheney: is there a quick test that could be written around that?
<davecheney> thumper: no idea
<davecheney> haven't looked at the tests in that code
<thumper> can you take a look?
<davecheney> hmm
<davecheney> so
<davecheney> none of our test fixtures have an environment-uuid: field
<davecheney> ok, this is bigger than a quick branch
<davecheney> logging a bug
 * thumper is fighting side-effects in code being tested elsewhere
<davecheney> https://bugs.launchpad.net/juju-core/+bug/1339967
<_mup_> Bug #1339967: juju: cacheAPIInfo users the wrong tag when storing the environ UUID <juju-core:New> <https://launchpad.net/bugs/1339967>
<davecheney> its on the list
<davecheney> i don't want to get distracted
<thumper> davecheney: can play.golang.org do github imports?
<waigani_> thumper: failed for me, maybe it does certain ones??
<davecheney> thumper: no
<thumper> failed for me too...
<thumper> ok that is why
<waigani_> func RunConfigureScript(script string, params ConfigureParams) error {
<waigani_> 	logger.Debugf("Running script on %s: %s", params.Host, script)
<waigani_> 	client := params.Client
<waigani_> 	if client == nil {
<waigani_> 		client = ssh.DefaultClient
<waigani_> 	}
<waigani_> 	cmd := ssh.Command(params.Host, []string{"sudo", "/bin/bash"}, nil)
<waigani_> 	cmd.Stdin = strings.NewReader(script)
<waigani_> 	cmd.Stderr = params.ProgressWriter
<waigani_> 	return cmd.Run()
<waigani_> }
<waigani_> client is not being used at all ?!?!
<davecheney> looks that way
<waigani_> hmph - I'll leave a question for the reviewer
<davecheney> does that code even compile ?
<waigani_> cloudinit/sshinit/configure.go:52
<waigani_> yep, I have not touched it
<waigani_> davecheney: ^
<davecheney> it's cos of the check
<davecheney> the if on line 51
<waigani_> yep
<davecheney> http://play.golang.org/p/m4Z-kfxN3w
<davecheney> oh well
<thumper> why oh why are so many of our tests so shit?
<davecheney> thumper: you know that 383,000 lines of code ?
<davecheney> that's not a number i'm particularly proud of
 * thumper smirks
<waigani_> I'm assuming they meant client.Command(... not ssh.Command
<davecheney> waigani_: yes
<davecheney> log a bug
<waigani_> davecheney: I actually need to fix it for my branch - need to manually provision with a given key
<waigani_> davecheney: should I still associate a bug with it and address it in my PR?
<davecheney> waigani_: if you're not going to fix it staight away
<davecheney> log a bug
<davecheney> so when you are on leave next week
<davecheney> it doesn't get lost
<menn0> woot. I think I've reviewed everything that needs reviewing.
<menn0> I'll keep an eye on the PR queue but ping me if there's anything that needs urgent review.
<thumper> omg...
<thumper> I found a test that tests something that can never happen...
<thumper> effectively it goes like this:
<thumper> look for the api end points
<thumper> make sure there are no addresses
<thumper> if there are no addresses, connect to the api to find the addresses
<thumper> return addresses
<thumper> yay
 * thumper waves his hand
<thumper> magic
<thumper> juju magic
 * thumper sighs
<menn0> thumper: the test does that and passes?
<thumper> menn0: well it mocks out the actual connection
<thumper> to return values
<menn0> right. so it's an unnecessary test.
<thumper> yup
<thumper> here is a good error message: logger.Warningf("cannot failed to cache API addresses: %v", localerr)
<thumper> double negative, so it worked, right?
<menn0> 8-)
<thumper> WT actual F?
 * thumper sighs
 * thumper holds in the rage and turns a little green
<thumper> why, oh why would the environment uuid change on an api connection?
<thumper> perhaps to save it?
<thumper> when it wasn't before?
<thumper> that is the only consideration I can think of
<thumper> davecheney: if I have a function that is package private, but I also export the func in export_test.go using the BigName = smallName method
<thumper> davecheney: but the function takes an arg that is an unexported interface
<thumper> davecheney: is go going to complain?
<thumper> or magically work?
<thumper> as long as what I pass in matches?
<thumper> hmm... unnecessary test is not entirely unnecessary
<thumper> there are other assumptions built int
<thumper> in
<menn0> thumper: while working on the schema migrations doc I think I've found a bug in the current upgrade mechanics
<thumper> oh?
<menn0> thumper: line 817 cmd/jujud/machine.go
<thumper> there
<menn0> a variable holding an error is carefully created but is never used
<menn0> and there's no tests that look for that error
<menn0> so if upgrades fail we silently ignore the failure and everything keeps going as if the upgrade was successful
<thumper> heh
<thumper> oops
<thumper> we should probably fix that
<menn0> I think the last return in runUpgrades should be "return err" not "return nil"
<thumper> surely there is a test...
<thumper> this was wallyworld_, so there should be a test
<menn0> I searched for "cannot perform upgrade" in the entire tree and it's only mentioned in that function
<thumper> hmm
<thumper> write a failing test :)
<wallyworld_> thumper: menn0: it wasn't me
<thumper> one where the step always fails
<thumper> and check
<wallyworld_> it was roger :-P
<wallyworld_> look at annotate :-)
<menn0> will do. I know this bit of the code quite well now.
<thumper> also... should probably look at the upgrade error before the "failed to update agent version error"
<wallyworld_> i suspect there hsould have been a baned return value
<wallyworld_> named
<menn0> wallyworld_: yep understood
<wallyworld_> :-)
<menn0> I think it might be clearer without a named return anyway
<menn0> wallyworld_: what is currently the desired behaviour if a upgrade steps fail? it's 50/50 whether it's better to downgrade or pressing on with the new version depending on which upgrade steps have already run.
<menn0> soon we will be able to rollback using the backup, but what do we expect right now?
<wallyworld_> menn0: hmmm. we haven't really supported rollback till now. rollback is more than db, includes config also etc. we don't really handle upgrade errors very well.
<wallyworld_> hard problem
<menn0> wallyworld_: right and I'm trying to make that situation better.
<menn0> wallyworld_: but given current limitations what do we do?
<wallyworld_> error out and then the agent restarts
<menn0> wallyworld_: or what /should/ we do is probably the better question
<wallyworld_> try and recover
 * thumper is pulling gently on the end of a piece of string, but is just getting a big knot every time
<wallyworld_> and restart the old agent
<menn0> wallyworld_: ok. that seems about the best we can do.
<wallyworld_> yeah
<menn0> the old agent may not work because of changes made by upgrade steps for the next version but we can't do much better
<wallyworld_> we can try and rollback the file changes
<wallyworld_> but that may not work either
<menn0> soon we will be recovering from the backup which has both the database and configuration files
<wallyworld_> the thought was, if it fails, it's time to call juju support
<menn0> got it
<wallyworld_> great, look forward to that
<menn0> wallyworld_: it was definitely rog's change... I just had a look and I can see exactly what happened.
<wallyworld_> \o/
 * wallyworld_ makes mistakes too, but sometimes needs to defend his honour :-)
<wallyworld_> especially since thumper implied there should have been a test :-)
<thumper> wallyworld_: that is because you always supply tests for your work
<menn0> although the lack of pre-existing tests for that error condition probably didn't help when rog refactored that code...
<wallyworld_> yes :-)
<menn0> :-p
<wallyworld_> well, i didn't write the original either
<menn0> just teasing
<wallyworld_> the jujud upgrade stuff is separate from the upgrade steps stuff
<wallyworld_> :-P
 * menn0 rolls up his sleeves
 * wallyworld_ takes the bait
<menn0> ;-)
 * wallyworld_ needs sleep, later
<thumper> success... just one failing test to fix
 * thumper is done for now
<thumper> meetings later
<thumper> night all
<ChrisW1> menn0: someone refactored untested code? tsk tsk
<menn0> ChrisW1: indeed :)
<davecheney> thumper: re that test, http://static.comicvine.com/uploads/original/11111/111119363/3792894-7922452111-tumbl.gif
<davecheney> it won't complain, but you won't be able to construct a value to pass to that function
<davecheney> however, if you have someone elses' value, that will work
<davecheney> menn0: re named return, hold that thought
<davecheney> it will be a good example for waigani
<davecheney> menn0: chrisw1, http://dave.cheney.net/2013/11/14/more-simple-test-coverage-in-go-1-2
<davecheney> may be useful for figuring out which footguns are lacking their protective covers
<menn0> davecheney: I'm not sure if this is the best sample for discussing named returns
<davecheney> menn0: what was the bug you found before ?
<menn0> the code is hairy
<menn0> not really about named returns
<davecheney> :/
<menn0> thumper or wallyworld were theorising that perhaps someone intended there to be named returns but there wasn't
<menn0> at any rate, no named returns are being used
<menn0> the bug is about an error not being returned
<davecheney> ok
<menn0> a line that says "return nil" when it should say "return err" (well actually it's more complex than that but that's the core of it)
 * davecheney moves on
<davecheney> :~
<menn0> frustrated email sent to juju-dev
<menn0> I'm done for this week.
<menn0> Back on Monday.
<TheMue> morning
<urulama> i've just filed bug 1340077 (https://bugs.launchpad.net/juju-core/+bug/1340077) ... didn't find similar one, but maybe it already exists
<_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
<_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
<davecheney> 1340077 1340077 1340077 1340077 1340077 1340077 1340077 1340077 1340077 1340077 1340077 1340077 1340077 1340077 1340077 1340077
<davecheney> #1340077
<_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
<davecheney> i wonder if mup is dumb enough to fall for that
<davecheney> #1340077 #1340077 #1340077 #1340077 #1340077 #1340077 #1340077 #1340077 #1340077
<_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
<_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
<_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
<_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
<_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
<_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
<_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
<_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
<_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
<davecheney> and the answer is, yes
<urulama> QED ;)
 * davecheney waves to urulama 
<davecheney> welcome to canonical
<urulama> thanks
<urulama> oh, australia, good evening then
<davecheney> o/
<davecheney> i'm representing for the southen himsphere tonight
 * TheMue waves as antipode
<jam> urulama: welcome. So how does one intend to pronounce "urulama" ? My first instinct is to read it as "you're a llama", but the intent could be something different
<urulama> jam: :D :D
<urulama> jam: never thought about that ... it's an old nick, so old that i don't thing about it, but maybe it is time to change it
<urulama> jam: "ooroo"+"llama" would sound as we read it
<jam> urulama: strong l or a y or a j sound ?
<urulama> strong L
<TheMue> jam: urulama: maybe itâs the right time to have nicks in phonetics (thinking of international teams)
<urulama> TheMue: or in asciiart :D
<TheMue> urulama: ;)
<TheMue> so, mine is Ã°É mjuË
<urulama> it's probably a known bug that autocomplet for debug-hooks in terminal returns charm/1 as charm is on machine 1, but hooks are connected only when "juju debug-hooks charm/0" is executed?
<urulama> on a amazon or manual env, not on local
<dimitern> tasdomas`, I added some review comments to your ports PR
<jam> urulama: I haven't heard of it, so feel free to report a bug about autocomplete, as the first unit of a service is always 0, it shouldn't depend what machine it is on.
<TheMue> so, https://github.com/juju/juju/pull/281 is back in for review
<jam> TheMue: dimitern vladk|offline standup?
<urulama> one more bug 1340133
<_mup_> Bug #1340133: debug-hooks don't work in manual env <juju-core:New> <https://launchpad.net/bugs/1340133>
<jam> urulama: whenever I read your name my first response is "nu-uh, *you're* a llama" :)
<uru_> damn, taken
<uru-urnotallama> jam: better? :D
<TheMue> *rofl*
<jam> uru-urnotallama: :)
<jam> dimitern: so you're gone from tomorrow for 2 weeks/
<jam> ah, that's next week
<dimitern> jam, yep, next week
<tasdomas`> dimitern, thanks
 * dimitern needs to step out now, bbl
<tasdomas> are pull requests for packages like github.com/juju/names managed by a landing bot or do I just merge them myself (having received an LGTM)
<tasdomas> ?
<perrito666> morning
<TheMue> perrito666: morning
<TheMue> perrito666: weâll see on Sunday, ha? :D
<perrito666> TheMue: I return home on sunday, I will most likely sleep trough the game
<TheMue> perrito666: hey, you cannot do that, youâll see  how our team beats yours :P
<perrito666> I care as much for football as I do for ... I think there is nothing I care that little about :p
<TheMue> perrito666: hehe, in that case
<bodie_> morning all
<mgz> bodie_: hey
<davecheney> mbruzek: hey
<mbruzek> davecheney, hello
<davecheney> mbruzek: did you see my update on taht issue
<davecheney> do you have the dmesg from that system
<mbruzek> yes I uploaded dmesg
 * davecheney checks email
<davecheney> hmm, nup
<davecheney> nothing
<mbruzek> https://bugs.launchpad.net/ubuntu/+source/gccgo-4.9/+bug/1304754/comments/35
<_mup_> Bug #1304754: gccgo has issues when page size is not 4kB <ppc64el> <trusty> <gcc:Fix Released> <gcc-4.9 (Ubuntu):Fix Released> <gccgo-4.9 (Ubuntu):Invalid> <gcc-4.9 (Ubuntu Trusty):Invalid> <gccgo-4.9 (Ubuntu Trusty):Fix Committed by doko> <gcc-4.9 (Ubuntu Utopic):Fix Released> <gccgo-4.9 (Ubuntu Utopic):Invalid> <https://launchpad.net/bugs/1304754>
<mbruzek> davecheney, ^
<davecheney> mbruzek: it's empty
<mbruzek> davecheney, Sorry take the comments/35 off
<mbruzek> the bug was updated with my dmesg_output.txt  I thought I would be clever by showing you on which comment, but I left no messages on file upload.
<davecheney> mbruzek: thanks
<davecheney> ok, so it's not the usual issue
<davecheney> dmesg shows no issue
<TheMue> wife bought strawberry cake, daughter made a tea - a very good working environment
 * perrito666 finds another race
<wallyworld_> axw: if you want a break from mongo fun https://github.com/juju/juju/pull/288
<katco> AWS question: does anyone know if there's any documentation on what version of signature each region supports?
<natefinch> katco: not sure what you mean version of signature
<katco> yeah, sorry: http://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html
<katco> they support v2, 3, and 4
<katco> and i'm trying to introduce support for 4; turns out it's important to know which region supports which
<wallyworld_> sinzui: \o/
<natefinch> katco: man, that is a terrible name for ... well anything.
<natefinch> wallyworld_: btw, A/C people still not here :/  Supposed to be here between 10 and noon, so the clock is ticking
<katco> natefinch: mm? what's a terrible name?
<wallyworld_> natefinch: np. we'll try not to eat *all* the kunch
<wallyworld_> lunch
<natefinch> katco: "SIgnature"
<katco> natefinch: ah
<katco> natefinch: context increase IQ by 100% ;)
<perrito666> natefinch: so much for "they usually come here first"
<natefinch> perrito666: Usually they end up coming early.  I guess they found out I'm not actually supposed to be working from home today, so decided to come late
<perrito666> natefinch: sounds possible
<natefinch> There have been a couple times they have simply not shown up.  But I called at 11 to make sure they hadn't just left me off the list this time.
<sinzui> wallyworld_, the 1.20.1 final test run and the 1.20.2 first test run were the two best runs CI has seen in 6 weeks. In both cases every test passed the first try. The entire run was less than 2 hour each
<wallyworld_> wow, awesome
<jcw4> is there a juju / charm acolyte who might be able to help breze441 in #juju ?
<jcw4> I tried to prime the pump a bit since his question was vague, but I think there's enough detail now that someone who knows juju/charms better may be able to help with?
<natefinch> katco, axw: btw, I pinged niemeyer about moving goamz to github, since some Go people had been asking about which version they should use - launchpad's or the dozens of copies on github.
<alexisb> sinzui, good stuff on 1.20.1, thanks for getting it out there!
<sinzui> thank you alexisb
<perrito666> natefinch: got ac?
<axw> natefinch: thanks, I think that'd be a good idea.
<katco> natefinch: +1, ty
<natefinch> perrito666: they're here, but it's not fixed yet
<perrito666> natefinch: well its something
<natefinch> perrito666: yeah, but I fear the person they sent is not their most competent at diagnosing problems.  They have like 3 really good technicians and a bunch of flunkies that are not that great
 * perrito666 wonders if we cannot fix that, there are like 8 of us here
<voidspace> rogpeppe: ping
<voidspace> rogpeppe: are you around?
<rogpeppe> voidspace: hiya
<rogpeppe> voidspace: that i am
<voidspace> rogpeppe: hey Roger, hi
<voidspace> I'm in Lexington
<rogpeppe> voidspace: cool
<voidspace> rogpeppe: I have a question about HA
<rogpeppe> voidspace: fire away
<voidspace> rogpeppe: should all writes go to mongo master - and does that mean that only the machine hosting the mongo primary should do writes, or do the other state servers connect remotely to the primary?
<voidspace> or does it mean something else
<voidspace> what I'm seeing, which surprised me, is that after "ensure-availability" the machine with JobManageEnviron is not the Primary mongo
<rogpeppe> voidspace: if you connect to a mongo secondary, it will automatically make a connection to the primary and send writes there
<voidspace> cool
<voidspace> so we don't need to worry about that
<rogpeppe> voidspace: after ensure-availability, there should be 3 machines with JobManageEnviron
<voidspace> they should all have JobManageEnviron, ok
<rogpeppe> voidspace: and the choice of primary is entirely up to mongo
<voidspace> hmmm... my machine 1 only listed JobHostUnits in its agents.conf
<voidspace> rogpeppe: I'm looking at the behaviour of HA when mongo dies but juju itself remains running
<rogpeppe> voidspace: when a majority of replicas die?
<voidspace> no, just when a single one dies
<rogpeppe> voidspace: it *should* just carry on working
<rogpeppe> voidspace: although there will be some churn
<voidspace> right, but the now "effectively dead" machine is still listed as a valid apiserver
<voidspace> when in fact it is screwed
<rogpeppe> voidspace: api servers will restart, clients will also need to reconnect
<voidspace> but things do still work
<voidspace> I'm trying to determine what doesn't work and what we need to fix
<voidspace> so yes, api servers will need to restart - but it doesn't look like they do
<voidspace> but it's only a minor issue I think
<voidspace> the replicaset configuration still lists the dead machine as in the replicaset
<voidspace> (the mongo rs.conf() that is)
<rogpeppe> voidspace: the dead machine will still remain in the replicaset until you run ensure-availability again
<voidspace> right
<voidspace> rogpeppe: when you run ensure-availability the first time, and mongo picks a master, will the singular workers stop running on machine-0 and start running on the master (assuming machine-0 is no longer the master)?
<rogpeppe> voidspace: yes, they should do
<voidspace> rogpeppe: ok, great
<natefinch> well fuck, A/C guys say the $800 worth of refrigerant they put in the system is gone and we need a new system.  Fantastic.
<voidspace> natefinch: ouch :-/
<voidspace> :-(
<natefinch> that was like 2 months ago they put that in, too.  Put in some "leak stop" stuff too.  Getting a second opinion in the morning, but... I think it's new A/C time... which means like $8,000
<natefinch> anyway, coming into the office
<perrito666> natefinch: f*** shouldn't they give you some refund on that? I mean they added refrigerant when they shouldn't
<wallyworld_> natefinch: and wwitzel3 ate all the lunch
<natefinch> that's ok
<natefinch> I had cake for lunch
<perrito666> uh, can we have cake?
<voidspace> rogpeppe: my machine-1 agents.conf only lists JobHostUnits under jobs, whereas as machine-0 (my current master) lists JobManageEnviron too
<voidspace> *agent.conf (singular)
<rogpeppe> voidspace: and machine 1 was created by ensure-availability?
<voidspace> yep
<voidspace> it also lists three api addresses when there are now only two state servers
<voidspace> and machine-2 agent.conf - which *was* master  - also only lists JobHostUnits
<rogpeppe> voidspace: i don't believe that machine was created without JobManageEnviron
<rogpeppe> voidspace: what's the output of juju status?
<voidspace> rogpeppe: http://paste.ubuntu.com/7776326/
<rogpeppe> voidspace: i see that all of machines 0, 1 and 2 are voting
<rogpeppe> voidspace: that means that they're part of the intended replica set
<voidspace> rogpeppe: but agent state of 2 is down
<voidspace> I took down mongo first
<voidspace> agent.conf on the other machines didn't change
<voidspace> I took down jujud as well
<rogpeppe> voidspace: sure, you can be down and still have a vote
<voidspace> still no change (that I could see)
<voidspace> but it is also still listed as a valid api server
<voidspace> even though it is down
<voidspace> but the master change worked fine
<rogpeppe> voidspace: all those machines definitely have JobManageEnviron, BTW
<voidspace> not listed in agent.conf they don't :-)
<voidspace> but I believe you
<voidspace> so it's a bit odd
<rogpeppe> voidspace: for my proof, see cmd/juju/status.go:323
<rogpeppe> voidspace: it's odd that that's not in agent.conf though
<rogpeppe> voidspace: that sounds like some kind of bug
<voidspace> rogpeppe: http://paste.ubuntu.com/7776354/
<voidspace> rogpeppe: machine 1 is the same
<voidspace> machine-0 also lists JobManageEnviron
<voidspace> rogpeppe: ok, so it's an oddity (probably a bug) but not significant
<voidspace> rogpeppe: thanks
<rogpeppe> voidspace: well, it may well be significant
<voidspace> hah, ah
<voidspace> ok
<voidspace> if you take down the mongo on the master then the master does switch, but jujud carries on running on the "old master"
<rogpeppe> voidspace: jujud will always continue running
<rogpeppe> voidspace: it runs on every machine
<voidspace> rogpeppe: what would you expect a juju that can't connect to mongo to do?
<rogpeppe> voidspace: BTW, AFAICS the Jobs in the agent config isn't used at all
<voidspace> rogpeppe: right
<voidspace> good
<voidspace> rogpeppe: I'm still wondering what writes it out and why it's wrong, but I can look for that
<rogpeppe> voidspace: i'd expect a juju that can't connect to mongo to sit around trying to connect to mongo
<voidspace> rogpeppe: hah, ok :-)
<voidspace> rogpeppe: I think juju behaves fine when we kill mongo
<rogpeppe> voidspace: good!
<voidspace> it doesn't rewrite agent.conf in the way perrito666 and I thought it should
<voidspace> but I don't think that's a problem
<rogpeppe> voidspace: nice to know that something works :-)
<voidspace> the machine log shows it stopping all the things it should I believe
<voidspace> hah
<voidspace> indeed :-)
<voidspace> so I'm going to close that bug....
<rogpeppe> voidspace: ha, i've found the cause of the bad Jobs
<rogpeppe> voidspace: i think
<rogpeppe> voidspace: in environs.NewMachineConfig
<perrito666> rogpeppe: I am pretty sure that I can fit an apple joke in there
<rogpeppe> voidspace: the Jobs are always set to JobHostUnits
<rogpeppe> perrito666: arf arf
 * rogpeppe actually doesn't laugh, because a reference to a joke is not the same as the joke itself
<rogpeppe> :-)
<voidspace> hah
<perrito666> rogpeppe: fine *(rogpeppe: I am pretty sure that I can fit an apple joke in there)
 * rogpeppe is still waiting for a joke
<voidspace> rogpeppe: so the machine actually has the ManageEnviron job, but we assume that a new machine only has host units (which was the case before HA) and so that's what we put in MachineConfig
<rogpeppe> voidspace: yup
<voidspace> rogpeppe: you just have to dereference it yourself
<voidspace> rogpeppe: could this be a potential problem? (not the apple joke)
<voidspace> rogpeppe: let me hedge my bets a bit more
<rogpeppe> voidspace: currently no
<voidspace> would it be fair to say that it's reasonable to assume that perhaps this could be a potential problem, at least in theory
<rogpeppe> voidspace: the plan was always to allow a machine to change its jobs
<voidspace> ok
<rogpeppe> voidspace: so a machine would populate its own machine config's Jobs field
<perrito666> rogpeppe: a skelton enters a bar and he says: bartender, please give me a whisky and a mop
<voidspace> I'd tell you a udp joke, but you wouldn't get it
 * rogpeppe laughs at both of those
<rogpeppe> although i'd heard the udp one before
<voidspace> I know another udp joke, but I can't tell that one either - it's a bit out of order
<voidspace> yeah, old
<rogpeppe> voidspace: pm me :-)
<voidspace> rogpeppe: no, that was the joke...
<rogpeppe> oh sod
<rogpeppe> :-)
 * rogpeppe lols a little more
<bodie_> I'm really excited that Elon Musk donated $1 million to the new Tesla museum in NY
<bodie_> I sure hope they take things far
<urulama> can juju-test be run with a parameter to .test file?
<mgz> voidspace: https://bugs.launchpad.net/juju-core/+bug/1307434
<_mup_> Bug #1307434: talking to mongo can fail with "TCP i/o timeout" <cloud-installer> <landscape> <performance> <reliability> <juju-core:Triaged> <https://launchpad.net/bugs/1307434>
<stokachu> anyoen know if the ServiceDeploy api call takes 'lxc:1' as its ToMachineSpec? I can't seem to get it to work
<stokachu> or do i have to add machine first
<natefinch> stokachu: juju help deploy will give you the format.   What are you trying to get it to do?
<stokachu> deploy to an lxc container on machine 1
<natefinch> stokachu: before machine 1 exists, I take it?
<stokachu> natefinch, no machine 1 exists
<natefinch> stokachu: oh, hmm. lxc:1 should work....
<stokachu> is the param syntax still {'ToMachineSpec': 'lxc:1'}
<natefinch> stokachu: yeah - https://godoc.org/github.com/juju/juju/juju#DeployServiceParams
<stokachu> hmm ok i must be doing something wrong with the api call
<rogpeppe> g'night all
<stokachu> natefinch, if you don't define a NumUnits it just deploys the charm but never attaches itself to a machine
<stokachu> shouldnt that give us an error or some indication in the json response?
<natefinch> yeah, it's a little wacky since numunits would default to 0, which is not really a valid value in any sense of the words
<natefinch> it should probably complain, yeah
<natefinch> or default to 1 for numunits < 1
<stokachu> yea
<stokachu> took me awhile to figure out why the ServiceDeploy api call wasn't associating a machine
<thumper> wallyworld_: sorry about missing the resources meeting, but 7am meetings after my late night lead ones isn't a good time
<thumper> was too out to it
<wallyworld_> thumper: np, we didn't need you anyway :-P
<thumper> good
<wallyworld_> thumper: i can ping you a bit later and fill you in
<thumper> sure
<natefinch> stokachu: the CLI stops you from using num units < 1.. the api should, too
<stokachu> if i dont define num units it'll just deploy the service with no machine
<natefinch> stokachu: yeah, that's a bug.  We haven't really put a lot of effort into making the API foolproof, unfortunately.
<stokachu> ill file a bug for it to track then
<perrito666> natefinch: that should blow at a lower level
<natefinch> stokachu: thanks
<perrito666> natefinch: sounds like something that we will never want to allow so making that check should not happen in the borders
<perrito666> s/borders/edges
<natefinch> perrito666: yep
<natefinch> perrito666: no sense having that kind of logic in more than one place
<thumper> wallyworld_: dog got in a bit of a fight last night, off to the vet in just under an hour, she won't put weight on one of her legs :-(
<wallyworld_> oh :-(
<wallyworld_> hope she's ok
<thumper> so do I
<thumper> she isn't behaving normally
<wallyworld_> :-(
<thumper> was at the vet yesterday for ear infection
<wallyworld_> $$$$$$
<thumper> which may have made her a little short tempered
 * thumper nods
<wallyworld_> i'll ping you later after dinner here
<wallyworld_> thumper: what do you mean by "name connection"?
<thumper> wallyworld_: we are going to have 'juju connect' and use the name "connection" to refer to a particular thing
<wallyworld_> thumper: this work will eventually kill the need for Environ to have to be able to provide mongo addresses
<thumper> a connection is to an environment within a juju server as a user
<thumper> wallyworld_: I'm happy that there is MongoInfo
<thumper> I was just saying I didn't like axw's suggestion of calling it ConnectionInfo
<wallyworld_> thumper: so Environ interface has StateInfo() returning a MongoInfo() and APIInfo()
<wallyworld_> the MongoInfo return value will go away
<thumper> because an Environ doesn't need it?
<axw> thumper: yeah agreed, I mostly just didn't like the inconsistency
<wallyworld_> Environ has no business knowing how the state persistence layer connects to mongo
<thumper> axw: fair enough, consistency ftw
<thumper> wallyworld_: agreed
<wallyworld_> and i am about to propose a branch the means it doesn't have to
<wallyworld_> thumper: you will be happy also with stuff that is being done to unpick State, will fill you in later
<thumper> wallyworld_: ack
<thumper> wallyworld_: next week is fine
<wallyworld_> ok
<dpb1> Hi all -- 1.20.1 + latest maas:  anyone seen this? http://paste.ubuntu.com/7777233/ (line 88)
<thumper> dpb1: not seen it, but I don't test maas
 * thumper off to the vet again
<dpb1> thumper: OK... anyone else seen it? :)
<waigani> thumper: https://github.com/juju/juju/pull/289
#juju-dev 2014-07-11
<thumper> taking the kids out for lunch
<thumper> back later
<thumper> davecheney: got a few minutes for a hangout?
<davecheney> sure
<davecheney> i'll get my other pc
<thumper> k
<davecheney> ready
<thumper> davecheney: https://plus.google.com/hangouts/_/gqpui2frcqiffoyg6usnsp6dfaa?authuser=1&hl=en
<stokachu> someone mind taking a look at this json response http://paste.ubuntu.com/7778445/
<stokachu> im passing it the ConfigYAML file with the service name
<stokachu> but it isn't finding the settings for keystone for some reason
<stokachu> i parsed the yaml file to make sure there were no errors and it loads up with the keystone set as the key
<thumper> stokachu: is the service named keystone?
<thumper> stokachu: I've found that the config is based on the name of the service, not the charm name
<stokachu> ah hmm
<stokachu> lemme check something
<stokachu> so i set the ServiceName to keystone
<thumper> stokachu: what is it named in status?
<thumper> stokachu: or, another way, what was your deploy command?
<stokachu> im using ServiceDeploy api call
<stokachu> so i pass in the params for ServiceName etc
<stokachu> thumper, if i deploy without ConfigYAML set then it deploys the keystone service named 'keystone'
<thumper> right
<thumper> sorry, not sure
<stokachu> i cant find a test that uses the ConfigYAML parameters
<stokachu> i tried to mimic the api call to https://github.com/juju/juju/blob/master/state/apiserver/client/client_test.go#L807
<stokachu> which i think is right
<thumper> stokachu: let me look at something
<stokachu> ok
<thumper> stokachu: according to the code in cmd/juju/deploy.go, the yaml config expected in the ServiceDeploy api is the entire yaml file with a top level name matching the service name.
<stokachu> so not the string?
<stokachu> filename string i take it
<thumper> haha
<thumper> no
<thumper> you need to read the file, and pass the yaml as string
<stokachu> ah well then thats probably why
<thumper> yep
<thumper> will be
<stokachu> shouldnt code so late
 * thumper was hacking at 1am the other night
<thumper> gets tiring
<stokachu> yea but im so close to get this working lol
<stokachu> damnit what a stupid mistake
<stokachu> thumper, thanks for the extra set of eyes
<thumper> np
<thumper> my brain has stopped working
<thumper> time to leave
<waigani> ugh, just realized my irc was not connected
<waigani> davecheney: here's the output of my script: http://pastebin.ubuntu.com/7778556/
<waigani> davecheney: it deals with comments, if the groups are in the wrong order, if there are too many groups. I *think* I don't have any false positives.
 * davecheney looks
<vladk> dimitern: please, take a look http://github.com/juju/juju/pull/121
<dimitern> vladk, looking
<TheMue> morning
<urulama> morning
<dimitern> vladk, reviewed
<vladk> dimitern: thanks
<dimitern> vladk, remind me again please, why do we need to care about parsing the interfaces files so thoroughly ?
<dimitern> vladk, can't we get away with just what the net package gives us?
<dimitern> (and running some commands like ifup etc.)
<dimitern> also, seems like fixing maas changes to interfaces files is not a job for juju
<dimitern> (does it need to be a special case like that?)
<vladk> dimitern: to bring up interface, we need to add some lines to configuration file, in the future we are going to support static IPs, so configuration lines may depend on network state
<dimitern> vladk, well, my point is we can *write* to the interfaces files, but use the net package to *read* what's currently on and has address
<dimitern> vladk, re static ips - let's think about that when we get there - it won't be until october that's for sure
<vladk> dimitern: I asked people and found that most prefer to have configuration in separate files
<vladk> additionally it may be interfaces not managed by juju
<dimitern> vladk, if it's a machine juju started, juju has total control over it and we don't have to care about what users change later
<dimitern> vladk, so istm being less careful to preserve what's there and making sure we (over)write the config file for interfaces juju manages (all of them) should be fine
<dimitern> TheMue, a small-ish review? https://github.com/juju/juju/pull/293
<TheMue> dimitern: yep
<dimitern> damn! i've edited a card and then it disappeared!
<dimitern> TheMue, thanks!
<TheMue> dimitern: after first fears that the review process in GH gets worse I now feel more comfortable with it
<dimitern> TheMue, it grows on you :)
<TheMue> dimitern: ;)
<TheMue> dimitern: youâve got a review
<dimitern> TheMue, tyvm
<TheMue> dimitern: yw
 * TheMue continues with the flakey tests
<dimitern> TheMue, need any help on these? For the "port 54321 already in use" it should be trivial not to hard code it, but use ":0" and then get the random port Listen used
<TheMue> dimitern: Iâm currently at the double interface event
<dimitern> TheMue, ok
<TheMue> dimitern: but Iâll keep your hint in mind, thanks
<dimitern> TheMue, cheer
<dimitern> s :)
<TheMue> ouch
<TheMue> system just logged me out (w/ kiling all appls)
<dimitern> TheMue, the PR linked to the flaky tests bug report is wrong btw
<dimitern> aw..
<TheMue> dimitern: which PR?
<TheMue> dimitern: Iâve not yet done one
<dimitern> TheMue, the one linked is about the networker https://github.com/juju/juju/pull/207/
<dimitern> TheMue, but the failing test is in state/machine_test.go, which is an earlier one - https://github.com/juju/juju/pull/169/
<TheMue> dimitern: thx, will change it
<TheMue> dimitern: could you pls take a look at state/machine_test.go line 1803 - 1808?
<dimitern> TheMue, something's fishy, I've been looking at the machine interfaces watcher implementation
<TheMue> dimitern: if two different interfaces are disabled, why we only await one change?
<dimitern> TheMue, the only reason I can think of is if 2 changes are merged and reported as one, but the watcher has to be written like that
<TheMue> dimitern: that would be in watcher.go 1758ff
<dimitern> TheMue, there's a collect() func in state/watcher
<dimitern> TheMue, which is supposed to collapse multiple changes into one, but the machine interfaces watcher is not using it, but it's being tested as it is
<TheMue> dimitern: yes, looks like
<dimitern> TheMue, what freaks me out is why it's not happening *all the time*
<TheMue> dimitern: itâs a race, sometimes the second disabling event is fast enough received, sometimes not
<dimitern> TheMue, that seems to be the issue - *all* notify watchers use collect() inside the loop
<TheMue> dimitern: so Iâll change it do it so here too
<dimitern> TheMue, can that be forced by introducing a delay before disabling the second iface in the test?
<TheMue> dimitern: not yet tested
<dimitern> TheMue, that way you can be sure your changes in the loop() work
<TheMue> dimitern: good idea, will try that first to have a good testbed
<dimitern> TheMue, thanks
<dimitern> TheMue, also, while you're at it, can you please drop the notify flag from the loop? setting out to nil or to w.out is enough to signal a notification is needed
<TheMue> dimitern: yip
<dimitern> TheMue, ta
<TheMue> dimitern: btw, why did you moved the flakey test card, thereâs no PR yet ;)
<dimitern> TheMue, did I? Wasn't intentional if it was me
<TheMue> dimitern: changed it back, an will split it into machine interface and the other one
<dimitern> TheMue, good idea
<vladk> dimitern: you wrote many comments on exportable names. 90% of them are related to access to internals from test package, because test package has different name. How do you solve this problem?
<dimitern> vladk, using export_test?
<TheMue> dimitern: standup
<dimitern> TheMue, brt
<mgz> http://code.mumak.net/2014/07/cutting-edge-debugging.html
<TheMue> vladk: ping
<vladk> pong
<vladk> TheMue: pong
<TheMue> vladk: in TestWatchInterfaces() in line 1854, why do you expect no change here?
<TheMue> vladk: state/machine_test.go
<vladk> TheMue: because we have a watcher per machine, so it does not notify about interface changes on foreign machine
<TheMue> vladk: ah, ic, thx
<perrito666> natefinch: the suspense is killing us, what is the veredict?
<TheMue> vladk: and found the error here in my code ;)
<TheMue> vladk: yeah, that has been the needed info, now it works.
<TheMue> vladk: youâre OCR? hereâs PR https://github.com/juju/juju/pull/294 for one of the flakey tests (see lp:1339864)
<vladk> TheMue: looking
<TheMue> vladk: thanks
<perrito666> more than 60 secs to run 1 test when using mgosuite... beautiful
<perrito666> wwitzel3: dont get that near the computer, it will mess your eyes
<perrito666> :p
<wwitzel3> perrito666: :)
<TheMue> vladk: any questions regarding the PR?
<vladk> TheMue: no, just a minute
<TheMue> vladk: thx
<TheMue> vladk: looking into the second issue during that time ;)
<mgz> TheMue: I'm confused as to how that pr actually makes the test reliable
<TheMue> mgz: it has been a race condition as it not used the collection of changes before. and when those have been with the wrong timng the watcher sent multiple events
<TheMue> mgz: Iâve been able to reproduce the error locally by removing the error asserts in the test (to make it faster, funnily a Sleep doesnât changed it)
<TheMue> mgz: and after the change (dimiter gave me the hint with collect) it worked fine in all situations
<vladk> TheMue: where did you find a race condition? We have a separate watcher for every machine with separate map of changes
<TheMue> vladk: I didnât found it, Andrew. See https://bugs.launchpad.net/juju-core/+bug/1339864.
<_mup_> Bug #1339864: MachineSuite.TestWatchInterfaces intermittently fails <intermittent-failure> <test-failure> <juju-core:In Progress by themue> <https://launchpad.net/bugs/1339864>
<TheMue> vladk: I simply tried to understand it, discussed with dimiter, found a way to have it almost every time here on my machine too, changed it and now it never happened again (ran the test multiple times in a loop)
<mgz> \$\$\S+\$\$
<vladk> TheMue: It would better to drop that test with two sequential changes, rather to implement collect. I agree that the test is not correct. But no race condition here. Even with the collect implemented that test may failed.
<TheMue> vladk: why using a different pattern then in the other watchers?
<TheMue> vladk: collect() hasnât been implemented by me and is used in multiple watchers
<vladk> TheMue: because all watchers already has different patterens
<vladk> I'm not sure that this code has large practical meaning, because interfaces are not changed very often. We will get more complex code, but will not get any increase in performance.
<TheMue> vladk: in details yes, not always in patterns
<vladk> TheMue: I gave you LGTM
<TheMue> vladk: thanks
<vladk> TheMue: But I would drop that test with 2 events or changed it to one event.
<vladk> TheMue: also there is a mistake in WatchInterfaces() comment
<TheMue> vladk: Some minutes
<wallyworld> mgz: https://github.com/juju/juju/pull/295
<axw> wallyworld: https://github.com/juju/juju/pull/296
<katco> niemeyer: you around?
<niemeyer> katco: Always!
<niemeyer> ;)
<mattyw> rogpeppe, ping?
<rogpeppe> mattyw: off now, sorry
<rogpeppe> g'night all
<voidspace> niemeyer: ping
<voidspace> niemeyer: I'm looking at a juju bug, "i/o timeout" errors, which occur in various places https://bugs.launchpad.net/juju-core/+bug/1307434
<_mup_> Bug #1307434: talking to mongo can fail with "TCP i/o timeout" <cloud-installer> <landscape> <performance> <reliability> <juju-core:Triaged> <https://launchpad.net/bugs/1307434>
<voidspace> niemeyer: we *believe* this is due to the way we use a single session for *everything* in juju
<voidspace> niemeyer: please bear in mind that I know very little about mgo and our use of it, so I'm very happy for you to correct any misconceptions I may have....
<voidspace> niemeyer: state.State has a transaction runner (actually our own that wraps an mgo one)
<niemeyer> voidspace: Heya
<voidspace> niemeyer: o/ sorry for the wall of text :-)
<niemeyer> voidspace: In a call, but can be with you in 20mins, at most
<voidspace> niemeyer: ok, sure - I'll finish describing the problem and if you get a chance to look at it and answer my question (I do have a question) then great
<voidspace> niemeyer: if not I can fire it off as an email (probably when I get back from Lexington)
<niemeyer> voidspace: Sounds good
<voidspace> niemeyer: we would rather use the socket pooling that is built into mgo
<niemeyer> voidspace: I mean, please feel free to continue describing the problem.. will read and respond right after the call
<voidspace> niemeyer: yep, thanks
<voidspace> niemeyer: the comment on the mgo transaction runner says
<voidspace> / Multiple transaction collections may exist in a single database, but
<voidspace> / all collections that are touched by operations in a given transaction
<voidspace> / collection must be handled exclusively by it.
<voidspace> niemeyer: this leads us to believe that we must only have a single transaction runner and that we can't just switch to using multiple sessions (as the transaction runner has a reference to the session it is created from)
<mgz> fun fixes: https://github.com/juju/juju/pull/298
<voidspace> niemeyer: and for some reason, just refreshing the session every time we use it is causing auth errors (possibly related to the way we change passwords - but reopening the state after changing password doesn't fix the auth errors so there must be some other interactin here)
<voidspace> niemeyer: so, can you see a way for us to avoid having a long lived transaction runner / session - and do you think that it is indeed likely that the long lived session is the root cause of these errors we're seeing
<niemeyer> voidspace: Okay, here
<niemeyer> Reading...
<voidspace> niemeyer: o/
<niemeyer> voidspace: The reason why it's timing out is likely that you have a session sitting around unused for more than 10 minutes
<voidspace> niemeyer: yep, we use a single session for everything
<niemeyer> voidspace: mgo currently does not ping sessions in use to keep them alive
<niemeyer> voidspace: Using a single session is not strictly a problem by itself
<niemeyer> voidspace: It may be a problem depending on what else is being done
<voidspace> niemeyer: ok
<voidspace> niemeyer: the transaction runner keeps a reference to the session, and we must have a single transaction runner (we believe)
<niemeyer> voidspace: For example, sharing a session means sharing the underlying socket too, which means concurrent clients may have to wait for long running operations
<voidspace> niemeyer: right
<niemeyer> voidspace: It also means that connectivity errors break both clients at once, and you cannot recover the session locally because it would hide the error from every other user
<voidspace> niemeyer: so we could use multiple sessions (copy / clone / refresh), but we also need to ensure we keep alive the one used by the transaction runner
<niemeyer> voidspace: Okay, switching to the transaction runner issue
<niemeyer> voidspace: You can run as many transaction runners with as many sessions as you want
<niemeyer> voidspace: Creating a runner is very cheap, and has no kind of caching
<voidspace> niemeyer: what about that comment in the transaction runner code?
<niemeyer> voidspace: That comment is about the transaction collection..
<niemeyer> voidspace: not about sessions
<niemeyer> (or runners)
<voidspace> ah... indeed
<voidspace> cool
<niemeyer> voidspace: I would like to implement global session pinging, but I'm a bit concerned about the cost of doing so
<niemeyer> voidspace: I will sit on this over the weekend to ponder how it might be implemented in a good way
<voidspace> niemeyer: I think I mentally substituted "runner" for "collection" when reading that comment - so it's not actually a concern
<niemeyer> voidspace: I definitely don't want to have an extra goroutine for every single session, for instance
<voidspace> niemeyer: that would certainly help us, but we should probably fix our code anyway
<voidspace> right
<voidspace> niemeyer: thanks, that's very helpful - I think I have some things I can try now
<niemeyer> voidspace: Right, I do think you likely have issues to solve there either way
<voidspace> yep
<niemeyer> voidspace: FWIW, I've shared that sentiment before in that same context (I/O timeouts)
<voidspace> we could have a session pinger ourselves, but that's probably not the best fix
<niemeyer> voidspace: I pretty much always implement http request handling as Copy + defer Close, for instance
<niemeyer> voidspace: Agreed.. it sounds like this is a symptom of a more fundamental design issue
<voidspace> I still have to work out why we get these auth errors, but that's my problem...
<niemeyer> voidspace: Even with pinging, connections die all the time.. then what?
<voidspace> m1k43l
<voidspace> m1k43l
<mgz> wallyworld_: https://bugs.launchpad.net/juju-core/+bug/1340893
<_mup_> Bug #1340893: juju bootstrap in an existing environment destroys the environment <canonical-is> <juju-core:New> <https://launchpad.net/bugs/1340893>
<bodie_> super simple PR for testing Actions -- literally nothing added, just a testing charm location.  I'll need the godeps change in order to land Actions RunHook
<bodie_> https://github.com/juju/charm/pull/16
<jcw4> bodie_: LGTM, I think it's fine to merge
<bodie_> yeah
<bodie_> hmm, my dependencies.tsv diff seems off
<jcw4> how so?
<bodie_> I seem to have a different entry for loggo even though I've synced with master
<mgz> bodie_: see my latest mp
<jcw4> bodie_: I think the launchpad.net/loggo dependency was wrong
<jcw4> mgz: +1
<bodie_> ah
<mgz> pull/299
<bodie_> thanks
<mgz> so, just remove that line
<bodie_> there we are then https://github.com/juju/juju/pull/301
#juju-dev 2014-07-13
<Egoist> Hello
<Egoist> Why $JUJU_UNIT_NAME is empty?
<thumper> davecheney: morning
<waigani> thumper: davecheney I'm here for standup
<davecheney> cloudinit_test.go:803: c.Assert(err, gc.ErrorMatches, "invalid machine configuration: "+test.err)
<davecheney> ... error string = "invalid machine configuration: entity tag must match started machine"
<davecheney> ... regex string = "invalid machine configuration: state serving info unexpectedly present"
<davecheney> OOPS: 6 passed, 1 FAILED
<davecheney> --- FAIL: Test (0.21s)
<davecheney> FAIL
<davecheney> FAIL    github.com/juju/juju/environs/cloudinit 0.326s
<davecheney> ok      github.com/juju/juju/environs/config    2.153s
<davecheney> confusing test of the day is confusing
#juju-dev 2015-07-06
<wallyworld> thumper: a quick look at the recent 1.25 CI failures seems to show a smattering of 1 off issues, from EOF pinging mongo to directory permissions etc. doesn't appear to be too much that's a systemic juju failure
<jam> anastasiamac_: just running a little late, will be there in a minute or so
<anastasiamac_> jam: nps :)
<mup> Bug #1471657 opened: linker error in procsPersistenceSuite unit test on ppc64 <ci> <ppc64el> <test-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1471657>
<dooferlad> voidspace: hangout time!
<voidspace> dooferlad: sorry was on a phone call
<jam> fwereade: ^^
<voidspace> dooferlad: http://reviews.vapour.ws/r/2103/
<dooferlad> fwereade: http://reviews.vapour.ws/r/2078 has an "The file 'state/collections.go' (rcf5bc23) could not be found in the repository" error about 3/4 of the way down. I don't know who can prod the server, but my guess is it is out of disk space again.
<fwereade> dooferlad, I *think* that's just because RB can't handle me renaming it to collection.go :/
<fwereade> dooferlad, the diff *is* a bit smaller than it looks because some of it was just that move to collection.go -- but it did change as it moved as well, I'm afraid
<dooferlad> fwereade: not to worry - it is new to me.
<jam> fwereade: ping about your PR?
<fwereade> jam, yes
<jam> fwereade: I'm a bit surprised to add EnvironTag as the first param of state.Open
<jam> though I suppose some of that is coming from languages that have optional params so you can fill them with stuff to avoid breaking the API. but it does feel like it is a clarification on mongoInfo vs being the most prominent bit of information.
<fwereade> jam, well, a state *is* specific to an environment now
<fwereade> jam, I don't think the mongoInfo specifies that?
<jam> fwereade: I'm guessing the moved Open function is in collections.go ? I keep looking for the change in the diff, and best guess it is the missing file
<fwereade> jam, the intent is just to make it a bit more explicit -- anyone connecting to a state really ought to know what env they're talking about -- rather than insertinng it magically and internally
<fwereade> jam, state/open.go
<fwereade> jam, it's a 2-pager :(
<jam> ah
<fwereade> jam, I'm still a bit bothered about magical internal serverTag-setting
<jam> fwereade: I'm not sure I'm aware of the magical serverTag setting. Though I do see it getting set.
<fwereade> jam, I'm not fully conversant with its purpose
<fwereade> jam, afaics adding env-awareness just meant adding those 2 fields and setting them wherever was conveniennt
<jam> fwereade: and the move for "not authorized" was a real-world case of hitting an error that didn't end up as a QueryError from mongo?
<fwereade> jam, yeah, it was a *LastError as it happens
<jam> fwereade: it feels like something that needs a bit more documentation so that we know why and someone doesn't just refactor the fixes away
<jam> fwereade: assuming we don't have good ways of triggering those cases.
<fwereade> jam, sgtm
<fwereade> jam, if someone breaks it it will fail intermittently because we interact with the collections in map ordering
<fwereade> jam, and they fail in all manner of excitingly different ways
<fwereade> jam, so, yeah, I will add to the documentation
<jam> fwereade: 2 page diffs make me sad...
<fwereade> jam, me too :(
<jam> fwereade: just grabbing a local copy and vim. at least I can jump around and search more easily
<jam> I like inline comments, but navigation is hard
<fwereade> jam, yeah, a lot of it is just that EnvironTag addition, but it obscures the meat
<jam> yeah
<jam> fwereade: I notice we don't explicitly create the txns.stash and txns.purge? (added by menno, IIRC).
<jam> not much with what you did, but just one of those "we create all the collections here" except the ones we don't.
<fwereade> jam, I explicitly turned my head away from that rabbit hole
<fwereade> jam, we create the same collections we did before and that's all I know
<fwereade> jam, I *think* txns.log is the only important one
<jam> txns.stash is created by mgo
<fwereade> jam, and quite possibly not even created explicitly?
<jam> and txns.purge? was our bookkeeping page for when the last purge was run/how much it cleaned out/etc.
<jam> fwereade: mgo/txn does a "C.database.name + ".stash") sort of trick.
<jam> created under the covers.
<fwereade> jam, it would indeed be good to add those as rawAccess collections just to make it clear that they shouldn't be touched
<fwereade> jam, yeah, indeed
<jam> fwereade: a thoughtâ¦ what about changing the comment strings in allcollections.go into string attributes on the collectionInfo structs?
<fwereade> jam, I wanted to do that and then couldn't quite convince myself it was that useful
<fwereade> jam, so I like the idea, but can you explain why? ;)
<jam> fwereade: large lists of metainformation feels like something you could use to automate documentation about said information
<jam> harder to scrape comments than write a "for foo in collections" sort of loop
<jam> but someone would actually have to write that part
<fwereade> jam, I counter "YAGNI", but I like the idea enough I think I'll do it ;p
<jam> fwereade: I can certainly see people asking "what is the layout here" and we can just point them at allcollections.go
<jam> it *feels* useful to be able to programatically pull that out somewhere else, but as you say YAGNI until someone actually does something with it.
<fwereade> jam, yeah, just putting that information together feels like the big winn
<jam> at which time they could turnt hem into strings
<jam> fwereade: ugh.. leaseC vs leasesC being multi-aware vs not.
<jam> +2 on deprecating that ASAP. single-character typos having bad consequences
<fwereade> jam, I just started the branch to tear that out by the roots :)
<fwereade> jam, the plan is basically to go around wantonly deleting code until I get tired, and then see what needs to be done to patch it up
<fwereade> jam, at the very least I'll change its name to doNotUseThisDeprecatedLeaseC
<jam> thisIsNotTheLeaseYoureLookingForC
<fwereade> :D
<jam> fwereade: so ATM we have no raw-access collections, just a place to put them?
<fwereade> jam, yeah
<fwereade> jam, have agreed with wallyworld that status-history in particular wants to go there
<fwereade> jam, thought I'd prepare the ground since I was there ;)
<jam> fwereade: so you logically split the groups up based on comments and layout in the file. Would there be a reason to have collectionSchema itself somehow be split up into different attributes?
<fwereade> jam, perhaps, but (1) I'm not sure entirely sure where we'd use them and (2) I'm not certain that that organisation is fundamental
<fwereade> jam, the thing that's scratching at the back of my mind is that we use several databases anyway
<fwereade> jam, and collectionSchema is only a step in a hopefully-good direction
<fwereade> jam, it doesn't cover everything yet and baking in *too* much structure might not be ideal
<jam> fwereade: sure. Just that the layout doesn't inform you that this collection is/isn't raw accessible. Presumably the higher-level Runners do those checks?
<fwereade> jam, the rawAccess attribute is the only thing that controls that -- and, yeah, it's the multiEnvRunner that pays attention to it
<fwereade> jam, and there's an empty branch in envStateCollection for somehow preventing .Writeable() access to non-raw-access collections
<fwereade> jam, but that's not done mainly because we still have no shortage of direct .Writeable access to non-raw collections
<fwereade> jam, (incidentally -- I feel like envStateCollectionn failing to strip env-uuid off ids on load is a bit squicky -- it causes all that nasty maybe-insert-env-uuid stuff which is just asking for subtle bugs imo)
<fwereade> jam, (concur? don't have time to do anything about it, just thinking aloud)
<jam> fwereade: I haven't specifically dug into it, but from your description it definitely sounds like a leaky abstraction
<jam> and a case for "I read this ID and I pass it back in and read it back again" and they don't all agree
<fwereade> menn0, hey, in case you're awake, did we take Settings into account when we did the multi-env stuff?
<fwereade> jam, yeah
<fwereade> menn0, hooray, we did
<menn0> fwereade: I was pretty sure we did
 * menn0 not working, honestly
<menn0> :)
<fwereade> menn0, I can pontificate about how we could have done it *even better*, because none of our user can call things in settings "env-uuid" any more
<fwereade> menn0, and I'm not 100% sure how that would play out in practice, but I'm pretty sure it would be no fun
<fwereade> menn0, we've been flirting with disaster there with txn-revno et al since forever, but env-uuid feels like the sort of name someone might be a smidgen less unlikely to actually use?
<fwereade> menn0, anyway, you are not working, I will stop talking ;p
<menn0> fwereade: i'm working a little kinda... while also making soup and doing some non-work jobs
 * fwereade knows how that goes :)
 * fwereade is not expecting anything resembling snappy repartee
 * fwereade coffee actually
<menn0> fwereade: just getting a windows hyperV VM set up to do windows builds and test runs
<menn0> fwereade: thinking about the possibility of a name collison on "env-uuid"
<menn0> fwereade: it seems most likely for settings
<mgz> er, what is theis failure trying to tell me? http://paste.ubuntu.com/11830352
<menn0> fwereade: almost everywhere else we have a struct which will already have env-uuid on it
<menn0> fwereade: and it'll be fairly obvious what it's for
<menn0> fwereade: maybe for settings there should be a check to block exernal uses of env-uuid, txn-revno etc ?
<menn0> mgz: the HasLen failures are a little hard to read...
<menn0> mgz: it's showing you that it got an empty slice of *syslog.Writer but it expected a length of 2
<mgz> menn0: aha, thanks
<menn0> mgz: the obtained line is showing you the full actual thing that was obtained
<menn0> mgz: not very clear though
<mgz> menn0: have a TestPrunes failure on ggco, do you want me to reopen bug 1459291 or open a new bug?
<menn0> mgz: can you pastebin the output for me?
<mgz> menn0: http://reports.vapour.ws/releases/2858/jub/run-unit-tests-trusty-ppc64el/attempt/3490
<menn0> mgz: that gives me a 404 (and I am logged in)
<mgz> s/jub/job/
<mgz> sorry, I have irc on a different machine and it makes passing links around dodgy :)
<menn0> mgz: aww but I wanted to see the jub :)
<mgz> ehehe
<menn0> mgz: regarding the problem... pls create a new bug
<mgz> okay.
<menn0> mgz: I've seen this before and could have sworn I had already created a ticket
<menn0> mgz: ah, no, there it is in my personal todo list
<menn0> mgz: pls assign the bug to me
<mgz> menn0: done, bug 1471770
<mup> Bug #1471770: TestPrunes fails occasionally still <ci> <intermittent-failure> <test-failure> <juju-core:Triaged by menno.smits> <https://launchpad.net/bugs/1471770>
<menn0> mgz: tyvm
<mgz> menn0: both failures I have since your fix are on the ppc64 tests
 * fwereade ended up having lunch too
<fwereade> menn0, fwiw, what we should do is put the actual settings in a subdocument, and just makie sure we escape the keys properly
<perrito666> morning
<menn0> fwereade: that would work nicely too
<menn0> and has the added benefit of not limiting the keys so much
<fwereade> menn0, it's always just been one of those copious-free-time bugs :/
<menn0> fwereade: would lookups be slower in a subdocument? you don't get the default index on _id then right?
<fwereade> menn0, surely _id would jsut stay at the top level with the others
<fwereade> menn0, I'm not sure we'd need to index settings by content?
<menn0> fwereade: i'm probably not understanding what you mean then (and I'm tired)
 * menn0 hasn't looked at how settings are stored very much
<fwereade> menn0, it's just a document with everything jammed into the top level alongside the metadata :/
<fwereade> menn0, it was a useful type in python, against zookeeper
<fwereade> menn0, as we switched languages and backends it gradually made less sense but was always basically just a straight port
<mup> Bug #1471770 opened: TestPrunes fails occasionally still <ci> <intermittent-failure> <test-failure> <juju-core:Triaged by menno.smits> <https://launchpad.net/bugs/1471770>
<mup> Bug #1471771 opened: After "juju destroy-service <charm-name>" is executed,  the corresponding Windows charm service is not uninstalled <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1471771>
<menn0> fwereade: ok, right so there's a doc per env
<menn0> fwereade: so a subdocument would be fine
<fwereade> menn0, settingsC has *so much* in it
<menn0> fwereade: a smaller, but grosser, change would be to translate the sensitive field names into other ones for storage
<fwereade> menn0, at least one set of config settings per service; at least one per relation unit that's entered scope; env settings, probably more I'm not immediately thinking of
<menn0> fwereade: that is a lot
<menn0> fwereade: any danger of hitting the 16MB limit?
<fwereade> menn0, oh!
<fwereade> menn0, no, each of those things is its own N documents
<fwereade> menn0, the collection holds a lot, so a lot of things are affected, is my only point
<menn0> fwereade: ok so not one doc per env
<menn0> fwereade: that's not so bad then
 * menn0 should stop discussing this subject when he hasn't looked at the code
<fwereade> menn0, yeah -- I got thrown because, well, there *is* one environment settings doc per environment, but that's not what we meant :)
 * menn0 also really needs to go to bed. soup is cooked, windows VM is set up.
<fwereade> menn0, sleep well, thanks for the conversation
<menn0> fwereade: no worries. i don't think I contributed anything useful :)
<fwereade> perrito666, apiserver/common/getstatus.go:163
<fwereade> perrito666, it looks like the query is a list of unit tags but it tells us information about some other entity
<fwereade> perrito666, if we want to know service status, why are we not passing service tags?
<mup> Bug #1471775 opened: TestModeForwarding occasionally fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1471775>
<dooferlad> voidspace, TheMue: Review please: http://reviews.vapour.ws/r/2105
<TheMue> dooferlad: ok
<perrito666> fwereade: iirc, implements StatusGetter
<fwereade> perrito666, right, that just means it accepts a list of entities annd will tell yuo their status, assuming you're properly authed
<fwereade> perrito666, why does it accept a list of entities and tell you the statuses of some *other* enntities?
<voidspace> dooferlad: looking
<perrito666> fwereade: oh?
 * perrito666 put on glasses
<fwereade> sorry brb kee ptalking
<perrito666> fwereade: service status returns status of a units service (and its units), you need to pass in the leader unit tag, I feel your question is a bit more complex than my answer, right?
<voidspace> dooferlad: "return None" is slightly confusing :-)
<voidspace> dooferlad: just to my Python addled brain...
<voidspace> dooferlad: one comment so far
<TheMue> dooferlad: and added another one ;)
<fwereade> perrito666, the question is -- why do we expect service status to come back when we ask for unit status?
<fwereade> perrito666, it's fine to restrict auth to the leader unit
<fwereade> perrito666, but that's a property of the connection, not of the request
<fwereade> perrito666, we already know who's connecting, and can use that information to decide whether or not to give out information about X entity
<fwereade> perrito666, but this *doesn't* implement StatusGetter
<fwereade> perrito666, because StatusGetter is supposed to tell you the status of the thing you asked for
<perrito666> nope, it implements ServiceStatusGetter
<perrito666> I am now reading the rest of the code
<fwereade> perrito666, ...we already had a StatusGetter
<fwereade> perrito666, it only handed out unit statuses, because those were all that existed
<fwereade> perrito666, whether or not to hand out service statuses is purely an auth-level problem
<fwereade> perrito666, the StatusGetter is not a *Unit*StatusGetter
<fwereade> perrito666, it just accepts entities and returns their statuses
<fwereade> perrito666, if they have them, and if the current user is authorized to know whether they even exist
<fwereade> perrito666, make sense?
<perrito666> fwereade: not really, I feel like entering in a mid sentence conversation here
 * perrito666 goes and re reads the whole file to make sure we are talking about the same here
<fwereade> perrito666, heh, context is removing juju/juju/lease and seeing what failed
<fwereade> perrito666, getstatus.go was the second one; reading it, I got confused, and am not seeking understanding
<fwereade> s/not/now/
<perrito666> quick hangout?
<perrito666> I have 15 mins before my next meeting
<perrito666> (but you are not allowed to laugh on my winter clothing)
<fwereade> perrito666, sure
<fwereade> perrito666, would you start one please?
<perrito666> sure hold a sec
<fwereade> perrito666, actually 2 mins coffee refill
<perrito666> k
<perrito666> fwereade: https://plus.google.com/hangouts/_/gzh5yzfc4533ewopliwwbc62wya?hl=en
<TheMue> dooferlad: commented your question
<dooferlad> TheMue: diff updated
<TheMue> dooferlad: already pushed? cannot see it
<dooferlad> TheMue: doh! wrong branch. One moment.
<TheMue> *lol*
<TheMue> dooferlad: voidspace: hangout
<perrito666> fwereade: ping
<mup> Bug #1471242 changed: juju upgrade-juju to 1.24.2 fails with "invalid series: wily" <upgrade-juju> <juju-core:New> <https://launchpad.net/bugs/1471242>
<mup> Bug #1471936 opened: suite.TestRunCmd shows script failure <intermittent-failure> <unit-tests> <windows> <juju-core:Incomplete> <juju-core feature-proc-mgmt:Triaged> <https://launchpad.net/bugs/1471936>
<mup> Bug #1471941 opened: widows unit tests fail because handles are not avIlable <intermittent-failure> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1471941>
<mup> Bug #1470714 changed: Ubuntu downloads are non-obvious <juju-core:Fix Released> <https://launchpad.net/bugs/1470714>
<mup> Bug #1470876 changed: Deploy --to zone=<name> <add-unit> <deploy> <feature> <landscape> <placement> <juju-core:Triaged> <https://launchpad.net/bugs/1470876>
<mup> Bug #1472004 opened: agent-state error yet unit logs show no error <juju-core:New> <https://launchpad.net/bugs/1472004>
<mup> Bug #1472009 opened: manual provisioning with juju requires systemd-services <juju-core:New> <https://launchpad.net/bugs/1472009>
<mup> Bug #1472014 opened: juju 1.24.0: wget cert issues causing failure to create containers on 14.04.2 with lxc 1.07 <openstack-installer> <juju-core:New> <https://launchpad.net/bugs/1472014>
<perrito666> wallyworld: anastasiamac I completely blanked out
<wallyworld> perrito666: we are in standup if you want to join :-)
<wallyworld> fwereade: i will hang around in our standup hangout in case you do join
#juju-dev 2015-07-07
 * thumper wields a hatchet in one hand and a machete in the other
<thumper> and yet still manages to type
 * thumper dives into the code
<wallyworld> thumper: how many fingers do you have left?
<jam> wallyworld: /wave
<wallyworld> hi jam
<wallyworld> can i ping you in say 30 minutes?
<jam> I'm a little scattered to chat a bunch right now, but 30min should be good
<wallyworld> ok, we can start talking and schedule smething for later
<wallyworld> jam: you ok to talk? https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand
<jam> wallyworld: sorry I completely missed your message. Are you still around?
<wallyworld> jam: yeah, but off to soccer soonish, can i ping you in say 3 hours?
<jam> wallyworld: sure
<wallyworld> ok, will do
<jam> fwereade: voidspace: standup?
<voidspace> jam: omw
<voidspace> jam: fwereade: dooferlad: TheMue: I just got booted out, have to rejoin
<voidspace> aaaand... it doesn't work
<voidspace> time for some diagnostics
<wallyworld> jam: you free now?
<jam> wallyworld: can you give me a couple of mins?
<wallyworld> sure
<jam> wallyworld: I'm around now if you're up for chatting
<wallyworld> sure
<wallyworld> https://plus.google.com/hangouts/_/canonical.com/tanzanite-stand
<jam> says trying to connect. gimme a sec I guess
<jam> ah, I had to pass the magic authuser=1
<ashipika> is something wrong with the reviewboard?
<mup> Bug #1472231 opened: juju-mongodb derror when bootstraping on maas <juju-core:New> <https://launchpad.net/bugs/1472231>
<perrito666> morning
<wallyworld> dooferlad: hey, you around?
<wallyworld> or voidspace
<dooferlad> wallyworld: hi, was having lunch. How can I help?
<wallyworld> dooferlad: hey, bug 1472014 is because machine address updates for state server are not triggering the machine address watcher. it looks like the state server has around 3 cloud local IP addresses but only 1 is reported via the watcher. i was wondering if you could take a look and see what might need fixing
<mup> Bug #1472014: juju 1.24.0: wget cert issues causing failure to create containers on 14.04.2 with lxc 1.07 <openstack-installer> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1472014>
<wallyworld> comment #4 has a summary of the core issue
<dooferlad> sure, will take a look
<wallyworld> ty
<wallyworld> ping me if anything is unclear
<wallyworld> we can pick it up and make a fix, but i'd like a hand in diagnosing
<wallyworld> as i need sleep soon
<dooferlad> sounds good
<wallyworld> ty
<mup> Bug #1472231 changed: juju-mongodb derror when bootstraping on maas <mongodb> <juju-core:New> <https://launchpad.net/bugs/1472231>
<perrito666> katco: are you going to the call?
<ionutbalutoiu> mgz: bogdanteleaga told me that you need some help with powershell.
<ionutbalutoiu> mgz: I am a PowerShell Windows charmer from Cloudbase.
<mgz> ionutbalutoiu: hey there!
<mgz> ionutbalutoiu: so, background is I wrote some powershell to run over winrm that gathers up the logs on a remote juju machine and sends them back
<mgz> ionutbalutoiu: it all works fine, I'm just not doing exception handling and want some tps on making the code more idiomatic
<mgz> ionutbalutoiu: code is in lp:juju-ci-tools remote.py - can see original review at https://code.launchpad.net/~gz/juju-ci-tools/winrm_copy/+merge/262548
<mgz> ionutbalutoiu: want to do a hangout or discuss here?
<ionutbalutoiu> mgz: Let's discuss here. I can't join a hangout right now. So to be more specific, this is the piece of powershell code you're running over WinRM: http://bazaar.launchpad.net/~juju-qa/juju-ci-tools/trunk/view/head:/remote.py#L164
<mgz> ionutbalutoiu: THAT'S IT
<mgz> er... caps
<mgz> -shouting
<mgz> so, two main things I want to do, wrap the execution in try/catch and make the return code non-zero if something goes wrong, and handle files being unreadable better
<mgz> anything else you see?
<ionutbalutoiu> mgz:  Yes, that one and I'd recommend to add at the beginning of the script: $ErrorActionPreference = "Stop". This means that the script execution will end at the first unhandled exception.
<ionutbalutoiu> mgz: The default is: $ErrorActionPreference = "Continue" and it will continue even if an exception was thrown. We also set it to "Stop" in all our charms.
<mgz> what I wasn't clear on was what happens with trying to set an exit code with that
<mgz> the excepton still propogates and catch code gets run I presume?
<mgz> with continue, each exception gets logged at the top level and the next line in run
<ionutbalutoiu> mgz: If you have $ErrorActionPreference = "Stop" and use try/catch, you're exception will be caught, catch code will be executed and there you can return with exit code different than 0, as you say.
<ionutbalutoiu> mgz: but if an exception if caught it won't propagate unless thrown again, as in any other OOP language.
<dooferlad> wallyworld: bug updated
<ionutbalutoiu> mgz: is*
<mgz> ionutbalutoiu: so, I'm thunking something like this to start with http://paste.ubuntu.com/11836093
<wallyworld> dooferlad: thanks. i'm very wary of changing network related code. do you know why only the first cloud address is stored? and why the others are discarded? what if we change it so they are all stored, what will break?
<dooferlad> wallyworld: I don't know why we only pick one and the comments only tell us that we do, not why
<wallyworld> dooferlad: if you communicate with dimiter, could you ask him?
<wallyworld> i know he's at gophercon
<dooferlad> wallyworld: sure, he should be in email contact. Will bug him about the bug.
<wallyworld> ty, now i need sleep, i'll check the bug for updates when i wake up
<mgz> wallyworld: sleep well
<dooferlad> voidspace, TheMue: ^^ do you have any ideas?
<wallyworld> will try to :-) so much juju to worry about :-)
<sinzui> alexisb: mgz Roger's projects (Go packages) have ambiguous or contradictory licensing info. https://github.com/go-errgo/errgo/tree/v1 is the most concerning. Roger holds copyright and issue it under bsd-style, but every code file us owned by Canonical under LGPL and site the Roger's LICENSE.
<alexisb> sinzui, so what is the path for address the LICENSE issues?
<voidspace> dooferlad: no, I don't know why we only store one cloud local address
<sinzui> alexisb: I think Roger needs to reconcile the issue. If it is a mistake, that is fixable in a commit, then we are not blocked.
<alexisb> sinzui, ok, can you send roger and uros a note
<alexisb> roger is currently at gophercon but hopefully he will read mail
<sinzui> alexisb: I am
<alexisb> awesome thanks sinzui !
<ahasenack> hi, does anyone know how a machine agent is told where to find the state server?
<ahasenack> I ask because on a container of mine it is trying to connect to localhost, which is incorrect
<mup> Bug # changed: 1457205, 1464470, 1468994, 1470150
<alexisb> wallyworld, thumper release call?
<wallyworld> menn0: hey
<menn0> wallyworld: howdy
<wallyworld> menn0: as ocr today, can i ask that you pay particular attention to any windows related PRs? as i've been told these are critical to get landed for 1.24
<menn0> wallyworld: ok will do
<wallyworld> i think there's 3 of them
<wallyworld> ty
<wallyworld> menn0: with the zip tools one, i've provided input on that already and it needs rework, so that's WIP so you can skip that one
<wallyworld> i've talked to them online about it
<menn0> wallyworld: ok thanks
<menn0> wallyworld: did you see the changes I made to the certupdater to fix the race?
<wallyworld> not yet, just in passing,but thank you for fixing my fck up
<menn0> wallyworld: I wouldn't say it was that bad. pretty subtle really, and I know you originally did that work under fairly extreme time pressure.
<wallyworld> yeah, but that's how we always work right? :-)
<menn0> wallyworld: it's here anyway if you want to see it: http://reviews.vapour.ws/r/2095/ (it's in 1.24 and master)
<wallyworld> \o/ ty
<wallyworld> looks like there's 3 windows prs - 2106, 2109 and 2006
<waigani> thumper, menn0: environment destroy cmd: http://reviews.vapour.ws/r/2110/
<menn0> wallyworld: i'm looking at 2106 now
<thumper> waigani: cheers, I would like to look before you land it
<menn0> waigani: cool, will get to it soon
<waigani> thanks both :)
<mup> Bug #1468354 changed: RelationUnitSuite setup fails <ci> <unit-tests> <juju-core:Fix Released> <https://launchpad.net/bugs/1468354>
<mup> Bug #1468355 changed: TestAddStoreCharmPlaceholder fails <ci> <test-failure> <juju-core:Fix Released> <https://launchpad.net/bugs/1468355>
<menn0> wallyworld: all windows PRs reviewed
<wallyworld> menn0: awesome, ty
<menn0> wallyworld: I think they're all pretty close
<wallyworld> great yeah, still a few other issues also to unlock 1.24.3
<wallyworld> arm issue being one :-(
<menn0> wallyworld: I'd like to get this in as well: https://github.com/juju/juju/pull/2724
<wallyworld> menn0: indeed, that would be good to land
 * wallyworld relocating, afk for a bit
#juju-dev 2015-07-08
<thumper> menn0: are you getting time to finish off https://github.com/juju/juju/pull/2724?
<menn0> thumper: working on that right now
<menn0> thumper: not far
<thumper> cool
<menn0> thumper: done, about to merge
<perrito666> mehh I was reviewing a pr and when I got to the end it got discarded
<anastasiamac> perrito666: :(
<anastasiamac> perrito666: what time is it for u?
<thumper> wallyworld: I don't suppose someone on your team can fix the intermittent failure in uniter worker?
<thumper> FAIL: uniter_test.go:892: UniterSuite.TestUniterUpgradeConflicts
<thumper> happens relatively regularly
<perrito666> anastasiamac: 22:30
<wwitzel3> axw: ping
<wallyworld> thumper: sorry, missed ping about failing test. will take a look. currently full with WIP fixes for 1.25 release and soon a critical customer issue which is more a feature thana bug
<wallyworld> i suspect will be end of week or early next
<wallyworld> also working on arm issue for 1.24.3
<menn0> wallyworld, thumper: the mongodb timeout PR has landed in 1.24
<wallyworld> great
<wallyworld> do we know who to prod to see if it helps with anything?
<menn0> wallyworld: ahasenack reported the bug that lead to me doing this work (i'm not sure if it will help or not)}
<wallyworld> ok
<menn0> thumper also thinks it might help with a problem env he was looking at
<wallyworld> time will tell i guess
<menn0> wallyworld: so what is the github.com/juju/juju/juju package all about?
<menn0> seems like stuff that I would have expected to be in the state package
<wallyworld> menn0: that package is sort of an attempt to get stuff out of state as far as i understand
<wallyworld> it is horribly named
<menn0> wallyworld: so state helpers then?
<cherylj_> wwitzel3: ping?
<wallyworld> menn0: more like juju core business logic
<wallyworld> that is not persistence related
<menn0> hmm ok
<wallyworld> i didn't add it :-)
<thumper> menn0: cool
<menn0> wallyworld: I didn't think you did
<wallyworld> i can't defend it too hard :-)
<menn0> wallyworld: review done
<wallyworld> ty menn0
<wallyworld> thumper: have you picked up much about juju and arm via osmosis?
<thumper> nope
<wallyworld> and dave is away this week :-(
<thumper> aye
<anastasiamac> thumper: u got a fish trophy!
<wallyworld> jam: hi
<jam> hey wallyworld
<wallyworld> jam: network related question if you have a moment
<wallyworld> bug 1472014
<mup> Bug #1472014: juju 1.24.0: wget cert issues causing failure to create containers on 14.04.2 with lxc 1.07 <openstack-installer> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1472014>
<wallyworld> see the last couple of comments
<wallyworld> it seems we don't store / report all the cloud local addresses for a machine
<wallyworld> so a machine's AddressWatcher doesn't get told about all possible addresses an https request can arrive on
<wallyworld> do you know why we throw away some cloud local addresses?
<wallyworld> i'm not looked at the code in detail, just going by jame's comment
<wallyworld> but i'm wary about changing network related code
<wallyworld> as it has the habit of breaking things
<jam> wallyworld: so offhand I'd say we don't actually cope with having multiple addresses where things could arrive
<jam> wallyworld: consider charms, they can only really report 1 private address to eachother
<wallyworld> hmmm, so which one to pick then
<jam> wallyworld: so the issue is probably that we are thinking 10.0.6.* is the right address, when really the correct cloud-local address is the 10.0.3* one
<wallyworld> as we are picking the wrong one
<wallyworld> hmmm, so how to pick the right one
<jam> wallyworld: so that machine has 3 addresses that I would consider "cloud-local" sort of addresess, a 10.0.3 a 10.0.6 and a 192.168
<wallyworld> for this purpose we should just stick everything in the SAN
<jam> wallyworld: Surprisingly (for me) 10.0.3 is usually the LXC bridge (I thought)
<wallyworld> jam: what about this line : setting API hostPorts
<jam> wallyworld: I think in the  idealized model Juju would be aware of all the subnets and have labled names for them (spaces), in which case it would know that machine X is supposed to talk to machine Y on a given address.
<wallyworld> it seems there we pass in everything
<jam> wallyworld: internally it feels like we should be aware and save all the addresses
<wallyworld> yes, save them all internally sounds good to me too, but if we do that now stuff would break i would tink
<jam> wallyworld: short term, I think just adding all addresses to the SAN is fine.
<wallyworld> but
<wallyworld> that relies on AddressWatcher :(
<wallyworld> so i'll need to change how it all works
<wallyworld> bollocks
<wallyworld> i'll go read the code and see what can be done
<jam> wallyworld: well, I think you can certainly get help from Sapphire on this one.
<wallyworld> jam: i asked but none were 100% sure about why only one address was saved etc
<wallyworld> so maybe there's not the level of knowledge there to dive right in
<jam> wallyworld: well, dimitern is away and the others probably not quite as familiar
<jam> gophercon being this week.
<wallyworld> yeah, that's what i figured, hence asking you :-)
<wallyworld> i'll see if it's possible to tinker with the cert updater
<wallyworld> i could re-read all machine addresses
<wallyworld> but may not be triggered
<dooferlad> wallyworld, jam: just read the backlog. Yell if you want a networking hand.
<dooferlad> wallyworld: also with ARM, I am an ex-ARM employee so if I can help with that please call on me
<wallyworld> dooferlad: oh, i might take you up on that arm offer. i might ping you after dinner
<dooferlad> jam, fwereade: hangout?
<voidspace> fwereade: git blame -L302,302 provider/ec2/config_test.go
<voidspace> fwereade: that's the test that fails for me on master
<voidspace> fwereade: git blame may be deceived of course...
<mattyw> fwereade, quick ping?
<fwereade> mattyw, heyhey
<mattyw> fwereade, is there any doc or something about the uniter operation/ callbacks arch? I'm finding myself getting in to it and was hoping I could make some decisions about my stuff without having to hassle you
<fwereade> mattyw, only what's inline, I'm afraid
<mattyw> fwereade, I probably only want to call a certain function when a certain hook has finished
<fwereade> mattyw, that sounds like the responsibility of the CommitHook bit to me?
<fwereade> mattyw, but the callbacks themselves are basically evil
<mattyw> fwereade, time for a 5 minute hangout?
<fwereade> mattyw, it's basically just a cut-down uniter facade/adapter for the use of the ops
<mattyw> fwereade, I'll try to timebox it at that
<fwereade> mattyw, sure, start one please?
<wwitzel3> ericsnow: ping
<mup> Bug #1472596 opened: bootstrap failed yet retry says it succeeded <juju-core:New> <https://launchpad.net/bugs/1472596>
<mgz> bogdanteleaga: is rr 2107 live or not atm?
<bogdanteleaga> mgz: no it's not
<bogdanteleaga> mgz: it's more of a weird interaction, 2109 is the same but should show a better diff
<bogdanteleaga> mgz: any ideas if I can delete that one?
<mgz> bogdanteleaga: it is marked as discarded, so that's probably fine, is just getting updated still I guess as it's the same github branch
<bogdanteleaga> mgz: yeah, that was the one submitted to github, but the diff would be a bit funky since it contains another branch
<mgz> bogdanteleaga: do you need anything else on those branches, or are you good to go?
<mgz> bogdanteleaga: I think we'll want to backport to 1.24 after master has blessed the change
<bogdanteleaga> mgz: no, I was doing some final tests a couple of hours ago, but everything seems fine
<bogdanteleaga> mgz: got caught up with something else
<mgz> bogdanteleaga: no problem
<bogdanteleaga> mgz: squashing now and I'll start merging
 * bogdanteleaga grabs popcorn
<mgz> :)
<wwitzel3> ericsnow: ping
<ericsnow> wwitzel3: hey hey hey
<wwitzel3> ericsnow: trying to work through an issue and I've run in to some code that I could use some help deubgging
<ericsnow> wwitzel3: sure
<ericsnow> wwitzel3: moonstone?
<wwitzel3> ericsnow: we can go to a query, conference wifi probably won't work so well with a hangout
<ericsnow> wwitzel3: right :)
<bogdanteleaga> mgz: you said they ought to be backported?
<mgz> bogdanteleaga: I think we do need it on 1.24, yeah
<mgz> want to see it work on master first of course
<bogdanteleaga> mgz: Build failed: Does not match ['fixes-1472632']
<bogdanteleaga> can't find a bug with that number
<mgz> abentley: ^did you mean to make that bug a blocker and private?
<abentley> mgz: Yes.
<mgz> it does not really strike me as either
<abentley> mgz: Regressions are blockers.
<abentley> mgz: It has debug logs from SSH.
<mgz> I am reading the debug ssh log and apart from containing your name and some of juju-ci's ips addresses it seems to have nothing personal
<mgz> and I don't see how this bug prevents us releasing, which is the point of blockers
<mgz> we've been releasing fine with this for three 1.24-s
<abentley> mgz: Well, I was erring on the side of caution with the SSH.  If you're willing to take responsibility for making it public, I'm fine with that.
<abentley> mgz: I don't know why we've continued to make releases after it was discovered.  I assumed sinzui had filed a regression bug, since he knew about it.
<sinzui> abentley: I didn't know about it
<mgz> abentley: okay. I can confirm this does not contain your private ssh keys. :)
<abentley> sinzui: Oh? Didn't you say you'd had to rename your ssh key to id_rsa to deal with this issue?
<mgz> abentley: the issue with the ssh stuff is it depends somewhat on your personal setup, so I knew that the combo of my local ssh config + juju ci scripts borked ssh for juju
<sinzui> abentley: yes, for just bootstrapping ec2 and openstack providers. I haven't seen any issue with other providers or ssh in general
<mgz> I agree this is a regression, but given it has an annoying but somewhat trivial workaround (don't use your personal ssh config) I don't see how it's critical
<sinzui> abentley: nd this behaviour matches the windows setup from 18 months ago
<abentley> mgz: I don't think the existence or lack of workarounds is a factor in whether an issue should block.  We don't want to break users' existing workflows, and this does break users' existing workflows.
<sinzui> abentley: I don't disagree
<mup> Bug #1472632 opened: regression: juju ssh dies with (publickey) <blocker> <regression> <ssh> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1472632>
<alexisb> abentley, do we know what commit caused the regression?
<alexisb> I would like to see bogdanteleaga be able to land his fix, it is a critical fix for 1.24.3
<abentley> alexisb: No, we don't know which commit.  We found it by hand, not with automated tests, so we don't have logs that would show it.
<alexisb> abentley, ok
<alexisb> sinzui, abentley, mgz there will not be anyone from core looking at that bug until NZ/AUS comes online
<mgz> I don't see how blocking is productive for this issue, nor how it's justified by our procedure
<sinzui> alexisb: it doesn't blocl
<sinzui> not tag blocker
<mgz> sinzui: it has that tag currently, I was planning on raising in standup in 5 mins
<alexisb> sinzui, ok, I must have miss read the back scroll
<alexisb> I thought bogdanteleaga was blocked
<mgz> sinzui: `./check_blockers.py check master`
<sinzui> alexisb: if he is, he can add __JFDI__  to $$merge$$ to make it mege and test <- bogdanteleaga
<mgz> noo..
<mgz> either the bug blocks or it doesn't, we shouldn't be bypassing
<mgz> I don't think it should block.
<bogdanteleaga> it is blocked currently, but this is just the fix for master, the one for 1.24 is coming up
<bogdanteleaga> not sure how long it takes for the upgrade ci job to test the fix though
<sinzui> mgz: as we don't have a test for it and the regression is in the wild, we don't need to block. I think this is like the expressions closing the stable door after the horse has bolted
<abentley> sinzui: That assumes that the number of people who have not upgraded to 1.24 is not significant.  I think that it is significant.  I think every time we put out a release, especially if we release 1.25, we encourage people who are using 1.23 and earlier to upgrade.
<sinzui> bogdanteleaga: use "$$merge$$ fixes-1471332" to the pull requet comment to ensure CI will test and merge
<bogdanteleaga> sinzui: I did try it with __JFDI__ but I fluked a test
<bogdanteleaga> sinzui: should be fine on the next try; should I use jfdi or fixes?
<sinzui> either bogdanteleaga
<bogdanteleaga> cool
<voidspace> dooferlad: TheMue: if you have a chance I'd appreciate a review http://reviews.vapour.ws/r/2116/
<TheMue> voidspace: one moment, hunting a test failure, but will start in a few seconds
<voidspace> cool, thanks
<voidspace> good luck with the hunt :-)
<TheMue> ah, kewl, panic is gone. now I can jump into your review
<TheMue> voidspace: seeing your new ReleaseAddress() signature. could it be that the passed address doesn't match to the passed MAC address? IMHO they always should be a kind of pair with 1:N (one MAC, multiple IP)
<voidspace> TheMue: no they're always 1:1
<voidspace> TheMue: the MAC comes from state.IPAddress
<voidspace> instance id is stored there too
<TheMue> voidspace: ok, but technologically one MAC could have oÂ´multiple IP, we only don't model it so right now
<voidspace> ah
<voidspace> our model does allow that, sorry
<voidspace> although we don't use that capability
<TheMue> ok
<voidspace> so yes, one mac address could have multiple ip addresses - and we handle that
<voidspace> we only delete the device if the IP address is the last one
<voidspace> otherwise we just release the address normally
<voidspace> biab, grabbing coffee whilst you read
<TheMue> voidspace: you've got a review
 * TheMue is afk for a moment, continue later
<voidspace> TheMue: thanks
<mup> Bug #1472711 opened: MAAS node has "failed deployment", juju just says "pending" <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1472711>
<mup> Bug #1472729 opened: juju stuck in "upgrade in progress " for 20min <juju-core:New> <https://launchpad.net/bugs/1472729>
<mup> Bug #1472729 changed: juju stuck in "upgrade in progress " for 20min <juju-core:New> <https://launchpad.net/bugs/1472729>
<mup> Bug #1472729 opened: juju stuck in "upgrade in progress " for 20min <juju-core:New> <https://launchpad.net/bugs/1472729>
<mup> Bug #1472749 opened: github.com/juju/utils has contradictory licences <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1472749>
<marcoceppi> hello world
<marcoceppi> maas 1.8.0 juju 1.24.2 deploying to LXC containers seems stuck, it's trying to wget the image from the bootstrap node/api server and it's been doing that for like 15 mins
<marcoceppi> jk, it's moving on now
<alexisb> hey marcoceppi welcome back from vacation
<marcoceppi> alexisb: hey, thanks!
<thumper> holy shit balls
<thumper> these worker tests are taking ages to run...
<thumper> FAIL	github.com/juju/juju/state/leadership	1200.021s
<thumper> hmm
<thumper> timeout kill
<marcoceppi> nbd, 20 min tests
<thumper> nbd?
<marcoceppi> no big deal
<thumper> nah man, it is a big deal
<thumper> this is broke
<menn0> thumper: shall I pick up the juju ssh blocker?
<thumper> bug?
<menn0> thumper: bug 1472632
<mup> Bug #1472632: regression: juju ssh dies with (publickey) <blocker> <regression> <ssh> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1472632>
<menn0> it's blocking master and 1.24
<alexisb> sinzui, ^^ I thought we had decieded that bug was not a blocker
<alexisb> menn0, we discussed that one earlier today
<thumper> menn0: I think abentley's analysis is wrong
<thumper> menn0: if you look at the logs, it was his personal id_rsa that worked
<thumper> but 1.24 and master did not appear to be trying
<menn0> thumper: i haven't looked at it in any detail
<alexisb> so menn0, thumper, my understanding from this morning is that bug should not be a blocker and the tag was going to be removed
 * thumper removes blocker tag
<alexisb> unfortunately I don't see any of the release dudes online atm
<alexisb> sweet
<menn0> thumper, alexisb: cool. that unblocks master
<menn0> 1.24 is still blocked due to the window upgrade issue
<menn0> i've just been talking to bogdanteleaga
<menn0> he's waiting to see the problem is fixed on master before pushing the fixes to 1.24
<thumper> that shouldn't block 1.24 then
<menn0> the PR to fix 1.24 is ready to go though
<menn0> thumper: no?
 * thumper thinks
<thumper> it will block us doing a release
<thumper> but I don't think it should block us landing other fixes on 1.24
<menn0> thumper: remove the blocker tag then?
<thumper> menn0: do we know if it fixed the issue on master?
<menn0> thumper: no we don't. CI hasn't gotten to running it yet
<menn0> thumper: bogdanteleaga just noticed that his fix broke the unit tests under windows so he's going to do a fix for that now
<wallyworld> waigani_: can you take a look at 1.24 bug 1472711? it claims bug 1376246 may not quite be fixed
<mup> Bug #1472711: MAAS node has "failed deployment", juju just says "pending" <maas-provider> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1472711>
<mup> Bug #1376246: MAAS provider doesn't know about "Failed deployment" instance status <landscape> <maas-provider> <juju-core:Fix Released by waigani> <juju-core 1.24:Fix Released by waigani> <https://launchpad.net/bugs/1376246>
<thumper> rick_h_: hey there
<menn0> thumper: so the windows upgrade still isn't working in CI
#juju-dev 2015-07-09
<menn0> thumper: bogdan is going to continue with it tomorrow but he's done for today
<thumper> :-(
<menn0> only machine 0 seems to upgrade and then others don't
<menn0> i'll get some reviews out of the way and then i'll take a look through the logs
<menn0> thumper, wallyworld: i've been chatting to bogdanteleaga
<bogdanteleaga> so the issue with the upgrade thing
<menn0> the CI test isn't going to work because it's upgrading from 1.24.2
<menn0> and the 1.24.2 agent won't restart for the upgrade on windows
<bogdanteleaga> pretty much
<bogdanteleaga> the starting agent needs to have the fix
<menn0> bogdanteleaga: and they're the fixes you have in the PR that's up already?
<bogdanteleaga> yep
<thumper> is there a workaround for users that have an older windows version?
<bogdanteleaga> I guess we either merge that and wait for it to be released, or make a different job
<thumper> how do they upgrade?
<bogdanteleaga> they have to manually restart the service I'm afraid
<bogdanteleaga> the upgrade itself works
<thumper> so if they just restart the service, it works, but not if they don't?
<thumper> is this a regression from previous windows versions, or new?
<bogdanteleaga> it doesn't know to start back up by itself
<bogdanteleaga> it might be a regression since the new service package was introduced
<thumper> hmm
<bogdanteleaga> not completely sure what we did before
<thumper> when was it introduced?
<bogdanteleaga> let me check
<thumper> also, which was the first juju version where we supported windows?
<thumper> do those versions upgrade to the released versions?
<thumper> that's a key question
<wallyworld> thumper: menn0: bogdanteleaga: if we need to documemtn a one off manual work around to get past this issue, i think that's ok
<bogdanteleaga> afaik the first one was 1.21
<bogdanteleaga> 1.23 has the old implementation
<bogdanteleaga> I'd have to try it out to see if it works though
<bogdanteleaga> the powershell code does not look promising
<bogdanteleaga> (to create the services)
<menn0> bogdanteleaga: is manually testing an upgrade from 1.24 with the proposed fixes to master
<menn0> thumper: ^^^
<menn0> if that works he's going to merge that into 1.24 so that at least 1.24.3 won't have this problme
<menn0> we won't have CI success until 1.24.3 is released
<thumper> ack
<menn0> wallyworld: recap since you were disconnected: bogdanteleaga is manually testing an upgrade from 1.24 with the proposed fixes. if that works he's going to merge that into 1.24 so that at least 1.24.3 won't have this problem. we won't have CI success until 1.24.3 is released
<wallyworld> ok ty
<wallyworld> and for older deploys, we restart service manually
<bogdanteleaga> all good
<bogdanteleaga> I'll merge it in
<wallyworld> waigani: hey, did you see my ping before about the maas failed deployment bug?
<waigani> wallyworld: no sorry
<waigani> wallyworld: do you have a link?
<wallyworld> waigani_: can you take a look at 1.24 bug 1472711? it claims bug 1376246 may not quite be fixed
<mup> Bug #1472711: MAAS node has "failed deployment", juju just says "pending" <maas-provider> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1472711>
<mup> Bug #1376246: MAAS provider doesn't know about "Failed deployment" instance status <landscape> <maas-provider> <juju-core:Fix Released by waigani> <juju-core 1.24:Fix Released by waigani> <https://launchpad.net/bugs/1376246>
<waigani> wallyworld: sure
<wallyworld> tyvm
<rick_h_> thumper: howdy?
<thumper> rick_h_: I'm not around tomorrow
<rick_h_> thumper: k
<thumper> rick_h_: just letting you know as we normally have a call
<rick_h_> thumper: anything I should know?
<thumper> only that we have slow progress, but expect it in 1.25
<thumper> 1.25 feature freeze pushed out so we can hit it
<rick_h_> thumper: ok, did that stuff help with the jes/system/environment destroy stuff?
<thumper> rick_h_: yeah, rehashing now
<thumper> although I have a few questions
<thumper> got 5 minutes now?
<thumper> for a hangotu?
<rick_h_> sure thing, just have to watch me eat dinner :) /me grabs headphones
<thumper> kk
<thumper> rick_h_: https://plus.google.com/hangouts/_/canonical.com/rick
<bdx> hey whats going on everyone?
<bdx> I'm looking for a way to seed a custom cloud-config to my juju deployed machines...I can use maas post install scripts for machines managed by maas, but I need my custom cloud-config to run on containers too. Is there a "best practice" way to do this with juju??
<bdx> from what I can tell juju creates the cloud init for lxc services here: https://github.com/juju/juju/blob/master/cloudconfig/containerinit/container_userdata.go
<bdx> amongst other places
<bdx> I'm thinking there has to be a way to pass a cloud-config file as an extra parameter when deploying services ....possibly I'm just missing somethig....
<bdx> charmers:^^
<marcoceppi> bdx: this is definitely a question for core, most charmers don't have this type of requirement
<marcoceppi> bdx: may I ask what you're trying to customize?
<bdx> marcoceppi: ok, thanks. -- I'm trying to automate my puppet cloud-config getting onto containers deployed by juju
<marcoceppi> bdx: why wouldn't you just have that wrapped in a charm?
<bdx> oooh ....like a secondary charm that I would deploy that was just puppet cloud-config?
<marcoceppi> bdx: sure, you could have it be a subordinate for example
<bdx> marcoceppi: Oooh totally...thats a great idea!
<marcoceppi> bdx: I'd have to know more about what this puppet stuff was doing and the goal, but charming is really the best way to interact with the machines juju gives you after deployment
<bdx> marcoceppi: totally....we have keys and users amongst other things that need to get onto each machine post deploy ... our infra is tightly tied in with a few puppet classes that are mandatory...plusss our newrelic and papertrial stuff ...
<marcoceppi> bdx: ah, yeah, so I would totally make a "my-management-stuff" subordinate that you just throw on everything. We also have papertrail and new-relic charms, but if those area already puppetized, just have that subordinate do all that for you
<bdx> marcoceppi: awesome. Do you know any hot docs for creating subordinate charms?
<marcoceppi> bdx: it's just like a normal charm, except you set subordinate: true in the metadata.yaml and you need a relation in the new subordinate charm
<marcoceppi> bdx: let me get you a link to the docs
<marcoceppi> bdx: https://jujucharms.com/docs/stable/authors-subordinate-services and https://jujucharms.com/docs/stable/authors-implicit-relations
<marcoceppi> bdx: here's an example metadata.yaml since those pages are...confusing
<bdx> marcoceppi: I have been scoping this too
<bdx> http://spamaps.org/files/charm-store-policy/drafts/subordinate-internals.html
<bdx> marcoceppi: nice! thanks!
<bdx> marcoceppi: thats awesome...that will be a perfect solution for what I'm trying to do here
<marcoceppi> bdx: http://paste.ubuntu.com/11845656/
<marcoceppi> that's all you need to make a subordinate charm, the rest is the same as a primary charm structure
<marcoceppi> lines 8 and 10-12 are the special bits
<bdx> thats so simple
<bdx> beautiful
<marcoceppi> bdx: so, as you deploy services, just do a juju add-relation <service> <your-subordinate> and it'll attach to all units in that service, even as you scale out/in
<bdx> marcoceppi: nice...even if the service exists on a container already?
<marcoceppi> bdx: regardless of the system the service is on
<marcoceppi> bdx: if it's deployed by juju, on metal, a VM, or a container
<bdx> sick
<bdx> sweet
<bdx> thats perfect....I'm going to implement it now....I'll let you know how it goes
<marcoceppi> bdx: awesome, I should be around for a few more hours if you have any questions
<bdx> marcoceppi: awesome. thanks again for the advice
<menn0> wallyworld, thumper: so 1.24 is still blocked and we won't know for sure whether that bug is fixed until 1.24.3 is released and the CI test starts using that
<menn0> wallyworld, thumper: should we removed the blocker tag?
<wallyworld> menn0: what bug is it blokec on?
<menn0> wallyworld: the windows upgrade one
<menn0> bug 1471332
<mup> Bug #1471332: Upgrade fails on windows machines <blocker> <ci> <upgrade-juju> <windows> <juju-core:In Progress by bteleaga> <juju-core 1.24:In Progress by bteleaga> <https://launchpad.net/bugs/1471332>
<wallyworld> ah, i didn't realise that one was a blocker
<wallyworld> i think based on your explanation above we could remove the blocker tag
<menn0> wallyworld: cool. i'll do that and add some detail to the bug
<wallyworld> ty
<menn0> thumper: one line review please: http://reviews.vapour.ws/r/2124/
 * thumper looks
<thumper> menn0: shipit
<menn0> 1.24 is now unblocked
<wallyworld> waigani: did you get a chance to look at bug 1472711 ? is it something that juju core needs to fix?
<mup> Bug #1472711: MAAS node has "failed deployment", juju just says "pending" <maas-provider> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1472711>
<wallyworld> menn0: we can mark bug 1469199 as fix committed right?
<mup> Bug #1469199: State server seems to have died <cloud-install-failure> <cloud-installer> <landscape> <juju-core:In Progress by menno.smits> <juju-core 1.24:In Progress by menno.smits> <https://launchpad.net/bugs/1469199>
<wallyworld> on 1.24?
<menn0> wallyworld: not sure
<menn0> wallyworld: we've committed 2 possible fixes
<menn0> wallyworld: but they might not be it
<menn0> wallyworld: I can't repro it reliably
<wallyworld> is a stakeholder going to test?
<menn0> wallyworld: so I don't know the problem is fixed
<wallyworld> we could mark as fix committed so 1.24.3 can go out
<menn0> wallyworld: seems the issue hasn't happened for a while
<menn0> wallyworld: yeah, mark it as fix committed. the stakeholder said they would report back if the issue happens again (with 1.24.3 or otherwise)
<wallyworld> ok, ty
<wallyworld> master too?
<menn0> wallyworld: we can always reopen it and it's not like we can do anything more
<wallyworld> yep
<menn0> wallyworld: yep master too
<wallyworld> ok
<menn0> wallyworld: I just marked bug 1465115 as fix committed too. that just merged.
<mup> Bug #1465115: api: data race in test <intermittent-failure> <race-condition> <unit-tests> <juju-core:Fix Committed by dave-cheney> <juju-core 1.24:Fix Committed by menno.smits> <https://launchpad.net/bugs/1465115>
<waigani> wallyworld: it's next on my list. I'll just finish this and look at it now.
<wallyworld> ty
<wallyworld> waigani: add any comments to the bug so we can see what's happening at the release standup tomorrow
<waigani> wallyworld: okay, will do.
<wallyworld> thanks menn0
 * wallyworld relocating, afk for a bit
<fwereade> axw, wallyworld: don't suppose either of you had a chance to look into the add-machine issue I mailed you about?
<mgz> bogdanteleaga: thanks for landing the upgrade changes
<mgz> bogdanteleaga: do I understand from menno's comment that we can never automatically upgrade from any existing juju versions with windows units?
<voidspace> mgz: I created a PR that I was expecting to get reviewed, it seems to have landed! Presumably without a test run (although tests pass of course...)
<voidspace> mgz: https://github.com/juju/juju/pull/2750
<voidspace> mgz: can you see what I did wrong? Presumably I pressed the wrong button somewhere...
<mgz> >_<
<voidspace> mgz: hmm... I don't think I did, I think a test run was completed for a different PR and this one was merged
<voidspace> mgz: I had a PR for this branch which I added the magic $$merge$$ cookie - that PR has vanished
<voidspace> mgz: https://github.com/voidspace/juju/tree/devices-master-merge-4
<mgz> well, that was a fun mystery
<voidspace> mgz: hah, oops... :-)
<bogdanteleaga> mgz: not with whatever is released now
<bogdanteleaga> mgz: I'll ask somebody to try 1.23 later today, but I'm not having high hopes
<bogdanteleaga> mgz: 1.24.x won't work until 1.24.3
<mgz> bogdanteleaga: CI happened to do a 1.22.7 run - that also failed
<mgz> so, I guess upgrades just won't work for existing windows envs
<mgz> bogdanteleaga: I think we need to document some manual steps
<mgz> even if the sanest thing really is to tear down the existing env and start again
<bogdanteleaga> mgz: yeah, then it's almost certain to fail on 1.23 as well
<mgz> bogdanteleaga: I've changed the CI job to try to upgrade from your fixed 1.24 - so we'll see if the job passes like that
<bogdanteleaga> mgz: for 1.24 it can be as easy as accessing the machine and restarting the service
<bogdanteleaga> might be the same for the rest, but it needs to be tested
<mgz> if I can run that over winrm, that's also possible to script
<bogdanteleaga> I don't see why not
<mgz> though I guess it needs to see the upgrade first, then do the restart
<bogdanteleaga> mgz: you can probably just query the service
<bogdanteleaga> mgz: and when it stops just start is back up
<bogdanteleaga> mgz: but you need to do the same for the units, which will stop after you upgraded the machine agent
<frankban> ericsnow or axw: could you please take a look at https://github.com/juju/names/pull/52 ? thanks!
<mup> Bug #1473069 opened: Inconsistency of determining IP addresses in MAAS environment between hosts and LXC containers <addressability> <lxc> <maas-provider> <network> <juju-core:New> <https://launchpad.net/bugs/1473069>
<mup> Bug #1473069 changed: Inconsistency of determining IP addresses in MAAS environment between hosts and LXC containers <addressability> <lxc> <maas-provider> <network> <juju-core:New> <https://launchpad.net/bugs/1473069>
<mup> Bug #1473069 opened: Inconsistency of determining IP addresses in MAAS environment between hosts and LXC containers <addressability> <lxc> <maas-provider> <network> <juju-core:New> <https://launchpad.net/bugs/1473069>
<marcoceppi> hey
<marcoceppi> quick help
<marcoceppi> what's the command to get the list of help for commands you run in hook env
<marcoceppi> on a call
<marcoceppi> in a pinch
<marcoceppi> juju help-tool
 * marcoceppi high fives
<marcoceppi> himself
<rick_h_> go marcoceppi go
<mgz> marcoceppi: also `juju run --unit some-unit/0 "close-port --help"` works
<mgz> for help on specific tools
<makyo_> sinzui, ping
<sinzui> hi makyo_
<makyo_> sinzui, working on setting up some nightly testing with Jenkins and am trying to get it to send emails to us for build status. Does QA have any experience with that?
<sinzui> makyo_: no, we abandoned Jenkins sending emails. our emails are sent by a script that inerprets the results
<makyo_> sinzui, Ah, alright.  None of the solutions I found in Jenkins land were all that good, yeah. Is that up on LP/GH somewhere?
<sinzui> makyo_: I can suggest that is builds are trigger other builds, or something watching the builds an trigger a "results" job, you can collect everything for an email and you have a choice of trying to use jenkins' infrastructure or adding your own
<sinzui> makyo_: lp:ci-director does some of the emails
<makyo_> sinzui, alright, thanks.  Will give it a look.
<makyo_> That sounds good.
<katco> ericsnow: o/
<ericsnow> katco: \o
<katco> ericsnow: how's the bug-fix coming?
<katco> ericsnow: sorry i haven't been around
<ericsnow> katco: np
<ericsnow> katco: good
<ericsnow> katco: wish we had sorted all this out thursday/friday :(
<katco> ericsnow: yeah =/
<sinzui> makyo_: for any job, you can check email-notification. It includes the conole log. So a "results" job that summarises other jobs can do what you want cheeply.
<katco> ericsnow: we've just been demoing basic stuff, it's ok
<katco> ericsnow: but was wondering if we'd have anything ready for today?
 * sinzui has set this up, but gets these emails from other jenkins
<ericsnow> katco: wwitzel3's working on it
<katco> ericsnow: hm. last time i talked to him he said you were ;) maybe different bug?
<ericsnow> katco: I'm pretty sure I fixed everything I could yesterday
<makyo_> sinzui, alright, that makes sense yeah
<ericsnow> katco: I've been helping wwitzel3 as much as I can this morning
<mup> Bug #1473197 opened: openstack: juju failed to launch instance, remains pending forever <juju-core:New> <https://launchpad.net/bugs/1473197>
<mup> Bug #1473197 changed: openstack: juju failed to launch instance, remains pending forever <juju-core:New> <https://launchpad.net/bugs/1473197>
<mup> Bug #1473197 opened: openstack: juju failed to launch instance, remains pending forever <juju-core:New> <https://launchpad.net/bugs/1473197>
<mup> Bug #1473209 opened: github.com/juju/juju/service/windows undefined: newConn <ci> <intermittent-failure> <test-failure> <unit-tests> <windows> <juju-core:Triaged> <juju-core trunk:Triaged> <https://launchpad.net/bugs/1473209>
<alexisb> wallyworld, ping me whn you are in please
<wallyworld> alexisb: hi, just about to go into meeting, i'll try and get you before release standup
<wallyworld> alexisb: free now
<alexisb> lets jump on our hangout
<sinzui> wallyworld: do you have time to review http://reviews.vapour.ws/r/2135/
<wallyworld> sinzui: yes, will do
<wallyworld> sinzui: lgtm
<sinzui> thank you wallyworld. this is an example armhf build log the trusty 1.20.11 has the same deps and looks similar https://launchpadlibrarian.net/210434988/buildlog_ubuntu-trusty-armhf.juju-core_1.24.2-0ubuntu1~14.04.1~juju1_BUILDING.txt.gz
<wallyworld> ty, looking
<wallyworld> anastasiamac: standup?
<anastasiamac> wallyworld: technical issues.. omw
<marcoceppi> bdx: were you able to get the subordinate working?
#juju-dev 2015-07-10
<menn0> woot! the logging-to-mongodb feature branch has landed
<anastasiamac> menn0: wow! congrats :D well done!
<menn0> anastasiamac: cheers
<menn0> I just checked the size of the diff to master: 3,500 additions and 852 deletions
<anastasiamac> menn0: would love to know of ur experiences in terms of wirtting ci tests for it as well as user-facing documentation
<anastasiamac> menn0: when did u create the branch? (for how long have u had it running?)
<menn0> anastasiamac: there is no user facing documentation, b/c from the user's perspective nothing changes
<menn0> anastasiamac: it's just a necessary change for JES ... and it's a little less fragile than all-machines.log
<menn0> anastasiamac: not sure how old the branch is... around mid April
<wallyworld> except we can't use a text editor when mongo dies :-(
<anastasiamac> menn0: so there r no changes to configuration
<anastasiamac> me?
<menn0> wallyworld: you still have a text log file of all received logs per state server
<wallyworld> which we need to accumulate by hand and which are not interleaved
<menn0> wallyworld: that's the fallback
<wallyworld> yeah, i know, i'm just grumpy
<menn0> wallyworld: yes, if there are multiple state servers
<wallyworld> no i mean all machines log also contained logs from nodes
<wallyworld> all interleaved
<wallyworld> so you could easily see sequencing
<menn0> wallyworld: yeah I understand
<wallyworld> i often ssh into a state server and grep that file
<wallyworld> far easier than debug log
<menn0> wallyworld: well the next thing is to expand debuglog's capabilities then
<wallyworld> yeah
<wallyworld> sorry for grumping, will just make my life harder now
<wallyworld> i understand the reasons for it
<menn0> wallyworld: for example, selecting time ranges is largely implemented on the server side but needs client side support
<wallyworld> it's the lack of exploring which is the main thing
<wallyworld> easier to just flitter around in a text file
<anastasiamac> menn0: weren't u at one stage considering to make log output destination (file, db, etc) configurable?
<menn0> anastasiamac: no I don't belive so. it's hard to effectively handle logs for multiple environments in a single file.
<menn0> wallyworld, anastasiamac: with the way it's the feature is structured it wouldn't be too hard to generate a all-machines.log or even separate log files per env from the DB.
<wallyworld> yay
<menn0> wallyworld, anastasiamac: with the bonus that it doesn't involve rsyslogd
<wallyworld> even better :-D
<menn0> we'd just need a worker which tails the DB like the debuglog API does and generates the file
<menn0> all the pieces are decomposed in such a way that this wouldn't be hard at all
<wallyworld> friday labs :-)
<anastasiamac> menn0: this is great! and the feature (as well as its design) would b an awesome demo for team meeting - again tyvm for the feature :)
<menn0> anastasiamac: yep good idea
 * menn0 is having lunch so sorry for the delay
<wallyworld> waigani: hey, did you see the maas output on that bug? looks like maas is doing the right thing?
<waigani> wallyworld: ah really? hmph. well there goes my theory. At least we can test with that as mock output - try to reproduce it in a test.
<wallyworld> waigani: well, i think it is correct, only took a quick look
<wallyworld> but we have the output
<waigani> wallyworld: I'll try to take a look today, but I need to finish off this branch - I'm on leave for the next 4 days
<waigani> great that we've got the output though, should be helpful
<wallyworld> waigani: ok, see how you go, let me know where you get to
<waigani> wallyworld: will do, I'm not far off...
<waigani> wallyworld: looks like gomaasapi wan't reading the substatus. Here's a PR to fix that: https://code.launchpad.net/~waigani/gomaasapi/substatus/+merge/264371
<wallyworld> waigani: ty, looking
<waigani> wallyworld: I've also added that to the bug as a comment.
<wallyworld> waigani: so that's a fix for the test service in gomaasapi, we still need to fix juju as well right?
<waigani> wallyworld: once that gets signed off, it should just be a matter of bumping the dependancies.tsv
<waigani> wallyworld: and probably adding a test
<wallyworld> waigani: how? the pr above doesn't fix anything
<wallyworld> it fixes a test server
<waigani> wallyworld: ugh, facepalm
<waigani> wallyworld: let me go back
<wallyworld> ok
<waigani> wallyworld: right, yeah sorry so the juju side is still to come
<wallyworld> sure
<waigani> but it looks like that's the problem, as you can see from that test
<waigani> wallyworld: the one thing that makes me nervous is that we are flattening two dimensions into one
<wallyworld> let me look at the maas output
<waigani> wallyworld: as juju status doesn't have any concept of a 'substatus' so, we just need to be careful how we decide which status/substatus gets reported
<wallyworld> waigani: so the maas "deployment_status" api call returns a string doesn't it?
<wallyworld> "Failed Deployment" or "Deployed" etc
<waigani> wallyworld: yeah
<wallyworld> so we don't need to worry about interpretting status vs subststus
<wallyworld> is it only older maas deployemnts without the new api call?
<waigani> wallyworld: let me look and I'll get back to you
<wallyworld> ok
<waigani> wallyworld: just seeing how we dial up that status from the juju side
<wallyworld> juju calls deployment_status
<wallyworld> well, it does while it waits for the node to come up
<waigani> wallyworld: add this to tip of 1.24: http://pastebin.ubuntu.com/11853823/
<waigani> wallyworld: it passes
<wallyworld> looking
<waigani> wallyworld: and yeah we call deployment_status in maas/environ.go deploymentStatusCall
<waigani> wallyworld: so it's reporting the correct error
<wallyworld> waigani: i'm not sure that's all correct - that test could pass if the status stays "pending"
<wallyworld> i don't see how we're testing the maas status interpretation
<wallyworld> and adding a test against a modified test server in gomaas doesn't really prove anything
<waigani> wallyworld: right, fair point.
<waigani> wallyworld: how about I checkout 1.24.1 (same as in bug), revert changes to gomaasapi and work on improving this test?
<wallyworld> try and reproduce a test failure (write a new failing test). then fix juju so the test passes
<wallyworld> TDD and all that
<wallyworld> target the test to the specific issue
<waigani> wallyworld: actually I did run that test on the unmodifed server - and if you comment out the "substatus" line, it's fails - as expected
<wallyworld> other more general bootstrap tests could also later need changing, but there should be a targetted, specific test done first
<wallyworld> yes, but that's because the test is relying on the behaviour of hte test server
<wallyworld> and the test server reports "Deployed" - status 6
<wallyworld> in the absense of sub status 11
<waigani> wallyworld: I can't get it to fail, I've written a summary on the bug. I've asked to look at the logs.
<wallyworld> did you test with real maas?
<wallyworld> or vmaas
<waigani> wallyworld: I was just about to say, that's the next step
<wallyworld> it won't fail if you just test with the gomaas test server
<wallyworld> unless the test server mimics the maas output
<wallyworld> which it doesn't appear to
<waigani> wallyworld: yeah, that's what I did - as explained in the bug
<wallyworld> ok, i'll read the bug :-)
<wallyworld> waigani: thanks for looking into it, enjoy the time off. i'll see what we can make of it
<waigani> wallyworld: thanks. I'm keen to know the cause.
<wallyworld> i'll update the bug
<wallyworld> when we find it
<waigani> ah I was just about to
<waigani> wallyworld: updated
<wallyworld> waigani: it could be that an old api call to get status is being made, and hence sub status is ignored - that would be my guess
<wallyworld> anyways, we'll see
<TheMue> fwereade: interested in a quick chat ;) we're alone today
<perrito666> fwereade: hi, please dont forget my branch if you have the chance
<fwereade> perrito666, sorry, the diff looks mangled? would you update and try again please?
<perrito666> fwereade: sure
<perrito666> mm, says rbt it cannot reach reviewboard, odd
<perrito666> fwereade: sorry rbt is playing dumb with me
<TheMue> voidspace: heya Michael, everything alright with your car?
<sinzui> katco: perrito666 : there is a new reression in master, bug 1473461 Maybe we want to backout a branch becaue the fix is to write a darwin-specific ./cmd/jujud/util/password/password_darwin.go
<mup> Bug #1473461: OSX/darwin builds fail: undefined: password.EnsureJujudPassword <ci> <osx> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1473461>
<mup> Bug #1473450 opened: upgrade-juju from 1.18 to 1.20.4 leaves some agents down <juju-core:New> <https://launchpad.net/bugs/1473450>
<mup> Bug #1473461 opened: OSX/darwin builds fail: undefined: password.EnsureJujudPassword <ci> <osx> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1473461>
<ericsnow> TheMue: was my review of http://reviews.vapour.ws/r/2129/ helpful?
<TheMue> ericsnow: very, thanks. I'm working on it.
<ericsnow> TheMue: cool :)
<perrito666> bogdanteleaga: that password thing is yours :)
<ericsnow> TheMue: I'll try and give you a quick turnaround as soon as you have any comments or updates to the patch
<TheMue> ericsnow: there has been a longer discussion about the EntityWatcher before. the first Addresser approach used the IP address values. but then Dimiter said it would make sense to use common.LifeGetter and common.Remover.
<mup> Bug #1473466 opened: When using openstack as provider lxc containers get a hardcoded ip <sts> <juju-core:New> <https://launchpad.net/bugs/1473466>
<TheMue> ericsnow: so we needed tags for ip addresses, an earlier chnage.
<TheMue> ericsnow: and this code is mostly based on http://paste.ubuntu.com/11803914/
<ericsnow> TheMue: ah
<TheMue> ericsnow: should have written more into the description *lol*
<ericsnow> TheMue: it just struck me as odd that the EntityWatcher was part of this patch :)
<ericsnow> TheMue: yeah, how terrible of you <wink>
<TheMue> ericsnow: it rushed in as a side-effect. would have been worth an extra change, yes
<TheMue> hehe
<ericsnow> TheMue: not really a blocker, but putting multiple effectively distinct changes in a single patch can be a problem every long once in a while (in this case not a big deal)
<TheMue> ericsnow: what? you need more than one commit to implement <insert favourite complex feature here>? :D
<ericsnow> TheMue: well, not me personally ;)  just this guy I know (okay it's me)
<TheMue> :,)
<mup> Bug #1473470 opened: Windows cannot ensurePassword <ci> <regression> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1473470>
<alexisb> hello akhavr welcome!
<akhavr> alexisb: :)
<perrito666> ashipika: around?
<ashipika> perrito666: here
<perrito666> just something I found and might bite you in the future
<ashipika> perrito666: do tell, please
<perrito666> ashipika: priv
<perrito666> sinzui: around?
<sinzui> perrito666: I am
<perrito666> sinzui: I am trying to use boot_context in my CI test
<perrito666> i feel a bit of a lack of clarity regarding what should the arguments be
<sinzui> perrito666 in deploy_stack.py deploy_job() -> deploy_job_parse_args(), _deploy_job() -> boot_context()
<sinzui> perrito666: the parse args will have descriptions
<perrito666> ah, excelent, thank you
<sinzui> perrito666: I think we want to add a ricj docstring to boot_context() to encourage it's use
<sinzui> perrito666: I will take a stab at the docstring in a few minutes, and pass it for review for you and maybe abentley
<mup> Bug #1473517 opened: juju environment not usable after the upgrade <juju-core:New> <https://launchpad.net/bugs/1473517>
<perrito666> sinzui:  back, sorry, 2 things, 1) what is bootstrap_host supposed to be and 2) job name can be set to something arbitrary or do I need to add it as an arg?
<sinzui> job_name is arbitrary yes, but it is alos unique so that the script and base env can be run in parallel
<perrito666> and bootstrap_host?
<sinzui> perrito666: bootstrap_host is not required. it is a placement directive for bootstraping manual or maas
<perrito666> None will suffice or you are expecting it to be a given type?
<sinzui> perrito666: yep
<perrito666> ok this function is too long
<perrito666> sinzui: ok, almost there:  agent_url and agent_stream?
<sinzui> perrito666: agent_stream == agent-stream in config. None means don't override
<sinzui> perrito666: agent_url == agent-metadata-url in config. None means don't override
<sinzui> perrito666: We use these often and will be required to run revision tests in parallel when we need concurent streams
<sinzui> well we do, which is why the configs force the testing streams
<perrito666> sinzui: so you are saying I should make these args
<sinzui> perrito666: all of those things need to be args becauee we may need to run the test with manual and we certainly will be running with streams created for the test
<perrito666> sinzui: I find then odd that those are not part of add_basic_testing_arguments
<mbruzek> sinzui: Do you know if anyone has an RPM to install juju client?
<sinzui> perrito666: the only arg from that may be dropped from (job_name, client, bootstrap_host, machines, series, agent_url, agent_stream, log_dir, keep_env, upload_tools) is upload_tools because we discovered this week that we cannot fallback to upload-tools with the new os and arch requirements
<sinzui> mbruzek: I have not seen one. mbruzek Since client relies on ubuntu-ness I doubt anyone succeeded
<perrito666> sinzui: ack
<sinzui> mbruzek: the centos client will work for centos https://launchpad.net/juju-core/+milestone/1.24.2
<sinzui> mbruzek: only centos7 actually. I thnk an error is quickly raise of the host os/series is not recognised
<mbruzek> sinzui: Marco and I just tried to alien the debian packages, it didn't work... yet
<sinzui> mbruzek: I am sure the deps wont work becaue mongo is not packaged to meet Juju's needs
<mbruzek> OK Thanks sinzui
<abentley> sinzui or jog: Could you please review https://code.launchpad.net/~abentley/juju-ci-tools/s3-download/+merge/264450 ?
<sinzui> abentley: looking
<abentley> sinzui: thanks.
<abentley> sinzui, perrito666: I think that --upload-tools is nice to have for devs who are testing their self-built jujus.
<sinzui> abentley: I can and maybe should install s3cmd on all slaves
<sinzui> abentley: My one mac has it
<abentley> sinzui: Oh.  Well, if we do that, we can rip out s3 support for the workspace runner.
<sinzui> abentley: then I wont because I like what you have written
<abentley> sinzui: I do like the idea of isolating the resource retrival/publication from the testing step.
<sinzui> yeah, this is awkwardly coupled. Isn't this because we haven't updated the build job to also upload to s3 yet?
<abentley> sinzui: It's because we haven't done download support for workspace-runner.
<abentley> sinzui: We can scp files, which is useful, but the remote client can't download files from s3.
<sinzui> abentley: This command now works on the osx-slave
<sinzui> s3cmd -c cloud-city/juju-qa.s3cfg ls s3://juju-qa-data/
<abentley> sinzui: Okay, I can switch it over to use s3cmd.
<sinzui> abentley: I can add s3cmd to windows, but I don't want to give it credentials. I think I put myself in a corner
<abentley> sinzui: If the plan is to ultimately have our windows jobs uploading everything directly to s3, that would be a problem.
<abentley> sinzui: Obviously, we can have separate win credentials.
<sinzui> abentley: The win-client-deploy job need the installer built by build-win-client.The current rule is the ci job procurs the installer under test and delivers it to the win machine.
<abentley> sinzui: Right.  Basically the same pattern I was following with run-osx-client.
<sinzui> yes. In egnlish, test this <client> using with <script>
<abentley> sinzui: But then at the end, ci-director uploads the console log to s3.
<sinzui> yes, and that is also true for windows.
<abentley> sinzui: I'm imagining that eventually, we'll want workspace-runner to be able to do that.
<sinzui> r=me abentley
<abentley> sinzui: I have updated the code so that s3cmd is run remotely.  Do you want that version instead?
<sinzui> abentley: I got scared.
<sinzui> abentley: I trust the osx machine but not the win machines. I think it is easier to maintain the idea that testing host cannot retrieve the things under test
<abentley> sinzui: Okay.
<mbruzek> sinzui: Those Juju binary files in the tar.gz worked on CentOS7.  Thank you!
<mbruzek> marcoceppi: ^
<sinzui> mbruzek: I should hope so, we officially distribute them
<mbruzek> sinzui: Is there a test process for installing Juju on CentOS7 ?
<mbruzek> to verify they work?
<sinzui> mbruzek: no. We are still tinkering with  what we recommend
<sinzui> mbruzek: I verified them using a centos machine I provisiioned in aws. I could boostrap an aws env
<mbruzek> sinzui: thanks.  I did not think they would not work, I was just letting you know I was able to get them to work.  Thanks.
<sinzui> mbruzek: this will be tested automatiically later this month.
 * mbruzek regrets the double negative
<mbruzek> sinzui: Do you know any work to get the tools build for centos7?  We could not deploy a centos7 charm because there were no tools
<sinzui> mbruzek: you don't need to build them, they are officially published. The problem is that no one created a way to manually provision or bootstrap them. mgz and and I are still playing with a non-maas way to provision an aws machine with cloud-init
<sinzui> mbruzek: https://streams.canonical.com/juju/tools/streams/v1/com.ubuntu.juju:released:tools.sjson lists the 1.24.0 and 1.24.2 agents
<sinzui> mbruzek: This is the most recent centos7 agent https://streams.canonical.com/juju/tools/releases/juju-1.24.0-centos7-amd64.tgz
<mbruzek> sinzui: marcoceppi downloaded a centos7 image from AWS that appeared to include cloud-init  https://aws.amazon.com/marketplace/pp/B00O7WM7QW/ref=srh_res_product_title?ie=UTF8&sr=0-2&qid=1436560475610
<mbruzek> Starting with CentOS-7 we now include cloud-init support in all CentOS AMI's,
<sinzui> mbruzek: yep that is what mgz and I plan to use
<sinzui> that is also the machine I tested the client with
<mbruzek> if I downloaded those tools could I use the --upload-tools flag in Juju?
<sinzui> mbruzek: no you cannot. that simple and practical feature was not built first :(
<sinzui> mbruzek: I think upload-tools or manual provisioning is the most sensible first level support, instread we got maas. The official way to write charm for centos is to get a maas with handmade centos images first :(
<mbruzek> sinzui: OK well if you and mgz are working on this I would be interested in helping getting amazon working.
<sinzui> mbruzek: we will give you an update next week.
<mbruzek> sinzui: I spoke with a potential customer they like Ubuntu but have some CentOS that they can not work around and specifically asked if Juju would work with CentOS
<mbruzek> sinzui: thanks for answering my questions
<sinzui> mbruzek: maybe by 1.25. 1.24 is for cloud engineers who are willing cheat every step to make something work
<mbruzek> sinzui: understood.  Consider me interested and I understand we actually want them using Ubuntu.  I would just like to demo CentOS without having to install maas
<sinzui> mbruzek: me too. My last thought was to bootstrap an ubuntu env, bring up a centos machine, run a prep script to satisfy add-machine, then juju add-machine to let juju really add it. The prep script would provide fake commands or alternates to for the cloud-init to work. For example. Create the ubuntu user. create an lsb_release script that returns centos7
<perrito666> can I mark comments as addressed someway in launchpad?
<sinzui> perrito666: no, just comment that you are done
<abentley> sinzui: I've successfully built osx client into (test) s3: https://console.aws.amazon.com/s3/home?region=us-east-1#&bucket=ws-runner-test&prefix=juju-ci/products/version-2873/build-osx-client%20%20/build-17/foo/
<sinzui> abentley: \o/
<xwwt> abently: good news
<xwwt> abentley: good news
<perrito666> the fact that save produces something called "unsaved comment" in launchpad is a tad confusing
#juju-dev 2016-07-11
<axw>  mgz: are you about? CI won't merge my critical fix, looks like because we have turned on Windows unit test gating but still have a bunch of failing Windows unit tests ...
<axw> wallyworld: ^^ I'd rather not spend all my time fixing Windows unit tests right at this point in time
<wallyworld> axw: agreed, i'm not sure why gating was turned on before tests passed
<wallyworld> we may have to skip them depending on how many there are
<wallyworld> axw: did i recall perhaps incorrectly that bug 1598049 had been sorted out in some form?
<axw> wallyworld: I *think* that's sorted out by perrito666's patch, which I merged into my branch and landed
<axw> but I don't have windows handy to verify
<wallyworld> axw: yeah, that rings a bell, that's what i thought had happened
<wallyworld> i might mark as fix committed
<wallyworld> axw: this updates the juju/rfc repo with the changes to remove the custom tls package https://github.com/juju/rfc/pull/1
<axw> wallyworld: you just did a straight copy of changes from juju/juju/standards right?
<axw> apart from txt file of course
<wallyworld> axw: yep, and i could only see that one change
<wallyworld> client.go plus deletes
<axw> wallyworld: cool. LGTM, thanks
<wallyworld> ta
<axw> wallyworld: I'd like to move that rfc5424 package to live under juju/syslog at some point
<axw> lumping all standards together is a bit odd, since there's many standards for wildly different things
<wallyworld> yeah, could do. although i thik the intent was to gather all rfc things there
<axw> wallyworld: I know that was the intent, it just seems very strange to me. maybe just me...
<wallyworld> can easily be done, let's discuss with tech board or whatever
<axw> sure, no rush anyway
<wallyworld> axw: and here's the juju/juju change http://reviews.vapour.ws/r/5218/ (not that it can land, sigh)
<axw> wallyworld: LGTM
<wallyworld> ta
<veebers> Hi axw, you have a moment to help me out. I'm attempting to generate some certs that I can use with the log forwarding feature and a rsyslog sink (this is for testing the feature)
<veebers> axw I can't seem to generate a cert that juju is happy with, it complains about there not being any IP SANs, I'm sure I'm generating the certs correctly
<axw> veebers: what are you using for "syslog-host" config?
<veebers> axw syslog-host: 10.194.140.165:10514
<veebers> axw I'm using certtool to gen the certs (creating a ca cert and some client/server certs too)
<axw> veebers: try using the hostname that you used when generating the cert
<axw> rather than IP
<veebers> axw: I don't have any dns setup for this as I've just bootstrapped and deployed rsyslog, added certs and config then exposed it for the rsyslog sink. Are you suggesting that I need dns settings for that machine for this to work?
<axw> veebers: either you need DNS, or when you generate the cert you need to include an IP SAN
<veebers> axw: the IP SAN is that for both the ca cert and the client/server cert or just one of them? I'm pretty sure I'm setting that for the ca cert
<axw> veebers: for the server cert at least, not sure how client cert verification works
<veebers> axw: hmm so what I'm doing at the moment is creating a ca cert, then I'm creating a cert that I sign with the ca cert and using that on the rsyslog server as well as the juju config. For the server should I create a cert and use that + ca cert and then a different cert for the client?
<axw> veebers: for a more realistic setup, yes. I'd stick with the one cert to start with until you get that working, and expand, though.
<veebers> Probably worth mentioning; the certs that I'm generating work fine when using just rsyslog (i.e. 2 machines one sending to the other)
<axw> veebers: interesting. that would seem to imply they're not doing strict host verification
<veebers> axw: ok, right now I'll try adding the ip address to the client cert (as opposed to the ca cert) too and see if I get any joy
<veebers> axw: that thought did cross my mind, could be the way I have it configured
<veebers> i.e. Using the config from the top answer here: http://serverfault.com/questions/666827/using-rsyslog-with-tls-without-generating-a-self-signed-cert
<veebers> axw: huh, I think that's working now. Is there an action I can do that would create a log that would be forwarded?
<axw> veebers: anything and everything that goes over the API
<axw> veebers: you shouldn't need to do anything really, logs just happen
<veebers> axw: I'm wanting something reproduce-able so I can check that it works now as well as incorporate it into the ci test :-)
<veebers> I saw a large influx of messages just at the end of the bootstrap but nothing since, want to force some message so I can confirm all is wired up correctly
<axw> veebers: fair enough. umm. I'm not sure what's a good candidate for a useful log message. you can just do "juju status", and you should expect to see an apiserver log message
<axw> that should have the word "FullStatus" in it
<veebers> axw: Hmm, 'juju status' doesn't change anything in either the rsyslog sync or the logs in /var/log/juju/machine-0.log (on the newly bootstrapped machine) although there seems to be an error in the last log: http://pastebin.ubuntu.com/19050127/
<axw> veebers: dunno what that's about. I think you won't get the log message unless you're at DEBUG level. I'll see if there are anyt interesting INFO messages
<axw> although, I think we default to WARNING?
<veebers> I'm not sure about the default logging level, I don't mind changing it for now or during the test assuming that's valid test cover
<axw> veebers: I think it's going to be necessary, at least until we change the default to INFO (which I think there was agreement upon in London)
<axw> veebers: if you're at INFO level, you should see "API connection from <IP>" whenever a client connects
<axw> veebers: so you could just run "juju status" and look for that
<veebers> axw: sweet, so changing log level is as easy as: juju set-model-config logging-config="<root>=INFO" -m controller ?
<axw> veebers: yup
<veebers> sweet cheers
<veebers> axw: wow ok, so doing that and then a status floods the log with: http://pastebin.ubuntu.com/19050776/
<veebers> over and over again
<veebers> I just killed the controller as it was pegging my system (jujud)
<axw> veebers: huh :/
<axw> wallyworld: ^^ there's probably a log forwarding loop
<wallyworld> awesome
<wallyworld> hmmm, i think i saw a bug last week with that outout
<wallyworld> veebers:  axw: this seems to be the same thing https://bugs.launchpad.net/juju-core/+bug/1599779
<mup> Bug #1599779: Very high CPU usage from 'creating cloud image metadata storage'  emitted in debug log every second <juju-core:New> <https://launchpad.net/bugs/1599779>
<wallyworld> not sure that it's log forward related
<axw> ah yes, I think this is the same issue that jam mentioned to me during the sprint - because of how we're using "ForModel" internally in state
<veebers> wallyworld: that looks like what I saw, but seems it was more than once a second. /var/log/syslog on the controller was flooded
<wallyworld> hmmm, maybe the log forward worker is not marking logs as sent, so it just keeps sending the same thing, not sure
<veebers> axw, thanks for you help. At any rate I was able to get something working. I'll look at using dns in the certs and how we might do that under a test environment
<axw> veebers: no worries
<mup> Bug #1600722 opened: MachineSuite.TestHostedModelWorkers is unreliable <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1600722>
<voidspace> frobware: babbageclunk: be at standup in 5 minutes or so
<frobware> dooferlad: standup today?
<axw> wallyworld: first of many: http://reviews.vapour.ws/r/5219/
<wallyworld> ok
<wallyworld> axw: fyi i've removed the controller model check - just get the controller uuid directly now, still getting tests to pass in my branch
<axw> wallyworld: great, thanks
<wallyworld> axw: lgtm, hopefully we can land stuff soon
<axw> wallyworld: ta. I've got another one coming with changes how we pass timeouts to MAAS and the bootstrap-state jujud code
<wallyworld> ok, may be afk for a fried time
<wallyworld> brief
<wallyworld> lol
<urulama> axw, wallyworld: is this a fix for access key issue?
<axw> urulama: authorized-keys issue?
<urulama> axw, wallyworld: and good evening :)
<urulama> axw: yes, sorry
<wallyworld> urulama: yeah
<wallyworld> but the landing bot is preventing landings as it wants all windows tests to pass
<urulama> geat :-/
<frobware> voidspace: want to do 1:1?
<urulama> mgz: you around? can you revert the changes for windows tests so that beta12 actually becomes useful (like be able to deploy an application)
<urulama> wallyworld, axw: do you know what the status of this one is? https://bugs.launchpad.net/juju-core/+bug/1593828
<mup> Bug #1593828: cannot assign unit E11000 duplicate key error collection: juju.txns.stash <ci> <conjure> <deploy> <intermittent-failure> <oil> <juju-core:In Progress by 2-xtian> <https://launchpad.net/bugs/1593828>
<axw> urulama: no clue, sorry
<voidspace> frobware: sorry, my wife got back from dropping off her dad at the airport and I went to talk to her
<voidspace> frobware: sure, can do 1:1
<frobware> voidspace: in the ho
<babbageclunk> urulama: I'm working on it - it's a bug in mgo. There's a PR to fix it, I've had it reviewed and am waiting to get it merged.
<babbageclunk> urulama: once it's merged into the v2 branch I can start updating the mgo version in the various dependencies.tsv files.
<urulama> babbageclunk: thanks ... any estimation when it might land? it's annoyingly consistent when trying to stress test the controller how many machines and units it can handle :)
<urulama> (annoyingly consistent at failing that is)
<babbageclunk> urulama: Hopefully merged into mgo today (depending on reviewer time) - then there are 11 packages to get updated, so that might not get into juju/juju (at the end of the dependency chain) until tomorrow sometime.
<babbageclunk> urulama: Are you using beta packages or source? It should be in the beta getting cut this week.
<urulama> babbageclunk: cool, thanks. also, it looks like tests are failing, which might be an issue to land it as well :) https://github.com/go-mgo/mgo/pull/291
<babbageclunk> urulama: Yeah - that's an occasional failure in the mgo test suite. :(
<urulama> babbageclunk: using source, will have an eye on when this lands
<babbageclunk> urulama: not anything to do with my change but I'm going to try to sort it out, it's bitten me twice now.
<babbageclunk> urulama: ok - I'll put an update on the bug now and keep you updated when there's movement
<jamespage> frobware, one for your list - https://bugs.launchpad.net/juju-core/+bug/1600546
<mup> Bug #1600546: lxd subnet setup by juju will interfere with openstack instance traffic <sts> <juju-core:New> <nova-compute (Juju Charms Collection):New> <https://launchpad.net/bugs/1600546>
<frobware> jamespage: ack & thanks
<jamespage> well lathiat can take the credit for finding that one :-)
<babbageclunk> Ugh, I just realised I'll need to do a topological sort of the transitive closure of packages that depend on mgo.
<urulama> babbageclunk: thanks (and auch, on the last one)
<babbageclunk> urulama: :)
<mgz> urulama: sorry, which tests?
<mgz> oh, it's the whole do we want gating or not thing
<urulama> yes
<mgz> well, there's a reason I pushed back on adding gating here, but... we *were* asked to
<urulama> ok
<mgz> urulama: there's actually a fun bug that circumvents the gate
<urulama> lol
<mgz> urulama: but I will disable the windows part if we have general agreement
<urulama> i mean, critical bug fixes can't land
<urulama> we can wait for Torsten to be up in 2h ...
<mgz> urulama: more a question for cherylj/alexisb
<mgz> but you+ian will do
<mgz> test regressions generally are critical bugs
<urulama> agree
<mgz> urulama: anyway, I'll fix the bug in the script and remove windows from the list of jobs for now
<urulama> mgz: ok, thanks
<mgz> urulama: done
<urulama> ty ... now i hope Andrew's branches land soon :)
<mgz> you can retrigger if it's approved
<mgz> I doubt he'd mind
<urulama> mgz: done, let's see if tests pass now :)
<babbageclunk> jam: gah, so there are a couple of cycles in the dependencies: juju-romulus and charmstore-charmrepo. How do you think I should handle those?
<dooferlad> macgreagoir: standup?
<urulama> rogpeppe, ashipika: ^ see comment from babbageclunk
<mgz> babbageclunk: kill romulus
<urulama> LOL
<babbageclunk> mgz: very classical
<ashipika> mgz:  et tu?
<ashipika> urulama, mgz, babbageclunk: the proposed solution was to integrate romulus into juju core.. which is on our todo list..
<mgz> kill, integrate, much the same
<ashipika> mgz: there's a certain Julius C. that would disagree :D
<ashipika> we're one sprint in Rome short of a Remus.. then we'd have a classical duel on our hands :)
<urulama> mgz: thanks, https://github.com/juju/juju/pull/5772 landed
<mgz> urulama: ace
<babbageclunk> ashipika: Ok, that's the long-term solution, but how should I update mgo in the meantime? (Trying to think it through but it's making my head hurt.)
<ashipika> babbageclunk: update the juju-core dependency first, merge, update the romulus dependency second (it depends on the core), merge.. i guess
<babbageclunk> ashipika: And it doesn't matter that the dependencies will conflict?
<babbageclunk> ashipika: does godeps handle that already?
<ashipika> babbageclunk: hmmm.. i think it should all work out.. i hope..
<babbageclunk> ashipika: I guess I can just try it! Thx
<ashipika> babbageclunk: good luck.. ping me if it doesn't work
<babbageclunk> ashipika: It should be ok, since the bugfix doesn't change any interfaces.
<babbageclunk> ashipika: thanks, will do!
<urulama> mgz: hm, so how come that branch from Andrew got merged, but then CI stated it's bad (at juju.fail) and then if you try it, it works? (/me just tries to understand what failed and why :D)
<mgz> urulama: hm, I guess I screwed something up
<mgz> oh, there's a trailing backslash all the way over there >_<
<urulama> babbageclunk: does this mean that you already have your fix landed in mgo?
<mgz> welp. fixed, good thing the branch had in fact already passed.
<rogpeppe> babbageclunk: what specific problem are you having?
<babbageclunk> urulama: No, just getting ready for the next bit.
<babbageclunk> rogpeppe: nothing yet - just trying to decide what order to update the dependencies when it's time to.
<rogpeppe> babbageclunk: note that the cyclic dependencies from charmstore<->charmrepo are only because charmrepo uses charmstore for its tests
<babbageclunk> rogpeppe: ah, ok - that is a lot less worrying.
<rogpeppe> babbageclunk: FWIW i think it's a mistake that it should do so and i think i've worked out what the right answer is, but it'll be a while before we get around to fixing that
<babbageclunk> rogpeppe: but if the tests pass then it should be ok, anyway.
<rogpeppe> babbageclunk: yup
<babbageclunk> rogpeppe: Thinking it through a bit more I was worrying too much - it's not like there'll be two versions of the code in memory, it just determines which version godeps checks out. Right?
<rogpeppe> babbageclunk: right
<rogpeppe> babbageclunk: you'll need to choose one version for all deps
<rogpeppe> babbageclunk: i usually use the newest version of all deps if in doubt
<babbageclunk> rogpeppe: yeah, that makes sense
<rogpeppe> babbageclunk: the -N flag to godeps can be useful too
<rogpeppe> babbageclunk: for coming up with a coherent "latest tested" set of deps from several projects' dependencies.tsv files
<babbageclunk> rogpeppe: ok, will use that. Thanks!
<jam> babbageclunk: I would think that neither romulus or charmrepo expose mgo as part of their interface.
<jam> as long as they aren't returning an mgo.Doc or something like that, we should be ok
<jam> (mgo.D/B)
<jam> babbageclunk: I'm in favor of updating deps, I'd just mention that if we aren't on the latest *today*, there there is probably a reason, and I don't want to dump all of that on you.
<jam> babbageclunk: they need your mgo fix more than they need newest of all other deps
<junaidali> Hi everyone, what is the equivalent command for $ juju set-constraints tags=controller     in Juju2.0
<frobware> junaidali: set-model-constraints (http://pastebin.ubuntu.com/19079305/)
<junaidali> thanks frobware
<babbageclunk> jam: good point, I'll make sure that I'm only updating deps (other than mgo) when they're on the latest.
<mup> Bug #1600600 changed: Docs are incorrect for Azure bootstrap <juju-core:Invalid> <https://launchpad.net/bugs/1600600>
<voidspace> babbageclunk: frobware: dooferlad: firefox crash! omw
<mup> Bug #1600600 opened: Docs are incorrect for Azure bootstrap <juju-core:Invalid> <https://launchpad.net/bugs/1600600>
<voidspace> frobware: are you going to mid-cycle?
<frobware> voidspace: nope
<mup> Bug #1600600 changed: Docs are incorrect for Azure bootstrap <juju-core:Invalid> <https://launchpad.net/bugs/1600600>
<voidspace> frobware: do you know anyone from the UK who is?
<frobware> voidspace: and from juju core?
<voidspace> frobware: I left my boots behind in the US - so if I can get them shipped to someone in the US going to the mid-cycle and get someone from the UK to bring them back
<voidspace> frobware: then it will be cheaper than getting them shipped to the UK
<voidspace> frobware: anyone from the UK willing to do me a favour... :-)
<voidspace> frobware: but I have no idea who's going
<mup> Bug #1600600 opened: Docs are incorrect for Azure bootstrap <juju-core:Incomplete> <https://launchpad.net/bugs/1600600>
<mup> Bug #1600600 changed: Docs are incorrect for Azure bootstrap <juju-core:Incomplete> <https://launchpad.net/bugs/1600600>
<mup> Bug #1600600 opened: Docs are incorrect for Azure bootstrap <juju-core:Incomplete> <https://launchpad.net/bugs/1600600>
<mgz> anyone got something they want to land and doesn't mind being a guinea pig?
<voidspace> dooferlad: ping
<mbruzek> mgz: or balloons: did you come up with another solution for the bash completion problem?
<mbruzek> mgz: or balloons: I had the wrong target on Friday, it is cleaned up to this: https://bugs.launchpad.net/juju-core/+bug/1600257 but balloons mentioned there might be a "better" way to solve that problem.
<mup> Bug #1600257: The tab completion on juju yields KeyError: 'services' <bash-completion> <packaging> <juju-core:New> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1600257>
<mgz> mbruzek: I do wonder if we want a wrapper script like juju-version rather than a symlink, I'm not sure how nicely the bash completion mechanism plays with that
<mgz> does it avoid registering completions twice if the same script is executed twice under different names?
<mbruzek>  mgz: OK but I believe the issue was how to not collide with juju1 bash completion
<mgz> is there a better way of auto-loading for aliases?
<mgz> mbruzek: that is an issue, but we also need to update the juju 1.25 packaging, and own both parts
<mbruzek> mgz in my testing the symbolic link worked and I was not getting double completions, but I will admit my testing was incomplete
<mgz> mbruzek: so, that's the jist of my code review questions
<mbruzek> mgz: OK I will read up on bash completion aliases and see what I can find. If you or balloons have a different solution please let me know to stand down
<alexisb> do we have anyone still online on the networking side
<alexisb> frobware, voidspace possible??
<frobware> alexisb: if we're quick...
<alexisb> frobware, was just recreating this bug: https://bugs.launchpad.net/juju-core/+bug/1516150
<mup> Bug #1516150: LXC containers getting HA VIP addresses after reboot <canonical-bootstack> <juju-reboot> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1516150>
<alexisb> and when looking at the code paths for filtering ip address I found this fucntion:
<alexisb> filterLXCAddresses
<alexisb> in : juju/juju/network/network.go
<alexisb> which seems rather useless given /etc/default/lxc-net doesnt exits anymore, right??
<alexisb> frobware, this is not urgent I am just curious
<alexisb> if I should open a bug
<frobware> alexisb: jam recently landed a change for filtering lxd bridge addresses
<alexisb> ah, ok I iwll look at those
<alexisb> thanks
<frobware> alexisb: http://reviews.vapour.ws/r/4478/
<frobware> alexisb: if there's nothing else then it's EOD for me. I only popped in to turn off some of my machines...
<alexisb> frobware, nope, I will catch you tomorrow, thanks!
<alexisb> sorry for the intrusion
<frobware> np
<mup> Bug #1602010 opened: juju status doens't display proper error when machine fails <juju-core:New> <https://launchpad.net/bugs/1602010>
<jcastro> does anyone know how I can set this? https://github.com/juju/juju/search?utf8=%E2%9C%93&q=test-mode%3A+true
<jcastro> I need to be able to set that variable in 2.x
<jcastro> but since I don't have an environments.yaml to put it in ...
<jcastro> test-mode:true is what I am trying to set
<mup> Bug #1602032 opened: Add machine and core count to 'models' output <juju-core:New> <https://launchpad.net/bugs/1602032>
<mgz> wallyworld: can you explain your change for bug 1599905 to me?
<mup> Bug #1599905: rfc5424 standard has a non-free license <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1599905>
<axw> wallyworld: http://reviews.vapour.ws/r/5221/
<mup> Bug #1602034 opened: 'ERROR connecting with bootstrap config' for status on destroyed model <juju-core:New> <https://launchpad.net/bugs/1602034>
#juju-dev 2016-07-12
<katco> axw: hey thanks for the review; i responded
<mgz> wallyworld: nvm by the way, saw after you'd put up a pr against the split out repo that removed the rfc text as well as other things
<wallyworld> mgz: yeah, sorry, the pr did a couple of things, including removing the bad file
<axw> katco: thanks/sorry for misunderstanding
<mup> Bug #1602053 opened: juju deployed lxd containers are missing a default gateway when configured with multiple interfaces <juju-core:New> <https://launchpad.net/bugs/1602053>
<mup> Bug #1602054 opened: juju deployed lxd containers are missing a default gateway when configured with multiple interfaces <juju-core:New> <https://launchpad.net/bugs/1602054>
<mup> Bug #1602053 changed: juju deployed lxd containers are missing a default gateway when configured with multiple interfaces <juju-core:New> <https://launchpad.net/bugs/1602053>
<axw> wallyworld: are you busy? could you please take a look at http://reviews.vapour.ws/r/5221/?
<wallyworld> sure, give me a few minutes
<axw> np
<mup> Bug #1602067 opened: [2.0b11] Repeated "log-forwarder" errors in debug-log with Azure provider <juju-core:New> <https://launchpad.net/bugs/1602067>
<axw> wallyworld: PTAL
<wallyworld> ok
<wallyworld> axw: tv, lgtm
<wallyworld> ty
<axw> wallyworld: thanks
<axw> wallyworld: I'll do a bootstrap && deploy just to be paranoid...
<wallyworld> sgtm
<veebers> axw: Hi, seems I can reproduce https://bugs.launchpad.net/juju-core/+bug/1599779 everytime using log-forwarder and setting debug level to INFO (as per convo from yesterdas). It useful for you if I file a new bug or just comment on that existing one?
<mup> Bug #1599779: Very high CPU usage from 'creating cloud image metadata storage'  emitted in debug log every second <juju-core:New> <https://launchpad.net/bugs/1599779>
<axw> wallyworld: ^^ are you looking at this?
<wallyworld> axw: not yet, hacking around in unit tests, will have a look next
<axw> veebers: I *think* we need a separate one, really depends on the root cause. I guess a separate one until we analyse it, and then we may mark as dup
<axw> veebers: there's an issue to do with how we start/stop workers in juju which is (I think) the cause of the linked bug, but I think there's more to the log-forwarding issue
<veebers> axw: ack, I'll file a bug for it, it can always be marked as dupe or whatever if needed.
<axw> veebers: thanks
<veebers> nw
<mup> Bug #1602084 opened: log-forwarding with level set to INFO starts endless logging loop. <juju-core:New> <https://launchpad.net/bugs/1602084>
<mup> Bug #1602084 changed: log-forwarding with level set to INFO starts endless logging loop. <juju-core:New> <https://launchpad.net/bugs/1602084>
<mup> Bug #1602084 opened: log-forwarding with level set to INFO starts endless logging loop. <juju-core:New> <https://launchpad.net/bugs/1602084>
<mup> Bug #1580497 changed: juju2 on maas permanent " connection is shut down" msg and loss of connection <cpe-sa> <orangebox> <juju-core:Expired> <https://launchpad.net/bugs/1580497>
<wallyworld> axw: when you get a chance, here's some logfwd fixes http://reviews.vapour.ws/r/5223/
<wallyworld> veebers: are you able to share your notes on how to manually set up a test environment for the log forward - ie what charm you used, the steps to generate certs, the charm set up etc?
<veebers> wallyworld: I'm in the process of writing a ci test for it (which would be easy to reproduce it), but I can also share the steps that I took to manually setup and test it
<veebers> wallyworld: I'm just about to EOD though and head off to a conference meeting. I could throw something together for you after that but not sure when that would be for you
<wallyworld> veebers: tis good, i'll see what i can get done and we can sync up tomorrow if needed
<wallyworld> veebers: i will hopefully have landed by then code to allow the log fwd to be toggled on/off via a syslog-enabled config flag
<veebers> wallyworld: nice! :-)
<wallyworld> so you have have it set up and turn on / off as needed
<wallyworld> of start without and set the config later
<wallyworld> or
<veebers> sweet, I'll ensure to have a test do both (at bootstrap and later on)
<wallyworld> awesome, ty
<wallyworld> i'll look at this cpu issue
<veebers> wallyworld: if it'll help I can provide rough and ready details now and refine later on? (i.e. I have a script that generates a cert + key given an IP address for the server + the config used on the rysync sink side)
<wallyworld> veebers: great ok, if it's easy to send through, otherwise i'll hack something up
<axw> wallyworld: looking
<veebers> wallyworld: heh, it's not pretty but it's the steps I used to bootstrap my testing env: https://pastebin.canonical.com/160714/
<wallyworld> ty
<veebers> wallyworld: oh, I may not have mentioned that once you expose the rsyslog chamr, the public ip address there needs to be plugged into the cert generator script as that needs to be embedded into the client cert. There is a comment in the script where that happens (like I said, rough and ready)
<wallyworld> veebers: no problem, the SAN list is a pita for sure
<veebers> I have the command line details if you want to generate certs that way too. I know now a lot more about create certs then I did a couple of days ago
<lazyPower> wallyworld - bruzer and i hacked on the tls layer quite a bit this cycle. we're backending with EasyRSA but lib/tls.py has some helpers you may be able to pull out for helping with SANS generation/listing/manipulation
<lazyPower> hah just kidding, i mean we put it in the reactive bits - https://github.com/juju-solutions/layer-tls/blob/master/reactive/tls.py#L291
<wallyworld> lazyPower: thanks! will take a look if needed. i hacked up a cert last week and did the SAN dance by hand. at this stage, i just need the one set of certs
<lazyPower> ack, just trying to help if there's anywhere we can share/collab i'm game to do so. My go-fu however, is non-existant.
<wallyworld> thak you, appreciate it
<axw> wallyworld: reviewed
<wallyworld> ta
<wallyworld> axw: i can't reproduce the CPU issue - the log forward worker uses a http endpoint to stream out the log entries so that doesn't create a loop. i quickly did an initial test by hacking the worker to write forwarded logs to a file rather than a log sink. but indications are that it's not related to any log forward issue (I did test on the latest code though that hasn't landed yet)
<axw> wallyworld: it does make API calls to update the last-sent log though doesn't it?
<wallyworld> not that i saw, but i didn't dig into that part so much
<wallyworld> i am tailing a file with forwarded data and it seems to behave as expected
<axw> wallyworld: okey dokey, I guess it's just the same issue as previously reported then
<wallyworld> axw: could be. i did also start another model and it still behaved itself
<urulama> wallyworld: model inheritance ... looks to be working. bootstrapping with test-mode config did go into all models
<urulama> not sure if that was supposed to happen or not yet :)
<wallyworld> urulama: you put that in cliuds.yaml?
<wallyworld> clouds.yaml
<wallyworld> that bit works
<wallyworld> axw: off to soccer, will push final changes when i get back, hopefully can land tonight so chris can pick up tomorrow, we'll see how i go
<axw> wallyworld: okey dokey. I have another change to push shortly also.
<axw> wallyworld: finally, http://reviews.vapour.ws/r/5224/ -- sorry it's a little on the large side. nett negative though if that's consolation
<dooferlad> jam, voidspace - hangout time
<rogpeppe1> anyone know the best way of manually destroying a juju lxd controller and all its resources (juju kill-controller isn't doing the job - i bootstrapped with a different, incompatible, juju version) ?
<babbageclunk> rogpeppe1: I think it's just `juju unregister <controller>` and then `lxc delete ` the machines.
<rogpeppe1> babbageclunk: what about all the jujuds ?
<babbageclunk> rogpeppe1: Well, I'd be surprised if they stayed after you killed the containers.
<babbageclunk> rogpeppe1: (I might be misunderstanding your question.)
<rogpeppe1> babbageclunk: lxc doesn't seem to have a delete subcommand
<rogpeppe1> babbageclunk: hmm, it does actually
<babbageclunk> rogpeppe1: phew
<babbageclunk> rogpeppe1: was getting confused there.
<rogpeppe1> babbageclunk: it gave me a usage message but i must've typed the wrong command
<rogpeppe1> babbageclunk: jujuds are gone now, ta!
<babbageclunk> rogpeppe1: :)
<urulama> babbageclunk: hey ... did you see my last comment here https://bugs.launchpad.net/juju-core/+bug/1593828 ?
<mup> Bug #1593828: cannot assign unit E11000 duplicate key error collection: juju.txns.stash <ci> <conjure> <deploy> <intermittent-failure> <oil> <juju-core:In Progress by 2-xtian> <https://launchpad.net/bugs/1593828>
<urulama> babbageclunk: could you verify with a simple test that it actually work or not?
<babbageclunk> urulama: yes! I started replying to it and then I started making a bug
<urulama> babbageclunk: you know what it could be?
<babbageclunk> urulama: I see the same behaviour - I don't think it's anything to do with that bug.
<urulama> babbageclunk: +1 on that
<babbageclunk> urulama: Well, not really - the failed machines have cloud-init logs that stop before installing all the juju stuff.
<babbageclunk> urulama: but I don't know why that is.
<urulama> babbageclunk: oh, ok, i'll pay more attention to cloud-init logs, thanks
<babbageclunk> urulama: I'll just finish grabbing logs and put them on the bug, then I'll put a link to it into the other comments.
<urulama> babbageclunk: awesome, ty
<babbageclunk> urulama: here it is: https://bugs.launchpad.net/juju-core/+bug/1602192
<mup> Bug #1602192: deploy 30 nodes on lxd, machines never leave pending <juju-core:New> <https://launchpad.net/bugs/1602192>
<urulama> babbageclunk: thanks, bumping importance, and preferred milestone
<mup> Bug #1602192 opened: deploy 30 nodes on lxd, machines never leave pending <juju-core:New> <https://launchpad.net/bugs/1602192>
<babbageclunk> urulama: Thanks - I don't know the protocol on those yet, never sure whether I should be setting them.
<jam> babbageclunk: https://bugs.launchpad.net/juju-core/+bug/1602192
<mup> Bug #1602192: deploy 30 nodes on lxd, machines never leave pending <juju-core:New> <https://launchpad.net/bugs/1602192>
<axw> wallyworld: sorry, I could've sworn the sink name was set to the sensible thing :/
<jam> I certainly believe that this is reproducible for you, but we need the logs from machine-0 which is doing the provisioning
<jam> vs the individual machines that fail.
<axw> wallyworld: do you agree that it should be what I described?
<babbageclunk> jam: ok, I'll add those.
<wallyworld> axw: tis ok, it should be changed i think yeah
<axw> wallyworld: I'm thinking we'd have something like storage pools, and in this case the sink name is equivalent to storage pool name
<axw> sorta
<axw> so that remains fixed for the lifetime of the sink, but the config may change
<wallyworld> yep
<jam> babbageclunk: so a cloud-init-output.log that stops fairly early... sounds a bit like just slow cloud-init due to your machine trying to run 30 containers at the same time. not sure
<jam> babbageclunk: the other thing that might be useful is 'cloud-init.log' vs 'cloud-init-output.log' if cloud-init is failing to complete.
<babbageclunk> jam: certainly my machine wasn't that happy when they were starting up.
<jam> machine-0.log would be if Juju provisioning is failing to request enough containers from LXD
<jam> cloud-init.log is for when cloud-init itself breaks
<jam> cloud-init-output.log is for when cloud-init thinks it's happy, but the initialization we request of it is wrong.
<jam> (its been rare that cloud-init.log is the problem, which is why it isn't my first go to)
<babbageclunk> jam: makes sense - adding the controller machine-0.log and cloud-init.log from a failed machine
<mup> Bug #1602084 changed: log-forwarding with level set to INFO starts endless logging loop. <juju-core:New> <https://launchpad.net/bugs/1602084>
<urulama> but the LXD start 90s apart, which was enough time that they were up and running before another one hit
<urulama> babbageclunk, jam ^
<babbageclunk> urulama: I realised I hadn't rebuilt with my mgo patch, which didn't seem to be the problem but definitely muddied the water. So I'm redoing it now.
<jam> urulama: just a dup of bug #1599779
<mup> Bug #1599779: Very high CPU usage from 'creating cloud image metadata storage'  emitted in debug log every second <juju-core:New> <https://launchpad.net/bugs/1599779>
<jam> nothing to do with INFO level
<jam> and I don't think it is actually a 'loop' in the general sense, just something that we're doing poorly.
<urulama> jam: so you assume when CPU issue is resolved, then provisioning will work as well? I doubt that, my CPU was not using all cores 100%
<jam> urulama: no, I think provisioning is separate from bug #1599779
<mup> Bug #1599779: Very high CPU usage from 'creating cloud image metadata storage'  emitted in debug log every second <juju-core:New> <https://launchpad.net/bugs/1599779>
<jam> it *might* be related if the provisioning failure is because there is too much CPU load causing the provisioned machines to fail to download the tools they need
<urulama> kk
<mup> Bug #1602231 opened: juju status should use natural sort for units <status> <juju-core:New> <https://launchpad.net/bugs/1602231>
<mup> Bug #1602237 opened: log forwarding config watcher needs to be implemented <juju-core:Triaged> <https://launchpad.net/bugs/1602237>
<axw> wallyworld: reviewed your branch
<wallyworld> great ty
<wallyworld> i'm adding to the feature test
<wallyworld> axw: i replied to one of the comments, see what you think
<axw> wallyworld: yeah, that's what I was suggesting. log but otherwise ignore the invalid config. carry on with the existing sink
<axw> in which case "enabled" shouldn't be touched I think?
<wallyworld> yep, am fixing that. but i still think the check for cfg.Enabled goes first before validating
<axw> wallyworld: I'm heading off, need anything from me before I go?
<wallyworld> axw: all good, ty, will run live test now. just added feature test
<axw> wallyworld: thanks. good night
<wallyworld> ttyl
<natefinch> wallyworld: I'll start looking at interactive bootstrap ASAP.
<wallyworld> ok, ty
<alexisb__> frobware, I am going to be late to our 1x1, will ping you
<frobware> alexisb__: ack
<mup> Bug #1602067 changed: [2.0b11] Repeated "log-forwarder" errors in debug-log with Azure provider <juju-core:New> <https://launchpad.net/bugs/1602067>
<babbageclunk> rogpeppe1: Thanks for the review!
<rogpeppe1> babbageclunk: np. we'll keep fingers crossed.
<babbageclunk> rogpeppe1: Also, I didn't understand this morning what you were saying about jujud processes hanging around - I didn't know that processes in lxd containers were visible on the host!
<rogpeppe1> babbageclunk: they showed up with ps alxw | grep jujud
<rogpeppe1> babbageclunk: maybe i should run my desktop in a container...
<babbageclunk> rogpeppe1: And with pgrep too. Maybe I should be less gung-ho about killing "stray" mongo processes on my machine in that case.
<rogpeppe1> babbageclunk: it's ok, they start again immediately if you kill 'em
<babbageclunk> rogpeppe1: yay!
<alexisb__> frobware, ok, I am free will join the HO
<frobware> alexisb__: omw
<babbageclunk> is that really alexisb_? Or is it someone pretending to be alexisb_?
<alexisb__> :)
<alexisb__> it is alexisb with a bad connection
<natefinch> hmm... that's exactly what someone pretending to be alexisb_ would say....
<natefinch> katco: I guess no standup?
<katco> natefinch: oh sorry, didn't know you were here
<jam> mgz: ping
<natefinch> katco: I'm here :)  just you and I, I think, though
<katco> natefinch: yeah. let
<katco> natefinch: let's defer until we have at least 3
<katco> natefinch: (i.e. thurs.)
<natefinch> katco: I'm just doing interactive bootstrap.
<katco> natefinch: i'm still working on audit
<natefinch> katco: cool. standup done! ;)
<mgz> jam: yo
<katco> natefinch: lol yep
<katco> natefinch: wb btw
<natefinch> katco: thanks.  Sorry about not updating the calendar that I'd be out yesterday.  Swear I did it, but it was like two weeks ago, so who knows.
<katco> natefinch: no worries
<rogpeppe1> anyone know how you're supposed to switch accounts from the command line?
<rogpeppe> juju switch doesn't seem to support account switching
<rogpeppe> well, in Î²11 anyway
<cherylj> babbageclunk: have you pinged smoser about that cloud init issue for bug 1602192?
<mup> Bug #1602192: deploy 30 nodes on lxd, machines never leave pending <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1602192>
<babbageclunk> cherylj: no - <looks up smoser>
<cherylj> babbageclunk: yeah, I'd ping him before spending a whole bunch of time debugging cloud init
<babbageclunk> cherylj: ok, will do - thanks
<cherylj> np :)
<mgz> he's around today, I have spoken to him... but I have some doubts it's actually cloud-init related
<cherylj> yeah, but he could give some hints about where to look if it's not
<jam> mgz: hi. I wanted to check if mgo is one of the -dev packages that we pull from the archive instead of bundling our own.
<jam> as we have an important fix for the next release, but does that mean we need to get a mgo release, and into xenial backports/updates before we can build juju with it?
<mgz> jam: it is not
<jam> mgz: good to hear
<mgz> hm, odd, it was on the list initially
<babbageclunk> mgz: do you have a theory about that bug?
<perrito666> hi all btw
<perrito666> frankban|afk: please ping me when you are back
<mgz> babbageclunk: not really I'm afraid
<natefinch> perrito666: howdy
<mgz> balloons: ^do you remember why we don't use the mgo package in xenial for juju?
<babbageclunk> mgz: darn. Why don't you think it's cloud-init related?
<balloons> mgz, golang-gopkg-mgo.v2-dev is on the list. We couldn't use it for xenial because it's not in main
<balloons> there's a MIR bug that's not finished for it
<mgz> I'd expect useful stuff in cloud-init.log if there was really a problem starting the init step, given init-local succeeds for both
<balloons> https://bugs.launchpad.net/ubuntu/+source/golang-gopkg-mgo.v2/+bug/1568162
<mup> Bug #1568162: [MIR] golang-gopkg-mgo.v2 <golang-gopkg-mgo.v2 (Ubuntu):Incomplete> <https://launchpad.net/bugs/1568162>
<mgz> jam: ^so, that's the answer, package not in main. your problem is fine for now then, though it may be polite to file an sru bug for the mgo update if it's likely to affect other users.... if there are other users.
<frobware> alexisb__: one thing I meant to mention is that the MAAS folks are having a sprint in bluefin in august - it might be worth tagging alone for a couple of days to talk about IPv6
<natefinch> jam, mgz: it shouldn't matter what's in main for most people, should it?  Since simple streams uses our own built version.  The only people using what's actually in ubuntu would be people who use upload-tools.
<mgz> natefinch: in this case it's just a distro policy thing you really don't need to care about
<natefinch> mgz: right, I just wanted to make sure I was on the right page, in that, for the most part, we (thankfully) don't need to care about what ubuntu does with their wacky go packaging
<mgz> and yeah, we already have some bugs that are not fixed if people use --upload-tools
<babbageclunk> mgz, natefinch - I'm not following this. What does it mean for mgo to be deployed from a package? When we package juju do we build it so that it's not statically linked?
<mgz> babbageclunk: normally when you bootstrap juju, it goes and fetches the juju binary from streams.canonical.com
<mgz> we build those with exactly what's in dependencies.tsv
<mgz> not what's in the archive
<babbageclunk> ok
<jam> babbageclunk: but the binaries you get from "apt-get install juju" (which gives you a jujud) uses ubuntu '-dev' packages.
<jam> so we get the worst of all worlds as near as I can tell.
<natefinch> babbageclunk: what we deploy to streams is a different binary with different behavior than what they package in ubuntu.  We use code that matches the versions in dependencies.tsv.  They use.... some other versions.
<babbageclunk> jam - so the apt-gotten jujud dynamically loads mgo?
<alexisb__> frobware, agreed
<natefinch> babbageclunk: no, it's just built statically with a different version
<natefinch> babbageclunk: ubuntu wants all go applications delivered with ubuntu to use the same version of mgo.  So they pick one and compile everything with that one.
<babbageclunk> natefinch: ah. Ok, that was the bit I missed.
<babbageclunk> natefinch: that seems quite restrictive.
<jam> natefinch: babbageclunk: so according to mgz the 'mgo' library itself is not one of those, but there are about 10 dependencies that do work that way
<jam> gocrypto being one of them, I believe.
<cherylj> redir: sorry to add more churn in your delete^H^H^H^H^H^H remove-user command ;)
<babbageclunk> jam, natefinch: So this only affects people using --upload-tools? Other bootstraps get a good jujud from the stream and the weird jujud on their local machine doesn't really matter?
<mgz> babbageclunk: yes. ideally we don't include jujud in the archive at all.
<jam> babbageclunk: so, I'm pretty uncomfortable having a jujud out there that isn't the real jujud and both of them claim exactly the same version, but AIUI that is true
<mgz> but I got yelled at when I tried to sneak it out :)
<cherylj> heh
<babbageclunk> jam: oh, I can see why it's gross, just wanted to make sure I understood the implicatons.
<babbageclunk> mgz :)
<babbageclunk> thanks for the explanations everyone!
<perrito666> rogpeppe: oh your mail brightened my day... not :p
<rogpeppe> perrito666: sorry :)
<perrito666> rogpeppe: I assumed some things might break that where working a bit accidentally because of the previous implementation of users :) I am a bit saddened that no test at all blew with this
<perrito666> nah, that is not true, I am actually quite pissed :)
<rogpeppe> perrito666: the problem was that there were no juju command tests for this
<perrito666> rogpeppe: exactly
<rogpeppe> perrito666: which was actually slightly deliberate, unfortunately
<perrito666> rogpeppe: care to elaborate a bit on that?
<dooferlad> cherylj: I tracked down the cause of bug #1599779 - every log forwarding call opens the API server, which starts some workers, then logs, the workers are stopped and the process repeats. The log sender needs to keep the API open on the client side to avoid this.
<mup> Bug #1599779: Very high CPU usage from 'creating cloud image metadata storage'  emitted in debug log every second <juju-core:Triaged> <https://launchpad.net/bugs/1599779>
<dooferlad> cherylj: don't know who to assign it to, but I know I need to go cook dinner soon :-|
<dooferlad> cherylj: happy to take it myself if nobody is free who worked on it
<dooferlad> ok, so the server side needs to keep things open. Oh, I need a fresh brain. Will make more notes in the bug
<katco> dooferlad: i think wallyworld was working on this
<mup> Bug #1600302 changed: security groups could not be destroyed when an Openstack provider bootstrap was interrupted with ctrl-c <cdo-qa> <juju-core:New> <https://launchpad.net/bugs/1600302>
<cherylj> dooferlad: thanks for digging into it.  I'll bring it up in the release call and see if we can get someone on it
<aisrael> I've seen mongod/jujud use a ton of cpu when I only have a single controller and one model with nothing deployed. `juju debug-log` shows nothing. How can I capture info out of mongo/juju in order to debug/provide feedback?
<natefinch> aisrael: you probably need to up the log level to show more... the default is pretty light on logging.  juju set-model-config logging-config="<root>=DEBUG" will help show more of what's going on.
<natefinch> aisrael: you will probably want to do that both for the default model and the controller model
<aisrael> natefinch: Excellent, thanks. I'll work on repeating the behavior and try to get something useful out of it.
<natefinch> aisrael: cool.  you can also do --config  logging-config="<root>=DEBUG" at bootstrap time to set the log level immediately (I'm not 100% sure how that interacts with multiple models, though)
<aisrael> natefinch: good to know!
<aisrael> natefinch: when I do that, where will I find that log output?
<aisrael> natefinch: nevermind, I found it. Switch to controller model and look in /var/log/juju
<natefinch> aisrael: the usual debug-log... however most likely anything interesting will be in the debug-log of the controller model (debug-log is per-model now)
<natefinch> aisrael: yep
<aisrael> debug-log wasn't showing me anything in the controller model but I have a ton of data now. I'll let it log over lunch and poke the logs when I'm back.
<natefinch> aisrael: cool, good luck.  I hope you can figure it out.
<cmars> how do i pprof a controller?
<cmars> i have a beta11 controller that's going nuts
<natefinch> cmars, aisrael: I think there's a bug that is causing this - https://launchpad.net/bugs/1599779
<mup> Bug #1599779: Very high CPU usage from 'creating cloud image metadata storage'  emitted in debug log every second <juju-core:Triaged> <https://launchpad.net/bugs/1599779>
<cmars> natefinch, thanks, checking my log
<cmars> natefinch, its a bunch of 'log forwarding not supported' messages
<cmars> natefinch, same or different issue, should I open a bug?
<natefinch> cmars: I think it's worth making it a new bug even if we eventually decide it's a duplicate, just to make it easier for others to find
<katco> cmars: there is already a bug open for that
<katco> cmars: i believe it's this one: bug 1598118
<mup> Bug #1598118: log-forwarder worker bounces endlessly when forwarding is not configured <2.0> <debug-log> <log-forwarding> <logging> <juju-core:Fix Committed by ericsnowcurrently> <https://launchpad.net/bugs/1598118>
<cmars> natefinch, thanks, i feel less guilty for opening dups :)
<cmars> katco, thanks, that's the one
<natefinch> cmars: a duplicate bug is far better than a missing bug
<natefinch> afk a while
<cherylj> katco: could you review that deployer fix we chatted about last week?  http://reviews.vapour.ws/r/5227/
<katco> cherylj: sure
<cherylj> ty!
<katco> cherylj: you have a review
<cherylj> thanks!
<cherylj> katco: for the testing comment - I did it asynchronously because if the deployer worker doesn't fail to deploy the unit, Wait() won't return
<cherylj> (since the loop would happily keep waiting for the next event)
<katco> cherylj: is there any way to set up the test to always fail?
<cherylj> katco: yeah,  since I've embedded the interface and the next thing the deployer would do is call DeployUnit, it will panic if I don't have that defined (which I don't)
<katco> cherylj: so, you can remove the goroutine?
<cherylj> I could.
<katco> cherylj: yay? do you disagree that removing it is good?
<cherylj> It just felt nicer
<cherylj> to me at least
<katco> cherylj: it has a race condition though
<cherylj> fair point
<cherylj> katco: updated!  http://reviews.vapour.ws/r/5227/
<katco> cherylj: k tal
<cherylj> blergh, it didn't save my updates to the description
<katco> cherylj: doh... also the checklist calls for testing methodology
<cherylj> katco: I ran it through CI
<cherylj> Can't recreate manually
<katco> cherylj: ah that's right
<katco> cherylj: lgtm
<perrito666> could anyone make a quick review to http://reviews.vapour.ws/r/5228/ ?
<cherylj> thanks!
<katco> cherylj: ty
<natefinch> perrito666: I can look
<perrito666> natefinch: its literally 2 lines
<perrito666> just growing a table, ish
<natefinch> perrito666: ship it
<perrito666> tx a lot
<natefinch> ug, juju bootstrap --clouds is a terrible idea
<natefinch> it makes juju bootstrap do two totally different things
<perrito666> natefinch: what does it do?
<natefinch> perrito666: it's basically juju list-clouds combined with juju list-credentials
<natefinch> perrito666: I don't really understand why it exists, and especially not why it is a flag on bootstrap
<natefinch> perrito666: http://pastebin.ubuntu.com/19206808/
<perrito666> natefinch: sounds like a very specific --help
<natefinch> perrito666: yeah
<mup> Bug #1602416 opened: Failure to perform action due to tcp i/o timeout <juju-core:New> <https://launchpad.net/bugs/1602416>
<mup> Bug #1602416 changed: Failure to perform action due to tcp i/o timeout <juju-core:New> <https://launchpad.net/bugs/1602416>
<mup> Bug #1602416 opened: Failure to perform action due to tcp i/o timeout <juju-core:New> <https://launchpad.net/bugs/1602416>
<wallyworld> niedbalski_: we're running late, still in another meeting, be there soon
<thumper> alexisb: is there the sts cross team?
<alexisb> thumper, yes
<perrito666> k leaving for a moment, wallyworld ill be back for standup
<wallyworld> ok
<niedbalski_> cherylj, https://bugs.launchpad.net/juju-core/+bug/1602054
<mup> Bug #1602054: juju deployed lxd containers are missing a default gateway when configured with multiple interfaces <juju-core:New> <https://launchpad.net/bugs/1602054>
<alexisb> thumper, did you want to take a coupld of minites and catch up before my eod??
<thumper> alexisb: sure
<alexisb> https://hangouts.google.com/hangouts/_/canonical.com/alexis-tim
<perrito666> redir: alexisb https://en.wikipedia.org/wiki/Teletext
<wallyworld> menn0: would love a quick chat at some point today, when you have 5 minutes free, can be any time
<wallyworld> veebers: that latest log forward branch finally got landed. the new config attribute is logforward-enabled (false by default)
<menn0> wallyworld: sure. i'm close to proposing a fix for this debug-log issue. let's talk once i've done that.
<wallyworld> no hurry at all
<veebers> wallyworld: sweet
<wallyworld> veebers: i am going to look at that CPU issue again - i couldn't repro it, but there's something amiss it seems. apart from that, everything should be functional
<veebers> wallyworld: cool. I'll see if I can repro it again with a latest build
<veebers> wallyworld: did those instructions came in handy yesterday?
<wallyworld> veebers: i ended up hacking something else together for expediency (used a file sink not a syslog sink) - that was all i needed to test the bits i was interested in
<wallyworld> but i will probs do the full set up at some point
<veebers> ah nice, wasn't aware of a file sink :-\ That may have been easier
#juju-dev 2016-07-13
<wallyworld> veebers: i just hacked up something in code as a temp thing on my system
<redir> wallyworld: got any availability in the next 60-90m?
<wallyworld> redir: sure
<redir> wallyworld: pick a time any time
<wallyworld> redir: now is good,that way you can escape and go do dinner or whatever
<redir> k
<redir> tanzanite?
<wallyworld> ok
<menn0> thumper: here's the fix for the debug-log sorting issue: http://reviews.vapour.ws/r/5229/
<thumper> menn0: kk, will look shortly
<thumper> menn0: http://reviews.vapour.ws/r/5230/
<menn0> thumper: will take a look in a sec
<menn0> thumper, wallyworld: I can't land the fix for 1590605 b/c it isn't a blocker
<thumper> menn0: JFDI
<wallyworld> +1
<menn0> ok
<rick_h_> wallyworld: hacked up the ACL spec based on conversations I had with jam and urulama today
<rick_h_> wallyworld: PTAL sometime and let me know if that's ok by you and any issues/concerns from here
<wallyworld> rick_h_: will do, in meeting, will look straight after, ty
<rick_h_> wallyworld: all good, thanks for giving it a go when you're free
<mup> Bug #1602010 changed: juju status doens't display proper error when machine fails <juju-core:New> <https://launchpad.net/bugs/1602010>
<veebers> wallyworld: everytime I enable log forwarding (and it works i.e. I use the right host IP) it triggers that logging bug (#1599779)
<mup> Bug #1599779: Very high CPU usage from 'creating cloud image metadata storage'  emitted in debug log every second <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1599779>
<veebers> wallyworld: is there any useful information that I can provide you? I doubt I'm doing anything special or out of the ordinary
<wallyworld> veebers: i think i have enough now - i am rewriting some stuff, i will have something fixed today
<veebers> wallyworld: ah cool :-)
<wallyworld> veebers: but apart from that, good that it works, thanks for testing
<wallyworld> rick_h_: one thing, thumper said that mark himself was the one who originally wanted the add-user command to include the --shared models option, so you will need to be sure that he is across the change to remove that
<axw> wallyworld: FYI I found that state was still allowing controller config into model config in some cases (I think only in tests), so currently fixing a bunch more things.
<wallyworld> ok
<axw> thumper menn0: was environs.MigrationConfigUpdater added only for azure? the need for it has gone away, so I'll remove it unless there's another use case
<thumper> not sure TBH
<axw> (we don't have controller-uuid in model config anymore. we'll need a way to retag things, but should be done a bit differently I think)
<axw> thumper: it's not implemented by anything other than dummy, so I'll remove it and we can reinstate if needed
<mup> Bug #1556153 changed: ERROR destroying instances: cannot release nodes: gomaasapi: got error back from server: 504 GATEWAY TIMEOUT (Unexpected exception: TimeoutError <oil> <juju-core:Invalid> <MAAS:New> <https://launchpad.net/bugs/1556153>
<mup> Bug #1556153 opened: ERROR destroying instances: cannot release nodes: gomaasapi: got error back from server: 504 GATEWAY TIMEOUT (Unexpected exception: TimeoutError <oil> <juju-core:Invalid> <MAAS:New> <https://launchpad.net/bugs/1556153>
<mup> Bug #1556153 changed: ERROR destroying instances: cannot release nodes: gomaasapi: got error back from server: 504 GATEWAY TIMEOUT (Unexpected exception: TimeoutError <oil> <juju-core:Invalid> <MAAS:New> <https://launchpad.net/bugs/1556153>
<menn0> thumper: ship it for 5230
<menn0> wallyworld: chat?
<thumper> menn0: cheers
<wallyworld> menn0: sure, https://hangouts.google.com/hangouts/_/canonical.com/tanzanite-stand
<wallyworld> axw: you canpop in too if you're free - talk about log streamer etc
<axw> wallyworld: can you PTAL at ahttp://reviews.vapour.ws/r/5224/, just the last commit/rev. I've remove ca-private-key from controller config attrs, plugged a hole in state where we allowed controller config through, and fixed fallout
<axw> wallyworld: there was a bit of model migration removed too, which was added for azure but is no longer needed
<wallyworld> ok
<wallyworld> axw: minor typo. so the private key should just go to state serving info (from memory) and nowhere else
<wallyworld> it is used by the cert update worker
<axw> wallyworld: thanks. yes, that is correct
<wallyworld> so godd that it is also removed from controller config as nothing else needs to see it
<wallyworld> good
<mup> Bug #1602508 opened: LastLogTracker accesses mongo collections directly <2.0> <juju-core:Triaged> <https://launchpad.net/bugs/1602508>
<wallyworld> axw: when you have time, here's that log forward fix http://reviews.vapour.ws/r/5231/
<axw> wallyworld: reviewed
<wallyworld> ta
<axw> argh, juju-ci is Service Unavailable
<wallyworld> axw: i didn't want to make any assumptions about order - i guess i could pick the one with the biggest timestamp
<axw> wallyworld: well we forward them in order don't we?
<axw> I'm pretty sure that's part of the contract
<wallyworld> fair enough, i was being overly cautious i guess
<wallyworld> axw: fixed
<axw> wallyworld: LGTM, thanks
<wallyworld> ta
<axw> wallyworld: CI is buggered atm
<wallyworld> oh, damn
<axw> seems the jenkins agent died, I don't know how to fix it tho
<wallyworld> axw: same thing happended yesterday too
<axw> interesting
<axw> jam: it was changed from SetList to SetLastSent
<jam> axw: ah, just read it backwards then.
<jam> thanks
<wallyworld> axw: the juju login command - where does that write to the db? ie the macaroon and record of login
<axw> wallyworld: it requests a macaroon from the controller, the controller generates a root key for the macaroon. that's the only thing that's stored in the db
<axw> wallyworld: otherwise it's all stored client side
<wallyworld> axw: np, thanks. i'm commenting on https://docs.google.com/document/d/1xRO2tbeC-Dg5JdSV-wMYIZQel11EfWqPk8LU-0XdH8Y
<axw> wallyworld: when you send the LoginRequest, you can optionally include a model UUID. if you don't include it, you get a controller-only login. so that much already exists, if I'm interpreting it correctly
<wallyworld> axw: yep, that's what i though too
<axw> wallyworld: do you recall why you made this change? https://github.com/juju/juju/commit/f751ea7b54876a5a38dbef6dfc90e1d56b1531d5
<axw> wallyworld: I'm trying to weed out unnecessary environs.Environ constructions, this code stuck out as a bit odd
<wallyworld> axw: not 100% sure - i think the intent was to not do an upgrade (or attempt it) if there was an issue with the cloud and the machines could not be contacted
<wallyworld> so a sanity / pre-upgrade check
<axw> hm, ok.
<wallyworld> axw: i can't recall where the requirement came from, but i recall "someone" asked for it
<axw> wallyworld: alright. I'll leave it alone
<wallyworld> axw:  can you join us? https://hangouts.google.com/hangouts/_/canonical.com/regular-catchup
<axw> wallyworld: be there in a moment
<jam> frobware: ping
<rogpeppe2> axw: hiya
<axw> rogpeppe2: hey
<axw> rogpeppe: I'm hopping on a call shortly, but will be around after that (in an hour or so)
<rogpeppe> axw: ok, cool
<rogpeppe> axw: let's do it then
<axw> rogpeppe: I just did a little test, if you set the value of "user" in accounts.yaml to nothing, and remove the password line, it should trigger external auth
<axw> rogpeppe: except there's a bug, fixed by http://reviews.vapour.ws/r/5232/
<rogpeppe> axw: ah yes, i came across that
<rogpeppe> axw: it's still not ideal though
<axw> rogpeppe: re your email, I think we could more or less drop accounts.yaml, we just need the logged-in user's details. we used to support multiple users logged in simulataneously from the same client, but not now
<axw> so models.yaml shouldn't need the account qualifier. they would implicitly be relative to the logged-in user
<rogpeppe> axw: ah, ok - i guess that the jujuclient API is already due for an update then
<axw> rogpeppe: it wasn't really necessary until now, but I do think this tips it over the edge
<rogpeppe> axw: wouldn't you still need accounts.yaml 'cos you can still have a different user for each controller?
<axw> rogpeppe: yeah, sorry, we can't drop that - we can only drop the account part from models.yaml
<jam> axw: tech board?
<axw> rogpeppe: accounts.yaml would just become controller -> {user creds}
<axw> jam: coming
<rogpeppe> axw: right, cool
<rogpeppe> axw: as i think i suggested in my email
<rogpeppe> axw: just looking at http://reviews.vapour.ws/r/5205/diff/# - doesn't our suggested approach above rather go against what that's doing?
<mup> Bug #1602572 opened: Handler function is not being called even after changed one of the config values of the config.yaml <juju-core:New> <https://launchpad.net/bugs/1602572>
<thumper> night all
<axw> rogpeppe: back. looking...
<axw> rogpeppe: suggested approach of changes to accounts.yaml?
<rogpeppe> axw: well, of changes to models.yaml really
<rogpeppe> axw: if a model isn't relative to an account, then it's not going to be that easy to namespace model names by user
<axw> rogpeppe: models.yaml will only store information about models that the logged in user has access to. and you can still tell what user you're logged in as
<axw> rogpeppe: I think the only thing that changes in that diff is to replace the use of AccountName with the logged-in user name
<axw> which we get back from login
<rogpeppe> axw: i guess i'm wondering whether the model namespace is actually still per-user
<rogpeppe> axw: have you got some time to pair for a bit?
<axw> rogpeppe: yes
<mup> Bug #1602591 opened: Juju 2.0 Resources: Issue while fetching empty resources from charm store <juju-core:New> <https://launchpad.net/bugs/1602591>
<mup> Bug #1602591 changed: Juju 2.0 Resources: Issue while fetching empty resources from charm store <juju-core:New> <https://launchpad.net/bugs/1602591>
<mup> Bug #1584616 opened: mtu configuration should not be moved to bridge interface <network> <juju-core:In Progress by frobware> <https://launchpad.net/bugs/1584616>
<axw> mgz: are you around? do you know juju-ci is busted?
<frobware> dooferlad: ping - do you some time to look over my sholder at some networky things....
<dooferlad> frobware: sure
<frobware> dooferlad: 1:1 HO
<axw> rogpeppe: https://github.com/juju/juju/pull/5788
<perrito666> morning all
<axw> rogpeppe: back for 10 mins or so - how's it going?
<mgz> axw: yeah, it's I think just the proxy server, master seems to be up and doing things
<axw> mgz: when I ssh'd to the machine, the jenkins job log said the agent had terminated or something like that
<mgz> have restarted jenkins to see if it get stuck in the same loop
<mgz> axw: well, it's up now, possibly still not very happy?
<axw> mgz: I'll try landing my branch again, we'll see :)
<axw> mgz: thanks
<rogpeppe> axw: sorry, was on lunch
<cherylj> mgz: got a few to help me look at the 1.25 CI failures?
<babbageclunk> Help - does anyone know about how cloud-init works?
<mgz> cherylj: sure, daily hangout?
<cherylj> mgz: yeah, omw
<cherylj> babbageclunk: you may have some luck asking in #cloudware on the canonical IRC
<babbageclunk> Ok, thanks - I pinged smoser but caught him on the way out.
<frobware> anybody see this "bad ports from GCE: invalid port range 0-0/tcp" from GCE recently?
<mup> Bug #1602716 opened: MAAS provider bridge script doesn't handle alias interfaces IP <maas-provider> <network> <sts> <juju-core:New> <https://launchpad.net/bugs/1602716>
<lazyPower> frobware - i have not, i've been running nearly exclusively on GCE since beta-8
<lazyPower> frobware - any clue on reproduction? I'm happy to give it a go
<perrito666> controlleruuid and controllermodeluuid are the same always? and if so, is that by design?
<alexisb_> frobware, looks like a bug just got opened
<mup> Bug #1602732 opened: GCE bad ports 0-0/tcp <blocker> <ci> <gce> <regression> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1602732>
<cherylj> lazyPower, frobware just be aware that that bug also leaves the controller instance alive.
<cherylj> yay!
<cherylj> mgz: ^^  fyi
<cherylj> perrito666: yes, that is by design
<cherylj> babbageclunk: have you been able to get help with your cloud-init question?
 * perrito666 decides not to create a controllerTag
<cherylj> perrito666: that being said, I don't know if there are plans to change that
<babbageclunk> cherylj: yes, some - I'll do an update on the bug.
<perrito666> cherylj: ah, that was my next question
<mup> Bug #1602732 changed: GCE bad ports 0-0/tcp <blocker> <ci> <gce> <regression> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1602732>
<alexisb_> babbageclunk, should this bug be fix committed: https://bugs.launchpad.net/juju-core/+bug/1598897 ??
<mup> Bug #1598897: juju status: relation name oscillates for peer relations <juju-core:In Progress by 2-xtian> <https://launchpad.net/bugs/1598897>
<alexisb_> if so I will update it for you
<cherylj> alexisb_: just fyi - that GCE bug means that no one can bootstrap on GCE now with the current master
<babbageclunk> alexisb_: oops, yes please.
<alexisb_> cherylj, yes
 * cherylj sadface
<alexisb_> it will need to get fixed before we release
<cherylj> heh
<mup> Bug #1602732 opened: GCE bad ports 0-0/tcp <blocker> <ci> <gce> <regression> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1602732>
<lazyPower> ah ok, i'm currently on beta-11
<lazyPower> that makes sense why i haven't seen it if its only affecting master
<cherylj> lazyPower: yeah, just injected yesterday
<natefinch> gah, who decided that github.com/juju/juju/cloud.Cloud shouldn't have a Name field :/
<natefinch> one might assume the name of a cloud might be important info :/
<perrito666> oh, great, another breaking change, people is going ot hate me
<alexisb_> perrito666, what change?
<perrito666> alexisb_: oh, not that breaking
<frobware> mgz: thanks for raising the bug
<perrito666> alexisb_: I am writing controller permissions and thinking on unifying some code but on second thought it might be better to have a bit of code duplication at this point
<frobware> lazyPower: yep, fails on tip (plus my changes, which don't seem to make it worse/better)
<mup> Bug #1602749 opened: no visible sign that HA is degraded when lost  <2.0> <usability> <juju-core:Confirmed> <https://launchpad.net/bugs/1602749>
<natefinch> searching for the string literal "lxd" returns a distressing number of hits.  did we not all have it beaten into our heads to always use constants and not write out string literals everywhere?
<katco`> cherylj: any objections to raising bug 1598063 as critical so i can land the fix?
<mup> Bug #1598063: Data race in apiserver/observer package <ci> <race-condition> <juju-core:In Progress by cox-katherine-e> <https://launchpad.net/bugs/1598063>
<cherylj> katco:  no objections :)
<katco`> cherylj: great, thx!
<cherylj> you'll need to add the blocker tag too to use the $$fixes-####$$ notation
<katco`> cherylj: ah ok
<frobware> dooferlad: thanks for the link to the alias bug
<dooferlad> frobware: I assume that is sarcasm...
<frobware> dooferlad: check!
<frobware> sigh
<frobware> dooferlad: we used to bridge aliases but removed it. I cannot immediately recally why we removed bridges for aliases...
<natefinch> oh man, we love spooky action at a distance in this codebase
<dooferlad> frobware: I am hoping that https://bugs.launchpad.net/juju-core/+bug/1602054 is related to some interfaces juggling, but I am not seeing much hope.
<mup> Bug #1602054: juju deployed lxd containers are missing a default gateway when configured with multiple interfaces <network> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1602054>
<frobware> dooferlad: you wrote "we save the original in /etc/network" - we do?
<dooferlad> frobware: unfortunately when trying to recreate the issue I set up two NICs on the MAAS controller, put the new NIC on another subnet and then I couldn't add a LXD because Juju was trying to connect to the wrong IP address. Yay.
 * dooferlad goes to make dinner and ponder the wrongs of trying to make computers communicate
<frobware> dooferlad: have you tried putting both on the same subnet?
<frobware> cherylj, mgz: not that I have cloud-city creds for GCE, is there a way to get to the dashboard to kill of my rogue instance. Up until recently I was using my own (free/trial) account.
<mgz> frobware: I can add you if you promise to be good
<frobware> mgz: I can be good-ish. Promise-ish. :)
<cherylj> lol
 * frobware steps out of being bad to "kill" an instance... ???
<mgz> frobware: you can now login to the webconsole via your canonical account and the details in cloud-city
<frobware> mgz: thanks & trying now...
<cherylj> frobware: would you be able to review https://github.com/juju/juju/pull/5790 ?
<frobware> cherylj: we used to do this. then removed it - I mentioned this in the bug.
<cherylj> frobware: ah, so the reasons need to be investigated ?
<frobware> cherylj: the change is absolutely fine. it's the semantics that concern me a little.
<frobware> cherylj: but... this could have been at a time when there were /other/ things that were broken.
<frobware> cherylj: either way, I just commented in the PR
<cherylj> thanks, frobware
<frobware> dooferlad, voidspace, babbageclunk: PTAL @ http://reviews.vapour.ws/r/5234/
<babbageclunk> frobware: looking
<katco`> cherylj: wow, that got merged fast... is this the new branching structure in play? it doesn't look like any tests were run? http://juju-ci.vapour.ws:8080/job/github-merge-juju/8403/console
<cherylj> umm.....
<cherylj> balloons: can you look at http://juju-ci.vapour.ws:8080/job/github-merge-juju/8403/console ?
<cherylj> oh, hmm
<katco`> cherylj: i knew it was too good to be true =|
<cherylj> maybe the output from the unit test isn't displayed anymore
<cherylj> ?
<cherylj> 2016-07-13 16:08:45 DEBUG Waiting for trusty to finish
<cherylj> 2016-07-13 16:30:32 DEBUG trusty finished
<katco`> ...
<cherylj> 22 minutes seems reasonable
<katco`> i'm not sure how i feel about that...
<katco`> i guess if it succeeds you don't need the scrollback?
<cherylj> "reasonable"
<cherylj> yeah
<cherylj> dunno
<katco`> maybe we could at least put something there about "tests finished successfully"
<natefinch> we used to print out the packages running tests... I don't think there's any reason not to do that
<katco`> yeah
<katco`> maybe if the io was causing slowdown, but i don't think that was the case?
<cherylj> yeah, but if we're running multiple things in parallel, where would the output go?
<katco`> oh it does say ALL passed
<cherylj> I think we're just running trusty
<cherylj> abentley: for the new parallel merge job, where is the output from the parallel jobs logged?
<balloons> whart's our concern about the merge? The speed? The missing results in the console?
<cherylj> balloons: the missing results made me think it hadn't run
<abentley> cherylj: In the jenkins artifacts for the build.
<balloons> http://juju-ci.vapour.ws:8080/job/github-merge-juju/lastSuccessfulBuild/artifact/artifacts/trusty-out.log/*view*/
<katco`> balloons: i wasn't sure if the tests ran. i missed the "All passed, sending merge" which i assume is reerring to the tests?
<balloons> well, I guess I should link to your specific build: http://juju-ci.vapour.ws:8080/job/github-merge-juju/8403/artifact/artifacts/trusty-out.log/*view*/. But indeed they are there
<natefinch> balloons: any reason not to just put that right in the jenkins console output?
<cherylj> abentley: ah, got it
<abentley> natefinch: The reason for not doing that is because we are running 3 sets of tests at once, and outputting the all at the same time would be confusing.
<balloons> right. We could echo them to the console in order upon completion I suppose
<abentley> balloons: I would like to do that for failing tests.  I'm not sure it's desirable for successes.
<katco`> cherylj: did an email go out about this? looks like not everyone knew about the change?
<balloons> well desire is a funny thing. Developers might rather have the giant log.
<cherylj> katco: an email did go out
<abentley> katco`: Yes, I sent it to juju-dev: "Windows and --race tests are now gating"
<cherylj> katco: don't think it covered the change in the test output, maybe
<abentley> cherylj: It did.
<katco`> abentley: oh that one
 * cherylj is corrected :)
<katco`> abentley: must have missed that part
<katco`> abentley: ty
<cherylj> ha, we core devs are great about reading entire emails
<balloons> anyways, I guess it's good that you are concerned about potential failures -- most would be happy it landed, but you care enough to know how it did so as well
<balloons> kudos :-)
<natefinch> abentley: could we at least write links to the console so we don't have to try to figure out how to get to the artifacts from that page?
<katco`> cherylj: well i had thought i got the just of it: make sure your stuff works on windows :) i didn't expect additional information about log formatting in that chain
<cherylj> lol
<natefinch> katco`: ditto for me.  My bad for not reading the whole email.
<katco`> balloons: goal is definitely a stable product, not jfdi ;)
<abentley> natefinch: We could, but I would rather print out the logs for failures first, and then see if we still want it.
<natefinch> abentley: I'd like the links printed out always, and then print out failures.  The test output has a lot of very useful information in it... like test times etc.
<balloons> right, if you can adjust to the idea that no output is a "good thing", the output can become more usable and grokkable, as it will only ever have useful information of failures
<natefinch> balloons: no output = good is very dangerous.  no output can also mean "nothing ran"
<balloons> natefinch, well, you are getting a positive result back, so no output isn't literal
<natefinch> balloons: ideally I'd like something like this for each test run - Windows: SUCCESS   output: http://juju-ci.vapour.ws:8080/job/github-merge-juju/lastSuccessfulBuild/artifact/artifacts/trusty-out.log/*view*/
<natefinch> so, like, for example, it looks to me like the only thing we ran for this merge was trusty (so, no windows): http://juju-ci.vapour.ws:8080/job/github-merge-juju/8403/console
<balloons> I've no desires either way, but I can definitely see both sides
<balloons> the right amount of information at the right time should be the goal
<abentley> balloons: That is the only thing we ran.  We are temporarily kneecapped.
<abentley> natefinch: ^^
<natefinch> abentley: understood
<natefinch> abentley: for the record, I disagree with Ian.  The reason the tests on Windows don't pass is *because* we never make them gating.
<katco`> natefinch: we have a spectrum of folks on the team: ||-(jfdi we're so busy)------(do it perfect or not at all)-||
<abentley> natefinch: I'd say it's because CI failures don't block beta releases.
<katco`> natefinch: as always, the middle-way is preferable
<natefinch> abentley: I don't understand how we can ship anything, beta or not, if we know even one test is failing.  That means we *know* the product doesn't work.
<natefinch> I mean, I do understand. We assume we know better than the test and that it's not *really* a bug.
<natefinch> which is dangerous but also often true.
<abentley> natefinch: The rationale with the betas is more like "It's a beta, it's allowed to have flaws".
<katco`> abentley: natefinch: yes. and i think that direction comes from the top
<katco`> natefinch: also, lots of products in beta (and even not) come out with a list of "known issues"
<natefinch> I guess a bug with a failing test is better than a bug without one.... and we certainly have plenty of bugs without accompanying tests.
<mup> Bug #1602780 opened: "cannot allocate memory" errors on 2.0beta11 controller <juju-core:New> <https://launchpad.net/bugs/1602780>
<perrito666> bbl
<mup> Bug #1556137 changed: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement with maas 1.9.1 as provider <2.0-count> <oil> <juju-core:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1556137>
<mup> Bug #1600300 changed: [2.0 RC1] can't install lxd  - E: The value 'trusty-backports' is invalid for APT - daily fix hasn't been promoted to release <oil> <oil-2.0> <cloud-images:Invalid> <juju-core:Invalid> <MAAS:Invalid> <maas-images:New> <https://launchpad.net/bugs/1600300>
<bdx> hey whats up team? I've a few questions concerning network spaces on aws ...
<bdx> 1. Is juju capable/aware of pre-existing subnets/networks associated with the aws account?
<bdx> eeerrr ... * capable of using them, * aware that the networks exist
<bdx> 1.a By what method can I instruct Juju to use the pre-existing subnets, if the functionality exists?
<bdx> 2. Feature request if functionality doesn't exist?
<bdx> 2.a Where can I find the docs on this functionality if it does exist?
<bdx> can't seem to locate anything in juju's docs .. I know they are not complete ... guess I'm just hoping this is a thing ... anyone?
<natefinch> bdx: most of the network gurus are on European time
<natefinch> bdx: juju help add-subnet probably is what you want
<niedbalski_> perrito666, natefinch quick question; I am facing https://bugs.launchpad.net/juju-core/+bug/1449633, there is any way to modify the db for flagging the stuck machines as non-voting? because right now, if i try to terminate (--force) those machine juju claims that 'machine xxx is required by the environment'.
<mup> Bug #1449633: Cannot terminate/remove broken state server after ensure-availability <destroy-machine> <ensure-availability> <sts> <sts-needs-review> <juju-core:Triaged> <https://launchpad.net/bugs/1449633>
<natefinch> niedbalski_: rerunning ensure-ha should mark them as non-voting and eventually remove them
<mup> Bug #1556137 opened: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement with maas 1.9.1 as provider <2.0-count> <oil> <juju-core:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1556137>
<mup> Bug #1600300 opened: [2.0 RC1] can't install lxd  - E: The value 'trusty-backports' is invalid for APT - daily fix hasn't been promoted to release <oil> <oil-2.0> <cloud-images:Invalid> <juju-core:Invalid> <MAAS:Invalid> <maas-images:Confirmed> <https://launchpad.net/bugs/1600300>
<mup> Bug # changed: 1556137, 1594958, 1595360, 1600300
<natefinch> niedbalski_: it's possible this is an edge case that we can't recover from.  A replica never even being created due to lack of cloud availability is probably not something we have actively tested for.  I would hope that ensure-availability would do the right thing, but I can't be sure.
<niedbalski_> natefinch, I don't see any evident effect, they remain in error state; and machine 0 keep screaming this: machine-0: 2016-07-13 19:54:39 ERROR juju.worker runner.go:223 exited "firewaller": machine 31 not provisioned
<niedbalski_> natefinch, actually ha is working with another set of machines; but at the time we ran ensure-ha those machines failed to provision, now they are stuck in error state.
<perrito666> niedbalski_: natefinch nuking the machines wont do the trick?
<niedbalski_> perrito666, I would be more than happy to nuke them orelse flag them as non-voting and terminate those .. any trick?
<natefinch> niedbalski_: have you tried the same thing in 1.25?  We did make some fixes at some point, though I don't know if any of them would have fixed this problem.
<bdx> natefinch: oooh niceeee!  you da' man!
<perrito666> natefinch: not sure I have enough authority in the subject to confidently say to nuke something
<niedbalski_> natefinch, this is 1.25.5
<natefinch> niedbalski_: oh, sorry, the bug mentioned 1.20.  Well, good, sorta
<natefinch> niedbalski_: maybe try adding two new machines and doing ensure-availability --to x,y, where x and y are the new machines' numbers?
<niedbalski_> natefinch, yep, that's the way we got ha working; now the issue is to get rid of the machines that remain in error state.
<niedbalski_> 30         error                                    pending                                                        trusty
<niedbalski_> 31         error                                    pending                                                        trusty
<natefinch> niedbalski_: you might be stuck with them, unfortunately. It's probably worth a bug report to say that remove-machine --force should work if the server isn't even running yet (and/or is non-voting etc)
<natefinch> niedbalski_: you could, in theory, go hack the database, but it's not something I'd feel super comfortable about.
<niedbalski_> natefinch, understood, I'll fill an extra bug; I don't feel comfortable with hacking the database, but those stuck errored machines are driving me somehow crazy.
<natefinch> niedbalski_: make an alias for juju status that strips them out ;)
<niedbalski_> natefinch, lol .. yeah, probably I can mock the status output too.
<mup> Bug #1602838 opened: Charm upgrade should use bulk calls for whole model, not one per charm <juju-core:New> <https://launchpad.net/bugs/1602838>
<mup> Bug #1602840 opened: juju status (or equivalent) should show all addresses a machine has <network> <status> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1602840>
<frobware> anybody succesfully deploying LXD containers today? I ask because the download seems to stop at about 30% for me then nothing more.
<frobware> well, well... it may be something at my end as downloading latest from kernel.org also hangs at ~40%
 * frobware goes to bed and hopes the internet fairies sprinkle unicorns over his internet connection....
<mup> Bug #1598708 changed: juju use many DEPRECATED apis ,is there new juju version using the latest api? <juju-core:New> <https://launchpad.net/bugs/1598708>
<wallyworld> veebers: the latest log forward stuff has just landed, cpu issue hopefully fixed
<veebers> wallyworld: awesome, I'll give it a spin shortly
<wallyworld> hope it works :-)
<veebers> heh I'll let you know either way :-)
<arosales> hello juju-core devs :-)
<arosales> I am hitting a lxd perms issue
<arosales> http://paste.ubuntu.com/19316751/
<arosales> is there a work around for this?
<veebers> wallyworld: quick Q: what's the best way to get a models (i.e. the controller) uuid? I'll be using it to confirm the right log message appears in the rsyslog sink
 * arosales tried to reconfigure the network per https://jujucharms.com/docs/devel/getting-started but no luck
<arosales> hit this on beta7, beta10, and beta 11
<wallyworld> veebers: juju show-controller --format yaml should print the controller uuid i think
<veebers> wallyworld: cheers
<wallyworld> arosales: i've not seen that particular issue. thumper? ^^^^
 * thumper looks
 * arosales trying to clean up other containers to see if thats the issue
<thumper> ah... nope
<veebers> wallyworld: fyi that works, thanks
<wallyworld> veebers: awesome, thanks for testing
<veebers> wallyworld: oh sorry to mislead , that was re: show-controller. I'll have tested the cpu stuff soon :-P
<alexisb_> arosales, I have bootstraped several times on lxd in the last week (both from devel, beta7 and master) and not seen that issue
<arosales> alexisb_: on Z :-)
<alexisb_> ah ok
<arosales> ?
<alexisb_> that I have not done
<arosales> :-(
<alexisb_> :)
<alexisb_> arosales, someone on the QA team can provide details on system z tests in CI, maybe balloons
<alexisb_> if he is still around
<arosales> alexisb_: ok I see if any qa folks respond
<arosales> alexisb_: thanks
<arosales> got some z folks interested in a juju demo tomorrow and would like to show 20
<arosales> 2.0
<arosales> but . . . .the above error is a little bit of an issue
<arosales> luckily 1.25 is working
<alexisb_> arosales, looking at this we have many working lxd deploys on s390x: http://reports.vapour.ws/releases/4135/job/lxd-deploy-xenial-s390x/attempt/217
<alexisb_> arosales, not that that really helps for your specific issue
<arosales> alexisb_: well good to know that is has been working
<arosales> alexisb_: thanks for the information
<mup> Bug #1602885 opened: machine allocation failed due to maas error, but machines stay in pending state forever <oil> <oil-2.0> <juju-core:New> <https://launchpad.net/bugs/1602885>
<axw> wallyworld: it was a combination of my code and your code that caused the problem, so I eat my words
<wallyworld> we both suck :-)
<axw> wallyworld: the provider is using StateServingInfo, should be using ControllerConfig
<wallyworld> hmm, i thought it was using controller config, oh well
<axw> wallyworld: my change made it so that StateServingInfo is no longer populated when the Environ.Bootstrap call is made
<axw> wallyworld: I'm planning to make InstanceConfig write-only when I get some time, any input should be in StartInstanceParams
<wallyworld> ok
<thumper> menn0: http://reviews.vapour.ws/r/5167/diff/# updated
 * perrito666 is back
#juju-dev 2016-07-14
<veebers> wallyworld: fyi my initial test shows that the latest log forward changes has *fixed* the cpu/loop issue (wrt to logforwarding and what I saw previously)
<wallyworld> veebers: yay, ty
<axw> wallyworld: http://reviews.vapour.ws/r/5236/
<wallyworld> looking
<wallyworld> axw: lgtm, ta
<mup> Bug #1602895 opened: log forwarding sends all messages on enabling <2.0> <juju-core:Triaged> <https://launchpad.net/bugs/1602895>
<redir> This http://reviews.vapour.ws/r/5153/ is still longing for a shipit
<axw> thumper: probably not going to have time to review your pubsub stuff today, will try to get to it tomorrow if nobody else does in the mean time
<thumper> axw: that's fine, it isn't urgent
<axw> wallyworld: log forwarder test panicking: http://juju-ci.vapour.ws:8080/job/github-merge-juju/8407/artifact/artifacts/trusty-out.log/*view*/
<wallyworld> damn, i wonder why use of dying channel didn't prevent that
<natefinch> man, I really wish we'd stop using maps of name to struct everywhere... especially when the struct doesn't even contain the name :/
<thumper> natefinch: like where?
<natefinch> thumper: almost all the new cloud & credential stuff.  github.com/juju/juju/cloud.Cloud doesn't even have a Name field :/
<natefinch> thumper: cloud.Credential has no Name field.
<thumper> well, we know why
<thumper> actually...
<thumper> we could trivially add a Name in there with things like `yaml:"-"`
<thumper> which means don't serialize this value
<thumper> so the output stays clean
<thumper> and we could add them in when parsing
<thumper> just a thought
<natefinch> thumper: the fact that our internal data structures are being dictated by serialization formats is a bad thing
<thumper> it is a thing
<natefinch> hmm... bootstrap sometimes letting you use the provider name rather than the cloud name is sort of annoying
<natefinch> and by annoying, I mean confusing
<natefinch> juju bootstrap foo lxd works, juju bootstrap foo ec2 does not.
<natefinch> oops, heh... uh... wallyworld... bootstrapping lxd requires --upload-tools
<wallyworld> natefinch: i miss the point?
<wallyworld> also, lxd is a cloud name as well as a provider name
<natefinch> wallyworld: just that I was only doing interactive if the user specified no other flags... but then you can't do interactive with lxd, because you need to specify --upload-tools
<wallyworld> what happens if you don't?
<natefinch> this wonderful error: ERROR failed to bootstrap model: cannot start bootstrap instance: tools info mismatch ({2.0-alpha1-xenial-amd64  b67c1484745bd58e7fac6ad672a7f6e45042ebef7a1e0e995f3f0f3c2baa7d33 18556414}, {2.0-alpha2-xenial-amd64  ceb165a45206eddadc06a7c986b44a3f76195c71a317d0c87810727c71bcc0f8 18073871})
<wallyworld> that's a bug then
<wallyworld> upload-tools should not be required
<wallyworld> maybe the streams data is wrong
<natefinch> hmm... I was under the impression that unless you were running a released version of the client, you always had to use upload-tools... but maybe that was only true if you needed the dev jujud
<natefinch> I've just always used upload-tools
<wallyworld> ok, so from dev yes, you need upload tools
<wallyworld> but not for lxd in general
<wallyworld> thre same applies for other clouds
<natefinch> well right, and in this case, I don't care what binary the jujud uses
<wallyworld> i'd have to check the rules - but the client and agent versions generally need to match
<natefinch> that's probably what I'm hitting, yeah.  I guess that's ok.  It makes it a PITA to test though :)
<wallyworld> yes it does
<wallyworld> i just hack the juju version
<natefinch> well, the problem is that the code is checking for a command line that is just "juju bootstrap" and what I need it to also accept it "juju bootstrap --upload-tools" ... now the question is, do we want that to trigger interactive mode in production, or only as a hack for development?
<natefinch> ...and this is why I'd prefer to just have a flag for requesting interactive mode :D
<wallyworld> interactive mode is for when there are not enoug positional args
<wallyworld> axw: a small one http://reviews.vapour.ws/r/5237/
<natefinch> wallyworld: should I go into interactive mode even if they specify flags, then?
<wallyworld> yep
<wallyworld> when we talked yesterday, it was about missing positional args i think
<natefinch> wallyworld: ahh, ok, I misunderstood the spec, then.
<wallyworld> the spec was/is unclear
<wallyworld> i'm just giving my interpretation
<wallyworld> i think it makes sense
<wallyworld> althugh to start with, we could just limit interactive to no args or fags
<wallyworld> flags
<wallyworld> perhaps it's better to start out conseratively
<wallyworld> no args or flags
<wallyworld> but i can see that allowing --upload-tools and still doing interactive for no positional args would be desirable for dev
<natefinch> I hate that juju help constraints doesn't work anymore
<wallyworld> oh yeah, i wonder what happened
<natefinch> a ton of the "help topics" were stripped out.  I don't know why
<natefinch> also juju help placement... gone
<wallyworld> :-(
<natefinch> $ juju help topics
<natefinch> basics          Basic Help Summary
<natefinch> commands        Basic help for all commands
<natefinch> global-options  Options common to all commands
<natefinch> topics          Topic list
<wallyworld> natefinch: i have to duck out, but how about interactive for juju "juju bootstrap", maybe special case --upload-tools if it makes it easier for dev?
<natefinch> wallyworld: seems fine for now.  Hoestly, looking at the flags, there's almost no flags that would be a problem with interactive mode
<wallyworld> --credential would be
<wallyworld> as it doesn't make sense until you select a cloud
<wallyworld> so i reckon start simple
<natefinch> sure
<wallyworld> then we can get the basics done and iterate
<wallyworld> axw: i have to go to doctor, bbiab, if you review branch and i don't respond, i'm not ignoring you :-)
<veebers> wallyworld: re: logfwd, what's the expected behaviour when forwarding isn't on at bootstrap but is toggled later on the track? Are backdated logs sent or just from the toggle point onwards sent?
<veebers> I see it as an open question on that spec foc
<veebers> doc*
<axw> wallyworld: sorry I've had a very disrupted morning, looking now
<natefinch> wallyworld: well, first pass, needs a bunch more tests, but you can bootstrap interactively if you already have credentials, at least. https://github.com/juju/juju/pull/5797
<mup> Bug #1602935 opened: Juju 2.0 DB2 charm giving error while deployed using ZFS as storage backend   <juju-core:New> <https://launchpad.net/bugs/1602935>
<mup> Bug #1602952 opened: provider/azure: we should be checking "provisioningState" on entities before adding relationships <azure-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1602952>
<rogpeppe> jam: any chance you could take a look at http://reviews.vapour.ws/r/5166/ please? I'm just about to make some changes to that code and it would be much easier to work on the simpler version if you approve of it.
<axw> rogpeppe wallyworld: http://reviews.vapour.ws/r/5232/ -- this is ready for review now, I think this one could do with both 2 sets of eyes on it
<axw> fairly simple changes, but a lot of them
<wallyworld> ok
<rogpeppe> axw: is this what we've just been working on?
<axw> rogpeppe: yes
<axw> rogpeppe: it lacks migration at the moment, I'll work on that now
<rogpeppe> axw: ah, i'd say the PR description is a bit misleading then
<axw> rogpeppe: bleh, I updated the commit message but not the description
<axw> fixing
<rogpeppe> axw: it's quite a bit more than "allow empty username"
<axw> rogpeppe: updated, I hope that's a bit better
<rogpeppe> axw: s/rejiggered/rejigged/ ?
<rogpeppe> axw: otherwise, looks good
<axw> rogpeppe: apparently rejigger is an americanism, I've been infected
<rogpeppe> axw: ha, and apparently "rejig" is a britishism
<rogpeppe> axw: so rejigger looks fine - i just hadn't seen it before
<axw> rogpeppe wallyworld: one bit of ugliness this change exposes: when you logout, any memory of what your current model is wiped; then when you login you have to set your current model again
<rogpeppe> axw: that didn't happen before?
<axw> rogpeppe: nope, we weren't ever wiping info from models.yaml on logout before. so you could logout as admin, login as bob, and admin's current-model will still be in models.yaml
<rogpeppe> axw: ah, of course, because "current-account" was separate
<axw> it won't be *used*, but it'll be there
<axw> then if you logout and log back in, you'll be back on the same
<wallyworld> hmm, that may be ok perhaps? if there's no current model, we prompt right?
<rogpeppe> axw: hmm, why are we wiping info from models.yaml now?
<axw> rogpeppe: because now models.yaml is entirely linked to the logged in user
<axw> wallyworld: we tell the user what to do ("Please use "juju models" ... and "juju switch")
<wallyworld> axw: maybe if there's just the one model we should switch automatically
<rogpeppe> axw: perhaps the current model info should include both username and model name
<rogpeppe> axw: otherwise there's no way to be switched to a model that's under a different username, right?
<axw> rogpeppe: that'll be part of the model name, when I update/land my other change: i.e. current-model will have the format "modeol-owner/model"
<rogpeppe> axw: ah, in which case the problem you mention above won't happen, right?
<rogpeppe> axw: because models.yaml won't be linked to the logged in user
<axw> rogpeppe: I guess, if we want to say that current-model doesn't change between users
<axw> rogpeppe: that seems a bit odd to me though
<rogpeppe> axw: i think it's better than wiping it
<axw> maybe it's ok
<axw> yeah, probably
<axw> alright, I'll just take out the code that wipes models.yaml for now then
<rogpeppe> axw: i think that it would be surprising if i couldn't log out, then log back in to the same model
<rogpeppe> axw: 'cos logged in user is almost entirely orthogonal to what model's currently being used.
<wallyworld> rogpeppe: what happens if i log back in and new user can't access model?
<rogpeppe> wallyworld: then you'll get permission denied
<rogpeppe> wallyworld: seems better than just forgetting it always
<wallyworld> seems reasonable i think
<wallyworld> axw: changes look ok to me, if rogpeppe is happy that it solves his problem and allows beta12 this week to fit their requirements
<rogpeppe> wallyworld: it doesn't solve the problem in itself, but it lays the groundwork for solving it
<frobware> dooferlad, voidspace, babbageclunk: PTAL @  http://reviews.vapour.ws/r/5235/ and http://reviews.vapour.ws/r/5234/
<rogpeppe> wallyworld: and it seems like a good change in general
<axw> rogpeppe: well you can craft a file, like you could before. there are more changes due of course tho
<wallyworld> rogpeppe: agreed, sorry i just meant that it unblocks you
<rogpeppe> axw: have you tried crafting a file with these changes in place?
<rogpeppe> axw: i'm not sure if it'll work
<axw> rogpeppe: yes, it does. I don't have an idm to test with, but I verified that it tried to connect without a user/pass
<rogpeppe> axw: you do have an idm to test with
<rogpeppe> axw: identity-url: https://api.jujucharms.com/identity
<axw> okey dokey
<voidspace> frobware: can take a look
<voidspace> frobware: I still need a full review on http://reviews.vapour.ws/r/5162/ :-p
<voidspace> frobware: in the first one, was prefix already unused by all those methods?
<voidspace> looks like it
<frobware> voidspace: yes - was tidying up
<voidspace> frobware: cool
<voidspace> that first one is nice and easy
<voidspace> frobware: LGTM
<frobware> voidspace: will look at your PR after standup
<voidspace> cool
<voidspace> I'm looking at your second one
<voidspace> frobware: I wish we could encapsulate all this in a general purpose library
<voidspace> frobware: it's extremely precious knowledge
<frobware> voidspace: yes, it has got to that stage now. It's quite different from the original sed script we started with.
<voidspace> frobware: second one LGTM as well - modulo the comment from babbageclunk
<frobware> voidspace: thanks
<jam> rogpeppe: looking
<rogpeppe> jam: thanks a lot
<jam> rogpeppe: so does it still try the first one and then with a delay try the rest?
<rogpeppe> jam: it still tries all the addresses
<rogpeppe> jam: it just doesn't fall back to the bootstrap config (provider-specific) connection
<jam> sure, but I thought the parallel try was the thing that did it, but that got removed if I'm reading the diff correctly.
<rogpeppe> jam: no, there are two levels of parallel tries
<rogpeppe> jam: the API connection code also does it
<rogpeppe> jam: the Try in the top level connection was entirely for the bootstrap config fallback
<frobware> babbageclunk: sync?
<babbageclunk> frobware: oh, torry
<babbageclunk> sorry
<jam> ah good
<urulama> wallyworld: could you give your +1 on http://reviews.vapour.ws/r/5232/ if it's ok? or if not, to fix it before beta12?
<axw> wallyworld: nearly forgot about this one https://github.com/juju/romulus/pull/52
<jam> rogpeppe: lgtm
<rogpeppe> jam: thanks!
<axw> rogpeppe: I've added migration code to my PR, and dropped the code that was wiping models.yaml. should be good to go once it's stamped
<rogpeppe> axw: ah, i'll take another look
<rogpeppe> axw: added a couple more review comments
<axw> rogpeppe: I think adding a test is a waste of time. I've manually tested it, and the code will be deleted as soon as the beta is out (which is imminent)
<rogpeppe> axw: fair enough, just a thought
<rogpeppe> axw: as long as you've actually run the code :)
<axw> rogpeppe: thanks. yeah I did, it was broken the first two times :p
<rogpeppe> axw: BTW ignore my first comment (sorry, can't work out how to reply on reviewboard) - i hadn't realised the lines moved between types.
<axw> rogpeppe: no worries - it's not super clear. thanks
<axw> rogpeppe: I'm going to look at temporarily disabling the romulus dependency to break the cycle
<rogpeppe> axw: what do you mean by "disabling the dependency" ?
<axw> rogpeppe: well, just stop importing the commands actually
<rogpeppe> axw: the "push temporary branch" thing works pretty well actually
<rogpeppe> axw: wait until you've got a LGTM on both romulus and the juju-core branch before doing it though
<rogpeppe> axw: and means you don't need to change the code at all
<axw> rogpeppe: how does one push a temporary branch? don't I need to be able to write to master?
<rogpeppe> axw: you'll need the capability to make new branches in romulus
<rogpeppe> axw: you can ask ashipika1 to do it if you can't
<axw> rogpeppe: which I don't have. I think I'll have to come back later, I think ashipika1 has gone back offline
<axw> need a review first anyway
<ashipika1> axw: who is offline?
<axw> ashipika1: or not :) I just saw you're offline on canonical
<axw> err
<ashipika1> axw: ah, who know.. i have a probabilistic internet connection..
<axw> not even there, my IRC client is telling lies
<ashipika> axw: you need a feature branch?
<axw> ashipika: yes please
<ashipika> axw: pick a name, please :)
<axw> ashipika: modelcmd-no-account
<ashipika> axw: done
<ashipika> axw: enjoy :)
<axw> ashipika: ta
<axw> ashipika: I'm not going to be able to push to that though am I? can you please push my change over there.
<ashipika> axw: https://github.com/juju/romulus/pull/53  ?
<axw> ashipika: yes, but the lander's not going to like it because juju/juju's API changed
<ashipika> axw: shall i (ab)use the green button?
<axw> ashipika: ah, if you have that then yes please
<ashipika> axw: done :)
<axw> ashipika: thanks
<rogpeppe> jam: do you think that https://github.com/juju/juju/pull/5719 can land even though it doesn't fix one of the blocking critical bugs?
<jam> rogpeppe: I would check with Cheryl about that more than myself. If they are trying to stabilize this is more likely to cause a regression than others
<rogpeppe> jam: fair enough. FWIW it does fix at least one bug I've seen recently, just not any of the critical blockers.
<rogpeppe> jam: and if it doesn't land, getting branches that depend on it landed for beta12 might be hard.
<frobware> voidspace: still owe you your review - sidetracked...
<rogpeppe> trivial dependency update anyone (stops juju-core depending on an external feature branch)? https://github.com/juju/juju/pull/5798
<frobware> babbageclunk: could you take another look over http://reviews.vapour.ws/r/5235/
<babbageclunk> frobware: LGTM
<frobware> rogpeppe: just the one question, see RB
<mup> Bug #1603060 opened: upgrade-charm arguments don't support tilde expansion <juju-core:New> <https://launchpad.net/bugs/1603060>
<rogpeppe> frobware: thanks
<rogpeppe> frobware: i just replied
<rogpeppe> frobware: it seems that it was a left-over dep
<rogpeppe> frobware: unless you can find somewhere where that package is used
<frobware> rogpeppe: Was just (trying to) being diligent. Wanted to ensure that it was not accidental.
<rogpeppe> frobware: yeah, it made me think again too
<frobware> dooferlad: one for you - https://c9.io/blog/great-news/
<frobware> dooferlad: you'll get bugs faster with prime! :)
<dooferlad> frobware: I need coffee, but I would also like to talk through our current LXD bugs. Can you join a hangout in ~5 minutes?
<frobware> dooferlad: yep
<dooferlad> frobware: team hangout?
<frobware> yep
<frobware> dooferlad: http://reviews.vapour.ws/r/5040/
<frobware> dooferlad: https://bugs.launchpad.net/juju-core/+bug/1566801
<mup> Bug #1566801: LXD containers /etc/network/interfaces as generated by Juju  gets overwritten by LXD container start <cdo-qa-blocker> <landscape> <network> <juju-core:In Progress by frobware> <https://launchpad.net/bugs/1566801>
<frobware> dooferlad: https://bugs.launchpad.net/juju-core/+bug/1600546
<mup> Bug #1600546: lxd subnet setup by juju will interfere with openstack instance traffic <network> <sts> <juju-core:Triaged> <nova-compute (Juju Charms Collection):New> <https://launchpad.net/bugs/1600546>
<alexisb__> dooferlad, sorry, I have a conflict
<dooferlad> frobware: not in a meeting if you want to talk again.
<frobware> dooferlad: need to resolve my conflict on my other PR first
<dooferlad> frobware: sounds good
<mup> Bug #1559299 opened: cannot obtain provisioning script <bootstrap> <ci> <manual-provider> <regression> <xenial> <juju-core:Triaged> <juju-core 1.25:Fix Committed by anastasia-macmood> <juju-core api-call-retry:Fix Released by axwalk> <https://launchpad.net/bugs/1559299>
<rogpeppe> anyone got an idea what the failure is here, and whether it has anything to do with the branch being landed? http://juju-ci.vapour.ws:8080/job/github-merge-juju/8414/console
<rogpeppe> mgz, sinzui: ^
<rogpeppe> i've tried again in hope that it's just a sporadic infrastructure failure
<mgz> rogpeppe: looking
<rogpeppe> mgz: t
<rogpeppe> mgz: ta, even
<mgz> rogpeppe: see trusy-err.log
<mgz> rogpeppe: juju/api_test.go:132: undefined: noBootstrapConfig
<rogpeppe> where can i see that file?
<mgz> rogpeppe: juju/api_test.go:132: too many arguments in call to newAPIConnectionFromNames
<mgz> it's in the job artifacts
<mgz> so, up one level from /console
<mgz> at the top of the page
<mgz> we're still looking at making this output clearer than it is at present
<rogpeppe> mgz: ah, so you don't see test failures in the console output any more.ir
<mgz> just for now. they should be there again at some point.
<rogpeppe> what a great failure mode the IRC client has - if you're typing under heavy load, the input box goes into a state where text comes out randomly
<natefinch> rogpeppe: I've seen that.  not sure if it's IRC or linux
<rogpeppe> natefinch: i blame the app
<rogpeppe> mgz: it's in trusty-out.log, not trusty-err.log
<mgz> rogpeppe: both have revelent things
<rogpeppe> mgz: oh yeah
<mgz> splitting them is actually a little confusing
<rogpeppe> mgz: it's really hard to see the pertinent data in trusty-err.log
<mup> Bug #1559299 changed: cannot obtain provisioning script <bootstrap> <ci> <manual-provider> <regression> <xenial> <juju-core:Triaged> <juju-core 1.25:Fix Committed by anastasia-macmood> <juju-core api-call-retry:Fix Released by axwalk> <https://launchpad.net/bugs/1559299>
<mgz> rogpeppe: yep
<rogpeppe> mgz: can you monitor the build artifacts in real time like the console log?
<rogpeppe> mgz: i find it really useful to see a test error before all the tests have completed
<mgz> rogpeppe: nope, that's another problem with parallel setup at present
<mup> Bug #1559299 opened: cannot obtain provisioning script <bootstrap> <ci> <manual-provider> <regression> <xenial> <juju-core:Triaged> <juju-core 1.25:Fix Committed by anastasia-macmood> <juju-core api-call-retry:Fix Released by axwalk> <https://launchpad.net/bugs/1559299>
<rogpeppe> mgz: is there any way to abort a jenkins run that's already started?
<rogpeppe> mgz: i know this one's gonna fail and i've fixed the issue already http://juju-ci.vapour.ws:8080/job/github-merge-juju/8417/
<mgz> there is, but the safest way is to ask me
<mgz> okay, I can do that
<rogpeppe> mgz: please, martin, could you? :)
<rogpeppe> mgz: thanks
<babbageclunk> So, looking at bug #1602192 - why might systemctl be reporting that / didn't mount, when it's definitely available?
<mup> Bug #1602192: deploy 30 nodes on lxd, machines never leave pending <lxd> <juju-core:In Progress by 2-xtian> <https://launchpad.net/bugs/1602192>
<frobware> babbageclunk, dooferlad, voidspace: can you take another look over http://reviews.vapour.ws/r/5234/. My other PR gave me a few conflict so had to rebase.
<mup> Bug #1600237 changed: ErroredUnit: 0 is in state cannot complete machine configuration: model configuration has no authorized-keys <deploy> <regression> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1600237>
<babbageclunk> frobware: lgtm
<rogpeppe> anyone got any idea why a controller-only login doesn't send userinfo back in the response?
<rogpeppe> apiserver/admin.go:150: 	if isUser && !serverOnlyLogin {
<voidspace> frobware: still need that review?
<frobware> babbageclunk: actually, yes. just to be on the safe side as there were quite a few conflicts
<frobware> voidspace: that ^ was supposed to go to you :)
<babbageclunk> frobware: I already did! :)
<frobware> babbageclunk: the bridgescript.go is back - another push fixed that. was lost in my conflict resolution
<voidspace> frobware: ok
<frobware> oh, interesting. last 12-24 hours no $(juju add-machine lxd:0) on MAAS 1.9. Just tried MASS 2.0 and it worked. Coincidence? Or is 1.9 broken?
<mup> Bug #1603133 opened: Application Get api call doesn't return deployed series for multi-series charms <juju-core:New> <https://launchpad.net/bugs/1603133>
<voidspace> frobware: a couple of minor issues - but feel free to drop them if you don't think it's worth it
<babbageclunk> frobware: I guess I should really have opened an issue for that.
<frobware> voidspace: const as in some constant list someplace?
<frobware> voidspace: I was trying for locality; in some case we remove mtu, in other mtu+others.
<voidspace> frobware: I meant the same as you do for BRIDGE_OPTIONS
<voidspace> frobware: but if you don't feel it aids readability then feel free to drop it
<mup> Bug #1603133 changed: Application Get api call doesn't return deployed series for multi-series charms <juju-core:New> <https://launchpad.net/bugs/1603133>
<frobware> voidspace: yep, but chatted with babbageclunk about this earlier. Didn't want the constant to be updated (in some future change) without really understanding the implication, hence the locality
<voidspace> ok
<frobware> voidspace: regarding performance, ... don't think it's an issue here
<frobware> voidspace: this script will only ever run once
<voidspace> heh
<voidspace> I just like to see the *right* data type used...
<voidspace> but I don't really care
<voidspace> it's not an optimisation it's a semantic correction
<frobware> voidspace: and as long it is the same in python 2 & 3 I'm happy to change it
<voidspace> it's an unordered collection not a sequence
<voidspace> frobware: it is
<voidspace> just wrap a set constructor round it
<frobware> voidspace: given the nature of this code anything I don't have to change make me delirious.
<voidspace> :-)
<voidspace> up to you, it's such a minor detail
<frobware> voidspace: in a follow-up, sure. but have been testing it as-is so don't want to start over (though I cannot believe it would be an issue)
<frobware> voidspace: but thanks anyway
<mup> Bug #1603133 opened: Application Get api call doesn't return deployed series for multi-series charms <juju-core:New> <https://launchpad.net/bugs/1603133>
<frobware> voidspace: as in http://pastebin.ubuntu.com/19376777/ ?
<babbageclunk> voidspace, frobware: no, just write {'address', 'gateway'...}
<frobware> babbageclunk: yep, done already. :)
<frobware> babbageclunk: http://reviews.vapour.ws/r/5234/diff/4-6/
<babbageclunk> frobware: I've already clicked Ship It twice on that. I think it looks good!
<frobware> babbageclunk: yep. thanks. was just confirming my SET LITERAL! :)
<babbageclunk> frobware: :)
<natefinch> super easy review anyone? http://reviews.vapour.ws/r/5242/diff/#
<natefinch> cherylj: ^ ?
<frobware> natefinch: reviewed
<natefinch> frobware: thanks!
<natefinch> alexisb__: I have a fix for hatch's bug, should I mark it critical and submit it, or... ?
<alexisb__> yes please
<hatch> ooo critical :)
<hatch> thanks natefinch
<natefinch> hatch: welcome.
<natefinch> hatch: luckily it was as easy as it looked :)
<hatch> haha great!
<perrito666> we are spoiling hatch, he got 2 bugs in a week
<hatch> LOL
<hatch> maybe I just work on important stuff ;)
<urulama> no worries. he's spoiled already.
<urulama> :)
<hatch> hahahaha
<perrito666> hatch: nah, you are using some of these canadian superpowers of yours
<hatch> a well placed "sorry" goes a long way
<perrito666> nonsense, witchcraft I say
<hatch> lol
<urulama> hatch: do keep an eye on that branch and test it with gui when it lands, please, just in case to catch the beta12 train with any last changes
<urulama> i'm sure it'll be fine though
<hatch> urulama: yep will do!
<urulama> ty
<cherylj> natefinch: just fyi - for bug 1603133 , you'll also need to give it the blocker tag to use the fixes-1603133$$
<mup> Bug #1603133: Application Get api call doesn't return deployed series for multi-series charms <juju-core:In Progress by natefinch> <https://launchpad.net/bugs/1603133>
<cherylj> sigh, missed the first $$.  But whatevs
<hatch> natefinch: just wanted to point out that https://github.com/juju/juju/pull/5801 failed building
<cherylj> hatch: retrying...
<hatch> great
<mup> Bug #1578059 opened: Default route not coming up with juju 1.25.5 and bonding <canonical-bootstack> <juju-core:New> <MAAS:Incomplete> <MAAS 1.9:Incomplete> <https://launchpad.net/bugs/1578059>
<natefinch> cherylj, hatch: thanks
<natefinch> it's so much more nerve wracking watching jenkins now...
<natefinch> there's no play by play update, you just have to wait for the newspaper in the morning to tell you if your team won or lost
<hatch> haha
<perrito666> natefinch: oh? what changed?
<natefinch> perrito666: we're running multiple unit tests in parallel (well, in theory, I think right now, multiple == 1), and so they can't/don't update the jenkins console output with the test output.  It's only when the test run is done that the test output is linked to by the jenkins job page
<natefinch> perrito666: so like, here, the tests are running, but you don't get real-time output of go test anymore: http://juju-ci.vapour.ws:8080/job/github-merge-juju/8421/console
<katco> cherylj: maybe we should send out another email on this =|
<natefinch> heh yeah, seems like everyone missed that little caveat at the end
<perrito666> at least I did
<natefinch> this is like when they try to slip in some bad news behind an otherwise banal headline:
<natefinch> Pokemon go now accepts bitcoin!
<natefinch> áµá¶«Ë¢áµ á´¼áµáµáµáµ Ê°áµË¢ áµáµá¶á¶«áµÊ³áµáµ áµáµÊ³Ë¢Ê°áµá¶« á¶«áµÊ·
<perrito666> pokemon accepting bitcoin is not banal, check your priorities dude
<natefinch> haha
<natefinch> TestResumeTransactionsFailure failed... yay
<natefinch> whelp. half hour of the test machine's time wasted.  Let's retry
<mup> Bug #1603176 opened: juju debug-log returns not logged-error <juju-core:New> <https://launchpad.net/bugs/1603176>
<mup> Bug #1603176 changed: juju debug-log returns not logged-error <juju-core:New> <https://launchpad.net/bugs/1603176>
<perrito666> redir: ping?
<redir> pong
<redir> perrito666:
<perrito666> redir: was it remove user you where working on?
<mup> Bug #1603176 opened: juju debug-log returns not logged-error <juju-core:New> <https://launchpad.net/bugs/1603176>
<perrito666> if so, did that ever land?
<redir> perrito666: yup
<redir> nope
<perrito666> ah, ok, tx :) ill stop looking for it then :p
<redir> perrito666: http://reviews.vapour.ws/r/5153/ I think the shipit button is broken or something;)
<redir> I am trying to parse the latest review.
<redir> the client side bits are just waitin for it
<redir> perrito666: ^^
<perrito666> redir: oh I can't hear you, I am entering into a tunnerl, shh shh <toot><toot><toot>
<redir> :)
<redir> I think we're really close
<natefinch> hatch: fix committed :)
<alexisb__> thank you natefinch
<alexisb__> redir, how are you feeling?
<hatch> natefinch: thanks!
<mup> Bug #1593850 changed: Deployment stuck in "Pending" for all containers <cdo-qa> <cdo-qa-blocker> <juju-core:Invalid> <https://launchpad.net/bugs/1593850>
<redir> alexisb__: meh. Still drugged up. If I don't feel better by the weekend I'll go to the doc next week.
<mup> Bug #1603202 opened: kill-controller didn't do anything <juju-core:New> <https://launchpad.net/bugs/1603202>
<mup> Bug #1603202 changed: kill-controller didn't do anything <juju-core:New> <https://launchpad.net/bugs/1603202>
<rick_h_> redir: did you catch my cold?
<mup> Bug #1603202 opened: kill-controller didn't do anything <juju-core:New> <https://launchpad.net/bugs/1603202>
<redir> rick_h_: caught something somewhere.
<redir> nose,ears,throat. Hopefully it'll be gone soon. I got a decent night sleep after a delayed flight. Another good night and I hope to report I'm on the upswing.
<mup> Bug #1603208 opened: (Windows unit test) ConfigSuite.TestConfigNonExistentPath failure in config_test.go <blocker> <ci> <unit-tests> <windows> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1603208>
<mup> Bug #1603208 changed: (Windows unit test) ConfigSuite.TestConfigNonExistentPath failure in config_test.go <blocker> <ci> <unit-tests> <windows> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1603208>
<mup> Bug #1603208 opened: (Windows unit test) ConfigSuite.TestConfigNonExistentPath failure in config_test.go <blocker> <ci> <unit-tests> <windows> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1603208>
<mup> Bug #1602192 changed: deploy 30 nodes on lxd, machines never leave pending <lxd> <juju-core:Invalid by 2-xtian> <lxd (Ubuntu):New> <https://launchpad.net/bugs/1602192>
<mup> Bug #1602192 opened: deploy 30 nodes on lxd, machines never leave pending <lxd> <juju-core:Invalid by 2-xtian> <lxd (Ubuntu):New> <https://launchpad.net/bugs/1602192>
<mup> Bug #1602192 changed: deploy 30 nodes on lxd, machines never leave pending <lxd> <juju-core:Invalid by 2-xtian> <lxd (Ubuntu):New> <https://launchpad.net/bugs/1602192>
<mup> Bug #1603221 opened: Charms utilizing storage fail on LXD <juju-core:New> <https://launchpad.net/bugs/1603221>
<wallyworld> rick_h_: we are still in release standup, running a bit late
<rick_h_> wallyworld: ah ok ty for heads up
<wallyworld> we didn't abandon you :-)
<rick_h_> ...yet :p
<mup> Bug #1603228 opened: Juju does not support simplestreams for Azure-ARM <azure-provider> <simplestreams> <streams> <juju-core:Triaged> <https://launchpad.net/bugs/1603228>
<wallyworld> niemeyer: hey, we want to use the latest and greatest mgo stuff in juju for beta12 (with the E1100 fix). but the fix is landed in a v2-unstable branch and so that now means a lot more than a godeps update to get it in. is there any chance you can merge the work to the v2 branch?
#juju-dev 2016-07-15
<niemeyer> wallyworld: No, unfortunately I can't do a release today. This needs to be prepared and announced as usual, and it's not a good idea to do that on a Friday before leaving for a sprint
<wallyworld> niemeyer: ok. we have have to release beta12 today/tomorrow to we'll need to deal with it
<wallyworld> s/to/so
<niemeyer> wallyworld: Sorry about that, but I really can't risk compromising everybody else with a broken release when I'm not going to be around for days to fix it
<wallyworld> niemeyer: totally understand. i think the CI guys are looking at a workaround
<marcoceppi> is there a limit on the size of a local resource I can deploy with beta11?
<marcoceppi> nevermin,d just took a hot min
<niemeyer> wallyworld: Note the code can actually import from mgo.v2-unstable
<niemeyer> wallyworld: That may be the easiest
<wallyworld> niemeyer: sure, but that means churn just to change all the import paths
<niemeyer> wallyworld: ... which is a trivial mechanical change, right?
<wallyworld> it is. and then we change back again next week or whenever. that bit about Go is annoying to say the least
<axw> wallyworld: http://reviews.vapour.ws/r/5244/ - trivial fix for windows failure
<wallyworld> ok
<wallyworld> axw: lgtm
<thumper> niemeyer: except it is a "trivial mechanical change" across 10 different repos
<alexisb__> so thumper, wallyworld are we all good for release except for dep updates for the mgo fix?
<alexisb__> can one of you please send a summary to balloons and myself
<thumper> alexisb__: I'm not sure if we even need to do the dep update
<thumper> if the release process can pull over the branch
<alexisb__> thumper, understood
<wallyworld> alexisb__: as per my email i am expecting what tim said
<alexisb__> I want to make sure that is clear to all
<alexisb__> what is being requested
<wallyworld> i asked nic/martin to confirm in the email
<alexisb__> wallyworld, thumper I sent a clarification email just in case :)
<alexisb__> please take a look and add comentary/corrections if neccisary
<wallyworld> alexisb__: thanks. let's hope we get the answer we are looking for. we need a jedi mind trick
<niemeyer> thumper: A trivial mechanical change across "10 repositories" (doubt it) is still a trivial mechanical change. It'd be done by now.
<thumper> you doubt that we have that many that depend on mgo?
<thumper> really?
<niemeyer> Yeah, I doubt that a juju release has to build 10 independent repositories that all depend on mgo.. will be surprised, honestly.
<thumper> not build 10, but there are ~10 external repos that juju/juju depends on that also bring in mgo
<thumper> all those would also need to change, no?
<thumper> luckily we have a smart releast team that have worked a way for us not to bother
<thumper> but yes, changing imports is invasive
<niemeyer> I don't know.. depends on how you organize your code I guess. I'm just saying I'm surprised if that's the case, as I try not to do that.
<thumper> sure... whatever
<niemeyer> It still a mechanical change though, which I bet takes less typing than we've done thus far.
<niemeyer> I bet your release team very far surpasses the necessary skills to do that.
<thumper> no... we are working around it so we don't have to
<thumper> yes, their skill far surpasses what is needed to rename shit
<niemeyer> That's good to hear .. nobody wants stuff named shit.
<natefinch> wallyworld, thumper: btw, you can cheat with godeps and still be importing gopkg.in/mgo.v2 but pin a revision from v2-unstable.  That way, only the dependencies.tsv file needs to change. It's a hack, but it works and doesn't cause a ton of churn.
<wallyworld> natefinch: interesting, i didn't realise we could do that
 * thumper wonders about the nested packages
<natefinch> yeah, godeps is a handy little hack... it doesn't care about branches at all, so as long as the revision is in the git repo, godeps can point the local code at it.
<thumper> natefinch: https://github.com/go-mgo/mgo/blob/v2-unstable/session.go
<thumper> natefinch: still impots from v2-unstable
<thumper> so not sufficient
<natefinch> thumper: oh, yeah, that won't work
<natefinch> crud
<natefinch> I've done it with feature branches, but they weren't hard coded in the import statement.  That does make it basically impossible
<mup> Bug #1570594 changed: read access to admin model allows grant <docteam> <juju-release-support> <juju-core:Fix Released by thumper> <https://launchpad.net/bugs/1570594>
<thumper> natefinch: however we can specify the revision that was the tip of babbleclunk's branch
<natefinch> thumper: sounds like it could work
<thumper> jam: ping
<thumper> jam: unping
<wallyworld> axw: i've updated the mgo dep, will fix mgo issue in beta12 http://reviews.vapour.ws/r/5245/
<wallyworld> jam: so as axw pointed out, the above PR won't work because code in gopkg.in/mgo.v2 imports from gopkg.in/mgo.v2-unstable. wtf
<axw> wallyworld: gopkg.in/mgo.v2-unstable/txn imports gopkg.in/mgo.v2-unstable
<axw> the commit you're pointing at is from the unstable branch
<wallyworld> yes, but i thought i was following the advise that we just hack the commit sha in deps.tsv
<wallyworld> which won't work will it
<axw> nope
<wallyworld> so no choice other than to vendor if we want beta12 out
<axw> wallyworld: we build with go 1.6 now, so that would be the least amount of work I think
<axw> wallyworld: take it or leave it, but this works: https://github.com/juju/juju/pull/5805
<wallyworld> looking
<wallyworld> axw: hmmm, seems like now we will just be double handling everything. commit to the upstream repo and copy all the files to the vendored package. i'm -1 on it, so best you get jam or someone to +1
<wallyworld> unless there's something i don't get
<axw> wallyworld: how's that worse than committing to upstream, copying to juju namespace?
<wallyworld> now we commit to upstream and update dependencies.tsv
<wallyworld> one small change to juju/juju
<axw> wallyworld: in other words, what are you going to do if you don't want to merge this
<axw> wallyworld: this doesn't have to live beyond beta12
<wallyworld> seems like a huge change just for one beta, but i guess it's just copying files
<wallyworld> the other alternative is just to update the import paths to v2-unstable
<axw> wallyworld: copying a bunch of files into one temporary location, vs. changing files over all our repos
<wallyworld> fair point. it can be reversed after beta ships
<wallyworld> although we'd just need to change import paths in juju/juju
<axw> wallyworld: nope. blobstore takes mgo.v2, we pass into it from juju
<axw> likewise for juju/txn I think
<wallyworld> sure, but blobstore has no depencencies.tsv
<wallyworld> ah
<wallyworld> but yeah import paths
<wallyworld> either way it's a mess
<wallyworld> axw: so maybe it's the only viable option, but cut you get a +1 from william or john just to be sure?
<axw> wallyworld: sure
<axw> I think will is out
<axw> jam: are you about?
<axw> away on IRC at any rate
<wallyworld> axw: here's a quickee fix for a critical restore bug http://reviews.vapour.ws/r/5247/
<wallyworld> the main issue is now gone since rog deleted failback connect
<axw> wallyworld: why change it to use ControllerByName first?
<wallyworld> axw: i wanted to reuse existing cloud / region
<axw> wallyworld: if you rebootstrap with a mismatched cloud/region, it'll be terribly broken anyway
<wallyworld> ah yeah, that is true
<wallyworld> i'll revert that bit
<jam> axw: wallyworld: I thought we could point to babbageclunk's revision as well
<jam> which was written against mgo.v2 so shouldn't be importing mgo.v2-unstable
<jam> thumper mentioned a revision
<axw> jam: dependencies.tsv does not separate repo from package path
<axw> so you can't say get babbageclunk's repo, and call it gopkg.in/mgo.v2
<axw> wallyworld: in your PR, I meant a test for the thing that broke in the first place
<axw> wallyworld: I didn't see a test added
<wallyworld> axw: the thing that broke was in api connect code that was deleted
<axw> wallyworld: that was the trigger, but you still fixed a bug?
<wallyworld> yeah, i could add a check for the order of updating controller info
<wallyworld> i'll do that
<jam> axw: because the revision is in the repository that also holds gopkg.in/mgo.v2 godeps will let you use it
<jam> axw: anything revision that is in the upstream repository is a potential target for godeps
<jam> I tried it with aee6a64 to confirm
<jam> though that would suffer from the import problem
<axw> jam: babbageclunk's most recent commit has the -unstable import paths
<axw> it wasn't done as a separate merge step
<wallyworld> axw: test done, will propose once merge finishes
<axw> wallyworld: thanks
<wallyworld> i should have done it in the first place
<jam> axw: well that sucks
<wallyworld> axw: and here's the test http://reviews.vapour.ws/r/5248/
<wallyworld> jam: so we either (temporarily) vendor as axw has proposed or we update import paths in juju/blobstore, juju/txn and juju/juju
<axw> wallyworld: LGTM, thanks
<wallyworld> ta
<jam> wallyworld: if we vendor we have to update everything don't we? the discussion with mgz yesterday was that we might be able to add an "apply this patch" as part of the 'make-release-tarball.sh' script
<wallyworld> jam: yeah, that's my issue with vendoring. axw has done the PR - it's huge. but the current thinking is this will be just for this beta. the changes to core are trivial. 99.99% of the PR is copying in the files of all the deps
<wallyworld> the alternative is to churn the necessary dependent repos and then update core also
<wallyworld> with the new import paths
<axw> wallyworld jam: to be up front, I would like it to be there for good, and I'll make my argument for that later. but we don't *have* to have it for good
<wallyworld> axw: if it is there for good, my issue is the double handing of every dependent repo update
<axw> wallyworld: please let's talk about that later :)
<wallyworld> :-)
<axw> (wallyworld: I don't disagree that that's a problem, but there are benefits that I'd like us to weigh up.)
<wallyworld> sure, fair point
<axw> I intended to bring it up at the sprint, but there was never really a good time
<wallyworld> yeah :-(
<anastasiamac> axw: sounds like we need another sprint :)
<axw> heh
<axw> I'm all sprunt out
<anastasiamac> the same. m glad my voice is back at least \o/
<babbageclunk> hey wallyworld - what happened with this PR? https://github.com/juju/juju/pull/5804
<wallyworld> babbageclunk: i had to not do it cause it would have broken everything due to mixed import paths
<wallyworld> code in that rev imports from v2-unstable
<babbageclunk> wallyworld: ah, gotcha.
<urulama|____> does openstack provider in juju 1.25 support v3 keystone auth?
<wallyworld> no
<urulama> but it does in juju 2.0, right?
<urulama> (to a very limited default region degree)
<wallyworld> babbageclunk: jam and axw and myself have been discussing. there's a PR to vendor all the things http://reviews.vapour.ws/r/5246/; or we have to update all the necessary repos with new import paths
<wallyworld> babbageclunk: either way, pain and suffering
<babbageclunk> wallyworld: :(
<wallyworld> urulama: you can specify domain and endpoint url
<wallyworld> urulama: bbiab, dinner time
<urulama> wallyworld: bon appÃ©tit
<babbageclunk> How many reviewers does a 19k-line diff need?
<urulama> :)
<babbageclunk> Prob'ly a few.
<axw> wallyworld: I'll hold off until the beta is out, but I have a PR ready to delete some code: http://reviews.vapour.ws/r/5249/
<axw> no rush on a review, can wait till monday
 * axw goes to make dinner
<babbageclunk> axw, wallyworld, jam - is there anything I can do to help with the mgo update before the release? With vendoring the package, are we then going to apply the minimal patch in place? (Sorry for interrupting dinners.)
<axw> babbageclunk: what's in my PR is actually the v2-unstable branch, just renamed to v2 with import paths fixed
<axw> babbageclunk: so it has your changes
 * axw goes away again
<babbageclunk> axw: Awesome, thanks.
<urulama> axw: ERROR storing charm for URL "cs:ubuntu-0": delegatable macaroon cannot be obtained for public entities
<urulama> axw, wallyworld: ^ is this client side?
<axw> urulama: I don't know which part you mean, but that error message is printed out by the client: https://github.com/juju/juju/blob/master/cmd/juju/application/deploy.go#L460
<axw> urulama: sorry, gtg
<urulama> axw: all good, default grant is read only, that's returned instead of saying you don't have write access
<babbageclunk> does anyone know if there's a reason not to replace common.SortStringsNaturally with the version from utils throughout juju/juju?
<babbageclunk> The utils version handles values with multiple embedded numbers.
<babbageclunk> (like 3/lxd/4)
<axw> jam: I've just weeded out a few issues with my vendor branch, should be good now. if you're OK with it, can you please merge it?  otherwise someone will need to do the dep changes
<axw> I need to go help with the kids now
<babbageclunk> (answering myself) gah, this change was already done (https://github.com/juju/juju/pull/5666), but on the model-migration branch.
<babbageclunk> That seems obtuse.
<voidspace> babbageclunk: I bought the Microsoft LX6000 headset. Works great and doesn't look so ridiculous. :-)
<anastasiamac> babbageclunk: as far as I know, we intend to merge model-migration branch next week (right after shipping beta12)
<anastasiamac> babbageclunk: mayb hangon on updating the bug and mark as fix committed once the merge occurs?.. :D
<babbageclunk> voidspace: yay, headset buddies!
<babbageclunk> anastasiamac: ok, thanks - I'll do that.
<anastasiamac> babbageclunk: \o/ thank you for ur patience :D there are plenty ofother bitesizes that can be nibbled on if u r keen :P
<babbageclunk> anastasiamac: :) Actually yeah - I find myself at a bit of a loose end this afternoon, so I'll have a look.
<anastasiamac> babbageclunk: wow! i forgot what it feels like :) u r great for tackling these!
<babbageclunk> :)
<katco> natefinch: standup time
<mup> Bug #1603473 opened: Relation fails as untis/machines are on different subnet on a multi NIC setup, juju 2.0 beta11 <11> <2.0> <beta> <juju> <juju-core:New> <https://launchpad.net/bugs/1603473>
<alexisb__> voidspace, ping
<alexisb__> dooferlad, ping
<dooferlad> alexisb__: I am both on holiday and cooking, but what's up?
<alexisb__> dooferlad, nevermind, it is not that urgent
<alexisb__> sorry didnt know you were out today
<alexisb__> enjoy your holiday
<perrito666> dooferlad: also dont cook and irc
<dooferlad> perrito666: it's OK, that's what irccloud is for. I am done with knives and am just waiting for things to cook.
<natefinch-afk> out for a bit taking a kid to a checkup
<perrito666> natefinch-afk: gluck
<frobware> alexisb__: will take a look over bug #1603473 again
<mup> Bug #1603473: Relation fails as untis/machines are on different subnet on a multi NIC setup, juju 2.0 beta11 <11> <2.0> <beta> <juju> <juju-core:New> <https://launchpad.net/bugs/1603473>
<alexisb__> thanks frobware
<alexisb__> frobware, if we cna just get an idea of next steps that would be awesome
<frobware> alexisb__: just asked for their MAAS network setup - with that I can try and reproduce
<katco> need to run out for a late lunch meeting. bbiab
<mup> Bug # changed: 1567635, 1568101, 1583789, 1584616, 1586512, 1590605, 1591387, 1594924, 1595686, 1596493, 1596597, 1597342, 1597704, 1598049, 1598063, 1598113, 1598118, 1598164, 1598286, 1598289, 1598293, 1598897, 1598964, 1599402, 1599779, 1599905, 1602732, 1602895, 1603208
<mup> Bug #1593828 changed: cannot assign unit E11000 duplicate key error collection: juju.txns.stash <ci> <conjure> <deploy> <intermittent-failure> <oil> <oil-2.0> <juju-core:Fix Released by 2-xtian> <https://launchpad.net/bugs/1593828>
<natefinch> if anyone has some time, moderate sized review (+631, -20) http://reviews.vapour.ws/r/5238/
<mup> Bug #1603577 opened: backup-restore: panic: empty value for "api-port" found in configuration <backup-restore> <blocker> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1603577>
<mup> Bug #1603577 changed: backup-restore: panic: empty value for "api-port" found in configuration <backup-restore> <blocker> <ci> <regression> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1603577>
<katco> wallyworld: mup is telling on you :)
<wallyworld> alexisb: that bug is a slightly different manefestation of the same know restore issue, so the beta should still go ahread
<wallyworld> alexisb: what was rhe final decison with regards to mgo - vendoring was considered and ruled out, looks like a patch approach was adopted
<mup> Bug #1603577 opened: backup-restore: panic: empty value for "api-port" found in configuration <backup-restore> <blocker> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1603577>
<mup> Bug #1603584 opened: juju-uitest calls obsolete --show-passwords <ci> <juju-gui> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1603584>
<mup> Bug #1603585 opened: modelManagerStateSuite.SetUpTest no reachable servers on windows <ci> <intermittent-failure> <test-failure> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1603585>
<alexisb> wallyworld, it is not blocking beta
<alexisb> but I am assigning it to you as it was a new symtom of the same restore issue you are working on
#juju-dev 2016-07-16
<mup> Bug #1598358 changed: Node is started but not deployed <oil> <oil-2.0> <juju-core:Invalid> <MAAS:New> <https://launchpad.net/bugs/1598358>
<mup> Bug #1598358 opened: Node is started but not deployed <oil> <oil-2.0> <juju-core:Invalid> <MAAS:New> <https://launchpad.net/bugs/1598358>
<mup> Bug #1598358 changed: Node is started but not deployed <oil> <oil-2.0> <juju-core:Invalid> <MAAS:New> <https://launchpad.net/bugs/1598358>
<natefinch-afk> alexisb: do you need someone to test that bug in azure still?  I have credentials for azure, though nothing currently bootstrapped
<rick_h_> natefinch: I'm bootstrapping atm
<natefinch> rick_h_: cool
<rick_h_> natefinch: will give it a go on b11, then upgrade to b12 and double verify if there's any change there as well
<alexisb> it is not urgent natefinch, I was just to lazy to bootstrap and setup credentials in azure
<rick_h_> we got your back alexisb :)
<alexisb> rick_h_, the wierd thing is it should have been in b11
<alexisb> not sure why it was getting hit there
<alexisb> you should hit that path for b9 and b10 but not b11
<alexisb> and the error messgae plain doesn't exist in b12
<alexisb> so if someone is hitting it htere we have real problems :)
<rick_h_> lol
<alexisb> anyhow my foobar, sorry
<rick_h_> well, will see/try. Maybe there was something to the path that isn't clear
 * alexisb goes and cleans stalls to clear my head
<katco> (sigh). i'm sorry... i introduced a temporal race condition in b10
<rick_h_> katco: I thought we were done with those!
<katco> fair warning: we may have this same conversation tomorrow, or yesterday.
<rick_h_> the conversations we get to have yesterday are the best
<katco> lol
<mup> Bug #1603596 opened: HA often fails on azure <azure-provider> <ha> <juju-core:Triaged> <https://launchpad.net/bugs/1603596>
<mup> Bug #1603596 changed: HA often fails on azure <azure-provider> <ha> <juju-core:Triaged> <https://launchpad.net/bugs/1603596>
<rick_h_> ok, replicated somewhat and replied
<mup> Bug #1603596 opened: HA often fails on azure <azure-provider> <ha> <juju-core:Triaged> <https://launchpad.net/bugs/1603596>
<natefinch> rick_h_: you around?
<rick_h_> natefinch: kinda
<natefinch> rick_h_: quickly - for interactive bootstrap I need to tie into interactive add credential, if the user has no creds.  But the UX format of that command is very different from mine.  Can I hack up that command to make it look more like mine?  I'm sure this will happen with add-cloud, too
<natefinch> rick_h_: this is one of the reasons I'd like unified guidelines on the UX of interactive commands
<rick_h_> natefinch: took a look at the guidelines, I'd like to chat on them and get them setup.
<rick_h_> natefinch: but have some feedback and think for now just use as is and we'll want to sync after we get the guidelines finalized
<natefinch> rick_h_: good enough.  That's basically what I figured.  For now it'll look weird, but we can always fix everything up in a separate PR.
<rick_h_> natefinch: <3
<katco> wallyworld: not sure if you're on; just pushed the state stuff for auditing for review
<mup> Bug #1603640 opened: Show controller version in 'juju controllers' <juju-core:New> <https://launchpad.net/bugs/1603640>
#juju-dev 2016-07-17
<thumper> menn0: are you fixing conflicts between master and model-migration branch? or shall I do it?
<menn0> thumper: it's on my list but given how long my list is I'm unlikely to get to it today
<thumper> menn0: ok, I'll do it now
<menn0> thumper: I want to land this other PR into the branch as well
<thumper> ack
<thumper> wallyworld: morning
<wallyworld> hello
<thumper> care to look over http://reviews.vapour.ws/r/5167/ ?
<thumper> addressed all review comments from the sprint
<thumper> would like to land it
<wallyworld> you already have a ship it from william?
<mup> Bug #1592365 changed: Juju 2.0 crashes on bootstrap with datacentred.co.uk OpenStack cloud <juju-core:Invalid> <https://launchpad.net/bugs/1592365>
<thumper> wallyworld: that was pre-review at the sprint
<thumper> I mean, I'm happy with it :)
<wallyworld> yeah, realised that after i asked, looking now
<thumper> wallyworld: also... https://bugs.launchpad.net/juju-core/+bug/1603596
<mup> Bug #1603596: HA often fails on azure creating virtual machine <azure-provider> <blocker> <ci> <ha> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1603596>
<thumper> azure giving us a 400
<thumper> so we are probably doing something wrong
<wallyworld> \o/
<thumper> perhaps it was deprecated and now removed?
<mup> Bug #1488573 changed: Juju treats transient vnet failures as permanent <azure-provider> <bootstrap> <ci> <deploy> <intermittent-failure> <reliability> <repeatability> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1488573>
<thumper> wallyworld: also, will be merging model-migration into master RSN, after I update it and menn0 lands one last branch
<wallyworld> yay
<wallyworld> thumper: lgtm with trivials
<thumper> wallyworld: ta
#juju-dev 2017-07-10
<axw> mwhudson: there's a new gollvm package, which sits between gofrontend and llvm. it's totally separate from the LLVM Go bindings (aka GoLLVM), and llgo (the thing I originally wrote, but also had a significant amount of work by a googler)
<axw> s/package/project/
<mwhudson> ah ok
<mwhudson> i was thinking of llgo yeah
<axw> wallyworld: would you please review https://github.com/juju/juju/pull/7607?
<wallyworld> sure
<wallyworld> axw: i suspect the controller used to need to talk to the key manager facade a long time ago perhaps
<axw> wallyworld: I guess so
<axw> doesn't now tho
<wallyworld> yeah
<wallyworld> axw: your recent model upgrade changes fixed this bug right? bug 1700434
<mup> Bug #1700434: missing credential stops upgrade from running <juju:Triaged> <https://launchpad.net/bugs/1700434>
<axw> wallyworld: yes
<axw> wallyworld: aka https://bugs.launchpad.net/juju/+bug/1700451
<mup> Bug #1700451: Upgrade from 2.1.x to 2.2.1 blocked by missing Azure resources <canonical-is> <upgrade-juju> <juju:Fix Committed by axwalk> <https://launchpad.net/bugs/1700451>
<wallyworld> axw: and were you looking at this one ? bug 1701438
<mup> Bug #1701438: worker/apicaller: timeout for api dials is too low <juju:Triaged> <https://launchpad.net/bugs/1701438>
<wallyworld> if not we can pick it up
<axw> wallyworld: I haven't yet
<wallyworld> axw: i'll get it done
<wallyworld> jam: axw: given the size of the diff, i wouldn't mind a quick eyeball (there were a few conflicts). this merges 2.2 into develop, the biggest changes are status history pruning and model upgrades https://github.com/juju/juju/pull/7608
<axw> wallyworld: sure, just finishing up status changes for model upgrades, will look after that
<wallyworld> sgtm, no hurry
<wallyworld> i know there's changes coming, but i wanted to get the baseline a little mnore up to date and clear the conflicts for folks
<veebers> wallyworld: is that merge including the CI parts? (acceptancetests and releasetests)
<wallyworld> veebers: it's tip of 2.2
<wallyworld> so whatever that included
<wallyworld> i pulled 2.2 just before doing the mrge just now
<veebers> wallyworld: ah ok, cool. I get the feeling there is some differences there for the CI stuff, let me take a look :-)
<wallyworld> ok, thank you
<veebers> wallyworld: I don't see any changes to either acceptancetests/ or releasetests/ so we should be good
<wallyworld> veebers: excellent, thanks for looking. i didn't notice any such changes come through with the merge, but always good to be sure
<veebers> wallyworld: aye, it got my interest because I got tripped up with CI things being in 2.2 but not develop (which is what we currently deploy, until we change that to be in branch)
<wallyworld> yeah. multilple branches is fun
<veebers> Life would be boring if it was easy
<axw> wallyworld: while I'm looking, can you please review https://github.com/juju/juju/pull/7609 ?
<wallyworld> sure
<wallyworld> axw: the worker can only ever run with the newer facade, so there's no need for a version check, right?
<wallyworld> what about HA though
<axw> wallyworld: right, it's a new facade in 2.2.2
<wallyworld> the worker could hit a 2.2.1 facade
<axw> wallyworld: the controller agents all upgrade first before the model workers start
<wallyworld> yeah, that is true
<wallyworld> axw: lgtm but with a request to include the error in the status message
<axw> wallyworld: ok
<axw> wallyworld: ta
<axw> wallyworld: merge looks fine, just one little issue about some test code which I think can be dropped
<wallyworld> axw: thanks, looking
<wallyworld> axw: i'll pull your last PR into the merge as well
<axw> wallyworld: great, thanks
<wallyworld> axw: if it's not too late, otherwise it can wait till tomorrow, a tweak to find/show endpoints https://github.com/juju/juju/pull/7610
<axw> wallyworld: what is this "user feedback" you speak of :)
<axw> looking
<wallyworld> axw: it's in the bugs, from rick
<axw> I jest
<wallyworld> :-)
 * wallyworld bbiab, making dinner
<rick_h> wallyworld: axw :P
<wallyworld> rick_h: he started it :-)
<menn0> jam: the PR is here: https://github.com/juju/juju/pull/7612
<menn0> jam: I need to stop now. could you do a custom build for dimitrii and get him to try it out?
<wallyworld> externalreality: hey, did you want to catch up?
<externalreality> wallyworld, yes
<externalreality> @wallyworld, are you available now
<wallyworld> externalreality: sure, give me one minute
<externalreality> ok
#juju-dev 2017-07-11
<axw> wallyworld: https://github.com/juju/juju/pull/7617 <- api dial timeout
<wallyworld> looking
<wallyworld> axw: lgtm, could you look at https://github.com/juju/juju/pull/7615 ? just a small tweak
<axw> wallyworld: yep, looking now
<axw> wallyworld: maybe a stupid question... just looking at the model-config code, isn't the answer to use "juju model-config --reset http-proxy" ?
<wallyworld> axw: that will reset back to the model default, rather than explicitly ""
<wallyworld> model default value may be something specific
<axw> ok
<wallyworld> i'll check to be sure though
<axw> wallyworld: how's it going to work for string config attrs that won't accept an empty string value? it'll fail. you really need to delete in that case... but then the model defaults apply
<wallyworld> axw: my take is that if the user tries to set "" and that is invalid, it will just error
<wallyworld> i guess i could make foo= be nil
<wallyworld> so we'd support foo="" -> empty string, foo= -> nil
<axw> wallyworld: the quotes will be interpreted by the shell
<axw> it'll end up as empty string in the args in either case
<axw> and that'd be pretty subtle anyway
<wallyworld> right but I can check for "foo="
<wallyworld> hmmmm
<axw> wallyworld: anyway, it's an incremental improvement
<wallyworld> yeah, we probably should have a separate semantic for delete
<axw> wallyworld: you've got some dupes in the test
<axw> all you need to add is "k1=", AFAICT
<wallyworld> that was on purpose to reset the value back to non empty
<axw> ah
<wallyworld> just to test parsing "" and empty
<wallyworld> jam: did you have a few minutes to otuch base on the 2.2.2 bugs?
<jam> wallyworld: do you have a sensor on my chair? I *just* sat down :)
<wallyworld> lol
<wallyworld> i can wait
<jam> I was planning on looking through that list this morning, so I haven't really gotten to it yet
<jam> I'll have standup in 20 min
<jam> let me read through them and see what I can do
<wallyworld> i had some info to share on my work
<wallyworld> well, our work on this end
<jam> sure, I just figure if I haven't actually read through the list, a conversation may be a bit one sided :)
<wallyworld> np, maybe ping me after standup then
<jam> wallyworld: so bug 1696739 and bug 1662857 both seem like they could just be removed from the 2.2.2 milestone
<mup> Bug #1696739: mongodb reporting saslStart and isMaster as being slow <mongodb> <performance> <juju:Incomplete> <https://launchpad.net/bugs/1696739>
<mup> Bug #1662857: cannot go get the source code  <juju:Fix Committed by ecjones> <juju 2.2:Won't Fix by ecjones> <https://launchpad.net/bugs/1662857>
<wallyworld> right
<wallyworld> i wanted to create a new 2.2.3 milestonr
<wallyworld> i changed the project driver to a team which we are in, but still can't do it it seems
<wallyworld> also bug 1696557
<mup> Bug #1696557: relationscopes may have an O(N^2) bug during startup <performance> <startup> <juju:Triaged> <https://launchpad.net/bugs/1696557>
<wallyworld> and i think bug 1697956 might fix bug 1696508
<mup> Bug #1697956: restarting controller during an HA upgrade will cause it to not upgrade <adrastea> <upgrade-juju> <juju:In Progress by wpk> <juju 2.2:In Progress by wpk> <https://launchpad.net/bugs/1697956>
<mup> Bug #1696508: secondary controllers not coming up correctly <adrastea> <enable-ha> <ha> <performance> <juju:Triaged> <https://launchpad.net/bugs/1696508>
<wallyworld> and bug 1696472 can come off - we could do that for a 2.2.3 based on the history rpuning work
<mup> Bug #1696472: dblogpruner failed to prune logs by time <adrastea> <logging> <performance> <pruning> <juju:Triaged> <juju 2.2:Triaged> <https://launchpad.net/bugs/1696472>
<jam> wallyworld: I created a 2.2.3, where did you try to create it?
<jam> I went to launchpad.net/juju and then clicked on the series 2.2, and then scrolled down for "create milestone"
<wallyworld> i had thought there was a button on the milestone overview page
<jam>  /shrug, maybe there should be, but I found it on the series
<wallyworld> ah, yeah i see it there too
<wallyworld> so i looked in the wrong place
<wallyworld> jam: the biggest concern is that cdo qa blocker - the mongo issue. i was going to ping menno as he had had some involvement and could have maybe provided some insight but he's out today etc. i'm not sure what we can do about that bug before we look to cut a release
<jam> wallyworld: yeah, he handed some of that off to me, so I'll pick up from where he left off
<wallyworld> there's 2 issues - the pinger one, and the other
<wallyworld> controllers not being able to even login to mongo
<wallyworld> bug 1701275
<mup> Bug #1701275: [2.2.1] juju-agent loses connection to controller and doesn't retry to connect <4010> <cdo-qa-blocker> <cpe> <cpe-sa> <juju:Triaged> <https://launchpad.net/bugs/1701275>
<wallyworld> i think we still need to add the pinger one to the milestone as well
<wallyworld> in addition to this other one
<jam> wallyworld: I'm back around again
<jam> finished my other meetings
<jam> wallyworld: so I'm actually focused on 1701294, which is a bug that is private, so I'm creating a public bug to track that against juju itself.
<wallyworld> jam: sorry, was at school pickup. do you think we can release without fixing that other mongo one? I can't see us diagnosing, fixing, and testing this week, and we need 2.2.2 out the door
<axw> jam: if you have any free time today, I'd appreciate a review of https://github.com/juju/juju/pull/7606 (apiserver facade reorg)
<jam> yeah, trying to get through the backlog
<axw> thanks
<jam> I'm holding off on that one a little, as its bigger, but I'll try to get to it
<axw> no worries, no rush
<jam> axw: on pull 7611, you have a TODO about schema.Omit()
<jam> but from what I can tell your default is "", not schema.Omit()
 * axw looks
<axw> jam: huh. I'm sure I had it as omit, must have changed it by mistake at some point. thanks, will fix - I believe the TODO still applies, but I'll double check
<axw> jam: thanks for catching: https://github.com/juju/juju/pull/7621. running QA now
<axw> jam: not sure I follow your comment about storageprovisioner - was that based off reading the description? I did put it under facades/agent, just didn't mention that in the description
<jam> axw: yeah, just reading the description
<axw> okey dokey
<jam> haven't gotten into the 385 files changed yet
<axw> :)
<axw> it's mostly just changed imports
<axw> 99% mechanical
<jam> axw: so is it mostly about asking if the grouping is sane?
<axw> jam: yup, which I think we agreed on already, but it needs the stamp
<axw> jam: actually the only non-mechanical bit in this PR are dropping the AuthClient check in apiserver/highavailability. there were auth fixes, but they were made in 2.2 and then merged already
<jam> wpk: axw: trivial review: https://github.com/juju/juju/pull/7624
<jam> we had a helper function that was essentially "c.Assert(true)"
<axw> jam: doh :) lgtm
<wpk> jam: whoops :)
<wpk>  /wind 54
<jam> wpk: https://github.com/juju/juju/pull/7625 is another quick-tweak of logging data
<jam> wpk: I need to EOD now, but if you do a review I'm happy to land it
<wpk> lgtm
<wallyworld> externalreality: hey, could you please backport this PR into 2.2 branch? https://github.com/juju/juju/pull/7552
<externalreality> OK
<wallyworld> awesome, thanks
<externalreality> np
<wallyworld> externalreality: bug 1696472
<mup> Bug #1696472: dblogpruner failed to prune logs by time <adrastea> <logging> <performance> <pruning> <juju:Triaged> <juju 2.2:Triaged> <https://launchpad.net/bugs/1696472>
<externalreality> nice, I'll make a leankit card now if one doesn't already exist
#juju-dev 2017-07-12
<axw> burton-aus: I've added this: "By default, the remove-storage command will fail if the storage is currently attached. To force removal of the attachments as well as the storage, you can supply the --force flag."
<axw> burton-aus: BTW that fix hasn't landed yet, I'm merging it now
<burton-aus> Ok.
<axw> veebers: what's up with windows in CI? it often (always?) fails but the jobs still pass. e.g. http://juju-ci.vapour.ws:8080/job/github-merge-juju/11303/artifact/artifacts/windows.log/*view*/
<axw> veebers: and I think it's slowing down the jobs quite a lot
<veebers> balloons: did we make any progress with the windows unit tests? If they are still causing grief perhaps we should disable them for now
 * wallyworld out to lunch, bbiab
<balloons> veebers, sure. No progress
<veebers> balloons, axw: I'll disable windows unit tests for now until we can fix it, dont want to harm velocity
<axw> veebers: thank you
<axw> wallyworld: re that vsphere bug, google says the error message does occur when the datastore is inaccessible. so my changes for 2.2.2 may fix it (there may be other causes too, but they seem less likely)
<axw> wallyworld: so I've marked dupe
<axw> jam: wallyworld is going to be late for techboard. can we just wait until he gets back? I'll go get something to eat quickly
<jam> axw: fine with me
<jam> I'm russing to make it myself
<jam> could use a couple mins
<jam> axw: ian's here
<axw>  wallyworld: can you come back? had a couple of things to talk about for tech board, ran out of time...
<wallyworld> ok
#juju-dev 2017-07-13
<wallyworld> externalreality: review done, i think we can remove the mock store
<externalreality> without the mock store the tests won't actually read the yaml files.
<externalreality> The yaml files are read twice, once for getting the data and once for validating it.
<externalreality> unfortunately I could work around that
<wallyworld> externalreality: but only one method is called onthe mock store - we create a mock store just to call the one method. the mock store is not used elsewhere after that that i can see
<wallyworld> so can't we call that one method directly?
<externalreality> Hmmm, sounds right. Will fix. :-D
<wallyworld> ty
<wallyworld> axw: thanks for review. i may have misunderstood your point about relation macaroon. i've replied to your comment. maybe we need to discuss?
<axw> looking
<axw> wallyworld: for the relation macaroon, you're using for the ID: "relation-"+localRel.Tag().Id(). I'm saying that's OK, but you should include the model UUID in the ID as well. otherwise it'll collide with other models (bakery storage is not model-specific)
<wallyworld> axw: ah, right, i missed the bit about bakery storage not being model specific. i thought it was
<axw> wallyworld: alternatively make it blank, but then you'll get a new key for each register call, even for the same relation
<wallyworld> axw: i wanted to give it a name so i could delete it when the relation died
<axw> wallyworld: yep, makes sense
<wallyworld> axw: that was also the reason for naming the offer macaroon. but it can just be cleaned up by the ttl index
<axw> wallyworld: for the offer macaroon, you can have a single one, and then rely on an additional caveat to force the client to prove itself. then use that for revocation
<axw> i.e. refresh
<wallyworld> axw: the idea was that it would be a bearer token rather than have a caveat to discharge
<wallyworld> the controller uses the macaroon, not the user
<axw> wallyworld: I think it's fine one per consume for now, we can revisit that
<wallyworld> yeah
<wallyworld> axw: relation macaroon now includes model uuid
<wallyworld> in the id
<axw> wallyworld: reviewed
<wallyworld> ty
<wallyworld> yeah, i have got more testing
<axw> wallyworld: lxd storage PR, if you have time: https://github.com/juju/juju/pull/7635
<wallyworld> axw: swap you reviews? https://github.com/juju/juju/pull/7637
<axw> wallyworld: ok
<axw> wallyworld: what do you think about adding special syntax to "add-storage" for enlisting? like "juju add-storage postgresql/0 pgdata=ebs:vol-123456", where vol-123456 is the provider (EBS) volume ID
<axw> I think that's all the info we need, in order to create a storage instance, volume, and attachments
<wallyworld> axw: that would save an extra command for sure
<wallyworld> axw: but what about adding an ebs volume as detached storage
<axw> wallyworld: it wouldn't be possible, but it is it necessary? you can't add new volumes detached
<wallyworld> axw: i was thinking of the case where someone adds a unit and then later detaches the storage - that storage is now referenced by the model and be attached again elsewhere. i would think we'd want a way to allow an ebs volume to be made known to juju for later attachment
<axw> wallyworld: ah yes, it won't work with --attach-storage
<wallyworld> maybe we could tweak attach-storage
<wallyworld> axw: i'm confused about where "juju-zfs" comes from - it that our (juju's) naming convention?
<axw> wallyworld: it's specified in DefaultPools
<axw> wallyworld: the juju storage pool definition includes an attribute "lxd-pool", which identifies the lxd storage pool to use
<axw> wallyworld: and if the lxd-pool attribute is missing, we use "juju" as the lxd storage pool name
<wallyworld> and zfs.pool_name s passed to lxd
<axw> wallyworld: yes, things other than driver/lxd-pool are passed directly to lxd
<wallyworld> axw: lgtm. with the macaroon storage, other places use json. should we be correct for cmr or consistent? i guess there's no reason we can have cmr use binary
<wallyworld> *can't
<axw> wallyworld: thanks
<axw> wallyworld: not too fussed, your call
<wallyworld> maybe leave for now and take a view
<wallyworld> can see what others think
<axw> wallyworld: CreateStoragePool is not idempotent. we check if it exists first. I could create and hceck on failure, but there's no special error code for "already exists"
<axw> there is an error message we can check, but that could change
<wallyworld> yeah :-(
<axw> wallyworld: I'll just make it do a create, then check if it exists on failure
<axw> ignoring the specifics of the create error
<wallyworld> i think that would be good
<wallyworld> s/good/better
<wallyworld> jam: wtf do you think we need to do with this mongo bug? it seems the pinger is not the root cause? or is it that things get messed up due to the pinger issue and manifest hat way?
<jam> wallyworld: so my feeling on it is that it shouldn't block 2.2.2. I feel like we have had a latent bug, and the pinger bug exacerbated it
<jam> so I think it is a separate bug, but one that we've had
<jam> the lack of clear reproduction situation, and really the need to do live debugging, because the round-trip info is killing us in investigating it
<wallyworld> jam: i have been telling myself that if it is not a regression we could ship, but that if 2.1 didn't have the problem, we can't ship
<jam> missing info, things that you'd pick up on what to do next while you're looking at the exact logs, etc.
<wallyworld> but as you say, it could be in 2.1
<jam> wallyworld: nobody has reproduced, and getting information out is taking days, IMO that isn't worth delaying a fix of 10 other things that we concretely made better
<wallyworld> exactly
<wallyworld> jam: will eric's PR, we could land as is and follow up with that %q tweak
<jam> wallyworld: with eric's PR, I also don't feel that's a blocker for 2.2.2 being actually released. If we get it in, great, but not a delay
<wallyworld> jam: the issue is a bit shit, we should land it. i can do that and easy to make the subsequent little tweak after that
<jam> wallyworld: sure, but its a little ugly wart that doesn't actually prevent you from doing what you asked to do (hence not a Critical blocker), definitely worthy of a 2.2.X release, I just wouldn't hold anything up on it.
<wallyworld> yeah, ok. i'll land now and it should make it
<wallyworld> jam: did you want to move that bug odd the 2.2.2 milestone? also, eric's PR doesn't need the %q instead of %s because the string comes out of whatever the underlying api call is already quoted. or so my manual testing showed
<wallyworld> *off
<jam> wallyworld: k. I will say it *didn't* get quoted when he was interpreting the error incorrectly, but I did see that one of his tests seemed to say it was quoted
<jam> so I wasn't sure
<wallyworld> np
<wallyworld> i wasn't sure either
<wallyworld> until i tested manually
<mup> Bug #1704099 opened: Juju state server not starting after reboot <4010> <juju-core:New> <juju-release-tools:New> <https://launchpad.net/bugs/1704099>
<wallyworld> hml: can you join us in release standup to update on release? https://hangouts.google.com/hangouts/_/canonical.com/juju-release
<hml> wallyworld: on my way
<mup> Bug #1704099 changed: Juju state server not starting after reboot <4010> <juju:New> <https://launchpad.net/bugs/1704099>
#juju-dev 2017-07-14
<blahdeblah> Morning folks; I notice some of my 2.2.1 bugs have been marked as fix released, but I'm not seeing a new client in the zesty stable PPA.  Am I just impatient, or did it get missed?
<axw> blahdeblah: the 2.2.2 release is underway
<blahdeblah> So I'm just impatient; OK :-)
<wallyworld> axw: hey, i didn't have zfs-fuse install and got and error bootstrapping lxd. it should just be a warning or something and the zfs pool should not be created, allowing the user to still use the dir driver
<wallyworld> ERROR failed to initialize state: adding default storage pools for "lxd": creating default pool "lxd-zfs": validating storage provider config: creating LXD storage pool "juju-zfs": creating storage pool "juju-zfs": The "zfs" tool is not enabled.
<wallyworld> the bootstrap aborted with the error
<axw> wallyworld: ok, thanks, I'll sort that out now
<wallyworld> ta
<wallyworld> no rush
<hml> blahdeblah: you can have fun with 2.2.2 now :-)
<hml> night night
<blahdeblah> thanks hml
<axw> wallyworld: https://github.com/juju/juju/pull/7641 fixes the lxd storage bootstrap bug
<wallyworld> axw: was out with anastasia, looking now
<wallyworld> nice
<burton-aus> wallyworld it's cloudy here, as usual, will rain very soon and cold.
<wallyworld> burton-aus: but it's melbourne so it will be sunny and then windy straight after
<blahdeblah> So what's the workaround for juju not finding the upgrade in my cloud?  Sync tools?
<blahdeblah> gaaaaah - sync-tools is definitely not the right workaround; it's downloading every known agent for 2.2.2 from UK to AU, only to upload it from AU to UK again!
<blahdeblah> There don't seem to be any documented means of filtering sync tools by OS and arch; any other options?
<blahdeblah> updated https://bugs.launchpad.net/juju/+bug/1700455 with more info
<mup> Bug #1700455: juju 2.1.x models cannot be upgraded to 2.2.1 <canonical-is> <juju:New> <https://launchpad.net/bugs/1700455>
#juju-dev 2018-07-09
<mup> Bug #1749763 changed: remove an application not in bundle should be ignored <juju:New> <https://launchpad.net/bugs/1749763>
<mup> Bug #1768064 changed: Juju messes up when terminating AWS instances <juju:New> <https://launchpad.net/bugs/1768064>
<mup> Bug #1749763 opened: remove an application not in bundle should be ignored <juju:New> <https://launchpad.net/bugs/1749763>
<mup> Bug #1768064 opened: Juju messes up when terminating AWS instances <juju:New> <https://launchpad.net/bugs/1768064>
<mup> Bug #1749763 changed: remove an application not in bundle should be ignored <juju:New> <https://launchpad.net/bugs/1749763>
<mup> Bug #1768064 changed: Juju messes up when terminating AWS instances <juju:New> <https://launchpad.net/bugs/1768064>
#juju-dev 2018-07-10
<mup> Bug #1727355 changed: Juju attempts to bootstrap bionic by default <cdo-qa> <cdo-qa-blocker> <cdo-release-blocker> <foundations-engine> <sts> <uosci> <verification-done> <verification-done-xenial> <verification-done-zesty> <juju:Fix Released by nskaggs> <juju-core:Won't Fix> <distro-info-data
<mup> (Ubuntu):Won't Fix> <juju-core (Ubuntu):Invalid> <distro-info-data (Ubuntu Trusty):Won't Fix> <juju-core (Ubuntu Trusty):Invalid> <distro-info-data (Ubuntu Xenial):Fix Released by vorlon> <juju-core (Ubuntu Xenial):Fix Released> <distro-info-data (Ubuntu Zesty):Fix Released> <juju-core (Ubuntu
<mup> Zesty):Fix Released> <distro-info-data (Ubuntu Artful):Won't Fix> <juju-core (Ubuntu Artful):Invalid> <https://launchpad.net/bugs/1727355>
#juju-dev 2018-07-13
<valentina_> Hello All :D
<valentina_> would anyone give me a hint please: I'm using pylxd in my charm: https://git.launchpad.net/charms-6wind/tree/charm-layers/6wind-common/lib/charm/openstack/utils.py.
<valentina_> I want to add a constraint: that my charm installs and uses only pylxd>=2.2.7 from PyPy repository not python3-pylxd from official ubuntu's repos.
<valentina_> I've found small notice about wheelhouse.txt file in official doc
<valentina_> I'm hesitating, where I should put this constraint, shall I create wheelhouse.txt in 6wind-common layer directory: https://git.launchpad.net/charms-6wind/tree/charm-layers/6wind-common
<valentina_> Or I should put it in charm's dir here:  https://git.launchpad.net/charms-6wind/tree/virtual-accelerator-compute
<valentina_> ?
<valentina_> The second question: actually there is no any wheelhouse.txt files in charms-6wind repo, but when I build the charm, the build folder is created and I can see wheelhouse.txt generated here. How it is generated by charm build and which template it takes, how it takes decision which python libraries it have to put to wheelhouse.txt as a needed dependencies ?
<valentina_> Thanks for any help
