Automatic Network Configuration in Cloud with NetworkManager
(nm-cloud-setup)
by Thomas Haller
Hello,
We (NetworkManager) are working on a tool that should help configuring
NetworkManager in cloud.
This is for example for configuring the secondary IP addresses on
AWS/EC2 ([1], [2])
[1] https://aws.amazon.com/premiumsupport/knowledge-center/ec2-centos-rhel-se...
[2] https://aws.amazon.com/premiumsupport/knowledge-center/ec2-ubuntu-seconda...
It's inspired by and serves a similar purpose as SuSE's cloud-netconfig
([3], [4]) and ec2-net-utils package on Amazon Linux ([5]).
[3] https://www.suse.com/c/multi-nic-cloud-netconfig-ec2-azure/
[4] https://github.com/SUSE-Enceladus/cloud-netconfig
[5] https://github.com/aws/ec2-net-utils
The tool can be triggered via a systemd.timer and/or a NetworkManager
dispatcher scripts. Then it fetches meta data from the Instance
Metadata Service (thereby detecting whether it runs in a cloud
environment). Finally it configures the networking using
NetworkManager.
Currently it only supports EC2 and IPv4. But if the tool shows to be
useful, it could be extended to also support other cloud providers
(Azure).
There is a merge request on review ([6], [7]). There is a bit of a
hurry to get this merged, because it should make the cut for the next
NetworkManager release. So, I will merge it soon to master, albeit
still in an experimental state.
[6] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_reques...
[7] https://bugzilla.redhat.com/show_bug.cgi?id=1642461
The plan is that cloud images could install and enable the tool, so you
boot a (Fedora) image and networking would just work.
Is there interrest in something like this? Any comments, questions?
best,
Thomas
4 years, 3 months
Re: Fedora Atomic Host Nearing End Of Life
by Dusty Mabe
On 11/25/19 11:41 AM, Normand wrote:
>
>
> On 11/21/19 11:33 PM, Dusty Mabe wrote:
>> This content also exists at: https://www.projectatomic.io/blog/2019/11/fedora-atomic-host-nearing-eol/
>>
>> Last year we [introduced the plans for Fedora CoreOS] [1] including that
>> Fedora CoreOS would be the successor to Fedora Atomic Host and Container
>> Linux (from CoreOS Inc.). As part of that succession plan we decided that
>> Fedora 29 Atomic Host would be the last stream of Fedora Atomic Host to be
>> released.
>>
>> Fedora 29 Atomic Host has served us well, but with Fedora 29 End of
>> Life coming soon [2], so will the last release of Fedora 29 Atomic Host.
>> The next release of Fedora 29 Atomic Host (in the next few weeks) will be
>> the last two-week release. It will contain all of the latest content
>> from Fedora 29. After that release, Fedora 29, and Fedora 29 Atomic
>> Host will no longer receive any updates.
>>
>> Please try out the Fedora CoreOS preview to help us get it towards
>> stable. Documentation and download links can be found at https://getfedora.org/coreos/
>>
>> The Atomic Host Team
>>
>> [1] https://fedoramagazine.org/announcing-fedora-coreos/
>> [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>> _______________________________________________
>> devel mailing list -- devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
>
> Thanks for the info,
>
> But what about arches that are not x86_64 ?
> Where could we found for exemple the ppc64le coreos replacement of
> Atomic Host ? Is there already a web page to retrieve them ?
>
Hi Normand,
Thank you for bringing this up. You have indeed pointed out a gap in what we're currently
delivering with Fedora CoreOS preview and what we were delivering with Atomic Host. The good
news is that we have done enablement work to allow for Fedora CoreOS to be run on other
platforms. The bad news is that we don't currently run our build infrastructure in an environment
that has other architectures available.
So while you can build it yourself today, there is currently no where to download it from the Fedora
website. I have added Jakub Cajka who was working on getting some space to host unofficial builds of
Fedora CoreOS for other architectures for now. I'll also link you to our open issues where we're working
through our strategy for delivering multi-arch FCOS:
- https://github.com/coreos/fedora-coreos-tracker/issues/262
- https://pagure.io/fedora-infrastructure/issue/8370
- Dusty
4 years, 3 months
Validation testing enhancement: AMI information
by Adam Williamson
Hey folks!
So as part of the 'xen -> ec2' criteria migration, I noticed that it's
not really easy to find the appropriate AMIs for testing validation
candidate composes in EC2. I decided to make that better!
I've enhanced wikitcms to be capable of generating a template page
containing AMI IDs for a given validation event, much like the page
which has all the image download links in it. I tweaked the wiki
validation instructions template to transclude that page in Cloud
validation pages (but not other validation pages, to avoid clutter and
confusion), and wrote a fedora-messaging consumer which should update
the AMI info page every time a new AMI image is published for a
validation candidate compose. So basically, when you look at the Cloud
validation page, you should see some handy tables with all the relevant
AMI IDs (and direct launch links).
Here's how it looks for the current validation event:
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20191109.n....
I hope it'll keep working as new validation events show up, I'll try
and keep an eye on it.
Note this gets its data from the messages published by fedimg, so it
will *not* include any images *not* published by fedimg. This may
become an issue when CoreOS becomes release blocking, I guess.
If anyone's interested in the implementation details here, the new
consumer is in relvalconsumer:
https://pagure.io/fedora-qa/relvalconsumer/c/3ceac217bc90a9d29bb8d7c6156e...
the other changes were in wikitcms:
https://pagure.io/fedora-qa/python-wikitcms/c/49f450c19418adf82d9d0713551...
and the wiki release validation instructions template:
https://fedoraproject.org/w/index.php?title=Template%3ARelease_validation...
Let me know if you see any problems or have any suggestions for this.
thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4 years, 4 months
Re: [Xen-devel] Criteria / validation proposal: drop Xen
by Adam Williamson
On Thu, 2019-07-11 at 14:19 -0700, Adam Williamson wrote:
> On Thu, 2019-07-11 at 21:43 +0100, Peter Robinson wrote:
> > > On Mon, 2019-07-08 at 09:11 -0700, Adam Williamson wrote:
> > > > It's worth noting that at least part of the justification for the
> > > > criterion in the first place was that Amazon was using Xen for EC2, but
> > > > that is no longer the case, most if not all EC2 instance types no
> > > > longer use Xen.
> > >
> > > I don't know where you got that particular piece of information. It
> > > isn't correct. Most EC2 instance types still use Xen. The vast majority
> > > of EC2 instances, by volume, are Xen.
> >
> > Correct, it's only specific types of new hypervisors that use kvm
> > based, plus new HW like aarch64.
> >
> > That being said I don't believe testing we can boot on xen is actually
> > useful these days for the AWS use case, it's likely different enough
> > that the testing isn't useful, we'd be much better testing that cloud
> > images actually work on AWS than testing if it boots on xen.
>
> Yeah, that's where I was going to go next (there has already been a
> thread about this this morning). If what we care about is that Fedora
> boots on EC2, that's what we should have in the criteria, and what we
> should test.
>
> IIRC, what we have right now is a somewhat vague setup where we just
> have 'local', 'ec2' and 'openstack' columns. The instructions for
> "Amazon Web Services" just say "Launch an instance with the AMI under
> test". So we could probably stand to tighten that up a bit, and define
> specific instance type(s) that we want to test/block on.
OK, so, to move forward with this (and looping in cloud list): does
someone want to propose a set (ideally small - 2 would be great, one
Xen and one non-Xen, if we can cover most common usages that way!) of
EC2 instance types we should test on? With that, we could tweak the
criteria a bit to specify those instance types, tweak the Cloud
validation page a bit, and then drop the Xen criterion and test case.
Thanks everyone!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4 years, 4 months