[00:03] wallyworld: looking :D [00:05] wallyworld: there is nothing to do with regards to pricelist and stuff that axw did before holidays?.. [00:05] anastasiamac: otp, sec [00:05] anastasiamac: that pricelist stuff is orthogonal [00:06] you can bootstrap just fine [00:06] wallyworld: lgtm'ed [00:06] ty [00:07] Bug #1634289 opened: new AWS region: us-east-2

[00:17] wallyworld: i seem to recall u had a cunning plan to specify what machine gets picked from maas based on some user desire... where is it at? [00:23] time to take the dog for a wander === thumper is now known as thumper-dogwalk\ === thumper-dogwalk\ is now known as thumper-dogwalk [00:26] alexisb: if u have a sec, I'd love ur advice on something [00:34] anastasiamac: sorry, was otp. we have had the ability to use maas agent as a placement directive. that's been there for a while. not sure if that's what youo mean [00:38] wallyworld: https://bugs.launchpad.net/juju-core/+bug/1345440 [00:38] Bug #1345440: add-machine does not check for duplicates

[00:39] anastasiamac: right, that's what I think the agent name placement directive is used for [00:39] but i'm not 100% [00:39] would need to look at the code [00:40] wallyworld: i know it's an old bug, but if u could comment on it with what you know currently, i'd really really apreciate [00:40] (like coffee-worthy appreciate \o/) [00:40] ok, i'll need to do it later today after i look at the maas code [00:40] \o/ [00:41] i guess, i'll pay coffee in credit then ;D [01:12] anastasiamac juju wait was owned by stub iirc [01:21] anastasiamac, fyi, I gave wallyworld a task that may prevent him for having time to update lp 1345440 today === thumper-dogwalk is now known as thumper [03:03] lazyPower: tyvm \o/ [03:04] alexisb: ack [03:08] damn [03:08] can't deploy anything from the charmstore with beta 7 as I get unknown channels [03:08] and juju panics [03:08] * thumper sighs [03:09] thumper: I think beta13 is the oldest that can be used to deploy from charmstore (I hit this a little while back :-|) [03:10] * thumper grabs marcoceppi's ubuntu charm directly from github [03:11] * thumper hopes it deploys locally into beta 7 [03:12] well... something is happening [07:19] anastasiamac, did you see my comments about juju-1-switch [07:19] yes, u r awesome: marked as duplicate [07:19] balloons: i was also told that u have a plan \o/ [07:19] Bug # opened: 1577556, 1592887, 1597318, 1614633, 1615986, 1616149, 1616832 [07:20] anastasiamac, it seems like juju-1-switch should have worked or>> [07:20] anastasiamac, the update-alternatives issue can be solved, but I'm afraid the juju-1-swith command still won't work [08:43] frobware: ping [08:43] dimitern: pong [08:43] dimitern: your PR is on my list [08:43] frobware: I've forked your kvm-maas repo and I'm close to sending a PR your way to handle multiple networks [08:44] dimitern: I have a PR pending for that too. :) [08:44] frobware: yeah, a final look on my PR will be good at some point ;) [08:45] frobware: nice ;) we could integrate the approach later I guess? [09:25] frobware: there it is - even works :) https://github.com/frobware/kvm-maas/pull/1 [09:28] dimitern: \o' ok, entering review mode now. first up is your net port prober. [09:28] frobware: cheers [09:31] dimitern: ah, actually need to raise a bug first. :/ [09:33] np :) [10:27] dimitern: reviewed. just a few comments. [10:28] frobware: tyvm! [10:34] frobware: updated to use conn.Close() instead of defer conn.Close() [10:35] dimitern: close early, close often. :) [10:36] frobware: yeah - originally I had it like this because the results chan was unbuffered, now it doesn't matter [10:39] ow ffs! maas 1.9 DNS can resolve only its nodes' hostnames, not its own hostname :/ [10:45] frobware: oops sorry - I didn't see your "outdated" comments [10:46] frobware: compromise? ReachableHostPort() ? [10:48] or even SelectReachableHostPort [10:48] dimitern: yep, prefer Reachable. [10:48] dimitern: first of your alternatives. [10:48] frobware: ok, pushing in a momemnt. [10:49] dimitern: less words. select.. what? ;) [10:51] morning [10:54] frobware: :) [10:57] https://github.com/juju/juju/pull/6465 <-- dimitern, frobware, voidspace instead of messing with hostnames, just reverting an earlier change. Seems like something else fixed the container DNS issue. [10:59] dooferlad: LGTM [11:01] dimitern: I didn't get to your review yesterday, did you get one? [11:01] voidspace: I got one from frobware, but feel free to have a look :) [11:03] dimitern: you have the link handy? [11:03] voidspace: https://github.com/juju/juju/pull/6454 [11:04] dimitern: I was trying your kvm-maas PR - "error: could not determine IP address for PXE network br-enp1s0f1 br-enp1s0f0[0]'" [11:04] dimitern: need to investigate a bit [11:08] frobware: where is that? kvm-maas-add-node ? [11:08] dimitern: not sure; flipping between too many things, but yes, my first add-node failed. [11:08] voidspace: sorry, just pushed the last change related to frobware's review [11:08] dimitern: whilst you're feeling talkative... [11:09] dimitern: I'm diagnosing issues with vsphere and xenial. Any unit gets an fe::80 address (or similar) - which is machiine local ipv6 [11:09] frobware: why "br-enp1s0f1" ? I'd expect to see e.g. virbr42 instead (well in my case bridge-name==virt-net-name) [11:09] dimitern: and from my logging, as far as I can tell machine addresses are *never* set [11:09] dimitern: so juju/vsphere/xenial is unusable [11:09] dimitern: do you have suggestions as to my next step in debugging [11:10] dimitern: the machines get ipv4 addressses from vsphere [11:10] voidspace: fe80:: addresses are link-local ones [11:10] dimitern: right, link local [11:10] dimitern: I can't ssh to the machine via juju [11:10] voidspace: they always exist when ipv6 is enabled - so somewhere we're not filtering them properly [11:10] voidspace: is vsphere/trusty usable? [11:10] frobware: yes [11:11] voidspace: last time I looked at this I could only do *anything* on vsphere as long as it was trusty [11:11] dimitern: it's not that we're not filtering - we don't have *any other addressess* for the machin ein state [11:11] frobware: I believe that's still the case [11:11] voidspace: ah.. well if that's the case something is quite broken [11:11] dimitern: at least that's my current conclusion - adding more logging to confirm [11:11] dimitern: yep :-) [11:11] voidspace: on the provider side I'd guess [11:11] rick_h_: ping? [11:12] dimitern: pong [11:12] rick_h_: should we do our 1:1? [11:12] dimitern: I'm there [11:12] rick_h_: ok, omw [11:12] dimitern: yep, agreed - but it maybe a problem with provisioning xenial images on vsphere [11:12] dimitern: I'd like to get into the machine to see [11:13] dimitern: will try the controller machine as I can contact the state server [11:13] dimitern: http://paste.ubuntu.com/23343319/ [11:13] dimitern: haven't looked into why [11:13] voidspace: let me get back to you a bit later [11:13] dimitern: sure [11:26] frobware: found it! pushing update to the PR [11:30] voidspace: if you can ssh into the controller, what address(es) did you use? [11:30] dimitern: just hacking up some more logging, trying again shortly - will let you know [11:30] voidspace: ok [11:32] Bug #1324841 changed: Improve isolation in utils/file_test.go [11:32] Bug #1325837 changed: juju run is updating ~root/.ssh/known_hosts

