Re: [cloud] #24: File F21 change: Big Data Image

2014-04-05 Thread Fedora Cloud Trac Tickets
#24: File F21 change: Big Data Image
+---
 Reporter:  mattdm  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Fedora 21 (Feature Deadline)
Component:  Big Data Image  |  Resolution:
 Keywords:  |
+---

Comment (by mattdm):

 Replying to [comment:9 jeid64]:
  Mattdm, I can own this ticket and work on it.

 Awesome, thanks. hguemar, do you want to be co-owner?

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/24#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] #20: File F21 change: Adopt-Your-Cattle

2014-04-07 Thread Fedora Cloud Trac Tickets
#20: File F21 change: Adopt-Your-Cattle
-+-
 Reporter:  mattdm   |   Owner:  mattdm
 Type:  task |  Status:  assigned
 Priority:  normal   |   Milestone:  Fedora 21 (Feature
Component:  Collaboration   |  Deadline)
  Communication  |  Resolution:
 Keywords:   |
-+-
Changes (by mattdm):

 * status:  new = assigned
 * owner:   = mattdm


-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/20#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] #20: File F21 change: Adopt-Your-Cattle

2014-04-07 Thread Fedora Cloud Trac Tickets
#20: File F21 change: Adopt-Your-Cattle
-+-
 Reporter:  mattdm   |   Owner:  mattdm
 Type:  task |  Status:  closed
 Priority:  normal   |   Milestone:  Fedora 21 (Feature
Component:  Collaboration   |  Deadline)
  Communication  |  Resolution:  fixed
 Keywords:   |
-+-
Changes (by mattdm):

 * resolution:   = fixed
 * status:  assigned = closed


Comment:

 This one is submitted. sgallagh is co-owner.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/20#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


Re: [cloud] #33: File F21 change: use %license for cloud image packages

2014-04-07 Thread Fedora Cloud Trac Tickets
#33: File F21 change: use %license for cloud image packages
--+---
 Reporter:  mattdm|   Owner:  mattdm
 Type:  task  |  Status:  closed
 Priority:  normal|   Milestone:  Fedora 21 (Feature Deadline)
Component:  Cloud Base Image  |  Resolution:  fixed
 Keywords:|
--+---
Changes (by mattdm):

 * resolution:   = fixed
 * status:  assigned = closed


Comment:

 change filed.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/33#comment:6
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] #26: File F21 change: Docker Container Image

2014-04-07 Thread Fedora Cloud Trac Tickets
#26: File F21 change: Docker Container Image
---+---
 Reporter:  mattdm |   Owner:
 Type:  task   |  Status:  new
 Priority:  major  |   Milestone:  Fedora 21 (Feature Deadline)
Component:  Docker Base|  Resolution:
  Container|
 Keywords: |
---+---

Comment (by mattdm):

 Elements of this:

 1. get the support into koji for making images (currently there as an
 imagefactory plugin)
 2. if necessary, update to $SOMENEWTHING - Stephen Tweedie is working on
 an rpm specfile-based method
 3. release engineering scripts to build images nightly as with regular
 cloud images
 4. release engineering scripts and process to get these images into the
 docker registry (will require some collaboration with docker.io people)

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/26#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] #26: File F21 change: Docker Container Image

2014-04-07 Thread Fedora Cloud Trac Tickets
#26: File F21 change: Docker Container Image
---+---
 Reporter:  mattdm |   Owner:
 Type:  task   |  Status:  new
 Priority:  major  |   Milestone:  Fedora 21 (Feature Deadline)
Component:  Docker Base|  Resolution:
  Container|
 Keywords: |
---+---
Description changed by mattdm:

Old description:

 '''Summary:''' This is Fedora running inside Docker. Currently, there are
 non-official images in the docker index, but we'd like them to really
 come out of release engineering.

 '''Importance:''' nice to have (The unofficial image situation is not
 ideal. Plus, this is an area where we can show leadership.)

 '''Timeframe:''' F21 alpha / If it's not ready for alpha, we have missed
 this release

 '''Scope:''' self-contained

 '''Cloud SIG owner:''' TBD (mattdm to kick things off)

 https://fedoraproject.org/wiki/Changes/Docker_Container_Image

New description:

 '''Summary:''' This is Fedora running inside Docker. Currently, there are
 non-official images in the docker index, but we'd like them to really come
 out of release engineering.

 '''Importance:''' nice to have (The unofficial image situation is not
 ideal. Plus, this is an area where we can show leadership.)

 '''Timeframe:''' F21 alpha / If it's not ready for alpha, we have missed
 this release

 '''Scope:''' self-contained

 '''Cloud SIG owner:''' lsm5

 https://fedoraproject.org/wiki/Changes/Docker_Container_Image

--

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/26#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


Re: [cloud] #24: File F21 change: Big Data Image

2014-04-08 Thread Fedora Cloud Trac Tickets
#24: File F21 change: Big Data Image
+---
 Reporter:  mattdm  |   Owner:  jeid64
 Type:  task|  Status:  assigned
 Priority:  normal  |   Milestone:  Fedora 21 (Feature Deadline)
Component:  Big Data Image  |  Resolution:
 Keywords:  |
+---

Comment (by jeid64):

 Updated https://fedoraproject.org/wiki/Changes/Big_Data_Cloud_Image for
 the deadline tonight for proposal changes. Can anyone else take a look at
 it (especially hguemar) and see if there's anything they'd like to add or
 clarify?

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/24#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] #17: File F21 change: Move to ImageFactory For image Creation

2014-04-08 Thread Fedora Cloud Trac Tickets
#17: File F21 change: Move to ImageFactory For image Creation
--+---
 Reporter:  mattdm|   Owner:  imcleod
 Type:  task  |  Status:  assigned
 Priority:  blocker   |   Milestone:  Fedora 21 (Feature Deadline)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+---

Comment (by mattdm):

 Marking this as resolved since change is filed. We can open new tickets to
 track actual work as needed.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/17#comment:6
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] #26: File F21 change: Docker Container Image

2014-04-08 Thread Fedora Cloud Trac Tickets
#26: File F21 change: Docker Container Image
---+---
 Reporter:  mattdm |   Owner:  lsm5
 Type:  task   |  Status:  assigned
 Priority:  major  |   Milestone:  Fedora 21 (Feature Deadline)
Component:  Docker Base|  Resolution:
  Container|
 Keywords: |
---+---

Comment (by mattdm):

 closing ticket as this is ready for wrangler

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/26#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] #17: File F21 change: Move to ImageFactory For image Creation

2014-04-08 Thread Fedora Cloud Trac Tickets
#17: File F21 change: Move to ImageFactory For image Creation
--+---
 Reporter:  mattdm|   Owner:  imcleod
 Type:  task  |  Status:  closed
 Priority:  blocker   |   Milestone:  Fedora 21 (Feature Deadline)
Component:  Cloud Base Image  |  Resolution:  fixed
 Keywords:|
--+---
Changes (by mattdm):

 * status:  assigned = closed
 * resolution:   = fixed


-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/17#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] #26: File F21 change: Docker Container Image

2014-04-08 Thread Fedora Cloud Trac Tickets
#26: File F21 change: Docker Container Image
---+---
 Reporter:  mattdm |   Owner:  lsm5
 Type:  task   |  Status:  closed
 Priority:  major  |   Milestone:  Fedora 21 (Feature Deadline)
Component:  Docker Base|  Resolution:  fixed
  Container|
 Keywords: |
---+---
Changes (by mattdm):

 * resolution:   = fixed
 * status:  assigned = closed


-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/26#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

2014-04-09 Thread 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

2014-04-09 Thread 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] #45: need three packages added to the fedora21 cloud iamge

2014-04-10 Thread Fedora Cloud Trac Tickets
#45: need three packages added to the fedora21 cloud iamge
--+
 Reporter:  sdake |  Owner:
 Type:  task  | Status:  new
 Priority:  normal|  Milestone:  Fedora 21 (Branch)
Component:  Cloud Base Image  |   Keywords:  OpenStack
--+
 We need os-collect-config, os-apply-config, and os-refresh-config added to
 the Fedora cloud images for both OpenStack Heat and OpenStack TripleO.
 These agents are used for new features or basic functionality in the case
 of TripleO.

 These are based on Python3 and import the Python3 runtime when installed.
 First package: 29 MB
 (most of the 29MB is the python3 runtime)

 Second package: 21 MB

 Third package: 22KB

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/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] #45: need three packages added to the fedora21 cloud iamge

2014-04-10 Thread Fedora Cloud Trac Tickets
#45: need three packages added to the fedora21 cloud iamge
--+-
 Reporter:  sdake |   Owner:
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Branch)
Component:  Cloud Base Image  |  Resolution:
 Keywords:  OpenStack |
--+-

Comment (by slagle):

 TripleO builds its own images using diskimage-builder and the Fedora cloud
 image as input. So, it's more accurate to say TripleO modifies existing
 images before deploying them to baremetal. TripleO doesn't really need
 these packages on the cloud image since it can install what it needs
 during the image build process.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/45#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

2014-04-14 Thread 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

2014-04-14 Thread 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

2014-04-15 Thread 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

2014-04-15 Thread 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

2014-04-15 Thread 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

2014-04-15 Thread 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

2014-04-15 Thread 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

2014-04-15 Thread 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

2014-04-15 Thread 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

2014-04-15 Thread 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

2014-04-15 Thread 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

2014-04-17 Thread 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] #46: Project Atomic and Fedora Docker Host Image

2014-04-17 Thread Fedora Cloud Trac Tickets
#46: Project Atomic and Fedora Docker Host Image
---+-
 Reporter:  mattdm |   Owner:
 Type:  task   |  Status:  new
 Priority:  normal |   Milestone:  Fedora 21 (Branch)
Component:  Docker Host Image  |  Resolution:
 Keywords:  meeting|
---+-

Comment (by hguemar):

 Tough choice, though the Atomic Host way is awesome, it's still in early
 stages and might even scare the majority/laggards. At least for F21, we
 should provide both ways if possible.
 If we had to chose only one, it seems logical that we focus on the Atomic
 Host considering our mission statement: Atomic is TEH future !

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/46#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] #47: Crucial basic Docket Host Image decisions

2014-04-18 Thread Fedora Cloud Trac Tickets
#47: Crucial basic Docket Host Image decisions
---+
 Reporter:  red|  Owner:
 Type:  task   | Status:  new
 Priority:  normal |  Milestone:  Fedora 21 (Branch)
Component:  Docker Host Image  |   Keywords:  meeting
---+
 Originally brought up in ticket #19, there's a few basic but crucial
 decisions to be made regarding the Fedora Docket Host Image. Therefore,
 I'm proposing the following set of decisions for the next meeting:

 - Whether to use (rpm-)ostree (aka Fedora Atomic Initiative)
 - Whether to remove yum/dnf (if going with ostree)
 - Whether to replace cloud-init by coreos' cloud-init or min-metadata-
 service
 - Whether to kick out python (if we decided against yum/dnf and cloud-
 init)

 Some of these decisions also benefit or contradict decisions to be made in
 ticket #46.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/47
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

2014-04-18 Thread 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

2014-04-21 Thread 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] #24: File F21 change: Big Data Image

2014-04-21 Thread Fedora Cloud Trac Tickets
#24: File F21 change: Big Data Image
+---
 Reporter:  mattdm  |   Owner:  jeid64
 Type:  task|  Status:  closed
 Priority:  normal  |   Milestone:  Fedora 21 (Feature Deadline)
Component:  Big Data Image  |  Resolution:  fixed
 Keywords:  |
+---
Changes (by red):

 * status:  assigned = closed
 * resolution:   = fixed


Comment:

 Change has been proposed and announced.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/24#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] #29: Coordinate Features that aren't filed

2014-04-21 Thread Fedora Cloud Trac Tickets
#29: Coordinate Features that aren't filed
--+---
 Reporter:  mattdm|   Owner:
 Type:  task  |  Status:  closed
 Priority:  blocker   |   Milestone:  Fedora 21 (Feature Deadline)
Component:  Planning  |  Resolution:  fixed
 Keywords:  meeting   |
--+---
Changes (by red):

 * status:  new = closed
 * resolution:   = fixed


Comment:

 Since the list is now empty and the deadline has passed, I think this is
 all done...

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/29#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


Re: [cloud] #48: remove rsyslog from default image, configure journald options appropriately

2014-04-22 Thread Fedora Cloud Trac Tickets
#48: remove rsyslog from default image, configure journald options appropriately
--+
 Reporter:  mattdm|   Owner:
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by johannbg):

 I should also mention that it's not enough to simply remove rsyslog from
 the cloud image, each package that ships service/daemon needs to split out
 their rsyslog and syslog-ng configuration file as well as their
 accommodating logwatch files ( which are roughly 100 components ) into
 their own sub package to properly prepare and integrate components and
 journal into the distribution.

 I filed a request two years ago with FPC in attempt to get the guidelines
 fixed so I could fix this when I do the systemd cleanup process well that
 ticket is still open and unresolved, perhaps the cloud community has more
 luck with the FPC if you are going to start doing the necessary legwork to
 do this work.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/48#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


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

2014-04-22 Thread 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] #49: Spins Process for Cloud Images

2014-04-22 Thread Fedora Cloud Trac Tickets
#49: Spins Process for Cloud Images
-+-
 Reporter:  red  |   Owner:
 Type:  task |  Status:  new
 Priority:  blocker  |   Milestone:  Fedora 21 (Branch)
Component:  ---  |  Resolution:
 Keywords:  meeting  |
-+-
Changes (by mattdm):

 * cc: cwickert (added)


Comment:

 I guess we can go forward with it and raise a ruckus if we hit problems.
 Mostly, it looks like we shouldn't have any. I don't think the guidelines
 all apply exactly, though -- we don't want these on the 'spins' download
 page, as that will just confuse people.

 I guess we should ask Christoph, as spins wrangler, what he thinks.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/49#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

2014-04-22 Thread 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

2014-04-22 Thread 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

2014-04-22 Thread 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] #41: Write Initial QA Documents

2014-04-22 Thread Fedora Cloud Trac Tickets
#41: Write Initial QA Documents
--+-
 Reporter:  mattdm|   Owner:  roshi
 Type:  task  |  Status:  assigned
 Priority:  major |   Milestone:  Fedora 21 (Branch)
Component:  Testing  QA  |  Resolution:
 Keywords:|
--+-
Changes (by roshi):

 * status:  accepted = assigned
 * owner:  red = roshi


-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/41#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] #49: Spins Process for Cloud Images

2014-04-22 Thread Fedora Cloud Trac Tickets
#49: Spins Process for Cloud Images
-+-
 Reporter:  red  |   Owner:
 Type:  task |  Status:  new
 Priority:  blocker  |   Milestone:  Fedora 21 (Branch)
Component:  ---  |  Resolution:
 Keywords:  meeting  |
-+-

Comment (by mattdm):

 You know, this has one huge advantage. I keep accidentally referring to
 our cloud image variants as spins. Making them _actually_ spins would
 remove the need to come up with a new term. :)

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/49#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


Re: [cloud] #45: need three packages added to the fedora21 cloud iamge

2014-04-23 Thread Fedora Cloud Trac Tickets
#45: need three packages added to the fedora21 cloud iamge
+-
 Reporter:  sdake   |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Fedora 21 (Branch)
Component:  Cloud Base Image|  Resolution:
 Keywords:  OpenStack, meeting  |
+-
Changes (by red):

 * keywords:  OpenStack = OpenStack, meeting


-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/45#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


[cloud] #50: Deliverables and release engineering changes for Fedora.Next

2014-04-23 Thread Fedora Cloud Trac Tickets
#50: Deliverables and release engineering changes for Fedora.Next
--+-
 Reporter:  mattdm|  Owner:
 Type:  task  | Status:  new
 Priority:  major |  Milestone:  Future
Component:  Planning  |   Keywords:  meeting
--+-
 https://lists.fedoraproject.org/pipermail/cloud/2014-April/003759.html

 See https://fedorahosted.org/rel-eng/ticket/5891

 I'm only making a ticket here to get it in the meeting :)

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/50
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] #51: start communication/collaboration on cloud image updates

2014-04-23 Thread Fedora Cloud Trac Tickets
#51: start communication/collaboration on cloud image updates
+-
 Reporter:  mattdm  |  Owner:
 Type:  task| Status:  new
 Priority:  normal  |  Milestone:  Future
Component:  --- |   Keywords:  meeting
+-
 At today's FESCo meeting, FESCo approved
 https://fedoraproject.org/wiki/Changes/%28A%29Periodic_Updates_to_Cloud_Images
 but wants us to get started actually changing the hand-waving parts about

 * policies (when exactly we will do off-cycle updates)
 * QA expectations (the exact testing requirements)
 * QA contribution (commitments to help with the automation and possible
 manual testing)
 * release engineering help (contributing scripts/code/effort as needed)

 We really need people to sign up for each of these -- not necessarily to
 do all the work, but to take ownership of the communication and
 coordination for each.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/51
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

2014-04-23 Thread 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] #41: Write Initial QA Documents

2014-04-23 Thread Fedora Cloud Trac Tickets
#41: Write Initial QA Documents
--+-
 Reporter:  mattdm|   Owner:  roshi
 Type:  task  |  Status:  assigned
 Priority:  major |   Milestone:  Fedora 21 (Branch)
Component:  Testing  QA  |  Resolution:
 Keywords:|
--+-

Comment (by roshi):

 Created an initial draft of a test plan [0] and relevant documentation.
 [1]

 // Mike

 [0] https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Test_Plan
 [1] https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/41#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] #5: tracker for GCE work

2014-04-24 Thread Fedora Cloud Trac Tickets
#5: tracker for GCE work
--+-
 Reporter:  mattdm|   Owner:
 Type:  task  |  Status:  new
 Priority:  major |   Milestone:  Future
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+-

Comment (by mattdm):

 We should probably file a F21 Change for this -- Fedora Cloud image in
 GCE. It's self-contained if we can get releng on board. :)

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/5#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


Re: [cloud] #23: File F22 change: Re-factor cloud-init

2014-04-24 Thread Fedora Cloud Trac Tickets
#23: File F22 change: Re-factor cloud-init
--+
 Reporter:  mattdm|   Owner:  hguemar
 Type:  task  |  Status:  assigned
 Priority:  normal|   Milestone:  Fedora 22
Component:  Cloud Base Image  |  Resolution:
 Keywords:  meeting   |
--+
Changes (by hguemar):

 * status:  new = assigned
 * owner:   = hguemar


Comment:

 I'll be investigating if we could make min-metadata-service a suitable
 replacement for cloud-init within F22 timeframe. I doubt that cloud-init
 is a good option for the long run.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/23#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] #16: rename cloud spin kickstart to distinguish the cloud base image

2014-04-24 Thread Fedora Cloud Trac Tickets
#16: rename cloud spin kickstart to distinguish the cloud base image
-+-
 Reporter:  mattdm   |   Owner:
 Type:  task |  Status:  new
 Priority:  minor|   Milestone:  Fedora 21 (Branch)
Component:  ---  |  Resolution:
 Keywords:  meeting  |
-+-

Comment (by red):

 So I think we agreed on the name (Fedora Cloud Base) for the image at
 the meeting just now.

 Regarding the kickstart file, I asked for clarification why two (i.e.
 cloud-base-base.ks and cloud-base.ks) are necessary. My impression was
 that we'd just have cloud-base.ks which would have two purposes:
 - Create the Fedora Cloud Base image (what I think mattdm called fedora-
 base.ks above)
 - Be %include'd in all other (except maybe leading-edge Docker/Atomic)
 ks/images (what I think mattdm called fedora-base-base.ks above)

 So why is there a need for two separate ks files?

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/16#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] #45: need three packages added to the fedora21 cloud iamge

2014-04-24 Thread Fedora Cloud Trac Tickets
#45: need three packages added to the fedora21 cloud iamge
+-
 Reporter:  sdake   |   Owner:  jzb
 Type:  task|  Status:  assigned
 Priority:  normal  |   Milestone:  Fedora 21 (Branch)
Component:  Cloud Base Image|  Resolution:
 Keywords:  OpenStack, meeting  |
+-
Changes (by jzb):

 * owner:   = jzb
 * status:  new = assigned


Comment:

 Discussed this in the most recent Fedora Cloud meeting. We're not
 definitely saying no, but currently we need a better case for inclusion
 at this time. Can we get some more info on why this should be in the
 default image?

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/45#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] #46: Project Atomic and Fedora Docker Host Image

2014-04-24 Thread Fedora Cloud Trac Tickets
#46: Project Atomic and Fedora Docker Host Image
---+-
 Reporter:  mattdm |   Owner:
 Type:  task   |  Status:  new
 Priority:  normal |   Milestone:  Fedora 21 (Branch)
Component:  Docker Host Image  |  Resolution:
 Keywords:  meeting|
---+-

Comment (by mattdm):

 So, at the [http://meetbot.fedoraproject.org/fedora-meeting/2014-04-24
 /fedora-meeting.2014-04-24-14.08.log.html IRC meeting], we decided to go
 ahead with Atomic for the Docker Host Image. More to come. :)

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/46#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

2014-04-24 Thread 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


[cloud] #52: Confirm voting members' continued membership

2014-04-24 Thread Fedora Cloud Trac Tickets
#52: Confirm voting members' continued membership
+--
 Reporter:  red |  Owner:
 Type:  task| Status:  new
 Priority:  normal  |  Milestone:  Fedora 21 (Feature Deadline)
Component:  --- |   Keywords:  meeting
+--
 According to [ 1 ], we're supposed to confirm voting members' continued
 membership every six months. Guess what? The first six months have passed
 (approval happened end-of-October [ 2 ]) and I think some members are not
 interested in their position anymore (read: I think we haven't seen any
 directly related work or message from them in months, let alone meeting
 participation).

 So, can voting members please confirm their continued membership by
 leaving a short comment in this ticket? People that don't and people that
 indicate they'd rather step down will be released from their duties at an
 upcoming meeting (and hopefully be replaced by other interested SIG
 members).

 [ 1 ] http://fedoraproject.org/wiki/Cloud/Governance
 [ 2 ]
 https://lists.fedoraproject.org/pipermail/cloud/2013-October/002823.html

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/52
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

2014-04-30 Thread 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] #15: migrate to GPT instead of old-style partitions

2014-04-30 Thread Fedora Cloud Trac Tickets
#15: migrate to GPT instead of old-style partitions
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  assigned
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+
Changes (by janeznemanic):

 * owner:   = janeznemanic
 * status:  new = assigned


-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/15#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] #45: need three packages added to the fedora21 cloud iamge

2014-04-30 Thread Fedora Cloud Trac Tickets
#45: need three packages added to the fedora21 cloud iamge
+-
 Reporter:  sdake   |   Owner:  jzb
 Type:  task|  Status:  assigned
 Priority:  normal  |   Milestone:  Fedora 21 (Branch)
Component:  Cloud Base Image|  Resolution:
 Keywords:  OpenStack, meeting  |
+-

Comment (by jzb):

 We have the standing IRC meeting tomorrow, wondering if we still wanted to
 consider this or if I should close it out for now. Thanks!

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/45#comment:6
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] #47: Crucial basic Docket Host Image decisions

2014-05-01 Thread Fedora Cloud Trac Tickets
#47: Crucial basic Docket Host Image decisions
---+-
 Reporter:  red|   Owner:
 Type:  task   |  Status:  closed
 Priority:  normal |   Milestone:  Fedora 21 (Branch)
Component:  Docker Host Image  |  Resolution:  fixed
 Keywords:  meeting|
---+-
Changes (by red):

 * resolution:   = fixed
 * status:  new = closed


Comment:

 Okay, so through the acceptance of the main point of ticket #46 last week,
 we go with rpm-ostree. For reference, part of this decision is also, that
 the Docker Host Image is not the Atomic Image.

 At today's meeting, we further decided (let me stress again, that is goes
 only for the Atomic Image):
 - To ship without yum/dnf
 - Try to have min-metadata-service work by/in F21 Alpha but fall back to
 cloud-init before Beta if that doesn't work.
 - Ship without python, if we ship without min-metadata-service.

 In other words: all was accepted, with some reservation.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/47#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] #51: start communication/collaboration on cloud image updates

2014-05-01 Thread Fedora Cloud Trac Tickets
#51: start communication/collaboration on cloud image updates
-+-
 Reporter:  mattdm   |   Owner:
 Type:  task |  Status:  new
 Priority:  normal   |   Milestone:  Future
Component:  ---  |  Resolution:
 Keywords:  meeting  |
-+-

Comment (by mattdm):

 See also: https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/51#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] #49: Spins Process for Cloud Images

2014-05-01 Thread Fedora Cloud Trac Tickets
#49: Spins Process for Cloud Images
-+-
 Reporter:  red  |   Owner:
 Type:  task |  Status:  closed
 Priority:  blocker  |   Milestone:  Fedora 21 (Branch)
Component:  ---  |  Resolution:  fixed
 Keywords:  meeting  |
-+-
Changes (by red):

 * resolution:   = fixed
 * status:  new = closed


Comment:

 Discussed at our meeting today and we do agreed to go with the spins
 process as proposed. Figure we'll notice how well that works for images
 (for which it wasn't originally intended) as we move forward. jzb will
 open separate tickets for each planned image to follow the process.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/49#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] #4: new release criteria for post-f20 cloud image

2014-05-04 Thread Fedora Cloud Trac Tickets
#4: new release criteria for post-f20 cloud image
--+
 Reporter:  mattdm|   Owner:  roshi
 Type:  task  |  Status:  assigned
 Priority:  major |   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+
Changes (by red):

 * status:  accepted = assigned
 * owner:  red = roshi


Comment:

 roshi has actually also taken over this ticket together with ticket #41.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/4#comment:6
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] #53: anaconda doesn't allow installation of current fedora-cloud-base.ks

2014-05-07 Thread Fedora Cloud Trac Tickets
#53: anaconda doesn't allow installation of current fedora-cloud-base.ks
-+-
 Reporter:  walters  |   Owner:
 Type:  task |  Status:  new
 Priority:  normal   |   Milestone:  Future
Component:  ---  |  Resolution:
 Keywords:   |
-+-

Comment (by walters):

 walters dgilmore, did you see the conclusion of yesterday's thread?  is
 setting a root pw in kickstart then locking good enough?
 dgilmore walters: its really not
 walters dgilmore, ok, we need to figure this out; i'm interested as I
 need to be producing cloud images via anaconda as well
 walters should take this to a bug or something
 dlehman pardon me for being behind, but what's the problem?
 dlehman you want root locked but anaconda doesn't allow that?
 dgilmore dlehman: anaconda doesnt allow it without creatinga  user
 walters dlehman, i think the typing to catch you up is best done in a
 bug
 dlehman fair enough
 dgilmore dlehman: need to be able to say the root account can be locked
 if a package that will configure the system on first boot is installed
 dlehman dgilmore: and the rationale is that we can't know for sure if
 there will be compulsory user-account creation, so we can't lock root,
 right?
 dgilmore walters: but yeah a bug is probably best
 walters https://fedorahosted.org/cloud/ ?
 dgilmore dlehman: well we can deal with it all in %post, but that is
 easy to get wrong
 walters i can wordsmith this
 dlehman the only way anaconda could let this slide, I think, is if those
 initial-setup packages provide something that says I take full
 responsibility for compulsory user account configuration
 dlehman then we can just reassign the bugs to those packages when they
 inevitably come
 dgilmore dlehman: right
 dlehman so I think those various packages should have Provides: user-
 account-setup
 walters https://fedorahosted.org/cloud/ticket/53
 dgilmore dlehman: i am okay with that
 dgilmore initial-setup cloud-init etc can all provide that
 dlehman and that means if they get installed it's their responsibility
 to see to it that the accounts are created
 dlehman it doesn't matter what else is installed, doesn't matter what
 the user does, c c
 davidshea we'd need a way to ensure that the service or whatever is
 actually enabled on boot. that's all over the place right now
 walters are you saying anaconda would come with code to check the rpm
 transaction for something with the requisite provides?
 dlehman it certainly sounds better than maintaining a list of packages
 that may or may not handle it
 dlehman I'm not volunteering, but if you want something better than what
 we have now this seems like the way to go.
 dlehman we can log prominently WARNING: not enforcing user account
 creation because package foo will handle it on the reboot
 walters though come to think of it, this isn't going to work for me
 walters at least not easily
 walters since min-metadata-service will likely be in the default tree,
 just not enabled
 walters as davidshea says
 walters maybe in the future i'd have a variant tree for cloud, also with
 stuff like the physical kernel drivers stripped out
 * walters keeps coming back to the idea of a kickstart verb for this

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/53#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] #3: Fedora.next product branding for cloud - list of questions

2014-05-08 Thread Fedora Cloud Trac Tickets
#3: Fedora.next product branding for cloud - list of questions
---+---
 Reporter:  rbergero   |   Owner:
 Type:  task   |  Status:  closed
 Priority:  major  |   Milestone:  Fedora 21
Component:  Collaboration  Communication  |  (Final)
 Keywords:  meeting|  Resolution:  fixed
---+---
Changes (by jzb):

 * resolution:   = fixed
 * status:  new = closed


Comment:

 I think this one is now complete. I'm closing this unless we need further
 action.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/3#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


[cloud] #54: define shell command API available in Fedora Atomic

2014-05-08 Thread Fedora Cloud Trac Tickets
#54: define shell command API available in Fedora Atomic
---+---
 Reporter:  mattdm |  Owner:
 Type:  task   | Status:  new
 Priority:  normal |  Milestone:  Fedora 21 (Alpha)
Component:  Docker Host Image  |   Keywords:
---+---
 This is a list of shell commands (or at least the packages which contain
 them) which are expected to work in a cloud metadata userscript at initial
 Fedora Atomic launch. We should maintain this list and note changes in the
 release notes, have a deprecation procedure, and so on.

 The initial goal for Fedora Atomic is to be as small as reasonably
 possible, including removing Python (and, not including python and yum/dnf
 on the list).

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/54
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] #55: define shell command API available in Fedora Cloud Base Image

2014-05-08 Thread Fedora Cloud Trac Tickets
#55: define shell command API available in Fedora Cloud Base Image
--+---
 Reporter:  mattdm|  Owner:
 Type:  task  | Status:  new
 Priority:  normal|  Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |   Keywords:
--+---
 This is a list of shell commands (or at least the packages which contain
 them) which are expected to work in a cloud metadata userscript at initial
 Fedora Cloud Base Image launch. We should maintain this list and note
 changes in the release notes, have a deprecation procedure, and so on.

 The initial goal for Fedora Cloud Base Image is to balance size and
 usefulness -- python and yum/dnf will be in the list, for example. For a
 more edgy image, see Fedora Atomic.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/55
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] #54: define shell command API available in Fedora Atomic

2014-05-08 Thread Fedora Cloud Trac Tickets
#54: define shell command API available in Fedora Atomic
---+
 Reporter:  mattdm |   Owner:
 Type:  task   |  Status:  new
 Priority:  normal |   Milestone:  Fedora 21 (Alpha)
Component:  Docker Host Image  |  Resolution:
 Keywords: |
---+

Comment (by red):

 A ticket is good to work on an initial list and maybe discuss further
 changes later on, but shouldn't the actual maintained list better be kept
 in a wiki? :)

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/54#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


Re: [cloud] #46: Project Atomic and Fedora Docker Host Image

2014-05-08 Thread Fedora Cloud Trac Tickets
#46: Project Atomic and Fedora Docker Host Image
---+-
 Reporter:  mattdm |   Owner:
 Type:  task   |  Status:  new
 Priority:  normal |   Milestone:  Fedora 21 (Branch)
Component:  Docker Host Image  |  Resolution:
 Keywords:  meeting|
---+-

Comment (by jzb):

 Do we need this to continue being tagged for meetings?

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/46#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] #45: need three packages added to the fedora21 cloud iamge

2014-05-08 Thread Fedora Cloud Trac Tickets
#45: need three packages added to the fedora21 cloud iamge
+-
 Reporter:  sdake   |   Owner:  jzb
 Type:  task|  Status:  closed
 Priority:  normal  |   Milestone:  Fedora 21 (Branch)
Component:  Cloud Base Image|  Resolution:  wontfix
 Keywords:  OpenStack, meeting  |
+-
Changes (by jzb):

 * resolution:   = wontfix
 * status:  assigned = closed


Comment:

 No response, so I'm closing this for now. If necessary we can reopen.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/45#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] #56: tracking ticket for conversations around shipping ostree... trees. (was: tracking ticket for conversations around shipping ostree images)

2014-05-08 Thread Fedora Cloud Trac Tickets
#56: tracking ticket for conversations around shipping ostree... trees.
---+---
 Reporter:  mattdm |   Owner:
 Type:  task   |  Status:  new
 Priority:  blocker|   Milestone:  Fedora 21
Component:  Collaboration  Communication  |  (Branch)
 Keywords: |  Resolution:
---+---

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/56#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


[cloud] #56: tracking ticket for conversations around shipping ostree images

2014-05-08 Thread Fedora Cloud Trac Tickets
#56: tracking ticket for conversations around shipping ostree images
---+---
 Reporter:  mattdm |  Owner:
 Type:  task   | Status:  new
 Priority:  blocker|  Milestone:  Fedora 21
Component:  Collaboration  Communication  |  (Branch)
   |   Keywords:
---+---
 We've decided to base the Fedora Docker host image on Project Atomic, and
 therefore rpm-ostree. This means several big conversations, including with
 QA, Rel Eng, and the mirror network. It will mean some new development and
 possibly extra resources. But first we need to figure out the questions to
 ask, and then we need to ask them, and then we need to find answers, or
 provide them where they don't already exist.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/56
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] #51: start communication/collaboration on cloud image updates

2014-05-08 Thread Fedora Cloud Trac Tickets
#51: start communication/collaboration on cloud image updates
-+---
 Reporter:  mattdm   |   Owner:  roshi
 Type:  task |  Status:  assigned
 Priority:  normal   |   Milestone:  Future
Component:  ---  |  Resolution:
 Keywords:  meeting  |
-+---
Changes (by roshi):

 * owner:   = roshi
 * status:  new = assigned


-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/51#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


Re: [cloud] #56: tracking ticket for conversations around shipping ostree... trees.

2014-05-09 Thread Fedora Cloud Trac Tickets
#56: tracking ticket for conversations around shipping ostree... trees.
---+---
 Reporter:  mattdm |   Owner:
 Type:  task   |  Status:  new
 Priority:  blocker|   Milestone:  Fedora 21
Component:  Collaboration  Communication  |  (Branch)
 Keywords: |  Resolution:
---+---

Comment (by mattdm):

 So, some questions:

 1. How to get a starting-point ostree repo built in koji?
 2. How to get updates to that?
 3. Can this be put on the existing mirror network as is?
 4. If not, can changes be made so that it'll work?
 5. What changes? (Deltas?) Who will make them and when will they land?
 6. If we can't do that, do we have a fallback?

 I'm not sure what exactly the QA questions are, other than this is
 another thing we'll need to test.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/56#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


Re: [cloud] #51: start communication/collaboration on cloud image updates

2014-05-12 Thread Fedora Cloud Trac Tickets
#51: start communication/collaboration on cloud image updates
-+---
 Reporter:  mattdm   |   Owner:  roshi
 Type:  task |  Status:  assigned
 Priority:  normal   |   Milestone:  Future
Component:  ---  |  Resolution:
 Keywords:  meeting  |
-+---

Comment (by mattdm):

 See also:

 * policies for batched updates: https://fedorahosted.org/cloud/ticket/42
 * procedures and process for getting updated images onto mirrors:
 https://fedorahosted.org/cloud/ticket/43

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/51#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


[cloud] #57: get official images uploaded into Rackspace

