Re: [foreman-dev] Merge permissions for Katello/katello

[Justin Sherrill]

Given its been a number of days with no -1's, I've now granted you access!

Congrats!

Justin

On Tue, Oct 31, 2017 at 9:37 PM, Eric D Helms 
wrote:

> +1
>
> On Oct 31, 2017 9:10 AM, "Andrew Kofink"  wrote:
>
>> +1
>>
>> On Tue, Oct 31, 2017 at 8:17 AM, Brad Buckingham 
>> wrote:
>>
>>> +1 from me as well!
>>>
>>> On Fri, Oct 27, 2017 at 9:19 AM, John Mitsch 
>>> wrote:
>>>
 +1 from me!

 John Mitsch
 Red Hat Engineering
 (860)-967-7285 <(860)%20967-7285>
 irc: jomitsch

 On Thu, Oct 26, 2017 at 4:00 PM, Jonathon Turel 
 wrote:

> Hey folks,
>
> The time has come (through some helpful suggestions) that I should
> make my request to have $subject bestowed upon me. If you'd like to see
> some of my contributions to Katello here are my merged PRs
> 
> and PRs I've otherwise participated in
> .
> Looking forward to contributing more as I continue to come up to speed.
> What do you all think?
>
> Thanks!
>
> Jonathon
>
> --
> You received this message because you are subscribed to the Google
> Groups "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

 --
 You received this message because you are subscribed to the Google
 Groups "foreman-dev" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to foreman-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "foreman-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to foreman-dev+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Andrew Kofink
>> akof...@redhat.com
>> IRC: akofink
>> Software Engineer
>> Red Hat Satellite
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Katello Packaging Migration to Foreman Packaging Plan Proposal

[Justin Sherrill]

On 10/20/2017 08:30 PM, Eric D Helms wrote:

All,

One of the items on the Roadmap I've sent out is centralizing 
packaging into a single repository. The last time I tried this I 
attempted to go whole hog migrating all things all at once. In order 
to make this more approachable, and to encourage reviews, I would like 
to follow the following plan in this rough order for nightlies only:


 1) Move comps to foreman-packaging and update mash scripts
 2) copy releasers and tito.props to foreman-packaging for katello 
repositories
 3) Move packages 1 by 1 to foreman-packaging starting leaving nightly 
RPMs (rubygem-katello, hammer_cli_katello, and katello-installer) for 
last. This will involve a PR to foreman-packaging and PR to 
katello-packaging adding to the former and removing from the latter.

 4) Update katello-packaging README to indicate deperecation


Sounds good to me!   What are the plans for the non-ruby packages, such 
as 'katello' and 'pulp-katello' ?  These have hard requirements on pulp 
(you can likely argue 'katello' should not), and likely would break any 
repoclosure without including our 'pulp' repo in the repoclosure.


-Justin




I am sending this plan along to gather feedback, find holes in the 
plan and to get approval/disapproval from the community in taking this 
step.


My plan would be to begin this migration towards the end of next week.

--
Eric D. Helms
Red Hat Engineering
--
You received this message because you are subscribed to the Google 
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to foreman-dev+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Found In Version Katello Redmine custom field

[Justin Sherrill]

I like this idea, and there seems to be a plugin already to do it: 
http://www.redmine.org/plugins/redmine_issue_templates



On 10/18/2017 02:55 PM, Tom McKay wrote:

Perhaps using a template for new issues. Here is an example from github:
https://github.com/openshift/origin/issues/new

[provide a description of the issue]

# Version
[provide output of the `openshift version` or `oc version` command]

# Steps To Reproduce
1. [step 1]
2. [step 2]

# Current Result

# Expected Result

# Additional Information
[try to run `$ oc adm diagnostics` (or `oadm diagnostics`) command if 
possible]
[if you are reporting issue related to builds, provide build logs with 
`BUILD_LOGLEVEL=5`]
[consider attaching output of the `$ oc get all -o json -n 
` command to the issue]

