Re: Non-atomic Vagrant images?
On Thu, Mar 19, 2015 at 08:41:55PM -0400, Matthew Miller wrote: I think Matthew Miller said he added the kickstart file, need to see what else needs to be done there. Someone needs to test that it works, and make any needed changes. Send me the kickstart file and I'll spin a version using packer Cool. https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base-vagrant.ks You'll probably need to flatten the includes. Was someone able to test this? I'm not really a vagrant user -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader ___ 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: Non-atomic Vagrant images?
- Original Message - From: Matthew Miller mat...@fedoraproject.org To: Fedora Cloud SIG cloud@lists.fedoraproject.org Sent: Tuesday, March 24, 2015 7:31:13 AM Subject: Re: Non-atomic Vagrant images? On Thu, Mar 19, 2015 at 08:41:55PM -0400, Matthew Miller wrote: I think Matthew Miller said he added the kickstart file, need to see what else needs to be done there. Someone needs to test that it works, and make any needed changes. Send me the kickstart file and I'll spin a version using packer Cool. https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-cloud-base-vagrant.ks You'll probably need to flatten the includes. Was someone able to test this? I'm not really a vagrant user If we have images, I can test them today. -- Joe Brockmeier | Principal Cloud Storage Analyst j...@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ ___ 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: Password policy changes
- Original Message - From: Matthew Miller mat...@fedoraproject.org To: Fedora Cloud SIG cloud@lists.fedoraproject.org Cc: desk...@lists.fedoraproject.org, ser...@lists.fedoraproject.org, k...@lists.fedoraproject.org Sent: Tuesday, March 24, 2015 2:25:02 PM Subject: Re: Password policy changes On Tue, Mar 24, 2015 at 08:36:28AM -0700, Adam Williamson wrote: I'm wondering if those products/spins intending to set a policy weaker than the default could all agree on the same one, so there'd only be at most two policies to care about (and if all products/spins overrode the upstream default, there'd only be one). I won't speak for everyone, but I *think* the general cloud attitude here is to use private/public keys and certificate-based auth instead of passwords in any case. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct That's been my experience, as well. -- David ___ 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: Fedora Cloud Docs
My two cents: 1. Pandoc is your friend!!! Write rST, Markdown, AsciiDoc, Textile, DocBook, LaTeX and a bunch of others and Pandoc translates to HTML, epub, various other text markups and if you've got the LaTeX tool chain, PDFs. It will only take me half a day or so to put up a Dockerfile with these goodies - I'll fork fedora-dockerfiles on GitHub and build this puppy, since I use it heavily. 2. Standardization is good - IMHO vital. So let's make a decision that minimizes the amount of time we waste building tools for ourselves and standardize on something we can live with. Personally, I think Sphinx / rST / readthedocs is the best option - I'm a tad biased because I know some of the creators, but given Pandoc's Markdown - rST conversion I don't see any reason to use another toolchain. On Tue, Mar 24, 2015 at 2:21 PM, David Gay d...@redhat.com wrote: - Original Message - From: Pete Travis li...@petetravis.com To: Fedora Cloud SIG cloud@lists.fedoraproject.org, j...@redhat.com Sent: Tuesday, March 24, 2015 11:04:00 AM Subject: Re: Fedora Cloud Docs On Mar 24, 2015 11:38 AM, Joe Brockmeier j...@redhat.com wrote: On 03/24/2015 01:01 PM, Jared K. Smith wrote: If there's a particular cloud-related topic you'd like to write about -- go write! And then we can worry about the tooling, once there's some content to work with. I agree...ish. If Kushal, myself, mattdm, and jbrooks (for example) are collaborating on a document, we really need a single format to target. Best, jzb -- I was actually polling about preferred markup format, because I am writing tools, but Jared is right: don't let things like my misadventures with python hold you back! Start now, don't worry about formats, docs will handle the business of publishing and converting. --Pete ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct I think it'd be good to have at least all *our* (Cloud) docs in one format. I think it'd be a good idea to have that vote on markdown, rst, or otherwise. Of course, not being sure of that format yet doesn't mean you can't do some writing now. My two cents. -- David ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. ___ 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: Fedora EC2 Amis: SriovNetSupport
- Original Message - From: milanisko k vetri...@gmail.com To: Fedora Cloud SIG cloud@lists.fedoraproject.org Sent: Friday, March 20, 2015 7:52:21 AM Subject: Re: Fedora EC2 Amis: SriovNetSupport That would be one way. However, since it actually is a majority of the instance types[1] that support this feature, I'd vote to make it the default. That's unless it prevents using/booting the small instances of course, what AFAIK isn't the case --- I was able to create a snapshot ami from an F21 instance, register it with the sriov flag and boot both a t2 and an r3 instances without any issue and confirmed the sriov flag was in effect on the r3 instance. The only limit I know of is the ami has to be HVM[2]. Moreover, the feature is for free, no extra charges apply so why not to take advantage of lower latencies on the instances. Cheers, milan [1] Enhanced Networking Support, The Instance Types Matrix, http://aws.amazon.com/ec2/instance-types/ [2] Enabling Enhanced Networking on Other Linux Distributions, http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html 2015-03-19 18:39 GMT+01:00 Garrett Holmstrom gho...@fedoraproject.org : On 2015-03-19 9 :11, milanisko k wrote: I'd like to ask about the status/plan of SriovNet support[1] for Fedora Amazon images. I was able to set this up manually for recent F21 ami ami-5cd9ea41, but it is quite an inconvenient experience --- one has to instantiate, stop, set attribute value through the CLI tool and start again to enable the feature. Would it be possible to register future Fedora amis with the enhanced networking flag enabled[1]? As far as motivation is concerned, please check the blog post[2] for some performance evaluation. Since that only works for some types of instances it wouldn't make sense to do that for all images, but registering a separate image (from the same bundle/snapshot) with that enabled would be reasonable. -- Garrett Holmstrom __ _ 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 mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct I'm responsible for Fedimg which uploads our AMIs. Seems to be a reasonable thing to get people's opinions on. Do you *have* to start the instance up then stop it and do all the stuff at [1]? If that has to be done for every HVM upload we provide, that might add some significant time and oddness to the automatic upload process. I don't see a way to just simply toggle a flag at AMI registration time, but then again, I'm not familiar with enhanced networking on AWS. -- David [1]: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html#enhanced-networking-linux under Enabling Enhanced Networking on Other Linux Distributions ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Password policy changes
Hey, folks. I'm writing with my Server SIG member hat on, here. We've been discussing password policy changes at our meeting today. So the Great Password Policy Bunfight of 2015 was resolved by anaconda creating a mechanism for products/spins to set their own password policy: https://github.com/rhinstaller/anaconda/commit/8f24eeaedd7691b6ebe119592e5bc09c1c42e181 I'm slightly worried, however, about the possibility that everyone goes out and picks a more lenient policy more or less at random and we wind up with different policies on every Fedora medium. That seems like it'd be needlessly confusing to users and difficult to document. I'm wondering if those products/spins intending to set a policy weaker than the default could all agree on the same one, so there'd only be at most two policies to care about (and if all products/spins overrode the upstream default, there'd only be one). The obvious choice would be the pre-F22 policy, which I believe should be: --nostrict --minlen=6 --minquality=50 --nochanges --emptyok (though it's not *entirely* clear from the code - I think it used pwquality upstream defaults - so I may be a bit off). What's the general feeling here? Have other SIGs discussed this yet? Come to any decisions? Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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: Fedora Cloud Docs
I'm game to learn Sphinx and rST - I'm a heavy Markdown user already and Eric Holscher's almost persuaded me rST is significantly better. ;-) What time zone are you in? I'm in US Pacific Daylight - UTC - 7 hours. On Thu, Mar 19, 2015 at 2:29 AM, Kushal Das kushal...@gmail.com wrote: On 18/03/15, Pete Travis wrote: Hey cloud team, I think we need some cloud docs. Fedora has a lot to offer in the cloud area, and I'm sure that those engaged in the space are excited that Fedora has what they are looking for. The uninitiated, on the other hand, are looking for what Fedora has, and we can do better to demonstrate that. We have a cloud guide, https://git.fedorahosted.org/cgit/docs/cloud-guide.git/ . It covers some basics, ie euca2ools, but never really made it out of draft state, and your work has left it far behind. We don't have anyone on the Docs team fully engaged to track the cloud space, or anyone on the cloud team engaged to maintain that guide. Also, it's written in docbook, and a lot of folks aren't into that. So, as I'm working on some tooling for a new Fedora Docs site, I'd like to know what would get *you* into writing about Fedora Cloud. In the most direct sense, it's a question about markup and delivery, ie a collection of markdown or reStructuredText files in a git repo. In a broad sense, anything along the lines of I would write docs for using Fedora Cloud, if... would be great. Personally it will be easier if we start using Sphinx along with reStructruedText. Most of the documents I write[1] or manage[2] are in Sphinx using rst. It required I can provide IRC classroom trainings and other training material to get anyone into Sphinx within few hours. We can have a Fedora focused theme for Sphinx projects. [1] http://worknotes.rtfd.org [2] http://tunir.rtfd.org [3] http://pymbook.rtfd.org Kushal -- Fedora Cloud Engineer CPython Core Developer Director @ Python Software Foundation http://kushaldas.in ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. ___ 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: Fedora Cloud Docs
Docker image is built - https://registry.hub.docker.com/u/znmeb/tech-writing/. The source is on GitHub at https://github.com/znmeb/Fedora-Dockerfiles/tree/tech-writing/tech-writing. This is a branch on a fork of Fedora's Fedora-Dockerfiles. If the project wants a pull request, let me know and I'll send one. It's probably too late to get this into the F22 fedora-dockerfiles package. Contents: python-sphinx-*, pandoc-*, FlightCrew and Calibre for ebook wrangling and a few command-line utilities. At some point when I stop having fun with Project Atomic on Windows Hyper-V I'll update this for F22. On Tue, Mar 24, 2015 at 2:54 PM, M. Edward (Ed) Borasky zn...@znmeb.net wrote: My two cents: 1. Pandoc is your friend!!! Write rST, Markdown, AsciiDoc, Textile, DocBook, LaTeX and a bunch of others and Pandoc translates to HTML, epub, various other text markups and if you've got the LaTeX tool chain, PDFs. It will only take me half a day or so to put up a Dockerfile with these goodies - I'll fork fedora-dockerfiles on GitHub and build this puppy, since I use it heavily. 2. Standardization is good - IMHO vital. So let's make a decision that minimizes the amount of time we waste building tools for ourselves and standardize on something we can live with. Personally, I think Sphinx / rST / readthedocs is the best option - I'm a tad biased because I know some of the creators, but given Pandoc's Markdown - rST conversion I don't see any reason to use another toolchain. On Tue, Mar 24, 2015 at 2:21 PM, David Gay d...@redhat.com wrote: - Original Message - From: Pete Travis li...@petetravis.com To: Fedora Cloud SIG cloud@lists.fedoraproject.org, j...@redhat.com Sent: Tuesday, March 24, 2015 11:04:00 AM Subject: Re: Fedora Cloud Docs On Mar 24, 2015 11:38 AM, Joe Brockmeier j...@redhat.com wrote: On 03/24/2015 01:01 PM, Jared K. Smith wrote: If there's a particular cloud-related topic you'd like to write about -- go write! And then we can worry about the tooling, once there's some content to work with. I agree...ish. If Kushal, myself, mattdm, and jbrooks (for example) are collaborating on a document, we really need a single format to target. Best, jzb -- I was actually polling about preferred markup format, because I am writing tools, but Jared is right: don't let things like my misadventures with python hold you back! Start now, don't worry about formats, docs will handle the business of publishing and converting. --Pete ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct I think it'd be good to have at least all *our* (Cloud) docs in one format. I think it'd be a good idea to have that vote on markdown, rst, or otherwise. Of course, not being sure of that format yet doesn't mean you can't do some writing now. My two cents. -- David ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. ___ 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: Fedora Cloud Docs
On 03/24/2015 01:01 PM, Jared K. Smith wrote: If there's a particular cloud-related topic you'd like to write about -- go write! And then we can worry about the tooling, once there's some content to work with. I agree...ish. If Kushal, myself, mattdm, and jbrooks (for example) are collaborating on a document, we really need a single format to target. Best, jzb -- Joe Brockmeier | Principal Cloud Storage Analyst j...@redhat.com | http://community.redhat.com/ Twitter: @jzb | http://dissociatedpress.net/ signature.asc Description: OpenPGP digital signature ___ 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: Fedora Cloud Docs
On Thu, Mar 19, 2015 at 8:20 AM, Kushal Das kushal...@gmail.com wrote: Few advantages of using Sphinx and rst: Slowly catching up on this mailing list, so I apologize in advance for the late reply. The point here isn't to debate which markup language should we use, it's to solicit volunteers to actually write the *content*. I've volunteered many times before (and will continue to do so) to convert whatever you write in just about any format (text, asciidoc, rst, markdown, pencil and paper) and convert it into DocBook or anything else the Docs team thinks is appropriate. I'll even proofread, edit, and help organize. What we need is content! If there's a particular cloud-related topic you'd like to write about -- go write! And then we can worry about the tooling, once there's some content to work with. -Jared ___ 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: Atomic 2 week releases
On 13/03/15, Colin Walters wrote: On Fri, Mar 13, 2015, at 05:13 PM, Michael P. McGrath wrote: Yeah. We can do much better than we are now at just running through the current official process. Also, rather crucially there are no trademark concerns with images generated from updates-testing or just updates. I'd still like to experiment with a side repo implementing continuous delivery and actually making use of the fact that both Docker and ostree allow rollbacks and are by their nature more agile - will post more about that later. But option #1 here has my vote for now - it's a matter of trying it for a few months or so, we can always re-evaluate. I have a new tool available called Tunir[1] , which can be used to test the updated atomic images automatically. I already the Fedora test cases[2] running in Tunir. [1] http://kushaldas.in/posts/tunir-a-simple-ci-with-less-pain.html [2] https://github.com/kushaldas/tunirtests Kushal -- Fedora Cloud Engineer CPython Core Developer Director @ Python Software Foundation http://kushaldas.in ___ 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 image lifetimes
On 03/24/2015 01:51 PM, David Gay wrote: Cool, thanks for the input everyone. A short summary of what's been discussed: 1. Everyone seems to agree that we should hope to get usage data from AWS, but as Dennis mentioned (and I expect), there isn't any usage data available for AMIs. If there is such a console, I've never seen one. 2. Q: If a user spins up an AMI and then it's deleted by the provider, do they still have their instance(s) or do they lose the ability to create new images? A: The instances they already started would still run and be available, but they wouldn't be able to spin up anything new. If creating/killing instances is something they do a lot (autoscaling groups, worker farms, etc) then that could hose them just as surely as killing their existing instances. 3. We should probably look into how other projects handle their AMIs. I think the consensus here though is that whatever lifetime we have for releases, the alpha, beta, TC, RC, and other testing builds can -- and should -- be safely eliminated after the release. There's no good reason I can think of that someone would yell at us for deleting a test build AMI of a release that's already happened. 4. Anyone have an opinion on jzb wondering if we should run this by FESCo? 5. Regarding this exchange: at around $5/month, so each final AMI built will cost $5 * 13-16 months, or $65-$80. Not expensive, but not exactly free. Costs will, of course, vary for other cloud providers. your math is off, there should only be 9 Atomic as we only build it for x86_64 where we build the base for i386 and x86_64 so you have two arches by 2 image types by 9 regions Whatever the costs will be per AMI, I can tell you that what I've heard from people in the cloud WG is that we want a number of different AMIs *per build*. A new build currently results in 6 AMIs: 2 for atomic (standard + gp2) and 4 for base (standard + gp2, both for HVM and paravirtual virtualization). I spoke with gholms some time back and I think we determined that we're also going to want instance-store AMIs, as well as *encrypted* EBS AMIs. So, maybe there +1 for instance-store AMIs, they're incredibly useful. I think it's a good time to think about what AMIs we should be producing though, and talk to FESCO about just how much we're willing to spend on providing AMIs. should be some discussion on that with the full group, since that will result in a large number of AMIs. If we end up building that many different combinations of storage types, volume types, and virtualization types, we're talking a fair amount of AMIs being kept up during the release process, because of how many image builds go through Koji. Dennis mentioned to me that there is some sort of Koji bug that, if fixed, would builds be marked as either real life or scratch, so we could at least cut down a bit on the number of AMIs being built. I think this discussion should continue a bit more based on all that. However, I *do* move that I immediately delete at least all the alpha, beta, TC, and RC builds that were created back when we were working on F21. +1 sounds like a good plan for now. -- David ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. ___ 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 image lifetimes
Cool, thanks for the input everyone. A short summary of what's been discussed: 1. Everyone seems to agree that we should hope to get usage data from AWS, but as Dennis mentioned (and I expect), there isn't any usage data available for AMIs. If there is such a console, I've never seen one. 2. Q: If a user spins up an AMI and then it's deleted by the provider, do they still have their instance(s) or do they lose the ability to create new images? A: The instances they already started would still run and be available, but they wouldn't be able to spin up anything new. If creating/killing instances is something they do a lot (autoscaling groups, worker farms, etc) then that could hose them just as surely as killing their existing instances. 3. We should probably look into how other projects handle their AMIs. I think the consensus here though is that whatever lifetime we have for releases, the alpha, beta, TC, RC, and other testing builds can -- and should -- be safely eliminated after the release. There's no good reason I can think of that someone would yell at us for deleting a test build AMI of a release that's already happened. 4. Anyone have an opinion on jzb wondering if we should run this by FESCo? 5. Regarding this exchange: at around $5/month, so each final AMI built will cost $5 * 13-16 months, or $65-$80. Not expensive, but not exactly free. Costs will, of course, vary for other cloud providers. your math is off, there should only be 9 Atomic as we only build it for x86_64 where we build the base for i386 and x86_64 so you have two arches by 2 image types by 9 regions Whatever the costs will be per AMI, I can tell you that what I've heard from people in the cloud WG is that we want a number of different AMIs *per build*. A new build currently results in 6 AMIs: 2 for atomic (standard + gp2) and 4 for base (standard + gp2, both for HVM and paravirtual virtualization). I spoke with gholms some time back and I think we determined that we're also going to want instance-store AMIs, as well as *encrypted* EBS AMIs. So, maybe there should be some discussion on that with the full group, since that will result in a large number of AMIs. If we end up building that many different combinations of storage types, volume types, and virtualization types, we're talking a fair amount of AMIs being kept up during the release process, because of how many image builds go through Koji. Dennis mentioned to me that there is some sort of Koji bug that, if fixed, would builds be marked as either real life or scratch, so we could at least cut down a bit on the number of AMIs being built. I think this discussion should continue a bit more based on all that. However, I *do* move that I immediately delete at least all the alpha, beta, TC, and RC builds that were created back when we were working on F21. -- David ___ 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: Fedora Cloud Docs
On Mar 24, 2015 11:38 AM, Joe Brockmeier j...@redhat.com wrote: On 03/24/2015 01:01 PM, Jared K. Smith wrote: If there's a particular cloud-related topic you'd like to write about -- go write! And then we can worry about the tooling, once there's some content to work with. I agree...ish. If Kushal, myself, mattdm, and jbrooks (for example) are collaborating on a document, we really need a single format to target. Best, jzb -- I was actually polling about preferred markup format, because I am writing tools, but Jared is right: don't let things like my misadventures with python hold you back! Start now, don't worry about formats, docs will handle the business of publishing and converting. --Pete ___ 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: Fedora Cloud Docs
- Original Message - From: Pete Travis li...@petetravis.com To: Fedora Cloud SIG cloud@lists.fedoraproject.org, j...@redhat.com Sent: Tuesday, March 24, 2015 11:04:00 AM Subject: Re: Fedora Cloud Docs On Mar 24, 2015 11:38 AM, Joe Brockmeier j...@redhat.com wrote: On 03/24/2015 01:01 PM, Jared K. Smith wrote: If there's a particular cloud-related topic you'd like to write about -- go write! And then we can worry about the tooling, once there's some content to work with. I agree...ish. If Kushal, myself, mattdm, and jbrooks (for example) are collaborating on a document, we really need a single format to target. Best, jzb -- I was actually polling about preferred markup format, because I am writing tools, but Jared is right: don't let things like my misadventures with python hold you back! Start now, don't worry about formats, docs will handle the business of publishing and converting. --Pete ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct I think it'd be good to have at least all *our* (Cloud) docs in one format. I think it'd be a good idea to have that vote on markdown, rst, or otherwise. Of course, not being sure of that format yet doesn't mean you can't do some writing now. My two cents. -- David ___ 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: Password policy changes
On Tue, Mar 24, 2015 at 08:36:28AM -0700, Adam Williamson wrote: I'm wondering if those products/spins intending to set a policy weaker than the default could all agree on the same one, so there'd only be at most two policies to care about (and if all products/spins overrode the upstream default, there'd only be one). I won't speak for everyone, but I *think* the general cloud attitude here is to use private/public keys and certificate-based auth instead of passwords in any case. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
