| === 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 | ||
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
| === mup_ is now known as mup | ||
| === zz_CyberJacob is now known as CyberJacob | ||
| === CyberJacob is now known as zz_CyberJacob | ||
| === zz_CyberJacob is now known as CyberJacob | ||
| === CyberJacob is now known as zz_CyberJacob | ||
| === psivaa is now known as psivaa-lunch | ||
| jcastro | marcoceppi: do you have a link to your openstack presentation video | 14:58 |
|---|---|---|
| marcoceppi | jcastro: https://www.openstack.org/summit/vancouver-2015/summit-videos/ and https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/repeatable-benchmarking-of-openstack-architectures | 14:58 |
| marcoceppi | jcastro: the rally charm also has status in it ;) | 15:08 |
| mbruzek | marcoceppi: Cool I am interested in that myself. | 15:12 |
| mbruzek | marcoceppi: Are the status messages not backward compatible? | 15:13 |
| mbruzek | What happens if you deploy the rally charm on juju 1.18 or something? | 15:13 |
| marcoceppi | mbruzek: they are not, but the charm-helpers implementation of status-set is backwards compat | 15:13 |
| marcoceppi | mbruzek: it fails | 15:13 |
| mbruzek | weaksauce, I *wish* we could specify a minimum version of Juju in a charm. | 15:13 |
| marcoceppi | mbruzek: I don't, I think that's silly | 15:14 |
| marcoceppi | well, the potential for abuse is there | 15:14 |
| mbruzek | It is better to have a charm fail because you try to use new featurs? | 15:14 |
| marcoceppi | CI should just tell us what versions of juju the charm works with | 15:14 |
| mbruzek | Users will not check ci before deploying | 15:15 |
| mbruzek | I disagree | 15:15 |
| marcoceppi | but the store can | 15:15 |
| mbruzek | Does the store do that *now*? | 15:15 |
| marcoceppi | a tighter feedback loop between CI and charmstore seems better than having effort working on min version stuff | 15:16 |
| marcoceppi | mbruzek: no, but we don't ahve min version either and if I had to decide which to work on, I think yhou know where I stand | 15:16 |
| mbruzek | You stand on benchmarking | 15:16 |
| marcoceppi | yes, but the more we can do for the user, the better | 15:17 |
| mbruzek | everything all the time | 15:17 |
| mbruzek | Understand we have priorities, and limits on the work that can be done, but as we get more customers, and more features landing in Juju charms that don't deploy on older versions of Juju will cause us pain and is a "bad user experience" | 15:18 |
| marcoceppi | mbruzek: I'd say the oinous is on the charm author | 15:24 |
| marcoceppi | I care about my charm and will so build in a way to make it backwards compat by using the python charm helpers library | 15:25 |
| * mbruzek checks the rally charm for a minimum version | 15:25 | |
| mbruzek | in the readme | 15:25 |
| marcoceppi | which will make sure that, when status_set is called, if the command doesn't exist it uses juju-log instead | 15:25 |
| marcoceppi | that way it's transparent | 15:25 |
| marcoceppi | the user can use the charm in any version of juju | 15:25 |
| marcoceppi | and it just degrades nicely | 15:25 |
| mbruzek | marcoceppi: I have no doubt you can write EXCELLENT charms, but the other authors will not know what features were new or not backward compatible | 15:26 |
| marcoceppi | mbruzek: well, if charm authors are using the charm-helpers library | 15:26 |
| marcoceppi | we only have to encode that quality once | 15:26 |
| marcoceppi | then everyone gets it | 15:26 |
| marcoceppi | your point alone on this | 15:26 |
| marcoceppi | if a charm author doesn't know what version of juju a feature is added | 15:27 |
| marcoceppi | how will they know what to set the min-version to? | 15:27 |
| marcoceppi | they don't and will just set it to the latest juju they're using | 15:27 |
| marcoceppi | which may not acurately be the min version of juju it works for | 15:27 |
| marcoceppi | which means that charm doesn't get delivered to users who could /potentially/ run it | 15:27 |
| mbruzek | I found recently that the trusty/haproxy charm is version locked at charmhelpers revision 70. I tried to sync charmhelpers and use the new functionality and found that it could not move beyond revision 70. When I removed this lock, I found that charmhelpers is on revision 300 something. | 15:27 |
| marcoceppi | mbruzek: that's an implementation detail, I have an email going to the list about charm-helpers being better packaged, versioned, and distributed | 15:28 |
| marcoceppi | but even still that's not /that/ bad | 15:28 |
| mbruzek | my point is if we give someone a way to make a mistake they might and then that would suck. | 15:28 |
| marcoceppi | so we need smarter systems, better CI and charm store integration, and a better review process | 15:28 |
| marcoceppi | so these mistakes get caught before they enter the store | 15:29 |
| marcoceppi | min version is simply a bandaid to a larger concern in the system | 15:29 |
| Tribaal | jamespage: I'm going to merge https://code.launchpad.net/~free.ekanayaka/charm-helpers/relation-set-file/+merge/260594 into charm-helpers. It will fix the python3 issue, and reintroduce the --file feature for set-relation | 15:33 |
| Tribaal | stub: ^^ FYI. This includes your fixes from this morning | 15:34 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| bleepbloop | Hello everyone, I am trying to deploy openstack using the openstack installer onto 15.04 in multi install mode, however juju seems to be having trouble bootstraping to 15.04, when the maas default series is set to trusty it works fine however vivid just hangs and then gets a connection timeout error with ssh | 15:50 |
| === scuttlemonkey is now known as scuttle|afk | ||
| bleepbloop | Ahh I think this may be causing it: https://bugs.launchpad.net/cloud-installer/+bug/1442308 seems that the openstack installer currently does not work on vivid | 16:15 |
| mup | Bug #1442308: Juju cannot create vivid containers <ci> <cloud-installer> <local-provider> <lxc> <ubuntu-engineering> <vivid> <cloud-installer:Confirmed> <juju-core:In Progress by cherylj> <juju-core 1.24:Fix Committed by cherylj> <https://launchpad.net/bugs/1442308> | 16:15 |
| cherylj | bleepbloop: yeah, there was a problem with creating containers with vivid | 16:17 |
| bleepbloop | Wait no that doesn't fully make sense since it is the initial bootstrapping of juju that is failing, unless install is fully broken on vivid | 16:18 |
| marcoceppi | bleepbloop: you need 1.23 to do vivid, not sure what version cloud-isntaller uses | 16:19 |
| bleepbloop | marcoceppi: I'm currently using 1.23.3-trusty-amd64 and it is failing, as soon as I set it to bootstrap trusty it gets past that error though | 16:20 |
| bleepbloop | When I run on trusty I get agent-version: 1.23.3 for the remote bootstrap version, so something else is going wrong there | 16:27 |
| cherylj | bleepbloop: are you able to try the bootstrap with --debug so we could look at the log? | 16:29 |
| bleepbloop | cherylj: sure, working on it | 16:32 |
| === kadams54 is now known as kadams54-away | ||
| === redelmann is now known as rudi|LuNcH | ||
| === rudi|LuNcH is now known as redelmann | ||
| === kadams54-away is now known as kadams54 | ||
| bleepbloop | cherylj: http://paste.ubuntu.com/11436902/ is the log, at that point it just hangs until it finally gets a connection timeout error | 18:11 |
| bleepbloop | cherylj: If I try connecting via the regular ssh command it just hangs as well and eventually times out | 18:12 |
| bleepbloop | cherylj: Also if I restart the machine it is bootstrapping to manually, it comes up just fine | 18:14 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| cherylj | bleepbloop: can you tell me if there is anything in /var/lib/juju/containers/ on the machine it is bootstrapping to? I'm not sure if using --to with maas will use a container or not. | 18:38 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| bleepbloop | cherylj: There is no containers directory there, it seems the issue is completely unrelated to containers unfortunately, I was wrong there | 19:07 |
| cherylj | bleepbloop: I'd suggest opening up a bug for it. | 19:07 |
| bleepbloop | cherylj: thanks, I've filed it https://bugs.launchpad.net/juju-core/+bug/1460184 | 19:18 |
| mup | Bug #1460184: Bootstrapping fails with Maas on Ubuntu Vivid <juju-core:New> <https://launchpad.net/bugs/1460184> | 19:18 |
| === kadams54 is now known as kadams54-away | ||
| === scuttle|afk is now known as scuttlemonkey | ||
| === zz_CyberJacob is now known as CyberJacob | ||
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!