2014-05-12 Thread Fedora Cloud Trac Tickets
#57: get official images uploaded into Rackspace
-+-
 Reporter:  mattdm   |  Owner:
 Type:  task | Status:  new
 Priority:  normal   |  Milestone:  Fedora 21
Component:  Infrastructure  Release |  (Final)
  Engineering|   Keywords:
-+-
 Work with Rackspace engineers... they don't yet have public image sharing,
 but getting our official images uploaded to a fedora account as part of
 the release process would be a good start.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/57
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] #58: get vagrant-libvirt (and/pr vagrant-kvm) plugins into the distro

2014-05-13 Thread Fedora Cloud Trac Tickets
#58: get vagrant-libvirt (and/pr vagrant-kvm) plugins into the distro
+
 Reporter:  mattdm  |  Owner:
 Type:  task| Status:  new
 Priority:  normal  |  Milestone:  Future
Component:  --- |   Keywords:
+
 See http://ttboj.wordpress.com/2014/05/13/vagrant-on-fedora-with-libvirt-
 reprise/ and the call for help at the end. Also the discussion there, and
 also previous work at

 * https://bugzilla.redhat.com/show_bug.cgi?id=998503
 * https://fedoraproject.org/wiki/Changes/Vagrant

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/58
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] #44: hey we should have a vagrant base box

2014-05-13 Thread Fedora Cloud Trac Tickets
#44: hey we should have a vagrant base box
+-
 Reporter:  mattdm  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by purpleidea):

 Oh. Fair enough! I'm building one now using this method...

 https://ttboj.wordpress.com/2014/01/20/building-base-images-for-vagrant-
 with-a-makefile/

 and this patch:

 https://github.com/purpleidea/puppet-
 gluster/commit/e6f0bc559802abae16e06c79062f1910538fbedd

 Should be ready once I get on fast internet...

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/44#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] #44: hey we should have a vagrant base box

2014-05-13 Thread Fedora Cloud Trac Tickets
#44: hey we should have a vagrant base box
+-
 Reporter:  mattdm  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by mattdm):

 Awesome!

 Eventually, it'd be awesome if this would automatically fall out of the
 release engineering process. But let's start with whatever we can get :)

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/44#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


Re: [cloud] #44: hey we should have a vagrant base box

2014-05-13 Thread Fedora Cloud Trac Tickets
#44: hey we should have a vagrant base box
+-
 Reporter:  mattdm  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by purpleidea):

 Replying to [comment:2 mattdm]:
  Awesome!
 
  Eventually, it'd be awesome if this would automatically fall out of the
 release engineering process. But let's start with whatever we can get :)

 LOL, well you are all welcome to use my scripts-- they're all open
 source, but I'd rather not be the guy plugging it into release
 engineering. I'm happy to run make on my laptop whenever someone asks
 for a new build though.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/44#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] #44: hey we should have a vagrant base box

2014-05-13 Thread Fedora Cloud Trac Tickets
#44: hey we should have a vagrant base box
+-
 Reporter:  mattdm  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by purpleidea):

 Currently uploading, but wholly untested. Not even once!

 In about two hours this should be downloadable. (Make sure the sha256sum
 matches!)

 https://download.gluster.org/pub/gluster/purpleidea/vagrant/fedora-20/

 After I get some sleep, I'll test this as soon as I can.

 HTH

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/44#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] #44: hey we should have a vagrant base box

2014-05-15 Thread Fedora Cloud Trac Tickets
#44: hey we should have a vagrant base box
+-
 Reporter:  mattdm  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by walters):

 A few issues with that script:

 * Disabling SELinux is obviously not something we can ship with
 * virt-builder is a useful tool, but rwmjones's website is not maintained
 by releng.  It's not going to work to bounce content to his site and then
 have releng download it again

 Now there are two approaches.

 1) Anaconda + kickstart
I think this is probably the way to go, particularly as it would allow
 us to include Vagrant-specific content.
 2) Mutate an existing qcow2 (e.g. the cloud image)
For the latter, see: https://github.com/cgwalters/rpm-ostree-
 autocompose/commit/55af81ff04afb24429616ccb2c67b408e3a7e364 for an
 approach which injects a systemd unit file, rather than attempting to
 change the target from the outside.  The advantage of this is that way we
 pick up the SELinux policy from the target.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/44#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] #50: Deliverables and release engineering changes for Fedora.Next

2014-05-15 Thread Fedora Cloud Trac Tickets
#50: Deliverables and release engineering changes for Fedora.Next
--+-
 Reporter:  mattdm|   Owner:
 Type:  task  |  Status:  new
 Priority:  major |   Milestone:  Future
Component:  Planning  |  Resolution:
 Keywords:  meeting   |
--+-

Comment (by mattdm):

 note from May 15th meeting: jzb will file tickets for the individual new
 spins

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/50#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] #44: hey we should have a vagrant base box

2014-05-15 Thread Fedora Cloud Trac Tickets
#44: hey we should have a vagrant base box
+-
 Reporter:  mattdm  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-
Changes (by rjones):

 * cc: rjones@… (added)


-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/44#comment:6
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] #44: hey we should have a vagrant base box

2014-05-15 Thread Fedora Cloud Trac Tickets
#44: hey we should have a vagrant base box
+-
 Reporter:  mattdm  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by rjones):

 Not sure how virt-builder is involved here?  In any case note that virt-
 builder will use existing cloud images, but someone has to provide an
 index file (https://fedorahosted.org/rel-eng/ticket/5805)

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/44#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] #23: File F22 change: Re-factor cloud-init

2014-05-15 Thread Fedora Cloud Trac Tickets
#23: File F22 change: Re-factor cloud-init
--+
 Reporter:  mattdm|   Owner:  hguemar
 Type:  task  |  Status:  assigned
 Priority:  normal|   Milestone:  Fedora 22
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+
Changes (by mattdm):

 * keywords:  meeting =


Comment:

 as per current meeting, remove meeting keyword :)

 We will be investigating min-cloud-agent (new name for min-metadata-
 service) for the Fedora Atomic image ''only'' for F21. May look at it for
 other images for F22.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/23#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] #51: start communication/collaboration on cloud image updates

2014-05-15 Thread Fedora Cloud Trac Tickets
#51: start communication/collaboration on cloud image updates
-+---
 Reporter:  mattdm   |   Owner:  roshi
 Type:  task |  Status:  assigned
 Priority:  normal   |   Milestone:  Future
Component:  ---  |  Resolution:
 Keywords:  meeting  |
-+---

Comment (by mattdm):

 Status update for this week is that things are basically moving forward
 but it isn't ready yet for doing cloudy things. Taskotron is reaching  a
 useful stage.

 Leaving this ticket open for a status update next week.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/51#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] #44: hey we should have a vagrant base box