[visit https://docs.openshift.org/latest/welcome/index.html]


On Mon, Oct 16, 2017 at 1:47 PM, Ewoud Kohl van Wijngaarden 
> wrote:


https://projects.theforeman.org/projects/foreman/issues/new
 has
this, but I'm not sure we can rename the Release field since it's
part of the Redmine Backlogs plugin though my memory is fuzzy
here. I think someone with admin rights on Redmine can say more
about the practicalities but the idea makes a lot of sense to me.

On Mon, Oct 16, 2017 at 01:38:18PM -0400, John Mitsch wrote:

+1

If we do this, we should clarify that the current "version"
field is used
for releases by calling it "target version" or something similar.

John Mitsch
Red Hat Engineering
(860)-967-7285 
irc: jomitsch

On Mon, Oct 16, 2017 at 10:18 AM, Andrew Kofink
> wrote:

RFC:

Because Katello is a nested project under Foreman in
Redmine, we can only
see Foreman versions in the "version" field. It would be
great to have a
custom text box field "Found In Version" that bug
reporters can provide the
exact RPM they installed to see the issue.

Let me know if you would find this useful.


-- 
You received this message because you are subscribed to the Google

Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to foreman-dev+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout
.


--
You received this message because you are subscribed to the Google 
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to foreman-dev+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Katello UX nitpick - Sync Status

[Justin Sherrill]

On 10/06/2017 11:16 AM, Walden Raines wrote:

Hey,

As part of my campaign to reduce the number of menu items I would love 
to remove the sync status page entirely.


As far as I know the sync status page doesn't really provide any 
additional functionality over the products page with the exception of 
being able to select individual repositories from diverse products to 
sync (i.e. the products page bulk sync forces you to sync all of the 
repositories in each product).  I think we could add this to the 
products page pretty easily.


There is also a dashboard widget that shows sync status if you use the 
sync status page just to look at the status of your syncs.


So really what is the purpose of the sync status page?

I believe it was so you could get a better overview of what repositories 
were syncing.  I think the sync status dashboard widget is not currently 
well suited for that.


If we had a 'repositories' page where we could just list repos across 
the organization, that would likely be a better place to show this 
information (and allow the user to filter to see only what are currently 
syncing).


If we were going to just yank the sync status page, i think we would 
need to do some user interviews and confirm that the products page and 
dashboard widgets  fulfill their needs.


-Justin



Cheers,
Walden

On Fri, Oct 6, 2017 at 10:58 AM, Sean O'Keeffe > wrote:


“Sync Plans” -> “Planned Sync’s” ?

On Fri, 6 Oct 2017 at 15:56, Lukas Zapletal > wrote:

Hey,

I constantly keep mis-clicking on Sync Plans instead Sync
Status in Katello.

Any UX advice how to change that? I suggest either rename one
to be
more visible so you can easily target that with mouse or break
these
two guys into different main menu entries.

LZ

--
Later,
  Lukas @lzap Zapletal

--
You received this message because you are subscribed to the
Google Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to foreman-dev+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout
.

-- 
You received this message because you are subscribed to the Google

Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to foreman-dev+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout
.


--
You received this message because you are subscribed to the Google 
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to foreman-dev+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] request for write-access to katello-packaging

[Justin Sherrill]

You've now got access Evgeni!  Congrats!

-Justin


On 10/05/2017 02:37 AM, Evgeni Golov wrote:

Nope, not yet.

Can one of the masters of the universe please do the needful? :)

Cheers

On Thu, Oct 5, 2017 at 1:01 AM, Ewoud Kohl van Wijngaarden
 wrote:

Was this ever implemented?


On Fri, Sep 22, 2017 at 08:40:20PM -0400, Eric D Helms wrote:

+1 from me as well

On Fri, Sep 22, 2017 at 3:57 AM, Lukas Zapletal  wrote:


+1 thanks for all the help there.

On Thu, Sep 21, 2017 at 6:47 PM, John Mitsch  wrote:

+1 from me, you've been a great help at reviewing the katello scripts!

-John

John Mitsch
Red Hat Engineering
(860)-967-7285
irc: jomitsch

On Thu, Sep 21, 2017 at 12:00 PM, Evgeni Golov 

wrote:

Ohai,

I would like to request write access to katello-packaging.

I have 14 merged PRs [1] resulting in 14 commits [2].
If I count it right, I also somehow reviewed 19 PRs [3].

TIA
Evgeni

[1]
https://github.com/Katello/katello-packaging/pulls?page=

1=is%3Apr+author%3Aevgeni=%E2%9C%93

[2] https://github.com/Katello/katello-packaging/commits?author=evgeni
[3]
https://github.com/Katello/katello-packaging/pulls?utf8=%

E2%9C%93=involves%3Aevgeni%20is%3Apr%20


--
Beste Grüße/Kind regards,

Evgeni Golov
Software Engineer




Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Eric Shander

--
You received this message because you are subscribed to the Google

Groups

"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send

an

email to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google
Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Later,
   Lukas @lzap Zapletal

--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.




--
Eric D. Helms
Red Hat Engineering

--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.





--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] [infra] Packaging reorganization

[Justin Sherrill]

On 09/02/2017 03:00 PM, Eric D Helms wrote:



On Sep 2, 2017 10:22 AM, "Timo Goebel" > wrote:


I am wondering if we should name the katello-client repository
either foreman-client or just client. I can think of more plugins
that need a client package.
Timo


I was not going to suggest this yet, but since you brought it up and 
know of other client tools I think this would be a great addition and 
coming together for Foreman and Katello.  For the yum repositories 
(maybe this also translates for Debian? sorry I am not as familiar 
with them) I'd then suggest changing our structure to the following:
It might be even more out of scope, but i could see value in having 
hammer and all the hammer plugins in a client repo as well.


