| jrandall | I'm hoping someone here might be able to help with a failed `juju upgrade-juju` - I ran it a few hours ago to upgrade from 1.21.1 to 1.22.0, but it failed and now my agent is stuck in an error state | 01:15 |
|---|---|---|
| jrandall | (I also emailed juju@lists.ubuntu.com, but thought I'd try here as well) | 01:16 |
| === jrandall_ is now known as jrandall | ||
| === jrandall is now known as joshulux | ||
| === kadams54 is now known as kadams54-away | ||
| === axw_ is now known as axw | ||
| apuimedo | lazyPower: ping | 06:31 |
| lazyPower | apuimedo: o/ pong | 06:31 |
| apuimedo | lazyPower: what kind of timezone are you in? | 06:32 |
| lazyPower | EDT - but you're on my watch list so i get pings sent to my mobile. | 06:32 |
| lazyPower | Whats up? | 06:33 |
| apuimedo | omg, I'm so sorry about that. ping me when you get up in the morning | 06:33 |
| apuimedo | it's just to discuss about the review you sent me ;-) | 06:33 |
| lazyPower | No worries mate | 06:33 |
| lazyPower | I'll be around in ~ 5 or 6 hours. | 06:33 |
| apuimedo | very well :-) | 06:34 |
| apuimedo | Enjoy some rest | 06:34 |
| mwak | hi | 08:13 |
| === CyberJacob is now known as zz_CyberJacob | ||
| === benonsoftware is now known as clockwork | ||
| === clockwork is now known as benonsoftware | ||
| vila | I can't 'juju status' anymore on a local deployment I made last week-end | 12:55 |
| vila | vivid/1.22.0-0ubuntu1 (hmm, upgraded from 1.20 this morning... can this be related ?) | 12:56 |
| vila | juju status just hangs | 12:56 |
| vila | what can I do to get some better diagnosis ? | 12:56 |
| vila | ha | 13:04 |
| vila | after a long timeout (~10mins given my previous msg ;) juju status dies with: WARNING discarding API open error: unable to connect to "wss://localhost:17070/environment/65ccd21a-868f-42fe-85b2-72084fb6ceb9/api" | 13:05 |
| vila | some question remains though: how do I debug this further ? | 13:05 |
| schkovich | vila: do you have a firewall enabled on juju state server? | 13:47 |
| lazyPower | apuimedo: pong ) | 13:48 |
| lazyPower | :) | 13:49 |
| vila | schkovich: nope, no firewall | 13:49 |
| vila | but I was finally able to boot vivid with systemd instead of upstart and I wonder if that may explain it... | 13:49 |
| lazyPower | vila: systemd wasn't supported until 1.23 - here's a mailing list post on it | 13:50 |
| lazyPower | https://lists.ubuntu.com/archives/juju/2015-March/005072.html | 13:50 |
| vila | finally == I got a fix this morning so I could stop booting with upstart instead of the default systemd | 13:50 |
| lazyPower | if you're working with 1.22 - it makes sense that you're running into issues, really sorry about that. | 13:50 |
| vila | lazyPower: that's expected when running a dev release isn't it ;-) Thanks for confirming, I already feels much better ! | 13:51 |
| lazyPower | well 1.23 is the dev release currently :) | 13:52 |
| vila | lazyPower: yeah, was referring to vivid but same idea ;) | 13:52 |
| lazyPower | oh! | 13:52 |
| lazyPower | good call :D | 13:53 |
| vila | lazyPower: I was forced to use upstart until today and I didn't realize this could have an impact on juju until I tried 'juju status' ;) | 13:53 |
| vila | but my juju deployed lxc container did start and works properly | 13:54 |
| vila | lazyPower: so, I'd like to keep running vivid/systemd, I can re-create my local deployment if needed, will I be able to do that with juju 1.23 knowing that I want to deploy on trusty and precise lxc containers ? | 13:56 |
| vila | (and I'd prefer to switch back to stable juju asap but that can wait a bit if needed ;) | 13:57 |
| lazyPower | vila: yeah, 1.23 should be fine for you to use in dev. I'm using it daily here and its been pretty stable but i'm also on trusty | 13:59 |
| lazyPower | so ymmv - but i know that 1.23 in vivid is better supported than 1.22 - and you get the added benefit of the new features enabled by default like juju actions | 13:59 |
| lazyPower | upgrading from 1.23 when it lands as stable should be no trouble as well, just juju upgrade-juju | 14:00 |
| vila | lazyPower: ack, thanks | 14:00 |
| === scuttle|afk is now known as scuttlemonkey | ||
| lfforman | good morning | 16:29 |
| lfforman | i am new to juju, and i am trying to add an existing DigitalOcean machine to my juju environment, with the add-machine command. my issue is that the ssh port to this server is not the standard port 22, where do I state the ssh port I want to use? | 16:31 |
| lazyPower | lfforman: great question, let me spin up a DO environment and inspect | 16:32 |
| lazyPower | 1 moment | 16:32 |
| lfforman | ok, thanks | 16:32 |
| lazyPower | lfforman: this is taking a moment, it appears my node(s) are getting hung up in provisioning on DO | 16:45 |
| lazyPower | sorry about the delay | 16:45 |
| lfforman | ok | 16:54 |
| lfforman | lazyPower: I had to get off my computer for a minute i am back | 16:55 |
| lazyPower | ok, i'm reconfiguring the node to accept ssh on a non standard port atm | 16:55 |
| lazyPower | finally got my machines out of pending in the DO gui | 16:55 |
| lfforman | ok | 16:56 |
| lazyPower | it was strange, it doesn't normally give me fits like this :) it must know i'm up to no good | 16:56 |
| lfforman | :D | 16:56 |
| lazyPower | lfforman: i'm not seeing a clear path forward to do this addition,t he command simply errors out with positional arguments :| | 17:02 |
| lazyPower | http://paste.ubuntu.com/10774659/ is what i'm seeing | 17:02 |
| lfforman | this is the same result i’ve got | 17:04 |
| lazyPower | lfforman: https://bugs.launchpad.net/juju-core/+bug/1441749 | 17:06 |
| mup | Bug #1441749: Add-Machine does not support non-standard ssh port <juju-core:New> <https://launchpad.net/bugs/1441749> | 17:06 |
| lfforman | i am going to have lunch, thank you for the help | 17:06 |
| lazyPower | you may want to mark that bug as affects you so you can follow along with any new developments. | 17:06 |
| lfforman | ok | 17:06 |
| lazyPower | sorry about not having good news, cheers mate | 17:07 |
| === scuttlemonkey is now known as scuttle|afk | ||
| === bladernr` is now known as bladernr_ | ||
| === zz_CyberJacob is now known as CyberJacob | ||
| === kadams54_ is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54_ | ||
| === FunnyLookinHat_ is now known as FunnyLookinHat | ||
| === kadams54_ is now known as kadams54-away | ||
| apuimedo | lazyPower: hi. I hope it's not too late | 20:44 |
| lazyPower | o/ apuimedo nope not too late. | 20:47 |
| apuimedo | good! | 20:47 |
| apuimedo | lazyPower: I fixed the markdown | 20:49 |
| apuimedo | moved the .venvs to each charm | 20:49 |
| lazyPower | yeah :| sorry about that - but you'll thank me when we get this in CI | 20:49 |
| lazyPower | having the .venv in ../ was going to cause problems | 20:50 |
| apuimedo | lazyPower: I'm still wondering about if I should just give up and have it all in bazaar | 20:50 |
| lazyPower | you can still track upstream and vendor into bzr | 20:50 |
| lazyPower | i wrote a tool fo rthis | 20:50 |
| lazyPower | https://github.com/chuckbutler/git-vendor | 20:50 |
| apuimedo | lazyPower: that would come in handy :P | 20:50 |
| apuimedo | thanks! | 20:51 |
| apuimedo | The icons I'll handle next week | 20:51 |
| lazyPower | its relatively new, so if you encounter any bugs with git-vendor bugs are welcome :) | 20:51 |
| apuimedo | lazyPower: I wish I had time | 20:51 |
| lazyPower | the changelog support is pending, but tag exports are working well, I've been using it on the docker/kubernetes charms | 20:51 |
| apuimedo | I'd write a guide on the service framework too | 20:51 |
| apuimedo | after having read the code | 20:52 |
| apuimedo | to find the small things | 20:52 |
| lazyPower | new stuff for that as well - the services framework has some backwords incompatible changes coming that cory_fu will be sending out as soon as the docs are sorted | 20:52 |
| apuimedo | heh | 20:53 |
| lazyPower | :S | 20:53 |
| apuimedo | that sounds like it's going to keep me busy | 20:53 |
| lazyPower | are you installing charmehlpers from pip? | 20:53 |
| apuimedo | nope | 20:53 |
| cory_fu | The changes are not that significant, really | 20:53 |
| lazyPower | if you're following the embedded pattern no change is required. | 20:53 |
| apuimedo | I gave up on that | 20:53 |
| apuimedo | I failed two deployments due to some breaking commit | 20:53 |
| lazyPower | ouch | 20:54 |
| cory_fu | The docs for the new version are available here, for comparison, if you want a heads-up: http://big-data-charm-helpers.readthedocs.org/en/latest/ | 20:54 |
| apuimedo | well, a change will be required the next time I want to rebase ;-) | 20:54 |
| apuimedo | which I'd like to be in the same 6 months cycle as openstack | 20:54 |
| apuimedo | lazypower: about the purpose of the midonet-repository interface | 20:55 |
| lazyPower | ah yes, do tell | 20:55 |
| apuimedo | it's a configuration provider charm | 20:55 |
| apuimedo | basically, the charms that relate to it | 20:55 |
| lazyPower | ok, so its essentially an orchestrator for the services, and covers all the charms shared config? | 20:55 |
| apuimedo | get the repository and release information | 20:55 |
| cory_fu | Here's a side-by-side comparison of the changes: http://i.imgur.com/lR9Z60W.png I'm hopeful it won't be too onerous | 20:56 |
| apuimedo | so that they can render that information as part of their puppet hiera.yaml | 20:56 |
| apuimedo | lazyPower: only the repo info for now | 20:56 |
| apuimedo | no more shared things | 20:56 |
| apuimedo | it saves you from having many subordinate deploying going around | 20:56 |
| lazyPower | i understand why you chose that pattern, makes sense to me | 20:57 |
| apuimedo | and the rendering is common | 20:57 |
| apuimedo | so it's not really code duplication, it's similar to charm-helpers embedding | 20:57 |
| lazyPower | i still have 3 of the midonet charms to look at, but everything i saw in the first three was extremely good - just some minor nit cleanups for the store really. | 20:57 |
| apuimedo | only that instead of pulling, I push from my git repo into the charms | 20:57 |
| lazyPower | have you built a bundle for the midonet stack? | 20:57 |
| apuimedo | lazyPower: thanks ;-) | 20:57 |
| apuimedo | lazyPower: I'm doing so now | 20:58 |
| apuimedo | this week | 20:58 |
| lazyPower | bundle + tests will = quick win during final review | 20:58 |
| apuimedo | I'm basing it off the openstack bundle | 20:58 |
| lazyPower | perfect | 20:58 |
| apuimedo | still fighting some minor issues in some hooks though | 20:58 |
| lazyPower | thats exactly what I was looking for - to see if you were going to consume the existing openstack bundle, and bolt onto it | 20:58 |
| apuimedo | yes, something like that | 20:59 |
| lazyPower | https://jujucharms.com/openstack/ <-- this will become a topic page in the next week or so when the UI Engineering team finishes the release | 20:59 |
| lazyPower | but i think this is a good place to get started anyway :) | 20:59 |
| apuimedo | one thing I wanted to ask. To submit my change to charm-helpers and neutron-api I did it in the next branches | 20:59 |
| apuimedo | so that it would be upstreamed | 20:59 |
| lazyPower | yep, thats the process - submit against next, the charmhelpers guardians review + release. | 20:59 |
| apuimedo | but for deployment in production, how crazy is it to deploy that neutron-api? | 21:00 |
| apuimedo | (my changes over next) | 21:00 |
| lazyPower | neutron is always the troublemaker for me | 21:00 |
| apuimedo | lazyPower: s/me/everybody/ | 21:00 |
| apuimedo | :P | 21:00 |
| lazyPower | ^ that | 21:00 |
| apuimedo | cory_fu: thanks for the comparison | 21:00 |
| cory_fu | np. I didn't want you getting scared from what lazyPower said. :p | 21:01 |
| lazyPower | :D its not untrue | 21:02 |
| apuimedo | so I think I'll backport the changes to neutron-api for current production | 21:02 |
| lazyPower | just call me lazy, master of FUD | 21:02 |
| apuimedo | Fun Understanding and Discipline? | 21:03 |
| apuimedo | cory_fu: have you considered having the services framework be provided by the agent? | 21:07 |
| apuimedo | in a juju namespace | 21:07 |
| apuimedo | from juju.helpers import services | 21:07 |
| cory_fu | We hadn't, really, no. Seems like the same could be suggested of most of the things in charmhelpers | 21:09 |
| apuimedo | cory_fu: I think it would make quite a bit of sense | 21:10 |
| apuimedo | things like hookenv and such | 21:10 |
| apuimedo | bundled with agent releases | 21:10 |
| apuimedo | on the same cycle | 21:10 |
| cory_fu | I don't really disagree. | 21:10 |
| apuimedo | well, that's almost an agreement :P | 21:11 |
| blr | cory_fu: how's the service framework refactor going? | 21:12 |
| cory_fu | I think the main argument against is that Juju is intended to be as language agnostic as possible. So, bundling specific language bindings with the agent, and more so single language only features like the framework, go against that | 21:13 |
| cory_fu | (Though, I'd also like to work toward making the patterns, at least, of the framework more language agnostic, as well) | 21:13 |
| cory_fu | blr: Really well. I think it's just about ready to MP against upstream. I linked a preview of the docs for the new version above (http://big-data-charm-helpers.readthedocs.org/) as well as a side-by-side comparison image that I'm going to include in my upgrade path doc (http://i.imgur.com/lR9Z60W.png) | 21:15 |
| blr | cory_fu: neat, will have a look. | 21:15 |
| blr | cory_fu: looks good, 'requires', 'callback' and 'cleanup' are clearer. | 21:21 |
| blr | cory_fu: partial is new presumably? | 21:22 |
| blr | oh that's from functools, nvm :) | 21:22 |
| cory_fu | partial is built-in, part of functools | 21:22 |
| cory_fu | :) | 21:22 |
| === kadams54-away is now known as kadams54_ | ||
| blr | cory_fu: are you working on systemd support yet? | 21:26 |
| lazyPower | apuimedo: the takeaway is you're almost ready for teh final review? like in the mid to late 90% range? | 21:27 |
| cory_fu | Nope, but I think that would just involve a change to host.service_* | 21:27 |
| blr | cory_fu: will that release break the api? By the looks of it, upgrading our charms should be quite easy however. | 21:30 |
| cory_fu | The new version of the framework will definitely not be entirely backwards compatible, but, as you said, I don't expect the changes required to be too bad. If deemed necessary, we could possibly even come up with a compatibility layer to ease the transition, but I'm reluctant to do that unless really necessary. | 21:32 |
| blr | cory_fu: ok, will convey that to ci, they've been using the services framework too. | 21:33 |
| cory_fu | Thanks. Do let me know if a compat layer is something that we should look into | 21:34 |
| blr | our charms are reasonably simple, but I can't speak for others. | 21:34 |
| apuimedo | lazyPower: :-) | 21:35 |
| apuimedo | I'll be as soon as my bundle works | 21:35 |
| apuimedo | I'd say 90% | 21:36 |
| apuimedo | probably | 21:36 |
| apuimedo | lazyPower: not for the amulet part, unfortunately | 21:36 |
| apuimedo | so the 90% is over-optimistic because of that | 21:36 |
| lazyPower | Would it be helpful if we sta down and had a quick hour long charm school over amulet tests? | 21:37 |
| lazyPower | we can riff and start writing tests while pairing | 21:37 |
| apuimedo | lazyPower: that sounds really good for next week. I'll talk with my team tomorrow morning CEST and I'll shoot you an email ;-) | 21:39 |
| lazyPower | Sound good, i know for sure theres no way i can do it on Monday - but later on next week it shouldn't be an issue | 21:39 |
| apuimedo | ;-) | 21:39 |
| cory_fu | Alright, I have to head out. Got to finish packing to head to Germany tomorrow. :) | 21:45 |
| apuimedo | cory_fu: have a nice trip | 21:46 |
| === kadams54_ is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54_ | ||
| === kadams54_ is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54_ | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
