/srv/irclogs.ubuntu.com/2015/10/26/#juju.txt

sh__hi team09:17
sh__i have a requirement where i have to change my charm name in the store , for example , form platform lsf to ibm platform lsf.I have changed my charm folder name ,metadata file09:18
sh__But still its not getting reflected in the store.My stream name is launchpad is : lp:~ibmcharmers/charms/trusty/platform-lsf/trunk ,I dont want to create a new stream with name as ibm-platform-lsf.Can i edit my existing stream , is there any option in launchpad ?09:20
sh__Can you please help me out here09:20
PrabuHello Tea,09:21
PrabuHello Team, I am testing my charm in amazon webservice and my charm is supported on Ubuntu Power PPC64LE machine.. while deploying my charm in AWS it is failing due to unspported platform.. Please advise how to change OS/Architecture in Amazon webservice.09:23
stubDoes anyone recall why the mock library is pinned in charmhelpers?10:43
stubHmm... despite pip installing old-mock into the venv, new mock is being imported from the system because it is newer10:48
=== cyberjacob is now known as zz_cyberjacob
=== test is now known as Guest15422
Iceyany updates on https://bugs.launchpad.net/juju-core/+bug/138527615:13
Icey?15:13
mupBug #1385276: juju leaves security groups behind in aws <destroy-environment> <ec2-provider> <repeatability> <security> <juju-core:Triaged> <https://launchpad.net/bugs/1385276>15:13
IceyI just hit my 100 Security Group limit in AWS with 0 instances deployed15:14
Iceyjuju has been destroyed in the environment15:14
=== zz_cyberjacob is now known as CyberJacob
=== JoshStrobl is now known as JoshStrobl|AFK
lazypowerIcey there's a script int he CI repo to cleanup your sec groups16:32
lazypower1 sec, i'll see if i can fish it up16:32
lazypowerIcey http://bazaar.launchpad.net/~juju-qa/juju-ci-tools/trunk/view/head:/clean_resources.py16:34
lazypowerwait thats probably not it...16:34
lazypowerdisregard... thats not the clean sec groups16:34
sh__Hi Team, I have a charm pushed into the store with name platform-lsf , I want to change it to ibm-platform-lsf.To do so , I have modified my charm name and metadata file.Can someone help me how I can edit my existing trunk branch.16:37
mgz_lazypower: CI really does have one though, lp:juju-ci-tools clean_resources.py depends on boto and an env that has your creds16:37
sh__Currently its : lp:~ibmcharmers/charms/trusty/platform-lsf/trunk ,I want to change it to trusty/ibm-platform-lsf16:37
Iceyit's not hard to do manually just annoying that it isn't handled when spinning / tearing down a lot16:37
Iceylazypower,16:38
nottrobinhello juju folks16:38
nottrobindoes anyone know if there's a way for me to get juju to tell me the currently deployed charm version for a service?16:39
mgz_cherylj, maybe add your new special tag to bug 1385276 for Icey?16:39
mupBug #1385276: juju leaves security groups behind in aws <destroy-environment> <ec2-provider> <repeatability> <security> <juju-core:Triaged> <https://launchpad.net/bugs/1385276>16:39
nottrobinI want to automatically run "juju upgrade-charm" only if there's a new version available16:39
mgz_nottrobin: status has that info, under service charm: and can-upgrade-to:16:40
cheryljmgz_: sure, I can add it16:41
mgz_sh__: you can just push --remember to the name you want16:42
mgz_sh__: or edit branch details in the web interface16:42
nottrobinmgz_: I don't see a "can-upgrade-to". "services -> {service-name} -> charm" says things like "local:trusty/haproxy-0" - but I don't know how to use that to tell which charm revision is deployed16:42
mgz_nottrobin: you need to deploy from the charmstore to have the nice upgrade bits16:43
nottrobinmgz_: hmm. We can't do that in production environments :(.16:44
sh__I pushed my charm name ie ibm-platform-lsf to my trunk branch lp:~ibmcharmers/charms/trusty/platform-lsf/trunk , but still its showing platform-lsf in charm store instead of ibm-platform-lsf16:46
mgz_sh__: right, you didn't actually rename the branch on lp16:46
sh__Also in web interface , not able to find an option to edit this branch name from /trusty/platform-lsf/trunk to /trusty/ibm-platform-lsf16:47
mgz_nottrobin: I don't see why not, no routing to the internet from prod I guess?16:47
sh__I dont want to create a new branch , just want to rename my existin lp branch , but in web ui ,not getting it to edit16:47
mgz_sh__: not on charms/+source/your_charm?16:50
mgz_that may need someone special16:51
mgz_but pushing up under a new name should just work.16:51
sh__when i go to my charms/trusty/platform-lsf/trunk branch ,i see edit option , its not listing me option to modify the charm name.16:52
mgz_yeah, the branch page lacks it as charms are a bit magic, like distro16:53
sh__Yes , i thought changing charm name and metadata file , i can see new name in store , but still reflecting old name16:53
nottrobinmgz_: I think we have access to launchpad, which is presumably all it needs for the charmstore, but the reason we download the charms locally and deploy from there is 'cos we hack them in place before deploying16:54
sh__then the only solution is to create new branch and tag my existing bug there ?But then i have to delete old lp branch16:54
sh__is there any other way out ?16:55
mgz_sh__: no, a rename should be possible, not sure who we need for it though16:56
sh__ok16:57
mgz_nottrobin: well, that doesn't sound ideal. would be nice to not hack things.17:01
=== jam2 is now known as jam1
lazypowermgz_ ah! ta.17:21
* lazypower was off at lunch17:21
lazypowerwwitzel3 ping17:28
lazypowerI'm talking with cory_fu about payload management, one question came up that I dont have an answer to17:28
lazypoweras the payload classes are not predefined, what is that field intended to represent?17:28
lazypowerI've been stuffing my own context at it, in terms of 'monitoring', 'servicebot', etc.17:29
lazypowerwhich are meaningful only to me, as someone looking @ the data that launched it and has some context as to what its purpose is.17:29
cory_fuMy reading of the spec makes me think that it was intended to indicate which service (docker, kvm, etc) is running the payload17:29
lazypowerright17:29
lazypowerthat to me is less interesting than the job its performing, so i may be using it incorrectly if there are future plans for that data field17:30
lazypoweri suppose tags would give me that as well17:30
wwitzel3the intention was for a classification of the payloads, which maybe of many types17:30
wwitzel3so the usage like servicebot or monitoring is the intended use17:31
nottrobinmgz_: so what could be the dangers of "juju upgrade-charm" ing too often?17:37
cory_fuwwitzel3: Is the payload-class just for informational purposes, or are we expecting the charm to use that info somehow?17:38
mgz_nottrobin: mostly just that we store full copies of each version17:39
mgz_so, that adds up for fat charms17:40
mgz_it used to be a git branch, which performed terribly with fat charms and binary blobs17:40
mgz_now it's stuffed in mongo17:40
mgz_which has better worst-case performance, but can mean a lot of storage used17:41
nottrobinmgz_: oh so it does literally store every version17:42
nottrobinhmm17:42
mgz_nottrobin: really you want to store some per charm, or per env for a mojo spec, metadata that holds the extra info your deployment needs to know about whether it needs upgrading17:42
wwitzel3cory_fu: informational17:42
nottrobinmgz_: except that it will hopefully be redundant quite soon :(17:43
wwitzel3cory_fu: purely to provide the operator context17:43
mgz_sure, but it's also a path towards the data you'll want anyway for resources17:43
nottrobinwell I'm thinking all I'd want to store is the "bzr revno" of the local charm before it's deployed17:45
nottrobinwhich will be unnecessary when we deploy from store, because juju will track it17:46
mgz_well, it depends if you also care about doing an update when you have a new blob that needs pickling into the charm17:46
mgz_but just taking the cs revno and stashing it for comparison is fine, there's not much to wrap up there and it would be easy too yank out later17:47
mgz_nottrobin: you could write a trivial seperate upgrade script,17:48
mgz_that takes a juju env name and mojo spec17:48
mgz_if the env has a magic var set, pull the rev info out of that, otherwise use the values from the spec17:49
PrabakaranHello Team, I am testing my charm in amazon webservice and my charm is supported on Ubuntu Power PPC64LE machine.. while deploying my charm in AWS it is failing due to unspported platform.. Please advise how to change OS/Architecture in Amazon webservice.17:49
mgz_and upgrade everything that has a newer version in the store17:49
mgz_Prabakaran: does aws actualyl have any ppc64el machines?17:53
mgz_presumably not, which is your problem17:54
lazypowerCorrect, afaik AWS is only x86 machines17:54
Prabakarani am new to AWS testing .. my charm is only supported on Ubuntu Power machine... is it possible for me to test my charm in AWS?17:54
lazypowerPrabakaran it is not at present.17:55
mbruzekPrabakaran: AWS does not have the power machine architecture17:55
mgz_well, maybe with manual deployment and a ppc64 guest on intel, if that works17:55
mgz_but that's not better than testing locally with a container17:56
mgz_I do not think any public clouds offer ppc6417:57
mgz_be17:57
mgz_best I've found is a link from debian, a br university has some machines you can request access to :)17:58
mbruzekPrabakaran: You could check into siteox they have a ppc64le cloud17:58
mgz_ah, forgot about that one17:59
mbruzekPrabakaran: You have access to a ppc64le local environment right?17:59
Prabakarancan u pls share debian link? so that i can explore and request for the same17:59
Prabakaranya i do have local environment access17:59
mbruzekPrabakaran: I would test that it works with x86 on amazon, and ppc64le on the local environment18:00
mbruzekThat should cover all the architectures18:00
mgz_Prabakaran: I was just reading wiki.debian.org/ppc64el - was hoping someone would have an openstack, so actually test the interfaces, but seems not18:01
Prabakaranmy charm is working perfectly in local ppcle machine.. but even though i wanted to test my charm in AWS cloud.. tat is y i was looking for the saame18:01
mbruzekPrabakaran: Understood, but the public clouds just don't have power architectures available18:02
PrabakaranI just wanted make sure my charm works not only in local.. anyway thank u all for ur support...lol18:03
bdxwhats going on everyone? I have a few questions regarding package imports in charm-helpers..... I was under the impression that charm-helpers modules shouldn't include other charm-helpers modules as dependencies....is this correct?18:11
bdxor should I say shouldn't import other charm-helpers modules so as they become dependent on them18:12
bdxI am primarily refering to http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/openstack/amulet/utils.py#L3418:12
bdxI went ahead and modified the charm-helpers-hooks.yaml in each charm that pins "contrib.openstack|inc=*" so that OpenStackAmuletUtils(AmuletUtils) would be able to inherit AmuletUtils.....this fixed the issues I was seeing, but I'm not sure if what I did goes against charm-helpers best practices or not.....18:15
bdx^^*modified each charm's charm-helpers-hooks.yaml to include contrib.amulet18:16
bdxFollowing^, I then synced charmhelpers to pull in contrib.amulet, push each to a personal branch and made a MR for each charm.....18:19
bdxI feel like I have errored in the sense that, well this issue should be delt with differently....possibly by moving OpenStackAmuletUtils(AmuletUtils) into amulet.utils.....errrrr :-/ ...???18:21
bdxcore, dev, charmers, openstack-charmers: ^^^^18:24
lazypowerbdx : i know that the OpenStack CharmHelpers are a bit of a different case as they live under contrib18:25
lazypowerthey're ovveriding behavior of the tooling to fit the openstack use case, which is why you see it implemented as such18:26
lazypowerthey don't necessarily fit directly into the core of charm-helpers, and moving forward there's a discussion thats lost steam on the list about breaking apart charm-helpers.contrib into their own python packages so they can have proper dependency declarations when pip installing18:26
bdxlazypower: great...so then pinning "contrib.amulet" in charm-helpers-hooks.yaml is the correct path to remedy issue?18:29
bdxcorrect modifcation*18:30
bdxlazypower:^?18:36
lazypowerI suppose18:36
lazypowerI would follow up with a post to the list asking the ~openstack-charmers if thats their recommended fix18:37
lazypowerbut if it works, it sounds reasonable.18:37
lazypowerbdx sorry i'm a bit split brain today, really focused on resolving some k8's issues18:37
bdxlazypower: no worries, thanks for responding!18:38
Odd_BlokeSo I'm trying to deploy a simple Jenkins setup (one jenkins and one jenkins-slave) to GCE.18:51
Odd_BlokeAnd I'm hitting an error where the master can't contact the slave on port 8080.18:51
Odd_BlokeI'm guessing that this is because port 8080 isn't open by default.18:51
Odd_BlokeDo I have to go in manually to fix this, or am I missing some juju magic that could handle it for me?18:52
lazypowerOdd_Bloke i hope its not reading public address, you can try 'juju expose' on the slave, and juju resolved -r that unit in error18:52
lazypowerif it works, the relation is coded to listen / consume a network that may be firewalled by default18:53
lazypowerbut thats difficult to say without looking @ the charm source18:53
lazypowerOdd_Bloke link to the slave?18:53
Odd_Blokelazypower: Oh, no, I have misdiagnosed this problem.18:54
Odd_Blokelazypower: It looks like the charm tries to connect to the master using HTTP.18:55
Odd_BlokeAnd Jenkins has segfault'd. /o\18:55
lazypowersurprise!18:55
Odd_BlokeI'm guessing I need to add a memory constraint.18:55
bdxthedac: possibly you are not seeing it23:01
bdxthedac: return OPENSTACK_CODENAMES[vers]23:01
bdxthedac: and vers = '12.0.0'23:02
bdx....23:02
bdxit would need to be return PACKAGE_CODENAMES[package][vers]23:03
bdxI modified the MR to reflect that23:03
thedacbdx: I'll take another look23:04
thedacbdx: same issue we are looking at two different kinds of version strings. See for example http://pastebin.ubuntu.com/12975192/23:11
thedacIf we get paste the else in line 249 we are looking for version strings like 2015.2 not 12.0.0 and therefore use OPENSTACK_CODENAMES[vers]23:12
thedacs/paste/past23:12
bdxthedac: yeah, but vers = '12.0.0'23:16
bdxso OPENSTACK_CODENAMES[vers]23:16
bdxis not cool man23:16
thedacbdx: see my last comment on the bug. If the version is 12.0.0 we will not get to that code23:17
thedacThat code is for version strings of the form year.point_release23:17
thedacand if we do ... then the exeption is correct23:19
bdxthedac: Oooooh ...the only reason I was hitting that and vers = '12.0.0' is because 'nova-compute' is not in PACKAGE_CODENAMES23:21
thedacbingo23:21
bdxthedac: I see. Nice. Soo the only way that can happen is if a package gets passed in that is not in PACKAGE_CODENAMES23:22
thedacright. Which you fixed with your nova-compute MP.23:22
bdxtotally23:23
bdxmakes total sense now.....I was negleting to realize the only way vers == '12.0.0' is when package not in PACKAGE_CODENAMES is passed in. Thanks for hammering that out with me.23:25
thedacno problem23:25

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