[11:39] dimitern: closer... http://paste.ubuntu.com/23343396/ [11:41] dimitern: ahhh [11:41] dimitern: that's because my virt-network is now a bridge. Ho-hum. [11:44] frobware: yeah - I use the same names for the bridge and the network; btw pushed another [11:45] dimitern: different, my virt net work definition is actually a bridge. http://paste.ubuntu.com/23343406/ [11:46] dimitern: for that kind of definition this virt_network_address()" will always fail [11:47] frobware: that looks almost the same as what I have locally, e.g. http://paste.ubuntu.com/23343418/ (for maas-int19) [11:48] dimitern: but you have 'ip address=1.2.3.4' [11:48] frobware: ah, because it's a bridge without an address [11:48] yep [11:48] dimitern: it's actually the hosts bridge (which does have an address) [11:49] .query stgraber [11:49] dimitern: I think that's a separate commit/fix/enhancement. when I first started doing this I only need libvirt-derived bridges. Now I want them on my various VLANs [11:49] frobware: re https://github.com/juju/juju/pull/6454 - good to land? [11:50] dimitern: yep [11:50] dimitern: thanks all around [11:52] frobware: cheers! [11:53] jam: are you around? [11:53] dimitern: I wonder whether we should just paas the QEMU connection string as an argument. [11:54] frobware: there are 2 of those actually - from the host POV and maas's POV [11:54] dimitern: are they not the same? [11:54] frobware: nope [11:55] dimitern: well, I guess that really depends on your initial MAAS setup. My MAAS setup always connects as 'me' to the host. [11:55] frobware: the former can be qemu:///system as a sane default, while the other is likely different, with qemu+ssh://$USER:$PXE_IP/system being a reasonable default, except if it's not :) [11:56] dimitern: they are essentially always the latter, no? [11:56] dimitern: or it can just degenerate to the latter [11:56] frobware: I used qemu+ssh://maas:$IP/system before, as I had a maas user only the vmaas-es can use to ssh into my laptop [11:56] dimitern: if MAAS can do power-on/off, then you can use the same string to add/remove-node [11:57] frobware: if you're calling virsh locally, qemu:///system is assumed to be what you'd want [11:57] frobware: however, overriding it is useful if you're e.g. setting up a remove kvm host [11:58] in which case it's likely to be the same inside the vmaas host as well (assuming it's configured ok) [11:58] dimitern: I never tried that, but I think it is a reasonable thing to assume would just work. [11:58] I was thinking of adding a simple check that qemu+ssh://$USER:$PXE_IP/system is reachable from the local host [11:59] dimitern: I think I'm going to make it a required arg. A bit sucky, but less magic. [11:59] but really we need such a check more importantly for the vmaas host [11:59] dimitern: that would happen in kvm-maas-host - a new repo to setup MAAS controllers. [11:59] dimitern: or, I combine them. [11:59] frobware: as long as it can be exported once and then used in the same shell - sure [12:00] frobware: yeah, I forked that one as well :) nice work so far - haven't tried it though [12:00] dimitern: wouldn't bother. fundamentally broken until cloud-init is fixed. [12:02] frobware: oh, too bad :/ [12:02] dimitern: for reference, it is bug #1576692 [12:02] Bug #1576692: fully support package installation in systemd

