Re: [cloud] #24: File F21 change: Big Data Image
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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)
#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
#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
#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.
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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
#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