-Justin



http://yum.theforeman.org
  -- nightly/
 -- foreman/
   -- el7/
 -- plugins/
-- el7/
 -- client/
-- el7/
   -- el6/
   -- el5/
   -- f25/
   -- f26/
 -- katello/
   -- el7/
 -- pulp/
-- el7/
 -- candlepin/
-- el7/
  -- 1.15
  -- 1.14

Another question, though possibly overkill would be if its worth 
separating out the smart proxy (and plugins) to their own repository 
to differentiate them more clearly (and potentially support more 
distros?).



On 2. Sep 2017, at 01:48, Eric D Helms > wrote:


Howdy,

As a lead-in to being working towards migrating Katello's
packages to the foreman-packaging repository, I'd like to propose
a slight re-organization of the repository. As well, to seek any
other ideas or problems any might see with the proposal.

Currently, the packaging repository is a flat structure with all
packages being represented by a directory containing sources and
a spec file. When looking at it, I find it hard to think about
them in an organized manner given we separate by repository into
foreman and foreman-plugins (and eventually katello
repositories). Thus, my proposal is to let the packaging
repository reflect the repository organization by moving things
into the following directories:

foreman-packaging
   - foreman
   - plugins
   - katello
   - katello-client


Thoughts?

-- 
Eric D. Helms

Red Hat Engineering
-- 
You received this message because you are subscribed to the

Google Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to foreman-dev+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout
.
-- 
You received this message because you are subscribed to the Google

Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to foreman-dev+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout
.


--
You received this message because you are subscribed to the Google 
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to foreman-dev+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Katello with debian repositories

[Justin Sherrill]

This is awesome!

Would you be willing to open Pull requests against the main projects for 
easier review?


-Justin


On 07/18/2017 04:43 AM, Matthias Dellweg wrote:

Hi all,
here at ATIX-AG (Munich), we started to implement the necessary steps, to 
integrate Debian/Ubuntu repositories in Katello's content management system.
Since we reached a point of minimal functionality, we thought, we could share 
our progress with the community.
Since a handfull of software stacks are involved in the problem, modifications 
to no less than three projects were necessary.

With the following combinations of the branches we can sync and publish the 
stable release of a debian repository:
* https://github.com/ATIX-AG/katello/tree/feature/add_deb_repository_type
* https://github.com/ATIX-AG/runcible/tree/feature/add_deb_type
* https://github.com/ATIX-AG/pulp_deb/tree/feature/sync_release_structure

Since we added some debian archive specific filters for releases, components 
and architectures in pulp_deb,
the next step will be to implement the corresponding configuration options in 
the Katello UI.

We would be happy if anyone were willing to test this and comment on it.
Matthias and the ATIX crew

--
ATIX - The Linux & Open Source Company
http://www.atix.de



--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Proposal: Update Pulp to 2.13.2 in Katello 3.4

[Justin Sherrill]

+1, there is a nasty bug that prevents the syncing of some yum repos 
which sadly isn't being backported.  That seems severe enough to warrant 
pulling it in IMHO.


Justin


On 06/28/2017 08:36 PM, Eric D Helms wrote:

Devs,

I am proposing to update Katello 3.4 to Pulp 2.13.2 in order to pull 
in a number of fixes that are affecting users. These updates would 
move us to the most recent stable release of Pulp and prevent users 
from having to do work arounds to fix repositories that occasionally 
break.


One question is around changes to how Docker Schema V2 are handled and 
are addressed by the open PR [1]. The inclination is to include that 
change along with the update.


If anyone has any objects, questions or approval please speak up. This 
would most likely be done as a stand-alone release update to limit the 
amount of change.


[1] https://github.com/Katello/katello/pull/6775

--
Eric D. Helms
Red Hat Engineering
--
You received this message because you are subscribed to the Google 
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to foreman-dev+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[foreman-dev] renaming katello-agent to katello-host-tools

[Justin Sherrill]

As part of this PR: 
https://github.com/Katello/katello-packaging/pull/476  a discussion came 
up of renaming the base package to 'katello-host-tools', while moving 
all of the gofer-specific bits into katello-agent.


The benefit of this is that a user can install katello-agent and get all 
the tools including the gofer bits, or can install katello-host-tools 
and just get utilities and commands to support errata/package 
applicability and tracer reporting.


This naturally leads to renaming of the git repo from katello-agent to 
katello-host-tools.


Please speak up if you have questions or concerns!

-Justin

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Re: [RFC] HTTP proxy for requests

[Justin Sherrill]

