=== fginther` is now known as fginther
Gilcan anyone share a link with steps to install juju-gui charm to openstack liberty? thanks!03:00
lazyPowerstokachu usually that was a symptom of something being sick in my env, like the security group not opening the port to the mongo instance on the model controller, or maybe my maas bootstrap timeout wasn't long enough04:32
lazyPowerGil - hey there, not really sure what you're asking. Do you have an openstack liberty provider available to you that you would like to consume in juju, and additionally deploy the juju gui?04:33
lazyPowers/consume/model your applications/04:33
narinderguptamarcoceppi: hey marco06:14
gennadiyhi everybody, may i use git launchpad repo to publish charms?09:32
bloodearnestyo lazyPower, just looking over09:33
bloodearnestand have some questions when you are about09:33
kjackalhi everyone. I am manually provisioning an IPv6 only VM. Deployment of charms there fail with cannot get archive: Get https://api.jujucharms.com/charmstore/v4/trusty/mysql-35/archive: dial tcp network is unreachable10:00
kjackalDoes juju handle this case or is it all up to the admin?10:00
pittiwhat could be the cause of12:03
pitti$ juju deploy --repository deployment/charms  local:trusty/langpack-o-matic12:03
pittiERROR charm not found in "/home/martin/ubuntu/langpack-o-matic/deployment/charms": local:trusty/langpack-o-matic12:03
pittithe charm definitively exists:12:03
pitti$ ls /home/martin/ubuntu/langpack-o-matic/deployment/charms/trusty/langpack-o-matic/12:03
pitticonfig.yaml  hooks  metadata.yaml  README.md12:03
pitti(juju 1.25 in xenial)12:03
pittiI have another charm in that dir ("bootstrap-node"), and deploying that works fine12:04
pitti$ ls /home/martin/ubuntu/langpack-o-matic/deployment/charms/trusty/bootstrap-node/12:04
pittihooks  metadata.yaml12:04
pittiah, nevermind! typo in "name:" in metadata.yaml12:07
pittitypical "you have to ask, and then you'll figure it out" situation12:07
lazyPoweryo bloodearnest  o/14:06
bloodearnestlazyPower, hey14:07
lazyPowerhows things?14:07
bloodearnestgood, sprint next week, so lots of prep14:08
bloodearnestand trying to understand this new systemd world...14:08
lazyPowergennadiy - (super late reply) - you can warehouse the code in git, however bzr is still the only ingestion method right now. There's a new feature coming that decouples your charms from DVCS which in turn provides instant publishing14:08
lazyPowerbloodearnest - i hear ya man!14:09
lazyPoweri upgraded to xenial on my primary workhorse and its been slow going getting the system stood back up. i need another weekend on it14:09
bloodearnestso, tls layer14:09
lazyPowerstill totally a thing :)14:09
lazyPoweranything specific i can help with?14:10
bloodearnestmy usage is very different though14:10
gennadiyi have found bzr-sync module. it will sync my code from git to bzr14:10
bloodearnestso, some thoughts:14:10
gennadiythanks for your response14:10
lazyPowergennadiy - its a nice solution for a short term problem :)14:10
lazyPowergennadiy also o/ great to see you in here14:10
bloodearnest1) a standard layer for generating certs would be useful14:10
bloodearnestfor us to use easyrsa, it would need to be installed by system packages14:11
bloodearnestbut we could use14:11
lazyPowerso, we need to put easy-rsa in a PPA or is that still a red-flag?14:12
bloodearnest2) there are 2 distinct uses of tls certs here: intra service comms (your layer/interface), and public service comms14:12
jrwrenkjackal: most charms have no support for ipv6. Its not that they don't support them but they've never been tested there, so they often do things that do not support ipv6.14:14
lazyPowerbloodearnest - yeah, matt and I have talked about this, the public facing ssl bits. we dont have a path forward with any time alotted to get that done14:14
lazyPowerbut we've been kicking around ideas. we started with an idea to wrap lets-encrypt as a layer14:14
jrwrenkjackal: e.g. take an ip address from juju and curl http://thatip/   which doesn't work because it needs to be wrapped in [] to be a valid ipv6 url.14:14
lazyPowerbloodearnest - if you were going to put public facing ssl infrastructure in your modeling language. what would be your preferred method to do so?14:15
bloodearnestlazyPower, ppa won't work, but we could add a package to our archives, perhaps. I'm also not sure how much control it provides. Can it do SubjectAlternativeName for DNS *and* IP?14:15
lazyPowerit already does add SAN for DNS and IP14:16
lazyPoweri think we can tune the config to include a config option for additional SAN14:16
lazyPowerright now we're kind of lazy about what we stuff in the SAN, ip and hostname14:16
lazyPowerbut it supports both entry styles14:16
bloodearnestlazyPower, so, the 2 uses are different enough to warrent different approach, and different interfaces, I suspext14:16
lazyPoweroh for sure14:17
lazyPowerself signed certs vs ca signed sergs14:17
kjackaljrwren: True. So to have juju on an ipv6 setup we need a translation service to ipv414:17
lazyPowermbruzek o/ morning14:17
lazyPowermbruzek we're talking about our baby14:18
lazyPower> re: layer-tls14:18
mbruzekis my baby ugly?14:18
lazyPowerits our ugly babby14:18
mbruzeksay it isn't so!14:18
lazyPower:P nah14:18
lazyPowerbloodearnest was just riffing about how we can make it more useful to more ppl14:18
bloodearnestis what we want, in terms of self signed cert14:19
lazyPowerthey need a deb package of easyrsa. aparently fetching it from where we're grabbing it is basically out of sorts14:19
bloodearnestthe DNS/IP thing is an openssl/gotls thing14:19
lazyPowerbloodearnest we can do these alt_names no prob14:19
bloodearnestgotls is stricter and wants proper SANs14:20
lazyPowerright on14:20
lazyPowerso, matt and i are spiking on k8s this week14:21
lazyPowerif you want to file some bugs @ the repo for layer-tls we can start planning and try to get it on our board14:21
bloodearnestso, I think what we want is a subordinate charm, so we can configure multiple certs for one service (e.g. apache, haproxy)14:21
bloodearnestlazyPower, ack14:21
mbruzekwe talked about a subordinate charm that is a good idea, I wonder if both can be built from the same layer so we don't have to maintain two different codebases14:22
bloodearnestmbruzek, you can build 2 charms from 1 layer?14:23
mbruzekbloodearnest: I would see a subordinate layer that imports tls, and just has metadata that makes it a subordinate14:24
mbruzekThen add the functionality you and lazypower were discussing to the tls-layer14:24
bloodearnestI suspect the interface types will be different (1 for peer negotiation, 1 for simple path communication)14:24
lazyPowerpath of least resistance14:25
mbruzekbloodearnest: The subordinate could have a tls provides relation and or requires, and you would have to extend our tls interface which *only* deals with the peer relation at this point14:26
mbruzekAgain those could be done in the reusable tls layer and interface14:26
mbruzekYour subordinate layer would be extremely small, just making it a subordinate and using the provided functionality14:26
bloodearnestso they'd be differentiated on relation type (provides, peer) rather than name?14:27
mbruzekbloodearnest: yes14:27
mbruzekthe beauty of layers!14:27
mbruzekreusable components14:27
bloodearnestso, the issue is, how best to generate certs, preferably using just system packages14:28
bloodearnestor python deps14:28
bloodearnestthe python version above works fine in xenial, fwiw, python-cryptography is in main14:28
bloodearnestbut not trusty :(14:29
mbruzekwell the current tls layer uses easyrsa (as lazypower) pointed out, if that is not sufficient you can suggest alternate methods.14:29
mbruzekIn Juju 2.0 you can in the metadata.yaml specify what release your charm supports.14:30
bloodearnestany method is fine, as long as it's a) vendored or b) system packaged14:30
bloodearnestgrabing from git is a no-no14:30
lazyPowerbloodearnest how about resources?14:31
bloodearnestthat would work also14:31
bloodearnestbut require some manual prepping14:31
lazyPowerwhat if easyrsa were exposed as a charm resource, you the deployment engineer stuff @ resources in your model-controller, and when you deploy boom its all offline.14:31
bloodearnestnicer if it could work OOTB14:31
bloodearnestthe self signed stuff is really only for devel14:32
bloodearnestplus, we are a ways away from being on 2.014:33
mbruzekbloodearnest: I used easyrsa from github because it had some bug fixes I needed. if you can get the repo one working submit a pull request for that.14:33
bloodearnestmbruzek, ok, I will try that14:33
mbruzekeasy-rsa latest github release 3.0.1, vs the latest easy-rsa in Xenial is 2.2.214:35
mbruzekI know you have rules against github, but I question if our rules move at the speed of modern software14:36
bloodearnestmbruzek, not my rules14:36
mbruzekbloodearnest: I know14:37
mbruzekmy point is you are 4 releases behind upstream, and the rules are supposed to be for "security", I would want the latest release if I were doing it for myself.14:38
mbruzekIt would be great if we could create a snap of the latest release and put that in the charm.  If snaps can be trusted like archive14:38
lazyPoweri have this appliance docker image i use to print some certs sometimes14:39
bloodearnestmbruzek, can't we just vendor it in some other form14:39
lazyPowercaveate: you install docker on every host you want to generate certs14:39
bloodearnestit's just a cli wrapper around openssl cli,14:39
lazyPowerpretty much14:40
lazyPowerbut its based on busybox so its stupid small14:40
lazyPowerthats the only saving grace here14:40
bloodearnestlazyPower, mbruzek: easy-rsa 3.0.1 is 140k of text files (40k of docs)14:45
bloodearnestseems reasonable to vendor into the layer?14:45
mbruzekbloodearnest: yeah I think we are OK there, I would get worried about gb14:46
mbruzekbloodearnest: you were going to change it to the package manager anyway... I am sure that one is less kilobytes right?14:46
bloodearnestprobably about the same14:47
mbruzekbloodearnest: I get it, our current layer does it wrong by grabbing from github.14:48
bloodearnestI think w/o docs and extras, you're talking about 60kb14:48
cory_fukjackal: I don't know if we'd need a translation layer really, we just need to audit charms and start testing them in IPv6 environments to ensure they're coded to be IPv6 aware.  That said, your error seems like Juju couldn't connect to the charm store via IPv6 which seems even more fundamental than charms supporting IPv6.14:49
bloodearnestmbruzek, not objectivelywrong, perhaps, but wrong for us :)14:49
cory_fuI wonder if rick_h_ can chime in on whether there are issues between Juju and the charm store in IPv614:49
mbruzekbloodearnest: so help us fix it so it is _more_ useful14:49
bloodearnestmbruzek, on it14:49
rick_h_cory_fu: yes! :)14:49
cory_fuYes you can chime in, or yes there are issues?  ;)14:50
rick_h_cory_fu: was just talking with kjackal about this in another channel and asked him to kick off an email because we expect problems with the store and the charms in them to be honest14:50
cory_fuAh, I see14:50
rick_h_cory_fu: the charmstore is fronted by apache2 with SSL terminitaion and only works on IPV4, we'll have to work with IS on how to add IPV6 support14:50
rick_h_cory_fu: but there's a bigger issue as to what/how charms would work?14:50
rick_h_can wordpress, exposed, work with IPV6 ootb behind haproxy?14:51
Gilhi lazyPower thanks.  never had any problems when deploying juju-gui on trusty.  When I try deploy on liberty, I get this:  "ERROR cannot resolve charm URL "cs:wily/juju-gui": charm not found".  in my environments.yaml I have "default-series: wily" in the maas section.  I needed wily and liberty to deploy this successfully:  https://jujucharms.com/u/openstack-charmers-next/openstack-lxd14:51
rick_h_same with all services that can be exposed, how many don't support binding to an IPV6 addr14:51
rick_h_Gil: do you need the GUI running on wily?14:51
rick_h_Gil: are you colocating it with another Wily services or something?14:51
jrwrenrick_h_: and the inverse too, a cloud may be ipv4 on CGN or private IP, but support ipv6 public addresses14:52
rick_h_jrwren: yea, there's a whole can of worms here we've not worked through to my knowledge14:52
bloodearnestmbruzek, so, the bugfixes you needed are not in 3.0.1, correct?14:53
mbruzekbloodearnest: I don't recall what version was needed, but the github version fixed the error I was getting14:54
bloodearnestI will attempt a PR to use a vendored version14:54
Gilrick_h my main goal is to work with the nova lxd which is why I'm deploying that bundle. yes, i'd like to run the juju-gui on the liberty deploy if it's possible.14:55
rick_h_Gil: right, but you only need wily GUI if it's on a wily host. You can deploy the trusty juju-gui onto liberty without a problem14:57
rick_h_Gil: the things you deploy don't all have to be on the same series.14:57
Gilok gtk.  when I deployed the bundle: https://jujucharms.com/u/openstack-charmers-next/openstack-lxd it errored out and complained about the charms not matching the series so I went to "all -wily".  So what I need to do then is change in environments.yaml back to "default-series: trusty" I guess which I will try now.14:59
lazyPowerGil - that or juju deploy trusty/juju-gui15:01
lazyPowertvansteenburgh - got a moment for a quick review? https://github.com/juju-solutions/jujubox/pull/215:05
tvansteenburghlazyPower: yeah gimme a min and i'll take a look15:05
Giljuju deploy --to 0 cs:trusty/juju-gui; gives:  Added charm "cs:trusty/juju-gui-48" to the environment. + ERROR cannot assign unit "juju-gui/1" to machine 0: series does not match15:06
lazyPowerah thats because the state-server is wily, gotchya.15:07
lazyPoweri didnt think you were colocating15:07
=== firl_ is now known as firl
tvansteenburghlazyPower: won't this break 1.25 users? maybe we should put these changes in a 2.0 branch?15:08
lazyPowertvansteenburgh - its for :devel flavored15:08
lazyPowerthis doesn't change :latest15:08
tvansteenburghright, but this will eventually become latest i expect15:08
lazyPowerone 2.0 lands15:08
tvansteenburghand then we'll have nothing for 1.2515:08
lazyPowercurrent :latest: will move to a tag for 1.2515:09
lazyPowerand :dev will supplant :latest, and :dev moves to whatever is in the :devel ppa15:09
tvansteenburghlgtm then15:09
lazyPowersweet \o/ progressss15:10
tvansteenburghlazyPower: yeah thanks for doing that15:10
lazyPowerwe were solid with no modifications for 8 months15:11
lazyPowerthats kind of impressive man. it wasn't until beta-1 landed that i had to dig in here and change some things15:11
lazyPowerhey rick_h_ - when i'm bootstrapping with 2.0 beta-1,  i get that env vars make it simple but is there an option for me to pass --config=path/to/aws.yaml to get my cloud keys?15:14
lazyPowerthe cloud credentials file i use for create-model dont seem to work for bootstrap :|15:14
rick_h_lazyPower: yea, you have to write out a .local/share/juju/credentials.yaml file with named credentials in it15:15
rick_h_lazyPower: will get you an example in a sec15:15
Gil"In order to deploy a cs: Trusty charm to an alternate series machine, the charm must be locally branched to a <series>/<charm-name> directory, then juju deployed from that local repo." from link https://github.com/Ubuntu-Solutions-Engineering/openstack-installer/issues/79115:16
Gilis that what I would need to do at this point?15:17
lazyPowerthats an option, or re-bootstrap with a different default-series15:17
GillazyPower changed environments.yaml to "default-series: trusty" then bootstrapped and successfully (as expected) deployed juju-gui.  But then when the bundle "juju-deployer -c https://api.jujucharms.com/charmstore/v4/~openstack-charmers-next/bundle/openstack-lxd-50/archive/bundle.yaml -S -d" is deployed get "Added charm "cs:~openstack-charmers-next/wily/ceph-osd-15" to the environment. + ERROR cannot assign unit "ceph-osd/0" to machine 0:15:45
lazyPowerGil you'll have to modify the bundle to change the placement of ceph-osd15:46
Gilsome solutions would be 1 extra machine for juju-gui or just use the local repo method15:46
lazyPoweryou'll need to co-locate it with another wily based service15:46
beisnerjamespage, fyi - updated the syncs and gh repos yesterday and they're syncing ok.   https://github.com/openstack-charmers/migration-tools/blob/master/charms.txt    +lxd +ceph-osd +percona-cluster15:48
jamespagebeisner, ack - have the git review ready to push again15:49
beisner+ceph-mon that is15:50
beisnerosd was already good15:50
ChrisHolcombecan any unit do a leader set or can only the leader perform that?16:21
roadmrChrisHolcombe: "Only the leader can write to the bucket"16:29
ChrisHolcomberoadmr, darn i was hoping you weren't going to say that haha16:29
roadmrChrisHolcombe: sorry :) straight from the docs: https://jujucharms.com/docs/1.25/authors-charm-leadership16:30
ChrisHolcomberoadmr, ah yeah i missed that line.  thanks :)16:31
jamespagebeisner, hey - could you take a look at https://code.launchpad.net/~james-page/charms/trusty/neutron-gateway/tox8-test-refactor/+merge/28693318:02
jamespageneeded for migration - also some prep for my neutron explosion branches18:02
jamespagebeisner, there was some fairly nasty lack of isolation between unit tests...18:05
jamespagemainly due to massaging of CONFIG_FILES directly - moved to deepcopy + modification now18:05
beisnerjamespage, yah i've been had by copies of dicts in py too.  deepcopy ftw.18:07
beisnerjamespage, want to flip `make test` to the tox method on that?18:16
beisnerand lint18:16
thedacbdx: cargonza tells me you have an active issue that needs looking at?18:53
bdxthedac: hey, yeah, do you mind?18:53
thedacno, what's up?18:53
bdxI have been experiencing an issue where my nova-metadata-api seems to become unavailable after service restart ...18:54
bdxmy instances can talk to initiall after creating tenant networks18:54
bdxfollowing that, if I restart the api-metadata service or reboot the node becomes unavailable to the instances18:55
thedachmm, Could be MTU. Do these hosts have jumbo frames on?18:56
thedacEspectially after a reboot18:56
bdxok, I'm not using jumbo frames. The issue presents itself w/o instance reboot18:57
thedacSo that is my first suggestion. We definitely see problems with metadata when using default MTU of 1500. If at all possible set it on the neutron-gateway and the nova-compute nodes, restart the nova-api-metadata service and check18:58
bdxthedac: after some introspection, I'm not seeing the address or interface on my compute nodes ...18:58
bdxip netns list show only qrouter-283684d1-6e4d-4704-a72e-6fe6acc8e9a618:58
thedacbdx: they don't it is a special address space18:59
thedacIt uses multicast18:59
bdxok, gotcha. Do you know of ways to test for its existance from outside of the instance?19:00
thedacThe best test is on the instnace. But verify nova-api-metadata is listening on 877519:01
thedaclet me double check that port. That is off the top of my head19:01
bdxthedac: also, I'm not seeing the metadata api service show itself here http://paste.ubuntu.com/15182540/19:03
thedacYeah, it does not show up in the service list. So check it on neutron-gateway or if you are doing metadata on the compute nodes check there. 8775 is correct19:05
bdxsudo service nova-api-metadata status19:06
bdxnova-api-metadata start/running, process 432790y19:06
thedacbdx: And this shows up in console-logs as failed access to metadata correct?19:06
bdxthedac: `ps aux | grep metadata` -> http://paste.ubuntu.com/15182600/19:08
thedacok, so I am still thinking MTU19:09
bdxit seems there is a wealth of metadata processes running19:09
thedacYou can test this by running ping with larger and larget packets sizes on the qrouter netns19:09
bdxentirely, ok19:09
thedacping -s 1472 I think19:09
bdx`sudo ip netns exec q-router<#> ping -s 1472` ?19:10
thedacand then with 1473 or higher19:11
thedacoh, sorry19:11
thedacno the IP of the instance19:11
thedacnot the 169.254 address19:11
bdxohh.. ping an instance?19:12
thedacbdx: and regardless our best practice advice is to use jumbo frames in all openstack deploys19:12
bdxthedac: good to know19:15
bdxthedac: my pings are successful19:16
thedacwith > 1472?19:16
thedacok let's check /var/log/nova/nova-api-metadata.log for any tracebacks19:16
bdxI'll check again ... my logs have been clean though19:17
bdxERROR oslo.messaging._drivers.impl_rabbit [req-85055fc4-7de0-46c9-8cc2-119c0eda3430 - - - - -] AMQP server on  is unreachabl19:18
bdxrabbit was actually my initial suspect because I am seeing stale notifications in the rabbit queue19:19
thedacIt is always rabbit ;)19:19
bdxbut hadn't seen any errors yet ..19:19
thedaclovely, ok so sounds like a rabbitmq problem. From a networking perspective can you nc -vz $RABBIT_IP 5672 from the nova-api-metadata host?19:20
thedacThen we can check rabbitmq-server logs19:20
bdxnc -vz 567219:20
bdxConnection to 5672 port [tcp/amqp] succeeded!19:20
thedacok, let's hope on the rabbit instance and check logs19:21
thedacs/hope/hop but also hope19:21
bdxok, just launched an instance, that failed communicating with, rabbit logs show -> accepting AMQP connection <0.3547.1> ( ->
thedacIs rabbit clustered or singleton?19:24
thedacYou might keep the tail on the rabbit log and restart the nova-api-metadata service and neutron-metadata service and see what we get19:25
thedacIt could have been temporary failure19:25
bdxyea, I got a bunch of warning reports for about a second19:27
bdxrabbit seems to be talkin to both services19:28
thedacWhat were the warning messages19:28
bdx=WARNING REPORT==== 23-Feb-2016::19:27:38 ===19:28
bdxclosing AMQP connection <0.19995.0> ( ->
thedacThat could have been the stop of the metadata service depending on timing19:29
thedacso you might test another instance deploy19:29
thedacAnd watch the nova-api-metadata log as well as the rabbit log19:29
bdxit was ... rabbit logs got spammed with that at the time I restart19:29
bdxon it19:29
bdxthedac: yea, no errors in any logs19:33
thedacok, fingers crossed for the instance19:33
bdxneutron-api, neutron-gateway, nova-cloud-controller, nova-compute19:34
bdxall show no errors19:34
bdxinstance gets stuck reaching out for metadata while booting19:34
thedacok, so I am going to keep pushing the MTU issue. metadata is suseptible to it.19:35
bdxI can use the config drive as a workaround to get my user-data on to my instances for the time being ... I just feel this is really fragile though19:35
bdxthedac: so .... If I create two new tenant networks, the instances get metadata just fine19:36
bdxthat are deployed to the new nets19:36
bdxIf I neutron net-delete19:36
bdxand recreate the tenant networks that are affected, metadata works again19:36
thedachmm, ok, that is interesting19:37
thedacdo they subsequently stop working or work indefinitely?19:37
thedacafter a re-create?19:38
bdxthedac: metadata works until I restart the respective services, then stops working until I destroy and recreate again19:38
bdxthedac: I'm suspicious this might be a permissions thing ...19:39
thedacok, and is this liberty?19:39
bdxis the a unix socket?19:39
thedacI'll see if I can recreate this and get back to you19:39
=== blr_ is now known as blr
cory_fukjackal, lazyPower: https://github.com/juju-solutions/layer-basic/pull/3721:25
lazyPowercory_fu - how can i not include some of the project meta files from base like Makefile and such?21:26
lazyPoweri can override that in layer.yaml right?21:26
* lazyPower makes a note to look at the builder readme21:27
cory_fulazyPower: I don't think there's a way to say "remove this file" (bcsaller might be able to correct me), other than just overriding it with an empty file (which isn't the same as deleting it)21:28
lazyPowerah, ok.21:28
cory_fulazyPower: Maybe we need an "excludes" section in layer.yaml?21:28
lazyPowerI think thats a swell idea21:28
cory_fuWhat is your use-case for that, though?21:29
lazyPowerjust so i can say " excludes: readme, makefile, hacking.md - things like that so when i assemble my charm, if i dont have a hacking.md file, i dont have one floating around for one of the runtime layers21:29
cory_fuWhy would you not want those files, though?21:30
cory_fuYou definitely need a README21:31
cory_fuAnd I can't see why you wouldn't also want a HACKING.md and Makefile21:31
magicaltrouti sorta agree with that, i built a charm the other day and committed a load of shit for no reason other than i didn't notice it was in the output21:31
magicaltroutadmittedly I used bzr ignore, but still, it seems like a valid usecase, or maybe bzr ignore is the way to go! :)21:32
cory_fuActually, it looks like layer.yaml might already support an "ignore" list21:33
cory_fuYeah, you can give an ignore list that will do what you want21:34
cory_fulazyPower: ^21:34
lazyPowercory_fu - ballin. I guess you found that in charm-tools docs?21:34
cory_fuAnd it looks like it will work per-layer, so each layer can ignore things from the layer below (if you stack more than once)21:35
cory_fulazyPower: If by "docs" you mean "source"21:35
lazyPowerah, right21:35
lazyPowerone and the same, the tome of charm keeper knowledge21:35
cory_fuYeah, that should be documented, for sure21:35
lazyPowerya know cory_fu - i just realized we didnt put in a reference guide to any of the layer stuff21:36
cory_fuYeah, that would be a good place for this21:37
cory_fuThere's a lot of functionality built in to layer.yaml alone21:37
lazyPowercan we card this and bring it up later this week?21:37
* lazyPower has k8s stuff thats stale and needs cooked21:37
cory_fuWhere would that card go?21:38
lazyPoweri'll take it and put your face on it21:38
lazyPowerthat..sounded way creepier than i intended21:38
lazyPoweranywho, incoming notice21:38
lazyPowerso, word to the wise. series in metadata will make the -stable tooling (bundletester, proof) quite angry as i just found out.22:51
bdxit seems when I deploy my same stack in kilo, then in liberty, my nova-api-metadata changes its location from the dhcp port (kilo), to the network:router_interface_distributed port (liberty). Was this intended? Do you know about it?23:07
bdxthedac, openstack-charmers:^23:07
thedacbdx: hey23:07
bdxthedac: whats up23:07
thedacI just had a liberty deploy up and was testing. I saw no change.23:07
thedacbdx: are you doing DVR for this?23:07
bdxthedac: yeah23:07
bdxthedac: and local dhcp/metadata23:07
thedacOk, that is what I need to test next. I could not re-create the failure. So I will stand up a DVR deploy and keep trying23:07
bdxthedac: so yea, whats going on here is this -> I deploy my same stack in kilo, then in liberty, nova-api-metadata changes its location from the dhcp port (kilo), to the network:router_interface_distributed port (liberty)23:07
=== philipballew is now known as Guest44851
bdxSo in my spinup bash script for creating tenant networks, I did not know/had not updated the network params to reflect the change of nova-api-metadata23:08
bdxi.e for kilo -> neutron subnet-update vlan110-subnet \23:08
bdx  --host_routes type=dict list=true \23:08
bdx  destination=,nexthop= \23:08
bdx  destination=,nexthop= \23:08
bdx  destination=,nexthop= \23:08
bdx  destination=,nexthop= \23:08
bdx  destination=,nexthop= \23:08
bdx  destination=,nexthop= \23:08
bdx  destination=,nexthop=
bdxbut for liberty --> neutron subnet-update vlan110-subnet \23:09
bdx  --host_routes type=dict list=true \23:09
bdx  destination=,nexthop= \23:09
bdx  destination=,nexthop= \23:09
bdx  destination=,nexthop= \23:09
bdx  destination=,nexthop= \23:09
bdx  destination=,nexthop= \23:09
bdx  destination=,nexthop= \23:09
bdx  destination=,nexthop=
thedacbdx: ok, so is that working for you when you changed the route nexthop?23:10
bdxthedac: yea23:10
thedacok, great. I'll figure out why things changed.23:11
bdxthedac: an interesting difference --> in kilo, when you update your subnet, you must include the destination,nexthop for the 169.254 address because the host route for metadata is not automatically appended to the list of new host routes23:12
thedacI was going to ask. We do not add the 169.254 route in our testing.23:13
bdxso in kilo, I can update my subnet, and lose my 169.254 static route if I do not add it to the update23:13
bdxin liberty, the nexthop/destination for metadata is appended to static routes automatically23:14
bdxunless you override it by specifying a user defined route for 169.254 as I was23:15
thedacgot it so, may be a bug in kilo23:15
bdxthanks for your help on this23:17
thedacno problem23:18

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