Re: [foreman-dev] 2018 community survey

[Sean O'Keeffe]

What did we use the data for last year?

I ask because be able to say "last year we made X change due to Y feedback"
might drive more submissions this year

On Thu, Nov 30, 2017 at 3:11 PM, Greg Sutcliffe 
wrote:

> It's time (again, :P) to start drafting the community survey for while
> we're in Belgium next year :)
>
> I'm short on time today, so here's a link to last year's survey. Much of
> the generic questions will remain the same, they seem to work. What
> other burning issues would people like data on? What needs more detail?
> What can be dropped?
>
> https://theforeman.org/2017/03/2017-foreman-survey-analysis.html
>
> I'll get to work stripping out the outdated questions and incorporating
> new ones sometime next week.
>
> 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.

Re: [foreman-dev] Proposal: Foreman 1.18 = 2.0

[Sean O'Keeffe]

+1 to the idea. Although 1.17 is a good candidate in terms of features,
lets give ourselves time to decided what should be deprecated. Anytime
after 1.17 is good with me!

On Wed, Nov 29, 2017 at 10:10 AM, Greg Sutcliffe 
wrote:

> Given 1.17 will have:
>
> * vertical nav
> * rails 5.X
>
> I think this is a good candidate, if we're ever going to do it. It's
> also a good chance to put the woes of 1.16 behind us :)
>
> 1.17 hasn't been branched, but it's soon. If we're going to do this,
> we'll need to decide what should be deprecated.
>
> 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.

Re: [foreman-dev] Community-developed Ansible modules for Foreman API objects

[Sean O'Keeffe]

Here's a radical thought, use Hammer...

Ansible modules do not have to be written in Python[2], although Ansible
does provide some nice shortcuts with Python, all that is really required
is JSON output... Some Ruby examples [1]
A couple of things to note if we were to entertain going down this route;
- How does DOCUMENTATION work for non-python modules? I played around for a
bit, but couldn't get ansible-doc to work..
- If the goal is to get them into Ansible core, will they accept Ruby
modules? Looking at Ansible core I think all the modules are python...


[1] https://github.com/ansible/ansible-for-rubyists
[2]
http://ansible-docs.readthedocs.io/zh/stable-2.0/rst/developing_modules.html

On Fri, Oct 27, 2017 at 8:11 PM, Michael Hofer <
michael.ho...@adfinis-sygroup.ch> wrote:

> On Wed, 25 Oct 2017 08:09:10 -0400
> Andrew Kofink  wrote:
> [...]
> > If given a choice, I would vote for Nailgun, a more mature project with
> > more contributors and guaranteed future contribution from Satellite QA.
> > There is a bit of a gap between foreman-ansible-modules and Nailgun,
> given
> > that it is not purpose built; for this, we do include
> > ansible_nailgun_cement.py [1].
> >
> > I appreciate the support and interest from the community.
>
> So far we've only used python-foreman in a few different projects, one to
> configure Foreman based on a YAML file. We use python-foreman to resolve
> the
> IDs first thus the actual names of the templates, etc. can be used. Working
> with the lib is nice but it still needs some glue because the API is
> inconsistent and doing a lookup for the ID is not aligned for all
> resources.
>
> I have no experience with nailgun but from my point of view dependencies
> are
> not that big of a deal when provided as proper packages. E.g. to use the
> Ansible mysql_db module you require python-mysqldb.
>
> I'd love to switch to an upstream Ansible module to configure Foreman and
> improve our existing playbooks.
>
> Thanks for all the hard work so far!
>
> Kind regards
>
> Michael
>
> --
> 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] [RFC] Deprecate and move Github RFC repo content

[Sean O'Keeffe]

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
untouched that doesn't necessarily require any "closing" step.

Without wanting to hijack this thread... I think this is actually one of
the areas Discourse can benefit us, generally as a community I think were
not very good at making a decision after a discussion. I think some of the
features it seems to provide (voting system) could help with that.

On Wed, Nov 15, 2017 at 10:08 AM, Marek Hulán  wrote:

> Since you volunteered to clean up, definitely a +1 from me :-)
>
> I agree that discussion should happen outside of the RFC itself as the
> discussion in the PR was usually hard to follow. It was not clear if
> comments
> are still valid or not. Mail list seems to have good presence of
> developers so
> I expect the discussion to happen there. I don't really care which wiki we
> use
> for writing summaries of this discussion but redmine feels a bit more
> natural
> to me.
>
> --
> Marek
>
> On středa 15. listopadu 2017 10:14:49 CET Lukas Zapletal wrote:
> > 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, 1 PR last month):
> > https://github.com/theforeman/rfcs/pulls?q=is%3Apr+is%
> 3Aopen+sort%3Aupdated-> desc
> >
> > C) There is only one published RFC on the front page (by the way I am
> > the author). I see some randomly numbered files in text/ folder but
> > this does not look like a friendly space to newcomers or even
> > experienced guys. We failed following processes described on the front
> > page obviously and it's no surprise - people in need of writing a
> > proposal need to focus on the most important stuff.
> >
> > D) Developers naturally create [RFC] threads on our -dev list, some
> > random subjects:
> > * Make foreman STI to work even when an inherited class is not found
> > * Proxies with multiple interfaces
> > * Found In Version Katello Redmine custom field
> > * Foreman with Puppet in a wildcard domain leads to nodes mistaken
> identity
> > * Templates rendering only through Proxies
> > ... and others I am gonna stop here. These are e-mail from core devs
> > and also our community.
> >
> > E) It's been already proposed on list by Tomer ("Retire the RFC
> > repo"). Some people expressed intentions to use it (Justin, Eric, John
> > and Perry) but I haven't seen much activity (see above). One of the
> > reasons was time, but these days we should be pushing hard on
> > proposals for the next generation of Foreman versions and I don't see
> > this. Greg agreed this needs some more work around visibility and
> > process improvement, but I don't see much improvements.
> >
> > F) Content is not visible, most of us don't use it and WIP RFCs are
> > quite unreadable. I want to read proposal as a completed document and
> > then I want to send a consistent opinion about it.
> >
> > PROPOSAL
> >
> > Let's close the RFC repo for new PRs, add a note that contents has
> > been moved. I will then move all finished RFCs to our wiki page. We
> > already have that for years, it's named Features:
> >
> > http://projects.theforeman.org/projects/foreman/wiki/Features
> >
> > There is a template
> >
> > http://projects.theforeman.org/projects/foreman/wiki/
> Sprint_Feature_Template
> >
> > And couple of proposals already:
> >
> > http://projects.theforeman.org/projects/foreman/wiki/Pagelets
> > http://projects.theforeman.org/projects/foreman/wiki/
> Discovered_host_redesig
> > n
> > http://projects.theforeman.org/projects/foreman/wiki/
> Remote_Execution_Desig
> > n http://projects.theforeman.org/projects/foreman/wiki/
> CentralizedLogging
> > http://projects.theforeman.org/projects/foreman/wiki/PXE_Booting_UEFI (I
> > moved this one, I take this back)
> >
> > The wiki pages are just a place to put content on, a opt-in way. Most
> > of us will likely prefer e-mail list for smaller proposals and I
> > encourage everybody to continue to do so. This is just a complementary
> > place, but it's not pulling conversation out of our devel list.
> >
> > BENEFITS
> >
> > 1) Stops splitting place for important discussions - we already have
> > the dev list.
> > 2) Actually *readable* content, easy to edit, easy to track changes.
> > 3) Rich content - github hasn't invented HTML/RTF with images, wiki
> > can do it all.
> > 4) Free form - just write your proposal, add a title, name and status
> > and that's it.
> >
> > ALTERNATIVE PROPOSAL
> >
> > Let's keep the github repo but remove all git content and move all
> > pages to wiki 

