Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  kushal
 Type:  task  |  Status:  closed
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:  fixed
 Keywords:|
--+
Changes (by kushal):

 * status:  accepted => closed
 * resolution:   => fixed


Comment:

 Closing this ticket as part of trac clean up process. If you want to
 reopen, please reopen it after we move to pagure.io as atomic-wg.

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  kushal
 Type:  task  |  Status:  accepted
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by kushal):

 During the Cloud WG meeting on 2015-01-06 it was decided that we come back
 to this ticket during Fedora 25 time.

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  kushal
 Type:  task  |  Status:  accepted
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by mhayden):

 FWIW, I'm putting together a talk proposal for RH Summit 2016 to
 teach/demo systemd-networkd. If anyone has any feedback on that, I'm all
 ears. ;)

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  kushal
 Type:  task  |  Status:  accepted
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by mhayden):

 Tried to add a bunch of notes:

 * https://fedoraproject.org/wiki/Cloud/Network-Requirements

 Feedback?

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  kushal
 Type:  task  |  Status:  accepted
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+
Changes (by roshi):

 * keywords:  meeting =>


-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  kushal
 Type:  task  |  Status:  accepted
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by maxamillion):

 As a side note, just to add the mhayden's update. He's written a lot of
 great blog posts about using systemd-networkd in a number of use cases.

 https://major.io/?s=networkd

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  kushal
 Type:  task  |  Status:  accepted
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by maxamillion):

 Also, action item from 2015-09-23 Cloud SIG meeting is to request mhayden
 to do a formal write up of the comparison between NetworkManager and
 systemd-nspawn with different use cases and/or performance metrics (where
 applicable) since he appears to be the most experienced in the topic
 space.

 https://twitter.com/TheMaxamillion/status/646737193839423488

 https://meetbot.fedoraproject.org/fedora-
 meeting-1/2015-09-23/cloud_wg.2015-09-23-17.00.html
 http://meetbot.fedoraproject.org/fedora-
 meeting-1/2015-09-23/cloud_wg.2015-09-23-17.00.txt

-- 
Ticket URL: 
cloud 
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  kushal
 Type:  task  |  Status:  accepted
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:  meeting   |
--+

Comment (by mhayden):

 Kushal and I talked about this proposal in detail at Flock for the cloud
 images.  While it's great for server devices that aren't going to be
 moving around often, it's not ideal for laptops or desktops that change
 their physical location frequently.  NetworkManager makes a lot more sense
 there.

 I spoke with zbyszek about improving the documentation around systemd-
 networkd as well.  Much of the documentation is very focused and doesn't
 speak to full use cases where you're creating multiple .netdev and
 .network (and perhaps .link) files.

 With that said, I've been using systemd-networkd instead of NetworkManager
 on 10-20 production cloud instances, over 250 hypervisors, and several
 other physical systems since Fedora 21.  Other than the bonding
 shenanigans (fixed in systemd 216), I haven't seen any issues.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:45
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  kushal
 Type:  task  |  Status:  accepted
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:  meeting   |
--+

Comment (by dustymabe):

 In discussions about this we often bring up the need to have a set of
 requirements on network that the cloud images (and cloud environments)
 have. I have sent an email to the list [1] to solicit input and roshi has
 created a wiki page [2] for us to add information to.

 [1] -
 https://lists.fedoraproject.org/pipermail/cloud/2015-August/005670.html
 [2] - https://fedoraproject.org/wiki/Cloud/Network-Requirements

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:44
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  kushal
 Type:  task  |  Status:  accepted
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:  meeting   |
--+

Comment (by mattdm):

 NetworkManager has come a long way since I filed this, with a lot of work
 on paring down for minimal use cases.

 Maybe a crazy idea, but perhaps we could do a systemd-networkd vs
 NetworkManager showdown for the F23 Alpha, and then decide on one for F23
 Beta based on results.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:43
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  kushal
 Type:  task  |  Status:  accepted
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:  meeting   |
--+