2014-05-15 Thread Fedora Cloud Trac Tickets
#44: hey we should have a vagrant base box
+-
 Reporter:  mattdm  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by purpleidea):

 Replying to [comment:5 walters]:
  A few issues with that script:
 
  * Disabling SELinux is obviously not something we can ship with
 Agreed. I actually forgot about this... I think it was something that was
 needed by vagrant boxes at some point. Easy to change this. (one-liner).

  * virt-builder is a useful tool, but rwmjones's website is not
 maintained by releng.  It's not going to work to bounce content to his
 site and then have releng download it again
 I agree! I do think it makes sense to build upon existing tools where
 appropriate. This way we have fewer different initial ways to build a base
 image. For the releng requirements, I'm pretty sure rwmjones tools can
 point at a different repo, and even work fully offline. You typically
 need to set the /etc/virt-builder/repos.d/something.conf file to
 whatever you want. rwmjones is probably a great resource for info on how
 to build his template .xz files.

 
  Now there are two approaches.
 
  1) Anaconda + kickstart
 I think this is probably the way to go, particularly as it would
 allow us to include Vagrant-specific content.
  2) Mutate an existing qcow2 (e.g. the cloud image)
 For the latter, see: https://github.com/cgwalters/rpm-ostree-
 autocompose/commit/55af81ff04afb24429616ccb2c67b408e3a7e364 for an
 approach which injects a systemd unit file, rather than attempting to
 change the target from the outside.  The advantage of this is that way we
 pick up the SELinux policy from the target.

 I actually prefer my makefile/virt-builder approach, but I obviously am
 fine with other people working on different methods.

 I figured I'd step up to help with this, since it was apparently a very
 long-standing request. I'm happy to continue to generate these Fedora
 vagrant boxes, and I think it makes sense to use this, even officially
 since it works _now_, and nobody for a while seemed to be doing this.

 I should mention, working on this isn't really my prime directive, so
 more than I anything I was trying to be helpful so that I have beverage or
 bug karma with mattdm :P

 Cheers

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/44#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] #44: hey we should have a vagrant base box

2014-05-15 Thread Fedora Cloud Trac Tickets
#44: hey we should have a vagrant base box
+-
 Reporter:  mattdm  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by purpleidea):

 Replying to [comment:7 rjones]:
  Not sure how virt-builder is involved here?  In any case note that virt-
 builder will use existing cloud images, but someone has to provide an
 index file (https://fedorahosted.org/rel-eng/ticket/5805)

 Virt-builder being involved is my fault, sorry. It happened when I decided
 that I liked your tools enough to integrate them in my other projects.
 See:

 https://ttboj.wordpress.com/2014/01/20/building-base-images-for-vagrant-
 with-a-makefile/

 For more details.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/44#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] #44: hey we should have a vagrant base box

2014-05-15 Thread Fedora Cloud Trac Tickets
#44: hey we should have a vagrant base box
+-
 Reporter:  mattdm  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by walters):

 Replying to [comment:8 purpleidea]:
  Easy to change this. (one-liner).

 I'm not so sure it's that easy.  The problem I hit with using libguestfs
 for this sort of stuff is that you really need to be sure the SELinux
 label of critical files like /etc/passwd is set.  It's hard to do that
 from the outside - doing it *inside* the system on boot means we use the
 target policy.

  I actually prefer my makefile/virt-builder approach, but I obviously am
 fine with other people working on different methods.

 The makefile versus shell versus javascript or whatever is mostly a red
 herring I think.  The issue I see is more the second part - the semantics
 around how we change the contents of the target system.

  I figured I'd step up to help with this, since it was apparently a very
 long-standing request.

 Definitely!  Do you have some bandwidth to work on this/continue the
 conversation here?

 There are a few aspects to this:

 1) Content definition - what packages are installed?
 2) Partition layout
 3) System default configuration (vagrant user, vagrant ssh keys, sudo)

 To me, Anaconda+kickstart files are the thing to use for #1 and #2.  In
 other words we're just talking about another Fedora Cloud type image,
 except with Vagrant as the hypervisor.

 For #3, kickstart files are probably also the way to go.  My script was
 just a hack because I didn't have ostree support in Anaconda, but now I
 do.

 There's a general question here about anaconda versus virt-builder; when
 should you rebuild versus post-customize.  To me the answer comes down
 to the package set.  If for example we wanted different packages in the
 Vagrant image, then it would need to be an Anaconda rebuild.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/44#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] #44: hey we should have a vagrant base box

2014-05-15 Thread Fedora Cloud Trac Tickets
#44: hey we should have a vagrant base box
+-
 Reporter:  mattdm  |   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  --- |  Resolution:
 Keywords:  |
+-

Comment (by purpleidea):

 Replying to [comment:10 walters]:
  Replying to [comment:8 purpleidea]:
   Easy to change this. (one-liner).
 
  I'm not so sure it's that easy.  The problem I hit with using libguestfs
 for this sort of stuff is that you really need to be sure the SELinux
 label of critical files like /etc/passwd is set.  It's hard to do that
 from the outside - doing it *inside* the system on boot means we use the
 target policy.

 Agreed... but, I do do it inside. :)
 https://github.com/purpleidea/puppet-
 gluster/blob/master/builder/Makefile#L83

 I'm not sure if this is now equivalent to the new --selinux-relabel flag
 for virt-builder. If it is, we can simplify this.



 
   I actually prefer my makefile/virt-builder approach, but I obviously
 am fine with other people working on different methods.
 
  The makefile versus shell versus javascript or whatever is mostly a red
 herring I think.  The issue I see is more the second part - the semantics
 around how we change the contents of the target system.
 
   I figured I'd step up to help with this, since it was apparently a
 very long-standing request.
 
  Definitely!  Do you have some bandwidth to work on this/continue the
 conversation here?

 To be honest, not a lot, actually. If it would help, I will be in Westford
 next week, and I am happy to meet if you want to hack on this, or iterate
 quickly over some of the ideas.

 
  There are a few aspects to this:
 
  1) Content definition - what packages are installed?
  2) Partition layout
  3) System default configuration (vagrant user, vagrant ssh keys, sudo)
 
  To me, Anaconda+kickstart files are the thing to use for #1 and #2.  In
 other words we're just talking about another Fedora Cloud type image,
 except with Vagrant as the hypervisor.
 
  For #3, kickstart files are probably also the way to go.  My script was
 just a hack because I didn't have ostree support in Anaconda, but now I
 do.
 
  There's a general question here about anaconda versus virt-builder; when
 should you rebuild versus post-customize.  To me the answer comes down
 to the package set.  If for example we wanted different packages in the
 Vagrant image, then it would need to be an Anaconda rebuild.
 

 So, I must say, that I love Anaconda for it's use case, however in
 general, it's the reason that virt-builder and vagrant are so useful. The
 vagrant user or really most people (IMO), don't want to have to muck
 around with getting every anaconda setting right... If I can build this on
 top of an already built base image, then there is less chance for error.
 IOW, I'm glad Anaconda exists, but I want to use it as little as possible.

 What OS image can't you build with virt-builder? I don't know that it does
 anything to the template that can't be properly fixed with --flags to
 virt-builder... And it's easy :)

 As a side note, these comments might not make much sense in light of some
 of the os-tree stuff you're doing, but I'm not up to speed on all the
 specifics, so my commentary assumes that stuff doesn't exist. My bad if
 that's the case.


 

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/44#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


[cloud] #59: Process for determining when and why Docker trusted images need to be rebuilt

2014-05-21 Thread Fedora Cloud Trac Tickets
#59: Process for determining when and why Docker trusted images need to be
rebuilt
+
 Reporter:  scollier|  Owner:
 Type:  task| Status:  new
 Priority:  normal  |  Milestone:  Future
