[00:18] jason_, it can be any string re admin-secret [00:18] jason_, i assume for bootstrap? if you run juju -v bootstrap .. you should get a traceback on error, that you can paste to http://paste.ubuntu.com and paste the link here [00:29] niemeyer, sounds good [00:32] hazmat, http://paste.ubuntu.com/705195/ [00:33] jason_, it looks like your orchestra server isn't responding to api requests [00:34] the traceback is kinda of short.. so its hard to be sure, but its either the orchestra server isn't responding or the webdav server isn't up [00:34] I can to ssh to it, and I was able to pxe boot a system from it [00:35] now, in the sample, the address is marked off by trios of single quotes [00:35] ''' [00:35] do those not belong -- I tried without, and got a different, longer error [00:35] jason_, yeah.. it looks like its a problem with the webdav server when i look at the code [00:36] jason_, its the first thing talked to during bootstrap to check if a juju node already exists [00:36] jason_, not sure what you mean by the triple quotes [00:37] storage-url: '''http://192.168.1.103/webdav''' [00:38] jason_, that's not correct yaml afaics [00:38] jason_, single quotes around it are fine [00:38] else it parses to something broken for use as an address [00:39] yaml.load("storage-url: '''http://192.168.1.103/webdav'''") -> {'storage-url': "'http://192.168.1.103/webdav'"} [00:39] jason_, it doesn't even need quotes for a string in yaml for this case [00:39] jason_, which example are you referencing? [00:40] hazmat, https://help.ubuntu.com/community/Orchestra/JuJu [00:41] jason_, hmm.. ic. thanks, i hadn't realized this was documented somewhere.. first i'd try removing all the triple quotes [00:42] hazmat, the error w/o http://paste.ubuntu.com/705202/ [00:45] jason_, i'm not really all that familiar with it.. but my understanding is that first you need to define the management classes in cobbler that associate to machines you want to use, and those should match the management classes you have specified in juju's environment.yaml file.. the error is because juju queried the cobbler server and didn't find any machines matching the specified management classes. [00:45] hazmat, mmm, I think I might know what to try next, thanks. I've got to run for a while -- thanks [00:46] jason_, np.. good luck, and feel free to pop by if you have any more problems with it, there will be some folks around tomorrow who have more experience using juju + orchestra [00:46] hazmat, cool, thanks [00:49] hazmat, hey, got past that step, just had to netboot-enable it [00:49] jason_, awesome [00:50] hazmat, heh, meanwhile, my wife is going to kill me if I don't quit messing with this! :) [00:50] hehe ;-) [00:50] * hazmat knows that feeling [01:16] SpamapS, your updates are breaking the charms.. the revision file is missing === ejat- is now known as ejat [04:07] hazmat: so I still have to manage the revision?! :-( [04:07] * SpamapS had hoped it was optional [04:07] SpamapS, its in a separate file [04:07] Yeah I was hoping that was an optional file [04:07] 'revision' in the charm [04:08] SpamapS, it is during dev (it will autocreate it for you) [04:08] hazmat: so I need a universal pre-commit that checks for the file [04:08] hazmat: or we have to disallow general direct access to bzr. [04:08] SpamapS, the old way is backwards compatible [04:09] defined in metadata.yaml [04:09] hazmat: indeed, but it generates *copious* warnings [04:09] SpamapS, yeah.. for the 'charmers' group that might be good [04:09] probably should have used a deprecation warning.. but that's still once per process. [04:10] and random depending on which one you hit.. i guess the repo.find hits all of them. [04:12] yep === plars is now known as plars-holiday [12:30] Hallo! [12:54] niemeyer: mornin' [12:57] niemeyer: i tried to push my doc changes to the URL you suggested (lp:~juju/juju/trunk) and i still get a "read-only transport" error [13:03] rog: Can you please paste it? [13:10] <_mup_> Bug #871743 was filed: orchestra instance status is not visible < https://launchpad.net/bugs/871743 > [13:11] http://paste.ubuntu.com/705380/ [13:11] niemeyer: ^ [13:12] <_mup_> Bug #871745 was filed: orchestra: ks_meta not cleared < https://launchpad.net/bugs/871745 > [13:20] rog: This is wrong in a few different ways [13:20] rog: You can simply pick a branch and push onto trunk [13:20] rog: trunk has most certainly evolves since you created this branch [13:20] can? or can't? [13:20] rog: Sorry, can not [13:20] ok [13:20] rog: The way to go is to have a local trunk [13:21] i do [13:21] ok, and merge into that [13:21] rog: Then, bzr pull into it [13:21] then push it [13:21] rog: First pull from the real trunk [13:21] yup [13:21] rog: Then, merge onto that [13:21] rog: and _test_ it! [13:21] rog: Then, commit and push [13:21] even though i've only changed the docs? [13:21] rog: If you're using a bound branch, you actually don't have to push [13:22] just commit? [13:22] rog: But it's slightly easier to screw things up too [13:22] rog: Yeah [13:22] rog: For doc-only changes, build the docs again at least [13:22] how do i run the juju test suite BTW? [13:22] rog: and see how it looks in the browser [13:22] rog: ./test [13:22] ok [13:33] niemeyer: i still get the same error. i tried it from scratch: http://paste.ubuntu.com/705386/ [13:34] i'm sure i'm still doing something wrong :-) [13:34] rog: Hmm.. [13:34] rog: Are you not part of the team? [13:34] * niemeyer checks [13:35] rog: LOL, yeah [13:35] rog: Ok, try now [13:35] ah, that works. [13:35] rog: Sorry about that [13:35] BTW what *is* the difference between lp:juju and lp:~juju/juju/trunk [13:35] ? [13:40] rog: None, assuming that the former has a default series that points to the given branch [13:40] rog: Which is indeed the case [13:40] rog: Which series a project or a series points to is config-defined [13:40] niemeyer: ok. i understood something different from one of your previous remarks [13:40] Erm [13:40] rog: Which branch a project or a series points to is config-defined [13:40] rog: Which was? [13:41] niemeyer: http://paste.ubuntu.com/705389/ [13:42] (i'd used the URL lp:juju there) [13:42] rog: You were using http [13:42] rog: or that was my understanding at least [13:42] rog: if it wasn't, then I looked the URL incorrectly [13:43] niemeyer: i don't think i was. i just checked. i was using lp:juju [13:43] rog: Ok, sorry then [13:43] i woz confuzed [13:43] np [14:09] <_mup_> Bug #871773 was filed: machine_data needs a schema < https://launchpad.net/bugs/871773 > [14:21] <_mup_> juju/go-store r16 committed by gustavo@niemeyer.net [14:21] <_mup_> Merging from go-new-revisions. [14:50] <_mup_> juju/go-store r17 committed by gustavo@niemeyer.net [14:50] <_mup_> Renamed NewURL to ParseURL, and added MustParseURL. [15:05] SpamapS, fwiw i'm marking bugs for oneiric against the distribution and milestone oneiric updates [15:07] niemeyer, fwereade_ we don't have a separate oneiric series atm.. so merge order is critical to ensure we don't have new featues added before bugfixes for oneiric.. [15:08] hazmat: Agreed [15:08] hazmat: What's the context? [15:08] niemeyer, getting 399 and local provider storage into oneiric.. [15:08] hazmat: I've just been quietly working away and MPing against florence bugs, I hadn't been planning to merge anything until I had some idea what was going on [15:09] niemeyer, but it also applies to any other bugs we get that should be fixed against oneiric, where things become a bit harder. [15:09] if its post oneiric release, and we're onto florence feature dev [15:10] unless we're saying we're only going to do one sru update, and we'll save doing a maintained stabled till 12.04 [15:10] we'll at least get the practice in of doing an SRU before 12.04 which is nice [15:11] the question is if we need or want to do more than one [15:11] probably better is publishing a stablish ppa [15:12] hazmat: I don't know, but the focus ATM is indeed on oneiric [15:12] i'll ask again on list for wider feedback [15:13] hazmat: I think it depends quite a bit on how the 11.10 => 12.04 will look like [15:13] hazmat: There are important things we have to decide on that will modify the way we work on that period [15:15] hazmat: Regarding local-provider-storage, I wish we had gone with a webdav implementation from day zero [15:15] hazmat: But if you've tested that branch and it's solving the problem for the release right now, +1 [15:16] niemeyer, indeed, both i and jim have tested it [15:16] it solves the issue jamespage reported [15:16] hazmat: Cool, let's go with it then and get the problem fied [15:16] fixed [15:16] hazmat: We can reevaluate the approach in the future [15:17] niemeyer, what does webdav bring to the table here? and which webdav impl? [15:17] hazmat: It brings commonality between multiple providers, and it also brings privacy [15:17] hazmat: We already have webdav support in orchestra [15:20] niemeyer, hazmat: kinda-sorta: I only just MPed the version with authentication, and I think that's tied to the apache2 module (I forget what, but it skips one of the possible fields) [15:20] privacy between multi users on a machine with sudo root access, against atm public resources is a bit of a red herring, multiple environments on a single machine, means a cross provider resource (ie. host config alteration) or something costly like multiple apache2 webdavs. [15:21] hazmat: We already have it that code working. Just needed to bring up any existent webdav server properly configured. [15:22] with the new local provider storage, the fetch side is the same as what're using now against any url.. the push side is the same what we use in tests (disk storage), and is trivial [15:25] hazmat: Yeah, the fetch side is the same. The server side is disk store + twistd + wrapper to return URL on twistd. [15:26] hazmat: I hope that in the future that becomes a single server, for local, for orchestra, and for EC2. [15:44] Lunch, biab [15:54] later all [15:55] fwereade_, cheers [16:10] * hazmat wonders if google's dart aka java+coffeescript is really useful [16:11] * rog is quite glad that dart isn't stepping on Go's toes [16:23] <_mup_> juju/trunk r401 committed by kapil.thangavelu@canonical.com [16:23] <_mup_> merge local-provider-storage [r=jimbaker,niemeyer][f=869945] [16:23] <_mup_> Make local provider storage network accessible to allow for unit access, fixes problems [16:23] <_mup_> with charm upgrade. [16:44] * hazmat lunches [16:47] <_Groo_> hi/2 all [16:47] <_Groo_> could anyone help me? i want to test juju but i dont have a AWS key... [16:48] <_Groo_> how can i bootstrap juju without sucha key? can i emulate one or make juju ignore it? [16:48] _Groo_ , consider using the local provider setup [16:48] rog: I'm actually surprised by _how much_ it's not stepping on it [16:50] _Groo_: you can also use openstack [16:51] niemeyer: yeah, i thought there might be some influences going on there, but there don't appear to be [16:52] niemeyer: := and go-order type declarations would have been a nice touch... [16:52] rog: Interfaces as well, at the very least [16:52] niemeyer: yeah. [16:53] niemeyer: from my 30s look at it the type and object model seems substantially that of java [16:53] which does seem a bit... retro [16:54] rog: Yeah, it feels quite a bit like Javascript+Java [16:54] rog: Which is unsurprising given the stakeholders' background [16:54] on the positive side, it means i don't have an urge to waste time looking through it in detail... [16:55] niemeyer: yeah. seems like they could've been a little bit more radical. but maybe they like that space. [16:58] So, we may need to do one last upload to juju in 11.10 [16:58] oh wait, never mind [16:58] I was just thinking it uses the PPA by default [16:58] but it doesn't! w00t! [16:58] SpamapS: Yeah, it's.. magic! :) [17:00] niemeyer: I keep thinking that it would be better to have the bootstrap process build a repo with juju in it.. so you always get the same juju regardless of the archive/PPA state. [17:00] niemeyer: i'm off. i sent you a come back on that review by the way. all done save one query. [17:01] rog: Cool [17:01] rog: Thanks, and a good evening [17:01] see you tomorrow [17:01] btw, juju.ubuntu.com/docs is not being updated [17:02] * niemeyer tries to sort out ordering of updates in the store [17:08] hazmat: btw, we have some more bugs to fix in txaws .. [17:08] hazmat: the provisioning agent also needs to be a little more robust when handling errors from txaws .. [17:08] SpamapS, hmm.. this is around the machine termination work? [17:09] We had a failure during the demo where sometimes expose would try to list instances, fail, and then get an error raised because it tried to iterate on None [17:09] ugh [17:09] after that, the provisioning agent would not do *anything* [17:09] kill/restart it would work [17:09] luckily we had it a few times in rehearsal so I had Adam watching for it during the demo [17:10] It was about 1 in 10 times.. so we just crossed our fingers and went for it. :-P [17:10] glad the demo went well, sounds like it rocked [17:11] It went over great [17:11] hadoop w/ 7 nodes in under 5 minutes. :) [17:18] SpamapS, there's a related outstanding issue (bug824279) [17:18] bug 824279, please ;) [17:18] <_mup_> Bug #824279: Security group functions for EC2 provider should retry < https://launchpad.net/bugs/824279 > [17:20] jimbaker: that is definitely related, tho I think the bigger problem is that errors are allowed to disable the provisioning agent [17:20] from the sound of it, openstack occasionally returns a payload txaws can't parse, and this bubbles up inappropriately [17:20] jimbaker: exactly [17:20] SpamapS, yeah, i never liked that architecture [17:21] txaws should be smarter.. [17:21] but we should be more defensive [17:21] SpamapS, precisely [17:21] SpamapS: That's a slightly spread out issue indeed, and it's the sort of thing I hope to get cleaned up in the 11.10 => 12.04 timeline [17:21] Want to make sure its well reported so it will be easier to fix. [17:23] SpamapS, i think one possibility here is to consider the provisioning agent, when it does fall over, is something that can be restarted. ideally with ha. but there has to be a last line of defense. not you watching it ;) [17:24] yeah, what was weird was that it didn't exit.. it just stopped doing anything [17:24] SpamapS, ahh, so not even failfast [17:24] My guess was that some watch/callback/etc. needed to be re-added in a 'finally:' clause somewhere [17:24] Its quite reproducible.. [17:24] SpamapS: I've seen that happening before.. a deferred that never fires can cause that [17:24] just digging through bugs now to see if there's a dupe [17:25] (while also ISO testing the 11.10 release :) [17:28] SpamapS: My plan for 12.04 encompasses fixes for all of that, FWIW. We still have to talk about it to see if we're all buying into it, though. [17:31] SpamapS, is bug 863400 addressed already? [17:31] <_mup_> Bug #863400: examples repository is not installed from PPA < https://launchpad.net/bugs/863400 > [17:33] hazmat: no, its just blocked on me making the packaging from 11.10 backportable to lucid/maverick [17:33] trivial, but not done [17:33] BTW the reason they're not there is a missed file during the rename [17:35] ok.. i'm going to move it to the florence milestone.. i'm trying to close out eureka === hazmat changed the topic of #juju to: http://j.mp/juju-florence http://j.mp/juju-docs http://afgen.com/juju.html http://j.mp/irclog [17:38] florence is open [17:39] WOOHAY [17:40] very nice [17:44] it was very clear to me in working on the provisioning agent that it's very difficult to get a complex watch setup that is correct in twisted. so moving to golang is definitely something i continue to support [17:50] jimbaker, umm.. add an errBack ? [17:50] for the error handlng that is [17:52] SpamapS, do you have any of the logs from the provisoning agents by chance? [17:53] hazmat: no. :( [17:53] kept meaning to save one off [17:53] but its really easy to reproduce [17:53] just return None from describe_instances [17:54] can probably write a test actually [17:54] hazmat: rather, instead of returning None, raise an error [17:54] hazmat, sure, we could do that. i suspect (but i would need a log to confirm) that the problem would not be caught by the exception handler L461 in open_close_ports_on_machine in juju.agents.provision [17:55] actually that's just illustrative of where it should be caught, since in the specific case there, it's just to ignore something uninteresting [17:55] wouldn't the appropriate way be to handle unexpected errors in any underlying library call? [17:57] SpamapS, yes, to be more defensive, or failfast, when doing something external [17:57] SpamapS, religious backwards compatible will leave important features on the table.. zk security comes to mind as a pending one [17:59] that method does isolate any txaws calls related to expose, but it can be called in the context of a watch [18:00] SpamapS: Yes, that's really all that there is to it. Certain practices make that intrinsic, while others make that error prone. [18:06] hazmat: agreed 100%, I think it will slow down dev a lot. [18:07] hazmat: I'm not sure how we can manage to keep putting new versions of juju in -updates without it though.. otherwise we're going to get angry people who have dead environments. [18:08] SpamapS, i'm not sure why we should try past an initial SRU (which is good experience for 12.04) [18:08] have a stable ppa for people who want new features [18:08] if we want to have additional fixes for 11.10, we should have a release branch [18:09] Thats typically how its done, yes. [18:09] However I think we're being asked to think outside the box here. [18:12] SpamapS, hazmat: We may well live the entire 12.04 timeframe with a compatible code base [18:12] SpamapS, hazmat: It really depends on how we're running next [18:13] There are two very distinct levels of compatibility to think about too [18:13] There's the running environment, and the charms. [18:13] And a third, which is the CLI [18:13] SpamapS, hazmat: People must be able to trust it by 12.04, so the focus is on making it solid [18:14] Yeah, nobody's arguing that we shouldn't do some radical things to make juju a production ready product for at least a few use cases by 12.04. The current question is what to do about SRU [18:16] SpamapS: I don't think we need any incompatible changes to make it production-ready. [18:17] SpamapS: SRUs can flow from trunk before we break compatibility. [18:18] niemeyer: adding ZK security would probably be difficult to do w/o breaking a running env [18:19] unless we are careful in making things gracefully degrade on the ZK schema version [18:19] SpamapS: That's not critical for putting it in production, to be honest, but it'd be possible still [18:21] niemeyer: alright, I'l have to take your word on both of those, as I'm not entirely familiar with the current security model [18:21] The previous understanding I had was that any agent can change and view any part of ZK [18:21] thats not even close to production acceptible. [18:21] SpamapS: The main point I'm raising here is that I don't even think we should be addressing zk security right now [18:22] yeah I believe you that there's no need for it.. I just don't understand it well enough to speak to it. [18:23] SpamapS: "production" means different things to different people. [18:23] right now the story there is no security, there is an implementation on deck that can be finished up with in an additional week or two [18:23] but its moot if we go go [18:23] SpamapS: I'd certainly deploy juju with agents having access to zk [18:23] SpamapS: In production [18:23] SpamapS: I'd not deploy it without being able to reboot [18:24] SpamapS: etc [18:24] I'd put rebooting above zk security too. [18:24] niemeyer, iotw. there are other issues with higher priority [18:24] hazmat: You mean in the same words, yeah :-) [18:24] I'd just be hesitant to deploy something that makes it so one root compromise enables a global root compromise. [18:25] it can be "production part deux" ;) [18:25] SpamapS: Precisely [18:25] SpamapS: It's not that we disagree, it's just that that's critical critical, and critical :-) [18:25] s/that that's/that there's/ [18:27] i'd still like to fix finish the merge on the security stuff, just so its not pending.. the further away the further the context switch [18:27] hazmat: I'm not sure it's a good idea, but we should definitely talk about it [18:27] i should probably just update it to current trunk and leave it pending [18:28] niemeyer, i'm fine with holding off on it for now, but it is still something i'd like to see for 12.04 [18:28] wouldn't it be possible to simply put a version constraint on it.. if schema_version >= 3: ... else: warn("NO SECURITY!") [18:28] but agreed reboots and other prod issues are more important for now [18:28] hazmat: It's something I want to see in too, for sure, but we have to put the work in context of the overall strategy [18:29] niemeyer, we haven't done much overall strategy discussion for what we want to accomplish this cycle [18:29] hazmat: ROTFL [18:30] niemeyer: I went ahead and made 'prouction' an official tag for juju's bugs [18:31] hazmat: We haven't indeed.. but please excuse me while I go back to hacking the store so I can try to get this on time. :-D [18:32] hazmat: We've been consciously delaying strategy conversations since the strategy is very well known up to now [18:32] hazmat: Getting 11.10 in shape [18:33] niemeyer, good stuff we can revisit post store/repo launch [18:33] * hazmat returns to hacking [18:33] hazmat: Once we're good on that front (I'm still not), and we breath for a couple of days maybe, we should start more serious conversations on the months ahead [18:33] SpamapS, btw.. pls put in a request to merge status2gource ;-) that's awesome [18:33] SpamapS, is there a screencast of that rocking out? [18:34] hazmat: I'm hoping to just make it part of juju status. --gource [18:34] SpamapS, nice [18:34] its pretty simple [18:34] hazmat: we had a few [18:34] hazmat: hopefully we'll have full video of the actual demo [18:35] that would be awesome... although potentially a long wait [18:36] IIRC, the OpenStack conf guys are editting [18:37] SpamapS, sure.. but i remember waiting a year for the surge guys to finish up last years videos.. [18:37] doh [18:41] evening all [18:42] I have a query re public-address/private-address [18:42] JAMES PAGE! [18:42] * jamespage waves at niemeyer [18:44] I've been doing a bit of work on the cassandra charm and I've switched over to using private-address/public-address [18:45] but I have to configure cassandra to listen on a specific IP address for cluster communication [18:45] jamespage: Hmm, ok [18:46] I went with `unit-get private-address` - but running in ec2 this give me 'domU-12-31-39-0B-14-11.compute-1.internal' [18:46] jamespage: I actually already committed changes to use public-address/private-ddress [18:46] which binds onto 127.0.1.1 [18:46] heh thats interesting [18:47] ugh.. [18:47] yeah - thats what I thought :-) [18:47] seems like we should be putting private *address* in that field, not private-hostname [18:47] jamespage: Looks, buggy.. [18:47] since we have the collaboration of the provider, addresses should be useful [18:47] SpamapS: This should actually be the public one for EC2, right now [18:47] SpamapS: I've done some work on the seed management as it was restarting cassandra *alot* when it did not need to [18:48] jamespage: cool! [18:48] jamespage: you can just --overwrite lp:charm/cassandra .. I was just seeing how unit-info and private/public addresses work [18:48] niemeyer: huh? [18:48] SpamapS: wilco [18:49] SpamapS: It should be the address that allows units to intercommunicate.. I guess we can use the internal 10.*.*.* [18:49] jamespage: as far as binding a specific IP, is that necessary? can't you use 0.0.0.0 ? Or is it the snitch thing that needs to know its IP? [18:49] niemeyer: we *must* use the internal address, or people get massive bandwidth bills [18:49] SpamapS: you can for the thrift interface - but not for the peering [18:49] SpamapS: yeah, cool [18:50] jamespage: right that makes sense. [18:50] jamespage, that's interesting.. [18:50] host domU-12-31-39-0B-E0-59.compute-1.internal [18:50] domU-12-31-39-0B-E0-59.compute-1.internal has address 10.214.231.167 [18:50] jamespage: I suppose the simple way is to look it up with dig/host, instead of using gethostbyname [18:50] ping domU-12-31-39-0B-E0-59.compute-1.internal -> 127.0.1.1 [18:50] hazmat: bingo! [18:50] hazmat: right, thats because we always put a machine's hostname in /etc/hosts as 127.0.1.1 [18:51] hazmat: Cool.. we just need to resolve it differently [18:51] hazmat: Or rather.. are we resolving it? /me looks at get-unit private-address [18:51] jamespage, if we drop the search domain from /etc/hosts it should also work [18:51] niemeyer, it queries the private address from the metadata server [18:52] hazmat: But what's the output from the command? [18:52] hazmat: an ip, or the domain name? [18:52] niemeyer, we can get either, we use address for ec2 [18:52] hazmat: Is the address an ip, or a domain name? :-) [18:52] er. domain [18:53] niemeyer, its domains for every provider except local which uses ip [18:53] so what should public-address get me in ec2? [18:53] hazmat: That sounds good then [18:53] jamespage: public would be less relevant for cassandra [18:53] jamespage: The internal domain name for the local machine [18:53] jamespage, the public dns name for the machine [18:53] Sorry, s/internal/public/ for public-address [18:54] so that should be a name not an address - OK [18:54] I think whats important is that the behavior of private-address is well understood. I have to admit, I'd expect it to *always* give me a network address, not a hostname, but if it might do that sometimes, then charms can deal with that. [18:54] jamespage: I think you have to plan for both [18:55] jamespage: address is a loose term [18:55] if unit-info private-addres | grep -q "[a-zA-Z]" ; then resolve_hostname ; fi [18:55] hrm that breaks on IPv6 doesn't it? [18:56] jamespage: ipv4 address, ipv6 address, mac address, etc, are not loose terms [18:56] SpamapS, that's one reason its hostname for address, to preserve ipv6 compatbility [18:57] ie. leave it to dns to resolve [18:57] except here dns is effectively broken [18:57] yeah, my concern would be that sometimes it might be an IP [18:58] SpamapS: We can certainly polish/improve that over time [18:58] SpamapS, in the local provider it is indeed an ip, since the hostname isn't routable from the host to the container [18:58] SpamapS: Let's keep an eye on that and learn how people use it [18:58] niemeyer, that's kinda what caught me out; I've been testing in the local provider just fine [18:58] (appreciate its a simpler environment) [18:59] so the underlying problem comes from cloud-init [18:59] # Added by cloud-init [18:59] 127.0.1.1 domU-12-31-39-0B-E0-59.compute-1.internal domU-12-31-39-0B-E0-59 [18:59] Its not really a "problem" per se [18:59] switched to ec2, no peering with cassandra [18:59] if it didn't have the *.internal address it would just work [18:59] its meant to make sure the machine can resolve its hostname [18:59] that is in /etc/hosts [18:59] SpamapS, we can do that from the second part of that line [18:59] hostname [18:59] domU-12-31-39-0B-E0-59 [19:00] we don't need the domU-12-31-39-0B-E0-59.internal entry [19:00] hazmat: right, but the FQDN needs to resolve to the local machine [19:00] its actually something to do with MTA's IIRC [19:00] that's what causes the problem.. it doesn't need to link back to 127.0.1.1 just to the ip address? [19:00] smoser knows better than I do [19:01] if i remove that entry from the line it all works as expected [19:01] jamespage,hazmat: I think the way the cloud-init stuff is injecting the ip is a bit dubious as well, [19:01] That entry is not going away [19:01] I mean, raise a bug [19:01] :-) [19:01] IIRC its there for a good reason [19:01] SpamapS, but the entry would work with just -> 127.0.1.1 domU-12-31-39-0B-E0-59 [19:01] afaics [19:02] Would work for what? [19:02] You're assuming you know every way that the FQDN is used [19:02] i dunno... probably juju ;-) [19:02] SpamapS: FWIW, I don't think it's a common convention to use a loopback for the FQDN [19:02] i don't think fqdn -> localhost is something that should be assumed [19:02] its already resolvable [19:03] you could turn it off [19:03] We might even be setting it [19:04] cloud-init is setting it.. [19:04] * hazmat checks cloud-init config [19:04] manage_etc_hosts must be set to skip that bit [19:05] smoser: around? [19:05] SpamapS: you might be lucky - think he's on hols today [19:05] sanitize hosts file for system's hostname to 127.0.1.1 (LP: #802637) [19:05] <_mup_> Bug #802637: cloud-init needs to check for hostname to resolve to 127.0.1.1 < https://launchpad.net/bugs/802637 > [19:06] doh [19:06] no explanation as to why that is asserted [19:06] i don't see any reasoning in there on why fqdn should be aliased to localhost.. that looks like it introduced abug [19:06] but my guess based on the time frame is this was centered around orchestra starting to use cloud-init [19:07] m_3, ping [19:07] whoops [19:07]