| sh__ | hi team | 09: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 file | 09: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 here | 09:20 |
| Prabu | Hello Tea, | 09:21 |
| Prabu | Hello 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 |
| stub | Does anyone recall why the mock library is pinned in charmhelpers? | 10:43 |
| stub | Hmm... despite pip installing old-mock into the venv, new mock is being imported from the system because it is newer | 10:48 |
| === cyberjacob is now known as zz_cyberjacob | ||
| === test is now known as Guest15422 | ||
| Icey | any updates on https://bugs.launchpad.net/juju-core/+bug/1385276 | 15:13 |
| Icey | ? | 15:13 |
| mup | Bug #1385276: juju leaves security groups behind in aws <destroy-environment> <ec2-provider> <repeatability> <security> <juju-core:Triaged> <https://launchpad.net/bugs/1385276> | 15:13 |
| Icey | I just hit my 100 Security Group limit in AWS with 0 instances deployed | 15:14 |
| Icey | juju has been destroyed in the environment | 15:14 |
| === zz_cyberjacob is now known as CyberJacob | ||
| === JoshStrobl is now known as JoshStrobl|AFK | ||
| lazypower | Icey there's a script int he CI repo to cleanup your sec groups | 16:32 |
| lazypower | 1 sec, i'll see if i can fish it up | 16:32 |
| lazypower | Icey http://bazaar.launchpad.net/~juju-qa/juju-ci-tools/trunk/view/head:/clean_resources.py | 16:34 |
| lazypower | wait thats probably not it... | 16:34 |
| lazypower | disregard... thats not the clean sec groups | 16: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 creds | 16:37 |
| sh__ | Currently its : lp:~ibmcharmers/charms/trusty/platform-lsf/trunk ,I want to change it to trusty/ibm-platform-lsf | 16:37 |
| Icey | it's not hard to do manually just annoying that it isn't handled when spinning / tearing down a lot | 16:37 |
| Icey | lazypower, | 16:38 |
| nottrobin | hello juju folks | 16:38 |
| nottrobin | does 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 |
| mup | Bug #1385276: juju leaves security groups behind in aws <destroy-environment> <ec2-provider> <repeatability> <security> <juju-core:Triaged> <https://launchpad.net/bugs/1385276> | 16:39 |
| nottrobin | I want to automatically run "juju upgrade-charm" only if there's a new version available | 16:39 |
| mgz_ | nottrobin: status has that info, under service charm: and can-upgrade-to: | 16:40 |
| cherylj | mgz_: sure, I can add it | 16:41 |
| mgz_ | sh__: you can just push --remember to the name you want | 16:42 |
| mgz_ | sh__: or edit branch details in the web interface | 16:42 |
| nottrobin | mgz_: 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 deployed | 16:42 |
| mgz_ | nottrobin: you need to deploy from the charmstore to have the nice upgrade bits | 16:43 |
| nottrobin | mgz_: 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-lsf | 16:46 |
| mgz_ | sh__: right, you didn't actually rename the branch on lp | 16: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-lsf | 16: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 edit | 16:47 |
| mgz_ | sh__: not on charms/+source/your_charm? | 16:50 |
| mgz_ | that may need someone special | 16: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 distro | 16:53 |
| sh__ | Yes , i thought changing charm name and metadata file , i can see new name in store , but still reflecting old name | 16:53 |
| nottrobin | mgz_: 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 deploying | 16: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 branch | 16: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 though | 16:56 |
| sh__ | ok | 16:57 |
| mgz_ | nottrobin: well, that doesn't sound ideal. would be nice to not hack things. | 17:01 |
| === jam2 is now known as jam1 | ||
| lazypower | mgz_ ah! ta. | 17:21 |
| * lazypower was off at lunch | 17:21 | |
| lazypower | wwitzel3 ping | 17:28 |
| lazypower | I'm talking with cory_fu about payload management, one question came up that I dont have an answer to | 17:28 |
| lazypower | as the payload classes are not predefined, what is that field intended to represent? | 17:28 |
| lazypower | I've been stuffing my own context at it, in terms of 'monitoring', 'servicebot', etc. | 17:29 |
| lazypower | which 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_fu | My reading of the spec makes me think that it was intended to indicate which service (docker, kvm, etc) is running the payload | 17:29 |
| lazypower | right | 17:29 |
| lazypower | that 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 field | 17:30 |
| lazypower | i suppose tags would give me that as well | 17:30 |
| wwitzel3 | the intention was for a classification of the payloads, which maybe of many types | 17:30 |
| wwitzel3 | so the usage like servicebot or monitoring is the intended use | 17:31 |
| nottrobin | mgz_: so what could be the dangers of "juju upgrade-charm" ing too often? | 17:37 |
| cory_fu | wwitzel3: 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 version | 17:39 |
| mgz_ | so, that adds up for fat charms | 17:40 |
| mgz_ | it used to be a git branch, which performed terribly with fat charms and binary blobs | 17:40 |
| mgz_ | now it's stuffed in mongo | 17:40 |
| mgz_ | which has better worst-case performance, but can mean a lot of storage used | 17:41 |
| nottrobin | mgz_: oh so it does literally store every version | 17:42 |
| nottrobin | hmm | 17: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 upgrading | 17:42 |
| wwitzel3 | cory_fu: informational | 17:42 |
| nottrobin | mgz_: except that it will hopefully be redundant quite soon :( | 17:43 |
| wwitzel3 | cory_fu: purely to provide the operator context | 17:43 |
| mgz_ | sure, but it's also a path towards the data you'll want anyway for resources | 17:43 |
| nottrobin | well I'm thinking all I'd want to store is the "bzr revno" of the local charm before it's deployed | 17:45 |
| nottrobin | which will be unnecessary when we deploy from store, because juju will track it | 17:46 |
| mgz_ | well, it depends if you also care about doing an update when you have a new blob that needs pickling into the charm | 17: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 later | 17:47 |
| mgz_ | nottrobin: you could write a trivial seperate upgrade script, | 17:48 |
| mgz_ | that takes a juju env name and mojo spec | 17:48 |
| mgz_ | if the env has a magic var set, pull the rev info out of that, otherwise use the values from the spec | 17:49 |
| Prabakaran | Hello 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 store | 17:49 |
| mgz_ | Prabakaran: does aws actualyl have any ppc64el machines? | 17:53 |
| mgz_ | presumably not, which is your problem | 17:54 |
| lazypower | Correct, afaik AWS is only x86 machines | 17:54 |
| Prabakaran | i 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 |
| lazypower | Prabakaran it is not at present. | 17:55 |
| mbruzek | Prabakaran: AWS does not have the power machine architecture | 17:55 |
| mgz_ | well, maybe with manual deployment and a ppc64 guest on intel, if that works | 17:55 |
| mgz_ | but that's not better than testing locally with a container | 17:56 |
| mgz_ | I do not think any public clouds offer ppc64 | 17:57 |
| mgz_ | be | 17:57 |
| mgz_ | best I've found is a link from debian, a br university has some machines you can request access to :) | 17:58 |
| mbruzek | Prabakaran: You could check into siteox they have a ppc64le cloud | 17:58 |
| mgz_ | ah, forgot about that one | 17:59 |
| mbruzek | Prabakaran: You have access to a ppc64le local environment right? | 17:59 |
| Prabakaran | can u pls share debian link? so that i can explore and request for the same | 17:59 |
| Prabakaran | ya i do have local environment access | 17:59 |
| mbruzek | Prabakaran: I would test that it works with x86 on amazon, and ppc64le on the local environment | 18:00 |
| mbruzek | That should cover all the architectures | 18: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 not | 18:01 |
| Prabakaran | my 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 saame | 18:01 |
| mbruzek | Prabakaran: Understood, but the public clouds just don't have power architectures available | 18:02 |
| Prabakaran | I just wanted make sure my charm works not only in local.. anyway thank u all for ur support...lol | 18:03 |
| bdx | whats 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 |
| bdx | or should I say shouldn't import other charm-helpers modules so as they become dependent on them | 18:12 |
| bdx | I am primarily refering to http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/openstack/amulet/utils.py#L34 | 18:12 |
| bdx | I 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.amulet | 18:16 |
| bdx | Following^, I then synced charmhelpers to pull in contrib.amulet, push each to a personal branch and made a MR for each charm..... | 18:19 |
| bdx | I 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 |
| bdx | core, dev, charmers, openstack-charmers: ^^^^ | 18:24 |
| lazypower | bdx : i know that the OpenStack CharmHelpers are a bit of a different case as they live under contrib | 18:25 |
| lazypower | they're ovveriding behavior of the tooling to fit the openstack use case, which is why you see it implemented as such | 18:26 |
| lazypower | they 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 installing | 18:26 |
| bdx | lazypower: great...so then pinning "contrib.amulet" in charm-helpers-hooks.yaml is the correct path to remedy issue? | 18:29 |
| bdx | correct modifcation* | 18:30 |
| bdx | lazypower:^? | 18:36 |
| lazypower | I suppose | 18:36 |
| lazypower | I would follow up with a post to the list asking the ~openstack-charmers if thats their recommended fix | 18:37 |
| lazypower | but if it works, it sounds reasonable. | 18:37 |
| lazypower | bdx sorry i'm a bit split brain today, really focused on resolving some k8's issues | 18:37 |
| bdx | lazypower: no worries, thanks for responding! | 18:38 |
| Odd_Bloke | So I'm trying to deploy a simple Jenkins setup (one jenkins and one jenkins-slave) to GCE. | 18:51 |
| Odd_Bloke | And I'm hitting an error where the master can't contact the slave on port 8080. | 18:51 |
| Odd_Bloke | I'm guessing that this is because port 8080 isn't open by default. | 18:51 |
| Odd_Bloke | Do I have to go in manually to fix this, or am I missing some juju magic that could handle it for me? | 18:52 |
| lazypower | Odd_Bloke i hope its not reading public address, you can try 'juju expose' on the slave, and juju resolved -r that unit in error | 18:52 |
| lazypower | if it works, the relation is coded to listen / consume a network that may be firewalled by default | 18:53 |
| lazypower | but thats difficult to say without looking @ the charm source | 18:53 |
| lazypower | Odd_Bloke link to the slave? | 18:53 |
| Odd_Bloke | lazypower: Oh, no, I have misdiagnosed this problem. | 18:54 |
| Odd_Bloke | lazypower: It looks like the charm tries to connect to the master using HTTP. | 18:55 |
| Odd_Bloke | And Jenkins has segfault'd. /o\ | 18:55 |
| lazypower | surprise! | 18:55 |
| Odd_Bloke | I'm guessing I need to add a memory constraint. | 18:55 |
| bdx | thedac: possibly you are not seeing it | 23:01 |
| bdx | thedac: return OPENSTACK_CODENAMES[vers] | 23:01 |
| bdx | thedac: and vers = '12.0.0' | 23:02 |
| bdx | .... | 23:02 |
| bdx | it would need to be return PACKAGE_CODENAMES[package][vers] | 23:03 |
| bdx | I modified the MR to reflect that | 23:03 |
| thedac | bdx: I'll take another look | 23:04 |
| thedac | bdx: same issue we are looking at two different kinds of version strings. See for example http://pastebin.ubuntu.com/12975192/ | 23:11 |
| thedac | If 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 |
| thedac | s/paste/past | 23:12 |
| bdx | thedac: yeah, but vers = '12.0.0' | 23:16 |
| bdx | so OPENSTACK_CODENAMES[vers] | 23:16 |
| bdx | is not cool man | 23:16 |
| thedac | bdx: see my last comment on the bug. If the version is 12.0.0 we will not get to that code | 23:17 |
| thedac | That code is for version strings of the form year.point_release | 23:17 |
| thedac | and if we do ... then the exeption is correct | 23:19 |
| bdx | thedac: Oooooh ...the only reason I was hitting that and vers = '12.0.0' is because 'nova-compute' is not in PACKAGE_CODENAMES | 23:21 |
| thedac | bingo | 23:21 |
| bdx | thedac: I see. Nice. Soo the only way that can happen is if a package gets passed in that is not in PACKAGE_CODENAMES | 23:22 |
| thedac | right. Which you fixed with your nova-compute MP. | 23:22 |
| bdx | totally | 23:23 |
| bdx | makes 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 |
| thedac | no problem | 23:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!