On 05/17/2017 07:57 AM, Tom McKay wrote:
After reading the RFC I think that more robust and adaptable solution 
would be better. A single env var is not going to cover the needs of 
all the scenarios. A simple example may be accessing both 
registry.access.redhat.com  
(through proxy) and myopenshift:5000 (no proxy).


As @jlsherrill noted on the PR, the temporary solution for the 
foreman-docker plugin is alright for the moment.
I'd like to echo what tom said, we've had many users that want to access 
content externally through a proxy and internally (where the proxy is 
not controlled by them and does not properly proxy internal requests).  
Its happened enough for me to say that a simple solution is not good 
enough long term.




On Wed, May 17, 2017 at 3:08 AM, Sebastian Gräßl 
> wrote:


There was some feedback regarding this on the PR[1] mentioned in
the beginning.
There is already a RFC[2] regarding this and a plugin[3] to
implement the solution proposed in the RFC.

The solution proposed by jlsherrill allows to add multiple
HTTP-proxies in Foreman and use these in plugins and allow to
configure what HTTP-proxy should be used for what requests.
So far the plugin only adds the ability to add HTTP proxies and
misses a essential part, which is applying the HTTP proxies to
requests.

While looking at how other applications handle this and also
considering typical HTTP proxy configurations, it feels that such
a solution would make it rather complex in practice to apply.
Configuring rules for requests or just ensuring the proper request
is using the right HTTP proxy is better configurable in the HTTP
proxy itself.

I believe a very bold simple solution would be the better, which
in my opinion would be to ensure all parts respect a HTTP proxy
configuration and have good documentation around it to advice on
how to configure the HTTP proxy correctly. Taken other
applications in the same area the HTTP_PROXY environment variable
seems to be the common standard to use.

Please, I would love to hear more feedback on this and what are
common HTTP proxy setups.

[1] https://github.com/theforeman/foreman-docker/pull/189

[2] https://github.com/theforeman/rfcs/pull/18

[3] https://github.com/jlsherrill/foreman_http_proxies


On Thursday, April 20, 2017 at 1:07:33 PM UTC+2, Sebastian Gräßl
wrote:

Hej,

at the moment there is a PR[1] open on foreman-docker to set a
HTTP proxy for requests to registries.
The PR allows to set a HTTP proxy on the HTTP client, in this
case deep down Excon, only for registry requests.

A HTTP proxy won't be set on requests if a `HTTP_PROXY`
environment variable is available, since it is an unlikely
setup to have registry request routed over a different proxy
than other requests. However setting it via the environment
variable will allow requests to succeed to resources available
by the HTTP proxy, but will fail for those inside and possible
blocked.

The `HTTP_PROXY` environment variable seems to be a standard,
and therefore Excon is built to use it when available.
Excon is used by docker-api as well as fog, it might be used
by other components and there might be other parts that use
another HTTP client like RestClient, which also respects the
variable.

This means at the moment with that environment variable set
some requests would already rely on it.
In any case this should be in mentioned in the manual to be
aware of, also because some operating systems set this globally.

The question is should we make an afford to ensure deployment
behind a HTTP proxy on a system with HTTP blocked works
without issues and provide a way to configure it properly?

I've tested Foreman with HTTP blocked and `HTTP_PROXY` set,
but in a very basic setup, with the only external requests
being to Docker registries outside and squid configured to
just pass requests through regardless there to.

It didn't show any apparent issue, but there are for sure
issues with a more robust configured HTTP proxy.
This raises another question: How common is a setup where
external resources requiring HTTP are used with Foreman behind
a HTTP proxy?

Comments?

All the best,
Sebastian

[1] https://github.com/theforeman/foreman-docker/pull/189


-- 
You received this message because you are 

Re: [foreman-dev] qdrouterd communication

[Justin Sherrill]

On 04/28/2017 09:10 AM, Unix SA wrote:

Hello,

I would like to understand qdrouterd communication between katello master and 
katello capsule

1) what will happen if connection is broken while some sync going on ?
Capsule syncs are no longer handled via qdrouterd (since katello 3.0).  
So essentially no issue would occur if you were doing a capsule sync and 
the qdrouterd communication died.



2) if my capsule and master are connected using WAN does it have any RTT impact 
on communication.

I'm not 100% sure what you are asking here.  Could you explain a bit more?


3) I assume if qdrouterd is broken between master and capsule, I will not be 
able to use hammer to install/remove/update erratas on client machines 
connected to capsule ??

Correct, if you use REX it will still work fine though.



Does anyone has any user stories, diagrams on how wood, gofer, qdrouterd, 
celery are communication and any impact if those connections are disturbed or 
broken.


This is kinda old, but should still be accurate may help: 
https://raw.githubusercontent.com/ehelms/connection_diagram/master/katello.png

Doesn't really cover broken connections.


Thanks in advance.
DJ


Hope that helps.
-Justin

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Retire the RFC repo?

[Justin Sherrill]

