[23:36] <akgraner> pleia2, susan asked me to send her an email with her action items do I need to look on the blueprint or the etherpad
[23:37] <pleia2> akgraner: I've updated the blueprint so they are there now
[23:38] <akgraner> thanks - I'll get on it then
[23:38] <akgraner> pleia2, you're awesome!


[00:00] <wallyworld> *so
[00:00] <menn0> wallyworld: I look forward to cleaning that up. the code in the area pissed me off last time I made changes there.
[00:00] <menn0> :)
[00:01] <wallyworld> lol
[00:01] <wallyworld> good to clean up shit which pissed you off
[00:01] <perrito666> Eschatological refactoring, interesting
[00:02] <wallyworld> menn0: the thing to bear in mind is that we filled a 32GB root partition with repeated charm deploy/model removal for a few users on a few models
[00:02] <wallyworld> so if we see a pathway to fix that then good
[00:02] <wallyworld> this is a step in the right direction
[00:02] <wallyworld> "Eschatological" is a fancy word
[00:02] <menn0> wallyworld: well with will's improvements and the removal of the cache we should be good then
[00:03] <wallyworld> menn0: i'll believe it when i see it - this is a very large whack a mole i fear
[00:03] <perrito666> It's not so weird in Spanish
[00:03] <wallyworld> i don't even know what it means, will need to look it up
[00:05] <perrito666> Wallyworld https://en.m.wikipedia.org/wiki/Scatology
[00:05] <perrito666> Apparently in english they use different words in Spanish is the same word for all meanings
[00:05] <wallyworld> oh i know what that word means
[00:06] <wallyworld> didn't recognise the one starting with "e"
[00:06] <perrito666> So yes we share a word for shit and religion aren't we cool
[00:06] <wallyworld> same thing :-)
[00:07] <menn0> wallyworld: i'll do some checks on disk usage with some large bundles after all the changes are in and see
[00:07] <wallyworld> sgtm, ty
[00:08] <anastasiamac> perrito666: apparently a fetish for some ppl according to that reference
[00:29] <alexisb> thumper, wallyworld you guys around
[00:29] <thumper> I am
[00:29] <wallyworld> depends who's asking :-)
[00:29] <alexisb> can you join a quick HO?
[00:29] <alexisb> :)
[00:29] <wallyworld> suppose so
[00:30] <alexisb> meet you in a-team
[00:30] <thumper> ack
[00:38] <mup> Bug #1623275 opened: neutron-gateway juju-agent lost forever <juju-core:New> <https://launchpad.net/bugs/1623275>
[00:47] <menn0> axw: review done
[00:47] <menn0> phew
[00:56] <anastasiamac> menn0: so just to make sure u r having fun, here is the simple scream one as promised - http://reviews.vapour.ws/r/5674/
[00:57] <anastasiamac> axw: wallyworld: if u r feeling exceptionally generous ^^
[00:57] <redir> bbiab
[00:57] <wallyworld> i'll take a peek in a bit
[00:57] <anastasiamac> menn0: i tried to have logically grouped commits for the ease of perusing :)
[01:08] <anastasiamac> menn0: and another 1-liner :) http://reviews.vapour.ws/r/5675/
[01:10] <axw> menn0: TYVM
[01:20] <menn0> anastasiamac: i've got a few jobs to do but I'll get to those soon
[01:27] <menn0> wallyworld: ship it
[01:27] <wallyworld> awesome, ty
[01:34] <anastasiamac> menn0: sure thing! tyvm ;)
[01:45] <thumper> wallyworld, menn0: big but boring http://reviews.vapour.ws/r/5676/
[01:46] <wallyworld> thumper: like you :-)
[01:46] <thumper> oh you so funny
[01:48] <axw> thumper menn0: re http://reviews.vapour.ws/r/5676/, why no access levels in core/description? do we not migrate access?
[01:49] <thumper> axw: we do, but as string values
[01:49] <thumper> not special Access type
[01:49] <thumper> core description is all about being able to describe the model for export
[01:49] <thumper> not a generic "stick it here" type package
[01:50] <thumper> specific small packages for specific things is good
[01:50] <axw> thumper: but access *is* part of the description of a model?
[01:50] <thumper> it is an attribute of users, sure
[01:50] <thumper> that is still there
[01:50] <thumper> but the type for Access should live elsewhere
[01:54] <axw> thumper: I don't see why. If you have access there in core/description, but as a string, you're just making it stringly typed. It would be nice to retain some type safety in the core description - this will matter if we start using core/description for more than just exporting
[01:55] <wallyworld> axw: i'll make that api change for cloud tags, ok?
[01:55] <axw> wallyworld: yes, thank you
[01:56]  * wallyworld gets food first
[01:56] <axw> wallyworld: probably need to let mhilton know
[01:56] <wallyworld> axw: yeah, jeff is all set to make his upstream changes sod tomorrow
[01:56] <axw> cool
[01:57] <thumper> axw: core/description needs to be able to handle old and new format values, if we tie types in there, we could limit our ability to do this easily
[01:57] <thumper> I just don't think it is the right place for that
[01:57] <thumper> yes we need some business object tier
[01:57] <thumper> but I've become increasingly sure that core/description isn't it
[01:58] <axw> thumper: fair enough then. perhaps "core description" is not the best name for it then - that implies to me that it's *the* canonical representation
[01:58] <thumper> I actaully want to move core description out of juju/juju
[02:01] <thumper> ugh...
[02:01] <thumper> I now have two branches that I know will conflict
[02:01]  * thumper waits for the first to land
[02:04] <natefinch> menn0: pong
[02:05] <natefinch> menn0, wallyworld: saw your comments on the review
[02:05] <natefinch> menn0, wallyworld: the main reason to keep track of how the value was constructed is so that error messages make sense.  otherwise you get something like this:
[02:06] <natefinch> juju deploy --constraints=cpu-cores=3 --constraints=cpu-cores=4
[02:06] <natefinch> ERROR: bad 'cores' constraint: already set
[02:07] <wallyworld> isn't that a corner case though?
[02:07] <natefinch> there's a lot of ways validation can fail
[02:08] <natefinch> and they all specify the value that failed, which won't be in the list of things you set
[02:08] <natefinch> I agree, it's a lot of complication.  I almost didn't do it.
[02:08] <wallyworld> hmm, i see your point. i wonder what others think
[02:10] <menn0> sorry otp, almost done
[02:11] <natefinch> My other option was to print out a deprecation warning at the beginning, but that gets clunky fast, if we do any more of these aliases.
[02:12] <natefinch> Warning: the "cpu-cores" constraint is deprecated in favor of "cores"... etc
[02:13] <wallyworld> natefinch: that's the approach we have taken for config attributes and is one i like
[02:14] <wallyworld> lets the code stay simple, the majority of cases works nicely without cruft, but does alert the user to change what they type
[02:14] <wallyworld> and it's not like there will be 100s of deprecations
[02:15] <menn0> wallyworld, natefinch: i'd prefer the deprecation warning too
[02:16] <natefinch> ok... undo undo undo :)  Simpler is better, I agree.
[02:16] <menn0> natefinch: sorry :)
[02:17] <natefinch> menn0: nah, it's the right call. I was doing that, but then I was halfway to just having the right error message anyway, so I kept going. Except of course, I wasn't really half way, I was like 10% of the way, I just didn't realize it yet :)
[02:18] <axw> wallyworld: I don't suppose you'll have any bandwidth for a second review on my branch today?
[02:19] <wallyworld> axw: just for you
[02:19] <axw> wallyworld: thanks. no rush, any time later on
[02:19] <axw> going to look at credentials now
[02:19] <wallyworld> axw: ok, will do it real soon
[02:29] <natefinch> menn0, wallyworld: one question - I noticed HardwareCharacteristics has cpu-cores.... it wasn't specified in the bug, but I presume we want to make that match the constraint
[02:31] <wallyworld> natefinch: i think so
[02:33] <menn0> natefinch: good catch. yes, that should probably match
[02:35] <natefinch> wallyworld: btw the reason I wasn't going to change the field name on the struct is merely to keep the change smaller.  The name of the field is still close enough to the name it is serialized as, that I don't think it's worth the churn.
[02:35] <axw> wallyworld: re http://reviews.vapour.ws/r/5674/: I *think* what anastasiamac's doing is going in the right direction. ImageMetadata.Stream shouldn't really be there, because it's not actually part of the simplestreams format at that level
[02:35] <wallyworld> i can go either way
[02:36] <axw> wallyworld: moving it up to the "resolve info" feels more natural to me, because it's meta-metadata
[02:36] <wallyworld> axw: ok, i need to look at it again
[02:37] <wallyworld> axw: the issue is that resolve info is about a location/source of metadata. not necessarilty the stream from which is came
[02:37] <wallyworld> but maybe in practice there's 1:1
[02:40] <axw> wallyworld anastasiamac: hrm, I think it's only 1:1 because of this: https://github.com/juju/juju/blob/master/environs/simplestreams/simplestreams.go#L640
[02:41] <axw> wallyworld anastasiamac: that looks to me like we're picking an arbitrary stream, when multiple are specified. is that right?
[02:41] <anastasiamac> axw: well, source and stream are 1:1
[02:41] <axw> so things will only work properly if you do a lookup with one stream. which I think we always do anyway
[02:41] <anastasiamac> axw: what we are picking here is only location out of potentially many matches
[02:42] <wallyworld> axw: right, from memory, the assumption was that index files would only contain one product stream. and we currently rely on that. but it's not guaranteed
[02:42] <anastasiamac> relationship between source and stream is still 1:1 if you look at products files... stream is defined on content id which there is only one of per file
[02:42] <wallyworld> locations are not 1:1 with stream
[02:42] <wallyworld> in the model
[02:42] <wallyworld> and yet now we would be hard coding that faulty assumption
[02:42] <anastasiamac> maybe not in the model but m looking at the actual files we have in simple streams... streams are on content id and there is only one content id
[02:43] <wallyworld> that's the way they have chosen to make the files currently, but it can be different
[02:43] <wallyworld> and if it changes we will break
[02:43] <anastasiamac> wallyworld: pla point me to a file which has n=more than one content-id
[02:43] <anastasiamac> please*
[02:43] <axw> ah right, because we have a different URL for daily
[02:43] <wallyworld> i'd have to go digging to find one
[02:43] <wallyworld> we used to have them
[02:44] <wallyworld> we may have moved on to differentiating using url
[02:44] <wallyworld> i just fear that we are making assumptions based on an implementation artifact, not the true streams model
[02:44] <axw> wallyworld anastasiamac: the other option would be to have GetMetadata return a map, keyed on stream
[02:45] <anastasiamac> m looking at code and data. how is it hard-coding worng assumption?!
[02:45] <wallyworld> data does things one possible way, not the only way
[02:45] <axw> anastasiamac: the point is that index.json *could* have multiple product IDs
[02:45] <axw> anastasiamac: it works now because they only have one. but that can change
[02:46] <wallyworld> may not change, but if it does we will break
[02:48] <anastasiamac> axw: sure. but m getting stream from a content id of selected product
[02:48] <wallyworld> here's one http://streams.canonical.com/juju/tools/streams/v1/index2.json
[02:49] <anastasiamac> wallyworld: that's index file. m talking about product files
[02:49] <anastasiamac> content id of product
[02:49] <axw> the content ID is in the index as well. that's where we start
[02:50] <anastasiamac> that content id is notnecessarily the one we match on, we also look in products files
[02:51] <anastasiamac> this is why in simplestreams.go, l987 in my PR, function getLatestMetadataWithFormat deals with content id of the selected block
[02:51] <wallyworld> i can't find one at the moment
[02:51] <anastasiamac> happy to ho if it's easier for u
[02:51] <anastasiamac> wallyworld: i don't hink there is one
[02:52] <axw> anastasiamac: IndexReference.GetProductsPath does filter on product IDs in the index
[02:52] <wallyworld> there may not be currently
[02:52] <anastasiamac> u can have more than on product block (and content id) on index file but nor in product file
[02:52] <axw> anastasiamac: and that's where we're doing the "Pick arbitrary match"
[02:52] <axw> wallyworld anastasiamac: the current code would be broken with multiple products in an index too, except if we specify a stream in the constraints
[02:53] <anastasiamac> yes, that will get u a block of products, the method that i refered to, has htis under one metadaat and I work with content id in this metadata
[02:53] <wallyworld> that is true
[02:53] <wallyworld> i think we always pass in  a stream
[02:53] <wallyworld> an issue for me is the mixing of concerns
[02:53] <wallyworld> resolve info and stream
[02:54] <axw> anastasiamac: you only have one metadata *because* of that "Pick arbitrary match"
[02:54] <natefinch> wallyworld, menn0: oh, weird... https://github.com/juju/juju/blob/master/instance/instance.go#L63  yaml and json names differ
[02:54] <anastasiamac> currently stream is not at the right level, stream is a product concern (product can have many items)
[02:54] <anastasiamac> we do not have abstraction for products only resolve info and items
[02:54] <wallyworld> the stream on item is a denormalisation from memory
[02:55] <anastasiamac> it never worked because stream was never pulled from product
[02:55] <axw> anastasiamac: IMO, the best thing to do would be to have GetMetadata return a map of stream->[]metadata
[02:55] <wallyworld> natefinch: you found the deliberate typo we left in there :-)
[02:55] <menn0> natefinch: ick... I think using dashes is better
[02:55] <axw> and remove environs/imagemetadata.ImageMetadata.Stream
[02:55] <menn0> natefinch: but do we want to break people scripts?
[02:55] <menn0> people's
[02:56] <anastasiamac> axw: that'd b bigger change.
[02:56] <wallyworld> it would be but it corrects the code
[02:56] <anastasiamac> i'll abandon my approach, re-target the bug to 2.1 and someone more keen on getting simplestreams sorted can fix it the *right* way
[02:56] <wallyworld> why not just fix it for rc1?
[02:56] <wallyworld> we have 2 days
[02:57] <wallyworld> well, 1.5 :-)
[02:57] <anastasiamac> sure, ian. fix it
[02:57] <wallyworld> i have a long todo list today sadly
[02:58] <natefinch> menn0, wallyworld: actually ... I don't think we use that for output: hardware: arch=amd64 cpu-cores=2 cpu-power=550 mem=1800M root-disk=10240M availability-zone=us-east1-b
[02:58] <natefinch> menn0, wallyworld: there's a String() method that does the single line output
[02:58] <wallyworld> that sounds right
[02:58] <natefinch> so we may be saved from ourselves
[02:58] <menn0> natefinch: I wonder why those tags are there... if they're not used then they should go
[03:01] <natefinch> menn0: the package's tests still pass if I comment them out... I'll do a biggest test run later
[03:03] <menn0> natefinch: ok
[03:03] <menn0> natefinch: maybe they were used once but aren't any more
[03:04] <natefinch> menn0: could be
[04:14] <natefinch> damn frameworks
[04:16] <natefinch> Just realized, when there's an error parsing flags, the error is printed out and we never get to the Run function, so I can't print stuff out there to give context to the error from the flag.
[04:24]  * natefinch is gonna have to do something heinous
[04:46] <redir> wallyworld: so in `juju model-defaults aws/us-east-1 --reset ftp-proxy` would it always be aws/us-east-1 or might it also be just the region `juju model-defaults us-east-1 --reset ftp-proxy`?
[04:46] <wallyworld> axw: srtrictly speaking, the client.ModelInfo() and client.ModelUserInfo() calls should not be returning params structs. But nothing in juju calls then so I'm not sure if it's worth changing? http://reviews.vapour.ws/r/5677/
[04:46] <wallyworld> redir: we need to cater for just the region
[04:47] <wallyworld> hence the need to use the cloud api
[04:47] <wallyworld> to get the valid regions etc
[04:47] <redir> wallyworld: the spec shows the cloud and region
[04:48] <wallyworld> redir: it may do, but not exlicitly also showing just the region is an oversight
[04:49] <wallyworld> unless i am mistaken
[04:49] <wallyworld> for the single controller case it is not needed
[04:49] <wallyworld> and there will always be a current controller
[04:49] <wallyworld> so there's always a current default cloud
[04:49] <wallyworld> we don't want to make the user type stuff unnecessarily
[04:49] <redir> right
[04:50] <mup> Bug #1623324 opened: Support for subnets in MAAS created after juju is boostraped <4010> <juju-core:New> <https://launchpad.net/bugs/1623324>
[04:53] <axw> wallyworld: if there's no caller, should we just delete the client side code?
[04:55] <wallyworld> axw: hmm, yeah good point
[04:55] <wallyworld> i'll double check
[04:57] <wallyworld> axw: yeah, i can't see anywhere
[05:01] <wallyworld> thumper: you still going to delete list-shares and tweak the list-users command?
[05:09] <thumper> wallyworld: I'll do it in one go
[05:09] <thumper> yes, I'll do that one
[05:10] <wallyworld> thumper: no problem. i was asking because there is an api on the api/client facade which can be deleted one yourwork is done, the ModeluserInfo() one
[05:10] <wallyworld> i am removing the ModelInfo() one
[05:10] <thumper> no, because we'll probably still use it
[05:10] <wallyworld> ok, maybe it can be moved
[05:11] <wallyworld> i have a goal to one day remove the client facade entirely :-)
[05:14] <thumper> axw: are you looking at fixing the provisioner so it doesn't do everything one at a time?
[05:15] <thumper> I think we should seriously look into that as a solution
[05:15] <thumper> I'm looking at another bug (bug 1611111) which it would help fix
[05:15] <mup> Bug #1611111: Model still exists for a while after running destroy-model <oil> <oil-2.0> <juju:Triaged> <https://launchpad.net/bugs/1611111>
[05:48] <axw> thumper: not atm
[05:48] <axw> looking at azure creds changes now
[05:49] <axw> wallyworld: that "azure bootstrap experience" card is for creds, I'm moving back to in progress
[05:49] <axw> "speed up azure provider" is for current work
[05:54] <wallyworld> ah sorry, misread
[06:26] <mup> Bug #1623324 changed: Support for subnets in MAAS created after juju is boostraped <4010> <juju:Triaged> <https://launchpad.net/bugs/1623324>
[07:31] <axw> wallyworld: do you have an azure account?
[07:32] <wallyworld> axw: i do, it was a trial, i think it has expired but i can look to reactivate
[07:32] <axw> wallyworld: no worries, can probably just use the CI account
[07:32] <wallyworld> good point
[07:32] <axw> wallyworld: I've got a toy app that authenticates interactively and then creates a service principal
[07:33] <axw> just need to make sure it works when I'm using a different AD tenant
[07:33] <wallyworld> axw: oh nice ok
[07:33] <wallyworld> we can try with CI creds I guess
[07:35] <axw> wallyworld: ah hm, there are no CI creds published for azure (apart from service principal)
[07:36] <wallyworld> oh
[07:40] <frobware> axw: ping; based on your experience of azure is there anything we can or should be doing regarding DNS?
[07:42] <axw> frobware: I don't recall what the requirements are from charmers around DNS, so hard to say
[07:42] <axw> frobware: can you fill me in?
[07:42] <frobware> axw: i think my observations are more general though. I'm surprised that, given the machine's name, you cannot DNS resolve it.
[07:43] <frobware> axw: for example, on AWS I get `ip-A-B-C-D'. The resolver in /etc/resolv.conf can happily resolve the name.
[07:43] <axw> frobware: well, you can resolve using nslookup. it's just that dig doesn't seem to use the search from resolv.conf by default
[07:43] <frobware> axw: I just don't see that on the images launched on axure
[07:44] <frobware> axw: ah, ok... let me take another look.
[07:44] <axw> frobware: try "dig machine-0 +search"
[07:45] <frobware> axw: I wonder if the safest thing for us to do is rely on the results of getent(1).
[07:45] <frobware> axw: the domain name you get on Azure aspires to hungarian notation. :p
[07:46] <axw> frobware: well, they did invent it :)  sorry, I'm not familiar with getent
[07:46] <frobware> axw: getent allows you to make queries against database entries in /etc/nsswitch.conf
[07:46] <frobware> axw: so passwd, or hosts, or dns, or ...
[07:47] <frobware> axw: e.g., getent passwd $USER
[08:01] <axw> menn0: I'll be a couple mins late
[08:01] <menn0> axw: no probs
[09:37] <wallyworld> babbageclunk: hey, this has been raised in priority, can you take a look and see if anything jumps out? the error message sucks and we need to use errors.NotSupportedf() properly, but I wonder why it doesn't detect MAAS 2.0 properly?
[09:37] <wallyworld> bug 1623184
[09:37] <mup> Bug #1623184: ERROR MAAS version 1.9 or more recent is required not supported <juju:Triaged> <https://launchpad.net/bugs/1623184>
[09:38] <babbageclunk> wallyworld: Sure, I'm looking now
[09:38] <wallyworld> ty, you may see it and know straight away maybe :-)
[09:39] <wallyworld> i attempted to leave a comment that made sense after looking at the code
[10:35] <babbageclunk> wallyworld: I think it's a bad endpoint url
[10:36] <wallyworld> babbageclunk: makes sense. we should probably deal with that a bit better, print a more useful message
[10:36] <babbageclunk> wallyworld: Yeah, that's what I was thinking.
[10:38] <babbageclunk> wallyworld: bit tricky to distinguish between getting getting 404s because the URL's wrong or because none of the versions we support are supported, though. Thinking.
[10:38] <wallyworld> babbageclunk: yeah, i was having the same thought
[10:38] <wallyworld> there must be some validity check on the base part of the url or something
[10:39] <wallyworld> some http get that we can do to check
[10:39] <wallyworld> that works for both 1.9 and later
[10:39] <wallyworld> and if that fails, then bad url
[10:39] <babbageclunk> wallyworld: ok, I'll try to find something like that.
[10:39] <wallyworld> as well as static checks on the url itself
[10:40] <wallyworld> just a thought, you may come up with something better
[10:40] <babbageclunk> wallyworld: I'm reluctant to look inside the url
[10:40] <voidspace> wallyworld: babbageclunk: there isn't a single endpoint we can check for both versions
[10:41] <wallyworld> bollocks, i guess we'll need to try both
[10:41] <voidspace> wallyworld: babbageclunk: the official maas response when we requested that was we needed to check the 2.0 endpoint and if it wasn't there we were on 1.9
[10:41] <voidspace> wallyworld: babbageclunk: if we get an invalid response from both endpoints we should know we're incorrectly configured
[10:41] <wallyworld> right, but in this case, we got a false 1.9 error
[10:41] <voidspace> wallyworld: babbageclunk: and provide a better error message
[10:41] <wallyworld> correct
[10:41] <voidspace> instead of the current misleading one
[10:41] <wallyworld> yes
[10:42] <voidspace> cool
[10:42] <voidspace> a single endpoint telling us the version would be much better though :-/
[10:42] <wallyworld> yeah :-(
[10:45] <babbageclunk> voidspace, wallyworld: ok, so that's really just changing the error message in getCapabilities to say that the endpoint's wrong.
[10:45] <voidspace> babbageclunk: sounds like it
[10:45] <babbageclunk> sweet
[10:45] <wallyworld> babbageclunk: and also fixing the bad use of NotSupportedf
[10:45] <wallyworld> for the 1.9 case
[10:45] <babbageclunk> wallyworld: yeah, already done that :)
[10:45] <wallyworld> \o/
[11:50] <babbageclunk> Someone give the github -> reviewboard bot a kick?
[11:54] <babbageclunk> wallyworld, voidspace: review plz? http://reviews.vapour.ws/r/5680/
[11:56] <wallyworld> sure
[12:01] <wallyworld> babbageclunk: +1 with a suggestion
[12:03] <voidspace> babbageclunk: :LGTM
[12:03] <voidspace> babbageclunk: I'm agnostic on wallyworld's suggestion. There are times when it could be helpful, but there's no requirement that the MAAS api needs to be exposed at an endpoint ending with /MAAS
[12:04] <wallyworld> ok
[12:04] <voidspace> babbageclunk: wallyworld: so there are times when it won't be helpful (probably not hurtful though - so +0 I guess)
[12:04] <wallyworld> ignore me then :-)
[12:04] <voidspace> hah
[12:36] <axw> wtf happened to master? there's some code referring to status.StatusBlocked, which doesn't exist any more
[12:39] <axw> frobware: would whatever you're trying to do with DNS on azure be avoided by just encoding the IP in the hostname, like on ec2? ip-n-n-n-n
[12:39] <axw> frobware: i.e. so you can map between them without having to use DNS at all
[12:50] <frobware> axw: the reverse is still the problem. the big data charms (hadoop et al) want forward and reverse lookup. They are currently fudging their way around things.
[12:50] <frobware> axw: http://sujee.net/2012/03/08/getting-dns-right-for-hadoop-hbase-clusters/#.V9lHpGQrLDE
[12:51] <frobware> axw: we can do ip-A-B-C-D, the trouble is nothing has an answer for who-is A.B.C.D.
[12:52] <axw> frobware: I thought that was what the NSS plugin was for?
[12:52] <frobware> axw: I'm sure babbageclunk made a change around status
[12:52] <axw> frobware: yeah he did, somehow api/deployer is still referring to StatusBlocked. *shrug*
[12:52] <frobware> axw: right. the plugin will parse names of the format `juju-ip-A-B-C-D'. You get back A.B.C.D. Hadoop says, wtf is A.B.C.D and there is no answer.
[12:53] <frobware> axw: the plugin cannot be authoritative for arbitrary IP addresses, largely because of the order in /etc/nsswitch.conf.
[12:53] <axw> frobware: ah, ok
[12:53] <axw> I thought it always went through that
[12:54] <frobware> axw: the plugin get 'A.B.C.D' and I have no idea whether that was oringally an juju-ip- form, or something like archive.ubuntu.com...
[12:54] <frobware> axw: the plugin (desperately) wants to avoid state
[12:54] <axw> righto, makes sense
[12:55] <frobware> axw: it does go through the plugin. Well, kind-of. I haven't implemented getaddrinfo for ^ reasons.
[12:56]  * axw nods
[13:00] <babbageclunk> axw - maybe someone landed something that was in flight when my rename branch merged?
[13:02] <axw> babbageclunk: the other change came from wallyworld, but it was landed by the bot. bot should stop that from happening. weird :/
[13:02] <axw> I'll investigate more tomorrow
[13:02] <wallyworld> oops, what have i done
[13:03] <wallyworld> oh, bloody merge conflict :-(
[13:03] <wallyworld> how did that get through
[13:06] <axw> wallyworld: not your fault. bot weirdness
[13:06] <wallyworld> am fixing now.
[13:06] <wallyworld> there was a merge conflict
[13:06] <wallyworld> but i must have missed a couple
[13:06] <babbageclunk> I think it must have been queued while mine was building, then mine passed, yours started, then mine was merged.
[13:07] <babbageclunk> Then yours passed and was merged - it didn't conflict at the textual level.
[13:07] <babbageclunk> Maybe?
[13:08] <babbageclunk> Still pretty weird
[13:09] <wallyworld> yeah, we were making conflicting changes and it all sort of just landed together
[13:11] <wallyworld> babbageclunk: here is the fix, trivial http://reviews.vapour.ws/r/5681/
[13:11] <babbageclunk> LGTM!
[13:13] <wallyworld> ta!
[13:15] <babbageclunk> wallyworld: sorry, I was grabbing lunch when you and voidspace were discussing the URL - you're alright with me leaving the message the way it is?
[13:15] <wallyworld> yeah
[13:15] <wallyworld> i dropped it
[13:15] <babbageclunk> cool thanks!
[13:15] <wallyworld> was just a thought
[13:15] <wallyworld> to try and guide the user to the solution
[13:15] <wallyworld> if it's an obvious fix
[13:28] <babbageclunk> wallyworld: You made me feel bad for the users. What do you think of this message? "Couldn't get MAAS version - check the endpoint is correct (it normally ends with /MAAS)"
[13:29] <babbageclunk> wallyworld: suggestions to crispen it up welcomed!
[13:30] <babbageclunk> trying to hedge a bit with "normally", but it seems a bit wishy-washy.
[13:30] <voidspace> rick_h_: just grabbing coffee, be a few mins late to 1:1 (if you're around)
[13:33] <wallyworld> babbageclunk: lol. maybe even "could not connect to MAAS controller...."
[13:33] <wallyworld> the user doesn't need to be told exacrly what it is trying to do
[13:33] <babbageclunk> Yeah, true
[13:33] <wallyworld> just what it is trying to connect to
[13:34] <babbageclunk> And we prefer "Could not" to "couldn't" ?
[13:34] <wallyworld> i prefer not using a contraction but ymmv
[13:34] <wallyworld> also
[13:35] <wallyworld> if you are going to say normally ends with /MAAS, you'd want to check that it didn;t first
[13:35] <babbageclunk> Yes, I'm doing that (in some code you can't see)
[13:35] <wallyworld> and you'd also attempt to parse the url to tell them it was malformed if that's what the issue is
[13:36] <babbageclunk> I think that'll happen already (checking now).
[13:37] <babbageclunk> ERROR Get httpoo://<IP_ADDRESS>/api/1.0/version/: unsupported protocol scheme "httpoo"
[13:37] <wallyworld> ok
[13:38] <babbageclunk> I think we're at numberwang
[13:41] <voidspace> rick_h_: sorry about that, managed to accidentally shutdown my system
[13:41] <voidspace> rick_h_: I'm around if you are
[13:46] <frobware> babbageclunk: "cannot determine MAAS version ..."
[13:56] <rick_h_> voidspace: sorry, I cancelled because I'm still on west coast
[13:56] <rick_h_> voidspace: coming up on 7am here
[13:56] <voidspace> rick_h_: I thought that was likely to be the case - I didn't get a cancellation though, was still on my calendar
[13:56] <voidspace> rick_h_: ah well :-)
[13:56] <voidspace> rick_h_: morning o/
[13:57] <babbageclunk> frobware: I like wallyworld's reasoning that the user probably doesn't need to know exactly what we're trying to do when we couldn't connect to the controller.
[13:58] <frobware> babbageclunk: so "determine" was less specific. <shrug>
[13:59] <babbageclunk> Oh, I think determine's better than get, but not as good as "couldn't connect to MAAS controller".
[14:01] <rick_h_> natefinch: ping for standup
[15:08] <babbageclunk> can someone explain the relationship between cloudconfig and cloudconfig/cloudinit? I'm working on bug 1475260 and have a fix that works, but I'm not sure where it should go.
[15:08] <mup> Bug #1475260: instances cannot resolve their own hostname <juju:In Progress by 2-xtian> <juju-core (Ubuntu):Confirmed> <https://launchpad.net/bugs/1475260>
[15:12] <frobware> babbageclunk: ping; hostnames and ^ bug: are you testing on maas?
[15:13] <babbageclunk> frobware: no, on lxd - I think the userdata for maas is generated in some completely different way? And it seems like the maas dns ensures that the hostnames are resolvable, right?
[15:19] <frobware> babbageclunk: right - I was just running some tests... not sure we want managed_etc_hosts
[15:19] <babbageclunk> frobware: On maas?
[15:19] <frobware> babbageclunk: possibly anywhere... give me a few mins
[15:19] <babbageclunk> ok
[15:20] <frobware> babbageclunk: btw, cloud-init for containers is in juju/cloudconfig/containerinit
[15:21] <babbageclunk> frobware: Is that for LXDs inside maas/aws/other provider hosts?
[15:21] <babbageclunk> frobware: as distinct from the lxd provider?
[15:22] <frobware> babbageclunk: that's for LXD's inside a cloud/maas host
[15:22] <frobware> babbageclunk: make sense?
[15:22] <babbageclunk> frobware: yup, I think so. Although I'm not sure what I should do in that case.
[15:35] <frobware> babbageclunk: so my concerns is that you end up with: "<IP_ADDRESS> vmtest.home vmtest" in /etc/hosts
[15:35] <frobware> babbageclunk: and that we start handing out <IP_ADDRESS>
[15:36] <natefinch> alexisb: hey, just FYI - whatever bug had been causing my computer to take forever to get make the login screen work is evidently magically fixed (or I happened to twiddle the right config to avoid it sometime in the last few months)
[15:36] <babbageclunk> frobware: ok
[15:38] <babbageclunk> frobware: So what's the right solution?
[15:39] <frobware> babbageclunk: so maybe a combo of the NSS Juju plugin and a fix to https://bugs.launchpad.net/juju/+bug/1623480
[15:39] <mup> Bug #1623480: Cannot resolve own hostname in LXD container <lxd> <network> <juju:New> <https://launchpad.net/bugs/1623480>
[15:40] <frobware> babbageclunk: I think we can certainly try that but we should try it with some charms
[15:42] <frobware> babbageclunk: given the original bug I was trying to understand whether instance is the host (hosting the container), or just containers, or possibly both.
[15:43] <frobware> babbageclunk: if you don't see the issue in MAAS (2.0) then that's because we have working DNS \o/
[15:44] <frobware> babbageclunk: as long as "things" handle localhost then manage_etc_hosts: "true" should be fine. but there's work to confirm that.
[15:45] <babbageclunk> frobware: I'm not sure what you mean by "things" handle localhost.
[15:45] <frobware> babbageclunk: s/w -- all the s/w. :)
[15:45] <babbageclunk> lolz
[15:46] <frobware> babbageclunk: what does hadoop do when you tell it, "hey, here's my hostname/address... <IP_ADDRESS>" ....
[15:46] <frobware> babbageclunk: well, that will obviously be perfectly fine on a single machine.
[15:47] <babbageclunk> But I guess there's a risk that various units will report their address to others as that?
[15:49] <frobware> babbageclunk: exactly. if you say contact me on <IP_ADDRESS> then... well... we'd better be living in the same shoe box.
[15:52] <perrito666> morning all
[15:52] <natefinch> wow, neat.... the visual studio code find/replace window shows you a preview of all the changes that'll be made if you make that find and replace
[15:56] <babbageclunk> frobware: Would you mind commenting to that effect on the bug? Would be good to get input from the bug reporter.
[16:01] <frobware> babbageclunk: done
[16:01] <babbageclunk> frobware: Thanks!
[16:04] <natefinch> ahhhhhhhhhhh who makes a field for Memory (RAM) and doesn't tell you what the units are? :/  https://github.com/juju/juju/blob/master/instance/instance.go#L61
[16:05] <alexisb> perrito666, you around?
[16:05] <perrito666> alexisb: yes I am
[16:05]  * perrito666 feels a bug comin his way
[16:58] <babbageclunk> Can someone review this revert? http://reviews.vapour.ws/r/5682/
[16:58] <babbageclunk> alexisb asked me to do it.
[17:01] <alexisb> perrito666, can you help out babbageclunk pleas
[17:01] <alexisb> e
[17:01] <alexisb> I need to get testing going again for master
[17:01] <perrito666> alexisb: I am reviewing the patch
[17:02] <perrito666> babbageclunk: why would you revert https://github.com/juju/juju/commit/693ef8e2d2812df11d24edf35ee4853e7b4c20a2 ?
[17:02] <perrito666> babbageclunk: so it will be faster here.
[17:03] <perrito666> I would guess you are reverting a full merge so:
[17:03] <perrito666> 1) what is the full merge being reverted
[17:03] <perrito666> 2) why, if possible, with a link to a regression bug or at least jenkins failure?
[17:03] <babbageclunk> perrito666: I didn't really look at the commits, just reverted all of the ones in the PR.
[17:03] <babbageclunk> Ok, I'll add those to the description of the PR.
[17:04] <babbageclunk> (Actually, alexisb, links to the regressions?)
[17:04] <alexisb> babbageclunk, let me get you the bug
[17:05] <alexisb> https://bugs.launchpad.net/juju/+bug/1623560
[17:05] <mup> Bug #1623560: Juju rc1 cannot deploy applications to openstack or centos <centos> <ci> <deploy> <openstack-provider> <regression> <juju:Triaged> <https://launchpad.net/bugs/1623560>
[17:05] <alexisb> ^^^ this is teh regression we need to address
[17:09] <babbageclunk> perrito666: Added
[17:10] <perrito666> babbageclunk: ship it
[17:10] <babbageclunk> perrito666: sweet
[17:10] <perrito666> babbageclunk: plus add relevant information to the regression bug please
[17:11] <perrito666> and send an email to the author of the offending commit so they lear it from the source
[17:11] <perrito666> sorry for raining on your parade :p
[17:12] <natefinch> BTW, the easiest way to revert a merge is to do it through the github UI.  That way you're ensured that all you're doing is reverting the merge.... that falls down if there are conflicts, but if there aren't, it basically means there's no need for a real code review.
[17:13] <babbageclunk> perrito666: Ok - alexisb said that she'd let them know, but you're right, better to be sure.
[17:13] <babbageclunk> natefinch: Thanks, I'll try that next time. (There weren't any conflicts with this one so that would have worked.)
[17:19] <perrito666> annyone getting ERROR cannot fetch model settings ?
[17:19] <babbageclunk> bye everyone! Have a lovely day!
[17:20] <natefinch> perrito666: what's the exact error?
[17:21] <perrito666> natefinch: what I just pasted
[17:21] <natefinch> perrito666: oh, weird.  Uh, run with --debug?
[17:31] <perrito666> natefinch: found it, changed a slice into an array and forgot to change append into array[i]=blah
[17:32] <natefinch> ahh
[17:34] <perrito666> its interesting how many wrong error cases are being caught by the "upgrading" failsafe, that is going to gives us problems very soon
[17:35] <natefinch> ug
[17:47] <perrito666> the agent lost before idle issue is very annoying
[19:05] <natefinch> holy crap.... https://github.com/blog/2256-a-whole-new-github-universe-announcing-new-tools-forums-and-features
[19:05] <natefinch> kanban on github.com itself.  real reviews on PRs (bundled comments, approve/request changes etc)
[19:09] <alexisb> natefinch, that would be awesome
[19:10] <natefinch> alexisb: totally.  If we used github issues it would be even better, but I'm sure we could make it work with boring old links to launchpad like we've been doing anyway.
[19:11] <natefinch> alexisb: dropping our dependence on reviewboard would be nice. We'd have to take the PR reviews on github for a spin, but it seems like there's very little advantage to reviewboard at this point
[19:12] <alexisb> yep
[19:14] <natefinch> heh, github won't let me start a review of my own code. Boo.
[20:14]  * perrito666 takes reviewboard to the back yard and shoots it
[20:15] <natefinch> haha
[20:15] <perrito666> alexisb: natefinchis the bot down?
[20:15] <perrito666> my merge request has not been answered
[20:16] <natefinch> I saw some merges that hadn't been finished since last night
[20:16] <natefinch> sinzui: ^^
[20:16] <natefinch> mgz: ^
[20:17] <alexisb> perrito666, I will ask I am on with the QA team now
[20:19] <perrito666> alexisb: wat does that mean, did you switch teams?
[20:19] <alexisb> perrito666, mean I am on teh QA standup
[20:19] <alexisb> they are looking into it
[20:19] <perrito666> you are efficient
[21:02] <menn0> alexisb: ping?
[21:02] <alexisb> heya menn0 just got on with thumper
[21:03] <menn0> alexisb: ok
[21:03] <menn0> alexisb: I was joining our HO and saw you were in there and then you disappeared
[21:03] <alexisb> menn0, sorry
[21:15] <alexisb> ok menn0 I am free if you have time to chat
[22:05]  * thumper tries to get some hacking done before next call
[22:56] <axw> looks like juju hit 500 stars today
[23:01] <anastasiamac> axw: which stars?
[23:03] <axw> anastasiamac: github
[23:12]  * elmo points at the sky - you know, the stars!
[23:14] <alexisb> elmo, lol
[23:15] <redir> stanup ?
[23:16] <redir> stand even
[23:41] <menn0> axw: question about provider/azure/envrion.go line 901. I don't think os.Arch should be handled there. Do you agree?
[23:41] <menn0> axw: we don't support Arch Linux instances do we?
[23:45] <alexisb> ok anastasiamac
[23:45] <alexisb> I will meet you in our 1x1 HO
[23:45] <anastasiamac> alexisb: k
[23:59] <axw> wallyworld: I'm just running all the unit tests now, have already done a live test on this. would appreciate a review ASAP: https://github.com/juju/juju/pull/6247
[23:59] <wallyworld> sure


