/srv/irclogs.ubuntu.com/2016/05/18/#juju.txt

marcoceppimagicaltrout: yeah, apt get install charm-tools; then you can do `charm create` (sans the -) ;)00:08
=== freeflying__ is now known as freeflying
=== JoseeAntonioR is now known as jose
=== tris- is now known as tris
=== hazmat_ is now known as hazmat
jamespagedosaboy, can you cast your eye over https://code.launchpad.net/~james-page/charm-helpers/fixup-service-running/+merge/29494208:29
dosaboyjamespage: sure08:40
jamespagedosaboy, ta - I was looking for the testing that beisner did yesterday - but he must of done it offline I think08:40
dosaboyjamespage: i just realised that since your fix for 1580320 is ceph-osd only and some amulet tests use ceph for osds it won't apply so tests will still fail08:42
dosaboyso i have a tmp workaround08:42
jamespagedosaboy, I can apply to ceph as well08:43
dosaboyjamespage: that would be the easy fix ;)08:43
dosaboyor we could get teh amulet tests using ceph-mon+ceph-osd08:43
dosaboybut that means more resources for each test08:43
dosaboytest run that is08:43
dosaboyjamespage: i'm working around it with https://review.openstack.org/#/c/314063/10..11/tests/basic_deployment.py for now08:44
=== Zetas_ is now known as Zetas
=== rohit___ is now known as rohit__
=== bodie__ is now known as bodie_
=== thomi_ is now known as thomi
=== cargonza_ is now known as cargonza
=== plars_ is now known as plars
=== xnox_ is now known as xnox
jamespagedosaboy, https://review.openstack.org/#/c/317910/08:48
=== Ursinha_ is now known as Ursinha
=== braderhart_ is now known as braderhart
jamespagedosaboy, beisner: raised https://bugs.launchpad.net/juju-core/+bug/158310910:44
mupBug #1583109: error: private-address not set <juju-core:New> <https://launchpad.net/bugs/1583109>10:44
=== matthelmke_ is now known as matthelmke
gennadiyhi everyone, is it possible to deploy custom openstack image from juju charm?11:51
gennadiywe have a few snapshots and we want to use them in our charms11:51
gennadiyseems it's not 'true' juju way11:52
=== \b is now known as benonsoftware
jamespagebeisner, shall we land the ch fix for service_running and then generate the master branch re-syncs?11:55
jamespagethat would exercise this bug well11:55
beisnerjamespage, sounds good.  just confirming that the trace log gets enabled as planned on 1 short run now.11:55
jamespagebeisner, okies11:56
jamespagegoing to eat lunch11:56
simonklb_anyone familiar with the sync-watch plugin? for some reason it's causing two updates each time I re-build my charm - any idea why?12:22
=== simonklb_ is now known as simonklb
jamespagebeisner, ok going to raise reviews for resyncs right now12:43
beisnerjamespage, merging your c-h thing now12:43
jamespagebeisner, already done12:43
beisnerjamespage, oh you beat me to it12:43
jamespagejust pushed it12:43
beisnerha, good deal12:43
jamespagedosaboy, what's your bugref for the IPv6 thing?12:55
beisnerjamespage, skip ceilometer-agent.  i've got a review that i'll just resync and append.12:57
dosaboyjamespage: there's this one for the charm bug - https://bugs.launchpad.net/charm-helpers/+bug/158159812:59
mupBug #1581598: ipv6 enabled charms don't understand mngtmpaddr flag <ipv6> <openstack> <sts> <Charm Helpers:In Progress by hopem> <ceilometer (Juju Charms Collection):In Progress by hopem> <ceph (Juju Charms Collection):In Progress by hopem> <ceph-mon (Juju Charms Collection):New> <ceph-osd (Juju12:59
mupCharms Collection):In Progress by hopem> <ceph-radosgw (Juju Charms Collection):New for hopem> <cinder (Juju Charms Collection):In Progress by hopem> <glance (Juju Charms Collection):In Progress by hopem> <heat (Juju Charms Collection):In Progress by hopem> <keystone (Juju Charms Collection):In12:59
mupProgress by hopem> <neutron-api (Juju Charms Collection):In Progress by hopem> <nova-cloud-controller (Juju Charms Collection):In Progress by hopem> <nova-compute (Juju Charms Collection):In Progress by hopem> <openstack-dashboard (Juju Charms Collection):In Progress by hopem> <percona-cluster12:59
mup(Juju Charms Collection):In Progress by hopem> <rabbitmq-server (Juju Charms Collection):In Progress by hopem> <swift-proxy (Juju Charms Collection):In Progress by hopem> <swift-storage (Juju Charms Collection):In Progress by hopem> <https://launchpad.net/bugs/1581598>12:59
jamespagedosaboy, beisner: OK re-running now with amended commit message - I'd not raised any reviews just yet...12:59
dosaboyjamespage: once it all lands i can kick off an ipv6 run13:00
=== caribou_ is now known as caribou
jamespagebeisner, dosaboy: ok here they come13:15
jamespagehttps://review.openstack.org/#/q/status:open+branch:master+topic:bug/158117113:16
mupBug #1581171: pause/resume failing (workload status races) <landscape> <maintenance-mode> <uosci> <ceilometer-agent (Juju Charms Collection):In Progress by 1chb1n> <cinder (Juju Charms Collection):Fix Committed by thedac> <glance (Juju Charms Collection):Fix Committed by thedac> <keystone (Juju13:16
mupCharms Collection):In Progress by thedac> <https://launchpad.net/bugs/1581171>13:16
kjackalHey lazyPower, do you have a minute? Its about an exception I am getting when I stop filebeats.13:29
lazyPowersure, whats up?13:29
kjackalhttps://pastebin.canonical.com/156708/13:29
kjackalLet me also tell you what i am deploying13:30
lazyPowerI've seen this before kjackal13:30
kjackalhttps://pastebin.canonical.com/156709/13:30
kjackalDo we know what it is?13:30
lazyPowerunit-filebeat-0[15988]: 2016-05-18 13:06:11 INFO unit.filebeat/0.stop logger.go:40 subprocess.CalledProcessError: Command '['relation-list', '--format=json', '-r', 'elasticsearch:5']' returned non-zero exit status 2 <--  its trying to call relation-list on a relation thats been removed right?13:30
lazyPoweri only got this once, and was unable to reproduce it13:31
lazyPoweris the unit still alive?13:31
kjackalyes13:31
lazyPowerpaydirt. is the ES unit still alive?13:31
kjackalyes, the entire deployment is online13:32
lazyPowerhmm.. when i encountered this, the beat subordinate did not have an active relation, and the scope.unit relation interfaces were still trying ot contact a disconnected elasticsearch unit13:33
lazyPowerperhaps thats not the problem here13:33
kjackalwaitup13:33
lazyPowerwhich makes me think i should go peek at the elasticsearch interface to make sure i'm removing its .available state13:34
kjackalhow do you check if you have active relations?13:34
lazyPowereither via juju status, the gui, or by running the relation-* hookenv cmds on the unit13:35
lazyPowerkjackal i think i found the root of the issue though13:35
lazyPowerhttps://github.com/juju-solutions/interface-elasticsearch/blob/master/requires.py#L3213:35
lazyPowerreactive is doing exactly what i told it to do. the .available state is still set,  (notice i only remove .connected) - so its hitting its cached data13:36
lazyPowerand trying to reference that relationship because its still marked as active (i think this all true, cory may mythbust me)13:36
kjackal:)13:36
lazyPowerkjackal - has this been happening consistently?13:37
lazyPoweror is this the one-off that got hung up?13:37
lazyPowers/the/a13:37
kjackalit happened in two seperate deployment13:37
kjackaland i can reproduce it by jujuresolved --retry13:38
lazyPowerok let me grab a coffee and i'll push a fixed publish to my namespace13:38
lazyPowerif it works out, we'll bump the store revision13:38
kjackalsounds good13:39
kjackalso we need something line @when (elastic search available AND connected) call cache_elasticsearch_data(...)13:42
kjackallet me try that13:42
lazyPowerkjackal - think is, .available presumes .connected13:42
lazyPoweras .available is only ever set when we've gotten the connection string data we expect13:43
lazyPoweri think the problem lies in not removing that .available state on that conversation object13:43
lazyPowerkjackal https://github.com/juju-solutions/interface-elasticsearch/pull/613:44
kjackallet me try to test this... it will take some time...13:45
kjackalHa! I believe the charm is killed now!13:47
lazyPoweryeah?13:47
kjackalYes, it seems to work!13:47
kjackalGood job lazyPower!!! Not so lazy!!!13:48
kjackal:)13:48
lazyPower:) Thanks13:48
kjackalSo, do you have any eta on when this will be available?13:49
kjackalDo you want me to merge it?13:49
lazyPowerurl: cs:~lazypower/filebeat-013:49
lazyPowergive that a go in place of the store url if you dont mind. i'd like an a-z test before we merge this assuming its fixed13:50
kjackallet me do a full deployment with that charm13:50
kjackalThese easy fixes are too good to be true! But I am optimistic!13:51
lazyPower:)13:51
lazyPowerI am as well13:51
lazyPoweri'm curious why this wasn't rooted out i the bundle tests13:51
lazyPower*in13:51
beisnerjamespage, dosaboy, thedac, tinwood - fyi - i'll be doing some readme-only change/reviews and landing them to iterate a bit on gerrit change-merged stream advertisements and triggers wrt getting charm upload jobs set up in the chain.  just no-op noise, safe to ignore.13:52
kjackallazyPower could I have also a url for topbeat? The fix is in the beats_base and affects all beats charms13:54
lazyPowersure, 1 sec and i'll rebuild that as well13:54
kjackalthank you13:55
lazyPowerurl: cs:~lazypower/topbeat-013:56
gahanI'd like to update /etc/neutron/dhcp_agent.ini using juju (as it is maintained by juju). can someone enlighten me how to achieve through cli or gui?14:00
cory_fuI forget, does quickstart work with bundles that reference local: charms?14:01
lazyPowerbeisner - i know we've exposed config points for cinder like this, where you can modify config with a sub. Is this also true with neutron that you're aware of? (re: gahan's question above)14:01
lazyPowercory_fu negative14:01
cory_fuBlast and damn14:01
lazyPowerthats why deployer was so long-lived14:02
lazyPowerthat and its wrapped by our testing tooling14:02
beisnergahan, curious, what specifically are you needing to mod?14:02
gahanbeisner: I heard if I modify dhcp_domain field in mentioned .ini file, it wil change the value of field "search" in /etc/resolv.conf for all new instances in openstack14:04
beisnergahan, indeed, in liberty and prior you could do that there (ref:  http://docs.openstack.org/liberty/config-reference/content/section_neutron-dhcp_agent.ini.html) ... but it was deprecated and removed @mitaka.  i'm not sure where the equivalent is off hand.14:07
gahanbeisner, I'm still using liberty :) thanks14:08
beisnergahan, typically, any adjustments to those confs must be done via charm config values.  if you modify the file by hand, your changes will be overwritten when the conf is re-rendered from templates by the charm, which could happen at any time.14:08
gahanit doesn't seem like this particular one is exposed or I'm looking in wrong place14:09
beisnergahan, we'd need to add a charm config option, but also figure out what it means for mitaka and later.  i'd imagine it can be set by some other approach there.14:09
beisnergahan, right.  we don't expose 1:1 all conf options as that would be massive.  we typically encapsulate sane common defaults with knobs and levers to tune things to common needs.14:10
beisnerah, dns_domain in neutron.conf for >= mitaka it appears14:11
beisnerso this *could* be added to the charm so long as the conf template rendering logic is set up to plop the config in the right file depending on release version (we do that for other things, so that framework is already there).14:12
beisnerit'd have to go into the next/dev (master) charm first, which would then be released at either 16.07 or 16.10.14:13
lazyPowerhmm. i haven't validated this assertion yet, but do we know when using 1.25 if i set environment constraints (eg; tags=lazypower) and then i have additional tags defined in the bundle if those are additive (eg: tags=lazypower,bundle-constraint)   or if the bundle constraints override the environment constraints14:21
lazyPowerbeisner i think you have experience in this ^14:21
beisnerlazyPower, hmm i've only ever used constraints at bootstrap and deploy time (ie. in the bundle)14:22
beisnerlazyPower, i would think the constraint in the bundle would win though14:22
lazyPoweryeah i was afraid of that :/14:22
lazyPoweri'm trying to come up with a good workflow to test these submissions, without stepping all over oil's toes and without modifying the bundle14:23
lazyPoweri guess i'm caught in a corner where i have to mod the bundle. *snaps*14:23
beisnerlazyPower, sec...14:23
jamespagebeisner, I think we should put this resync through on a smoke only14:25
beisnerjamespage, ack14:25
beisnerjamespage, maybe kick a few fulls to try to trap this juju core bug?14:26
beisneri kicked 114:26
jamespagesure14:26
jamespagebut I'd not block +2 landing on that basis14:26
jamespageinfra queue must be long.... atm14:26
jamespageUOSCI is besting it hands down...14:27
lazyPower i think they *are* merging the tag constraints, at least thats the behavior i'm seeing with this deploy. #TIL14:27
beisnerjamespage, she's a hopping atm for sure14:27
beisnerlazyPower, we use this to strip or insert constraints on the fly in osci:  http://bazaar.launchpad.net/~uosci/ubuntu-openstack-ci/trunk/view/head:/tools/bundle_constrainer.py#L1814:27
beisnerlazyPower, i've got a WIP refactor of that into our git namespace with other features, but that one is functional.14:28
lazyPowerthat would be excellent if i were generating this bundle14:28
beisnerlazyPower, pull it down, pipe it through that, get 0 constraints ;-)14:28
lazyPoweri think thats a big part of the disconnect here, is i'm testing an artifact of their submission, not really using the tooling OS/OIL uses14:28
beisneroh, so they have a bundle that they're proposing with abnormal constraints?14:29
lazyPoweryeah14:29
lazyPowertags=openstack, or tags=nedge14:29
cory_fuarosales, kwmonroe, kjackal: Quick review of README updates for Bigtop PR: https://github.com/juju-solutions/bigtop/pull/214:29
lazyPowerwe kind of need that for placement however14:29
lazyPowerthese charms have very strict hardware requirements, if the charms detect they are on a sub-par node, it panics and sets the charm to blocked and refuses to continue14:29
beisnerlazyPower, good thing actually.  much better than mysteriously failing14:30
lazyPoweryeah i'd rather it punch me in the face with a reason, than punch me in the face and tell me to go troll the logs :)14:30
beisnerjamespage, yah the zuul queue is large atm14:33
beisnerwe have 42 of the 235 jobs queued up ;-)14:33
beisnerjamespage, bahh.  ceph-mon tox ini has site_packages True, which is bad.  it failed upstream CI, but passes ours b/c we of course have that installed.14:46
beisneri pulled ceph-mon master, changed to sitepackages = False locally, and we fail identically to http://logs.openstack.org/57/318057/1/check/gate-charm-ceph-mon-python27/1ab631a/console.html14:46
beisnerwe need to make a pass and flip those False on any charms that have that True14:47
jamespagebeisner, is apt in pypi?14:48
beisnerjamespage, not sure if it is.  but it seems to me that should be mocked out anyway14:48
lazyPowerjamespage sure is https://pypi.python.org/pypi/apt/14:48
beisnerjamespage, i'd suspect this passed before infra started re-paving hosts in the p->t upgrade efforts.14:50
beisneror something along those lines14:50
jamespagebeisner, new virtualenv disables this by default14:50
beisnereither way, site packages pollute the test and will give differing results on different hosts14:50
beisnerjamespage, yes, but if it's explicitly set True in tox.ini, it'll still use site packages14:50
jamespageyup14:51
beisnerwe might be wise to inject False in case someone fires up with an older tox or virtualenv14:51
arosalescory_fu: thanks, taking a look at the readme now . . .14:56
jcastrolazyPower: out of curiosity, have you tested the beats charms on xenial? wondering why they're trusty-only15:00
lazyPowerjcastro - at the time of writing that layer their archive did not have xenial packages available15:01
lazyPowernow that xenial is out, i think that may have changed. simple enough to add a series and kick off a bundle test. /me will do that later today15:01
jcastrooh ok, so blocking on upstream packages15:01
lazyPoweryeah however i'm not certain thats still the case15:01
lutostagwhere would I file a bug for the charm store?15:34
lutostagah there's even a link at the bottom of the page... duh ;)15:35
=== arturt______ is now known as arturt_
=== arturt_ is now known as arturt______
lazyPowerlutostag - we hid it down there in hopes it would be helpful :D16:45
gennadiyhi everybody, seems i have some issues charms publishing. as example i have pushed mesos-dns charm more than 1hr ago. but haven't got in store yet.16:53
gennadiysource code - https://code.launchpad.net/~dataart.telco/charms/trusty/mesos-dns/trunk16:53
gennadiyis it possible to check what is wrong with it?16:54
lazyPowergennadiy - launchpad ingestion was broken a couple weeks ago and has been unable to be restored. we're relying on the new charm publishing features of the store to continue progress16:54
lazyPowergennadiy see: https://jujucharms.com/docs/devel/authors-charm-store16:55
lazyPowergennadiy - bright side of the inconvenience is your publishing becomes instantaneous vs the 30/60 minute ingest waiting period.16:56
gennadiythank you @lazyPower i will review new mechanism16:58
jamespagebeisner, updated https://review.openstack.org/#/c/318057/ with mocking for apt17:11
jamespagewaiting for check to confirm that's OK17:11
jamespagebeisner, stable syncs17:12
jamespagehttps://review.openstack.org/#/q/status:open+branch:stable/16.04+topic:bug/158117117:12
mupBug #1581171: pause/resume failing (workload status races) <landscape> <maintenance-mode> <uosci> <ceilometer-agent (Juju Charms Collection):Fix Committed by 1chb1n> <cinder (Juju Charms Collection):Fix Committed by thedac> <glance (Juju Charms Collection):Fix Committed by thedac> <keystone (Juju17:12
mupCharms Collection):In Progress by thedac> <https://launchpad.net/bugs/1581171>17:12
beisnerjamespage, ack thx17:12
gennadiy@lazyPower - is it possible to remove charm?17:20
lazyPowerno removal, but you can remove the permissions from the charm so only you can see it17:20
lazyPowercharm grant --help17:21
gennadiyok17:21
gennadiyanother question: can we deploy specific openstack snapshot from charm?17:21
lazyPowernot sure what you mean17:21
gennadiy@lazyPower - now we have snapshot/image of openstack machine and we would like to deploy it from juju.17:29
gennadiyi know that it's not 'true' way. but maybe it's possible17:29
lazyPowerah, i dont think we have any support for that, as we assume the charms to probe/setup as required. i'm not going to say its not possible, but i dont know thats a supported deployment method as of yet17:38
lazyPowerthere has been talk of imaging support for providers that can support it, but i have no idea where that is on the roadmap if its a next cycle thing or cycle after next.17:39
gennadiy@lazyPower - one more question: i have account https://launchpad.net/~dataart.telco but email login is tads2015dataart@gmail.com so when i make charm login it will not allow to push to cs:~dataart.telco/sipp17:46
gennadiyas i understand it calculates name by primary email. am i right?17:46
lazyPowerlaunchpad name, or launchpad group actually17:46
lazyPowerits still backed by the mechanisms (groups, acls, etc) inherited by ubuntu SSO17:47
gennadiyhm. "charm push . cs:~dataart.telco/sipp" returns error "unauthorized: access denied for user "tads2015dataart" but https://launchpad.net/~dataart.telco it's me17:49
gennadiya few mouth ago i renamed account from tads2015dataart to dataart.telco17:50
gennadiy*month17:51
lazyPowerjrwren - any known issues with accounts that have changed their handle and the charm-store's backend bits?17:51
jrwrenlazyPower: yes, if the account name changed since they first logged into www.jujucharms.com17:52
lazyPowergennadiy - does this sound like the situation? ^   did you log into the charm-store (jujucharms.com website) prior to renaming your launchpad account?17:56
gennadiyalso i can't login to jujucharm too17:56
gennadiyyes17:56
gennadiyyes i logged before rename17:56
lazyPowerjrwren - anything we can do to help gennadiy? And for future reference, if i encounter a user with similar issues, where should i direct them to file bugs/etc. so we can triage accordingly?17:57
gennadiydoes it fix issue if i remove account and create new with correct name?17:57
lazyPowerideally we should be able to fix this... i'm not very familiar with that side of the codebase however, so i'm bugging jay for details :)17:58
PrabakaranHi Matt/Kevin, I was reviewing the merge proposal which you have given for ibm-java. It looks good to me and I have a small doubt in the default package name and SHA value for JRE.18:01
PrabakaranAs per this merge proposal http://bazaar.launchpad.net/~kwmonroe/charms/trusty/ibm-java/may-2016/view/head:/reactive/ibm-java default package name and SHA values are used only for SDK in the reactive/ibm-java file (Between Line number 14 to 25).18:01
PrabakaranHow this default package name and SHA values for JRE if it is not provided by the user as it handles only for SDK.18:01
jrwrenlazyPower, gennadiy i'm browsing our docs to see if we have notes on this issue. iirc, we did the same thing for aisrael18:03
PrabakaranKindly advise on this and also I was not able deploy this merge proposal because of the if loop in the line number 65. After accepting this merge proposal I will be correcting this line of code.18:03
mbruzekPrabakaran: What is your concern with the ibm-java merge proposal?18:03
mbruzek Prabakaran: If you can fix it I think that is great. Let me check the code. Why is there a loop18:05
Prabakaranwe have a different package for JRE and SDK. My doubt is regarding the line of codes http://pastebin.ubuntu.com/16498220/ in the reactive file. How default package will work for ibm-jre18:07
Prabakaranthats no problem. i will fix it.18:08
jrwrengennadiy: can you file a bug with your account rename details at https://github.com/CanonicalLtd/jujucharms.com/issues ?18:09
PrabakaranAs per my understanding this new proposal code will install SDK primarly and if the user wants install jre obivously he must have to feed package name and its sha thru juju set command. Is my understanding is correct?18:19
mbruzekPrabakaran: that sounds good to me.18:28
bbaqarhey guys .. we can push revisions in charms using bzr right? i can see the revisions on launchpad but not is charm show cs....18:30
kwmonroeyup Prabakaran - you got it.  the user gets to choose what installer to use (sdk or jre) by setting the installer filename18:30
kwmonroePrabakaran: so there is no need ot set the default for a jre (in fact, there's no need to set any default installer or sha since we say the installer filename and sha is required to be set in the config18:31
mbruzekbbaqar: You can push to your own namespace, but the ones in ~charmers need to be reviewed18:32
bbaqarmbruzek: well i have a private team space where i can push charms ..18:33
bbaqari still cant get new revisions in18:33
lazyPowerbbaqar - launchpad ingest has been broken for about 2 weeks, we sent a notice to the mailing list18:34
lazyPowerbbaqar see: https://jujucharms.com/docs/devel/authors-charm-store18:34
mbruzekbbaqar: Yes the automatic injest is broken, but you can push using the document that lazyPower linked ^18:35
lazyPowerthis will get you ramped up on the new charm push commands which will eliminate your need to wait 20/30 minutes for ingest. Make sure you fully read that document and grokk the new ACL structure for charms. by default, they are only visible to you as the uploader, and go into an unpublished channel18:35
bbaqarlazyPower: i believe i have done all this .. i ll go over the document once again18:36
lazyPowerbbaqar so just to confirm, charm publish . ~plumgrid-ons/series/mycharm does not work for you?18:37
mbruzeknotice the dot for current directory.18:38
lazyPoweri paraphrased the namespace, feel free to sub with the proper group string18:38
bbaqarlazypower: i ran the exact same thing: charm push . cs:~plumgrid-team/trusty/neutron-api-plumgrid .. but the problem is it did not have the last two revisions that i pushed in the last week18:39
lazyPowerbbaqar - did you publish those charms you pushed?18:39
mbruzekbbaqar: Did you publish those charms?18:39
lazyPowerby default they land in an unpublished channel. You have to both push, and publish against the appropriate channel (Stable/devel accordingly)18:40
PrabakaranI am deploying and checking this ibm-java now.. i will accept this merge proposal. Thanks matt and kevin :)18:40
bbaqarlazypower: yup .. charm publish cs:~plumgrid-team/trusty/neutron-api-plumgrid-18 --channel stable    problem is i want 20th rev18:40
mbruzekbbaquar: charm publish cs:~plumgrid-team/trusty/neutron-api-plumgrid-2018:41
bbaqarmbruzek: no matching charm or bundle for cs:~plumgrid-team/trusty/neutron-api-plumgrid-2018:42
lazyPowerbbaqar - i'm showing that -18 is head of what you have published. verified with `charm list -u plumgrid-team`  and additionally charm show cs:~plumgrid-team/trusty/neutron-api-plumgrid  does not show a -20 revision as available.18:42
lazyPowerbbaqar so where is the "20'th revision" coming from?18:42
lazyPoweris that the BZR id?18:42
mbruzekbbaqar: Yeah I only see 18 revisions in the listing. Perhaps the permissions are not allowing us to see 19 and 20?18:43
bbaqarmbrukzek, lazypower: http://bazaar.launchpad.net/~plumgrid-team/charms/trusty/neutron-api-plumgrid/trunk/changes/20?start_revid=2018:43
lazyPowermbruzek - i'm pretty sure evne if its in unpublished, it will show up in the revision-info key18:43
lazyPowerbbaqar ah thats where the disconnect is coming from. those revision id's do not match whats in bzr, at all18:43
mbruzekah18:43
bbaqarits there on launchpad18:43
lazyPowerits completely disconnected from VCS18:43
bbaqarSo am i doing something wrong here?18:45
mbruzekbbaqar: Yeah as we mentioned the automatic launchpad injest is broken, you have to manually push each revision, and then publish the ones you want to see.  The upside is no waiting 30 minutes for the automatic process, and the downside is that you have more manual work.18:46
lazyPowerbbaqar if you did a charm push, it will tell you what revision the charm store incremented to.18:46
mbruzekSo checkout the latest from bzr to your computer, then push it to the charm store.18:46
lazyPower^18:46
mbruzek* Where more manual work is 2 additional "charm" commands.18:48
bbaqarI love the fact that we dont have to wait 30 mins and i am willing to run as many commands it takes .. just trying to figure out what they are exactly .. so this is what i am going to do now18:48
mbruzekbbaqar: the document that lazyPower linked you to outlines the steps18:49
bbaqarokay so this is what i am going to do 1) bzr branch lp:~plumgrid-team/charms/trusty/neutron-api-plumgrid/trunk 2) bzr ci -m "commit message" --unchanged 3) bzr push lp:~plumgrid-team/charms/trusty/neutron-api-plumgrid/trunk 4) charm push . cs:~plumgrid-team/trusty/neutron-api-plumgrid 5) charm publish cs:~plumgrid-team/trusty/neutron-api-plumgrid --channel stable18:50
bbaqarmbruzek i did run that .. let me try this18:50
lazyPowerbbaqar nope18:51
lazyPowerbbaqar you *have* to specify the revision output in the charm push command to that charm publish command18:51
bbaqarohhhh h18:51
bbaqari get it ..18:51
lazyPowerwhich should increment to -19, as -18 is head18:51
bbaqarwait let me try that18:51
gennadiy@lazyPower - new publish charm tool - very cool. it shows errors in bundle! very useful18:51
lazyPowergennadiy really happy its a positive impact on your experience :)18:52
lazyPowerjrwren you're getting praise and not targeted sir ^ <318:52
gennadiyone more improvement: add flag --grant-everyone to publish command18:52
mbruzekgennadiy: and it lets *you* control what charms/bundles are in the store, no more automated injestion18:52
lazyPowergennadiy file a bug over here: https://github.com/juju/charm18:52
mbruzekgennadiy: you can do that with the charm set acl command18:52
bbaqarlazyPower: so this right charm push . cs:~plumgrid-team/trusty/neutron-api-plumgrid-1918:53
bbaqarlazypower but it says error: charm or bundle id "cs:~plumgrid-team/trusty/neutron-api-plumgrid-21" is not allowed a revision18:53
lazyPowerbbaqar nope push doesn't need the revno18:53
mbruzekgennadiy:  sorry the `charm grant cs:~kirk/foo everyone` command.18:53
lazyPoweronly publish does, push i creating the entity, publish is registering it.18:53
lazyPowerbbaqar - so what you're looking to do is this:18:54
lazyPowercharm push . cs:~plumgrid-team/trusty/neutron-api-plumgrid18:54
lazyPowerwhich it should come back with some output like:18:54
lazyPowerurl: cs:~plumgrid-team/trusty/enutron-api-plumgrid-1918:54
lazyPowerchannel: unpublished18:54
lazyPowerThen you move into the publish phase if its ready for that:18:54
lazyPowercharm publish cs:~plumgrid-team/trusty/neutron-api-plumgrid-19 --acl read everyone18:55
lazyPowerit will default to publishing into the stable channel. if this is a devel release, please target the channel appropriately18:55
bbaqarIt returns the same revno url: cs:~plumgrid-team/trusty/neutron-api-plumgrid-1818:55
lazyPowerso, this is a super cool feature of push18:56
lazyPoweryou dont have a change from what you pushed into the -18 revision, teh charm command does store *small bits of metadata about the VCS tree*18:56
lazyPowerall that info is shown when you charm show cs:~plumgrid-team/trusty/neutron-api-plumgrid  --- pipe that into less and evaluate the output to see the revision it read in from teh bzr metadata. Its not reading and is disconnected from, but if its present, we will use it to our advantage and keep you from revving a charm with no changes18:57
lazyPowerbbaqar - one way you can validate is to `charm pull  cs:~plumgrid-team/trusty/neutron-api-plumgrid-18`  to a temporary location and then dir-diff that against what you have in your bzr archive. You should see its 1:1 copy18:57
lazyPoweralso i think its worth mentioning that some of these nuances will be much easier to see once we have the new review queue launched, which offers diffing between revisions and is layer aware. no ETA on when that will be available though, other than we are actively cycling towards resolution.18:58
bbaqari understand .. yup you are right . .i pulled the charm .. and did a diff between the two directories .. its the same .. but one more thing ... i should be able to deploy the charm using juju deploy cs:~plumgrid-team/trusty/neutron-api-plumgrid-1818:59
lazyPowerThat is correct, so long as you granted read access to the published charm to the user you are logged in as thats trying ot deploy it, or gave read permissions to everyone19:00
mbruzekbbaqar: It will depend on the permissions granted, but yes you should be able to19:00
bbaqari got it .. thanks guys ..19:01
bbaqarthanks for patiently explaining it19:01
mbruzekbbaqar: No problem please raise issues (link above) if you feel it can be improved.  If the documentation was not clear you can open an issue for that too19:02
lazyPowernp! if there's any verbiage we could explain better in those docs, i'd love to get a bug report from anyone struggling with the new publish workflow19:02
lazyPowermbruzek we have finished assimilation, we are the same person19:02
lazyPowermbruzek who are you?19:02
bbaqarmbruzek: now that it is working .. this is awesome19:03
* mbruzek whoami19:03
lazyPower> Pizza19:03
mbruzekhttps://github.com/juju/docs/issues/new19:03
lazyPower:O it all makes sense now19:03
mbruzekSo my other self (lazypower) gave you a link to create issues with the charm command, and the documentation link is there if you feel it could have been more clear (which I have a feeling it could have been)19:04
lazyPowerwe are the juju singularity19:05
bbaqarlazyPower: I ll read it once again and raise an issue if i think we should update the doc19:07
bbaqarOnce again .. guys this is cool .. i feel like i have control now ..19:15
lazyPower\o/ thats awesome19:23
lazyPowerbbaqar glad it had a positive impact on your experience :)19:23
PrabakaranHi Matt/Kevin, I have tested ibm-java and i am able to deploy successfully. I have merged those changes into the stream. And also i have updated the charm store with the updated code https://jujucharms.com/u/ibmcharmers/ibm-java/trusty/7 . I hope it will be approved soon. Thanks for your help and support :)19:37
mbruzekPrabakaran: OK we will give it another look19:37
PrabakaranThanks matt19:38
mbruzekPrabakaran: did you also build the charm and update the bzr merge proposal19:38
Prabakarani did charm build with the latest source code and pushed using charm push command19:41
Prabakaranmbruzek, All ok? is there anything needs to be done from my end?...19:46
mbruzekPrabakaran: can you give me link to the merge proposal ?19:46
Prabakaranfrom which branch to which branch?19:47
=== redir is now known as redir_lunch
PrabakaranSource Code Repo : https://code.launchpad.net/~ibmcharmers/charms/trusty/ibm-java/source  This charm has been pushed into the charm store. Below is the link  Charm store link : https://jujucharms.com/u/ibmcharmers/ibm-java/trusty/719:49
mbruzekPrabakaran: The Juju charm store and bzr are different things.19:51
mbruzekTo be in the review queue you need to create a bug with a merge proposal19:52
mbruzekYou had one, let me find it19:52
Prabakaranhttps://bugs.launchpad.net/charms/+bug/147706719:52
mupBug #1477067: New Charm: IBM Java SDK <Juju Charms Collection:Fix Committed> <https://launchpad.net/bugs/1477067>19:52
mbruzekPrabakaran: Yep that is what I needed.19:54
mbruzekPrabakaran: my mistake, this one was a bug since there is no charm to merge with, so I incorrectly used "merge proposal"19:54
Prabakaranthats no problem19:54
Prabakarannothing else from my end right..19:55
mbruzekno19:55
Prabakaranits time for me to sleep...if anything is required please email me.. thanks again for your great support :)19:56
kjackalcory_fu: Do you have a minute?19:56
cory_fuSure.  We're in bigdata-daily19:57
=== zz_CyberJacob is now known as CyberJacob
=== redir_lunch is now known as redir
cholcombeinterfaces.juju.solutions doesn't seem to understand lp links21:08
cholcombethe Apache WSGI base layer repo link is dead21:08
lazyPowercholcombe - err thats just a databag21:16
lazyPowerdo you mean the builder?21:16
lazyPowercholcombe - here's the list of what we test with the builder: https://github.com/juju/charm-tools/blob/master/tests/test_fetchers.py#L4921:16
cholcombelazyPower, i'm not sure.21:16
lazyPowersorry, i mean the fetcher21:16
cholcombelazyPower, i see21:17
cholcombewell than maybe interfaces.juju.solutions is having an issue resolving lp links21:17
cholcombelazyPower, i was just trying to click the repo link to figure out what the apache wsgi layer requires21:25
lazyPowercholcombe OH21:25
cholcombefirefox just gives me an: I don't understand this link error21:25
cholcombe:D you get it now haha21:25
lazyPoweryou mean with the browser21:25
lazyPoweryeahhhhhh21:25
cholcombeyep21:25
lazyPowerthis is a fail on our planning part21:25
lazyPowercan you file a bug against the repo?21:25
cholcombesure if i could find it lol21:25
lazyPowerthis may still live in bens namespace21:26
cholcombei can't find it under jacek's lp21:26
lazyPowerhttps://github.com/bcsaller/juju-interface <- is what i meant21:26
cholcombeoh nvm i found it21:26
cholcombehttps://code.launchpad.net/~jacekn/charms/+source/apache-wsgi/+git/apache-wsgi is the link21:26
lazyPowerthis is the codebase for the interfaces webservice21:27
lazyPowerwe'll need to add support to resolve those links21:27
cholcombelazyPower, everyone else seems to just be putting in the link to the summary page21:27
* lazyPower shrugs21:28
lazyPoweri use github yo21:28
cholcombelazyPower, i updated it21:28
lazyPowerbut that works equally as well21:28
cholcombeit would take me 10x as long to write a bug report haha21:29
cholcombei still think it's too difficult to find out what reactive layers and interfaces require of the person using them.  You have to dig21:32
mpjettarandom question: I’m using juju 2.0-beta6 and MAAS 2.0 beta3. I’m still having to use “export JUJU_DEV_FEATURE_FLAGS=maas2” , is that correct or am I doing something wrong ?21:47
lazyPowermpjetta - i dont think that came out from behind the feature flag until beta721:55
lazyPowerI'm pretty sure thats covered in the release notes in /topic however21:55
mpjettaok thanks22:07

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