Component:  Docker (Other)  |   Keywords:
+
 We have several Docker trusted images hosted on the Docker index:

 https://index.docker.io/u/fedora/

 These are built from the Fedora Cloud github account here:

 https://github.com/fedora-cloud/Fedora-Dockerfiles

 We need a clear process for deciding when these layered images need to be
 rebuilt.  Is it when new RPMs are released?  Security errata?  Changes to
 config files?  What are other criteria that could trigger the need for a
 rebuild?

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/59
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] #59: Process for determining when and why Docker trusted images need to be rebuilt

2014-05-21 Thread Fedora Cloud Trac Tickets
#59: Process for determining when and why Docker trusted images need to be
rebuilt
+-
 Reporter:  scollier|   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  Docker (Other)  |  Resolution:
 Keywords:  meeting |
+-
Changes (by mattdm):

 * keywords:   = meeting


-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/59#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


Re: [cloud] #35: External need: Automatic Image Upload

2014-05-22 Thread Fedora Cloud Trac Tickets
#35: External need: Automatic Image Upload
-+-
 Reporter:  mattdm   |   Owner:
 Type:  task |  Status:  new
 Priority:  normal   |   Milestone:  Fedora 21
Component:  Infrastructure  Release |  (Alpha)
  Engineering|  Resolution:
 Keywords:   |
-+-

Comment (by mattdm):

 Note, particularly, that in addition to uploading images, the plan needs
 some way of keeping track of which images were uploaded to each location,
 including build metadata (source, kickstart, some kinda label) and after-
 the-fact metadata (test results, labeling as release candidate or release,
 etc.).

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/35#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] #35: External need: Automatic Image Upload

2014-05-22 Thread Fedora Cloud Trac Tickets
#35: External need: Automatic Image Upload
-+-
 Reporter:  mattdm   |   Owner:  oddshocks
 Type:  task |  Status:  assigned
 Priority:  normal   |   Milestone:  Fedora 21
Component:  Infrastructure  Release |  (Alpha)
  Engineering|  Resolution:
 Keywords:   |
-+-
Changes (by mattdm):

 * owner:   = oddshocks
 * status:  new = assigned


-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/35#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] #60: Enable serial console for bootloader

2014-05-23 Thread Fedora Cloud Trac Tickets
#60: Enable serial console for bootloader
--+-
 Reporter:  fabiand   |   Owner:
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Future
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+-

Comment (by fabiand):

 Yep, as ausil said, I'm talking about extlinux (the bootloader :) ).

 I tested using qemu -kvm -snapshot -hda $IMG -serial stdio

 The bootloader output is missing, as soon as the kernel starts output
 appears (which matches what you said in comment 1, mattdm).

 Please see this post for more details:
 http://dummdida.tumblr.com/post/86583072660/automatic-testing-of-a-fedora-
 cloud-image-with-gherkin

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/60#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] #60: Enable serial console for bootloader

2014-05-23 Thread Fedora Cloud Trac Tickets
#60: Enable serial console for bootloader
--+-
 Reporter:  fabiand   |   Owner:
 Type:  task  |  Status:  new
 Priority:  normal|   Milestone:  Future
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+-

Comment (by mattdm):

 Ah, got it. Right now, image building in koji is broken entirely, but once
 that's fixed we can add this -- I guess to both pvgrub and extlinux.

 Also, the automated testing is _awesome_ -- thanks for working on that!

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/60#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] #59: Process for determining when and why Docker trusted images need to be rebuilt

2014-05-27 Thread Fedora Cloud Trac Tickets
#59: Process for determining when and why Docker trusted images need to be
rebuilt
+-
 Reporter:  scollier|   Owner:
 Type:  task|  Status:  new
 Priority:  normal  |   Milestone:  Future
Component:  Docker (Other)  |  Resolution:
 Keywords:  meeting |
+-
Changes (by jzb):

 * cc: jzb@… (added)


-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/59#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


[cloud] #63: list fedora accounts needed for releng to make official cloud images content

2014-05-29 Thread Fedora Cloud Trac Tickets
#63: list fedora accounts needed for releng to make official cloud images
content
+
 Reporter:  mattdm  |  Owner:
 Type:  task| Status:  new
 Priority:  normal  |  Milestone:  Fedora 21 (Branch)
Component:  --- |   Keywords:
+
 What official accounts and agreements do we need to upload cloud images to
 our intended targets, including Amazon AWS, Google GCE, and etc?

 What do we need to a) upload docker base images and b) do docker trusted
 builds?

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/63
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] #61: meeting agenda item: next steps on test plan

2014-05-30 Thread Fedora Cloud Trac Tickets
#61: meeting agenda item: next steps on test plan
-+-
 Reporter:  mattdm   |   Owner:
 Type:  task |  Status:  new
 Priority:  normal   |   Milestone:  Future
Component:  ---  |  Resolution:
 Keywords:  meeting  |
-+-

Comment (by roshi):

 Per the last Cloud meeting, I've created a wiki space for discussing this
 ticket: https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/ticket61

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/61#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] #16: rename cloud spin kickstart to distinguish the cloud base image

2014-06-02 Thread Fedora Cloud Trac Tickets
#16: rename cloud spin kickstart to distinguish the cloud base image
+-
 Reporter:  mattdm  |   Owner:  red
 Type:  task|  Status:  closed
 Priority:  minor   |   Milestone:  Fedora 21 (Branch)
Component:  --- |  Resolution:  fixed
 Keywords:  |
+-
Changes (by mattdm):

 * resolution:   = fixed
 * status:  assigned = closed


Comment:

 this looks like it's done

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/16#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


[cloud] #64: meeting agenda item/tracker for Project Atomic

2014-06-02 Thread Fedora Cloud Trac Tickets
#64: meeting agenda item/tracker for Project Atomic
+-
 Reporter:  mattdm  |  Owner:
 Type:  task| Status:  new
 Priority:  normal  |  Milestone:  Future
Component:  --- |   Keywords:  meeting
+-
 Weekly report on status/blockers/todos for Project Atomic in Fedora --
 starting with image generation and ostree repos and building up from
 there.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/64
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] #15: migrate to GPT instead of old-style partitions

2014-06-03 Thread Fedora Cloud Trac Tickets
#15: migrate to GPT instead of old-style partitions
--+
 Reporter:  mattdm|   Owner:  janeznemanic
 Type:  task  |  Status:  assigned
 Priority:  normal|   Milestone:  Fedora 21 (Alpha)
Component:  Cloud Base Image  |  Resolution:
 Keywords:|
--+

Comment (by janeznemanic):

 At the moment we are using MBR partitioning. If we want to use GPT
 partitioning with these specs [
 http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/]
 we need to use GPT partitioning with EFI system partition(ESP).
 I think these lines need to be added to kickstart file if we want to have
 GPT partitioning with ESP.

 bootloader --timeout=1 --append=inst.gpt console=tty1
 console=ttyS0,115200n8 extlinux

 part efi --size 200 --fstype vfat #or should it be --fstype efi

 I'm a little confused about efi partition file system type. Because the
 web page [
 http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/]
 specifies that the allowed file system type in the case of ESP is vfat.
 But the official Red Hat documentation says that the file system type in
 ks file can also be efi. Not sure what to use.
 So if I add the above lines to ks file will the cloud image use GPT with
 ESP? Team comments and suggestions needed.

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/15#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


  1   2   3   4   5   6   7   8   9   >