[11:47] <C-O-L-T>  amarok has written to me that 150 songs visible of 600 why?????????????????????????????????????????
[11:47] <topyli> AMCDeathKnight: yes
[11:47] <cdubya> bueller, yes
[11:47] <Stork> lowman62, it's not hard to build your own computer
[11:47] <dukebody> that's a question Stork
[11:47] <Stork> dukebody, good point
[11:47] <bueller> do you have a link?
[11:47] <AMCDeathKnight> got ya ok fixed and will reboot and try
[11:47] <butcherbird> bueller: see wiki.ubuntu.com search for mp3
[11:47] <cdubya> !restrictedformats
[11:47] <ubotu> extra, extra, read all about it, restrictedformats is https://wiki.ubuntu.com/RestrictedFormats Most of the formats listed here have been replaced by !FreeFormats
[11:47] <AMCDeathKnight> Thanks :-)
[11:47] <liable> C-O-L-T: excessive punctuation like that is very annoying, as is asking twice in 30 seconds.
[11:48] <lowman62> Stork: once upon a time i was a truck driver...I stayed up lots of times...have the samsonite lugage to prove it under my eyes..so do me a favor lil person...climb back into your creepy lil porn site and stay there I was not talking to you anyways...flush!
[11:48] <Andrew[CS] > wuts the command to install suff again
[11:48] <PuMpErNiCkLe> bueller: I found the problem, and I'm going to paste an update version of your xorg.conf file that fixes it.
[11:48] <cdubya> bueller, that should do it.
[11:48] <topyli> Andrew[CS] : sudo apt-get install "stuff"
[11:48] <kameron> i was reading here: https://wiki.ubuntu.com/RestrictedFormats#head-fda9cc5147253891fe3047263b82d787ab025bba but it only shows a deb file for x86. can i get win32codecs for amd64?
[11:48] <Andrew[CS] > ty
[11:48] <preglow> i get a nice little error when trying to compile any program in my brand new breezy install: /usr/bin/ld: crt1.o: No such file: No such file or directory
[11:48] <lowman62> Stork: Dork!
[11:48] <C-O-L-T> liable: a lot of people are writing here, and in a few moments my message becomes unvisible
[11:48] <preglow> any pointers on how to fix this?
[11:48] <Stork> lowman62, what the hell is "flush"? go build a crappy computer, loser.
[11:48] <dukebody> what, Stork ??? sorry i'm spanish
[11:48] <PuMpErNiCkLe> bueller: You want 1024x768, right?
[11:49] <Motoko-chan> ...
[11:49] <Andrew[CS] > sudo apt-get install ??
[11:49] <topyli> yes
[11:49] <bueller> yes pump
[11:49] <lowman62> Stork: come to my house and say that to my face lil person...don't hide behind your lil cheesy emachine and blabber crap...make yourself appear in person then we will see
[11:49] <trappist> preglow: sudo apt-get install build-essential (that particular file belongs to libc6-dev)
[11:49] <Andrew[CS] > and Pumpernickel, i want a res like that
[11:49] <bueller> wow im getting excited
[11:49] <Andrew[CS] > the max i can get it 800*600 *cries*
[11:49] <Zugwrack> !pastebin
[11:49] <ubotu> methinks pastebin is a site where you can post large texts and screenshots so you don't flood the channel. You can find it at http://paste.ubuntu-nl.org
[11:49] <bueller> <----has been trying for a few hours
[11:50] <bueller> to get resolution fixed
[11:50] <Stork> lowman62, stop being an e-thug. Go clean your glasses or something.
[11:50] <kameron> anyone get win32codecs working with amd64?
[11:50] <preglow> trappist: how come that isn't a dependency? not requiring crt1.o in a working c install is... strange...
[11:50] <Chousuke> Stork: lowman62: Stop.
[11:50] <tenshu> Hello all , actually the great remote controller from ATI: remote wonder had some bug (incorrect/unrecognized key). I help giving info on Bugzilla, but nobody seems to be interested in.  Both USB.
[11:52] <butcherbird> yggdrasil: breezy?
[11:52] <_max_> Andrew[CS]  if you expect to get help in a linux channel state a proper question, wait atleast 10 minutes before asking again and dont spam.
[11:52] <mwe> yggdrasil: you have to make a new one. next time please back it up before messing with it
[11:52] <Motoko-chan> They seem labeled fie to me
[11:52] <yggdrasil> butcherbird yea
[11:52] <iKrnel> Hi guys. This is my first time using ubuntu, I must say, it is pretty fast! :D
[11:52] <trappist> preglow: it's possible to compile ye olde c app without all the stuff in build-essential.  it would suck to have to install all that, if I didn't want to, just to compile my hello world.
[11:52] <mwe> yggdrasil: pastebin it and i'll clean it up for you
[11:52] <Motoko-chan> ubuntu-version-type-arch.iso
[11:52] <bueller> how to replace pumper?
[11:53] <lowman62> _max_: RTFM <--there that used to be the most common response geesh chill out
[11:53] <Bjelleklang> does anyone know about some kind of text-based hardware monitor?
[11:53] <yggdrasil> mwe ok
[11:53] <Bjelleklang> that can be used from ssh?
[11:53] <preglow> trappist: you can't compile any c program without the c runtime libs, hello world included
[11:53] <iKrnel> But I have a problem. I don't know what the default root password is. I don't have an ubuntu manual, and the wiki didn't help. Can anybody help me?
[11:53] <jhenn> is there a way to downgrade from dapper to breezy?
[11:53] <Motoko-chan> Bjelleklang, depends on what the hardware is.
[11:53] <david1> hey, does anyone know if it's possible to make animated gifs using gimp?
[11:53] <_max_> free~lowman62: problem is linux newbies dont know what RTFM stands for so you gotta slap the basics nowdays.
[11:53] <kameron> Motoko-chan that's BS man. there's got to be some way to get win32codecs working in my amd64 install
[11:53] <jhenn> iKrnel: sudo -s
[11:53] <mwe> jhenn: yeah. reformat and install over :)
[11:53] <Motoko-chan> kameron, have fun.
[11:53] <janoli> dapper is the lastest ?
[11:53] <trappist> preglow: you mean without the headers?  I s'pose that's true, unless you write your own, which is not unheard of
[11:53] <Motoko-chan> Note the 32 part
[11:53] <Motoko-chan> 32-bit
[11:53] <Andrew[CS] > dambitg
[11:54] <kameron> Motoko-chan haha, thanks man. i hope i'll find a way.
[11:54] <iKrnel> jhenn: It wants me to type in the password for root.
[11:54] <Motoko-chan> If you are native 64-bit, it won't work.
[11:54] <rjb> hi folks, is an AMD Turion a k8?
[11:54] <iKrnel> jhenn: ...which I don't have...
[11:54] <preglow> trappist: this wasn't the headers, this was the c runtime. the very code that actually calls main()
[11:54] <jhenn> iKrnel: type the user password
[11:54] <iKrnel> whoa that's hax!
[11:54] <Motoko-chan> rjb, cat /proc/cpuinfo
[11:54] <Bjelleklang> had a look at lm_sensors, but couldn't get it up and running
[11:54] <lowman62> _max_: exactly what my point was...they are newbies and nothing turns a newbie off a new thing more than someone bulling them...try being nicer you get more for less
[11:54] <Stork> hi, can anyone tell me the commands i'd need to split my hdd into two parts (80gb, and 80gb) while keeping my current data?
[11:54] <jhenn> iKrnel: if its not your machine  your not going to be able to and I'm not going to help you break into it
[11:54] <IdleOne> how do i install libglib1.2 libgtk1.2 libstdc++5 ?
[11:54] <rjb> Motoko-chan, and..?
[11:54] <iKrnel> jhenn: Anyway to disable that option?
[11:54] <trappist> preglow: I'm not a big c guy, but if that's the code that calls main() how does anything run, let alone compile, without it?
[11:54] <Motoko-chan> Look at the output
[11:54] <Bjelleklang> and don't have access to the gui...
[11:54] <jhenn> iKrnel: what option?
[11:55] <PuMpErNiCkLe> bueller: copy it, save it in a file called 'xorg.conf' in your home folder, and then run 'sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup && sudo cp ~/xorg.conf /etc/X11/xorg.conf'
[11:55] <_max_> lowman62 i dont care for being nice to people who can't act more mature than a 13 year old on crack.
[11:55] <mwe> Stork: um you need parted I think
[11:55] <preglow> trappist: that's the deal, it didn't :) i got errors whenever i tried to compile something
[11:55] <iKrnel> jhenn: sudo -s. Lets you become root without the root password. I don't like it.
[11:55] <Zugwrack> IdleOne...checkout restricted...it will install some of what you want...with command line information
[11:55] <lowman62> _max_: I want the world to use linux and send billy bouy gate high steppin
[11:55] <rjb> wow i sort of guessed I should look at it, but it doesn't answer my question
[11:55] <mwe> Stork: but I think you need to run it from a live-cd
[11:55] <Stork> i don't understand partitions, lol
[11:55] <jhenn> iKrnel: just make sure other users aren't in the sudoers file
[11:55] <Motoko-chan> It should say in there somewhere...
[11:55] <IdleOne> Zugwrack,  restricted?
[11:55] <PuMpErNiCkLe> bueller: And make sure when you copy it, you don't copy the numbers along the left-hand side. :)
[11:55] <Motoko-chan> I don't have an AMD handy to check.
[11:55] <iKrnel> jhenn: Ah, good point.
[11:55] <_max_> free~lowman62: nothing would please me more than the world to use opensource but they need to go a course in decent behaviour
[11:55] <_max_> linux channels used to be filled with intelligent well stated questions.
[11:56] <rjb> cpu family      : 15
[11:56] <rjb> model           : 36
[11:56] <_max_> not spam with "speedtalk" and other crap thats not readible or hurts your eyes.
[11:56] <yggdrasil> mwe its done
[11:56] <iKrnel> jhenn: This is most probably a dumb question, but how do I find out the root password from here?
[11:56] <Stork> brb, booting from livecd so i can partition!
[11:56] <rjb> that's what it says
[11:56] <mwe> yggdrasil: where did you paste it?
[11:56] <Telemachus> _max_ :  I toatally agree with you
[11:56] <lowman62> _max_: respect ...I understand and you are right...just that they are a newbie and don't know the rules just like you once upon a time didn't
[11:56] <jhenn> iKrnel: there is no root password
[11:56] <rjb> nothing about k8 or k-anything
[11:56] <Zugwrack> IdleOne: Just issue this command and read... !restricted
[11:56] <iKrnel> jhenn: Ah. Well, I'll have to set one...
[11:57] <IdleOne> !restricted
[11:57] <ubotu> extra, extra, read all about it, restricted is https://wiki.ubuntu.com/RestrictedFormats  Most of the formats listed here have been replaced by !FreeFormats
[11:57] <preglow> trappist: anywho, i just think it's curious. everything works just fine and dandy now, thanks again
[11:57] <bueller> copy it, save it in a file called 'xorg.conf' in your home folder, and then run 'sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup && sudo cp ~/xorg.conf /etc/X11/xorg.conf'
[11:57] <IdleOne> ty
[11:57] <bueller> is the && syntax?
[11:57] <_max_> lowman62 i never spammed a channel with crap ;) i once saw a bot where you could get it to pm someone "how to aproprietly ask something in a linux channel" should bring one in here ;p
[11:57] <jhenn> !root
[11:57] <ubotu> By default, the root password is locked in Ubuntu. Look at http://wiki.ubuntu.com/RootSudo for all information.
[11:57] <jhenn> iKrnel: ^^
[11:57] <PuMpErNiCkLe> bueller: And to start using the new xorg.conf, hit ctrl-alt-backspace (NOTE: this will quit any graphical applications you have running.)
[11:57] <Andrew[CS] > !amsn
[11:57] <ubotu> it has been said that amsn is at http://amsn.sourceforge.net
[11:57] <PuMpErNiCkLe> bueller: yes
[11:57] <bueller> k ;)
[11:57] <kemik> !tell _max_ about coc
[11:57] <cyphase> has anyone gotten their breezy cd's yet?
[11:58] <Andrew[CS] > but no, ubuntu
[11:58] <greenpenguin13> ages ago
[11:58] <Andrew[CS] > doesn't have that version
[11:58] <Motoko-chan> rjb, I looked it up and I see that any of the AMD chips supporting 64-bit is a K8
[11:58] <_max_> thanks kemik :)
[11:58] <kemik> Andrew[CS] :  either you stick with what's in the repositories, or you have to compile it yourself (at your own peril)
[11:58] <Motoko-chan> The Turion64 is.
[11:58] <rikai> brb, installing memory <.<;
[11:58] <mwe> cyphase: I heard someone from sweden got em in a few days
[11:59] <rjb> ok so linux-image-k8 might work better than linux-image-amd64-generic?
[11:59] <Motoko-chan> Might.
[11:59] <lowman62> _max_: some aren't as fortunate or as patient to read the f***ing manual either...I once stepped into a world of hell asking the wrong question in a mandrake channel...I got jumped on ...uninstalled and went back to my windows world in fear of linux...come on..ubuntu is cool and the idea is that it is for everybody...even those that can't read
[11:59] <Motoko-chan> You can try and see.
[11:59] <kemik> _max_:  yw ;)
[11:59] <Motoko-chan> Just make sure you can revert.
[11:59] <butcherbird> cyphase: youll get your breezy cds 3 months after dapper comes out and youll like it that way
[11:59] <rjb> what i wanna get right is suspend (sleep mode)
[11:59] <_max_> free~Andrew[CS] : Gaim is just as good as amsn.
[11:59] <rjb> my system hangs hard when awaking from sleep