On 03/13/2017 07:10 AM, Tomas Strachota wrote:

For me the biggest advantage of RFC repo over design discussions on
mailing list is that when you come back to it later, you immediately
see the latest state of the proposal without any need for reading
through the whole email thread. At the same time, when you what to see
the whole discussion you can display the outdated comments and older
commits. Sending/receiving comments in form of code reviews is quite
natural for me, but that's matter of personal preference.

In my opinion both described issues (RFCs not being closed and design
decisions without RFCs) aren't connected with github reviews but with
the process around. Moving back to mailing lists won't help us with
that. Therefore I'd keep RFC repo and rather work on defining how we
decide on accepting/rejecting RFCs and who's responsible for keeping
an eye on that.
I also like the RFC repo.  As someone that opened an RFC but never 
'closed' it, it was mostly due to time, but I still plan to revisit it 
in the future. I'm not sure that its a 'bad' thing to have open RFCs 
(although we could auto close them after some months of inactivity).  
Similarly on the mailing list you'd just end up with discussions that 
never go anywhere.


I'd be interested in other proposals, but like Tomas said, I don't think 
moving to the mailing list would solve many of the issues.


-Justin




T.

On Sun, Mar 12, 2017 at 9:52 AM, Tomer Brisker  wrote:

Hello,

About a year ago, we decided to try using a new system for discussing design
decisions prior to making changes, by creating a repo for RFCs [1]. Part of
the problem was that when discussing on the mailing list, discussions tended
to die out without a resolution, and eventually whoever wrote the code made
the decision (or not).
Since then, there have been about 30 proposals made in the repository. 22 of
them are still open, most with no activity for months.
So I feel fairly safe to say that this change has not led to the wanted
result of getting decisions made faster or with more discussion. A
significant part of the proposals have less then 10 comments, in many cases
all from just one or two respondents. Eventually proposals are still decided
on only when someone goes ahead, writes the code and gets it merged.
This has also led to some discussions taking place without all of the
developers even knowing about them, as it would seem most don't follow that
repo regularly, leading to repeated discussions when a PR is created.
In addition, some design decisions are still being made without going
through the RFC process, either by mailing list discussions or by people
just creating PRs without any prior discussion.

I'm not sure what we can do to increase peoples' involvement in these
discussions, nor what would be a better way of making design decisions, but
let's try to figure it out since this attempt has not worked out as expected
in my opinion.

[1] original discussion -
https://groups.google.com/forum/#!msg/foreman-dev/P9uRYV5K1Dc/xKMnzOOqDgAJ

--
Have a nice day,
Tomer Brisker
Red Hat Engineering

--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[foreman-dev] Hosting katello repos on yum.theforeman.org

[Justin Sherrill]

Within https://github.com/theforeman/foreman-packaging/pull/1541 it was 
expressed that yum.theforeman.org does not have enough resources to hold 
the katello repos as they are today (but that this PR was not the right 
place to discuss it).  This mailing list does seem like the current place.


What are the resource limitations that prevent this from happening?  The 
details in the PR are quite limited.


For size, here are the last few releases, binary RPMS:

52M3.3
106M3.2
105M3.1

Source RPMS:

298M   3.1
142M  3.2
79M   3.3

Are there any other reasons to not host the repositories there?

Thanks,

-Justin

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[foreman-dev] candlepin 2.0 merged

[Justin Sherrill]

Hi All,

Candlepin 2.0 has been merged to katello master and available in 
nightly.  Sadly after we merged we found an issue that prevents 
upgrading with all your data in the devel environment.  Until this is 
fixed you'll have to do a full reset:


1.  systemctl stop tomcat

2. yum update 
http://koji.katello.org/packages/candlepin/2.0.24/1.el7/noarch/candlepin-2.0.24-1.el7.noarch.rpm 
http://koji.katello.org/packages/candlepin/2.0.24/1.el7/noarch/candlepin-selinux-2.0.24-1.el7.noarch.rpm


3.  systemctl start tomcat

4. rake katello:reset   (in your foreman checkout)

If you don't want to do a full reset you'll need to wait until a newer 
candlepin is available.  I'll send out instructions when a fixed build 
is available.  You can stay at commit 
3256117f51f558aa9fd531259cad01200e2576cf and stay on candlepin 0.9.54 
for now.


If you see any issues please reach out on #theforeman-dev, reply to this 
email, or open an issue.


Thanks,

-Justin

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[foreman-dev] 1.14.0 inclusion request

[Justin Sherrill]

The following issue was just moved to 1.14.1:

http://projects.theforeman.org/issues/17894

and I'd like to request for it to be moved back to 1.14.0.  Its
currently preventing katello from being built for 1.14.0 and the only
other workaround would be to partially revert a commit and hope that the
problem is still not present.  There's a short explanation here:
http://projects.theforeman.org/issues/17894#note-5

