[01:56] <smoser> blackboxsw: well, its that there is no python
[01:56] <smoser> in rawhide
[01:56] <smoser> well, we could buildpend on python2 and use python2.
[01:57] <smoser> thats probably the easiest path out of it... to just build python2 for fedora, but we really want to be doing python3 there.
[01:58] <blackboxsw> yet on successes I also see the missing python log
[01:59] <blackboxsw> https://copr-be.cloud.fedoraproject.org/results/blackboxsw/cloud-init/fedora-rawhide-i386/00776423-cloud-init/build.log.gz
[01:59] <smoser> all by myself tomorrow :)
[01:59] <smoser> wll that is odd.
[01:59] <blackboxsw> yet in this success case the diff is logged from sh instead of /var/tmp/rpm-tmp.v0 etc
[01:59] <blackboxsw> BUILDSTDERR: sh: /usr/bin/python: No such file or directory
[01:59] <smoser> i think that is just an error in their build system
[01:59] <smoser> that it didn't catch failure
[02:00] <blackboxsw> get a few of those and then it goes on building
[02:00] <smoser> if you're saying that url is a success
[02:00] <smoser> hm...
[02:00] <blackboxsw> yeah the last one was a success and continued building perBuilding target platforms: i686
[02:00] <blackboxsw>  "
[02:03] <blackboxsw> it's strange, I'll try kick off a build myself from tip pre-get-linux-distro   to see if it passes. here's the proper "pass" linked logs from cloud-init-dev's run before my changeset landed in tip    https://copr-be.cloud.fedoraproject.org/results/@cloud-init/cloud-init-dev/fedora-rawhide-i386/00774784-cloud-init/build.log.gz
[02:04] <blackboxsw> that differs from my local failed build attempt https://copr-be.cloud.fedoraproject.org/results/blackboxsw/cloud-init/fedora-rawhide-i386/00776423-cloud-init/build.log.gz
[02:05] <smoser> how'd you local build ?
[02:13] <blackboxsw> I local built a source rpm and uploaded it via copr UI in the "new Build" dialog ./tools/run-container  --source-package centos/7
[02:14] <blackboxsw> ok gotta run
[02:14] <smoser> oh. right. ok. i didn't understand that as "local"
[13:23] <caribou> smoser: I just pushed modifications for my MR. For some reason Jenkins did not trigger after the failed build
[13:23] <caribou> but I have one issue that I'd like to bounce by you people
[13:25] <caribou> The network config gets generated on each boot, but, even though I see bring_up=True, the network config does not get applied (i.e. the IPv6 portion of it)
[13:31] <caribou> I traced it down to _write_network_config that returns the result of _supported_write_network_config, which always happens to be an empty list
[13:35] <caribou> Since _bring_up_interfaces() scans that list, it never brings up any device
[13:35] <caribou> I hope I'm making some sense
[13:57] <smoser> caribou: you have to be in a group to get it to autmatically run for you
[13:57] <smoser> dont know if you're in it or not.
[13:58] <caribou> well, usually it runs on each new commit
[13:58] <caribou> the first one failed then I fixed & pushed again
[13:58] <smoser> caribou: bring_up=True should actually be removed.  we dont do anything with it now, and i think its not really supposed to get called (but i'd have to dig to remember)
[13:58] <smoser> it was kind of garbage from long time a go.
[13:58] <smoser> what is supposed to happen is that cloud-init in local mod renders the networking configuration
[13:59] <smoser> and then the operating system brings it all up as it would if that was writtenb efore the boot.
[13:59] <caribou> hmm, that'll explain it, I moved it back to DEP_NETWORK
[14:00] <caribou> hmm, then that means that I still need to rely on EphemeralDHCP since I need to fetch the metadata to the the IPv6 info
[14:02] <smoser> caribou: yes. you do need to use ephemeraldhcp
[14:03] <smoser> caribou: maybe some background info ...
[14:03] <smoser>  - local runs before networking is brough up by the OS
[14:03] <caribou> got that
[14:03] <smoser>  - cloud-init.service runs *after* networking is brought up by the OS
[14:04] <smoser>  - we want to guarnatee that things that need networking can use it when the OS says it is up.
[14:04] <smoser>  ie, we do not want cloud-init to go bouncing the interfaces
[14:04] <caribou> k
[14:05] <smoser> so we write networking before the OS brings it up and let the OS bring it up
[14:05] <smoser> with future events we may have cloud-initn bounsing networking
[14:05] <caribou> So the use of EventType is to assure that the network_config in the ds will run at each boot and not on the initialone
[14:05] <smoser> or otherwise telling the OS to apply new networking of some sort.
[14:05] <smoser> right.
[14:05] <caribou> ok got it
[14:06] <caribou> I'll fix it up as such & push again
[14:06] <caribou> thanks for the details
[14:06] <smoser> users of scaleway will by default have cloud-init render networking on every boot
[14:06] <smoser> they will be able to disable that
[14:06] <smoser> but should they do that... then they wont get networking rendered on boot, and bad things might happen.
[14:06] <smoser> the reason we allow them to disable that behavior.
[14:07] <smoser> a.) cloud-init has not behaved like this in the past (backwards compat desire)
[14:07] <smoser> b.) they may have other ways of building things on top . perhaps they bring up a vpn or something, and cloud-init would cause issues with that if it modified the networking configuraitoin on reboot.
[14:08] <caribou> good, understood
[14:32] <caribou> Grrr, I accidentaly delete my MR branch off LP :-(
[14:33] <caribou> smoser: any chance of tying a new branch on the original MR ? Or I should just close this one & create a new one ?
[14:44] <smoser> caribou: "tying a new branch?"
[14:45] <smoser> i suspect if you just push the branch again with same name it might work
[15:12] <caribou> smoser: doesn't look like it, maybe I try ro resubmit
[15:18] <smoser> ok
[15:30] <caribou> smoser: sorry, had to delete & resubmit it was referring to the dead branch
[15:37] <smoser> caribou: i'll get a look at that today.
[21:18] <powersj> smoser: are you using blackboxsw's gce instances?
[21:22] <smoser> powersj: no.
[21:22]  * powersj blows them away then