| smoser | mgagne, a build of https://code.launchpad.net/~smoser/cloud-init/trunk.fix-networking/+merge/296272 should be landing at https://launchpad.net/~smoser/+archive/ubuntu/cloud-init-dev shortly | 00:37 |
|---|---|---|
| smoser | (and this one should actually build :). the previous didn't build, which was why whatever you had there would have been garbage. | 00:37 |
| smoser | whats there right now will use the 'id' as the nic name. i plan to look at changing that for openstack tomorrow. | 00:38 |
| ubuntu__ | smoser: hi, is https://bugs.launchpad.net/cloud-init/+bug/1355909 still on the radar? | 08:53 |
| Odd_Bloke | Well, I've been sitting all by myself in a #cloud-init on a different IRC server for a few days. :p | 11:24 |
| smoser | ubuntu__, i would like to have that functional, yeah. | 13:05 |
| === ubuntu is now known as Guest4264 | ||
| === ubuntu__ is now known as sfriesel | ||
| === jgrimm-afk is now known as jgrimm | ||
| Takumo | Hi all, how would I set hostname based on an ec2 tag in cloud-config? | 13:53 |
| === rangerpbzzzz is now known as rangerpb | ||
| smoser | Takumo, nothing really helpful to that in cloud-inti. | 14:43 |
| smoser | are tags available inside the instance, i forget | 14:43 |
| smoser | i didnt think they were. | 14:43 |
| Takumo | I think they're available from the metadata service | 14:43 |
| Takumo | doesn't matter too much | 14:43 |
| Takumo | was just looking for a way to assign a hostname or id to use within ansible scripts | 14:44 |
| Takumo | thought I could set the fqdn based on a tag and keep my ansible stuff agnostic of ec2 | 14:44 |
| smoser | well you can assign te hostname via cloud-init | 14:54 |
| smoser | just not via a tag | 14:54 |
| smoser | http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt#L408 | 14:55 |
| GivenToCode | Hi I am using ubuntu 14.04.4 with cloud-init 0.7.5 on ec2 and am having issues with ephemeral drives on various instance families | 14:59 |
| GivenToCode | essentially, for the r3 family, cloud-init runs mount -a and in fstab is an entry to mount xvdb to /mnt, however for r3s the ephemeral devices don't have file systems | 14:59 |
| GivenToCode | the mechanisms cloud-init provide (bootcmd) run after mount -a runs... | 15:00 |
| Odd_Bloke | smoser: I have a doc improvement MP open at https://code.launchpad.net/~daniel-thewatkins/cloud-init/merging-doc-clarification/+merge/295822. If gaughen reviews and approves it, are you happy for me to merge it, or would you like to review? | 15:21 |
| smoser | Odd_Bloke, thats fine/ | 15:21 |
| smoser | GivenToCode, you just want it to not do that ? | 15:22 |
| GivenToCode | if it matters i am using this AMI ami-0f8bce65, which has a mount for xvdb to /mnt in fstab and fails on r3 instances | 15:22 |
| smoser | GivenToCode, you should be able to provide user-data that says: | 15:23 |
| GivenToCode | smoser, I'm not sure what I want it to do, but it is clear cloud-init has at least one faulty assumption on ec2 | 15:23 |
| smoser | mounts: | 15:23 |
| smoser | - [ephemeral0, null] | 15:23 |
| smoser | - [swap, null] | 15:24 |
| smoser | http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt#L174 | 15:24 |
| smoser | and if you could, file a bug against cloud-images at http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt#L174 | 15:25 |
| smoser | bah | 15:25 |
| smoser | at https://bugs.launchpad.net/cloud-images/+filebug | 15:25 |
| smoser | and Odd_Bloke and his team will see if they can't make it dtrt | 15:25 |
| GivenToCode | smoser, but i still do in fact want xvdb to mount to /mnt, we depend on it | 15:25 |
| smoser | ah. ok. then you can put a filesystem on it too. | 15:26 |
| smoser | hold on | 15:26 |
| GivenToCode | but i want it to happen after we mkfs, which we are trying to do in bootcmd but it happens after mounts it looks like | 15:26 |
| smoser | http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config-disk-setup.txt#L4 | 15:26 |
| smoser | that should work. | 15:26 |
| smoser | disk_setup: | 15:26 |
| GivenToCode | smoser, so something like that is happening for c3s but not r3s | 15:28 |
| smoser | right. | 15:29 |
| smoser | so on amazon in most cases they provide you an ephemeral disk that already has a filesystem on it. | 15:29 |
| smoser | and cloud-init just says "mount that" | 15:29 |
| GivenToCode | ok, so if i put that in my own custom user data it'll happen for all instances no matter the family? | 15:29 |
| smoser | but in this case (and on other clouds) that is not the case. | 15:29 |
| smoser | this is new info to me, i've not tracked ec2 closely for quite a while. | 15:30 |
| GivenToCode | ok, you've been a huge help | 15:30 |
| smoser | GivenToCode, i'd like it to. it is possible there are bugs in it. but this is generally the path that azure takes, so something should be able to be made to work there. | 15:30 |
| GivenToCode | cc_disk_setup.py[WARNING]: Query against device /ephmeral0 failed | 15:53 |
| GivenToCode | util.py[WARNING]: Failed partitioning operation | 15:53 |
| GivenToCode | ah typo on line 9 | 15:54 |
| Odd_Bloke | smoser: Will cloudinit.readthedocs.io eventually get updated, or is there another step that needs to happen? | 16:40 |
| smoser | Odd_Bloke, i think so. | 16:51 |
| Odd_Bloke | I guess we'll find out. ;) | 16:54 |
| harlowja | i think its a manual refresh for that one | 16:54 |
| harlowja | since afaik smoser and i are the people that can click rebuild that website | 16:55 |
| Odd_Bloke | Ah, OK. | 16:55 |
| smoser | harlowja, thank you | 16:55 |
| smoser | :) | 16:55 |
| harlowja | guess u want me to click rebuild :-P | 16:55 |
| Odd_Bloke | I know some RTD things update on commit. | 16:55 |
| Odd_Bloke | harlowja: Make it so, number one. | 16:56 |
| harlowja | Odd_Bloke i don't think bzr stuff does update on commit :( | 16:56 |
| harlowja | i think github stuff might | 16:56 |
| harlowja | but bzr is manual afaik | 16:56 |
| Odd_Bloke | Fair enough. :) | 16:56 |
| Odd_Bloke | Anyway, /me --> long weekend | 16:56 |
| harlowja | not allowed | 16:56 |
| harlowja | lol | 16:56 |
| GivenToCode | is 0.7.5 the latest version for ubuntu 14.04.4? | 16:58 |
| smoser | GivenToCode, yes. | 17:05 |
| GivenToCode | hmm, how hard is it to patch? I need the fix for this: https://bugs.launchpad.net/cloud-init/+bug/1311463 | 17:29 |
| smoser | GivenToCode, thats probably not too bad. and i'd help you learn the Ubuntu SRU process if you're really looking to learn | 18:00 |
| smoser | (that is me saying i'd like to help but have limited time and higher priorities at the moment... but if i can get you involved and then later possibly get you to contribute m ore, then i'd probably help you along :) | 18:00 |
| GivenToCode | smoser, to be clear the bug has been fixed, i just need the new version (0.7.7) which doesnt seem to be easy to upgrade to | 18:02 |
| GivenToCode | or, since it is a one liner I could manually patch my AMI but it doesn't look like the .py files are actually on disk | 18:03 |
| smoser | well, you need an SRU (Stable Release Update) to get it into 14.04 | 18:03 |
| GivenToCode | I'd be happy to contribute, am an ASF committer, but there is some red tape with my current employer | 18:03 |
| smoser | the .py files are on disk, and you *can* do that. | 18:03 |
| smoser | dpkg -L cloud-init | grep .py | 18:04 |
| GivenToCode | smoser, oh I see, my assumption of what SRU was was wrong | 18:04 |
| smoser | https://wiki.ubuntu.com/StableReleaseUpdates | 18:05 |
| smoser | rharper, so what happens if i do this: | 18:56 |
| smoser | http://paste.ubuntu.com/16928154/ | 18:56 |
| smoser | or this | 18:58 |
| smoser | http://paste.ubuntu.com/16928206/ | 18:58 |
| rharper | smoser: for the first, if we omit the name, I don't think we'll write out correct eni files, rather, we'd need to create our own name value if we don't use id | 18:59 |
| smoser | for some reason i thoguht it might just use the current name if its not present. | 18:59 |
| rharper | the latter patch makes more sense, however, the absence of a 'name' key in the network_config will break the requirements of a type: physical dict | 18:59 |
| rharper | smoser: that'd require more introspection at network_config parse-time | 19:00 |
| rharper | but it could be done | 19:00 |
| rharper | the name_by_mac | 19:00 |
| rharper | we have for ip set link stuff would provide the values | 19:00 |
| rharper | I need to think a bit more about whether we can construct reasonable configs for multi-layered things (like bonds, vlans and bridges) | 19:01 |
| rharper | we have at-least the rackspace /ironic case which uses bonds and vlans in the network_data.json | 19:01 |
| smoser | mgagne, i'm pretty sure my ppa should work for you now. | 20:41 |
| smoser | i've tested on dreamhost and we've tested via config drive similar to what you gave | 20:41 |
| smoser | rharper, so i think that https://code.launchpad.net/~smoser/cloud-init/trunk.fix-networking/+merge/296272 is ready ... except for the obnoxious naming in openstack | 20:42 |
| smoser | which i really just dont feel comfortable putting in | 20:42 |
| rharper | smoser: you've got merge conflicts | 20:43 |
| rharper | in Changelog | 20:43 |
| smoser | well, just that one. i was fixing it. | 20:44 |
| rharper | w.r.t the id -> name , what do you suggest otherwise then? Is your concern that users will be confused in the case that the id was tap-fasdfs23 ? | 20:44 |
| smoser | well, i expect a few things | 20:44 |
| smoser | a.) some users saying WTH UBUNTU! | 20:44 |
| smoser | b.) juju charms not expecting that name or being able to predict it in any way | 20:45 |
| rharper | s/UBUNTU/$DISTRO_WITH_CLOUD_INIT | 20:45 |
| smoser | rharper it doesn't make me feel better to say "WTH SMOSER!" | 20:45 |
| smoser | :) | 20:45 |
| rharper | smoser: right, cloud-init -> smoser | 20:45 |
| rharper | understood | 20:45 |
| rharper | so, totally understand a and b, so instead of cloud-init picking; I think we can just re-use what the nics were named unless 'name' exists in the network_data | 20:46 |
| rharper | I think that's a completely reasonable alternative that allows folks to toggle the interface name wit net.ifnames=0 or 1 | 20:46 |
| rharper | and cloud-init won't be in the way | 20:46 |
| smoser | yeah. then we have to search, which we're not doign right now. | 20:50 |
| rharper | it's the same lookup call for rename later | 20:50 |
| rharper | at the time of config-drive conversion | 20:50 |
| rharper | we fetch the list of nics and macs, and just inject name: <current name by mac> | 20:50 |
| smoser | yeah. i think so. | 20:52 |
| smoser | mgagne, so your input would be appreciated. really should be fixed. | 20:58 |
| mgagne | will test right now | 20:58 |
| smoser | ok i have to go afk, but will check in later, and maybe try to do the last change there for openstack nic names. | 20:58 |
| harlowja | "WTH SMOSER!" | 21:30 |
| harlowja | lol | 21:30 |
| mgagne | it's not working. cloud-init thinks my interfaces are named after the link id (found in interfaces.d). After running ip link, they are still named ens3 and ens4. | 23:50 |
| mgagne | hostname is still not set, user scripts not run, etc. | 23:50 |
| mgagne | I had to reboot the instance in single mode to debug and read logs | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!