404 - Not Found

=== kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [04:32] Hi folks, I'm running "charm proof" against a charm I've been writing trying to learn it, and it's complaining "I: all charms should provide at least one thing" [04:32] Why is this so? If the charm is basically just a single client-facing service does it really need any relations? === kadams54 is now known as kadams54-away [04:43] blahdeblah: you can ignore I: prefixed warnings [04:44] blahdeblah: the only warnings you *need* to fix are Warns and Errors. Info is just FYI - and no, its completely acceptable for a charm to be 100% stand alone. [04:44] lazyWeekend: OK - thanks [06:47] I'm running some charm tests and its failing, but I can't reproduce it outside of the tests - how do I tell it to not tear down the env after running the tests? [06:51] oh, cleanup=False, fine. === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away === lazyWeekend is now known as lazyPower === tvansteenburgh1 is now known as tvansteenburgh [14:37] jose, ping === fabrice is now known as fabrice|family [17:34] marcoceppi, mbruzek, Tribaal, dpb1, niedbalski - I'm in the hot seat for a demo fix - can i get a quick review on https://code.launchpad.net/~lazypower/charms/trusty/hdp-hadoop/amir_hpcloud/+merge/240483? [17:35] lazyPower: why all the unrelated changes in there? 'start_NM' -> 'start_nm', etc? [17:35] 'start_datanode' -> 'start_dn' ?? [17:36] dpb1: This was a fix by asanjar that lives in his personal namespace - i think he's normalizing his method signatures as combining camel case with underscores was "obnoxious" as put by 3rd party reviewers. [17:36] i pulled this in and verified it works on hpcloud, testing amazon now [17:43] lazyPower: well... in the case of datanode, it's actually decreasing readability... and in any case, for an emergency fix seems like those should be stripped out? [17:43] dpb1: ack, i'll cherrypick changes and give this another go [17:44] thanks for taking a look dpb1 [17:44] lazyPower: yes, if you get a reduced version, I'll peek again === kadams54 is now known as kadams54-away [17:58] dpb1: https://code.launchpad.net/~lazypower/charms/trusty/hdp-hadoop/asanjar_hpcloud_cleanup/+merge/240487 [18:01] dpb1: looks like my editor had fun reformatting :( cant win for losing today [18:01] yowzer [18:02] :) [18:02] removing trailing spaces is almost always a good thing :) [18:02] .. never letting them sneak in is the better thing, of course [18:03] ATOM's python language lint/bindings is pretty stellar I have to admit. [18:03] and its consistent [18:05] http://askubuntu.com/questions/540209/ip-domainname-of-juju-master-or-slaves-changes ;x === tvansteenburgh is now known as tvan|lunch [18:15] lazyPower: +1 to that. [18:16] aisrael: review or ATOM comment? [18:17] lazyPower: ATOM, sorry. [18:17] all good - just beating the drum :) === tvan|lunch is now known as tvansteenburgh [19:30] can anyone point me to docs for how to use the storage charm with mongodb charm? === roadmr is now known as roadmr_afk [19:47] jrwren: i just happened to glance at https://code.launchpad.net/~evarlast/charms/trusty/mongodb/trunk/+merge/240376 and noticed there are merge markers in the diff [19:48] tvansteenburgh: no idea where that came from. I didn't commit that code. [19:48] or I did, and I didn't mean to. Its been 5yrs since I used bzr much. [19:49] jrwren: i'd charm get cs:trusty/mongodb - reapply your patches to it, and resubmit. somewhere along the lines a dirty merge happened on your local branch. [19:51] is this some known launchpad thing? [19:52] fwiw, I just confirmed that some of that code is not in my branch or the charm in charmstore. [19:58] can anyone suggest how I may use bzr correctly so taht this doesn't happen again? [20:03] does bzr have equivalent of git push -f ? [20:07] on github, I'd simply git push -f and the PR would be updated. How do I do this with LP and this MR? [20:08] jrwren: you just push... there's no need for --force, lp updates [20:09] jrwren: you probably just need to merge trunk into your branch and resolve the conflicts [20:10] i don't want to merge. I want to push force. [20:10] the whole point is that I have my tree exactly how I want, and I own the remote true. How do I get the remote to be exactly what I have local? [20:11] or is there a magic merge option that says "ignore all remote" ? [20:11] jrwren: no, I don't think you can do that [20:12] there's nothing wrong with your branch [20:12] jrwren: bzr is safe safe safe [20:12] launchpad is just telling you your branhc conflicts with later changes on trunk [20:12] in order to land your branch, you need to resolve them [20:15] jrwren: to be clear - your branhc does not have merge markers in it. it's just diverged from trunk of what you're merging into. === kadams54 is now known as kadams54-away [20:16] mgz: I don't know what that means. Pretend I've never used bzr and I only know git words, because that is how fried my brain is right now ;) [20:17] i'm just going to push to a new branch. [20:18] jrwren: in your local charm dir do `bzr merge https://code.launchpad.net/~charmers/charms/trusty/mongodb/trunk`, resolve any conflicts, then commit and push back to https://code.launchpad.net/~evarlast/charms/trusty/mongodb/trunk [20:18] that "resolve any conflicts" step is too much friction for me. [20:18] gah, thhose links were supposed to be lp: links [20:18] what you said still works though :) [20:20] i did figure out how to update the MR with the new branch. YAY! [20:21] https://code.launchpad.net/~evarlast/charms/trusty/mongodb/i-do-not-know-how-to-use-bzr-so-i-pushed-here/+merge/240499 oh, it doesn't really update it. new url and everything. [20:27] jcastro: pong [20:27] jrwren: heh, nice branch name [20:28] jrwren: much cleaner, thanks for the cleanup [20:28] jose, heya, is there a reason you didn't push owncloud to trusty? Was just wondering [20:29] jcastro: yeah, as I said some tests were giving a weird error and I need to take a look. and the apache2 file structure has changed [20:29] jcastro: minor changes and I'll open a bug. will deal with them tonight as I have classes in 30m [20:29] * jcastro nods [20:29] I was just wondering, not implying that you needed to fix it! [20:29] I'm fully back to charming, sorry if I've been absent but exams + flu [20:29] hey, it needs to be on trusty asap! [20:30] I think it's a point release behind too? [20:30] not actually, you can specify and install any release. [20:30] oh ok, woo! [20:30] need to check the default again to make sure it's updated to the latest rev [20:30] but expect something today === kadams54-away is now known as kadams54 === roadmr_afk is now known as roadmr [21:10] * skay waves to roadmr [21:10] skay: hows the jujuing going? [21:11] roadmr: am trying to figure out why the charm I am working on is using a fork of python-django instead of python-django [21:11] roadmr: and so on. okay I guess [21:11] skay: oh! yes, I remember it using a fork... [21:12] roadmr: I haven't looked through everything yet, but perhaps when someone made the fork python-django didn't support installing tarballs? maybe? [21:13] roadmr: if I get good at this I think I'll reuse my knowledge to make a juju charm for pyvideo.org [21:13] that'd kick ass :) [21:14] roadmr: I have run through fabric on it, experimented with ansible, ... and might as well see how this goes [21:15] looks like the python-django maintainers are experimenting with supporting ansible and fabric (perhaps other things) [21:36] skay: the python-django charm maintainer is actually in progress of moving it to a python only charm using charmhelpers [21:37] lazyPower: yes, I think I saw that. and the fork my project is using is from before that. [21:37] skay: as it stands today they are still deploying the ansible charm as thats whats in teh store - but the pure python branch should be landing soon [21:38] last time i looked at it was a little over 3 weeks ago - but its in the queue [21:54] lazyPower, hi [21:54] o/ themonk [21:54] I am facing a problem [21:54] i deployed my charm in amazon [21:55] but in charm when i get unit puclic address it gives me aws instamce private address [21:56] themonk: you're looking for the IP Address of the unit correct? [21:57] yes and i use this "unit-get public-address" [21:58] themonk: there's a few ways you can work around this behavior - there have been bugs filed against this in the past, but this is apparently expected behavior from juju - favor the FQDN of the unit vs the ip address. one method is to dig +short the hostname but this fails gloriously in some environments. [21:58] marcoceppi: do you recall the helper we came up with to resolve EC2 ips? [21:59] themonk: wait, i think i just glossed over something. you got the private address back from unit-get public-address? [21:59] Hi All. Do any methods exist to retry juju upgrade-juju to the environment, in case of some nodes have not upgraded their juju agents. So I have now some agents previous version [22:00] themonk: have a look at this paste - try running a similar juju-run command for me and pastebin the output: http://paste.ubuntu.com/8808757/ [22:00] lazyPower, bacicaly 'unit-get public-address' and 'unit-get private-address' gives same ip [22:05] May be I can manually try to upgrade somehow those agents ? If any methods exist ... [22:07] lazyPower, http://paste.ubuntu.com/8808837/ [22:07] themonk: what juju version? [22:08] lazyPower, 1.20.11-trusty-amd64 [22:11] interesting, i'm running the same juju version and I get FQDN not IP's [22:11] interesting [22:11] themonk: i'm not sure what to say to that... what AZ are you in? [22:12] lazyPower, US East (N. Virginia) [22:13] themonk: do you have a floating ip attached to the instance? an EIP? [22:15] lazyPower, what is floating ip? where do i look in ec2 dashboard? [22:15] themonk: ElasticIP's are typically attached to a unit in the EC2 dashboard under "elastic ip" - you'll see the IP and an instance ID next to it if it's assigned. [22:15] thats teh last thought I had is if you attached an EIP and it was somehow overriding the networking on the machine to point @ that EIP [22:16] ezobn: hey there sorry about the delay, the only thing i've found is upgrade-juju - which upgrades the tools in the env. The units themselves should upgrade (i think) at some point during the agents lifecycle checkins. [22:16] working on getting a definitive answer for you [22:17] lazyPower, no i do not have EIP, its showing blank [22:18] themonk: i haven't seen that behavior out of amazon before, it seems really strange to me that a) its returning the IP, and b) its the same IP on both pub and private addressing. [22:18] *out of juju on amazon [22:18] themonk: i would recommend a ping to the juju@lists.ubuntu.com or a question on ask ubuntu tagged juju - and crowd source a possible answer. [22:20] lazyPower: Hi, not a problem. Thanks for the answer. But they are in this state already more then a day ... so I think something wrong happened ... [22:21] lazyPower, if juju is written in python, may be i can look into the source now :) [22:21] themonk: old juju was, after 1.14 it was ported to go [22:22] lazyPower, yes [22:22] if you juju upgrade-juju --version 1.20.11, does that have any effect over the straggler agents? [22:22] ezobn: ^ [22:26] ezobn: and feel free to substitute --version with the point release you were trying to build and upgrade your environment to [22:31] lazyPower, what do you think is this a bug? [22:32] themonk: seems like it might be, or a corner case. Do all you runits deployed in AWS exhibit the same behavior? [22:32] lazyPower: no - says "no upgrade available" [22:33] lazyPower: even when --version [22:34] ezobn: thats unfortunate - can you file a bug against juju-core for the units not upgrading? Be as detailed as you acn and it would probably help during triage to attach logs during the timeframe that you sent the upgrade command and ~ 20 minutes afterwords. [22:34] themonk: I'm going to recommend you do the same, along with debug output of the juju-run commands i had you run earlier, instance constraints, and anything pertinent about your environment. [22:35] lazyPower, yes its same for all instances === kadams54 is now known as kadams54-away [22:36] themonk: Most definately a bug then. I'd file a bug https://launchpad.net/juju-core/+bugs [22:37] lazyPower, will I file a bug or you? [22:38] themonk: i dont have insight into your network - id' prefer you create it so you can track it and populate it with all the right info for your environment [22:38] lazyPower, ok thanks :) [22:39] themonk: ezobn: sorry you two ran into trouble, let me know if there's anything else i can potentially help with [22:40] lazyPower, do you know anyone using juju with aws in production? [22:42] themonk: our very own marcoceppi does, and i believe that omg ubuntu! is run on aws with juju as well - or was at one time. I'd need to follow up on that one [22:49] lazyPower: NP, will reinstall everything ;-) Thanks for make me sure that no yet any means to force the update. === kadams54-away is now known as kadams54 [23:32] lazyPower, https://bugs.launchpad.net/juju-core/+bug/1389014 [23:32] Bug #1389014: juju AWS EC2 "unit-get public-address" gives private address [23:33] lazyPower, take a look [23:33] themonk: thanks, i'll ping in the dev channel with this and someone should update the bug soon [23:42] themonk: anotehr thought - was your EC2 instance perhaps provisioned in a VPC? [23:44] lazyPower, what is 'provisioned in a VPC' ? [23:45] themonk: VPC networks are virtual private clusters - subnetted units out of the AWS public cloud space to add another layer of isolation on your services running on top of EC2 [23:45] lazyPower, all i do is give juju my access secret and using it [23:45] ack. [23:46] lazyPower, i dont think so [23:46] lazyPower, i mean no VPC [23:46] Ok, Just another possible reason it might be doing that === kadams54 is now known as kadams54-away [23:46] themonk: what i'm getting back from core - executing this on the unit is basically how juju determines the unit ip [23:46] curl http://169.254.169.254/latest/public-ipv4 [23:47] it polls the AWS metadata url to return the public address, AWS meta is responsible for all of the assignment [23:47] themonk: can you run curl http://169.254.169.254/latest/public-ipv4 [23:47] on that machien that thinks it's private IP is it's public [23:52] davecheney, i run it but getting a xml with 404 [23:52] davecheney, 404 - Not Found [23:53] hmm [23:53] let me check again [23:53] i was reading that from the aws domcunebt [23:53] documentation [23:58] curl http://169.254.169.254/latest/meta-data/ [23:59] davecheney: ^ i think thats what we were looking for right? http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html