On Mon, Jan 7, 2019 at 3:41 PM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > > On Mon, Jan 07, 2019 at 09:26:25AM -0800, Kevin Fenzi wrote: > > > central project management service from the Infrastructure team — > > > probably [Taiga], although we're asking the team to also look at GitLab > > > for this purpose. We'll have a dedicated instance, likely hosted, and we > > > ask each team to have a minimum presence on that tool, whether they use > > > it otherwise or not. The presence should, at a minimum, indicate the > > > team's communication methods for synchronous and asynchronous > > > communication and where project information may be found if not in the > > > shared tool. That way, there will be an automatically-curated list of > > > active teams. (See <https://tree.taiga.io/discover> for an idea of what > > > this would look like — imagine each project there is a Fedora team.) > > Is this request public anywhere? I know we talked about it in the past, > > but it would be nice to have someplace people to see the requirements > > and chime in with their thoughts. I'm not sure if this would best be a > > list thing or a ticket or what... > > Maybe tracked in Taiga? :) I've been talking with Jim about it — I'll check > with him about what he thinks would be best. > > > >This means a shift away from running all layers of the > > > stack and focusing more on application management. The goal is to have > > > the Infra team administering applications, not low-level infrastructure. > > I am not sure if this really follows from the goal above. > > Sure, low level infrastructure takes some time, but I don't think it's > > all that much, and also some of it's unavoidable. > > As I understand it, there was just a multi-month, multi-person project to > update OpenStack. That's the kind of thing I'm talking about. > > > > #agreed The Fedora Project wants to advance free and open source > > > software and as a pragmatic matter we recognize that some infrastructure > > > needs may be best served by using closed source or non-free tools today. > > > Therefore the Council is willing to accept closed source or non-free > > > tools in Fedora's infrastructure where free and open source tools are > > > not viable or not available. (+9,0,-0) > > > > So, what do you mean running non free tools "in Fedora's infrastructure" > > here? As noted above we always said upstreams for applications or the > > like can do as the people doing the work decide, but does this mean we > > should (for example) consider running oracle db if we feel it would be > > better for our database loads? Can you clarify here? We don't currently > > run any non free software actually in infrastructure. > > Hmmm; I'm not super sure about that exact wording in re-reading it. I think > "infrastructure" there is to be read very broadly. We meant things like: > hosting VMs in a cloud service where the cloud service stack might not be > open source all the way to bare metal (GCE, Azure, AWS). We'd want to make > sure we aren't locked in (for example, by using OpenShift on top of that). > This certainly wasn't meant to be an instruction to go look for proprietary > replacements for infrastructure. And "we feel it would be better" is > certainly not the same as "not viable or not available". > > Although we aren't in this situation now, one thing I can imagine is back > before Amazon released open-licensed versions of their tool to upload > images. I think it probably would have been okay for Fedora to use that > proprietary tool in order to make Fedora Cloud available to people. > > n > > > #action contyk, FESCo to work with Infra to examine current > > > applications and determine: 1. which applications can be moved out of > > > the datacenter immediately or in the short term, > > Moved out of the datacenter to... where? Cloud instances? > > Hosted solutions? Based on what critera? > > Any of those things. I think in general, if there's an open source hosted > version of something (like Taiga) that should absolutely be the default. > Otherwise, yes, cloud instances — or better, running containers in a > provided-to-us-as-a-service OpenShift. > We should be careful about this. We got screwed over with Transifex years ago, and it'd be bad if that was repeated. If we can make self-hosting our services simpler, easier, and let more people do it, that'd be the holy grail. > > This is going to cause a lot of short term work for... well, everyone. > > Especially in the case of things we don't spend much time on now, since > > everyone will have to adjust their workflow and we will have to spend > > time migrating things. > > I recognize that this is non-trivial, and it's possible that it's easier to > just let some things sit where they are. But a lot of those normally > low-maintenance things are tech-debt time bombs. Or, they're really > languishing. > It'd be better if it was easier for more people to participate. We have a lot of infra-types. It's kind of amazing in a bad way that despite all that, we don't really have an easy way for more people to help on that side. > > > >2. Which applications > > > have industry-standard open source or proprietary alternatives that we > > > could move to. > > I'm not coming up with too long a list here. Most of our apps are highly > > specialised for distro making, but: > > > > * fedocal (which we pretty much spend no time on) > > Yeah, this'd be a good candidate. It was a great, useful tool for its time > but is rather dated. It could use a *lot* of development work, and > realistically, we all know it's not going to get it. > Are there any nice open source calendar/meeting assignment web apps out there we could deploy? I feel like this is a common enough venture that someone has done something... > > > * pagure (which we want to keep? or no?) > > I think we're pretty committed to pagure for src.fpo. But for general git > hosting... I think it's a great project — but I also see that Debian, GNOME, > Linux Kernel, are evaluating it and picking GitLab. Meanwhile GitLab (and > GitHub) are growing new useful features rapidly and there's no way we can > invest development to keep up. I don't think anything like "kill pagure!" > but I also don't think that Fedora *as a project* can afford to invest > significant time. > Pagure as a project is starting to pick up steam in its own right. And users outside of Fedora (both public and private) are also turning into contributors. If anything, this is one of the better successes we've had in a while. As for the feature development, Pagure is keeping pace with solutions like GitHub. We're now at the point where Pagure meets the features that Debian was requesting for their Alioth migration, and other groups are considering rolling out Pagure instances as well. As for the pagure.io forge, a large part of its lack of success is that people don't know how to move to it. Heck, even I don't really know how to effectively migrate a project from GitHub.com or GitLab.com or some other site to Pagure.io and migrate things like issues, PRs, etc. It is a good solution and it is developing rapidly into being a good competitor to the others. It helps that Pagure is drastically simpler than most other solutions to deploy and extend. > > * nagios (pagerduty?) > > I had a great conversation with Jef Spatela who is now at Sensu at > AnsibleFest. Maybe Sensu. :) > I've had poor experiences with PagerDuty... Never used Sesu, but it looks interesting... > > * magazine /communityblog ( wordpress.org? but there's very little time > > spent on these too) > > All of the "very little times" do add up. > > > * mailing lists (discourse?) > > Or a more traditional mailing list provider — maybe ponee.io? > https://fedora.fsn.ponee.io/ > Please no. I *like* our mailing list system as it is. > > * openstack (The big consumer here is copr... if it could move to the > > cloud or somewhere and we didn't need a openstack I would be very happy). > > Yes. I think this is something we can make happen. Possibly we can work > something out with Mass Open Cloud. > I think it's pretty obvious our Copr host platform (RHOSP 5) has been a disappointment. It's unfortunate that there's no formal avenue for people to sponsor and offer resources to improve services like Copr and assist with improving the quality of the service. People want to depend on it, and it's still not getting the love it needs. Supposedly it was going to be upgraded and improved, but I dunno what's going on there. Beyond that, we should consider making it possible for people and companies to be able to sponsor effort and resources in Fedora, similar to what openSUSE does. That's how their OBS has so much more resources than our Koji and Copr systems combined. > > I think things like koji are particularly ill suited to move anywhere > > since we need to run Fedora on the builders, they have to run virt, and > > we have lots of arches that aren't commonly available in cloud. > > Yeah, multi-arch is going to be a sticking point for a lot of things. > Losing the ability for people to be able to trivially self-host variants of our infrastructure would be a huge loss, in my mind. _______________________________________________ council-discuss mailing list -- council-discuss@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to council-discuss-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/council-discuss@xxxxxxxxxxxxxxxxxxxxxxx
