[00:17] bcsaller: hey, if you're still around it'd be awesome if you could take a look at https://code.launchpad.net/~jose/charms/precise/wordpress/fix-1309980 [00:43] Juju Icehouse-Openstack LXC | http://askubuntu.com/q/490164 === pmatulis_ is now known as pmatulis === FourDollars_ is now known as FourDollars === vladk|offline is now known as vladk === CyberJacob|Away is now known as CyberJacob === vladk is now known as vladk|offline === vladk|offline is now known as vladk === scuttlemonkey is now known as scuttle|afk [07:45] Hi I am writing a basic charm that should just take a given tar file open it and install a program. 2 questions: first what is the best place to place the tar file? second: This charm does not provide or require anything. Can a charm not provide and not require? Thanks! === rogpeppe2 is now known as rogpeppe [07:55] yaell: every charm should provide something. And the placement of the tar is up to you as the charm author. [07:58] Thanks! So if the charm just installs a program what should it provide? [07:58] That depends on what it's installing. [07:59] but ideally it should provide an interface to interact with the application. eg: if you're installing a minecraft server - it should expose an interface that sends the service ip, and port for connections. [08:01] I'm installing a driver and toolkit. [08:01] hmm. is for like an SDK type installation? [08:02] or is this more for ' i have a service that depends on this driver and toolkit, and i need this everywhere in my network'? [08:04] It's a driver that supports a nic so yes I depend on it and need it in my network [08:05] That sounds like a prime candidate for a subordinate. https://juju.ubuntu.com/docs/authors-subordinate-services.html [08:06] the idea behind a subordinate is it doesn't actually create a machine to occupy on the service map. it is deployed within scope:container of other services. So consider the scenario you deploy a Redis server - and attach this subordinate to the redis instance. The subordinate is deployed to any machine of the redis service that gets spun up, as its a subordinate attached to the redis cluster. [08:08] That removes the requirement of having a provides, and you consume the juju-info explicit relationship when defining your subordinate. Now it adheres to the proper interface guidelines, and your charm is portable to any service (therefore any machine) [08:11] Ok I will take a look at it sound like it is the solution to my problem :) Thanks a lot! [08:12] No problem === rogpeppe1 is now known as rogpeppe === gmb is now known as breakum-binns === breakum-binns is now known as gmb [11:43] some here with knowledge about network settings in a bootstrapped juju node [11:45] trying to change network setting and not able to ifdown primary interface === jam is now known as jam1 === psivaa_ is now known as psivaa-lunch [12:21] schegi, is it a maas environment? [12:22] if so then Juju will have automatically create a bridge on eth0 -> br0 for use with LXC instances [12:34] got the following problem: first my interface use the new naming sceme em1 , em2, p1p2 etc 2nd problem if i have bootstrapped my juju node i like to change the networks to use bonding on all 1g interfaces, added a new interfaces file and brought up the interface manually works fine. but on reboot the node hangs somewhere in cloudinit.net something [12:34] jamespage and yes its a maas environment [12:34] does i have to change it somewhere in the maas?? [12:37] negronjl, the last commit you landed for charm-helpers breaks the unit tests btw === vladk is now known as vladk|offline [12:41] negronjl, I've reverted it - please ask the author to try again :-) [12:44] schegi, no - maas and juju don't support manipulation of network devices in this way (yet) [12:52] jamespage, yes i thought so but, as i said rebooting the bootstrapped juju node with modified interfaces and bonding load as module, doesn't bring up the network interfaces and bonds and later on just hangs in cloud-init-nonet. seems that cloud-init somehow changes /e/n/i on reboot. is that right?? [12:53] at least it changes the first interface. because if i leave this interface as it is all bonds come up and everything works fine [12:53] schegi, I'd hope not after first boot [12:53] schegi, its possible juju is mangling something [12:53] no after juju bootstrap the node is reachable but if i then change the first networking interface in /e/n/i and reboot the machine is not reachable any more [12:56] schegi, yeah - juju might be doing something on the reboot [12:57] jamespage, is this configurable? somehow? where to look up what juju is doing any idea? [12:57] schegi, also it adds something into /e/n/interfaces.d for br0 - that might be causing this [12:57] schegi, its not configurable [12:58] at least I don't think it is [12:58] * jamespage may be wrong [13:16] Hi all, anyone want to help with a juju error while bootstrapping juju on maas ? [13:18] http://paste.openstack.org/show/85227/ [13:19] Caguax_: that was a known bug, stable has moved to 1.18.4 - can you upgrade and retry the bootstrap? [13:20] hello everyone, any plans for nginx charm? [13:21] Let me try that, Just upgrade juju, right ? [13:22] sudo apt-get update && sudo apt-get upgrade should catch it [13:22] thats only necessary if you've got a currently running/deployed juju thats behind the current stable tip [13:27] sudo apt-get update && sudo apt-get upgrade, did not catch it. [13:27] root@luflores-maas:~# juju version [13:27] 1.18.1-trusty-amd64 [13:27] root@luflores-maas:~# [13:27] hmmm... do you have an apt-proxy? [13:28] it may be behind in the packages. [13:28] or perhaps its pinned at 1.18.1? there's quite a few reasons why it wouldn't be updating - and without having insight i dont know what to recommend. === psivaa-lunch is now known as psivaa [13:29] This is just a new install. Trusty was install, then maas and juju [13:30] well thats the shipping version, there's definately an update though. [13:32] stokachu, ping? [13:32] mattyb, pong [13:32] mattyw, pong [13:32] Let me figureout the how to upgrade and I will try again [13:32] stokachu, hey there, I read your blog post earlier about the cloud-installer (I'm the mattyw that posted that bug on github this morning) [13:33] Sounds good Caguax_ [13:33] mattyw, hey man, i got your bug report and was curious if `juju bootstrap` works outside of the installer? [13:33] stokachu, quick question I had, I have two machines that I'd like to try the multi install on. One of them has 8GB ram but the other one only has 2.5GB I wondered if there's any order I should do the install to get the best results? [13:34] stokachu, juju hadn't actually been installed, it was a fresh install of trusty [13:34] mattyw, so the machine with 8GB should run all your services except for nova-compute [13:34] sudo apt-get update && sudo apt-get upgrade should have upgraded it. Maybe you don't have trust-updates repository enabled? [13:34] mattyw, actually flip that [13:34] the 2.5G ram should run everything but nova-compute [13:35] stokachu, and I need to install maas first right? [13:35] mattyw, the installer will install maas for you and set it up [13:35] you'll just need manually commission a machine [13:36] so basically run the installer and it'll go to the status screen and wait for a machine to be allocated via maas [13:36] at that point commission your 2.5G machine first and the installer will deploy all the services on there [13:36] then commission your 8G for nova-compute [13:37] you could commission both machines at the same time as the installer has constraints set for what it needs [13:37] so nova-compute should automatically use the 8G machine [13:37] stokachu, ok great [13:38] stokachu, I'll check it out and see how it goes [13:38] mattyw, cool man, hit me if you need help im EST and around all week [13:38] hit me up i should say [13:38] stokachu, ok great, thanks very much for your help [13:38] anytime :) [13:54] hi all [13:54] question: charms deployed in "manual" env are not deployed using LXC, right? [13:55] jamespage, seems that the bootstraped node only brings up the bonds after reboot but not the included interfaces [13:58] question2: is it possible to setup manual env, with one machine in this environment deploying charms as LXCs? === scuttle|afk is now known as scuttlemonkey [14:09] urulama, you can always use the --to parameter when deploying charms to define to which machine a charm should be deployed to and there is also an systax to define lxc host and container together with --to [14:12] stokachu, may I have permission to reuse parts of your blog post on the cloud installer to answer some askubuntu questions? [14:13] jcastro, of course! [14:15] urulama: right, charms deployed in a manual env are not necessarily deployed using LXC. [14:16] and as schegi pointed out, using the --to flag with lx:0 (for example) will deploy to an lxc container on machine 0. [14:16] you also have the opportunity of using --to kvm:0 if you need kvm containers if the host supports it. [14:17] lazypower: so with juju-local installed, and with --to lxc:N, the charm is automatically deployed using LXC? [14:17] lazypower: (installed on that machine) [14:18] are you wanting to use the local provider? [14:18] lazypower: no, no, just curious how to mix environments. using LXC on say machine 1, but KVM on machine 2 [14:18] in a manual setup, to deploy to a single machine in the manual environment you dont need to have juju-local installed. but yes, if you specify on the CLI --to lxc:# it will deploy to an lxc container on that machine. [14:19] lazypower: tnx [14:21] What terminal do you all use? Gnome terminal is ok, but I prefer an underline cursor but I'm getting tired of it being the same size as an underscore and thus not being able to see the cursor whenever it's on an underscore. [14:25] cory_fu: no help here, i use gnome_terminal [14:37] cory_fu, you can change the shape of the cursor [14:37] in gnome terminal [14:37] Block, I-beam, Underscore [14:37] mbruzek: The only options are a full-character-height block, vertical i-beam, and an underline that is indistinguishable from a typed underscore [14:37] cory_fu, what is wrong with the block? [14:38] I want an underline-style cursor, but to actually be able to see the damned thing when the cursor is on an underscore [14:38] Block is big and ugly [14:38] :) [14:38] can you change the font to have a slightly different underscore? or does the terminal use the underscore character? [14:41] Hi all...I update to 1.18.4 and now I am getting this...http://paste.openstack.org/show/85240/ NTP issue ? [14:42] Hrm. That's a good idea that I hadn't tried, mbruzek. Thanks [14:42] cory_fu, either that or just accept the ugly block cursor, or the slender i-beam [14:43] Just seems strange that the options are so limited [14:46] luflores: is this with a bootstrap? [14:46] lazypower: Yes, I ran juju bootstrap --upload-tools [14:47] hmm, and you're getting a time mismatch - yeah sounds like one of the clocks are skewed [14:47] who's operating in the future? :) [14:47] lazypower: Let me check my UCS Manager and set ntp. I have NTP running on the MAAS/JUJU server already [14:48] luflores: i would think thats coming from whichever work station you have running the bootstrap command. since you told it to --upload-tools - its generating that package and pushing the tools @ your bootstrap node [14:50] stokachu, for the cloud installer, what's the IP/url of the dashboard? and is there a login and password? [14:50] (adding in some detail to your post) [14:50] hmm if I don't run the --upload-tools I get curl: (6) Could not resolve host: streams.canonical.com, but the machine can resolve the name [14:51] jcastro, so the horizon dashboard url will be displayed at the bottom of the status screen [14:52] and you are prompted to enter a password in the initial install dialog [14:52] so that would be used to login to horizon as the admin [14:52] there is also an ubuntu user with the same password that can be used to deploy instances under that account [14:53] ack [14:53] the only thing im not able to change is the juju gui password [14:54] isn't it just a config option? [14:55] thats what i thought but it apparently isnt the same for the login part [14:55] i think that only reads the jenv file [14:55] you should file a bug, that seems wrong/weird [14:55] i filed a bug on it awhile back and was told it wouldnt change [14:55] oh, :( [14:55] lemme see if i can find it [14:56] well, I think UX wise, if someone is doing a cloud installation and wants to set all the passwords in one go, that seems the best way to do it [14:56] yea same here === vladk|offline is now known as vladk [14:57] jcastro, https://bugs.launchpad.net/juju-gui/+bug/1317109 [14:57] <_mup_> Bug #1317109: unable to override login password