Comment (by gholms):

 While networkd is certainly suited to simple network setups like those of
 most clouds, we need to keep the consequences of using it within the
 broader context of Fedora in mind.  Every other Fedora build, including
 Atomic, uses !NetworkManager to address the issues this feature aims to
 address, so choosing to use something else incurs costs that we should
 acknowledge:

 1. Network configuration will not be compatible with Fedora Workstation.
 As that is Fedora's development environment, this conflicts with the
 [https://fedoraproject.org/wiki/Cloud/Cloud_PRD Cloud PRD]'s goal of
 avoiding compatibility issues or surprises from differences in the
 environment.  Perhaps we could make this change in concert with
 Workstation.
 1. Network configuration will not be compatible with Fedora Server.  The
 cloudtoserver script could handle migration from networkd to NM, or the
 Server SIG could simply acknowledge that some fraction of Fedora Server
 users will wind up using networkd.
 1. Network configuration will not be compatible with Fedora Atomic.  This
 may not actually be a big deal, but shipping two cloud products that use
 incompatible means of configuring networking is somewhat surprising.
 1. This adds another tree of potential errors and breakage.  Using the
 same technology across multiple products benefits all of Fedora because
 they can share the testing burden.  This is unfamiliar code; we will need
 additional test cases to cover it and it will take some time and effort
 for people to spin up on it so they can debug it and provide feedback more
 useful than, It doesn't work.
 1. This adds another tree of documentation since networkd can't use NM
 configuration files.

 We can address nearly all of these issues with a systemd
 [https://bugzilla.redhat.com/show_bug.cgi?id=1090090 generator] that reads
 the ifcfg-* files that NM uses.  People won't be able to use nmcli, but
 ifcfg files are still well-understood and what we configure NM to emit
 anyway.

 As for the additional testing burden, we probably just need to get QA buy-
 in.  Has anyone from QA chimed in on this feature yet?

 To be clear, I'm not against using networkd here, but the feature page is
 quite light on details like these that ought to be acknowledged.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:42
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  kushal
 Type:  task  |  Status:  accepted
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:  meeting   |
--+
Changes (by kushal):

 * keywords:   = meeting
 * status:  new = accepted
 * owner:  janeznemanic = kushal


-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:39
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  kushal
 Type:  task  |  Status:  accepted
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:  meeting   |
--+

Comment (by kushal):

 I have tested this on a running instance, will submit the F23 change page
 tomorrow. Just wondering if this should be a contained change or the
 system wide change?

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:40
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  kushal
 Type:  task  |  Status:  accepted
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:  meeting   |
--+

Comment (by dustymabe):

 Replying to [comment:40 kushal]:
  I have tested this on a running instance, will submit the F23 change
 page tomorrow. Just wondering if this should be a contained change or the
 system wide change?

 If we are talking about moving exclusively to systemd-networkd I don't
 think it makes sense as a systemwide change. There are a lot of benefits
 that NetworkManager gives for other use cases that make sense. systemd-
 networkd makes sense for cloud I think. The one use case that we had for
 systemd-networkd not behaving was cases where people plop down their own
 network files in the image (in /etc/sysconfig/network-scripts). Ideally
 we'd like to have systemd-networkd handle this and there was discussion of
 doing this (see https://bugzilla.redhat.com/show_bug.cgi?id=1194623).

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:41
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by janeznemanic):

 This has been on my mind for some time now. I have been wondering if all
 the scripts currently in /etc/sysconfig/network-scripts are needed in
 cloud environment? For example do we need if{up,down}-{isdn,bnep} scripts
 in cloud image?

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:36
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by janeznemanic):

 @mattdm - So I guess there is nothing else to do at the moment then to
 wait for generator.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:35
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by mattdm):

 janeznemanic - you need special permissions to build images in koji. We
 can check with release engineering about getting you permission to do at
 least scratch builds in this way.

 Also, FESCo wants me to let you know that there is some skepticism with
 doing this change for f21, and that ifcfg compatibility is probably a
 must-have.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:34
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by janeznemanic):

 Systemd-networkd enabled, initscripts and dhclient removed. Why do we use
 rsyslog and not systemd's journald?
 Let me try and build image with koji.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:27
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by gospo):

 Replying to [comment:8 mattdm]:
 
  If there were a generator for systemd-networkd which could read the
 basic values from the legacy files and create network units on the fly
 (akin to systemd-fstab-generator), that would level that advantage. (No
 need to implement the full syntax; just basic static and dhcp, plus log
 when something isn't understood and perhaps recommend NetworkManager for
 this cases.) And ifup/ifdown compatibility scripts would be nice (although
 I don't think we generally care for the cloud case)

 Sorry, but I miss why we would want to use the legacy files used by
 initscipts for networkd?  If we are concerned about the ability to migrate
 from networkd to NM we should probably consider a plug-in for NM to read
 networkd files.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:30
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by mattdm):

 Replying to [comment:30 gospo]:
  Sorry, but I miss why we would want to use the legacy files used by
 initscipts for networkd?  If we are concerned about the ability to migrate
 from networkd to NM we should probably consider a plug-in for NM to read
 networkd files.

 Many people are used to these files being *the* Fedora (and Red Hat
 distribution family) way to configure network interfaces. Their Puppet
 modules and Chef recipies work this way. In fact, the upstream code
 includes modules that understand this format natively. Tools like ec2-net-
 utils do too. All of our existing documentation talks about these files.
 And, it's already a common language between initscripts and Network
 Manager.

 I don't think we would be doing anyone any favors by making Fedora a
 special case. In the future, if systemd-networkd becomes common and native
 tool support is widespread, it'll be easy to transition people.

 In the future

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:31
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by gospo):

 Replying to [comment:31 mattdm]:
  Replying to [comment:30 gospo]:
   Sorry, but I miss why we would want to use the legacy files used by
 initscipts for networkd?  If we are concerned about the ability to migrate
 from networkd to NM we should probably consider a plug-in for NM to read
 networkd files.
 
  Many people are used to these files being *the* Fedora (and Red Hat
 distribution family) way to configure network interfaces. Their Puppet
 modules and Chef recipies work this way. In fact, the upstream code
 includes modules that understand this format natively. Tools like ec2-net-
 utils do too. All of our existing documentation talks about these files.
 And, it's already a common language between initscripts and Network
 Manager.
 
  I don't think we would be doing anyone any favors by making Fedora a
 special case. In the future, if systemd-networkd becomes common and native
 tool support is widespread, it'll be easy to transition people.
 

 Ah yes, I agree, then.  Thanks for the explanation.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:32
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by red):

 Replying to [comment:24 mattdm]:

  I haven't looked into it myself, but it's my understanding that systemd
 has or will have its _own_ dhcp client, which raises some concerns about
 compatibility testing but is also interesting on its own because on our
 current cloud image, dhclient is by far the largest single memory
 consumer. If systemd has a more lightweight dhcp client, that's a valuable
 plus in itself.

 Before I've written comment:22, I removed both initscripts and dhclient
 from a F20 image that I upgraded to Rawhide, and it worked just fine with
 systemd-networkd (in a non-cloud VM, i.e. there also was no cloud-init).

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:25
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by janeznemanic):

 Here is the kickstart file. I added few lines at the end of file. Have a
 look at it and let me know if something is wrong.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:20
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by mattdm):

 Replying to [comment:17 janeznemanic]:
  So what's the plan here? How do we proceed? What shall I do?

 It might be useful to put together a variant of the kickstart file used to
 produce the current cloud image which uses systemd-networkd for eth0
 instead of initscripts. See https://git.fedorahosted.org/cgit/spin-
 kickstarts.git/tree/fedora-cloud-base.ks and basically search for
 network for parts that might need to be changed.

 Then, you should be able to feed that kickstart file into ImageFactory (or
 appliance-creator) and get a qcow2 image we can test.

 I suppose that someone should file an RFE for systemd to have a
 generator (that's a typical systemd construct) for handling legacy ifcfg
 files (as above), and to create the ifup/ifdown compatibility scripts.
 Most ideally, someone will contribute that as patches to systemd upstream,
 because code always speaks louder than wishes :) but, just explaining what
 we need is a good start.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:18
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by gospo):

 Replying to [comment:3 janeznemanic]:
  Report on my work.
 [...]
 
  I did some research on scripts in /etc/sysconfig/network-scripts. All
 those scripts depend on ifcfg-* files in the same directory. But systemd-
 networkd doesn't use ifcfg-* files. I removed ifcfg-* files and systemd-
 netword worked fine. I was also able to ping google. But if I tried to use
 for example ifup or ifdown script then that script failed. Because it
 couldn't source ifcfg-*. I think so, I might be wrong. Since ifup and
 ifdown are links to /usr/sbin/{ifup,ifdown} it might be possible to remove
 /usr/sbin/{ifup,ifdown}. But I haven't tested that so I'm not sure. I
 think we also don't need to use /etc/rc.d/init.d/network. I removed that
 file and networking worked fine with systemd-networkd.
 
  So to sum up. If systemd-networkd service is used it is possible in my
 opinion to remove scripts in /etc/sysconfig/network-scripts and
 /etc/rc.d/init.d/network script. Besides that it is possible to remove
 NetworkManager.
 
 I took a quick look at the files from initscripts that are likely
 networking related.  It seems possible to remote these from initscripts
 core and (as Johannes suggested above) possibly break initscripts out into
 a new package.  If there was a desire to add the missing functionality to
 networkd that is currently in initscripts then the new initscripts package
 could be slowly whittled away to nothing when ppp and netconsole support
 are added to networkd (that appears to be the only missing functionality).

 /etc/NetworkManager
 /etc/NetworkManager/dispatcher.d
 /etc/NetworkManager/dispatcher.d/00-netreport
 /etc/networks
 /etc/ppp
 /etc/ppp/ip-down
 /etc/ppp/ip-down.ipv6to4
 /etc/ppp/ip-up
 /etc/ppp/ip-up.ipv6to4
 /etc/ppp/ipv6-down
 /etc/ppp/ipv6-up
 /etc/ppp/peers
 /etc/rc.d/init.d/netconsole
 /etc/rc.d/init.d/network
 /etc/sysconfig/netconsole
 /etc/sysconfig/network-scripts
 /etc/sysconfig/network-scripts/*
 /usr/bin/ipcalc
 /usr/lib/udev/rename_device
 /usr/lib/udev/rules.d/60-net.rules
 /usr/libexec/initscripts
 /usr/libexec/initscripts/legacy-actions
 /usr/sbin/ifdown
 /usr/sbin/ifup
 /usr/sbin/netreport
 /usr/sbin/ppp-watch
 /usr/sbin/usernetctl
 /usr/share/doc/initscripts/changes.ipv6
 /usr/share/doc/initscripts/ipv6-6to4.howto
 /usr/share/doc/initscripts/ipv6-tunnel.howto
 /usr/share/doc/initscripts/static-routes-ipv6
 /usr/share/man/man1/genhostid.1.gz
 /usr/share/man/man1/ipcalc.1.gz
 /usr/share/man/man1/netreport.1.gz
 /usr/share/man/man8/ifdown.8.gz
 /usr/share/man/man8/ifup.8.gz
 /usr/share/man/man8/ppp-watch.8.gz}}}


  '''Thoughts? Suggestions? Ideas?'''
 
  One more thing that's been bothering me for a few days now. How does
 systemd name network interfaces when Fedora is run on top of different
 hypervisors? If xen or kvm is used how does systemd name network
 interfaces?

 Systemd will name the device based on the bus/device/function of the
 interfaces, so there could be some differences in the name chosen
 depending on the hypervisor used (since each hypervisor may chose a
 difference bus/dev/function for a given emulated interface.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:5
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by mattdm):

 Replying to [comment:5 gospo]:
   One more thing that's been bothering me for a few days now. How does
 systemd name network interfaces when Fedora is run on top of different
 hypervisors? If xen or kvm is used how does systemd name network
 interfaces?
 
  Systemd will name the device based on the bus/device/function of the
 interfaces, so there could be some differences in the name chosen
 depending on the hypervisor used (since each hypervisor may chose a
 difference bus/dev/function for a given emulated interface.

 It's important to note that the Fedora Cloud image, we disable this
 feature (ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules),
 because systemd's priority is consistency of naming when there are
 multiple interfaces on the same system. By and large, our concern is with
 consistency of a *single* device name whereever the image boots, so the
 network interface is traditional eth0 (or eth* if more than one).

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:7
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by mattdm):

 Also, note that we are not using NetworkManager -- we're using the
 traditional network initscripts. It would be nice to eventually move away
 from these, and I don't have a strong view over which one should win (once
 NetworkManager gains the ability to configure a dhcp interface and then
 stop running).

 From my (cloud SIG) point of view, NetworkManager has the disadvantage of
 being dependency heavy (and the run-once mode is not yet done -- see
 https://bugzilla.redhat.com/show_bug.cgi?id=863515), but the significant
 advantage of parsing the existing config files.

 If there were a generator for systemd-networkd which could read the basic
 values from the legacy files and create network units on the fly (akin to
 systemd-fstab-generator), that would level that advantage. (No need to
 implement the full syntax; just basic static and dhcp, plus log when
 something isn't understood and perhaps recommend NetworkManager for this
 cases.) And ifup/ifdown compatibility scripts would be nice (although I
 don't think we generally care for the cloud case)

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:8
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by gospo):

 Replying to [comment:7 mattdm]:
 
  It's important to note that the Fedora Cloud image, we disable this
 feature (ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules),
 because systemd's priority is consistency of naming when there are
 multiple interfaces on the same system. By and large, our concern is with
 consistency of a *single* device name whereever the image boots, so the
 network interface is traditional eth0 (or eth* if more than one).

 I was thinking about the fact that the slot-naming-rules could be modified
 so that the first NIC found was named em1, second em2, etc, but disabling
 the rules completely seems fine.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:9
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by johannbg):

 As Matt points out we lack any kind of ifcfg-generator we also lack
 tunnelling support etc so I suggest people *wait* until the networkd code
 in systemd stabilizes before proceeding any further with this

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:10
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by janeznemanic):

 Replying to [comment:6 gospo]:
  Replying to [comment:3 janeznemanic]:
   But if I tried to use for example ifup or ifdown script then that
 script failed. Because it couldn't source ifcfg-*. I think so, I might be
 wrong. Since ifup and ifdown are links to /usr/sbin/{ifup,ifdown} it might
 be possible to remove /usr/sbin/{ifup,ifdown}. But I haven't tested that
 so I'm not sure. I think we also don't need to use
 /etc/rc.d/init.d/network. I removed that file and networking worked fine
 with systemd-networkd.
  
  Sorry, I forgot to address this in my last post.  As was mentioned above
 there are some who will want to preserve some of the ability to use
 ifup/ifdown in some manner.  I know that controlling the network
 interfaces is a current TODO for networkd, but it would seem reasonable
 that the networkd unit can be stopped/started or restarted if one wanted
 to reset the network config, correct?

 You can do ''systemctl {start,stop,restart} systemd-networkd.service'' to
 control networking.
 I'm not fedora networking expert, but I think it is possible to use ip
 command instead of ifup/ifdown to bring interface up or down.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:11
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by mattdm):

 Replying to [comment:10 johannbg]:
  As Matt points out we lack any kind of ifcfg-generator we also lack
 tunnelling support etc so I suggest people *wait* until the networkd code
 in systemd stabilizes before proceeding any further with this

 Let's start collecting a list of basic requirements. Just to brainstorm a
 bit

 * Single eth0 interface with DHCP
 * Possible other interfaces, also with DHCP (common in OpenNebula)
 * Static ipv4 configuration
 * ipv6?
 * Nice-to-have: ifcfg compatibility (basic config files, ifup/ifdown
 commands)

 Some use cases for basic use and for more advanced functionality like
 tunneling would help make a prioritized list.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:13
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by janeznemanic):

 Replying to [comment:8 mattdm]:
  Also, note that we are not using NetworkManager -- we're using the
 traditional network initscripts. It would be nice to eventually move away
 from these, and I don't have a strong view over which one should win (once
 NetworkManager gains the ability to configure a dhcp interface and then
 stop running).
 
  From my (cloud SIG) point of view, NetworkManager has the disadvantage
 of being dependency heavy (and the run-once mode is not yet done -- see
 https://bugzilla.redhat.com/show_bug.cgi?id=863515), but the significant
 advantage of parsing the existing config files.
 
  If there were a generator for systemd-networkd which could read the
 basic values from the legacy files and create network units on the fly
 (akin to systemd-fstab-generator), that would level that advantage. (No
 need to implement the full syntax; just basic static and dhcp, plus log
 when something isn't understood and perhaps recommend NetworkManager for
 this cases.) And ifup/ifdown compatibility scripts would be nice (although
 I don't think we generally care for the cloud case)

 Found out today on mailing list that cloud image is not using
 NetworkManager?. To me the idea of having both NetworkManager? and
 systemd-networkd in the cloud image is a little bit strange since both are
 network managers. I assume that NetworkManager? is superior to systemd-
 networkd, but I think systemd-networkd does it's job good in virtualized
 environment. Anyway I'm not an expert so that's just my opinion.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:14
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by janeznemanic):

 Replying to [comment:13 mattdm]:
  Replying to [comment:10 johannbg]:
   As Matt points out we lack any kind of ifcfg-generator we also lack
 tunnelling support etc so I suggest people *wait* until the networkd code
 in systemd stabilizes before proceeding any further with this
 
  Let's start collecting a list of basic requirements. Just to brainstorm
 a bit
 
  * Single eth0 interface with DHCP
  * Possible other interfaces, also with DHCP (common in OpenNebula)
  * Static ipv4 configuration
  * ipv6?
  * Nice-to-have: ifcfg compatibility (basic config files, ifup/ifdown
 commands)
 
  Some use cases for basic use and for more advanced functionality like
 tunneling would help make a prioritized list.

 Which other interfaces do you have in mind? Bridge?

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:16
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by janeznemanic):

 Report on my work.

 First I had to learn a little bit about systemd. What is all about, how
 does it work etc. Then I focused on networking subsystem in Fedora and
 tried to understand how it works. After setting my little lab environment
 I started with hands on approach.

 My test environment:
 - host system: 32 bit Fedora 20
 - hypervisor: VirtualBox
 - guest system: 32 bit Fedora 20
 - systemd release: rawhide

 My experiment and current findings

 I disabled Gnome's NetworkManager, NetworkManager-dispatcher and
 NetworkManager-wait-online and dropped network configuration file into
 /usr/lib/systemd/network. The content of this file is:

 [Match]
 Name=p*

 [Network]
 DHCP=yes

 Systemd names network interface p2p1 on my guest Fedora. So that's why I
 used Name=p*. That's the most simple and basic network configuration with
 systemd-networkd. I think that DHCP is also default configuration in
 desktop Fedora 20. I restarted systemd-networkd service and I could ping
 www.google.com and do DNS look up with dig. Ping and dig work as you would
 expect on my guest and on my host system.

 I did some research on scripts in /etc/sysconfig/network-scripts. All
 those scripts depend on ifcfg-* files in the same directory. But systemd-
 networkd doesn't use ifcfg-* files. I removed ifcfg-* files and systemd-
 netword worked fine. I was also able to ping google. But if I tried to use
 for example ifup or ifdown script then that script failed. Because it
 couldn't source ifcfg-*. I think so, I might be wrong. Since ifup and
 ifdown are links to /usr/sbin/{ifup,ifdown} it might be possible to remove
 /usr/sbin/{ifup,ifdown}. But I haven't tested that so I'm not sure. I
 think we also don't need to use /etc/rc.d/init.d/network. I removed that
 file and networking worked fine with systemd-networkd.

 So to sum up. If systemd-networkd service is used it is possible in my
 opinion to remove scripts in /etc/sysconfig/network-scripts and
 /etc/rc.d/init.d/network script. Besides that it is possible to remove
 NetworkManager.

 '''Thoughts? Suggestions? Ideas?'''

 One more thing that's been bothering me for a few days now. How does
 systemd name network interfaces when Fedora is run on top of different
 hypervisors? If xen or kvm is used how does systemd name network
 interfaces?

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:3
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by johannbg):

 For the first always use /etc/systemd/system never /usr/lib/systemd --
 this is for packages and will get overwritten flushed out on updates
 secondly we will be migrating everything to network units when the time is
 right as well as splitting out and removing the remaining parts of the
 legacy sysv initscript if that work wont be halted by traditionalists (
 initscript contain for example the chkconfig/service command ) within and
 outside Red Hat as well as RHEL 8 since there seems to be somekind of
 internal RH dispute going on determine how the future of network should
 look like in products which is being kept on need to know bases.

 Anyway split probably will end up somewhere along these lines

 initscript

 Requires changes in the FPG

 initscripts-doc
 initscripts-man
 initscripts-locale
 initscripts-network

 Split into it's own package outside initscript

 netconsole
 netreport
 ppp
 systemd-fedora

 These changes along with other necessary once that might never be allowed
 to be implemented in Fedora due to RHEL but should be, will land in a
 core/baseOS copr repo which should emerge as soon as copr starts
 supporting groups in FAS ( we dont want to tie this to a single individual
 ) which the cloud community could use for testing and what not and at that
 same time it will also probably emerge a test repository which will
 contain the latest systemd release for GA releases as well.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:4
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by janeznemanic):

 Just to let everybody know I am still working on this ticket. Slowly I am
 making progress.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:1
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [cloud] #14: Investigate systemd-networkd

[Fedora Cloud Trac Tickets]

#14: Investigate systemd-networkd
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by mattdm):

 Cool, thanks. Any particular blockers? We can try it in rawhide when
 you're ready.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14#comment:2
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[cloud] #14: Investigate systemd-networkd

[cloud]

#14: Investigate systemd-networkd
--+---
 Reporter:  mattdm|  Owner:  janeznemanic
 Type:  task  | Status:  new
 Priority:  normal|  Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |   Keywords:
--+---
 * What: new service to do very basic network config
 * Where: remove the sysv network scripts, add config for this
 * Why: remove very kludgey shell scripts; try the new hotness
 * When: Before F21 alpha
 * Who: Janez Nemanic

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/14
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct