| axw | nurfet: ok, cool. at the moment, the ubuntu user is hard-coded throughout the codebase. I think it would be difficult to change that now, so your provider would need to create the ubuntu user | 00:00 |
|---|---|---|
| axw | nurfet: will your provider not rely on cloud-init? | 00:00 |
| nurfet | I see. no my provider does not support cloud-init at the moment | 00:01 |
| axw | nurfet: I have to go, will be back in an hour or so if you still have questions. otherwise thumper or wallyworld may be able to assist | 00:05 |
| nurfet | axw: thanks | 00:10 |
| thumper | well... fuck | 00:49 |
| perrito666 | Good morning to you too thumper | 01:20 |
| thumper | o/ | 01:20 |
| redir | is it morning already | 01:21 |
| perrito666 | Not for me I just found funny the first thing I read from | 01:21 |
| perrito666 | Thumper | 01:21 |
| redir | I'm gonna give up soon | 01:21 |
| redir | for the day. | 01:21 |
| perrito666 | Ahhggg i hate phone kb | 01:21 |
| thumper | :) | 01:22 |
| perrito666 | I was just passing by | 01:22 |
| redir | now I can't deploy because the maas can't see resolve simplestreams host. | 01:22 |
| * redir eods | 02:09 | |
| redir | looks like it is still having trouble fetching the image from simplestreams | 02:10 |
| thumper | wallyworld: https://github.com/juju/juju/pull/6854 | 03:13 |
| wallyworld | you want a review? ok | 03:14 |
| thumper | please | 03:15 |
| wallyworld | thumper: +1, jeez why is arm so sloooooow | 03:16 |
| thumper | reasons | 03:16 |
| veebers | wallyworld: Is there an easy way to grab what series a controller is running? Or will it be the ol' "juju ssh lsb-release..."? | 03:53 |
| wallyworld | it might be in status, can't recall ottomh | 03:53 |
| veebers | wallyworld: ack I'll poke. Cheers | 03:56 |
| veebers | ah it totally is | 03:57 |
| wallyworld | axw: i'm having an issue with some azure unit tests. but maybe i should also validate the approach i'm using. did you have time for a HO? | 05:14 |
| axw | wallyworld: just finishing my lunch, in a short while | 05:15 |
| wallyworld | ok | 05:15 |
| axw | wallyworld: ready, see you in 1:1 | 05:21 |
| wallyworld | axw: here's the WIP https://github.com/juju/juju/compare/develop...wallyworld:azure-ingress-rules?expand=1 | 05:21 |
| axw | wallyworld: should be fine. limit is 80 characters: https://docs.microsoft.com/en-us/azure/guidance/guidance-naming-conventions | 05:46 |
| wallyworld | great ty | 05:47 |
| wallyworld | i have tests passing now, just need t add some more | 05:47 |
| wallyworld | axw: that PR is now up. much of it is cleanup https://github.com/juju/juju/pull/6855 | 06:10 |
| axw | wallyworld: OK, will look shortly | 06:10 |
| wallyworld | no rush ty | 06:10 |
| axw | wallyworld: what are the rules for grouping ingress rules, if any? as it is, there's no guarantee that IngressRules is going to return the rules with the same grouping as they were opened | 06:38 |
| axw | wallyworld: e.g. I might open port range 1000-2000, and later 2000-3000; then IngressRules will report them as one | 06:39 |
| axw | oh wait | 06:39 |
| axw | never mind... | 06:39 |
| wallyworld | axw: i am sure i read somewhere in our code that we do not allow overlapping ort ranges | 06:39 |
| wallyworld | i think if we do need to cater for that sort of thing, it needs to be done in the firewaller worker | 06:40 |
| axw | wallyworld: 2001-3000 then. what I mean is this: I could open 1000-2000 for 192.168.0.1/24, and then later 192.168.0.2/24. the azure implementation of IngressRules turns that into one IngressRule. is that the expection of the interface? does it *matter* that they're combined? | 06:42 |
| axw | (or not combined) | 06:42 |
| axw | wallyworld: if it matters, it should be specified on the interface method | 06:42 |
| axw | if not, then I'm wondering why we bother | 06:42 |
| axw | particularly in the provider. if the firewaller cares about grouping them, it should do it - relieve the providers of the burden | 06:43 |
| wallyworld | axw: the idea was that we OpenPorts() with an ingress rule that is has grouped CIDRs for a given port range, so we should mirror thaton the way back out when IngressRules() is called | 06:49 |
| axw | wallyworld: I understand. but what about when they're *not* grouped on the way in? | 06:49 |
| axw | why favour the one over the other? | 06:49 |
| wallyworld | the network.IngressRule struct contains a slice of CIDRs, so we try and stick to that where possible | 06:50 |
| wallyworld | otherwise why bother having a slice of CIDrs in the IngressRule | 06:50 |
| axw | wallyworld: it makes sense coming in, as an optimisation | 06:50 |
| axw | wallyworld: on the way out, I don't think it matters at all | 06:51 |
| axw | wallyworld: at least not at the provider level | 06:51 |
| wallyworld | i guess i also see it as an optimisation on the way out | 06:51 |
| wallyworld | but it can be changed if we think that's what needs to be done | 06:51 |
| axw | wallyworld: an optimisation for what? | 06:51 |
| wallyworld | the caller | 06:51 |
| wallyworld | who would otherwise need to do the grouping | 06:52 |
| axw | wallyworld: my point is this: either the caller needs to do the grouping, the provider needs to, or neither needs to; please document or remove | 06:53 |
| axw | (if the caller *needs* them grouped, and the provider doesn't do it, then it's breaking its contract. that contract needs to be specified, so people don't write dodgy providers) | 06:54 |
| wallyworld | i 'll add some doc the the IngressRules() interface method. we can see how it all plays out then when the firewaller is refactored to use this new stuff properly. we can always change the providers not to group if that turns out to be best | 06:55 |
| axw | wallyworld: I'm just going to give it a quick test, looks good tho | 07:13 |
| wallyworld | ty | 07:13 |
| wallyworld | axw: eating dinner soon, but thanks for review, will fix issues. let me know if any testing shows any issues | 07:30 |
| axw | wallyworld: sure, I'll let you know either way. still waiting on bootstrap... | 07:30 |
| wallyworld | azure is fast :-/ | 07:31 |
| axw | wallyworld: QA OK | 07:46 |
| wallyworld | awesome, ty | 07:54 |
| === frankban|afk is now known as frankban | ||
| perrito666 | Morning | 09:42 |
| hoenir | Good morning comrades ! | 10:31 |
| frankban | axw: ping | 11:20 |
| === frankban is now known as frankban|afk | ||
| perrito666 | morning again | 12:43 |
| === frankban|afk is now known as frankban | ||
| frankban | perrito666: do you know anything about the azure provider? | 13:33 |
| rick_h | frankban: what's up? | 13:33 |
| perrito666 | frankban: very little sadly, the person to as is axw, but shoot the question, we might sort it out | 13:41 |
| frankban | perrito666: ok thanks | 13:45 |
| frankban | perrito666: I'll send an email | 13:45 |
| perrito666 | frankban: k | 13:51 |
| mbruzek | rick_h: Who works on packaging the juju bits that are installed on the deployed VMs? | 14:09 |
| rick_h | mbruzek: the juju agents? they're pulled directly from streams so not really a package? | 14:12 |
| perrito666 | mbruzek: you are experiencing problems with agents? | 14:13 |
| mbruzek | rick_h: I was running a security tool and found jujud was not owned by a user on the deployed system. This set off a security issue, I filed a bug, but want to follow up with someone about it. | 14:13 |
| mbruzek | https://bugs.launchpad.net/juju-core/+bug/1658549 | 14:13 |
| rick_h | mbruzek: ah, yea saw that bug. | 14:13 |
| mbruzek | ok | 14:13 |
| rick_h | mbruzek: not sure there's any "one" person on that. | 14:13 |
| mbruzek | I can be the "one" just point me at the code that does that. | 14:14 |
| rick_h | mbruzek: hmm, so I'd imagine that's done during the agent install process as part of the agent setup bits https://github.com/juju/juju/blob/staging/agent/agent.go | 14:17 |
| rick_h | mbruzek: but yea, might need to get someone like perrito666 or core folks to help sanity check where the agents are installed from/setup. | 14:17 |
| perrito666 | mbruzek: rick_h I am not sure where the exact code is but typically its a tar.gz downloaded from our streams | 14:17 |
| rick_h | mbruzek: wallyworld is probably the best 'expert' on the whole agent setup bits | 14:17 |
| perrito666 | the user on them must be the one fro jenkins on the machine that builds them | 14:17 |
| perrito666 | so a chown is in order | 14:18 |
| rick_h | perrito666: right, but this is when the jujud is unpacked on the managed machine it needs to be chown there | 14:18 |
| rick_h | perrito666: at least that's how I read the bug | 14:18 |
| perrito666 | rick_h: agreed | 14:18 |
| perrito666 | I find it a bit odd that juju does not have its own user | 14:18 |
| rick_h | perrito666: hmm isn't it root? | 14:18 |
| mbruzek | The other files in that directory were symbolic links to something else. This was the only file not owed by root and not a symbolic link. | 14:19 |
| mbruzek | iirc | 14:19 |
| perrito666 | rick_h: yeah I would prefer us to be owned by a juju user | 14:19 |
| perrito666 | mbruzek: looking for the relevant code | 14:20 |
| mbruzek | Thanks perrito666 | 14:20 |
| mbruzek | perrito666: I have to relocate, if you find anything please leave it in the bug I opened and I can take action on it. I am happy to help on this issue, just need a hint on where to look and/or get started. | 14:22 |
| perrito666 | so ideally this should be done inside agent/tools/toolsdir.go -> UpackTools | 14:22 |
| mbruzek | Ok | 14:23 |
| mbruzek | writing that down now | 14:23 |
| perrito666 | mbruzek: ping me when you are back | 14:23 |
| perrito666 | :) ill have more info for you | 14:23 |
| perrito666 | happy relocation | 14:23 |
| mbruzek | brb | 14:23 |
| mbruzek | perrito666: back | 14:55 |
| perrito666 | mbruzek: hi, I was saying "so ideally this should be done inside agent/tools/toolsdir.go -> UpackTools" | 14:56 |
| mbruzek | perrito666: I will take a look and propose a fix | 14:57 |
| perrito666 | buut, that is only called by upgrades so cloud-init most likely has some repeated code doing that | 14:57 |
| perrito666 | mbruzek: looking for the relevant part | 15:00 |
| perrito666 | brb lunch | 15:38 |
| redir | morning | 16:09 |
| perrito666 | redir: hello :D | 16:09 |
| redir | :) | 16:09 |
| alexisb | morning redir, perrito666 | 16:30 |
| perrito666 | alexisb: morning | 16:30 |
| redir | alexisb: 0/ | 16:36 |
| === frankban is now known as frankban|afk | ||
| perrito666 | k, EOD until standup | 20:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!