[foreman-dev] Merge rights to Katello installer

[Sean O'Keeffe]

Hi,

I'd like to request write access to the installer team.

I've been involved with 38 PRs across what I'd consider to be the 'main'
repos, apparently I created 15 of them and I guess I reviewed the rest.

https://github.com/Katello/puppet-katello/pulls?q=is%3Apr%20involves%3Asean797%20
https://github.com/Katello/katello-installer/pulls?utf8=%E2%9C%93=is%3Apr%20involves%3Asean797
https://github.com/Katello/puppet-certs/pulls?utf8=%E2%9C%93=is%3Apr%20involves%3Asean797%20
https://github.com/Katello/puppet-candlepin/pulls?utf8=%E2%9C%93=is%3Apr%20involves%3Asean797%20
https://github.com/Katello/puppet-foreman_proxy_content/pulls?utf8=%E2%9C%93=is%3Apr%20involves%3Asean797
https://github.com/Katello/puppet-pulp/pulls?utf8=%E2%9C%93=is%3Apr%20involves%3Asean797%20
https://github.com/Katello/puppet-qpid/pulls?utf8=%E2%9C%93=is%3Apr%20involves%3Asean797

Thanks,
Sean

-- 
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] Current State of Nightlies

[Sean O'Keeffe]

Why dont we ask the maintainer to pkg a new version or someone offer to
become a co-maintainer and get a new version into EPEL ?


On Mon, Oct 16, 2017 at 9:31 PM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> On Mon, Oct 16, 2017 at 04:18:53PM -0400, Eric D Helms wrote:
>
>> Nightly RPM and tests have been broken for around 2 weeks now. This
>> morning
>> a bit of a regression was merged to foreman core to fix the breaking RPM
>> aspect and I can report that nightly RPMs are now building. However, this
>> leads to a breakage in plugin asset usage with the newer React components.
>> To potentially address this I have opened [1] for testing and input. As
>> part of the original breakage, I added to test_develop running npm install
>> and webpack compile the same way our RPMs do in order to catch these sort
>> of issues earlier.
>>
>
> Thanks for this!
>
> The second half is that after RPMs were built, repoclosure on the test
>> pipeline is currently failing [2]. The highlight being:
>>
>> *20:10:35* package: nodejs-react-dom-15.6.2-1.el7.noarch from
>> undertest-yum_el7-4203183943-68*20:10:35*   unresolved deps:
>> *20:10:35*  npm(object-assign) >= 0:4.1.0*20:10:35*
>> npm(loose-envify) < 0:2*20:10:35*  npm(loose-envify) >= 0:1.1.0
>>
>>
>>
>> nodejs-object-assign-2.0.0 exists in EPEL leading me to believe we will
>> need to add both of these as top level packages carried in
>> foreman-packaging. Can anyone confirm or deny that is how this should be
>> working? Or should another package we build be providing these?
>>
>
> I do believe we need to package this ourselves since we need a newer
> version than in EPEL.
>
> [1] https://github.com/theforeman/foreman/pull/4924
>> [2] http://ci.theforeman.org/job/packaging_repoclosure/37110/console
>>
>
> --
> 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

[Sean O'Keeffe]

“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.

Re: [foreman-dev] [Infra] Reducing Test Matrix

[Sean O'Keeffe]

+1 to hosting the Jenkinsfile in the repos, it'll make changes much easier.

All other ideas seem sane, nice!

On Wed, 23 Aug 2017 at 08:16, Ivan Necas  wrote:

> On Wed, 23 Aug 2017 at 01:44, Eric D Helms  wrote:
>
>> I am beginning to look at updating some of our test infrastructure by
>> re-writing Jenkins jobs into the pipeline plugin [1]. This is a new style,
>> with a different way of both writing and thinking about how jobs are
>> crafted. I've started this work by attempting to write jobs for both
>> Foreman and Katello [2].
>>
>> The current test_develop job for Foreman (which runs after pull requests
>> are merged) is a 4x3 matrix resulting in 12 different configurations
>> running. They are:
>>
>>  ruby: 2.1, 2.2, 2.3, 3.4
>>  databases: mysql, postgresql, sqlite3
>>
>> I would like to propose the following:
>>
>>  1) We drop sqlite3 entirely
>>
>
> :-1: Having an option to use sqlite3 is very convenient for small patch
> devel setup, I would vote to keep it at least for one ruby version
>
> -- Ivan
>
>>  2) We test all rubies on postgresql only
>>  3) We pick the most widely used Ruby version and test mysql with that
>>
>> This would effectively reduce the number of test runs in the matrix to 5
>> which should in theory increase throughput of testing and keep things
>> focused on the most important pieces to test. Further, sqlite3 is not a
>> production database so I feel it not worth the resources (but it would only
>> add one more job to keep it). I also don't see how Ruby version should
>> affect database choice and thus find no reason to run the full matrix
>> across all rubies for Mysql.
>>
>> From what I think I know, of the Rubies:
>>
>>  2.2 -- used in RPM production
>>  2.1, 2.3, 2.4 -- used by Debian production
>>
>> [1] https://jenkins.io/doc/book/pipeline/
>> [2] https://github.com/theforeman/foreman-infra/pull/321
>>
>> --
>> 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.

