/srv/irclogs.ubuntu.com/2016/04/14/#cloud-init.txt

=== bdx_ is now known as bdx
=== rangerpbzzzz is now known as rangerpb
larskssmoser: harlowja: are either of you familiar with the new systemd configs introduced between 0.7.6 and 0.7.7?  There are a couple of new targets, some udev configs, a systemd generator...are there docs on how all that is supposed to work?13:36
smoserlarsks, i do want to write some docs on taht :)13:38
smoserbut yeah, i'm familiar.13:39
smoserthe generator really makes it so you can completely disable cloud-init easily13:39
larsksThat seems useful.13:39
smoserjust by: touch /etc/cloud/cloud-init.disabled13:39
smoserthen it never is even considered by systemd in boot13:39
smoseralso by cloud-init=disabled on the kernel command line13:39
smoserso it wont do any of the annoying bottlenecks in boot that it woudl otherwise impose.13:40
smoserthe udev stuff stops networking from coming up until cloud-init-local is done13:40
smoserit blocks the hotplug events13:40
smoserand then when cloud-init has rendered the desired networking, it allows it to go on through13:40
larsksOkay, that helps.13:41
smoserthat way we're not dealing with a system that started ifup on a device that cloud-init re-wrote the configuration for13:41
larsksQuick question about dependencies in the unit files:  there is a dependency on "networking.service", which I'm assuming is an ubuntu-ism.  Would it make sense to simply replace that with a dependency on network.target (which is a standard systemd target)?13:41
larsksOtherwise I need to muck about with the unit files for packaging, and I would like to minimize mucking as much as possible.13:42
larsksOr make the dependency part of a drop-in rather than part of the main unit file, I guess (and the ubuntu packages could include the drop-in).13:42
smoserlarsks, yeah, networking.service is an ubuntu-ism (well, an ifupdown-ism)13:48
smosernetwork.target isnt really good enough13:49
larsksWhat exactly does networking.service provide?  Because there are *also* dependencies already on network-online.target...13:49
* larsks is obviously ubuntu-ignorant w/r/t network setup.13:49
smoserwell, it is really quite specific.13:50
smosernetworking.service is guaranteed to run before network.target is reached13:50
smoserif we were just After network.target, then 'cloud-init' would run in parallel with all other things that are really only blocked on network.target13:51
smoserwhich is a lot of things.13:51
smosersince cloud-init basically consumes user-data at this stage, we want it to block as much of boot as possible13:52
smoserby consumes, i mean it runs the boot-hooks13:52
larsksOkay.  What about moving that dependency to a drop-in?  That would get you exactly the same behavior, but if we could keep the main unit files generic that makes packaging for non-ubuntu enviornments easier.13:52
smosero13:52
smoseri'm not opposed to it if it works.13:53
smoseror some other way that we could do it.13:53
larsksI think drop-ins are the systemd approved way of doing this sort of thing.13:53
smoserthe generator could actually probably determine what the system will use and dtrt13:53
larsksOh, huh.13:53
larsksThat would be interesting.13:53
smoserwhat do you mean by drop-in?13:53
larsksYou create a directory /etc/systemd/system/cloud-init.service.d, and you can drop files in their to extend the unit file without having to modify it.13:54
smoserthats what i thought you meant.13:54
larsksSo from systemd's perspective, you end up with same final configuration, but you get to keep distribution-specific dependendecies out of the main unit file.13:54
smoseryeah. i'm not opposed to that.13:56
smoseryour'e looking to get this functional on centos/rhel ?13:56
* smoser would like that too13:56
larsksYeah.13:56
larsksI guess we will need the network setting stuff, too.13:56
smoserso, for that...13:56
smoserright now in cloud-init on ubuntu it basically works like:13:57
smosera.) read openstack networking configuration format13:57
smoserb.) convert it to "internal" format13:57
smoserc.) render it13:57
smoserc.) render it to /etc/network/interfaces and systemd.link files13:57
smoserthere is code i think in clod-init that will take a /etc/network/interfaces file as a "networking configuration format" and render it to redhat style networking format13:58
smoserso that might be the easiest way to do this.13:58
larsksYeah, that should already exist.13:58
smoseralthough ENI is kind of ...  sucky as a network config format13:58
smoserie, i'm afraod the conversion might be lossy13:58
smoserafraid13:59
larsksI will try to take a look at that soon unless mgagne or dmsimard gets to it first.13:59
dmsimardyeah but "/etc/network/interfaces" format != network_data.json14:01
dmsimardand network_data.json is the agreed way upstream to do it14:01
larsksdmsimard: right, but smoser  was saying there exists network_data.json format -> ENI, and we also have ENI->redhat already.14:01
larsksSo you could use ENI as an intermediate format.14:02
dmsimardah, yes.14:02
larsksModulo smoser 's comments re: lossy conversion.14:02
smoserbecause there exists ENI -> RH for the old crappy path where openstack declared networking in ENI format14:02
dmsimardso that patch added the "translator" and ubuntu support14:02
dmsimardwe can definitely re-use the "translator", just need to add RHEL support14:02
smoserbut doing it well probably isnt that much work.14:02
larsksYeah.14:03
smoseryou have a fairly clean networking config format declared to you, and we can fix the "internal" stuff in cloud-init to be better if we need to14:03
smoserthe harder part is the next step..14:03
dmsimardI can help testing an implementation for RHEL/CentOS but adding the support is a bit out of my league14:03
smoserwhere we want to take a hotplug event and then hit the datasource and say "hey, i just got a network device, what should i do with it"14:04
smoserand apply that.14:04
larsksI need to fix https://bugs.launchpad.net/cloud-init/+bug/1424710 first before I can play with 0.7.7 much :)14:08
dmsimardTIL about hostnamectl14:09
smoserrharper, ping when youre in.14:25
rharpersmoser: here14:32
smoserhey.14:33
smoserhttps://bugs.launchpad.net/maas-images/+bug/157014214:33
smoserthe one difference between cloud-init fallback rendered networking config (which doesnt work on iscsi root) and cloud-initramfs-dyn-netconf (which *does*) is 'auto eth0'14:34
smoserrather than manual14:35
rharpersmoser: really here: was at the car shop, back home now15:08
smoserk.15:09
smoserso theres 2 things there really15:09
smosera.) we need a way for config to say 'manual'15:10
smoserb.) cloud-init fallback needs to determine "this is manual" for the ip= fallback path.15:10
rharpercan you expand on (a); as it sounds like you mean more than just iface foo inet manual15:12
rharperwhich can already be expressed in network config15:12
smoserallow-auto15:15
smoseror allow-hotplug15:15
smoserrharper, http://paste.ubuntu.com/15831923/15:17
smoserthat'd be one suggestion, arbitrarily picked name 'control' to mean how should this interface be broought up or down15:17
rharpersmoser: anything that's not 'auto' (which is alias for allow-auto) or 'hotplug' (which we don't support in network config yet) get's ignored by ifquery as "manual"15:19
rharperso the default is manual control15:19
rharpercertainl fallback code can use ifquery to determine which ifaces are present but manual (i.e. not in ifquery)15:19
smosernot really.15:20
smoserfallback is dictating which are present but manual15:20
smoserit can't ask ifquery that15:20
rharperfallback runs when networking didn't come up (at all or just one expected iface);  in the case that there's an eni, we can use ifquery vs. the set of nics we find from the kernel; and apply heuristics w.r.t what we select first and what we ignore;  in the case that there is no eni; then  we just have the heuristics and ignore list.15:23
rharperI don't quite follow how a new field in eni would help15:24
smoser brb15:28
smoserhttp://paste.ubuntu.com/15832136/ is what i think is sane.15:28
rharperAFAICT, you're just excluding them from allow-auto (or auto); which means ifquery won't pick them up by default;  allow-manual removes it from the list of ifaces that ifquery looks for by default for bring all ifaces up;15:31
larsksSlightly off topic, but...does anyone here have Azure experience?16:29
waldisome16:32
larskswaldi: in particular, do you have experience convert disk images to vhd format and uploading them successfully?16:41
larsksconvert*ing*16:42
waldiyep16:43
waldicode: https://gitlab.credativ.com/de/azure-manage/blob/develop/azure_manage/vhd.py16:44
larskswaldi: thanks!  Looking.16:45
waldithe code in qemu-img is broken unfortunately. i need to write a bug-report about it16:46
larsksInteresting. At least that means I'm not crazy.  Or at least, not because of the conversion failures...16:47
waldiqemu-img alligns the images to cylinder/head boundary. this is futile on Azure, which expects images alligned to whole MiB16:48
larsksDo you know if earlier versions of qemu-img worked?  The microsoft docs seem to assume that there is a working version out there somewhere.16:52
waldinot sure16:54
larskswaldi: already fixed upstream; staged for next qemu-release: http://serverfault.com/questions/770378/problems-preparing-a-disk-image-for-upload-to-azure/770425#77042521:12
=== rangerpb is now known as rangerpbzzzz
=== klindgren__ is now known as klindgren

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!