[14:58] ah looks like thumper updated it recently [14:58] I wouldn't call May recent, heh [14:58] but i dont know how that will affect the gui login [14:58] we should add this to the cross call [14:59] I'm on it. [15:01] jcastro, cool, that will get discussed this thursday? [15:01] luflores: whicih machine? the one being bootstrapped or your workstation? [15:01] stokachu, I added it to the agenda [15:01] jcastro, thanks! [15:01] luflores: that would be the onus of the bootstrapped machine, and iirc - that's all being routed through the MAAS dns configured services. which *should* be forwarding those requests [15:02] but i'm not positive it is, its been a bit since i've looked at the default maas dns setup [15:02] stokachu, huge major flaws always get fixed, it's the little stuff like this that papercuts people to death [15:02] so when I see them I try to stomp them with fury [15:02] haha i agree [15:02] stokachu, the answer could very well be "wait for juju user and auth to land", but we can at least track it [15:02] sounds like a plan [15:04] out of curiosity, when it's finished where will the cloud installer land? Backports? cloud archive? [15:04] jcastro, its in the archive now and each dev release i upload the latest, i think for trusty though we're going to push newer updates via backports [15:05] since this is a 'soft release' im keeping all the latest bits in the ppa until we're ready to advertise it in the official ubuntu archives [15:07] jcastro, i'd also like to get a more permanent home for the documentation, right now its on readthedocs.org [15:08] no ubuntu branding or anything [15:08] as soon as they find out where the cloud docs will go they will tell us, I figure this can just be part of that. [15:08] ok cool [15:11] lazypower, I said it is that jose we have to worry about! [15:11] what?! [15:11] what happened? [15:12] jose: mbruzek said it. for the record ;) [15:12] :P [15:12] well [15:12] jose we are having problems with chamilo [15:12] and I blamed you [15:12] lazypower: The error is on the machine where I run the 'juju bootstrap command' [15:12] mbruzek: may I know what those are? I'm free today [15:13] jose, tvansteenburgh was having problems with the charm. The test failed differently for me than Tim. Apache2 does not seem to be running on 10.0.3.173 [15:14] mbruzek: let me double check the code I pushed to the branch [15:15] jose, Tim was getting an apt-get install error, I did not see the apt-get problem, just the message and failed test. [15:15] jose also 00-setup needs -y flags on add-apt-repository and apt-get install [15:15] mbruzek: yeah, apt-get was showing in the local provider, but not on the cloud [15:15] and see bug #1335340 [15:15] <_mup_> Bug #1335340: 00-setup's apt does not have -y flag [15:17] jose, good call on filing that bug! [15:17] jose, hopefully we can fix that soon. [15:17] if you point me to where those files are generated, I could surely fix them [15:18] its in a template directory [15:18] grep -ri through the source tree, its only in 1 spot [15:18] lp:charm-tools [15:19] cool, thanks [15:19] I'm running my tests now too [15:31] lazypower: I modified the ntp server on the maas server and now all is good...now to the next issue :) Thanks [15:31] luflores: brilliant news! Glad its sorted :) still having an issue with resolution? [15:32] lazypower: I am going to test that next, but I trying to use maas/juju for openstack deployment === luflores is now known as Caguax [16:07] when I deploy a new nova-compute using juju, it is using ubuntu 12.04. How do I make it install 13.10 instead? I tried changing the version by editing the node, which didn't help. [16:09] khuss: maybe this can help you http://juju-docs.readthedocs.org/en/latest/provider-configuration-openstack.html [16:09] sebas5384: o/ [16:10] hey! lazypower o/ [16:10] :) [16:10] whats up skillet? [16:11] lazypower: here I am struggling with the drupal charm hehe (finally i have time for continue) [16:11] sebas5384: thanks. let me check [16:12] sebas5384: which version of the drupal charm? you had a branch, and there was another using drush [16:12] lazypower: https://github.com/sebas5384/charm-drupal [16:12] master branch [16:12] and i think there were some crusty copies of drupal floating around somewhere [16:12] its in ansible :) [16:12] yeah, but none of them are like production and development ready [16:13] using best practices known by the community [16:13] i was showing the charm to a guy of acquia and he love the ideia [16:13] another thing i make is the icon hehe [16:14] *made [16:14] right on [16:15] I'm going to finish the first milestone and then i'm gonna comeback to the issue in launchpad where are happening some review :) [16:16] good plan. ping me when you're ready for a review, i'd love to look it over [16:16] awesome!! thanks! :) [16:16] i'm a bit bured atm in a charm rewrite, but i always enjoy a fresh look at new cuts on an old charm. [16:16] hehe [16:17] i would love to rewrite all charms in ansible hehe [16:17] extending some roles === vladk is now known as vladk|offline [16:17] all? thats ambitious [16:18] hahaha yeah i was kidding [16:19] nope, i have it on record that sebas5384 is going to rewrite all the charms in ansible. pack it up everybody, sebas's got this one. [16:19] ;) [16:19] hehehhee [16:19] oh!! let me ask you something about subordinated charms [16:19] go for it [16:20] when i make a relation between drupal<>varnish for example [16:20] i must pass some default.vcl file for make the proper configurations [16:20] and thats its like the same case with apache solr relation [16:21] so, what should be the best way? [16:21] i sow some solutions around [16:21] whats the purpose of this default.vcl file? [16:21] is it configuring drupal.. or... [16:21] like sending a hash of the file, or making a subordinated charm to make this customizations [16:22] well, you've got a few options. you can base64 encode it so it retains its integrity when being xferred over the wire [16:22] its a custom configuration for avoid some agressively cached things [16:22] or you can use the subordinate and relate it to any service that needs it and rely on relationships to do the configuring [16:22] ok, theres goes #1 [16:22] uh oh, this looks like a problem: tests give a different exit code after the first tun [16:23] but be careful - you'll want to make sure you account for any config-changed hooks not over-writing the settings if they are present, its sometimes prudent to make portions of a config immutable and only under the governance of that specific relationship hook - so in that case its difficult for me to tell you what to do aside form create a sentinel file, load it into an ansible variable on dont act on it if that predicate value is true. (if that makes [16:23] *any* sense at all) [16:23] lazypower: ok, but when i make a relation drupal<->varnish the subordinated charm related to varnish knows about it? [16:24] i'm not super familiar with the varnish charm, i think varnish ootb is kinda dumb and aggressively caches everything, just like it would if you specify no config to varnish post deployment. it says "k i got it all boss, serving all the things" [16:25] it may require some tweaking of the varnish charm itself to support this. [16:25] yeah exactly [16:25] so the varnish and the apache solr [16:26] is there someone who could help with some cloud-init related problems during system boot or can point me to an irc channel or something like this? [16:26] are not for a automated topology set [16:26] probably i will had to give it a look to this charms after the drupal charm is ready [16:27] thanks for the tips lazypower ;) [16:27] sebas5384: well, again i'm not super familiar with it. it might expose a configurable interface. [16:27] if it does that, you should be able to ship over the config OTW [16:27] that would be ideal, considering there are special varnish caching strategies for different apps. [16:27] yeah, but it doesn't hehe [16:27] and in the case of apache solr [16:27] i know in my use cases for drupal/joomla/wp - i wanted to cache only assets and let scripts regenerate since we pushed updates frequently. [16:28] there are a lot of other files that i would like to override like stopwords.txt file [16:28] yes! [16:28] lazypower: in drupal you have a number of modules to integrate with varnish for example [16:28] so using the headers [16:29] you can dynamically change the rules of caching [16:30] well, in that case, its probably going to need modifications. Just keep in mind if you're going for having it in the charm store ~charmer recommended charm, it'll have to be compat with drupal and everything else. [16:30] which is going to be tough, because i can see scope creeping quickly on that... [16:30] all of that is domain specific [16:31] yeah, but others like wordpress have that problem too [16:31] if we just do some more relation variables to configure each instance of the varnish or cores of solr [16:32] should be ready for others that might need that level of costumization too [16:33] cool. :) [16:33] thats why i was thinking in the responsabilities, subordinated charm, or a nice relation-set variable to pass the files [16:33] hehe [16:33] sounds like you've got some ideas, i'll let ya to it and we can reconvene during review [16:33] great! :D [16:34] thanks sharing your thoughts :) [16:35] hey sinzui, https://bugs.launchpad.net/juju-core/+bug/1242468 [16:35] <_mup_> Bug #1242468: Boilerplate for HP Cloud missing several keys