[21:02] <antoniotf> hello
[21:02] <antoniotf> i want to ask something about a Presentation i have upload to ubuntuspread.org


[01:43] <roaksoax> bigjools: maas-dhcp should be on the cluster right?
[01:43] <bigjools> roaksoax: yes
[01:43] <bigjools> you *just* caught me, about to go to lunch
[01:44] <roaksoax> bigjools: enjoy
[01:44] <bigjools> :)
[03:05] <roaksoax> bigjools:
[03:05] <roaksoax> Failure: twisted.internet.error.ConnectionRefusedError: Connection was refused by other side: 111: Connection refused.
[03:05] <roaksoax> 2013-09-20 12:03:12+0900 [Uninitialized] Stopping factory <HTTPClientFactory: http:///MAAS/api/1.0/pxeconfig/?cluster_uuid=5c11d0fa-6b41-4cd6-b278
[03:12] <bigjools> roaksoax: I have never seen that
[03:13] <roaksoax> bigjools: we are seeing this right now ;/
[03:13] <roaksoax> how does pserv get that address?
[03:13] <bigjools> what address?
[03:13] <roaksoax> bigjools: the address of the region
[03:14] <bigjools> DEFAULT_MAAS_URL
[03:14] <bigjools> has to be contactable by the nodes
[03:14] <bigjools> and clusters
[03:14] <roaksoax> bigjools: it is
[03:14] <roaksoax> but pserv is trying to contact without address:"  http:///MAAS/api/1.0/pxeconfig/?cluster_uuid=5c11d0fa-6b41-4cd6-b278
[03:14] <bigjools> oh I see now!
[03:14] <bigjools> jtv1: ^
[03:14] <bigjools> halp
[03:15] <roaksoax> bigjools: this is kind of critical btw
[03:16] <bigjools> roaksoax: what is in /etc/maas/maas_cluster.conf
[03:16] <bigjools> the MAAS_URL in there should be the region's
[03:16] <roaksoax> it is
[03:17] <bigjools> so that Connection refused error is in the pserv log?
[03:18] <bigjools> roaksoax: ^
[03:18] <freeflying> roaksoax, seems the same
[03:20] <bigjools> roaksoax: can you sniff its tcp and see what it's trying to connect to
[03:20] <bigjools> it's just a bad config somewhere
[03:20] <bigjools> or perhaps a proxy getting in the way
[03:20]  * jtv1 reads backscroll
[03:22] <roaksoax> yes p serv.log
[03:24] <roaksoax> bigjools: this is multinode maas btw
[03:24] <bigjools> roaksoax: you mean multi cluster?
[03:25] <roaksoax> ok hold on
[03:25] <roaksoax> it seems squid homehow messing things up
[03:25] <roaksoax> but it shouldn't
[03:28] <jtv> Might be worth checking whether the start-cluster-controller command line has the right server URL.
[03:28] <bigjools> that's what I was juuuust about to say
[03:29] <bigjools> jtv: it comes from MAAS_URL in the maas_cluster.conf file right?
[03:29] <jtv> If it doesn't, then either /etc/maas/maas_cluster.conf is messed up, or alternatively I'd say something changed in how upstart scripts work.
[03:29] <bigjools> I think that's what the packaging uses
[03:29] <jtv> Yes.
[03:29] <jtv> The upstart script sources that config file, then passes $MAAS_URL on the command line.
[03:30] <jtv> Oh.
[03:30]  * jtv checks something...
[03:30] <bigjools> roaksoax: /etc/init/maas-cluster-celery.conf starts it remember
[03:31] <roaksoax> yeah looking at it
[03:31] <bigjools> but you said that config was already ok
[03:31] <bigjools> so squid getting in the way?
[03:31] <jtv> How could squid get in this particular way?
[03:31] <roaksoax> bigjools: yeah, otherwise it would not have registered the cluster controller in the region
[03:31] <bigjools> roaksoax: right
[03:31] <bigjools> jtv: it could be down :)
[03:32] <jtv> Down, sure.  But mangling URLs..?
[03:33] <bigjools> who knows what its config us
[03:33] <bigjools> is
[03:34] <roaksoax> maybe a dirty pyc file?
[03:35] <bigjools> unlikely
[03:35] <jtv> Could happen with permissions problems and an upgrade, I suppose.
[03:36] <roaksoax> jtv: clean system
[03:36] <bigjools> roaksoax: have you traced the tcp?
[03:36] <bigjools> ethereal or something
[03:36] <bigjools> tcpdump
[03:37] <bigjools> take it one step at a time and divide the problem into possible areas
[03:38] <roaksoax> bigjools: https://pastebin.canonical.com/97785/
[03:40] <bigjools> roaksoax: stops short ...
[03:40] <roaksoax> bigjools: repeats itself
[03:40] <bigjools> roaksoax: is it connecting to the right place?
[03:41] <roaksoax> bigjools: yeah
[03:41] <roaksoax> again, otherwise the cluster controller would not have registered itself
[03:41] <bigjools> roaksoax: ok if you trace on the region controller do you see traffic?
[03:41] <roaksoax> bigjools: hold on, i rebooted the cluster
[04:10] <bigjools> jtv: roaksoax: so the config actually comes from /etc/maas/pserv.yaml
[04:10] <bigjools> tftp:generator:
[04:11] <bigjools> roaksoax: so I suspect the bug is in the packaging and it doesn't set that file up properly sometimes
[04:11] <bigjools> maybe a race condition with another package
[04:11] <bigjools> and the wrong one got installed first
[06:04] <freeflying> where can I watch commissioning log?
[06:41] <freeflying> bigjools, now I can  enlist node, but have problem to commission it, have apt_proxy in enlist_data and commission, any clue?
[06:43] <freeflying> jtv, ^^
[07:01] <jtv> Hi freeflying
[07:01] <jtv> I think a commissioning node will direct its syslog to either the region controller or the cluster controller...
[07:02] <jtv> Look for an "rsyslog" log.
[07:03] <freeflying> jtv, no log there
[07:04] <freeflying> jtv, it gives connect to 169.xxx fails, after it get ip address
[07:05] <jtv> The node says that on its console?
[07:05] <freeflying> yes
[07:05] <jtv> Any idea what the 169.xxx address is?
[07:06] <freeflying> no, all address we're using within 10.x.x.x
[07:07] <freeflying> looks that is epheremal image?
[07:08] <jtv> Yes, commissioning runs an ephemeral image.
[07:08] <jtv> But I don't think the node should be talking to the internet at that point.
[07:09] <jtv> Doesn't look as if it's the Ubuntu archive either, although I suppose it might be your local mirror.
[07:10] <freeflying> why its calling its calling <IP_ADDRESS>/2009-04-04/meta
[07:11] <jtv> So that's where it's trying to find its metadata service.
[07:11] <jtv> Strange address...
[07:12] <freeflying> jtv, where shall I configure it, or is it because it can't access to maas-regional contoller
[07:12] <jtv> That's a zeroconf address.  Any chance there's a wifi interface being mistaken for your server?
[07:12] <freeflying> jtv, no
[07:13] <freeflying> thre are 8 ports on the server, 1 of them are 10 gig, for of them are 1 gig;s
[07:14] <jtv> At least, when I use "whois" on it, it says computers use 169.154.*.* (note 154, not 254!) when they don't have an IP address and don't get one from the network.
[07:14] <freeflying> from weui, the metatada_url was set to maas regionl's
[07:14] <jtv> And that's a 10.*.*.* address, right?
[07:15] <jtv> And no 169.*.*.* networks at all?
[07:15] <rvba> <IP_ADDRESS> is used in Amazon EC2 and other cloud computing platforms to distribute metadata to cloud instances.
[07:15] <jtv> !
[07:15] <rvba> So cloud-init is acting up.
[07:16] <jtv> Thinking this is EC2...
[07:17] <rvba> cloudinit/sources/DataSourceEc2.py:DEF_MD_URL = "http://<IP_ADDRESS>"
[07:17] <freeflying> jtv, yes, in the preseed generated for commissioning is <IP_ADDRESS>/MAAS
[07:17] <rvba> (this is in the cloud-init source code)
[07:19] <jtv> I'm looking at the cloud-init source now...
[07:23] <rvba> I suspect the node can't reach the region and thus cloud-init falls back to using the EC2 metadata address.
[07:23] <jtv> Ah, I was thinking it might not have received the right configuration...
[07:25] <rvba> Well, I don't see how the EC2 IP could originate from MAAS.
[07:27] <jtv> Neither do I...  I was thinking that cloud-init might not have received the right configuration, and decided to try things the EC2 way.
[07:27] <jtv> I'm trying to figure out how cloud-init chooses the DataSource to use.
[07:27] <rvba> That's possible indeed.  But from what freeflying was saying, it seems the configuration is right.
[07:28] <rvba> freeflying: if cloud-init errors somehow (and uses the EC2 address as a — somewhat crezy — fallback), you will see errors on the node console while it is commissioning… do you have access to it?
[07:29] <freeflying> rvba, you mean the kvm?
[07:30] <jtv> The screen, yes.
[07:32] <rvba> freeflying: well, the node's screen if it is a physical machine.
[07:33] <freeflying> let me post a screenshot
[07:34] <jtv> ("kvm" can be either the mouse/keyboard switch on a physical machine, or a commonly used type of virtual machine)
[07:35] <freeflying> in this case, it mean mouse/keyboard :)
[07:37] <rvba> Well, it's the V in KVM that I'm interested in :)
[07:41] <freeflying> people.canonical.com/~zhengpenghou/20130920_162508.jpg
[07:42] <freeflying> uploading
[07:42] <jtv> Thanks
[07:42] <jtv> Yup, that's cloud-init running out of DataSource candidates.
[07:43] <rvba> Yep
[07:43] <jtv> AFAICS cloud-init tries to download data from various sources, until it finds one that works.
[07:44] <jtv> It's not finding any.
[07:44] <freeflying> any suggestion?
[07:45] <jtv> We'll have to find the root cause first...  Do you have a way of verifying that the nodes can reach the given IP address?
[07:45] <rvba> When I encountered that problem (cloud-init was using the EC2 IP), it was because the node could not reach the MAAS IP address.
[07:46] <rvba> So it's worth checking, as jtv said.
[07:46] <jtv> It would be ideal if you could access the full URL on http...  if you get a 404, it's likely to be a problem in the URL configuration.
[07:46] <jtv> If it's a permissions error, then it should just have worked and we have a mystery.
[07:46] <jtv> If it's a networking error, then there's our problem.  :)
[07:46] <freeflying> jtv, no, the node never fails to be commissioned
[07:47] <jtv> I thought it failed during commissioning..?
[07:47] <freeflying> jtv, funny thing is I do have 1 node commissioned :)
[07:47] <freeflying> jtv, yes
[07:48] <jtv> I don't understand... if it fails during commissining, then the node fails to be commissioned, right?
[07:48] <freeflying> before cloud-init gives the error info, I did see the commissioning node get ip
[07:49] <jtv> So DHCP is working...  did it get its IP from the right server?
[07:49] <freeflying> jtv, I enlist 3 machines, 1 succeeded, not the other 2
[07:49] <freeflying> jtv, yes
[07:50] <rvba> Is there anything special about these two machines network-wise?
[07:50] <freeflying> rvba, this could be a issue, but not sure
[07:50] <jtv> Are all the nodes visible in the web UI, and similarly (correctly) configured?  If something went wrong there, they might fail to get to the metadata service.
[07:51] <freeflying> jtv, all of them are listed in webui
[07:52] <jtv> If we're very lucky, the metadata server log will show the nodes' requests...
[07:52] <rvba> So one of them is "ready" and two of them stuck "commissioning", correct?
[07:52] <freeflying> rvba, exactly
[07:53] <freeflying> rvba, and have proxy set up in both commissioning/enlist_data
[07:54] <freeflying> jtv, rvba would like t have a check?
[07:55] <jtv> Always worth a check...  if you have a way to simulate an http request to that URL from the same node, that might tell us something too.
[08:12] <jtv> (I should say: by "that URL" I mean the metadata URL)
[08:13] <rvba> I see requests to the metadata service from <IP_ADDRESS>{0,1,2,3}.
[08:14] <jtv> freeflying: which node is the successful one?
[08:15] <rvba> jtv: the errors in maas/maas.log are concerning
[08:16] <rvba> The "PermissionDenied: Not authenticated as a known node." errors.
[08:16] <jtv> And first, a problem registering the node group..?
[08:17] <rvba> The two problems might be linked…
[08:17] <jtv> Yup.
[08:18] <jtv> Looks like the NodeGroupWithInterfacesForm.
[08:18] <freeflying> jtv, working node called xggt6
[08:18] <rvba> freeflying: we need its IP or it's uuid.
[08:18] <jtv> freeflying: do you know the last number of its IP address?  We see 4 machines making requests to the metadata service.
[08:19] <freeflying> rvba, <IP_ADDRESS>
[08:19] <jtv> Thanks!
[08:19] <rvba> freeflying: you said you had a config with 2 clusters right?
[08:19] <rvba> s/had/have/
[08:19] <freeflying> rvba, 1 cluster 1 regional
[08:20] <rvba> freeflying: when you go to the settings page, do you see one or two cluster controllers?  (because there is one cluster alongside the region by default)
[08:21] <freeflying> rvba, only 1
[08:21] <rvba> Is it called 'master'?
[08:21] <freeflying> rvba, we don't have maas-cluster-controller installed on regional
[08:22] <freeflying> rvba, the one I can from webui is cluster-xxxxx
[08:23] <rvba> freeflying: okay, I see.  Not having the maas-cluster-controller installed on the region is an untested setup.
[08:24] <freeflying> rvba, hehe
[08:31] <rvba> freeflying: the MAAS region has IP <IP_ADDRESS> right?
[08:31] <rvba> Or is that the cluster machine?
[08:32] <freeflying> that is cluster
[08:32] <freeflying> regional is 204
[08:50] <jtv> The 403 errors match the "Not authenticated as a known node" errors in the maas log.
[08:56] <jtv> A kernel download failed at one point.  But that should either break commissioning completely, or leave it unaffected.
[08:56] <rvba> freeflying: could you please run this in 'sudo maas shell': http://paste.ubuntu.com/6131745/ ?
[08:56] <freeflying> jtv, when idid that error happen
[08:57] <rvba> freeflying: it will just print information about the nodes and the clusters, to help us debug the problem.
[08:58] <jtv> freeflying: that failure happened at 11:13:54 +0900
[08:59] <freeflying> rvba, on it, give me secs
[09:02] <freeflying> rvba, 1 nodegroup there, and 2 node
[09:03] <rvba> freeflying: only two nodes total?  I though you said you had 3?
[09:03] <rvba> thought*
[09:03] <freeflying> jtv, during that time, we're still trying to configure them, and after that, roaksoax has reconfigure cluster
[09:03] <jtv> Yeah, I think the 404 is harmless here or we'd have seen different failures.
[09:03] <jtv> What IP addresses did you get from rvba's script?
[09:04] <jtv> A paste of the output would be ideal.
[09:04] <freeflying> rvba, sorry, forgot to say I deleted others stucked in commissioning
[09:05] <rvba> freeflying: okay, can you try re-enlisting then re-commissioning the problematic nodes, then run that script again?
[09:07] <freeflying> rvba, ok, give me mins :)
[09:08] <freeflying> thanks
[09:09] <rvba> freeflying: sorry but I'm a bit confused, you said you had 3 nodes total, but I can see 4 different IP adresses requesting the preseed…
[09:10] <freeflying> rvba, we actually have 31 machines, guess some one else powered on it
[09:10] <rvba> Okay.
[09:14] <freeflying> rvba, http://paste.ubuntu.com/6131822/
[09:17] <rvba> freeflying: can you run [(n.ip_addresses(), n.system_id, n.nodegroup, n.architecture, n.status, n.hardware_details) for n in Node.objects.all()]
[09:17] <rvba> freeflying: the output will be large :)
[09:22] <freeflying> rvba, any module I shall import?
[09:23] <rvba> freeflying: just 'from maasserver.models import Node'
[09:23] <rvba> (nothing new compared to the previous commands)
[09:24] <freeflying> Traceback (most recent call last):                                                                                │·····················
[09:24] <freeflying>   File "<console>", line 1, in <module>                                                                                │·····················
[09:24] <freeflying> AttributeError: 'Node' object has no attribute 'ip_addresses'
[09:25] <rvba> freeflying: ah, right, you're using the precise package.
[09:26] <rvba> freeflying: could you run this: [(n.system_id, n.nodegroup, n.architecture, n.status, n.hardware_details) for n in Node.objects.all()]
[09:31] <AskUbuntu> Should MaaS and Juju get installed on one of my servers or on a client system? | http://askubuntu.com/q/347866
[09:32] <jtv> freeflying: I also have a bit of python I'd like to see the output to.
[09:32] <jtv> from metadataserver.models import NodeKey
[09:32] <jtv> for nk in NodeKey.objects.all():
[09:32] <jtv>     print(nk.node.nodegroup.uuid, nk.node.system_id, len(nk.key))
[09:32] <jtv>  <- that should tell us a bit (not the actual keys of course) about which oauth keys are being sent to which nodes.
[09:32] <jtv> Because we're seeing those nodes fail to authenticate with those keys.
[09:34] <freeflying> rvba, http://paste.ubuntu.com/6131873/
[09:35] <freeflying> jtv, how can I redirect from python console to stdout
[09:36] <jtv> Try:
[09:36] <jtv> python <<EOF
[09:36] <jtv> # Script code goes here
[09:36] <jtv> EOF
[09:36] <jtv> Ahem.  Not python, of course, but "sudo maas shell <<EOF"
[09:37] <jtv> The <<EOF tells it to feed what comes next (until the EOF line) into stdin.
[09:37] <jtv> To redirect: sudo maas shell >/tmp/my-output <<EOF
[09:41] <rvba> freeflying: okay, so everything seems fine so far, you're got one allocated node and 3 commissioning nodes… did they get out of commissioning or are they stuck, same as before?
[09:43] <freeflying> rvba, same
[09:44] <rvba> freeflying: can you try removing the working node and re-enlist, re-commission it?
[09:45] <rvba> freeflying: if that works, then there is definitely a difference between this node and the others (I suspect related to the network config).
[09:45] <freeflying> jtv, no output
[09:47] <freeflying> rvba, error: gomaasapi: got error back from server: 409 CONFLICT (Node cannot be released in its current state ('Commissioning').
[09:47] <jtv> No output!?
[09:47] <rvba> freeflying: wait, the node in question should not be commissioning.
[09:48] <freeflying> jtv, no
[09:49] <jtv> That would explain why the nodes fail to authenticate with the metadata service, but...
[09:53] <freeflying> jtv, any configure I need change to get it fix?
[09:53]  * freeflying gonna go, will be back late, need grab some food
[09:54] <jtv> freeflying: I think somehow either the input or the output must have been lost.  It's got to print at least one entry for the working node, and if all is normal, one for each of the other ones as well.
[09:55] <rvba> freeflying: you can manually get rid of the juju environment and all the nodes using this: http://paste.ubuntu.com/6131943/
[09:56] <rvba> freeflying: again, if you get one node commissioned, this means you need to investigate how the other nodes (the one stuck commissioning) differ from this one.
[09:57] <rvba> freeflying: can these nodes download stuff from the internet for instance?
[10:21] <rvba> freeflying_away: could you also show us how the cluster controller is configured? (the network config on the cluster page)
[10:22] <jtv> At 14:02:22 there's a POST from the _successful_ node to a broken URL: /MAAS/api/1.0/nodes//MAAS/api/1.0/nodes/
[10:22] <jtv> Oh, not broken apparently -- I'm told there's a workaround on the MAAS side for that.
[10:28] <jtv> The other nodes are signaling to the metadata service...  their individual Node pages in the UI may show useful output.
[10:31] <jtv> Later attempts to do that hit 403.  But the attempts around 14:02:27--14:02:45 got OK responses.
[10:55] <freeflying> rvba, ok, so I'll delete all nodes, and re-enlist
[10:56] <rvba> Yep, let's see if what you've seen before can reproduced.
[10:56] <freeflying> besides this, anything else I shall try
[10:56] <rvba> jtv: ^ ?
[10:56]  * jtv can't think of anything
[10:56] <freeflying> rvba, I left there office, so might not be able to watch the screen
[10:57] <rvba> freeflying: if you can still reach the MAAS machine, then that will be enough.
[10:58] <rvba> Like I said, I want to be sure that the odd behavior you've seen (one node fine, two nodes stuck) can be reproduced.
[11:29] <freeflying> rvba, http://paste.ubuntu.com/6132269/
[11:30] <freeflying> rvba, we use maas to manager another network, which is a 10 gig, will have all later on traffic go through this one
[11:39] <rvba> freeflying: there is a problem right there, the network defined here is <IP_ADDRESS>/24 and the nodes connect to the region using IPs like <IP_ADDRESS>.
[11:39] <rvba> freeflying: did you get one node commissioned, same as before?
[11:40] <freeflying> <IP_ADDRESS>/24 we use for pxe boot, because of hw limitation, 10 gig can't do pxe boot
[11:43] <rvba> We're hitting the same problem we talked about before, MAAS can only deal with one interface right now, used for pxe booting and later on, the IP attached to that interface is the one juju services deployed on the node will use.
[11:43] <rvba> Now I really wonder how you got one node commissioned successfully :).
[11:44] <freeflying> rvba, for commissioning should be fine, we have tested it last week, difference is it was using single server for maas
[11:45] <freeflying> rvba, we have no problem to enlist/commission node
[11:46] <rvba> freeflying: hang on, the problem we've been trying to figure out today is that the nodes never get out of the commissioning phase.
[11:47] <freeflying> rvba, yes,  despite the magical one :)
[11:51] <rvba> freeflying: the whole problem revolves around the network setup.  The nodes need to connect to the region using an IP in the network defined on a cluster controller.
[11:51] <rvba> freeflying: that's how MAAS figures out to which cluster a node belongs.
[11:52] <rvba> freeflying: now, why did it work with one node, that's what needs to be investigated (did you change the cluster configuration half-way through?).
[12:23] <freeflying> rvba, no, the only things has done is set up proxy in preseed
[12:23] <freeflying> rvba, btw, the second network(10 gig's <IP_ADDRESS>/24, managed by maas) never been used so far, no item in that dhcp leases file
[12:25] <rvba> freeflying: the config of the cluster is what defined DHCP config.  The onlyl option I can see is that the config changed when MAAS was running.
[12:26] <freeflying> rvba, no idea
[12:27] <rvba> freeflying: what's in the DHCP config?  cluster machine, file /etc/dhcp/dhcpd.conf.
[12:30] <freeflying> rvba, http://paste.ubuntu.com/6132485/
[12:31] <rvba> freeflying: it defines <IP_ADDRESS>/24.  How come the nodes have ips in <IP_ADDRESS>/24?
[12:32] <freeflying> rvba, because we use an external dhcp to provide pxe boot, so during this stage, its only use pxe boot network, which is <IP_ADDRESS>/24
[12:35] <rvba> freeflying: so the problem is there, the cluster is configured to manage DNS and DHCP (cf http://paste.ubuntu.com/6132269/).  So it believes the nodes will have IP addresses in the range defined here ie. [<IP_ADDRESS> - <IP_ADDRESS>].
[12:36] <freeflying> rvba, as long as the node bootup, it will have the ip :) (after deploying)
[12:37] <rvba> freeflying: yes, but like I said, MAAS uses the IP the node uses to connect to the region to figure out to which nodegroup it should belong.
[12:38] <freeflying> rvba, during our testing last week, it worked :)
[12:38] <freeflying> rvba, thats the thing confusing me now
[12:38] <rvba> freeflying: what changed then?
[12:39] <freeflying> rvba, split regional and cluster onto two servers
[12:39]  * freeflying really tired, need some relax and rest
[12:40] <freeflying> rvba, anyway, I can't continue on it today, thanks for you guys
[12:41] <rvba> freeflying: I understand, it's pretty late for you.  This is indeed a networking problem, with the region and the cluster on different machines, the nodes use, to connect to the region, an IP adress which is not recognized as belonging to the nodegroup.
[12:41] <rvba> nn freeflying
[12:43] <allenap> freeflying: Would you be able to summarise what's happened today and email it with us in Red?
[12:44] <freeflying> allenap, individually? or do you have a list?
[19:09] <marlinc> Where are the MAAS power templates stored?
[19:15] <kentb> While on the subject of power, maas seems to pre-populate the IPMI power parameters with a maas username and random password.  Is that even usable?  I've been going in and changing those to a known-working username/password without trying the one maas gives me.
[19:29] <roaksoax> marlinc: depends on the version
[19:29] <roaksoax> kentb: they work
[19:29] <marlinc> I found out already :)
[19:29] <roaksoax> kentb: maas creates them intentionally
[19:29] <roaksoax> kentb: and doesn't prepopulate
[19:29] <roaksoax> kentb: it access the BMC and adds them
[19:29] <roaksoax> marlinc: cool :)
[19:48] <kentb> roaksoax: ok. thanks for clarifying