/srv/irclogs.ubuntu.com/2014/05/22/#juju.txt

=== menn0_ is now known as menn0
=== jcsackett_ is now known as jcsackett
=== vladk|offline is now known as vladk
=== zz_swebb is now known as swebb
=== CyberJacob|Away is now known as CyberJacob
=== sarnold is now known as sarnold_
=== vladk is now known as vladk|offline
=== vladk|offline is now known as vladk
=== vladk is now known as vladk|offline
mattywmorning all - is anyone working on a trove charm?08:26
=== vladk|offline is now known as vladk
rbasakjamespage: good news! 1.18 rev 2294 passes dep8 in packaging in utopic in my local test.10:36
rbasakThanks axw!10:36
rbasakjamespage: so next: do we want to upload that, or wait for an upstream 1.18 release?10:37
jamespagerbasak, whens it due?10:37
rbasakjamespage: and I don't see an MRE for juju-core, so what's the SRU plan for Trusty?10:37
rbasakNo idea when it's due. Nothing is listed on https://launchpad.net/juju-core/1.1810:37
rbasakIs there a release schedule?10:37
axwrbasak: sweet :) no worries10:43
=== vladk|offline is now known as vladk
=== vladk|offline is now known as vladk
=== wwitzel3_ is now known as wwitzel3
=== vladk|offline is now known as vladk
=== vladk|offline is now known as vladk
=== vladk|offline is now known as vladk
=== psivaa is now known as psivaa-afk
therealmarvHello, I’m trying to get juju running with vagrant on my mac. I used this guide: https://juju.ubuntu.com/docs/config-vagrant.html but my vagrant machine is not doing anything. Last log message is:12:26
therealmarvTaking a nap to let Juju Gui get setup12:26
therealmarvscreenshot: https://www.evernote.com/shard/s6/sh/599d7275-386e-4673-a6aa-b980bdfb9674/47cfe11653f99b1cab31cb3f6234e6c2/deep/0/Vollbild-22.05.14-14-27.png12:28
rick_h_lol12:32
rick_h_who knew we were nap worthy12:32
rick_h_therealmarv: do you know if you used the 14.04 or 12.04?12:33
therealmarv12.04. It is indeed a very long nap… and seems without an end12:34
rick_h_hmm, I've not used the vagrant workflow. I wonder if it's loading the first image for the lxc machine or somethng12:34
rick_h_marcoceppi: or jcastro any idea on the delay at the gui deploy in this vagrant workflow? ^12:35
marcoceppitherealmarv: rick_h_ that's a utlemming thing, but it's basically just deploying the GUI and it takes anywhere from 30s to 5 mins12:37
rick_h_marcoceppi: yea, sorry I was going to ping him but don't see him around atm12:38
rick_h_therealmarv: guessing based on your irc timing that it's well past that timeframe?12:38
therealmarvI’m sure I’m waiting longer than 5 minutes…. seems really like a nap without end ;)12:38
rick_h_your vagrant image is tired!12:39
rick_h_marcoceppi: is there a place to file bugs on the images?12:39
therealmarvhehe12:39
marcoceppirick_h_: not yet, utlemming is going to be publishing the build process as open source by end of week. lazyPower is the one who knows most about this process12:39
rick_h_marcoceppi: ty much, I'll move to bugging lazyPower and utlemming12:40
rick_h_sorry for the trouble therealmarv, you're on the bleeding edge, which we greatly appreciate, and we'll have to work out some debugging tips and such12:40
therealmarvno problem. I will try local lxc install now on a fresh virtualbox image.12:42
sander^workDo anyone know if it costs anything to borrow the new "cloud in a box" for 2 weeks?12:50
sander^workOr who might know the details about that..12:50
sander^workOr what channel is most appropriate to ask in? :-)12:51
jcastrosander^work, kirkland is the person to talk to, though I am pretty sure he's just going to say to use the form, heh13:29
lazyPowertherealmarv: are you using the trusty or the precise vagrant box?13:34
therealmarvlazyPower: precise13:34
therealmarvdid not tried out trusty yet13:35
lazyPowertherealmarv: we're seeing intermittant issues with the trusty box. Precise is still the recommended basebox pending a fix for some fringe issues13:35
lazyPowertherealmarv: The Vagrant box is pulling down an intermediary redirector to place on the Vagrant image that will forward your requests to the JujuGui instance being deployed via LXC in the container. Did you tweak any of the settings in the Vagrantfile?13:36
therealmarvno nothing. I followed strictly https://juju.ubuntu.com/docs/config-vagrant.html13:36
therealmarvbtw I wonder if something in environment.yaml is needed because it is still default to amazon13:37
lazyPowerok. If you destroy the box and bring it back up does it progress past the gui setup nap?13:37
lazyPowerit should set the default to local during the boot sequence.13:37
therealmarvI’m guessing it is doing so (inside the vm). As I said I’ve done nothing special.13:38
therealmarvRecreating the same VM with precise had the same result: nap without end ;)13:38
therealmarvI also used everytime the 64bit version if this helps13:40
lazyPowerHmm.. Ok.13:41
sander^workjcastro, is there some online version of the courses involved with it? as I have hardware I could run it on.13:42
lazyPowertherealmarv: i'm booting, just a moment. Let me see if this is a wider problem than we are aware of13:43
therealmarvI’m testing trusty in the meantime… also booting now13:43
lazyPowertherealmarv: when you get a chance can you pastebin me the output from /var/log/juju-setup.log?13:45
therealmarvok will do… my machine is now waiting again on the critical nap (GUI)… let’s see if it goes further…13:47
=== psivaa-afk is now known as psivaa
lazyPowerrelevant output would also be fetching the output of juju status, and $HOME/.juju/local/log/all-machines.log13:48
therealmarvlazyPower: oh wow. Trusty worked! Strange… but I double checked precise which was napping forever13:51
therealmarvOutput http://pastebin.com/yL8cygDn13:51
lazyPowerInteresting. If Trusty works for you, tally ho then :)   You may encounter an issue with more than 2 or 3 machines deployed with juju complaining about being unable to clone running containers13:52
lazyPowerits intermittant though, so maybe it'll do fine13:52
lazyPowertherealmarv: thanks for the output. Looks like the redirector completed and the GUI didn't stand up - output from all-machines would be insightful if you've still got the instance up.13:55
therealmarvI will rerun precise setup… now13:56
jcastrosander^work, yep: https://insights.ubuntu.com/2014/05/21/ubuntu-cloud-documentation-14-04lts/13:57
jcastrowe're working on the html documentation now, but basically it's Juju/MAAS/OpenStack13:57
sander^workjcastro, a few years ago, I got stuck with an particular error targeted at the bios/hardware.. I guess it's fixed now :-)14:04
sander^workCool.. documentation looks nice.14:04
jcastroit really depends14:04
jcastrohow well the IPMI MAAS stuff will work14:05
jcastrobut there's been a ton of fixes this cycles, so I am willing to bet it will work14:05
jcastroif not, at worst you'll have to manually power on the machines, but you can cross that bridge when you get there14:05
sander^workNo problem.. as i'm using some remotely controlled bladeservers to test with.14:06
marcoceppisander^work: jcastro it's also pretty trival to make a new power module for MAAS14:06
marcoceppiit's a plugin based system14:06
marcoceppiso if the blade server has an API you could make a new power type in MAAS that knows how to talk to it14:07
sander^workCool.14:07
sander^workDoes it integrate with powering it up, for testing, on vmware or hyper v?14:07
lazyPowersander^work: there's incoming work to integrate it with HyperV, i'm unsure of the status of Maas with VMWare14:09
sander^workOk.14:10
lazyPowersander^work: there's been some discussion over VMWare on the mailing lists. I would encourage you to join the mailing list and ask the community at large at the status and if anyone has any insights for you with regard to your specific requirements.14:12
therealmarvlazyPower: juju-setup.log from precise: http://pastebin.com/t6EDmHTx14:15
therealmarvlazyPower: Precise is napping forever. Triple checked now.14:15
lazyPowertherealmarv: thats the same output from the juju-setup log, can you vagrant ssh in and get me the output from $HOME/.juju/local/log/all-machines.log?14:16
lazyPowersorry for the multi-log request, and thanks for helping!14:17
=== hatch__ is now known as hatch
therealmarv@lazyPower: here it is http://pastebin.com/qxi0ygSA np14:20
lazyPowertherealmarv: Brilliant, thank you!  Looks like the LXC container creation failed, and that caused the script to hang.14:21
lazyPowerI'll take this output and move from here. Thanks again therealmarv - you've been a big help14:21
therealmarvlazyPower: look at the last line  ubuntu-cloudimg-query trusty released amd64 --format '%{url}\n'; confused by argument: trusty; + url1=; container creation template for vagrant-local-machine-1 failed; Error creating container vagrant-local-machine-114:21
therealmarvglad I could help :)14:21
=== cory_fu2 is now known as cory_fu
=== tedg is now known as ted
=== hatch__ is now known as hatch
=== qhartman_ is now known as qhartman
whithey all, I'm having some issue with juju upgrade-charm and need a sanity check whether I'm seeing a bug or I'm just doing it wrong14:53
whitI run it like this: juju upgrade-charm --switch=local:trusty/mycharm --repository=file/repo myservice14:54
whitand it tells me it's updating the charm (and increments the version by 1)14:55
whitwhen I look on the unit ala cat /var/lib/juju/agents/unit-uaa-0/charm/.juju-charm14:56
whitthe version number is several behind what was reported by upgrade-charm14:57
whitall service units are resolved14:57
marcoceppiwhit: what does juju status show?14:57
whithey marcoceppi :), https://gist.github.com/whitmo/7acc7d87f7351df6cede14:58
whitmarcoceppi, maybe I jumped the gun.  I see the upgrading there14:59
marcoceppiwhit: yeah, it may take a hot seccond14:59
marcoceppiwhit: also you don't need to do --switch when just upgrading the charm14:59
marcoceppiswitch is more like "I want to go from charm store to local" or vice versa15:00
marcoceppiit's just as crazy clobberful as the --to flag15:00
whitmarcoceppi, but local to local is fine?15:00
marcoceppiwhit: yeah, so you can do upgrade-charm and point to a different --repository and everything without using --switch15:00
marcoceppijust as long as the revision file number is greater than what is currently deployed15:00
whitmarcoceppi, how is a revision tracked on a local charm?15:01
marcoceppithe revision file15:01
marcoceppiit holds an arbitrary number that represents it's "revision"15:02
whitah15:02
whitmarcoceppi, is bumping that necessary sometimes?15:02
marcoceppiwhit: never since 1.1815:02
marcoceppiit'll automatically do a +1 bump on upgrade-charm15:02
marcoceppiin past versions you had to do a -u flag, or manually increment it15:03
whitmarcoceppi, not seeing that15:03
whitthis is stuck at 001 (though juju is adding a -+1 to each description it pushes out)15:03
whitanyway, thanks marcoceppi !15:05
whitmarcoceppi, I had some old juju hanging around. thanks again...15:32
rbasakjamespage: do you have a minute? I've been testing "future" releases of juju so that the current Utopic bugs won't happen again.15:34
jamespagerbasak, bit busy right now15:35
rbasakjamespage: OK, I can leave it for now.15:35
jamespagerbasak, tomorrow am?15:35
rbasakjamespage: sure15:35
=== scuttlemonkey_ is now known as scuttlemonkey
=== vladk is now known as vladk|offline
s3an2I am doing a test deployment of openstack icehouse on 14.04, I am trying to use a dedicated network for ovs gre comunictions, however it is currently using the wrong NIC interface. I can see inside ./plugins/ml2/ml2_conf.ini the value local_ip that looks to be responsible for this but can not see how this can be changed to another IP on another NIC within juju15:59
=== roadmr is now known as roadmr_afk
=== roadmr_afk is now known as roadmr
=== roadmr is now known as roadmr_afk
=== hatch__ is now known as hatch
=== nottrobin is now known as cHilDPROdigY1337
s3an2I did notice that a chef build had this issue but it was patched, you can see this here https://community.rackspace.com/products/f/45/t/324516:40
=== cHilDPROdigY1337 is now known as nottrobin
=== roadmr_afk is now known as roadmr
=== roadmr is now known as roadmr_afk
arosalesjose: hello17:42
bodie_I'm trying to figure out whether I can use Juju to deploy CoreOS units.17:45
AskUbuntuCannot Download Charm From juju-gui | http://askubuntu.com/q/47073017:52
=== roadmr_afk is now known as roadmr
=== vladk|offline is now known as vladk
=== vladk is now known as vladk|offline
sebas538_bodie_: yeah that would be awesome18:11
=== sebas538_ is now known as sebas5384
sebas5384I sow a talk about the future of containers18:12
=== vladk|offline is now known as vladk
sebas5384and I think topology problems won't be the problem, because we will have something like "cluster of process"18:25
sebas5384like openshift do with cartridge x gears18:26
niedbalski__hey mruzek , Did you have a chance to review the remote pdb merge?18:26
bodie_sebas5384, yeah, have you checked out deis.io?  I think it runs on fleet18:36
sebas5384bodie_: hmm i will take a look18:40
bodie_fleet being a container manager for coreos18:40
sebas5384bodie_: yeah! I exactly that18:40
bodie_basically open source heroku18:40
bodie_looks soooo cool18:40
AskUbuntujuju bootstrap time-zone 7:00 hours front of server | http://askubuntu.com/q/47075118:42
sebas5384yeah18:42
sebas5384bodie_: theres always missing the relation hooks, that are so good in juju18:43
bodie_definitely great stuff18:48
sebas5384jcastro: how juju's vision is aligned with paas using things like deis.io ?19:11
jcastrowe don't really do paas we're a tool for people to deploy paas'es19:12
sebas5384jcastro: hmmmm that give me a lot to think19:32
lazyPowersebas5384: with a bit of configuration several of our juju charms (see: rails) woudl work with some paas aspects of continuous deployment - however juju by itself is not a PAAS, its IAAS, you deploy PAAS's over IAAS to handle the scale of your PAAS19:34
lazyPowerwhich is a long winded way of repeating what jorge just said... sorry for the duplication.19:35
sebas5384hmm thanks lazyPower19:35
bodie_jcastro, I'm interested in thinking about that too19:38
sebas5384i'm thinking if for a team of developers, juju is needed, because production can be exactly paas, becuase i can scale and do redundancy too19:38
bodie_jcastro: do you think it would be possible to abstract a CoreOS cluster into a deploy target such that containers could be deployed on them as services?19:38
bodie_or are you saying that's definitively not the goal19:38
jcastrobodie_, I think that would be totally awesome19:39
bodie_aye19:39
jcastroas far as juju is concerned, that's just another cloud19:39
jcastrothe same as "AWS" or "Rackspace"19:39
bodie_perhaps Fleet could be used as the deploy API19:39
bodie_I'm still trying to wrap my head around some of this19:40
bodie_basically, I'd really like to put together a thing where I can add CoreOS instances as needed19:40
bodie_and then those are deploy targets for... perhaps juju, perhaps something else19:41
jcastroI think maybe(?) hazmat has looked into stuff like this, not sure though19:41
bodie_I think the folks at deis.io are trying something similar19:41
bodie_cool, I'll have to ping him19:41
jcastroI asked them on HN why they didn't just use juju for the heavy lifting but they didn't like the license19:42
jcastrothere was another similar PAAS that was doing some of the same things, the name escapes me though19:43
* hazmat steps out of charm authoring19:43
hazmatbodie_, yeah.. deis.. pivoted heavily in the last few months.. from chef + docker + django.. to coreos + docker + django.19:44
hazmatbodie_, re coreos as a target.. its conceivable.. in a couple of forms, though perhaps not what your think of... the cleanest separation with orchestration would be a set of charms.. one per app (set of containers) that upon instantiation would drive the core os containers, and reconfigure their sysd conf based on relation changes.19:46
hazmatbodie_, more natively is tough since the docker full os container support is pretty primitive19:47
hazmati was playing around with the ubuntu-upstart images last night19:47
hazmaton the public registry, but they have some issues.. if you install a some packages in them... plymoth hangs and sleeps.. looks like some events missing for full os container startup.19:48
bodie_hmm19:52
sebas5384hazmat: should be more like, app container, not full os19:52
sebas5384or service container19:52
hazmatbodie_, the primary issue for orchestration is  that a typical docker container is a brick... you get to cli and env params only at runtime. if you want to orchestrate you need to be able to change that, and the only way to do that with app containers is to restart them round-robin.19:52
hazmatsebas5384, so for app containers.. we have a docker based charm in rethinkdb that illustrates using juju to orchestrate via restart of nodes on changes19:53
bodie_interestnig19:54
bodie_ting*19:54
hazmatmaking containers work in a general way (and play nice with non containers) also means handling first class networking for containers19:54
bodie_I was thinking perhaps if you want to alter things you simply plop down a new container and kill the old one once it's up19:54
hazmatwhich is  something we're working on atm19:54
hazmatbodie_, fundamentally for app containers you need to run multiples..  new one down and old one dead.. is risky around data volumes19:55
hazmatsebas5384,  bodie_, what's the use case.  are you interested in containers or image based workflows or?19:57
sebas5384hazmat: so docker runs into a lxc container(or not), and then to scale can be add more machines?19:57
hazmatsebas5384, or add more containers on other extant machines19:57
sebas5384hazmat: good question ;)19:57
hazmatsebas5384, bodie_ you can do containers today with juju .. both lxc and kvm19:57
hazmateven nest them :-)19:57
sebas5384yeah!! thats why on of the main things why i'm using it19:58
hazmatbodie_, also fwiw. i just pushed out at an etcd charm19:58
sebas5384juju with openstack using docker images is interesting too19:59
hazmatcs:~hazmat/trusty/etcd19:59
hazmatsebas5384, it is.. although it gets really wierd there.. a full os container makes more sense at that layer/level.19:59
hazmatie.. doing things like block volume attach from cinder doesn't map to docker..20:00
hazmatwhereas a full os container would have no issues with that20:00
hazmatsebas5384, the docker heat integration seems a bit better suited to single process app containers.20:00
sebas5384hazmat: didn't know about that docker x heat integration20:01
hazmathonestly.. i think lxc containers (full os) map better as nova compute instances... but i do like the image workflow and portability that docker brings to the table20:02
sebas5384hazmat: yeah, exactly20:02
hazmati'll be at dockercon in a few weeks if either of you are around20:03
hazmatthere's a new openstack working group on containers as well20:03
sebas5384now i'm thinking how i can do paas with juju(not just for deploying)20:03
hazmatsebas5384, so full enterprise paas.. we've got some cloudfoundry charms in the works (pretty early stages)20:04
sebas5384hazmat: nice! well i won't be there, but will be nice to have a hangout to discuss this kind o things :)20:04
hazmatbut it does basic app deploys into warden (cloud foundry's container impl ;-)20:05
hazmatsebas5384, sounds good.. jcastro would you be up for organizing something like that?20:06
hazmathangout on air style20:06
sebas5384nice hazmat taking a look at20:06
sebas5384maybe i was using juju for the wrong thing after all hehe20:06
sebas5384yeah! hazmat that would be great20:06
hazmatsebas5384, there are definitely folks that treat juju as a paas.. and that can work.. but there's a pretty good blog post on what paas should mean from the cf folks20:07
* hazmat digs20:07
hazmatsebas5384, http://blog.cloudfoundry.org/2013/10/24/essential-elements-of-an-enterprise-paas/20:07
sebas5384thanks hazmat, would be my reading for later :D20:08
sebas5384hazmat: Buildpack support and relation between each one20:08
sebas5384is what i'm concerned20:09
sebas5384because building an app with some custom configurations of the nginx service or php for example20:09
hazmatsebas5384, in twelve factor apps.. buildpack is generally independent of service usage. ie. relations  inject env /conf variables for the built app.20:14
hazmatre twelve factor app .. per heroku paas methodology though a bit more general than that .. http://12factor.net/20:15
* hazmat dives back into charm authoring20:16
sebas5384hazmat and bodie_ thanks! great talk, I'm going to think more about this20:17
sebas5384jcastro: please please can we schedule some hangout on air about this topic? i think is really interesting20:17
jcastrosebas5384, like an openended discussion about paas/docker/containers, etc?20:21
jcastrosure, I'll do it after the troubleshooting I and II and LXC debugging20:21
sebas5384jcastro: yeah! and how Juju can be used as PaaS or just as IaaS20:22
sebas5384great :)20:22
sebas5384because the fact that a drupal or wordpress charm exist, paas (not completely) can be achieved20:25
sebas5384with juju20:25
bodie_I think I would see juju more as the tool that the cluster admins / paas provider would use to deploy the services that would act as the PaaS, managing containers20:26
bodie_but I'm not sure I have all that straight in my head20:27
sebas5384yeah bodie_ i'm confuse now about that20:30
sebas5384because I have a startup implementing devops in the company, and in our clients20:30
sebas5384so, i have to choose very well the tools we are going to use20:31
sebas5384to automatize things20:31
=== vladk is now known as vladk|offline
sebas5384hey lazyPower http://awesomescreenshot.com/02e2unug3920:52
sebas5384hehe20:52
lazyPoweri'm everywhere20:53
sebas5384haha spooky20:54
=== CyberJacob is now known as CyberJacob|Away
=== CyberJacob|Away is now known as CyberJacob
=== CyberJacob is now known as CyberJacob|Away
=== CyberJacob|Away is now known as CyberJacob
josearosales: pong21:19
josearosales: sorry, was taking an exam :) what's up?21:19
arosalesjose: hi. I hope you exame went well.22:01
josekinda :P22:01
arosales:-)22:02
arosalesjose: wanted to thank you for all the work you are doing on improving quality in the charm store22:03
arosalesand also wanted to see if you would be interested in project that is very near and dear to me.22:03
josewell, what is it about?22:04
arosalesThe Great Charm Audit of 201422:04
arosaleshttps://lists.ubuntu.com/archives/juju/2013-December/003331.html22:04
arosalesits also become important as we try to move charms forward into trusty22:04
arosalesit would be solid to audit charms and also get them moved into Trusty during that audit22:05
arosalesThe thought is with amulet tests for each charm we can then test against Trusty and see if we can actually move it forward22:05
joseaudit is something I will try to work on, I think I have the checklist :)22:06
joseabout amulet tests... I'm not a python person, but I can write a basic deployment test, not sure how I would be able to handle service verification22:06
arosalesgood to hear you are intrested in the audit :-)22:11
arosalesjose: we could work with you to get ramped up on amulet. A lot of hte work would be looking at releations and config testing per charm22:12
josearosales: well, I'l be more than happy to help wherever I can, that's for sure22:13
arosalesjose: its a good opportunity to learn how different charms works and get some good merge proposals22:14
joseas well as learn some python in between!22:15
arosalesjose have you seen https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Aia4W3c4fbL-dGs4SVBJMGRIdnlSMWhzSmo3WE1mZ1E&usp=drive_web#gid=022:15
joseyeah, it's open in my browser22:15
josethere's *lots* to do in there22:15
arosalesah great, so that list is sorted with highest priority at the top22:16
arosalesanything that is of interest that is in yellow needs done :-)22:16
joseI think 'passes proof' is the easiest to get done :P22:16
hazmatjose, tests don't have to be amulet22:30
hazmatjose, its any executable just like hooks22:30
=== vorpalbunny is now known as thumper
=== CyberJacob is now known as CyberJacob|Away

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!