(Ubuntu):Fix Released by pitti>

[12:02] frobware: I see though you've thought about allowing lxd-based maas-es to be deployable - nice [12:03] frobware: well, I can see cloud-init 0.7.8-1... in xenial-updates now [12:04] * frobware notes that this is now fix-released. [12:04] frobware: so I'll give it a try later today [12:04] dimitern: the focus is still wrong. We need to drive this from a network spec. [12:06] * frobware lunches [12:20] mgz, balloons: how often/when does github-merge-develop-to-staging run? [12:29] Bug # changed: 1325946, 1329256, 1329480, 1329578, 1331691, 1332048, 1365665 [12:43] Hey guys! A local charm failed is failing on install hook. I fixed it, updated the charm and marked it as resolved. But on debug-log I see that it is still using the old install-hook. How can I force it to use the new code? [12:45] dimitern, it runs whenever there is a bless on develop [12:45] dimitern, I believe there was a bless this morningish? [12:46] balloons: ah, I see - ok [12:46] balloons: I was wondering how a multi-PR fix will work if some PRs land in staging from develop before others [12:50] dimitern, the ci run should fail if it gets picked up [12:50] and thus, it shouldn't hit staging until it's all ok [12:52] balloons: right.. or if it doesn't fail, the later PR in the pipeline could be based on staging + cherry-picked PRs yet-to-land on staging [12:52] s/the later PR/the later PRs/ [12:53] dimitern, the need for rebasing might happen; see the discussion on the mailing list about this [12:53] but from a job perspective, you understand what will happen now :-) [12:54] balloons: yeah, cheers :) [12:59] Bug # changed: 1365675, 1368254, 1369638, 1369900, 1369909 [13:11] Bug #1373592 changed: When bootstrapping or deploying dont spec zone

