| niluje | blackboxsw: I was suggesting to start an instance in case you wanted to try the connector | 16:09 |
|---|---|---|
| niluje | but I'll ask to the team on monday if it is doable to give you an instance then, we do that for some open source projects | 16:09 |
| blackboxsw | niluje. it'd be helpful for me. I'm actually reviewing your branch a bit right now and was talking to smoser about why that was necessary for ScaleWay (security) | 16:10 |
| smoser | blackboxsw, niluje i can start one if its easier than niluje doing it as a one off. | 16:10 |
| smoser | it'd be nice if we had a "comp"ed and limited account that we would play nice with too though. | 16:11 |
| blackboxsw | s/ScaleWay/Scaleway/ rather | 16:11 |
| blackboxsw | +1 on that. since we'd use the account(or instance) exclusively for cloud-init enablement/testing/certification. | 16:12 |
| smoser | blackboxsw, niluje one thing that came out of my conversation with blackboxsw ... we'd like a comment in the code on why we're using the low source port number. | 16:13 |
| smoser | blackboxsw, root@51.15.134.115 | 16:17 |
| blackboxsw | thx smoser | 16:18 |
| blackboxsw | thanks I'm in the instance | 16:19 |
| smoser | powersj, so for your ssh work, were you looking to do a separate ssh server or using the built in one ? | 16:25 |
| powersj | Using built in one | 16:25 |
| powersj | at this point I'd rather just hijack the user-data and inject my key for kvm backed testing | 16:25 |
| powersj | where my key is a key we generate for each run | 16:26 |
| smoser | i guess to get going that is acceptable, but we dont want to rely on nit as that means that | 16:26 |
| smoser | a.) we always have to have user-data | 16:26 |
| smoser | b.) we always have to have ssh server enabled | 16:27 |
| smoser | c.) we can't test the ssh generation code | 16:27 |
| powersj | so for A our tests are entirely built around user-data | 16:27 |
| powersj | for now at least, so yes | 16:28 |
| powersj | for kvm testing we have said in our spec that we would use SSH to communicate, so we have to have B | 16:28 |
| smoser | but we also need to verify that systems work correctly without user-data. | 16:28 |
| powersj | for C we can run those tests via lxd | 16:28 |
| smoser | we have to have B because you just said we have to have B | 16:28 |
| smoser | :) | 16:28 |
| powersj | not trying with any user-data is a gap at the moment | 16:28 |
| powersj | I'll throw up a card | 16:29 |
| powersj | toss up* (throw up sounds odd)... | 16:29 |
| smoser | looking at https://github.com/gravitational/teleport seems like that mnigiht give a fairly sane path | 16:31 |
| powersj | smoser: while I have you, how does this look for a qemu cli http://paste.ubuntu.com/25089942/ | 16:33 |
| powersj | I'll take a look at that | 16:33 |
| smoser | well, ultimately i think we really do want something that is part of our test that stands "outside" of the normal behavior of the image and doesn't affect it | 16:40 |
| smoser | other wise what you're testing is not the thing you're intending to test. | 16:40 |
| powersj | not sure I follow | 16:41 |
| smoser | if we're trying to test running cloud-init from trunk on Ubuntu/17.04, then the goal is to test exactly that. Just as if that version of cloud-init were already in it, with no other changes. | 16:43 |
| smoser | ie, we dont want to install a bunch of extra packages on the image, or really do anything else. | 16:44 |
| powersj | right | 16:45 |
| smoser | every change that is required as part of the test harness should be made to have the least affects possible on the rest of the system. | 16:45 |
| powersj | ^^ that's a good way of summarizing | 16:45 |
| smoser | if we have to make changes, we want those changes to interact with the rest of the system as little as possible. ideally no side affects and no dependencies outside of what cloud-init requires. | 17:10 |
| powersj | right so using any odd SSH settings or new binaries should be avoided. Which is why I do like modifying user-data to provide us with a standard way of accessing the system. | 17:18 |
| powersj | This way the only possible change I make to the images is injecting a new version of cloud-init sometimes. Otherwise, no changes should be made. | 17:19 |
| smoser | powersj, yeah. i understand how that is "less" change, but in another way its more change. | 18:06 |
| smoser | you're affecting the normal boot of the system | 18:06 |
| smoser | i'm not suggesting that we change the port that the system ssh port runs on, i'm suggesting we run an additional ssh server on a random port. | 18:08 |
| powersj | We should chat about this because I'm not sure we are on the same page | 18:08 |
| smoser | :) | 18:08 |
| powersj | or even talking about the same thing anymore ;) | 18:08 |
| smoser | powersj, well http://c.brickies.net/hangout if you want. i'll hang there for a bit | 18:13 |
| powersj | smoser: still meeting with boss man | 18:13 |
| dpb1 | smoser: and now he's out of battery | 18:50 |
| dpb1 | :) | 18:50 |
| smoser | powersj, so you're not joining ? | 19:01 |
| powersj | smoser: yeah sorry I'm getting lunch and will drive home | 19:02 |
| powersj | I'll see if you are still around otherwise we can meet after stand up Monday | 19:02 |
| smoser | powersj, no worry | 19:12 |
| voja | Hi, is someone aware of a small / example implementation of a meta data server? | 19:30 |
| smoser | voja, https://gist.github.com/smoser/1278651/ | 19:31 |
| voja | Thank you! | 19:32 |
| smoser | voja, and https://git.launchpad.net/~cloud-init-dev/cloud-init/plain/tools/mock-meta.py | 19:33 |
| voja | Is it possible to re-configure the network that way? DHCP to get a LAN IP and then fetch public IP via metaservice? | 19:33 |
| smoser | voja, the only network based service that has that functionality is digital ocean | 19:35 |
| voja | I see. | 19:35 |
| smoser | so you'd have to mimic digital-ocean . i dont have an example of that server.. you can look in sources. | 19:35 |
| smoser | it uses ipv4 link local | 19:35 |
| smoser | but interestingly... what you asked for "DHCP to get a LAN IP and then fetch".... | 19:36 |
| smoser | is exactly what blackboxsw is trying to turn the EC2 metadata service into | 19:36 |
| smoser | but work would be required there anyway. | 19:36 |
| voja | At least I got NoCloud with static dualstack configuration working for Ubuntu and Debian | 19:37 |
| voja | I still have a problem with CentOS | 19:37 |
| voja | Which appears to have an older cloud-init version. It does not load my NoCloud iso | 19:37 |
| voja | What is blackboxsw btw? | 19:38 |
| blackboxsw | yeah voja, work in progress branch that we're pulling together now for Ec2 I'm sorting some CentOs dhclient issues at the moment https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+ref/aws-dhclient | 19:38 |
| blackboxsw | heh voja: short for blackbox software .. an allusion to https://en.wikipedia.org/wiki/Black_box | 19:38 |
| blackboxsw | I lost a bet during the world cup that I needed to change my irc nick from csmith -> blackboxsw | 19:39 |
| voja | Okay I see... | 19:39 |
| voja | I am working on a project that should be able to boot KVM OS images without running the whole installer. They will need pointopoint IPv4 in my setup, which makes everything complicated. | 19:41 |
| voja | I like to use cloud images for this | 19:41 |
| blackboxsw | so that Work in progress branch should come together today once I get past a couple of additional hoops , but the theory is we'll use the OS's dhclient without side-effecs in the ephemeral environment in order to manually bring up one interface in order to talk to the metadata service to obtain the entire picture of network config for all interfaces. | 19:41 |
| voja | That's indeed what I'd need | 19:42 |
| voja | Was this part of the discussion how to get the latest cloud-init version into the image? | 19:43 |
| blackboxsw | voja, nope it's a separate discussion for part of our work on IPv6 support in AWS. so in cloud-init I'm hoping we can use the context manager cloudinit.net.dhcp_clean_discovery to bring up a simple interface with details it gets from a dhcp server, then hit whatever | 19:44 |
| blackboxsw | the approach we are taking in amazon to get ipv6 info would be from the metadataservice. But we can't get metadata until we have a valid interface up. So dhclient -4 , then hit metadata, then react to setup the rest of the ipV6 networking if needed | 19:45 |
| voja | Okay, that would not bring static IPv4 to the cloud box as I would require | 19:46 |
| blackboxsw | the first steps part of the work should do that, cloudinit.net.dhcp_clean_discovery would just obtain an ip offer from the dhcp server using discovery and bring up the interface with the dhcp ip address. The rest of the ipv6 stuff would only happen if ipv6 network configuration were returned by the metadata service. | 19:52 |
| niluje | smoser: blackboxsw: that's how our metadata API works. We decided to only allow reading/writing to the metadata API from a privileged port to limit access to the root user, since privileged ports can't be bound by non-roots | 22:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!