| === hspencer[afk] is now known as hspencer | ||
| bkerensa | imbrandon: have your considered submitting some patches to OpenPhoto? :) | 06:45 |
|---|---|---|
| jcastro | hey jamespage, how's june 7th look on your calendar? | 13:25 |
| jcastro | we have 2 webinars to do, but it's right around clint baby time | 13:26 |
| jcastro | and we can't move them | 13:26 |
| jamespage | jcastro, lol | 13:26 |
| jamespage | lemme take a look | 13:26 |
| jamespage | jcastro, I can work around 'bug triage' | 13:26 |
| jamespage | so I'm available | 13:26 |
| jcastro | 1500 UTC and 1800UTC are the times, I take it the second one is out of hours for you? | 13:28 |
| vila | I'm trying to update a charm that was started for oneiric (lp:~canonical-bazaar/charms/quantal/udd/trunk), but when I try to push at lp:~canonical-bazaar/charms/quantal/udd/trunk, I get: bzr: ERROR: Permission denied: "~canonical-bazaar/charms/quantal/udd/trunk/": : No such distribution series: 'quantal'. | 13:29 |
| vila | meh, first url is: lp:~canonical-bazaar/charms/oneiric/udd/trunk | 13:30 |
| vila | jcastro: ^ any idea ? | 13:31 |
| mgz | they've moved. | 13:32 |
| mgz | just delete the current branch and push up again. | 13:32 |
| vila | hey mgz :) | 13:32 |
| vila | that was an initial push | 13:32 |
| vila | and branching from lp:~canonical-bazaar/charms/oneiric/udd/trunk worked | 13:33 |
| vila | mgz: so what did move ? | 13:33 |
| jamespage | jcastro, its a bit late but I can time shift to accomodate if needed | 13:34 |
| jcastro | I'll see if negron or mims can do the 2nd one | 13:35 |
| mgz | vila: just push to a non-distro path for now | 13:35 |
| mgz | as you're just developing it, doesn't need a fancy path to work with the charm store | 13:36 |
| mgz | so just push lp:~canonical-bazaar/charms/udd | 13:36 |
| vila | true, I can work locally | 13:37 |
| vila | bzr: ERROR: Permission denied: "~canonical-bazaar/charms/udd/": : Project 'charms' does not exist. | 13:37 |
| vila | forget it, I'll work locally | 13:37 |
| jamespage | jcastro, ta | 13:38 |
| jamespage | jcastro, assume we have some pre-canned stuff for the webinar? | 13:38 |
| jcastro | yeah, it's just some slides we can reuse | 13:38 |
| jcastro | we'll have a call like, earlier that week | 13:38 |
| jcastro | and bash it out | 13:38 |
| jamespage | jcastro, ack | 13:38 |
| jcastro | it's easy, I set them up with the lies and promises, you tell them what it really does. :) | 13:39 |
| jcastro | then you field live questions from the audience | 13:39 |
| jcastro | it's pretty fun actually | 13:39 |
| mgz | vila: confusing, that should work | 13:42 |
| vila | mgz: yeah, I'm confused too by the url scheme used here, which is why I asked the question in this channel | 13:43 |
| mgz | so, the old scheme was lp:~charmers/charms/SERIES/PROJECT/trunk | 13:45 |
| mgz | and quantal happens to not have been created yet | 13:45 |
| mgz | the new scheme is lp:charms/PROJECT | 13:45 |
| mgz | what personal forks are meant to be now isn't clear, I don't see why lp:~USER/charms/PROJECT shouldn't work, but no one seems to be using that yet | 13:47 |
| === lamont` is now known as lamont | ||
| cheez0r | Hey folks, I'm trying to stand up Maas+JuJu and I'm encountering something strange when running 'juju bootstrap'- the account has a ssh keypair, but when I run 'juju status' I get repeated errors that read "<DATE> ERROR SSH forwarding error: ssh_exchange_identification: Connection closed by remote host" and nothing else, seemingly indefinitely. | 16:01 |
| cheez0r | Is this just a 'be more patient, it'll respond eventually' situation or a 'you're missing a step' situation? | 16:02 |
| mgz | cheez0r: can you just ssh to the host directly? | 16:02 |
| cheez0r | I don't know its IP address, MaaS doesn't give me that info | 16:02 |
| mgz | it may be that either it's borked in your known_hosts, or the ssh server isn't up yet | 16:02 |
| mgz | cheez0r: if you pass -v when doing status you'll get more info, including the host name | 16:04 |
| cheez0r | k thanks | 16:04 |
| cheez0r | hrm, it's specifying a hostname in the ssh connect, not an IP | 16:06 |
| mgz | cheez0r: right. | 16:07 |
| cheez0r | This is strange, because I'm using the steps in the howto- the dns name doesn't resolve though | 16:08 |
| cheez0r | is there a DNS Server on the MaaS host that it's using? | 16:08 |
| mgz | not sure. | 16:12 |
| marcoceppi | cheez0r: have you installed mass-dhcp? | 16:13 |
| mgz | amusingly, there's a comment in the juju code saying it really wants an ip, but txaws only exposes the host... which then spread to the design of all the other providers | 16:13 |
| cheez0r | marcoceppi: yes, which apparently installs dnsmasq, so I'm adding a new dnsmasq.conf file now | 16:14 |
| cheez0r | I'm going to try defining the hostname it's looking for and see what it does | 16:14 |
| marcoceppi | cheez0r: right, maas master does all sorts of dns fun times | 16:14 |
| cheez0r | marcoceppi: right, so I added the nodes to MaaS and specified a hostname there, shouldn't it add entries for each of those hostnames so they resolve? | 16:16 |
| marcoceppi | cheez0r: it should, if the machine was fully commissioned. You'll also have to make sure your machine is using the MaaS as it's DNS reslover | 16:16 |
| cheez0r | right- I'm following the howto at https://wiki.ubuntu.com/ServerTeam/MAAS/Juju#MAAS:_getting_started_with_Juju | 16:17 |
| cheez0r | it has me install dnsmasq on the MaaS host and then commission the nodes | 16:18 |
| jcastro | imbrandon: huats: ajmitch: koolhead17: AlanBell: MarkDude: https://lists.ubuntu.com/archives/juju/2012-May/001662.html | 16:23 |
| jcastro | ^^ and other folks working on juju charms, hp has donated 3 months worth of instance time on HP Cloud. See the mail for more info. | 16:23 |
| marcoceppi | \o/ | 16:24 |
| * koolhead17 clicks | 16:24 | |
| MarkDude | Inm a minute, I just woke up to my name in an ITworld article http://www.itworld.com/it-managementstrategy/279368/oscon-nonprofit-pavilion-deals-limited-space | 16:24 |
| cheez0r | HP is doubling down on Juju/Ubuntu | 16:24 |
| koolhead17 | marcoceppi, hola sir | 16:24 |
| MarkDude | Way cool | 16:24 |
| koolhead17 | awesomeeeeeee | 16:24 |
| jcastro | MarkDude: imbrandon: it'd be _awesome_ to use HP Cloud to build the first cut of the RPMS? | 16:24 |
| MarkDude | That sounds like a good idea | 16:25 |
| * MarkDude is waiting for elections to be over 1st. I was concerend I would get involved folks that dont win their posts | 16:25 | |
| koolhead17 | jcastro, RPMS | 16:27 |
| SpamapS | jimbaker: hey, I was thinking more about an "unprovider" and I had an interesting thought | 16:35 |
| SpamapS | hazmat: ^^ | 16:36 |
| jimbaker | SpamapS, what's that? | 16:36 |
| SpamapS | What if we just added an 'add-machine' and 'remove-machine' command? | 16:36 |
| SpamapS | Doesn't most of the information about the machine come not from queries to the provider, but from the machine agent? | 16:36 |
| jimbaker | SpamapS, but such machines would not be managed by the provisioning agent? | 16:37 |
| jimbaker | SpamapS, it's registered in ZK, the PA doesn't sit in the path. so if the add-machine/remove-machine were to do the registration in ZK, that probably would work | 16:38 |
| SpamapS | something like 'juju add-machine --private-address 1.2.3.4 --public-address 4.5.6.7' | 16:38 |
| SpamapS | jimright | 16:38 |
| SpamapS | jimbaker: right | 16:38 |
| jimbaker | SpamapS, we could probably play with this first in jitsu. seems like a good idea to me | 16:39 |
| SpamapS | yeah we could | 16:39 |
| SpamapS | have to think more about how the provider code will be utilized tho | 16:39 |
| SpamapS | IIRC, only the provisioning agent makes calls to the provider code | 16:39 |
| jimbaker | SpamapS, basically you would just to ensure that machine agent is running on the given machine, since that's what the provider/provisioning agent work in concert on | 16:40 |
| SpamapS | hm, except the file storage bits | 16:40 |
| SpamapS | jimbaker: right | 16:40 |
| jimbaker | the file storage bits are important, as is access to ZK. the provider stuff works in concert to ensure that this all just works. but assuming some security setup, it could be done. worth doing, just to try out the idea | 16:43 |
| hazmat | SpamapS, an unprovider? | 16:46 |
| hazmat | you mean like a machine just registering itself? | 16:46 |
| jimbaker | basically jitsu add-machine/remove-machine could enable some sort of hybrid approach. you could provision machines with chef/puppet/capistrano/blaster of choice. link them to a juju environment in ec2. then at some point rework that so ZK/file storage could also be setup like that | 16:46 |
| hazmat | i've had a few feature requests for something similiar in private email | 16:46 |
| hazmat | however the provisioning agent is queried for all info about a machine | 16:47 |
| hazmat | status, dns, etc | 16:47 |
| jimbaker | hazmat, not the provisioning agent. it's not in that path. machine/user agents set status/addr info in ZK. eg, the unit agent is responsible for running set_public_address | 16:54 |
| hazmat | jimbaker, for the unit | 16:55 |
| hazmat | jimbaker, not for the machine | 16:55 |
| hazmat | its not the provisioning agent per se, but the provider | 16:55 |
| jimbaker | hazmat, correct | 16:55 |
| hazmat | if the provisioning agent can't find a machine's instance_id, it will attempt to allocate one.. if one exists and its not bogus, its just going to cause problems for the agent | 16:57 |
| hazmat | er. it is bogus | 16:57 |
| hazmat | SpamapS, what's the goal? | 16:57 |
| SpamapS | hazmat: allow juju to integrate into environmetns with an entrenched provisioning solution. | 16:58 |
| SpamapS | hazmat: I'm suggesting that we have a provider whose backend is just user provided data about the machine resources available... like MaaS without the "install a fresh new server every time" :) | 17:01 |
| hazmat | SpamapS, sounds useful | 17:02 |
| SpamapS | hazmat: yeah, and I was wondering if we can just fake it w/ jitsu.. but I think we'd need an actual provider for it actually | 17:02 |
| hazmat | indeed | 17:02 |
| jimbaker | SpamapS, still a pretty minimal provider impl for the "unprovider"; the provider is necessary for juju admin access to ZK (it provides connect) and for such things as looking up an ip address from an instance id (see for example, juju.control.utils). it should not be much more than what the dummy provider does | 17:29 |
| SpamapS | jimbaker: Yeah just needs a source of truth | 17:30 |
| SpamapS | jimbaker: which could perhaps just be ZK. :) | 17:30 |
| jimbaker | SpamapS, indeed, sounds like an excellent source of truth :) | 17:31 |
| jcastro | imbrandon: marcoceppi: hey so as far as moving the bootstrap. | 20:57 |
| jcastro | is this something we should file a bug on? | 20:57 |
| jcastro | "don't let people do this." | 20:57 |
| jcastro | or were we cheating to being with? :) | 20:58 |
| imbrandon | yea, there is a bug | 21:02 |
| imbrandon | iirc | 21:02 |
| imbrandon | jcastro: ^ | 21:02 |
| jcastro | ok let's deal with that later | 21:02 |
| imbrandon | np/win 26 | 21:14 |
| === izdubar is now known as MarkDude | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!