| === tds4 is now known as tds | ||
| Odd_Bloke | meena: OK, nice! So I think what you've produced there is closer to what we would have part way (or perhaps most of the way, I haven't looked at the exact set of things you've "migrated") through this migration process. I haven't fully read through Ryan's comment yet (I was off yesterday), so I'll do that today and perhaps see if I can propose an initial structure for discussion. | 13:37 |
|---|---|---|
| === hjensas is now known as hjensas|afk | ||
| blackboxsw | rharper: Odd_Bloke our debian/control depend on pyflakes (python2-version) anymore? | 17:21 |
| blackboxsw | it seems like we should be dropping that. pkg dep right? https://github.com/canonical/cloud-init/blob/ubuntu/devel/debian/control#L11 | 17:22 |
| lucasmoura | Hi everyone, just a quick question about https://bugs.launchpad.net/cloud-init/+bug/1456277 . The ec2 mirrors should only be used by ec2 instances, right ? Or is there any other scenario that I should still enable them ? | 18:52 |
| ubot5 | Ubuntu bug 1456277 in cloud-init (Ubuntu) "cloud-init searches for ec2 mirrors regardless of what cloud its on" [High,Confirmed] | 18:52 |
| lucasmoura | My idea here will be to enable those mirror only if the datasource platform_type is ec2, but I don't know if that is too restrictive | 19:05 |
| powersj | lucasmoura, I think in general AWS would be happy if only instances in their cloud use their mirrors | 19:12 |
| rharper | powersj: not sure but I don't think they are accessible from outside aws, no ? | 19:12 |
| rharper | it's internal ips that are mapped | 19:12 |
| powersj | http://us-west-2.ec2.archive.ubuntu.com/ubuntu/ | 19:13 |
| Odd_Bloke | blackboxsw: Huh, I'm very surprised that hasn't come up in in Py2 removal, but perhaps Build-Depends aren't checked in the same way. Yeah, looks like that should be pyflakes3 now. | 19:13 |
| rharper | powersj: heh | 19:13 |
| Odd_Bloke | I _believe_ that the Azure mirrors use in-cloud-only DNS servers so that only in-Azure instances will resolve the Azure mirrors to the Azure instances, so perhaps you're thinking of that, Ryan? | 19:14 |
| Odd_Bloke | lucasmoura: I'm not sure that bug is applicable any longer: `nslookup foobar.ec2.archive.ubuntu.com` gives me NXDOMAIN (whereas `nslookup us-east-1.ec2.archive.ubuntu.com` does return IP addresses). | 19:15 |
| Odd_Bloke | The "any subdomain will resolve" logic has moved to *.clouds.archive.ubuntu.com, which resolves to our mirrors by default instead of EC2's. | 19:18 |
| lucasmoura | Odd_Bloke, I think I am missing something, wouldn't it be possible for another cloud provider to set up their availability zone to a similar pattern than ec2 and enable the ec2.archive.ubuntu.com/ubuntu/ mirror ? | 19:23 |
| Odd_Bloke | lucasmoura: You're absolutely right, I misread the report initially, my mistake. | 19:26 |
| lucasmoura | Odd_Bloke, No worries. I will enable that mirror only for ec2 instances | 19:28 |
| lucasmoura | Thanks everyone for the help :) | 19:28 |
| Odd_Bloke | lucasmoura: I do worry that some cloud deployments may have configured their mirrors on the assumption that the EC2 pattern will always be searched. (i.e. They have a `us-east-1` region, and they have their internal DNS return their internal mirrors when `us-east-1.ec2.archive.ubuntu.com` is resolved.) | 19:28 |
| lucasmoura | Odd_Bloke, makes sense. But is there a way to know that this kind of configuration is expected ? I mean is there any info on the datasource that might suggest that ? | 19:30 |
| Odd_Bloke | Nope, unfortunately. So we need to think a little bit about how we want to release this change. My initial thought is that this is _fairly_ easy to workaround: if you're hitting a problem as a result of this then you must already have some internal DNS configuration, so adding us-east-1.clouds.archive.ubuntu.com to resolve to your mirrors should be possible. | 19:34 |
| Odd_Bloke | (Actually, you could also hit a problem if you rely on the use of the EC2 mirrors but have firewalled off the Ubuntu mirrors. Again, the workaround is to change your existing configuration, so shouldn't be too hard to deploy a workaround.) | 19:35 |
| Odd_Bloke | So I wonder if this is another case where we shouldn't be backporting the behaviour to current Ubuntu releases, but should change it going forward? | 19:37 |
| lucasmoura | Yes, I agree that it makes sense to change it only going forward. Should we support this change using the feature flags falcojr is implementing ? | 19:40 |
| Odd_Bloke | That's a good question: should this be configurable or not? | 19:43 |
| lucasmoura | I guess it shouldn't be, but I don't know if by doing non-configurable I would generate a headache on downstream package maintainers with they want to enable the ec2 mirror lookup. I know it would be still possible to edit this using patches, but it would be harder to find it in the code | 19:51 |
| Odd_Bloke | Sorry, let me rephrase: I think we _at least_ want to use a feature flag to capture the two different behaviours. The question I'm asking is: should we allow this behaviour to be configurable at runtime by users (in which case it would be better as a configuration option than a feature flag)? | 20:03 |
| blackboxsw | Odd_Bloke: right, I think https://github.com/canonical/cloud-init/pull/373 is the first upload we've tried after the official drop of pyflakes | 20:19 |
| blackboxsw | *from the archive | 20:19 |
| blackboxsw | which looks like it happened about a month ago | 20:19 |
| blackboxsw | in groovy | 20:19 |
| Odd_Bloke | Oh, OK, so I guess this did get caught by Py2 removal, just later removal than I assumed. :p | 20:21 |
| blackboxsw | so lucasmoura and falcojr I added and edited the a comment response about what testing we look for to validate a release. What I caught was that sbuild barked with a missing dependency error. when I tried to run `sbuild-it ../out/cloud-init_20.2-30-g8bcf1c06*dsc` | 20:21 |
| lucasmoura | Odd_Bloke, Now I see it. I think the best approach is allowing this to be configurable at runtime by users. But how should we proceed in making this configurable ? I initially thought about adding it to cloud.cfg, but the user can interact with it somehow ? | 20:22 |
| blackboxsw | I think this is the last step to validate that we can in fact upload a new-upstream-snapshot to the devel release. I pushed the changeset for a follow up review https://github.com/canonical/cloud-init/pull/373/files#diff-d837a1c17de0268bcea321239ddbed47 | 20:23 |
| blackboxsw | lucasmoura: mentioned that he had a different debian/changelog in his review of 373. I think tomorrow I'd like to walk through that new-upstream-snapshot creation if we could to see what diffs you were seeing lucasmoura. | 20:24 |
| Odd_Bloke | lucasmoura: So presumably we will have this new behaviour enabled by default in groovy. Under what circumstances would we want users to be able to switch back to the old behaviour? | 20:25 |
| Odd_Bloke | (Apologies for the Socractic method I'm employing here. ;) | 20:25 |
| lucasmoura | blackboxsw, I made a mistake when I reviewed that. Originally I thought that changelog was auto-generated, but after commenting that I spotted the differance, I realized that there is a commit that updates it | 20:29 |
| lucasmoura | So I don't think I have spotted anything unusual, I was just forgot that the changelog is not produce automatically as shown in the PR | 20:30 |
| blackboxsw | ahh; ok. that works. ok then I think we are fine here. I'll have a couple of other prs for folks to review in a moment dropping pyflakees from debian/control on all the other ubuntu/* branches we continue support for downstream releases | 20:30 |
| lucasmoura | Odd_Bloke, hahah no problem. But what about if we create a new config on apt configure module that enables and disables ec2 mirrors ? | 20:43 |
| lucasmoura | In this cc_configure_module function https://github.com/canonical/cloud-init/blob/master/cloudinit/config/cc_apt_configure.py#L946 we can see if the ec2 mirror is disabled and filter out the mirrors | 20:49 |
| lucasmoura | We just need to guarantee that this config will always be true for ec2 instances, but I don't know if I config modules should perform actions based on the type of instance we are running | 20:52 |
| Odd_Bloke | lucasmoura: You may also want to look at https://github.com/canonical/cloud-init/blob/master/cloudinit/distros/__init__.py#L845-L848 | 21:04 |
| lucasmoura | Yes, I have seen it when I was trying to understand how the mirrors were parsed from the cloud.cfg file. Do I still don't get your suggestion, do you think we alter the regex to not set the ec2_region ? Do we mean that we should allow this regex to be configurable ? | 21:09 |
| Odd_Bloke | lucasmoura: Sorry, give me a few minutes to finish up my response to Ryan's networking refactor comment, then you can have my full attention. | 21:13 |
| lucasmoura | Odd_Bloke, no worries | 21:13 |
| ACHLO | https://youtu.be/QokZbqwcHwc | 21:39 |
| Odd_Bloke | lucasmoura: OK, so "a few minutes" was evidently optimistic. I don't really have this code in my brain at the moment (though I have touched it recently), shall we hop on a video call and pair for a bit tomorrow so we can investigate it together? | 21:41 |
| lucasmoura | Odd_Bloke, Okay, no problem | 21:42 |
| Odd_Bloke | rharper: meena: Just dropped a long response to Ryan's comment into https://github.com/canonical/cloud-init/pull/363 (enjoy the read ;) | 22:00 |
| rharper | Odd_Bloke: thanks! | 22:04 |
| sodapop | I'm trying to append to profile.d this line-> declare -x PATH=$PATH:$JAVA_HOME/bin | 23:48 |
| sodapop | can I somehow write it as is and not the expanded | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!