Thanks,

-Justin

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[foreman-dev] Katello 3.3 Branching in 1 week

[Justin Sherrill]

Will branch towards the end of the day December 19th

-Justin

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Use mention-bot to increase reviews?

[Justin Sherrill]

On 12/06/2016 01:11 PM, Marek Hulán wrote:
> On úterý 6. prosince 2016 12:37:23 CET Daniel Lobato Garcia wrote:
>> On 12/06, Sean O'Keeffe wrote:
>>> Hows this going for everybody? I personally quite like it
>> Personally it's just noise for me, but if it works for some people it
>> causes no harm
> +1, I'm failing to get time for reviews and this does not help me, but I'm ok 
> with it pinging me if it helps others.

Not super useful for me either and I don't feel like its helping draw
more people in to review on katello/katello.  But it doesn't bother if
others enjoy it.

>
> --
> Marek
>
>>> On Fri, Oct 28, 2016 at 12:36 PM, Greg Sutcliffe
>>> 
>>>
>>> wrote:
 On 27 October 2016 at 14:55, Ohad Levy  wrote:
> On Mon, Oct 17, 2016 at 4:02 PM, Greg Sutcliffe
> 
>> wrote:
>> On 13 October 2016 at 13:28, Eric D Helms  
> wrote:
>>> This has been turned on for the Katello repo, if devs find it needs
>>> tweaking there is a configuration file that can be added (
>>> https://github.com/facebook/mention-bot#configuration).
>> How's that going for you?
>>
>> Dominic or Ohad, could you turn it on for the other repos mentioned,
>> as
>> a trial? Thanks!
> Done.
 Thanks. It's already pinged me for a review, so that was cool.

 Lets see how it goes for a few weeks and we can see if we want to expand
 to other repos. Feedback welcome as we go :)

 Greg

 --
 You received this message because you are subscribed to the Google
 Groups
 "foreman-dev" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an
 email to foreman-dev+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "foreman-dev" group. To unsubscribe from this group and stop receiving
>>> emails from it, send an email to
>>> foreman-dev+unsubscr...@googlegroups.com. For more options, visit
>>> https://groups.google.com/d/optout.
>> --
>> Daniel Lobato Garcia
>>
>> @dLobatog
>> blog.daniellobato.me
>> daniellobato.me
>>
>> GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
>> Keybase: https://keybase.io/elobato
>


-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Automating upload of DRPMs

[Justin Sherrill]

On 10/24/2016 10:19 AM, Og Maciel wrote:
> All,
>
> The QE Team is considering automating the upload of DRPM packages via
> API/CLI/UI and we would like to ask you for some feedback. The test
> case is listed here: https://github.com/SatelliteQE/robottelo/issues/3853
>
> Since this is an upload (and not a sync) task, it seems that DRPM
> packages behave differently when being uploaded. For example, if you
> create a single repository and manually upload a DRPM package, I'd
> expect to see it show up in the filesystem (and not the UI). However,
> once you import the DRPM you actually see a RPM listed in the
> filesystem. If you synchronize a repository that has both RPMs and
> DRPMs, you see both in the filesystem.
>
> We're a bit confused as to how a DRPM becomes a RPM in the former use
> case...
>
> Looking forward to your feedback,
>
> Og
> -- 
> You received this message because you are subscribed to the Google
> Groups "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to foreman-dev+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

Katello doesn't support uploading DRPMs.  I think what you are seeing
with regard to them 'becoming' rpms is just a side effect of the fact
that drpms look a lot like regular rpms.  They have an rpm header just
like a normal rpm. 
Since katello only supports uploading rpms to yum repos and what you are
uploading *looks* like an rpm, it is uploaded as an rpm and pulp imports
it as such.

We would need an RFE to support such a feature.

-Justin

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Re: RFC for foreman_api_v3

[Justin Sherrill]

On 08/28/2016 01:49 AM, Joseph Magen wrote:


On Fri, Aug 26, 2016 at 10:47 AM, Dominic Cleal > wrote:


On 26/08/16 06:58, Joseph Magen wrote:
> I created a RFC for a plugin called foreman_api_v3
>
>
and
> the initial repo atgithub.com/isratrade/foreman_api_v3

> >. If the community
accepts,
> I am happy to move this repo to theforeman/foreman_api_v3
>
> I choose to make this a plugin rather than a PR so it is
optional for
> users and doesn't affect the core code.

Please consider calling it something else that won't cause
confusion for
users with Foreman's own API versioning.


I can rename the plugin to *foreman_jsonapi* and change to version to 
v21 (meaning v2.1 since it inherits from v2), so it would look like this


GET api/api/v21/hosts


what happens when we get to version 21 of the api which in my 
calculations will occur around 2325?  :)




What do you think?