[foreman-dev] foreman-installer ansible role

[Sean O'Keeffe]

Hey guys!

I have a foreman-installer Ansible role[1], its really flexible and works
by merging a hash of custom parameters with the default ones defined in the
scenario's answer file.
I would quite like to move it to theforeman Github organisation and publish
it in Ansible galaxy under TheForeman name if people agree ?

My use case was for configuring a foreman cluster.

[1] https://github.com/sean797/ansible-role-foreman_installer

-- 
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] qdrouterd communication

[Sean O'Keeffe]

Hey Dhaval,

In future these kind of questions are better of being asked on
foreman-users. foreman-dev is meant for developer discussons :-)

Are you a Red Hat Satellite customer or Katello user?
Have you read https://access.redhat.com/articles/2474581 ?

REX is Remote Execution. (another plugin)
https://theforeman.org/plugins/foreman_remote_execution/0.3/index.html

On Fri, Apr 28, 2017 at 4:37 PM, Unix SA  wrote:

> Thanks Justin,
>
> >>Capsule syncs are no longer handled via qdrouterd (since katello 3.0).
> Ok, so i think that works over https and that is handled by apache.
>
> >>I'm not 100% sure what you are asking here.  Could you explain a bit
> more?
> I have my capsule behind firewall, and master in other region and they are
> connected over WAN, so i was looking for information if there is any impact
> if connection disruption, any timeout values, also how to measure latency
> of content sync,
>
> is there any document on
>
> how much capsules one single master can handle ?
> how to calculate latency between capsule <-> master sync ?
> how to handle DR or HA for capsules and Satellite master ?
> how to run Capsule and master on CNAME ?
>
> >> if you use REX it will still work fine though.
>
> what is that REX mean ?
>
>
>
>
> On Friday, 28 April 2017 18:52:02 UTC+5:30, jsherril wrote:
>>
>>
>>
>> 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.
>

