Re: [foreman-dev] Koji repo sync metadata problem

I would be against syncing regularly but I don't do much packaging so it's up to you. The problem I see is "random" breakage. You come to work on Monday after sync and if you don't realize the package was deleted from EPEL, you can burn hour or something to figure it out sometimes. This was pretty

[foreman-dev] Re: Discourse summary week 2 (ish)

I'm generally silent in here. It's certainly a +1 from me. I like the formatting. I like the categories. I like the tags. I like the suggestions. Will it take some getting used to? Of course it will. -- You received this message because you are subscribed to the Google Groups "foreman-dev"

Re: [foreman-dev] Koji repo sync metadata problem

I think we should sync & update. CentOS has no concept of supported minor releases and we should be testing with a supported release. On Wed, Nov 15, 2017 at 03:57:40PM -0500, Eric D Helms wrote: This now appears to be working again. One out standing question that affects nodejs- packaging

Re: [foreman-dev] Koji repo sync metadata problem

This now appears to be working again. One out standing question that affects nodejs- packaging builds. As part of the RHEL 7.4 release, http-parser was removed from EPEL. With this latest round of Koji external repositories update we now have a newer EPEL with this package removed. We did not

[foreman-dev] Question about defaults for VM memory

Hello, How does foreman decide what the defaults are for memory when provision VMs via the webui? Sometimes when creating VMs to test provisioning configs, I forget to adjust to memory (I usually use about 2 gig to be safe). Foreman defaults to 768MB. I am wondering if that is enough, RHEL

Re: [foreman-dev] Koji repo sync metadata problem

I had forgotten to run the repo-regen on Koji. That is finishing up now. I will run another test after and report back. On Wed, Nov 15, 2017 at 2:08 PM, Patrick Creech wrote: > On Wed, 2017-11-15 at 14:00 -0500, Patrick Creech wrote: > > On Wed, 2017-11-15 at 19:56 +0100,

Re: [foreman-dev] Koji repo sync metadata problem

I still get errors when building: http://koji.katello.org/koji/taskinfo?taskID=52363 http://koji.katello.org/kojifiles/work/tasks/2363/52363/root.log DEBUG util.py:439: Error downloading packages: DEBUG util.py:439:1:nodejs-6.10.3-1.el7.x86_64: failed to retrieve

Re: [foreman-dev] Koji repo sync metadata problem

Looks like everything is back up and working as expected. For packagers, keep in mind that this updated some of our external repositories to their latest versions if you see any oddities. This also means that Fedora 27 is available as an external repository for Pulp and Katello clients. On Wed,

Re: [foreman-dev] Discourse summary week 2 (ish) - inbound email

> I will update the direct-category and reply-to addresses (the > foreman.discourse+(token)@gmail.com one) to be correct later today, > but be aware it will break reply-to addresses in existing mails - > sorry, unavoidable but entirely worthwhile. Quick update on the email record stuff. These

Re: [foreman-dev] Discourse summary week 2 (ish)

Also a +1 from me. Among other things, I like the categories, markdown support, and tags. John Mitsch Red Hat Engineering (860)-967-7285 irc: jomitsch On Wed, Nov 15, 2017 at 9:59 AM, Sebastian Gräßl wrote: > I am one of the (silent) +1 voices Greg mentioned. > >

Re: [foreman-dev] Request to add Fedora 27 to Koji

On Wed, 2017-11-15 at 15:42 +0100, Lukas Zapletal wrote: > We have 200GB spare space, one more Fedora could fit. Can we delete > Fedoras 24 and 25? This is definitely the last time before we'd need > to expand space again. With regards to pulp needs, Fedora 24 can go, as that is no longer

Re: [foreman-dev] Discourse summary week 2 (ish)

I am one of the (silent) +1 voices Greg mentioned. Discourse would be a very welcomed move for me, there are a number of reasons, which Greg already mentioned as well. For me the one key reason is the possibility to have multiple categories to have discussions and share information in a

Re: [foreman-dev] Discourse summary week 2 (ish)

On 15/11/17 13:58, Lukas Zapletal wrote: > I AM STRONGLY AGAINST *MIGRATING* OUR MAILING LISTS TO ANY KIND OF > FORUM. I have included your opinion in both summaries. As a long standing member of the community, your vote does carry some weight - but shouting doesn't get you an extra one, and

Re: [foreman-dev] Request to add Fedora 27 to Koji

We have 200GB spare space, one more Fedora could fit. Can we delete Fedoras 24 and 25? This is definitely the last time before we'd need to expand space again. I initiated mrepo dry run which turned into real run and koji is now out of service due to missing metadata, we are working on this. Will

[foreman-dev] Koji repo sync metadata problem

Hey, when I initiated mrepo -n (dry run) this morning to see how mrepo works on our koji in order to test if we are able to add Fedora 27 for Pulp, I learned that this "dry run" is actually a real run and mrepo initiated full resync of our content without metadata regeneration. This rendered our

Re: [foreman-dev] Re: [UX] Facets and Host UI - roadmap discussion.

Perhaps another (or additional) approach to consider is having different "views" of the objects. Consider hosts currently. Depending on the user's role for that moment, the information and flows needed will be vastly different. The first engineer may, for example, be the provisioning one. Perhaps

Re: [foreman-dev] Re: [UX] Facets and Host UI - roadmap discussion.

You're right, there are cases where it's better to separate facets and cases where it's better to combine them. While we can define what page belongs to which category I think more natural approach is simply say that we need to allow both. For me, provisioning a host is a combination of

Re: [foreman-dev] Re: [UX] Facets and Host UI - roadmap discussion.

Marek, you lead me to an interesting conclusion: I think we have to distinguish two things here - there are workflows (such as provisioning, config management, fact reporting) and there are information aspects. An information aspect is a set of properties that describe a host in different

Re: [foreman-dev] [RFC] Deprecate and move Github RFC repo content

+1 to moving them to the Redmine wiki. The RFC repo was a good experiment but handled badly (at least some of the blame for that is on me). At this point I don't think it's possible to rescue it. On 15/11/17 10:52, Sean O'Keeffe wrote: > Without wanting to hijack this thread... I think this is

Re: [foreman-dev] [RFC] Deprecate and move Github RFC repo content

Yea +1 from me too. I think the biggest problem was that merging them has no direct link to the issue or PRs that resolved a RFC, this meant the author or someone had to remember to go back, ping someone to merge which often didn't happen. Whereas with a mailing list its okay to leave a thread

Re: Re: [foreman-dev] Regular Foreman-core issue triage?

I do check Redmine issues everyday (http://projects.theforeman.org/projects/foreman/activity) If there are many, I restrict the search to just Foreman (with subprojects). Usually it doesn't take more than 30 minutes. I basically look for: - New issues: if they look critical or very easy I

Re: [foreman-dev] Regular Foreman-core issue triage?

On 15/11/17 07:42, Tomer Brisker wrote: > One concern though is the amount of time it would take We could time-limit it to one hour, and start with "New" issues each time, sorted by oldest first. That way anything we don't get to one week would be present the next week. That's still better than

[foreman-dev] [RFC] Deprecate and move Github RFC repo content

Hey, this is another proposal to deprecate Github RFC repo and move the content to our wiki. Reasons: A) There is zero merged proposals for the past year (Jan-Nov 2017): https://github.com/theforeman/rfcs/commits/master B) Activity is very low (comments in 3 PRs last winter, 3 PRs last summer,