--
Dominic Cleal
domi...@cleal.org 



On Fri, Aug 26, 2016 at 11:36 PM, Tomas Strachota 
> wrote:


On 08/26/2016 07:58 AM, Joseph Magen wrote:

Hi all,

I created a RFC for a plugin called foreman_api_v3
>
and
the initial repo at github.com/isratrade/foreman_api_v3

>. If the
community accepts,
I am happy to move this repo to theforeman/foreman_api_v3

I choose to make this a plugin rather than a PR so it is
optional for
users and doesn't affect the core code. The initial repo only
includes
the GET `index` and `show` actions. The PUT/PATCH/POST/DELETE
actions
need to be added. Also, there are currently no functional
tests in the
repo, so a lot more work needs to be done.

Note that I inherited V2 so that V3 controllers look like this

module Api
  module V3
class DomainsController < V2::DomainsController

but the response is changed.

  def index
super
render json: @domains,
   fields: @fields_hash,
   include: @include_array,
   each_serializer: DomainSerializer
  end

For some background, the Foreman API v2 is more than 3 years
old. When I
implemented v2, I used conventions that I thought were good at
the time.
The katello had some slightly different conventions, and we
weren't
always in sync. This created some challenges for Satellite6 as
a single
RH product.

The goal of JSON API is to create a standardization that is
*Flexible,
Consistent, and Fast *-- we can all agree with these goals.


Thanks for sending that, Joseph. Jsonapi.org is nice specification
and I like how it structures the data. The ability to include
additional resources into the response is very handy and making
the katello and foreman api consistent would be good too. But that
alone wouldn't be enough to make switch to jsonapi. In my opinion
main painpoints of the current api v2 are elsewhere. Firstly I
miss adding associated resources without having to send all what's
currently included. Second main issue is inconsistent error
responses (we've improved with that but it's still not ideal).
Jsonapi.org has cures for both [1] [2], so I'm not against at all
that but we mustn't stop just at changing the output format.


Please explain the other pain points in v2 besides [1] [2]

Speaking about the format change, since getting consistent with
katello is one of motivations for the change, I'd like to hear
from somebody with expertise in that field how difficult would be
to bend the UI code to use the new format. 


Just to make sure we actually won't unintentionally put more
obstacles in katello's way.


I assume you mean using RABL to generate the new output format when 
keeping the same v2 controllers. IMHO, this would be a bigger headache 
for both Koreman and Katello. This would still lead to v3 since there 
are breaking changes. Maybe I don't understand your question fully.


If we decide that jsonapi is the way to go for v3 I think 

Re: [foreman-dev] bringing pulp-2.10 into katello

[Justin Sherrill]

On 08/24/2016 05:48 PM, Tom McKay wrote:



On Wed, Aug 24, 2016 at 5:36 PM, Chris Duryee > wrote:




On 08/24/2016 05:33 PM, Tom McKay wrote:
> Katello and foreman are nearing dev freeze in early September
but there are
> a few features centered around Atomic Host and Atomic Registry
that will
> need changes introduced in pulp-2.10. While I understand
pulp-2.10 is
> currently still in beta, I was hoping we could bring it into
katello now
> ahead of dev freeze so the dependent integration could be completed.
>
> If we did bring in pulp-2.10, it would have to be with the
understanding
> that breakages on both sides would need to be fixed prior to katello
> releasing. I know this is usually how things go anyways but I
just wanted
> to state it up front.
>
> Also, are there resources to do this work? If I understand things
> correctly, it's not just as simple as updating a repo file to
point to
> pulp-2.10, but that changes to runcible would also need to be
made? Is this
> something that could be done ASAP? Sooner means more time to
shake out
> issues.

2.10 should have additive-only changes from 2.9, I don't think
runcible
would change unless it was to support something new in 2.10.


We would be passing username/password for docker registries w/ 
authentication. Not sure if there are other changes too, @partha?


Generally when pulling in a new pulp release, we only initially 
introduce changes required to maintain existing functionality.  New 
functionality is added after that is done in one or more PRs.





>
> Thoughts?
>

--
You received this message because you are subscribed to the Google
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to foreman-dev+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout
.


--
You received this message because you are subscribed to the Google 
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to foreman-dev+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.



--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] qpid-cpp-client-devel required on slaves?

[Justin Sherrill]

On 08/12/2016 07:48 AM, Dominic Cleal wrote:

On 12/08/16 12:28, Eric D Helms wrote:

Should be good to remove.

Thanks, I've removed the Yum repo and the package will be left wherever
it's currently installed.

I believe this is actually required as now seen by the new katello test 
failures:


*00:03:32.077* An error occurred while installing qpid_messaging (0.34.1), and 
Bundler cannot
*00:03:32.077* continue.
*00:03:32.077* Make sure that `gem install qpid_messaging -v '0.34.1'` succeeds 
before
*00:03:32.077* bundling.
*00:03:32.132* + exit 1