[13:11] Bug #1373768 changed: Juju doesn't inform users when MAAS is out of nodes

[13:11] Bug #1375110 changed: "maintenance in progress" detection in the API server needs improving

[13:27] help for debug-log shows --tail and --no-tail as arguments, yet they don't seem to be defined [13:28] hmm, they are on my local box - yet not on the remote one using the same (allegedly) version of juju [13:28] gah, my fault [13:29] "juju help debug-log --no-tail" doesn't work, perhaps unsurprisingly [13:38] dimitern: I see this in the logs: provider addresses: []state.address{state.address{Value:"fe80::1", AddressType:"ipv6", Scope:"public", Origin:"provider", SpaceName:""}, [13:39] dimitern: so at some point we're getting an address with value fe80::1 come in with a Scope of "public" [13:39] dimitern: which is why we're setting it as a public address [13:39] voidspace: right! [13:40] voidspace: I remember seeing something nasty like using network.NewScopedAddress(..., network.ScopePublic) in the vsphere provider [13:40] dimitern: some smoking guns from the logs: http://pastebin.ubuntu.com/23343774/ [13:40] to fake some address as a public one [13:40] dimitern: I will hunt that out [13:40] dimitern: ouch [13:41] dimitern: yep, environInstance.Addresses makes addresses public [13:41] Bug # changed: 1375268, 1376576, 1380659, 1380989, 1382063, 1382276, 1383260, 1384013, 1384336, 1384348, 1384369 [13:41] dimitern: provider/vsphere/instance.go:58 [13:41] dimitern: shall I just change that to always use a derived scope instead of the two explicit scopes? [13:42] dimitern: in fact dammit, I'll just try it [13:44] dimitern: if Type was a method and we *always* derived it then we wouldn't have this issue [13:45] voidspace: let me have a look [13:46] dimitern: I've made the change and I'm just scp'ing the binaries up to try it [13:46] dimitern: only takes ten minutes [13:46] dimitern: although, please look to see if there's any reason why we shouldn't rely on a derived scope there [13:46] hi . we developed "cinder-storage driver charm. We want to install "git" not as part of install hook. But someone suggested "layer apt". In my charm folder I created layer.yaml file as pasted. http://paste.openstack.org/show/586196/ [13:47] when layer.yaml will execute? [13:47] natefinch: ping [13:47] Bug #1384549 changed: Running Juju ensure-availability twice in a row adds extra machines

[13:47] Bug #1385277 changed: malformed urls as environment variable values need to be handled better

[13:47] Bug #1386222 changed: Usability: machine provisioning timeouts

[13:48] Before install script (or) after install script? [13:48] voidspace: yeah, I think we should be using NewAddress() instead of NewScopedAddress() there [13:48] dimitern: bootstrapping now [13:48] dimitern: thanks [13:49] could anyone help me in this. [13:49] voidspace: it's commendable that whoever implemented the provider tried to convey the public vs. private distinction to juju with the scope, but ... [13:49] rick_h_: howdy [13:49] dimitern: yep, "but" [13:49] dimitern: hah, and with that change no tests fail... [13:50] or at least, no vsphere provider tests fail [13:50] natefinch: can you do me a fav please? Can you generate a new fallback-clouds.yaml file with the change ian landed overnight and get it to abentley to test out please? [13:50] voidspace: sweet! :) [13:50] rick_h_: sure [13:50] natefinch: ty [13:50] dimitern: well, either sweet or it was just untested.... [13:50] dimitern: hopefully they pass because using a derived scope is the right thing anyway... [13:52] dimitern: Hi. do you have any idea on my question? please tell me if you have. [13:56] rock_: try over in #juju. they usually discuss the charming side of things much more. marcoceppi or lazyPower may be able to help [13:56] rock_: or cory_fu [13:56] Bug #1384549 opened: Running Juju ensure-availability twice in a row adds extra machines

[13:56] Bug #1385277 opened: malformed urls as environment variable values need to be handled better

[13:56] Bug #1386222 opened: Usability: machine provisioning timeouts

[13:56] katco: Thanks. [13:56] dimitern: all machines started, all have ipv4 addresses, can ssh to them [13:57] rock_: this channel is more for developers of juju itself [13:57] rick_h_: found and fixed the vsphere ipv6 bug (need a PR and tests of course - but verified the fix) - with a bit of help from dimitern as usual [13:57] rock_: Hey. I'm glad to help. [13:58] voidspace: <3 [13:59] voidspace: dimitern frobware macgreagoir natefinch mgz ping for standup [13:59] cory_fu: Hi. Hi. we developed "cinder-storage driver" charm. Our charm dependent on Github. During the execution of the charm it will go and get latest files from Git and it will keep those files in cinder node. We will deploy our charm post deployment of Openstack setup. So during execution of our charm it was giving "git ERROR"[Like git is not there]. [13:59] rock_: The apt layer will install that package more or less the first chance it gets. Generally, this will mean during the install hook, though it can sometimes actually happen even earlier (due to leadership, storage, etc). Essentially, as soon as the reactive framework is bootstrapped and the apt layer sees that the package has not yet been installed. [14:00] rock_: That also applies to any of your own reactive handlers that don't have any other unsatisfied pre-conditions (e.g., @when decorators) [14:01] rock_: So, what you'll want to do, is ensure that the code that depends on the "git" package being installed has a @when('apt.installed.git') decorator on it. There's an example of this usage in the apt layer README: https://git.launchpad.net/layer-apt/tree/README.md#n69 [14:02] rock_: (That example also uses reactive code to perform the initial package install, but you can just as easily use the layer.yaml option definition if there are no conditions or other prerequisites that must be satisfied *before* installing the git package) [14:02] cory_fc: Thanks. Yes I saw this. But before install script oonly I need to install that git package. [14:03] rock_: Right. So just ensure that your initial "entry point" handler (i.e., the one with minimal or no pre-conditions) does at least have the precondition of @when('apt.installed.git') [14:04] rock_: Let me see if I can find you a more concrete example [14:04] cory_fc: I am new to this. didn't get [14:05] cory_fc: better I need to clear you with my requirement [14:05] Bug #1384549 changed: Running Juju ensure-availability twice in a row adds extra machines

[14:05] Bug #1385277 changed: malformed urls as environment variable values need to be handled better

[14:05] Bug #1386222 changed: Usability: machine provisioning timeouts

[14:09] cory_fu: If we have juju openstack setup. when we deploy our charm and added relation to cinder, then my charm will go and get our cinder-storage driver files from Git and keep them on cinder node. But before cloning from git it was giving "git ERROR". So we need to install git package not as part og install hook. [14:09] rock_: Hrm. All of the examples I can find use the apt.queue_install() method in the code, rather than the layer.yaml option, but it's functionally equivalent. I think the README is probably the best example, in that case, just know that you can substitute the layer.yaml option for lines 77-79 and it will behave the same [14:11] rock_: When using reactive, the idea is to think about the life-cycle less in the terms of hooks, and more in terms of what are the pre-conditions of the block of code (single function / handler) that you're concerned about. In your case, you have a handler which uses git, and so that block of code needs to be decorated with @when('apt.installed.git') and then it will always be delayed until that dependency is met. [14:12] That will likely still happen during the install hook, though, because it can really happen as soon as the apt package is done being installed. [14:12] Unless it has other pre-requisites, such as depending on the relation, as you mentioned, in which case it needs to have more conditions specified in its @when decorators [14:12] cory_fu: I developed my charm using shell script. [14:14] rock_: That's fine. You can use the reactive pattern with bash. Here is an example, although it doesn't use the apt layer: https://github.com/juju-solutions/layer-openjdk/blob/master/reactive/openjdk.sh [14:16] rock_: The main things to note with that are the "source charms.reactive.sh" at the top, and "reactive_handler_main" at the bottom. [14:17] Otherwise, it's similar to any other reactive example in that you define a set of functions and decorate them with the pre-conditions that are required for each one to be able to run [14:17] Bug # changed: 1260247, 1262750, 1263196, 1267298, 1268917, 1270041, 1270858, 1270896, 1271502, 1271504, 1330473, 1386494, 1386926, 1389303, 1389324, 1389418, 1390284, 1391353 [14:17] Those pre-conditions depend on states (flags) that are set either by other handlers in your layer, or by other layers that you depend on. [14:18] cory_fu: what layer-git-deploy will do? [14:20] core_fu: I am little bit confusing. where to add and what to add? [14:21] rock_: I had not seen that layer yet. To be honest, I'm not sure that it is complete. Perhaps bdx (James Beedy) will chime in? [14:23] core_fu: Ok Thanks. Simply, What I need to add to my charm to install git package? sorry, really these layer terms are very new for me. [14:24] rock_: If you haven't read through it yet, https://jujucharms.com/docs/stable/developer-layers covers the basics of layers and states to give you a better foundation. [14:25] rock_: As for your specific question, I think that using the "apt: packages: [git]" in your layer.yaml as you mentioned initially, and adding a @when('apt.installed.git') decorator around the code that uses git should be all you need [14:26] Bug #1271923 changed: using lxc containers with maas provider always default to series of host service unit

[14:26] Bug #1273216 changed: unknown --series to add-machine breaks provisioner

[14:26] Bug #1274450 changed: VM locale handling

[14:26] rock_: This all presupposes, of course, that you're writing your charm using layers and reactive, which we recommend, but is a very different style than writing traditional charms, in that you don't write the individual hooks directly, just reactive handlers that have preconditions. [14:29] core_fu: Oh. Actually I written my charm in a traditional way. So for installing "git" package only I asked in Chat. One guy suggested "layer apt". So I am asking about this. [14:29] rock_: If you're writing your charm using the classic approach and creating your hooks yourself, then you can't use the apt layer, have to call apt-get install yourself, and must manage ensuring the ordered execution of your code yourself with the understanding that hooks are inherently life-cycle events and not procedural code paths. Thus, I can promise that that approach can get difficult quite quickly [14:29] rock_: We recommend writing all new charms using layers and reactive because it makes dealing with these exact coordination issues much, much easier [14:30] rock_: I have to step away for a few minutes for a meeting, I'm afraid. I will try to continue to respond, but may be slower for a little while [14:31] core_fu: Oh. OK. thanks for your help. One final question please. [14:33] core_fu: We already used classic approach right. I will follow this. Because we have to deliver this charm quickly to the client. So at present situation I will use "apt-get install git" in install script of hook. This will be fine right? [14:35] Bug #1271923 opened: using lxc containers with maas provider always default to series of host service unit

[14:35] Bug #1273216 opened: unknown --series to add-machine breaks provisioner

[14:35] Bug #1274450 opened: VM locale handling

[14:46] gah..... why oh why does pastebin.ubuntu.com want me to log in with SSO to download the plaintext of a pastebin that I can see without logging in? Geez. [14:47] Bug #1271923 changed: using lxc containers with maas provider always default to series of host service unit

[14:47] Bug #1273216 changed: unknown --series to add-machine breaks provisioner

[14:47] Bug #1274450 changed: VM locale handling

[14:48] abentley: new fallback-clouds.yaml http://pastebin.com/raw/rnxGWLjB [14:48]