-- 
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] HTTPS Username / Password authentication in foreman_templates

[Sean O'Keeffe]

Yes - just set the URL to "
https://username:passw...@github.com/username/repository.git; and it should
work.

On Fri, Apr 21, 2017 at 3:05 PM, Bernhard Suttner  wrote:

> Hi,
>
> is it already possible to use username / password authentication to access
> the HTTPS-based git repository?
>
> If this is not the case, I'm happy that someone provides some information
> how to do it. I would then have a look on it.
>
> Best regards,
> Bernhard
>
> --
> ATIX - The Linux & Open Source Company
> 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.
>

-- 
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/Request for an foreman-ansible-modules repository

[Sean O'Keeffe]

I think this is a great idea, being able to configure and populate multiple
Katello servers from a git repository is something I'm going to be doing in
a couple of months and this sound perfect for it!

On Wed, 5 Apr 2017 at 16:04, Eric D Helms  wrote:

> Howdy,
>
> I have a number of Ansible modules that I have developed for managing
> Katello entities and Foreman organizations. An Ansible module can be
> thought of as providing extentsibility and new functionality to Ansible
> roles and playbooks. In this case, by being able to manage entities within
> Foreman and Katello. There are also a number of modules I have seen upon
> google search that exist for other various Foreman entities.
>
> I would like to share the modules I have written and encourage other
> community users to share theirs in a centralized place for use. Ideally,
> these modules would be offered to and go into Ansible's core set of modules
> after some time of development. However, I believe they need somewhere
> useful to live during said transition and as a place to harden them before
> offering them up and awaiting an Ansible release.
>
> Thus, I would like to propose and request a repository on theforeman
> Github organization named 'foreman-ansible-modules' as a place for these to
> live. The goals of the repository would be:
>
>  * House Ansible modules for managing Foreman and Katello entities
>  * Encourage other community users to add in their own to centralize them
>  * Have a mission to contribute the modules to Ansible proper and remove
> them from this repository when they are accepted
>
> If the development community feels this should be not be part of
> theforeman proper then so be it and I will manage them on my own. But, I
> ask that we weigh the value that this could add to the community at large.
>
> --
> 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] [RFC] - Proxies with multiple interfaces

[Sean O'Keeffe]

On Mon, Mar 20, 2017 at 2:25 PM, Lukas Zapletal <l...@redhat.com> wrote:

> Hey,
>
Howdy :-)

>
> I can't remember recommending such a big change :-)

Sorry I meant about tagging the email with [RFE]


> Can you elaborate more on motivation? Multi-homed proxy is still one
> instance, why would
> Foreman need to reach to it in two different ways?

This is for clients to reach a proxy in the different ways, NOT foreman.


> Isn't the result always the same (a change on the same instance)? How
> about relaxing
> the constraing when each individual proxy must have unique URL? Just
> checking before introducing another table (more SQL joins and query
> complexity).
>
If a Host / HostGroups can be assigned a URL/Hostname instead of a proxy
its useful for Multi-homing, loadbalancing & NAT'ed environments, maybe
others?
What does relaxing the unique URL constrain actually give us? I think if
you have 2 proxies with the same URL that's just effectively duplicating
the object?

Or if you mean creating 2 proxies with different URLs (an external & and
another internal one) I think would be problematic when Foreman needs to
talk to the Proxy. E.g Host needs to talk to proxy1-external.example.com
but foreman must talk to the proxy via proxy1-internal.example.com. If we
have 2 proxies in foreman ( proxy1-internal & proxy1-external ) and you
assign a host proxy1-external foreman would try to connect to
proxy1-external.example.com to create a DHCP or DNS or something else with
would not work.


>
> By the way this is (a properly tagged) RFC thread, why you already
> imlemented that? You had to spend lot of time on this already, we may
> find an alternative and less intrusive solution instead.
>
Because IMO proper discussions don't tend to actually happen until someone
writes the code.

Thanks for the reply!
Sean

>
> LZ
>
>
> On Wed, Mar 15, 2017 at 11:18 AM, Sean O'Keeffe <sokee...@redhat.com>
> wrote:
> > Hey!
> >
> > So lzap suggested this.. lets see how it goes :-)
> >
> > I'm looking to solve the following issues
> > - I would like to have a multi-homed proxy.
> > - I would like clients to connect to a Proxy when there is a NAT between.
> >
> > My approach has been for proxies to have multiple URLs and during
> > provisioning the user would then select a URL instead of the current
> method
> > of selecting a Proxy, This would be then mean all communication between
> the
> > Client -> Proxy would be via the selected URL. Each proxy would also
> have a
> > 'primary' URL which Foreman would always use to connect to it via.
> >
> > Does this approach make sense?
> > Any feedback to greatly appreciated
> >
> > Changes required:
> > Foreman: https://github.com/theforeman/foreman/pull/4346
> > - Adds Proxy URL concept
> > - Puppet CA & Puppet Master selection are now URLS
> >
> > Katello: PR to be raised
> > Content Source selection need to list URLS.
> > Bootstrap RPM will need to create one for each URL
> >
> > Let me know what you think or any questions you have!
> > Sean
> >
> > --
> > 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.
>