The EL6 source is now in the copr qpid repo 
(https://copr.fedorainfracloud.org/coprs/g/qpid/qpid/)

-Justin

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] syncing content through a capsule

[Justin Sherrill]

On 08/05/2016 11:04 AM, Tom McKay wrote:

Justin & Brad,
As part of the docker registry work I have the following setup:


+---+ +---+   ++
| https://katello | <---> | https://capsule  | <---> | https://registry |
+---+   +---+ ++

From a system that can see the capsule, I would like to run:

% hammer repository synchronize \
  --server https://capsule \
  --name docker-repository \
  --source-url https://registry

This would initiate a sync from registry through the capsule to katello.

In addition, I'd like sync plans on the repo to know that the 
source-url is through the capsule.


As a user, I want to sync content to katello that is visible only to 
the capsule.


How do I accomplish this?


At first glance I can think of two options:

1)  Setup an HTTP proxy on the capsule that only the katello/foreman 
server has access to.  Configure the repo on the katello server to use 
that for an http proxy


Using this method sync plans would work as is.


2) Talk to the capsule and create a repository that syncs the registry 
locally to the capsule, then have the satellite sync that repo from the 
capsule.


Sync plans would NOT work with 2) as they exist today.  You'd need some 
sort of orchestrated action on both the capsule and the katello server.






--
You received this message because you are subscribed to the Google 
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to foreman-dev+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.



--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Deprecate EL6?

[Justin Sherrill]

On 07/29/2016 05:29 AM, Michael Moll wrote:
> Hi,
> 
> On Fri, Jul 29, 2016 at 08:35:36AM +0100, Dmitri Dolguikh wrote:
>> I have at least one feature planned for smart-proxy that requires
>> dependencies not available on 1.8.7 (at all). At this point converting
>> the smart-proxy to use SCL isn’t worth it, and it would be great not
>> to have an additional 3-months wait.
> 
> That would be exactly my point also, as I said in my mail for the
> original discussion back then: If the support for EL6 is prolonged, the
> proxy (and maybe even the installer) should really get into SCL, which
> is definitely too much work for just 3 or 6 months. If EL6 support is
> really needed, somebody[tm] needs to do that work, but then we could
> also extend the lifespan not only some months, but probably some years.
> 
> As I don't use RH based distro at the moment, I can't really say how
> widespread the use of EL6 for Foreman really is...

It seems surprisingly prevalent in katello users (maybe 30% from my
instances helping users).

Since there wasn't a clear statement of when the deprecation was going
to occur (the original email thread was left without a conclusion), and
the release notes for 1.11 did not say which future release would remove
el6 support (until it was recently updated) I would vote to keep it for
1.13 and make it very clear to both users and devs.   It would allow us
(and users on el6) to more thoroughly test our backup and restore
procedures across all plugins.



> 
> Regards
> 

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] [Katello] weekly issue triage meetings?

[Justin Sherrill]

On 06/03/2016 10:47 AM, Justin Sherrill wrote:
> On 06/01/2016 07:19 PM, Justin Sherrill wrote:
>> Was thinking lately that the issue triaging process is currently:
>>
>> 1.  User files issue
>> 2.  Eric triages the issue to either a release or a backlog
>> 3.  Release nanny for a particular release fixes bug, asks someone else
>> to fix the bug or is just sits there
>>
>> In the case of 'it just sitting there' a lot of user issues come in that
>> are mostly ignored due to the release nanny's other responsibilities.
>>
>> I would like to get more eyes on the issues and spread the effort to not
>> just Eric and the release nanny for a given release.
>>
>> Any thoughts on a weekly triage meeting? The goals would be:
>>
>> * assign issues to a given release or the 'backlog'
>> * assign issues to be fixed to developers (for current releases)
>> * Assign user reported issues to be determined if they are actually bugs
>> or environment issues.
>>
>> This would spread the fixing of bugs to other people and hopefully get
>> user issues solved more quickly.
>>
>> Initially I would likely just have an open invite to anyone that wants
>> to come and may pare it down to some sort of rotation depending on the
>> number of people that join.  We would probably limit it to 1 hour per week.
>>
>> Thoughts?
>>
>> -Justin
>>
> 
> There seems to have been some interest, so I've gone ahead and setup a
> time on Wednesdays at 5:00 pm UTC (1:00 pm EDT).
> 
> We're going to try bluejeans for our triages:
> https://bluejeans.com/942337177/
> 
> I will add it to the foreman community calendar as well.
> 
> -Justin
> 

Note due to some scheduling oddities, i had to move this weeks meeting
to Thursday.  I kept it at the same time for simplicity.

Normal time & day will resume next week.

-Justin

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.