[04:15] <blahdeblah> Any charmers able to look at https://code.launchpad.net/~paulgear/charms/trusty/ntp/sync-charm-helpers/+merge/276826?
[04:16]  * marcoceppi_ shrugs
[04:16] <marcoceppi_> sure
[04:18] <blahdeblah> thanks marcoceppi_ - should be an easy one; I just wanted to get it out of the way before proposing my second one.
[04:36] <blahdeblah> marcoceppi_: https://code.launchpad.net/~paulgear/charms/trusty/ntp/sync-canonical-is-charms/+merge/276951 is the second one
[04:36] <blahdeblah> thanks for the merge!
[04:37] <marcoceppi_> blahdeblah: it's almost midnight and still Sunday, I'll let this get handled in the queue
[04:37]  * marcoceppi_ sleeps
[04:37] <blahdeblah> np
[08:04] <blahdeblah> Hi all - I've got a question about the juju-info implicit relation.  When we "nova floating-ip-associate $MACHINE $IP" in an OpenStack environment, juju status eventually works out that $IP is the public address, but that doesn't show up in the relation data returned from relation-get.  Why?  How can I get access to this information from within the charm?
[08:13] <gnuoy> jamespage, https://code.launchpad.net/~gnuoy/charms/trusty/odl-controller/amulet/+merge/276959 I'm investigating amulet fails for > trusty atm
[08:18] <stub> gnuoy: _initialize_tests has a whole heap of unit/0's hardcoded, and there may no longer be a unit/0
[08:18] <gnuoy> stub, there may no longer be a unit/0 ?
[08:19] <gnuoy> I must be missing an exciting new development
[08:19] <stub> Yes, with Juju 1.25 unit numbers stopped being recycled. So your first unit will not be unit 0 if the environment previously had a service using the same name.
[08:20] <gnuoy> ack, thanks for the tip
[08:20] <stub> https://code.launchpad.net/~stub/charms/trusty/cassandra/spike/+merge/276372
[08:22] <gnuoy> stub, even better , thanks for the fix!
[08:22] <stub> Share it around, its going to bite every non-trivial set of Amulet tests ;)
[10:00] <jamespage> dimitern, morning - nice picture ;-)
[10:00] <jamespage> http://blog.naydenov.net/2015/11/deploying-openstack-on-maas-1-9-with-juju-network-setup/
[10:00] <jamespage> thanks for the credit btw :-)
[10:01] <dimitern> jamespage, hey :) yeah - I'd like to give credit where it's due
[10:01] <dimitern> jamespage, thanks
[10:02] <jamespage> dimitern, great replay on our conversations btw
[10:02] <dimitern> jamespage, there are still some unresolved points, but it's shaping up I think
[10:02] <jamespage> dimitern, yup
[10:03] <jamespage> dimitern, so I think that thedac will be on point from my team to work on this - gnuoy is going on holiday for december afaict
[10:03] <gnuoy> haha, I'm around but lots of holiday dotted around the place
[10:17] <gnuoy> jamespage, any idea when python-networking-odl will be in the cloud archive for kilo and liberty?
[10:18] <jamespage> gnuoy, its already there
[10:18] <gnuoy> jamespage, argh, sorry. I'm looking at a vivid deploy so no cloud archive
[10:19] <gnuoy> jamespage, is it on its way to vivid?
[10:19] <jamespage> gnuoy, actually vivid did not get that enablement
[10:19] <jamespage> gnuoy, only the CA
[10:19] <jamespage> gnuoy, I don't think we'll do vivid
[10:19] <jamespage> its high cost, with no users as far as I'm concerned
[10:19] <jamespage> we can use the UCA for hardware enablement stuff like this
[10:20] <gnuoy> jamespage, ok, so the amulet tests for odl-controller can just be trusty?
[10:20] <jamespage> gnuoy, for now yes that's fine
[10:54] <sto> I'm deploying openstack liberty with juju using the same configuration I used for kilo and it looks that the neutron-gateway charm does not install the neutron-dhcp-agent ... is that intentional?
[10:55] <sto> With the current deployment my openstack nodes have no dhcp service
[10:55] <sto> BTW, if this is not the right irc channel a pointer to the right one will be appreciated
[12:08] <jamespage> sto: that's not intentional, but not something I've seen either in my testing
[12:08] <jamespage> (and this channel if fine for openstack charms + juju stuff)
[12:09] <jamespage> sto: can you tell a bit more about your deployment?  output of juju status might be good for a start
[12:14] <sto> jamespage: I'm re-deploying it now to have a clean installation, I'll send you a pastebin once deployed
[13:09] <gnuoy> jamespage, https://code.launchpad.net/~gnuoy/charms/trusty/odl-controller/amulet/+merge/276959 is ready for review. I can remove the systemd stuff if you want.
[13:41] <gnuoy> jamespage, I missed a ch change to support the previously mentioned branch https://code.launchpad.net/~gnuoy/charm-helpers/exlude-no-openstack-origin/+merge/277005
[13:57] <ddellav> jamespage, here's the link to the neutron port security MP again from friday in case you missed it: https://code.launchpad.net/~ddellav/charms/trusty/neutron-api/ml2-port-security/+merge/276764
[13:58] <ddellav> for some reason tests don't seem to have run, i must have disabled them somehow, I'll fix it.
[14:01] <jamespage> ddellav, looking now
[14:03] <jamespage> ddellav, couple of comments
[14:05] <ddellav> jamespage, got it, fixing.
[14:09] <jcastro> marcoceppi_: hey, wrt. charm-tools and all our associated tooling, did you see barry's plan for python3 only in main for 16.04?
[14:10] <jamespage> jcastro, erm python3 only in the iso
[14:10] <jamespage> not quite the same thing as python3 only in main
[14:11] <jcastro> ack
[14:13] <jcastro> acutally I said that entirely backwards, what I should have said is "hey are we ready for distros to drop python2"
[14:19] <jcastro> http://askubuntu.com/questions/693945/openstack-dashboard-instance-console-unavailable
[14:19] <jcastro> I've got some openstack questions that need to be scrubbed if people want to check them out
[14:32] <Odd_Bloke> So I'm trying to configure Juju (1.22.8) to use an HTTP proxy and (a) I'm seeing that I can't configure an HTTP proxy but _not_ an apt HTTP proxy, and (b) that the OpenStack provider attempts to use the configured proxy for OpenStack API calls.
[14:33] <Odd_Bloke> Are either of these things fixed/changed in more recent versions, or shall I report bugs?
[14:35] <beisner> Odd_Bloke, that is a thing for sure.  in my experience, the only way to get endpoint http/https traffic to not proxy api calls, is to set no_proxy to include every possible endpoint IP.  note, no_proxy doesn't understand cidr.
[14:52] <beisner> hi gnuoy, i've added odl/amulet MP comments.  holler with any ?s.  thanks!
[14:54] <marcoceppi_> jcastro: yes
[15:16] <sunitha> Hi
[15:18] <sunitha> i want to discuss about IBM XL Fortran charm review comments, which we recieved recently
[15:20] <sunitha> Hi Matt
[15:20] <mbruzek> Hello
[15:20] <sunitha> The charm must cryptographically verify all downloaded software. Line 125 of hooks/config-changed will skip the cryptographic check if the sha_fortran configuration variable is an empty string (which is default).
[15:21] <mbruzek> yes
[15:21] <sunitha> This is about Ibm XL fortran charm
[15:21] <mbruzek> Yes, I am watching this channel now that you said my name.
[15:21] <mbruzek> I recall the review.
[15:22] <sunitha> actually till now we were doing for all the charms as if user provides some value for cryptographic check, it will check, if user has not provided any thing it will ignore
[15:24] <mbruzek> sunitha: A charm can not skip the crytpographic check.  The way I read the code if the sha_fortran configuration value was NOT set then the software would not be verified.
[15:25] <sunitha> yes
[15:25] <mbruzek> sunitha: I see people just leaving that value empty when they deploy the charm (because empty is default)
[15:26] <mbruzek> So by default the charm will never check the cryptographic signature.
[15:26] <mbruzek> unless the user sets the sha_fortran value.
[15:27] <mbruzek> sunitha: You don't have to write code to verify payloads that are already inside the charm.  This is why I highly suggest putting the xl fortran payload inside the charm.
[15:27] <sunitha> now you want us to specify default  package value there?
[15:28] <mbruzek> sunitha: no. But you can not skip the validation if the value is empty.
[15:29] <sunitha> but if i keep build inside charm user can deploy charm for only specific version
[15:29] <sunitha> he cannot use for another build version
[15:30] <mbruzek> sunitha: How often is this xl fortran package updated?
[15:31] <mbruzek> sunitha: many charms make use of this pattern (putting the binary inside the charm).  Only the IBM charms require downloading the binary and putting inside the charm.
[15:32] <mbruzek> sunitha: I suspect there is not much activity on the Fortran binary.
[15:32] <mbruzek> but if there is, you can either update the charm, or write in the README how the user can update.
[15:33] <mbruzek> sunitha: I see the BASH code looks for *tar.gz anyway so in theory the user could replace with the new version.
[15:33] <mbruzek> Before they deploy .
[15:37] <sunitha> Matt: In last 6 months they updated with 2 fix packs
[15:38] <mbruzek> I still highly suggest putting the binary inside the charm, it makes it way easier to deploy the charm.
[15:39] <mbruzek> much easier user experience
[15:40] <sunitha> ok I will keep this inside charm only
[15:41] <sunitha> and one more thing about license
[15:41] <sunitha> with out setting license value , prouct uninstall will not happen
[15:42] <sunitha> if user want to uninstall the software..
[15:43] <sunitha> if i remove license parameter, how user will uninstall the software?
[15:43] <mbruzek> yes I understand
[15:44] <mbruzek> the license needs to be accepted
[15:48] <sunitha> matt:I cannot add any relations to this , since it is a stand alone and its just a compailer, using this user can develop applications in power linux systems.
[16:09] <mbruzek> sunitha: that is unfortunate, it really limits the usefulness of the charm.
[16:10] <mbruzek> sunitha: please consider the merge proposal I made to improve the README.md file.  If you do end up putting the file inside the charm the README.md file will need to be edited to remove the apache server, and perhaps tell the user how to put a new binary in the charm.
[16:13] <mbruzek> sunitha: regarding the uninstall:  The user does not need to uninstall the software.  If fortran is the only thing on the instance then when the user is done they would just shutdown/destroy the instance.
[16:15] <mbruzek> sunitha: uninstall:  If you mean how would the user uninstall the software when the license was no longer accepted that code would not change.  You can still remove it from /opt/ibm/.... so they can not run the fortran compiler any longer.
[16:23] <sunitha> Ok .Thanks Matt.
[18:16] <jcastro> cory_fu: bcsaller: So adam did a ghost charm with reactive
[18:16] <jcastro> and I started thinking, and it may be dumb but I'd like to think aloud for a minute
[19:51] <bdx> hey whats going on everyone? When specifying "JUJU_DEV_FEATURE_FLAGS=address-allocation" it seems my deploy is blocked after the first 3 devices are allocated ips see -> http://cl.ly/image/2o292Z3g1F3Q
[19:52] <bdx> I have verified this multiple times now......I'm sure you guys are already all over this though....
[20:37] <lazypower> bdx o/
[20:38] <lazypower> bdx - make sure you follow up with a bug on that please. It helps when tracking issues like this - if its a duplicate we can link the issues and track in a singular location
[20:46] <bdx> lazypower: I did
[20:46] <lazypower> bdx: ta :) appreciate the diligence in feedback
[20:47] <bdx> lazypower: of course!