-- 
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] Dev/Design Weekly Meeting - Subscriptions

[Sean O'Keeffe]

On Wed, 15 Mar 2017 at 11:50, Marek Hulán <mhu...@redhat.com> wrote:

> Hello Sean,
>
> I'm sorry if we created a feeling that we're doing something behind closed
> doors.
>
> Let me explain the background. When Roxanne started to look at the UI/UX
> improvements we quickly realized that Foreman with all its plugins is a big
> application and it seemed as too much to digest at once. So we decided to
> start introducing smaller, isolated parts of the whole thing to her once a
> week. Each week we sit and talk about specific area. I hope that it helps
> Roxanne to understand how the project is interconnected so she can suggest
> larger changes consistent across the whole app after some time.

That makes sense, a bit of context around the email would have been nice
though.

>
>
> Also as part of these demos, she takes notes of small items that we can fix
> right away, such as "this inline help does not provide a value", "this
> button
> should not be red". So it's not really a discussion or designing of new
> stuff,
> it's rather a demo for a certain area.

Thats good and I would agree if it's just a couple of small changes. Though
as this is a concerted effort that overall will like significantly impact
the UI a simple email like "we're going to making loads of changes to the
UI over the next few months, over many PRs. Here's the tracker in redmine,
watch it if you want to follow all of the changes" or use of the rfc repo
would have been nice.

>
> Roxanne provides the notes from these sessions for what could be improved.
> If
> those are low hanging fruit we try to fix it right away. Since she shares
> notes during these sessions and share them with everyone so people who are
> interested could also add their comments. All changes are going through PRs
> and the discussion, if necessary, happens there.
>
> I think sharing these notes is also useful for people who'd like to
> contribute
> with code and are looking for something small.
>
> I hope it makes better sense now.

Yes, thank you! The main issue was lack of context around these emails.

>
> --
> Marek
>
> On úterý 14. března 2017 22:43:39 CET Sean O'Keeffe wrote:
> > Firstly thanks for all the valuable input Roxanne, I'm just a bit
> concerned
> > about discussions that to me at least appear to be happening behind
> closed
> > doors.
> >
> > When do these "Dev/Design Weekly Meeting" take place?
> > Have they ever been advertised on this mailing list or anywhere
> publicly? I
> > haven't seen anything, maybe I missed it?
> > If not, why not?
> >
> > Having conversations behind closed doors that have such a large impact on
> > the project is not a good thing.
> > To me, sending notes about a meeting that I can only assume happens
> within
> > redhat every week is quite inappropriate. Not only does it make people in
> > the community feel excluded from important discussions, but it also shows
> > the sway and power redhat has within this community, which in my opinion
> > shouldn't be the case.
> >
> > I get that redhat will want to make suggestions that benefit itself and
> us
> > and maybe sometimes just itself but this is not the right way to go about
> > it. We need to have open discussions.
> >
> > Sean
> >
> > On Mon, Mar 13, 2017 at 3:02 PM, Roxanne Hoover <rohoo...@redhat.com>
> wrote:
> > > https://docs.google.com/document/d/1zqK49SNLMA2t8SHen4M2z6-Z
> > > gsVk3oKEQsCwxcK6d6A/edit
> > >
> > >
> > > Subscription Management
> > >
> > > Presented by Thomas McKay
> > >
> > >
> > > Subscription Manifest -- no manifest yet
> > >
> > >-
> > >
> > >Manifest history -- no message/time… it should state as much.
> > >-
> > >
> > >More direct route to Upload… entire page not necessary because it
> has
> > >no data.
> > >-
> > >
> > >Upload success inline messaging lacks icon.
> > >
> > > Subscription Manifest - already manifest
> > >
> > >-
> > >
> > >Delete Manifest is a big deal.
> > >-
> > >
> > >IMport History tab might not be necessary
> > >-
> > >
> > >“Upstream Subscription Management Application” - wraps to 4 lines,
> > >creates awkward empty space and could be confused for independant
> > >labels.
> > >-
> > >
> > >Can the Upload button Delete and then Upload… Tom says no.
> > >-
> > >
> >

[foreman-dev] [RFC] - Proxies with multiple interfaces

[Sean O'Keeffe]

Hey!

So lzap suggested this.. lets see how it goes :-)

*I'm looking to solve the following issues*
- I would like to have a multi-homed proxy.
- I would like clients to connect to a Proxy when there is a NAT between.

My approach has been for proxies to have multiple URLs and during
provisioning the user would then select a URL instead of the current method
of selecting a Proxy, This would be then mean all communication between the
Client -> Proxy would be via the selected URL. Each proxy would also have a
'primary' URL which Foreman would always use to connect to it via.

Does this approach make sense?
Any feedback to greatly appreciated

*Changes required:*
Foreman: https://github.com/theforeman/foreman/pull/4346
- Adds Proxy URL concept
- Puppet CA & Puppet Master selection are now URLS

Katello: PR to be raised
Content Source selection need to list URLS.
Bootstrap RPM will need to create one for each URL

Let me know what you think or any questions you have!
Sean

-- 
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] Notification content