[16:36] what's the recommended method for hp cloud? [16:36] like, shouldn't we be telling people to use keys? [16:36] jcastro: yep, we should be. Thats more secure than putting L/P in there. [16:36] yeah I just need a snippet from someone using it with keypair to fix the docs [16:37] i thought the boilerplate had the key sections in there jsut commented out [16:37] I have a card to fix up the hp page today [16:37] # auth-mode: keypair [16:37] # access-key: [16:37] # secret-key: [16:37] thats what was generated by juju back in the 1.16 series [16:37] hah I see what happened [16:37] jcastro, looks like that bug is fixed in 1.19.4 and I should close it [16:37] not sure whats changed in the 1.18+ since i havent regenerated my env.yaml in quite a while [16:38] I used quickstart and it doesn't include the commented out sections [16:38] ah, nice [16:38] TO THE BUG TRACKER! *points for great justice* [16:40] actually, no, if we just make it correct in the template .... [16:40] lazypower, 1.17/1.18 wrongly removed interesting config advice for HP. When HP closed their old regions, the devs were encouraged to fix the config [16:41] sinzui: ah, i should probably be regenerating my template between point releases and migrate data instead of leaving all this cruft in here. [16:41] i mean, my hp cloud config right now isn't even useable thanks to them closing down the old api and moving to horizon. i haven't put in the effort required to get the new config setup. [16:42] lazypower, be careful if you use 1.18, It doesn't know the new region and use-float true [16:42] good looking out. [16:42] jcastro: thats noteworthy ^ [16:42] i doubt we'll be having a lot of people on 1.19 reading the docs since thats -devel [16:43] yeah I am trying to get it working [16:43] 2014-07-01 16:43:31 ERROR juju.cmd supercommand.go:305 cannot start bootstrap instance: index file has no data for cloud {az-1.region-a.geo-1 https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/} not found [16:43] lazypower, jcastro the charm-bundle-slave has cloud-city. Its environments.yaml for charm testing is configured for modern HP, and specifically US East where you have 40 instances all to yourself [16:44] stuck on this [16:45] sinzui: over half of that was greek to me. I know what cloud-city is, but what is this charm-bundle-slave you speak of? is that the testing instance we got? [16:45] sinzui, where can I see a sanitized copy of that config? I'm just trying to update the docs for modern HP [16:46] lazypower, jcastro . This doc goes out to all charmers. https://docs.google.com/a/canonical.com/document/d/1mqO2geOuQwTMNpja2MG0B2JW4By6xy3GBc2o-dEGrNQ/edit [16:46] oh is this for the automated testing? [16:46] oh i've seen this! [16:47] i had no idea thats what you were talking about. ok. cool - i'm more up to date thatn i feared i was. [16:47] jcastro, the slave has a copy the the cloud-city dir, The charm-testing-hp env is what charm bundle testing will use. It is a valid config. [16:47] ack [16:48] I am getting access denied with my key [16:49] yuck [16:50] jcastro: i'm in,,,, let me get you the bits you need [16:51] jcastro, oops, wrong users [16:51] oh i did doc the right user [16:52] jcastro, are your keys on Lp correct? [16:52] yessir [16:52] I get to the power machines just fine [16:52] sinzui, we can sort it later; as long as lazypower can get me a working config to fix the docs [16:53] jcastro: sent to you over canonical irc pm. [16:54] its using user/pass though... combined with the paste i gave you earlier should be g2g, make sure we verify before its up in teh docs though - i'd hate to be wrong on that... [16:54] my notify-osd is crying right now [16:54] yeah, we want to use keypass, not username/pw [16:54] sorry :) i should have dumped that in canonical pastebin now that i think about it [16:54] next time man, i'll do it right next time. [16:54] it's all good [16:55] i always forget we have a nice password mfa protected pastebin === rogpeppe1 is now known as rogpeppe [16:55] pastebinit has spoiled me [16:55] 2014-07-01 16:43:31 ERROR juju.cmd supercommand.go:305 cannot start bootstrap instance: index file has no data for cloud {az-1.region-a.geo-1 https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/} not found [16:55] any idea on this? [16:55] I think the keypair auth is working [16:55] I am just having another error [16:55] hmm thts teh same thing i get [16:56] and mine is with the old config. the AZ data looks correct though [16:56] lazypower, There is no az data i modern config. HP is Havana now, the AZs aren't hard coded [16:56] http://pastebin.ubuntu.com/7732336/ [16:57] this is what I have [16:57] bogus region [16:57] bad ip [16:57] bad use-floating-ip [16:58] http://curtis.hovey.name/2014/06/12/migrating-juju-to-hp-clouds-horizon/ [16:59] did we not update the docs for that? [16:59] no matter, I'll fix it now [16:59] jcastro, the release candidate shows this http://pastebin.ubuntu.com/7732342/ which has the right use-floating-ip and advises a sensible region [17:00] ok so it's fixed in the template, so I don't need to file a bug there [17:00] ok, working on the docs now, I'll have a PR with working HP in a few minutes [17:00] it's working now [17:01] jcastro, great. Your the first person to confirm my recommendations I have had this nagging fear I missed something [17:03] can someone tell me what cloud-init is doing on boot on a bootstraped node?? [17:04] 2014-07-01 17:02:59 ERROR juju.cmd supercommand.go:305 cannot start bootstrap instance: cannot assign public address 15.125.121.196 to instance "7eb9f960-45d6-4e30-8b0a-2cca4f925b67": failed to add floating ip 15.125.121.196 to server with id: 7eb9f960-45d6-4e30-8b0a-2cca4f925b67 [17:04] is this our fault or theirs? [17:07] schegi: its updating sources, f etching additional dependencies like rsyslog-forwarder, etc. [17:10] sinzui, I made a mistake, the HP Docs are up to date other than the keypair part, which I'm fixing now. [17:10] i got some problems with it. When changing my /e/n/interfaces it sleeps for a couple of minutes in cloud-init-nonet. here my boot.log http://pastebin.com/xYFynAWS [17:17] If someone has a minute [17:17] https://github.com/juju/docs/pull/132 [17:18] sinzui, since you're on the dev release, can you tell me if `juju help hpcloud` mentions username/password or keypair? === vladk|offline is now known as vladk [17:32] hi all === alexisb is now known as alexisb_afk === gmb is now known as breakum-binns === urulama is now known as uru-away [17:55] http://askubuntu.com/questions/490141/deploying-charms-using-juju-fails-with-tcp-connection-timed-out [17:55] anyone see this before? [17:55] looks like it's trying to hit the public store but can't [17:59] jcastro: probably related to the maas proxying. all your subs proxy through the cluster controller as i understand it. [18:25] mattyw, what version of juju do you have? [18:26] hazmat, remember my bug that said m1.smalls shouldn't be the default? [18:26] http://aws.amazon.com/blogs/aws/low-cost-burstable-ec2-instances/ [18:27] I wish we had storage sorted [18:28] stokachu, I'd have to double check [18:28] jcastro, yeah.. saw those looks interesting [18:29] jcastro, we need new a bug to update the instance types in core with those as well [18:29] mattyw, http://paste.ubuntu.com/7732683/ [18:29] mattyw, make sure you running 1.18.3 or higher [18:29] hazmat, doing it now [18:30] oh wtf [18:30] mattyw, i just saw the comment of the deprecation [18:30] hazmat, https://bugs.launchpad.net/juju-core/+bug/1336473 [18:30] <_mup_> Bug #1336473: Support new t2 instance types on AWS [18:31] stokachu, the machine I ran the script on was a clean version of trusty so it got whatever version came out of the packages. my local machine is 1.19.3 and that warns me about deprecation [18:32] stokachu, I hadn't actually realised use-clone was ever valid - that's my bad, sorry [18:32] mattyw, nah man you're good and i appreciate the bug report [18:33] mattyw, there seems to be some issues with things being renamed, deprecated at an alarming rate [18:33] stokachu, for the record the version is was running was 1.18.1 [18:33] stokachu, which is what it got from the packages [18:33] mattyw, yea so lxc-use-clone was introduced in 1.18.3 and now is apparently deprecated in 1.19.x and newer [18:34] hazmat, they've basically removed m1's totally from the instance pages and the pricing pages [18:34] stokachu, ok - that pull request isn't going to cut it at the moment then [18:34] stokachu, we probably just need to have a pre requsite for a particular version of juju to be installed [18:35] mattyw, yea, also i need to talk to the juju guys to figure out what their plan is [18:35] 1.18.3 will be lxc-use-clone but 1.22 will be lxc-clone [18:35] as far as those comments state [18:37] mattyw, maybe thinking of just setting a hard version requirement in the debian package [18:38] stokachu, that's probably a good options [18:38] stokachu, I'll close that pull request for now then [18:39] mattyw, cool man, if you run into anything else like that with deprecation warnings being printed let us know [18:39] stokachu, I'm going to try out the multi instance install tomorrow, I'll let you know how it goes! [18:39]