[Sean O'Keeffe]

It's be nice to be able to turn some of these off, I might not care about
some types of notifications.

I think a simple "don't show this type of notifications again" on the
notification would be great.

I don't know if this is already possible?

Also a couple of more notification suggestions:
- Disk space if using Katello
- new blog post posted
- new community demo
- other community stuff?


Sean

On Wed, 25 Jan 2017 at 07:42, Ohad Levy  wrote:

> Hi,
>
> As you probably heard (and saw in the last demo) we have a new
> notification system, now its time to start using and improving it.
>
> here are some of the content I think make sense to discuss, comments etc
> are welcomed:
>
> first, I would like to group notification based of topic, for example,
> provisioning, infrastructure errors, plugin specific (e.g. content /
> subscriptions) etc
>
> Provisioning:
>
> notification when host was failed to provision - for example we were
> unable to render a template, or a proxy was down etc, this is usually
> hidden from the user and the only way to figure out whats going on is via
> logs or machine console.
> an action could be to take the user the to rebuild host modal, which
> checks the templates and proxies. another action could be to the host edit
> page, but we must relay the actual error so its clear what the issue is.
> I would suggest to keep the notification for 3 days or if the host got
> reprovisioned - then we could remove / mark as read the old notification.
>
> success provisioning - As we already send an email every time a host has
> finished provisioning, i think it make sense to highlight that in the UI as
> well, I would default to 24 hours or even less for such events. we could
> further think about limiting to either top xx hosts that got provisioned,
> or just have a message saying hosts were provisioned, where you can link
> and get back to host list of installed_at > time and owner = current.user.
>
> Inventory
> fact / report importing
> - when a new host gets imported? does it make sense? currently if we
> import a host from facts there is no place where we tell the user it
> happened, yet the concern here is that initial import can import thousands
> of hosts, so clearly, we can't have one notification per host.
>
> - when there is a failure importing facts (imho reports are already
> visible in the host status).
> I personally had problems where i was able to create a host record, but
> Nic record failed from some reason. as a user, if I would not watch the
> logs, I would be clueless of that failure ever happening.
> my concern here is that while I get let the user know a failure happened,
> I have no action to take him to, for example, I see this in my logs:
> 2017-01-23T15:31:08 26265d09 [app] [I] Import facts for 'host' completed.
> Added: 0, Updated: 4, Deleted 0 facts
> 2017-01-23T15:31:09 26265d09 [sql] [W] Saving br182 NIC for host host
> failed, skipping because:
> 2017-01-23T15:31:09 26265d09 [sql] [W]  IP address has already been taken
> 2017-01-23T15:31:09 26265d09 [sql] [W] Saving em1 NIC for host host
> failed, skipping because:
> 2017-01-23T15:31:09 26265d09 [sql] [W]  IP address can't be blank
> 2017-01-23T15:31:09 26265d09 [sql] [W]  Ip6 can't be blank
> 2017-01-23T15:31:09 26265d09 [sql] [W] Saving ipmi NIC for host host
> failed, skipping because:
> 2017-01-23T15:31:09 26265d09 [sql] [W]  Identifier has already been taken
> 2017-01-23T15:31:09 26265d09 [app] [I] Completed 201 Created in 569ms
> (Views: 4.3ms | ActiveRecord: 149.4ms)
>
> yet we have no place where this information is visible in the UI, I think
> we would need to either capture these errors in the db, or have a wizard /
> troubleshooting flow to fix this kind of issues. maybe just notifying the
> user as a first step is better than nothing.
>
> ENC Failures
> - If we were unable to create ENC output for puppet I would like to see a
> notification, again I would limit it to a certain amount of events (e.g.
> maybe up to 5?) and would clear the notification once the issue is fixed.
>
> Users
> - Does it make sense to notify admins when new users start using the
> system?
> - Anything else? (maybe admin change your permissions?)
>
> Org/Loc
> - Hosts in mismatch mode?
> - Hosts that do not belong to any org/loc (probably because they were
> imported?)
>
> Trends
> - When trend counter is not running?
>
> System status
> - when proxies are down / with failures
> - when dynflow, pulp candlepin etc are down
> - when compute resources are down?
> - when ldap servers are down?
> (all of these errors should clear or change their severity once they are
> resolved).
> - when there is a newer version of foreman or plugin available upstream?
>
> Community Templates
> - When there is a new version of the templates available at github?
>
> Discovery
> - When at least one new host is being discovered in the last xx minutes
> - When discovered host fails?
>
> CA Expiry (Puppet and others)
> When 

Re: Re: [foreman-dev] Revert removal of @host.params for host_param

[Sean O'Keeffe]

Maybe the best thing to do for now it to revert it and send a PR to the RFC
repo for a proper discussion?

On Fri, Jan 13, 2017 at 2:26 PM, Daniel Lobato Garcia 
wrote:

> On 01/12, Marek Hulán wrote:
>  > >
> > > > I strongly disagree that this does not have big benefits. Using
> internal
> > > > Foreman objects in templates is a bad practice. It blocks us from
> > > > improving
> > > > our code. Therefore it's very important to build a DSL that users
> can use
> > > > in templates and keep that compatible. We can then later change the
> > > > implementation of host_param_true method without any templates
> changing.
> > > > Think
> > > > of this as a templating API.
> > > >
> > > > Another less significant benefit is that for plugins it's easier to
> > > > wrap/alias
> > > > the template method rather than manipulating something that's used
> > > > internally in @host. Still not ideal but that should be solved by
> > > > https://github.com/ theforeman/foreman/pull/3701
> > > >
> > > > Of course it will require users to migrate to new template helpers
> which
> > > > is
> > > > why we move there slowly and hopefully with proper deprecations. I
> was
> > > > hoping to do the update for community-templates since it's very easy
> > > > migration.
> > > >
> > > > If you think it's too complicated for users we could provide rake
> task or
> > > > migration. But please don't revert this.
> > >
> > > Yes, if you provided a migration it would be much better.  That doesn't
> > > really solve the problem with people using the foreman_templates plugin
> > > who will have those changes reverted, but I guess it's better than
> nothing.
> > >
> > > There's still dozens of other things allowed for @host in the Jail that
> > > aren't covered by these macros.   What's the plan for those?
> >
> > Whenever we have a chance, we should move from internal objects to
> macros. The
> > more macros we have the higher the chance is that we can keep templates
> > compatible.
>
> Sorry but I oppose this. Some internal objects are quite stable, in
> fact people rely upon them successfully - but we break the compatibility
> for apparent advantages that IMO are not worth the hassle.
>
> @host.operatingsystem, @host.architecture, etc... and @host.params, are
> very stable objects that can safely be called from templates and expect
> that will work for a long time. Not only our users do it. We also relied
> upon these internal objects for years.
>
> The first community templates PRs which are 4 years old used
> @host.params, @host.operatingsystem, etc.. Those are stable enough to
> not warrant writing a macro for them
>
> What we did on #16740 is basically renaming things around and deprecating
> params for macros that don't do anything but calling @host.params
> themselves.
>
> I would argue for the opposite way of thinking. When we change how
> these internal APIs work, we should deprecate them. If these APIs
> remain stable, don't change anything as it provides no value, and brings
> headaches and wastes time. Time wasted on writing this thread, on the
> people who write and review PRs in the project and associated ones
> (templates, the migration to new macros, fixing anything that might break,
> and adding more LOC which complicate our codebase).
>
> >
> > > I still think this provides more headaches than any benefits.
> >
> > I hope that following helps
> > * https://github.com/theforeman/community-templates/pull/343
> > * https://github.com/theforeman/foreman/pull/4187
> > * https://gist.github.com/ares/5435226ef0317613535101765404d3f5
> >
> > --
> > Marek
> >
> > >
> > >
> > > - Stephen
> > >
> > > > --
> > > > Marek
> > > >
> > > > --
> > > > 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.
>

-- 
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 

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

[Sean O'Keeffe]

Hows this going for everybody? I personally quite like it

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.

[foreman-dev] Redmine permissions

[Sean O'Keeffe]

Hey!

A common problem I keep coming across is I cant edit any issues, so if I
create an issue or one is assigned to me I cannot correct any errors or
change one of the attributes, all i can do it add a comment asking for
someone else to do it. And I'm sure others with more permissions have
better thing to do than update other peoples issues.

Can we by default allow users to edit issues assigned to them & issues
they've created? [1] shows that it should be possible.

[1] http://www.redmine.org/issues/12550

Sean

-- 
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] Foreman Hooks Collaboration

[Sean O'Keeffe]

Hi Guys,

So I wanted to get people opinions on having a central repo to collaborate
around foreman_hooks? It could be kind of similar to community_templates
but for foreman_hooks, but hopefully it could also be a good source for
ideas for new plugins.

For example I've written a hook that uses foreman_bookdisk and the HP iLO
API to automate provisioning physicals and thought it would be good to
share it with the community.

Sean

-- 
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] Using certificates for SSH access

[Sean O'Keeffe]

Agreed, I think we should look for better integrations into other projects
like FreeIPA, so users can easily do this. A authentication
infrastructure project like FreeIPA will always do a better job than we
could do imo

Sean

On Tuesday, 13 September 2016, Stephen Benjamin  wrote:

>
>
> - Original Message -
> > From: "Marek Hulán" >
> > To: foreman-dev@googlegroups.com 
> > Sent: Tuesday, September 13, 2016 10:13:45 AM
> > Subject: Re: [foreman-dev] Using certificates for SSH access
> >
> > Hello
> >
> > some comments below
> >
> > On Tuesday 13 of September 2016 08:51:12 Ohad Levy wrote:
> > > Hi,
> > >
> > > I was looking at [1] which talks about how to leverage a CA for
> managing
> > > SSH access, and I thought it could be interesting for REX and
> potentially
> > > for foreman to manage.
> > >
> > > In the post, they describe how they create different principles
> (groups -
> > > think hostgroups) for access, generating certificates with expatriation
> > > etc.
> > >
> > > Since we already have some of the certificate handling code (puppet ca,
> > > pulp / katello certs) I wonder if it make sense to generalize it and
> offer
> > > SSH certificates (and their management and possible an auditing system
> for
> > > their usage) offering?
> >
> > I was thinking about this earlier, the major benefit I see is that in
> case we
> > change the key that Foreman uses we wouldn't have to update all hosts.
> Since
> > we currently only install it during provisioning it might be very
> helpful.
> > OTOH we should also provide puppet module that would configure this key
> so
> > there's easy way to update it also for unmanaged hosts. Then the CA
> might not
> > have that many benefits, we'd have to distribute the CA pub key instead
> of
> > the
> > main pub key. Probably the biggest benefit would be the key expiration.
> >
> > If we decide to generalize the CA handling I'd first look if we could use
> > something existing, e.g. FreeIPA. Maybe we could provide our simple
> backend
> > too but I'd like to avoid building our own CA on top ssh-keygen :-) I'd
> also
> > like to keep it in separate plugin - probably rex.
>
>
> The CA use with ssh-keygen is a neat idea, but FreeIPA does some great
> things
> that I'd rather not have us have to deal with.  The Facebook article
> towards
> the end evens offers warnings about the lack of any kind of revocation
> scheme.
>
> FreeIPA can do that, and handles it quite gracefully.  If a smart proxy key
> gets compromised, you can just remove it from authorized keys in FreeIPA
> and it propagates everywhere automatically.
>
> And we could even go further with FreeIPA and not have to deal with SSH
> keys
> at all and go the kerberos route, which handles access controls, key
> revocation,
> expiration, etc all very nicely.  We have an RFE for that[1].
>
>
> - Stephen
>
> [1] http://projects.theforeman.org/issues/11936
>
>
> > --
> > Marek
> >
> > >
> > > Ohad
> > >
> > > [1]
> > > https://code.facebook.com/posts/365787980419535/
> scalable-and-secure-access-w
> > > ith-ssh/
> >
> > --
> > 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.