[foreman-dev] Re: New form helpers and reusing definitions from server side

[Timo Goebel]

Marek,

Thanks for bringing this up. I think you raised some good points and I do 
agree, these are pain points. But I do prefer an iterative approach here, 
where we don't get it perfect on the first spot. How can we be sure, what 
we really need by not experimenting a bit? In my opinion, the react PRs are 
already quite large. I personally prefer much smaller iterations. I think 
we should define a common goal (maybe moving to a SPA all together, I don't 
know) and try to reach that goal one step at a time.
I personally like the client-side validation, that's a lot of user value, 
but I wouldn't have added it so early in the development process. It just 
added more complexity.

To be honest, we define our data model already twice. Once in the rails 
models and once in the API documentation. Maybe the way to go is to use 
graphql to have a shared schema for both the client and the server? I don't 
know the answer, but I believe, we need do something and learn from that. 
It might not be perfect at first, but we'll eventually get there.

Timo


Am Dienstag, 19. Dezember 2017 17:59:28 UTC+1 schrieb Marek Hulán:
>
> Hello 
>
> I'd like to bring into awareness a discussion that's going on in bookmarks 
> PR 
> [1]. This PR demonstrates how to do client side validations using new 
> components for forms. E.g. this is how we define that the field is 
> required 
> and can't be too long [2]. We have similar validations defined in our 
> model. 
>
> One concern I had is that we'll duplicate the definition, both in UI and 
> our 
> data model. I'd prefer to have UI validation rendered based on server 
> definition. There are cases where the UI field is not related to the 
> specific 
> model attribute so we also need the option to explicitly define client 
> validations. 
>
> Similarly, strings that are normally rendered server side are now 
> duplicated 
> at [3]. That can end up in out of sync error messages for users using UI 
> and 
> API. 
>
> Of course this can be refactored later, but if we start to hardcode too 
> many 
> things, the motivation for later refactoring will be lower. Also I'd like 
> to 
> have good form helpers from the beginning since changes to them will have 
> impact on many plugins later. 
>
> I'm definitely not going to block the PR on this. But I'd like to hear 
> opinions of others, suggestions for improvements or any other feedback. 
>
> [1] https://github.com/theforeman/foreman/pull/4807 
> [2] https://github.com/theforeman/foreman/pull/4807/ 
> files#diff-6011fb23e8f8bacb536ab442e57b874cR48 
> 
>  
> [3] https://github.com/theforeman/foreman/pull/4807/ 
> files#diff-6254f272d0e11d7caaacec9ece0c6669R6 
> 
>  
>
> Thanks 
>
> -- 
> 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.

Re: [foreman-dev] Possible to allow public access to finish templates?

[Timo Goebel]

Hi Martin,

Check out the foreman_userdata plugin. That might be what you need. It was made 
to make vmware image deployments more fun. The README on github has more detail.

Timo

> On 19. Dec 2017, at 11:48, 'Martin Juhl' via foreman-dev 
>  wrote:
> 
> Hi
> 
> 
> 
> I’m trying to get Linux Image deployments with vmware to work, without SSH…
> 
> Is it possible to allow public access (preferrably IP-based) to the finish 
> templates??? right now I need a login to see them…???
> 
> 
> 
> Thanks
> 
> 
> 
> Martin
> 
> -- 
> 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] DHCP filename option no longer honored

[Timo Goebel]

Hi,

Dimitri sent a patch that should fix the problem. It's just a one line 
change, so we just need to test it and it should be ready to merge.


However, we should check what change really introduced the problem to 
see if this needs backporting to 1.16. I have some doubts it was the 
change mentioned below.


Lukas, can you please confirm the patch fixes the issue for you?

Timo

Am 14.12.17 um 14:21 schrieb Lukas Zapletal:

Hey,

I noticed that DHCP filename option is no longer honored in
develop/1.17 branch anymore. This is regression from 1.15/1.16 series,
filed a blocker bug for 1.17:

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

This breaks UEFI provisioning. I git-bisected

commit e75df1dd3cc30bff2832d337b5bc20bd822e209a
Refs:
Author: Timo Goebel 
AuthorDate: Wed Oct 25 16:26:01 2017 +0200
Commit: Dmitri Dolguikh 
CommitDate: Mon Nov 6 14:28:09 2017 -0800

But I cannot figure it out, help needed. Thanks.




--
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] Nominating additional maintainers in foreman-core

[Timo Goebel]

Yes, please. We can use all the help we can get and both Shimon and Michael are 
doing great work.
Thanks Tomer for bringing this up.

> On 7. Dec 2017, at 09:23, Ondrej Prazak  wrote:
> 
> +1 to both
> 
>> On Wed, Dec 6, 2017 at 5:19 PM, Ivan Necas  wrote:
>> +2
>> 
>> -- Ivan
>> 
>>> On Wed, 6 Dec 2017 at 16:51, Lukas Zapletal  wrote:
>>> +1 +1 beer time!
>>> 
>>> LZ
>>> 
>>> On Wed, Dec 6, 2017 at 1:40 PM, Tomer Brisker  wrote:
>>> > Hello,
>>> > As many of you may have noticed, foreman-core open PR count has been in 
>>> > the
>>> > area of 100-110 for most of the last few months. There are only a few 
>>> > people
>>> > with merge access that actively review PRs, so that the time it takes for
>>> > changes to be accepted can take long. I would like to propose granting 
>>> > merge
>>> > access to two more members of the community:
>>> >
>>> > Shimon Shtein - has 75 merged commits [1] and has taken part in the 
>>> > reviews
>>> > of 64 merged commits[2].
>>> > Michael Moll - has 71 merged commits [3] and has taken part in the reviews
>>> > of 130 merged commits[4]. He is also already a long time maintainer of
>>> > several of our other repos and has proven to be a responsible maintainer.
>>> >
>>> > Please send +1/-1 either to the list or to me in private if you prefer.
>>> > Per our process, unless I receive any objections within a week, I will
>>> > request one of the organization owners to grant them access.
>>> >
>>> > [1]
>>> > https://github.com/theforeman/foreman/pulls?q=is%3Apr+author%3Ashimshtein+is%3Aclosed
>>> > [2]
>>> > https://github.com/theforeman/foreman/pulls?utf8=%E2%9C%93&q=is%3Apr+-author%3Ashimshtein+commenter%3Ashimshtein+is%3Aclosed+
>>> > [3]
>>> > https://github.com/theforeman/foreman/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Ammoll+is%3Aclosed+
>>> > [4]
>>> > https://github.com/theforeman/foreman/pulls?utf8=%E2%9C%93&q=is%3Apr+-author%3Ammoll+commenter%3Ammoll+is%3Aclosed+
>>> >
>>> > --
>>> > 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.
>>> 
>>> 
>>> 
>>> --
>>> 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] RFC: File audit for template rendering

[Timo Goebel]

I don't think, this is a good idea. Storing files on the local 
filesystem is generally consideres an anti-pattern imho. Both for web 
applications and expecially in a container world.


In a clustered setup, you'd have to attach some kind of shared-storage 
to the foreman hosts to make this work. Possibly via NFS or something. 
This is meant to cause trouble. I generally advise not to have any state 
on an application server.


I think, this can and should be done with a database. I agree, that the 
audit model might not be the best place for this. But a database 
definitely is.


Just my 2 cents.

- Timo

Am 05.12.17 um 18:01 schrieb Lukas Zapletal:

Hello,

Foreman does have a nice audit trail for many operations, what's
missing is ability to find how a template (e.g. kickstart) was
rendered. Storing whole template text in audit table is probably not
the best thing to do, production.log is also not a good fit, so here
is a proposal.

I want to create a small API called File audit (*) with ability to
store arbitrary files into
/var/log/foreman/file_audit/id/text-timestamp where "id" is record id
(or multiple ids concatenated with dots), "text" is arbitrary alphanum
text and "timestamp" is unix epoch number. Example:

/var/log/foreman/file_audit/1.33.7/my.host.lan-pxelinux-1512492603

That API will be used to store contents of all templates rendered, so
users can easily go "back in time" and see how templates are being
rendered. The directory would be root-only reading and files will be
created with restricted permissions (foreman user rw only). On system
with SELinux, security would be more tightened allowing writing only
to foreman_t domain and reading to nobody. For the example above, this
would mean:

1.33.7/my.host.lan-pxelinux-1512492603

1 - file audit type (static list, 1 stands for "template audit entry")
33 - host id
7 - template id
my.host.lan-pxelinux - extra data so users can work and search from command line
1512492603 - UNIX epoch timestamp

Everytime new record is added, a log entry is created into
production.log containing file path. By default, there will be a cron
job deleting all files older than one month. In documentation, we will
ask users to rsync the directory to different location if long-term
archival is needed.

This API could be used for other audit logging, for example when user
uploads a manifest ZIP file in katello or new version of RPM/Puppet
file. This will be the first step to improve audit around templates,
later on we can create a plugin showing the data in audit/host pages
if needed. But in the first phase, administrators could easily
search/grep/diff those files when necessary.

(*) if you have a better name, please do propose



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

[Timo Goebel]

... I think we should take increasing the major version as a chance and remove 
some old compatibility stuff with it like e.g. APIv1.
Or fix some APIv2 inconsistencies. Maybe we could move foreman tasks to core. 
Just some suggestions. Just increasing the major version is in, but I think 
just a cosmetic thing.

Timo

> On 29. Nov 2017, at 10:39, Lukas Zapletal  wrote:
> 
> What have Linus Torvalds and me in common? We both don't remember
> numbers higher than ten.
> 
> I propose to follow Linux kernel versioning and do 2.0 instead of 1.18
> for no other reason that it's just too high number and it's
> approaching crazy 20. "One point eighteen" sounds crazy, I always mess
> up with "One point eight". Frankly, I kinda lost track somewhere after
> 1.14. :-)
> 
> I'd like also to propose to avoid exceeding 10 in the future - someone
> speak up as we will approach to 1.8. Or we can put this to release
> wiki.
> 
> If we already have some infrastructure set for 1.18, I propose 1.19 to
> be 2.0 and act now - let's define a plan what needs to be done in
> advance. I can only think of version number in RedMine, but you tell
> me here what's needed.
> 
> I really hope it's not just me messing around with higher numbers or
> having problems with typing four characters instead of three many
> times.
> 
> -- 
> 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] Abandoned plugins under theforeman github org

[Timo Goebel]

... i would not remove it from the github org. There are even more abandoned 
plugins there. I would not delete the code, maybe somebody wants to start work 
on them again.

I would mark them as unmaintained in the repo description, remove the jenkins 
jobs and remove them from packaging.

Timo

-- 
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] Re: [UX] Facets and Host UI - roadmap discussion.

[Timo Goebel]

I have been playing with Facets the last few weeks and must say, that they 
are really great. It's pretty easy to add dedicated functionality to the 
host model and I want to use that for some of my plugins (Omaha, 
Monitoring, something new, ...).
Everything is great so far except for the missing UI hooks Shim mentions.

What I want to do are mostly easy thing, like adding a new tab to the host 
form or host show page. Currently, the only way to do this is using deface.
But this feels pretty hacky to me and isn't good to maintain. I'd really 
appreciate if there were easy and tested hooks for common areas like the 
host show page.

In my opinion, we are already too late on finishing the facets (and 
Pagelets) integration. Personally, I don't have a strong opinion on either 
option. But prefer the second approach as well.

In regards to widening the feature gap for a host ux redesign: We have to 
provide extension points anyways. The Foreman community gains a lot of 
value from the rich plugin ecosystem and the possibility to extend Foreman 
fairly easy.
When we redo the host ux pages, we have to provide extension points. This 
is not a nice-to-have feature, but a must-have in my opinion.

- Timo

-- 
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] Merge permissions to foreman-packaging

[Timo Goebel]

+1

> On 24. Oct 2017, at 07:33, Ondrej Prazak  wrote:
> 
> +1
> 
>> On Mon, Oct 23, 2017 at 9:49 PM, Marek Hulan  wrote:
>> +1, I remember you've helped me many times.
>> 
>> --
>> Marek
>> 
>> 
>> 
>> On October 23, 2017 6:16:48 PM Ewoud Kohl van Wijngaarden 
>>  wrote:
>> 
>>> Hello all,
>>> 
>>> To get more involved in packaging I'd like to request merge access to
>>> foreman-packaging. I've already been monitoring PRs and submitted
>>> various patches[1][2].
>>> 
>>> Regards,
>>> Ewoud Kohl van Wijngaarden
>>> 
>>> [1]: 
>>> https://github.com/theforeman/foreman-packaging/commits/rpm/develop?author=ekohl
>>> [2]: 
>>> https://github.com/theforeman/foreman-packaging/commits/deb/develop?author=ekohl
>>> 
>>> --
>>> 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] 1.17 Installation on Ubuntu 14.04 - Missing Dashboard Menu MouseOver Drop Downs && "Host Configuration Status widget loading".. Never Completes

[Timo Goebel]

Hi Lisa,

The Foreman dev setup basically needs two webservers running: One to 
serve the rails app via http and one to server webpacked javascript code.


I suspect, that the connection to the latter does not work. The two 
webservers are started using foreman (not "our forman", but a process 
manager gem with the same name). You can take a look at the Procfile to 
see what's going on. You can customize the startup with environment 
variables.



export RAILS_STARTUP='puma -w 3 -p 3000 --preload'

export WEBPACK_OPTS='... more options ...'

bundle exec foreman start


Timo

Am 12.10.17 um 02:56 schrieb Lisa Kachold:

I have setup TheForeman 1.17.1-0 in a Development install on AWS.

ruby 2.4.2p198 (2017-09-14 revision 59899) [x86_64-linux-gnu] 
(gem/bundler errors using other versions)

WEBrick 1.3.1
ALL Ports open from Server to my IP

I changed Rails to listen on all interfaces as:

|require'rails/commands/server'moduleRailsclassServeralias:default_options_bk 
:default_options defdefault_options 
default_options_bk.merge!(Host:'0.0.0.0')endendend|


Missing Dashboard Menu MouseOver Drop Downs && "Host Configuration 
Status widget loading".. Never Completes


Output from Log:

00:36:43 rails.1 | started with pid 19240

00:36:43 webpack.1 | started with pid 19241

00:36:45 webpack.1 | { [Error: ENOENT: no such file or directory, open 
'.env'] errno: -2, code: 'ENOENT', syscall: 'open', path: '.env' }


00:36:45 webpack.1 | Project is running at http://localhost:3808/

00:36:45 webpack.1 | webpack output is served from /webpack/

00:36:51 rails.1 | DEPRECATION WARNING: `config.serve_static_files` is 
deprecated and will be removed in Rails 5.1.


00:36:51 rails.1 | Please use `config.public_file_server.enabled` instead.

00:36:51 rails.1 |(called from  at 
/root/foreman/config/application.rb:218)


00:36:51 rails.1 | => Booting WEBrick

00:36:51 rails.1 | => Rails 5.0.6 application starting in development 
on http://0.0.0.0:5000


00:36:51 rails.1 | => Run `rails server -h` for more startup options

00:36:51 rails.1 | 2017-10-12T00:36:51[app] [W] DEPRECATION WARNING: 
ActiveRecord::Base.raise_in_transactional_callbacks= is deprecated, 
has no effect and will be removed without replacement. (called from 
 at /root/foreman/config/environment.rb:5)


00:36:55 rails.1 | The Apipie cache is turned off. Enable it and run 
apipie:cache rake task to speed up API calls.


00:36:58 rails.1 | 2017-10-12T00:36:58[app] [W] WARNING: Pry will not 
work with foreman gem, use script/foreman-start-dev


00:36:58 rails.1 | 2017-10-12T00:36:58[app] [W] DEPRECATION WARNING: 
before_filter is deprecated and will be removed in Rails 5.1. Use 
before_action instead. (called from  at 
/root/foreman/config/environment.rb:5)


00:36:58 rails.1 | 2017-10-12T00:36:58[app] [W] DEPRECATION WARNING: 
after_filter is deprecated and will be removed in Rails 5.1. Use 
after_action instead. (called from  at 
/root/foreman/config/environment.rb:5)


00:36:58 rails.1 | 2017-10-12T00:36:58[app] [W] DEPRECATION WARNING: 
before_filter is deprecated and will be removed in Rails 5.1. Use 
before_action instead. (called from  at 
/root/foreman/config/environment.rb:5)


00:36:58 rails.1 | 2017-10-12T00:36:58[app] [W] DEPRECATION WARNING: 
after_filter is deprecated and will be removed in Rails 5.1. Use 
after_action instead. (called from  at 
/root/foreman/config/environment.rb:5)


00:36:58 rails.1 | 2017-10-12T00:36:58[app] [W] DEPRECATION WARNING: 
alias_method_chain is deprecated. Please, use Module#prepend instead. 
From module, you can access the original method using super. (called 
from  at /root/foreman/config/environment.rb:5)


00:36:58 rails.1 | 2017-10-12T00:36:58[app] [W] DEPRECATION WARNING: 
Using a dynamic :controller segment in a route is deprecated and will 
be removed in Rails 5.2. (called from block in  at 
/root/foreman/config/routes.rb:17)


00:36:59 rails.1 | [2017-10-12 00:36:59] INFOWEBrick 1.3.1

00:36:59 rails.1 | [2017-10-12 00:36:59] INFOruby 2.4.2 (2017-09-14) 
[x86_64-linux-gnu]


00:36:59 rails.1 | [2017-10-12 00:36:59] 
INFOWEBrick::HTTPServer#start: pid=19242 port=5000


00:37:08 webpack.1 | Hash: 1d1afa88f456ce25e96c

00:37:08 webpack.1 | Version: webpack 3.6.0

00:37:08 webpack.1 | Time: 22521ms

00:37:08 webpack.1 | Asset SizeChunksChunk Names

00:37:08 webpack.1 | bundle.js17.5 MB 0[emitted][big]bundle

00:37:08 webpack.1 | vendor.js75.7 kB 1[emitted] vendor

00:37:08 webpack.1 |bundle.css81.7 kB 0[emitted] bundle

00:37:08 webpack.1 | manifest.json153 bytes[emitted]

00:37:08 webpack.1 | [55] 
./webpack/assets/javascripts/foreman_tools.js 4.22 kB {0} [built]


00:37:08 webpack.1 |[322] multi 
(webpack)-dev-server/client?http://localhost:3808 
webpack/hot/dev-server ./webpack/assets/javascripts/bundle.js 52 bytes 
{0} [built]


00:37:08 webpack.1 |[323] 
(webpack)-dev-server/client?http://localhost:3808 7.23 kB {0} [built]


00:37:08 webpack.1 |[371] (webpack)/hot/dev-server.js 1.61 kB {0} [built]

00:37:08 w

Re: [foreman-dev] Requesting discovery test for core PRs

[Timo Goebel]

... have you considered using some kind of a CDN for downloads, e.g. 
cloudflare, if traffic is a concern?

Timo

> On 27. Sep 2017, at 17:42, Greg Sutcliffe  wrote:
> 
>> On Wed, 2017-09-27 at 17:32 +0200, Michael Moll wrote:
>> 
>>> This would be PR-blocking, I assume? I'm fine with that, just
>>> checking.
>> 
>> While I'm +1 about this in general, the two specific cases for
>> Discovery
>> the last weeks were Rails 4.2 -> 5.0 and separation of puppet facts
>> from core. I can't see how a merge block on plugin breakages can be
>> mandatory. Of course it's nice to know that a change is breaking
>> plugins, and ideally the core PR author provides PRs to the affected
>> plugins then, but I worry about further reduction of core
>> development/merge speed, which is already not at its best...
> 
> Hmm, good point. There will always be a mix of cases where core is at
> fault, or where it's just a necessary update-and-roll-forward. I think
> there's two views here, we could go either way:
> 
> 1) This is advisory-only (non-blocking), but has the advantage of
> making more people aware of potential plugin breakage in PRs (compared
> to only the authors really finding out in a few days when the
> standalone plugin tests get run)
> 
> or
> 
> 2) This is blocking, but the processes that were discussed a few weeks
> back, about when to merge things with red tests, needs updating to
> account for this new test matrix.
> 
>>> * Bandwidth takes about 1/3rd of our $2k budget - perhaps we can
>>> affect that
>> 
>> Can we somehow see which part is taking most? I.e. is it the CI part
>> or rather the website?
> 
> I'll see what I can do. The Rackspace billing does provide an extensive
> CSV of all charges (several MB, which for CSV is impressive :P), so I
> may well be able to pull something from that.
> 
> 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] Release process & permissions

[Timo Goebel]

... isn‘t continuous delivery old these days? Why aren‘t we doing it?
I vote in favor of automating this. This ensures predictable results and 
hopefully makes this process easier. To be honest: The current process scares 
me.
Same for plugin releases. They also are way too manual right now.

Timo

> On 27. Sep 2017, at 16:46, Daniel Lobato Garcia  wrote:
> 
> Hi devs,
> 
> After a few releases, and now that I'm trying to help someone else to
> take over in case it's needed, I found a roadblock.
> 
> Whoever is doing the release, needs to have **many** permissions.
> 
> Otherwise, it doesn't make much sense for a person to take over release
> responsibilities. For example, if Ondrej has to do 1.15.5, he would need
> the following permissions (see at the end of the email).
> 
> Of course there are alternatives:
> 
> 1 is to have the release nanny be supervised by people who have 'earned'
> these permissions. This is a bad idea because some of the tasks just
> cannot be 'supervised'. The nanny would have to ask someone to tag
> repositories, modify jenkins jobs, upload GPG signatures, post to the
> mailing list, tag new builds in Koji...
> 
> 2 is to extend http://ci.theforeman.org/view/Release%20pipeline/ and
> make it a real pipeline from 0 to release completed. At this moment,
> releases that are not the first RC1 are mostly automated by
> https://github.com/dlobatog/foreman_release and
> https://github.com/theforeman/tool_belt.
> 
> My proposal is to go forward with 2. Give Jenkins permissions to do all
> of the actions needed, and whoever is the release nanny, ideally only
> has to make sure all of the steps are moving forward. If something
> breaks, figure out how to fix it for the next release.
> 
> This would mean making a few extra jobs before and after the current
> release pipeline. In my opinion, it's the way to go to ensure anyone can
> take over this responsibility.
> 
> At this moment, we are in a situation where only people who
> mostly have permissions everywhere can successfully do a release without
> asking many people for favors.
> 
> Personally if we complete this, I see it as a big win as it would dwarf
> our bus factor for release managers & allow us to release at any pace we
> desire (right now it's slow because we can't truly release things from
> one day to the next due to the work involved).
> 
> Thoughts?
> 
> Here's the list of permissions:
> 
> 
> 
> Github:
>  - Push in foreman, foreman-selinux, foreman-installer,
>smart-proxy, foreman-infra, foreman-packaging
> 
> Transifex -
>  - Allow to change the auto-update URL to point to latest -stable
>branch
> 
> Redmine -
>  - Create new "Found in Release" version
> 
> Jenkins -
>  - Modify jobs
>  - Run jobs
> 
> Koji -
>  - Create tags
>  - SSH access to update the mash scripts
>  - Create packages
>  - Tag builds
> 
> Repository servers
>  - ssh in deb.theforeman.org
>  - ssh in yum.theforeman.org
> 
> Announcements -
>  - Post to foreman-announce
>  - Merge access in theforeman.org
>  - Change IRC message
>  - Publish in Twitter, G+
> 
> ---
> 
> --
> Daniel Lobato Garcia
> 
> @dLobatog
> blog.daniellobato.me
> daniellobato.me
> 
> GPG: http://keys.gnupg.net/pks/lookup?op=get&search=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 email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Timo Goebel]

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

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

Re: [foreman-dev] Test failures and merging PRs

[Timo Goebel]

Am 28.08.17 um 17:12 schrieb Marek Hulán:

1) codeclimate is red

This can be ignored, we never agreed on using this as a hard metric for the
PR. The motivation to introduce it was mainly to save some time to reviewer.
We don't have to run it manually to get indications whether there's something
introducing a big complexity [1]. From my experience it sometimes leads to
worse code, since author splits the logic into more methods to lower e.g.
cyclomatic complexity but it should be judged separately in every case.

+1
I like it as a suggestion, but sometimes it's just off and better be 
ignored.


2) foreman is red

This can happen because of intermittent tests failures. If the PR is clearly
not causing new ones and commiter is aware of this error, the PR is merged
with message like "test unrelated" comments. If we are not sure, we retrigger
the run,

If Foreman develop branch is broken, we need to merge the PR to fix it so this
is another exception. Usually we trigger the jenkins job manually first to see
that the PR fixes the issue.

+1
Yes, don't merge a PR with failing Foreman core tests.


3) katello is red

If katello becomes red only for this PR, we analyze what causes it. Usually it
means that we change some internal things that have impact on Katello. In such
case, we're doing our best to send a fixing PR to Katello or we ping someone
with better knowledge in this area. We don't merge the PR until it's resolved,
then usually we merge both parts at the same time.
I think, this is totally unfair to all the "smaller" plugin maintainers 
and that's why I vote for removing the test completely or just keep it 
to test our public APIs.

I believe, we should do the following:
If the Foreman PR breaks some public API, e.g. facets, and the Katello 
tests show that, my suggestion is to fix the foreman PR to not break the 
public API and add proper depreciations if possible.
If we change something inside Foreman - in the past we changed the host 
multiple actions from GET to POST or introduced strong parameters for 
example - the contributor or maintainer should send a mail to 
foreman-dev expaining what needs to be changed in plugins. I think it's 
also a good idea to fix the example plugin or the How to create a plugin 
wiki page if applicable.
However I think, it's the plugin maintainer's responsibility to make 
sure his plugin works with Foreman. Everything else doesn't scale. In 
the past a lot of "my" plugins broke because of changes to Foreman core. 
Nobody cared to send a PR so far. But that's fine. I don't expect 
anybody to. It's my job to test the plugin and fix it if it breaks.
I think, we should not block Foreman PRs because an additional parameter 
was added to some internal method, just because Katello happens to 
overwrite that method. It just doesn't make any sense to me why we 
should do that for Katello but not for all the other plugins out there. 
This is not against Katello, it's just the only plugin tested with 
Foreman core right now.
Currently, we're developing a plugin to show system logfiles in Foreman. 
That requires a complete ELK-stack for development. I would not expect 
every developer to have that at hand.
If we leave Katello in the matrix, I think it would be totally fair to 
also add our new plugin to Foreman's test matrix as well. But I wouldn't 
want to block Foreman development just because some test in that plugin 
breaks.
I know, Katello is important for RedHat and it's one of the larger 
plugins. But that doesn't justify a special role in my opinion.

If it turns out there are more PRs that are failing with same errors, we merge
PRs if we're sure they don't introduce new Katello failures. At this time,
we're not blocking merges until Katello is green again. (*) here the
suggestion applies

4) upgrade is red

this is very similar to katello job, if there's some issue in upgrade, we
should not merge the PR. I remember though, there was a time when we knew the
job is broken which fall under "known to be broken" category.

+1, if upgrade is broken the PR is broken.


5) There's no 5, all the rest must be green. Sometimes hound service does not
respond and remains in "running" state, then it's retriggered by the reviewer.
prprocessor and travis must always be happy.
Don't get me started on hound. But it's the best we have right now, so 
generally speaking: Yes: Linting is important. If there are lint 
warnings, we shouldn't merge the PR.


Now the promised suggestion. When we see katello/upgrade job is broken on
multiple PRs, the first reviewer who spots it should notify the rest of
developers about "from now on, we ignore tests XY". The ideal channel seems to
be this list. This helps Katello devs to find out when it started, what were
the commits that first induced it.

[1] https://groups.google.com/forum/#!topic/foreman-dev/p7ESagXwNwk

Thanks for comments

--
Marek


Timo

--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To

Re: [foreman-dev] Changing PR processor introduction text

[Timo Goebel]

... do you just want to print some general hints for users for every new PR?
Or actively check that and automatically complain on every push?
I think prprocessor is already too chatty for my taste.
Maybe a Github PR Template could help as an alternative?

Timo

> On 31. Aug 2017, at 10:22, Lukas Zapletal  wrote:
> 
> Hey,
> 
> I would like to propose a change of our PR processor to better handle
> some things which we see often:
> 
> - empty description
> - splitting huge PRs into smaller ones
> - screenshots for UX changes
> 
> Any ideas for other things we should point out? Comments?
> 
> -- 
> 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

[Timo Goebel]

Am 23.08.17 um 01:44 schrieb Eric D Helms:


I would like to propose the following:

 1) We drop sqlite3 entirely
 2) We test all rubies on postgresql only
 3) We pick the most widely used Ruby version and test mysql with that
I think, Jenkins pipelines are a good thing and can make the Job 
configuration a lot easier. I'd like to to pitch some ideas. First of 
all I would propose putting the Jenkinsfile(s) in the repos alongside 
the code so it's more visible what happens and the job configuration 
follows the code lifecycle.
I've also grown fond of the Docker Plugin for Jenkins. With that you can 
easily run tests under different ruby versions. I found that easier to 
setup then rvm. If you'd like, I can share the code snippets. But it's 
rather trivial to connfigure.
You could also try to put the databases in a container. While I usually 
don't recommend this, it might be a good architectural choice for a CI 
system as you don't really need to persist data. It could also greatly 
decouple the jobs from the jenkins system. But first things first.


One more thing: If we have more capacity, we could start replacing 
HoundCI by our own linting again.


Timo

--
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 pulp_export_destination checks happen inside the application

[Timo Goebel]

Am 20.08.17 um 22:39 schrieb Ewoud Kohl van Wijngaarden:
I think if Pulp took a parameter to publish to a non-default 
location, we
would not need to do the extra copy step that ties Katello and Pulp 
closely

together. Currently it is needed because we need the export to land in
pulp_export_destination.


That would be nice. To me it looks like it already sends the 
export_directory to pulp and has an absolute path. Is there a reason 
this can't be set to Setting['pulp_export_destination'] directly?
What would you think, if we let smart_proxy_pulp handle the copy job and 
checking if the directories exist? That would loosen the coupling 
between Katello and Pulp?



Timo

--
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] Plugin gems with a single author

[Timo Goebel]

Am 20.08.17 um 15:48 schrieb Ohad Levy:


On Fri, Aug 18, 2017 at 2:48 PM, Greg Sutcliffe 
mailto:greg.sutcli...@gmail.com>> wrote:



Ohad Levy:
- foreman_memcache


Anyone? :) historically mmoll used to patch it - interested?


I currently use foreman_memcache in production, so I do have some 
interest in seeing it maintained. I'd volunteer if nobody else wants to.


I'd also be interested in helping with foreman_bootdisk. Although it's 
sad to see, it looks like Dominic isn't maintaining this at all anymore.


- Timo

--
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] Icon Feedback

[Timo Goebel]

In my opinion, the infrastructure icon looks unintuitive. How about some kind 
of treeview?
The rest looks good and straightforward to me.

Timo

> On 14. Aug 2017, at 21:10, Roxanne Hoover  wrote:
> 
> Visual Design took a pass at the icons in vertical nav. Anyone have any 
> thoughts? They seem straightforward to me, some were unaltered from the 
> original chosen.
> -- 
> 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] Aligning Foreman & Katello git repositories

[Timo Goebel]

Sounds very good to me. Let's do this and find solutions for problems as we go.
If bandwidth is an issue, Cloudflare CDN might be worth checking out for the 
packages.

Timo

> On 2. Aug 2017, at 14:33, Ewoud Kohl van Wijngaarden 
>  wrote:
> 
> Hello all,
> 
> As many of you know we have some overlapping work between Foreman and 
> Katello. This is an effort to reduce some of this. This is only focussing on 
> git repositories but once this is in place this should be easier. It's all 
> proposals and we will need to work out details.
> 
> One might notice that much of this has been talked about before but never 
> reached a conclusion, which is something we tend to do a lot. Let's break the 
> cycle and make some decisions.
> 
> # foreman-bats -> forklift merge
> 
> Currently we have foreman-bats[1] and forklift[2] which both include a 
> vagrant config and bats tests. I'd propose we merge foreman-bats into 
> forklift and deprecate foreman-bats. Most of bats (if not all) should already 
> be there so I believe we just need to verify we can test Foreman using 
> Forklift. Since I added Debian we need to make Ubuntu work and verify Jenkins 
> can still test everything it used to.
> 
> This should be a relative easy task for which a lot of work has already been 
> done.
> 
> Tasks/Challenges I can think of:
> 
> * Add Ubuntu to Forklift
> * Get bats passing on all supported configs
> * Verify foreman-bats is no longer used on CI
> * Add a deprecation warning in foreman-bats' README
> 
> # katello-packaging -> foreman-packaging
> 
> At the moment Foreman packages are maintained in foreman-packaging[3] with an 
> RPM branch for every release (rpm/1.15, rpm/1.16, rpm/develop) and a the same 
> with deb/ for obvious reasons. On the Katello side there is 
> katello-packaging[4] with KATELLO-3.3, KATELLO-3.4 and master.
> 
> There was a discussion in #1541[5] about merging katello-packaging into 
> foreman-packaging, but it didn't reach a conclusion. The general opinions 
> were in favour but there might be space and traffic constraints when actually 
> building the packages.
> 
> My proposal is to revive this effort. Given the practical constraints are 
> related to the hosting it makes sense to me to start with just merging the 
> git repositories. Is it possible to do the builds from a single git 
> repository and end up on different servers for now?
> 
> If that's possible, we can look at finding proper hosting and which yum 
> repositories we should offer.
> 
> # katello modules -> theforeman namespace (including modulesync)
> 
> Right now we have a foreman-installer-modulesync[6] and 
> katello-installer-modulesync[7] to maintain the base layout of modules.  
> These are all very similar and with little effort we can maintain all modules 
> with the same layout.
> 
> The bigger impact is that we need to migrate all modules at least on the 
> github level to the theforeman github namespace. It also implies that when 
> you make changes to modulesync that needs to be applied to about double the 
> modules which can be more effort. The upside is that the overall quality will 
> be higher.
> 
> If this all works well we can look at moving the katello modules to the 
> foreman namespace on the Puppet forge as well but I think that benefit is 
> smaller and will take effort on the (direct) users since the forge doesn't 
> support redirects.
> 
> # katello-installer -> foreman-installer
> 
> Currently the katello-installer[8] builds on the foreman-installer[9] with 
> additional modules and scenarios. Sometimes the katello build breaks on 
> dependencies and then the cache gets out of sync with the foreman thus 
> breaking on older builds as well.
> 
> I'd like to merge this in a single installer with one set of modules and 
> multiple scenarios. The impact is that the installer will be bigger but the 
> katello-installer should be less fragile. It can also simplify packaging.
> 
> Care will need to be taken that the needed repositories are present but there 
> are multiple ways of fixing this. Currently we assume the user has installed 
> the katello release RPM which enables the needed yum repositories but that 
> will not be true anymore if we ship it within foreman-installer.
> 
> We'll also want to remove/disable the katello scenarios on Debian/Ubuntu.
> 
> You may notice I haven't thought this through too much and it may depend on a 
> unified Yum repository structure but there are big usability and reliability 
> wins we can gain.
> 
> [1]: https://github.com/theforeman/foreman-bats
> [2]: https://github.com/theforeman/forklift
> [3]: https://github.com/theforeman/foreman-packaging
> [4]: https://github.com/katello/katello-packaging
> [5]: https://github.com/theforeman/foreman-packaging/pull/1541
> [6]: https://github.com/theforeman/foreman-installer-modulesync
> [7]: https://github.com/katello/foreman-installer-modulesync
> [8]: https://github.com/katello/katello-installer
> [9]: https://github.com/thefore

Re: [foreman-dev] Looking for facts from big servers

[Timo Goebel]

Hi,

Thanks to my co-worker Till: Here you go.
https://gist.github.com/timogoebel/11a928f297fbef98f15b643612a9d6e6

Facts from a VM with lots of CPU and memory and a physical host with some 
harddisks. Hope, that helps.

Curious to see some screenshots. Discovery UI refresh is long overdue. :-)

Timo

> On 3. Jul 2017, at 15:51, Lukas Zapletal  wrote:
> 
> Hey,
> 
> we are redesigning UX of the discovery pages and I was wondering if
> you can send me output of facter from some big fat servers. Looking
> for extremes, servers with:
> 
> - lots of CPUs or cores
> - lots of memory
> - lots of disks or volumes
> - or other periciphals
> 
> The command output we are interested in is:
> 
> facter --no-custom-facts --json
> 
> Please pastebin and send to the list or directly to me, thanks! The
> purpose of this is to import these into foreman and see how it will
> look like with the new UX design. We don't have anything yet, but we
> would like to replace the table view with something better, stay
> tuned.
> 
> -- 
> 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] Nomination for an additional GitHub org owner

[Timo Goebel]

+1 for both Eric and Greg. Keep up the good work.

> On 29. Jun 2017, at 13:05, Daniel Lobato Garcia  wrote:
> 
>> On 06/29, Tomer Brisker wrote:
>> Well, how about our fearless community leader?
>> Makes sense to me that managing the community includes the github repos
>> when needed - adding maintainers, migrating repos etc.
>> I nominate Greg Sutcliffe to be another owner of the git org as he is
>> available in European times.
>> ​Greg has been an active member, contributor and maintainer for quite a few
>> years now and should have no problem helping out with these tasks.​
>> 
> 
> +1 too.
> 
> (also to Eric's ownership, there were just too many +1s I don't think
> mine would've made any difference)
> 
>> 
>> On Mon, Jun 26, 2017 at 4:41 PM, Greg Sutcliffe 
>> wrote:
>> 
 On Mon, 2017-06-26 at 10:25 +0300, Tomer Brisker wrote:
 +1 to adding Eric, although that won't solve the issue of Ohad and
 Dominic being busy and having no owner available on this side of the
 globe.
>>> 
>>> That's fair, do you want to start a new nomination thread to address
>>> that? :P
>>> 
>>> 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.
>>> 
>> 
>> 
>> 
>> --
>> 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.
> 
> --
> Daniel Lobato Garcia
> 
> @dLobatog
> blog.daniellobato.me
> daniellobato.me
> 
> GPG: http://keys.gnupg.net/pks/lookup?op=get&search=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 email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Proposal to move "How to create a plugin" page to github.

[Timo Goebel]

Am 22.06.17 um 11:16 schrieb Greg Sutcliffe:

+1 for moving the plugin documentation to the plugins part of the
website. I think that makes sense, and we can (as with other areas)
keep the wiki for footnotes, edge cases, and tips.

Greg

I'd suggest to add a Markdown file to the core repo. I believe code 
documentation is better suited to be in the code repo and the 
documentation can be reviewed alongside the code change in core by core 
maintainers. The website should be more for foreman users. But 
theforeman.org is fine with me as well.


- Timo

--
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] Re: Unit test jenkins job with all plugins enabled

[Timo Goebel]

Am Donnerstag, 1. Juni 2017 12:17:49 UTC+2 schrieb Lukas Zapletal:
>
> I would like to open discussion about having a unit test job of 
> foreman with all major plugins enabled (katello, discovery, bootdisk, 
> rex, openscap).
>

 What would be all the major plugins? Expire Hosts? Digitalocean? Omaha?

The list gets quite long easily. How about making it a responsibility of a 
plugin to make sure it actually works? If as a maintainer of the omaha 
plugins I want a nightly job to test the plugin with more plugins enabled, 
nobody stops me from setting one up.
I'd also disable the katello ci job in core to be honest. It should not be 
the responsibility of core to make sure specific plugins work, but the 
responsibility of the plugins.
I think, it would be a better approach to have a nightly job that tests the 
"Satellite 6" configuration to check if everything still plays nice 
together.

- Timo

-- 
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] Moments of Coffee Meeting: Fog and Compute Resrouces NG

[Timo Goebel]

> On 22. May 2017, at 12:27, Ohad Levy  wrote:
> 
> Since we get a lot of lift from fog, especially for popular providers (e.g. 
> ec2) IMHO its not a good idea to remove fog, which means that we balance 
> between community contributions to fog (e.g. stuff we won't "enjoy" as we 
> will not corporate) vs other benefits mentioned above. 
> 
> I for one, is not convinced the effort to not run with fog is less work then 
> adding / updating a fog provider.
> 
> Ohad

I do agree with Ohad here. I'd focus on improving the fog-providers and not 
trying to reinvent the weel.
I think, "cloud" topics like focussing on real server orchestration (think 
hostgroup as an auto scaling group) adds more benefits for a user. A user 
usually doesn't care about the library used. Using foreman as a tool to setup a 
cloud or container environment on bare metal does add value.

Fog doesn't do any network orchestration, yet. If we add this (e.g. provision a 
vlan on a switchport or some SDN), that would be a valid point imho to switch 
the library.

- Timo

-- 
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] vmware html5 console support

[Timo Goebel]

Am Montag, 8. Mai 2017 18:27:58 UTC+2 schrieb Michael Eklund:
>
> I would be happy to help with testing.  IMO this is a killer feature.
>

I created some code to test this. [1] Unfortunately pre-authentication does 
not work with vsphere > 6 as it always requires SSO.

Great idea, but it does not work.

Timo

[1] https://gist.github.com/timogoebel/c8a915dc4fae9b79c8733cc7a2796038

-- 
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] vmware html5 console support

[Timo Goebel]

Mike,

This sound very interesting. If I got that right, you can even gerate a 
pre-authenticated console url that is valid only once. [1]


Foreman could use the compute resource's permission to generate such a 
link and then redirect the user to that url without leaking the compute 
resource's credentials.


If you're fine with this and time allows, I'll try to create a PR for 
this. Would you be able to test this?


Timo

--
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] HTTP proxy for requests

[Timo Goebel]

Hi,

Am 20.04.17 um 13:06 schrieb Sebastian Gräßl:
How common is a setup where external resources requiring HTTP are used 
with Foreman behind a HTTP proxy?


I believe, this is very common in enterprise environments. Usually any 
internet access is blocked for security reasons and only connections via 
a proxy server are allowed. The proxy ususally does a MITM attack to be 
able to investigate encrypted traffic. While this does make sense in 
some cases, don't get me started why it does not make any sense in others.



Comments?


I think especially access to all the docker registries out there is 
something a corporate it-security team would want to go through a proxy 
server. Setting a proxy server on a server via environment variables 
(http_proxy) is quite easy with systemd unit files. However that may 
lead to problems when the client doesn't respect the 'no_proxy' 
environment variable and suddenly all requests to a smart proxy are 
routed via the http proxy. This is problematic when smart-proxy is on 
the same network and not reachable via the proxy server.

I personally prefer only to have an explicit option in a settings file.

- Timo

--
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] Unify date format in Foreman and plugins

[Timo Goebel]

Am 12.04.17 um 18:21 schrieb Ewoud Kohl van Wijngaarden:

On Wed, Apr 12, 2017 at 06:02:34PM +0200, Marek Hulán wrote:

Thanks guys so far, I'm sending comments below in text that are also relevant
for lzap's comments in previous email.

On středa 12. dubna 2017 16:56:52 CEST Ewoud Kohl van Wijngaarden wrote:

I second that there are cases where "ago" is preferred. For the last
puppet run on the host page it's much easier to know if it was an hour
ago. Then I don't have to try and remember what day and time it is.
However, in a table of all puppet reports then the exact date is the
correct unit. The table of reports with a list of "about 1 month ago"
has been an annoyance

I agree that sometime it's more convenient. On reports page it might be
interesting only for reports that arrived withing last few hours though. IMHO
the consistency is the key here, I'd like to avoid showing 15 minutes ago for
times < few hours and full info for the rest. Most of reports on the page
(older than few hours) would benefit from the full format. Therefore I think
full format with "ago" information as tooltip might be the best compromise?

On the reports (where you see multiple) then I think the "ago" format
isn't useful because the granularity is too low so it's hard to compare.
IMHO in a list they should all have the same format. On a host page
where you see "Last report: 1 hour ago" it does make sense. I hope that
clarifies it.


I totally agree. Let's not drop the "time ago in words" format entirely. 
It does make sense in a lot of places, especially reports or 
certificates or when a host was created. As a user you probably don't 
care for the exact time. You just want to know approximately when it 
happened.
E.g. when you push new puppet code to your production servers and start 
to get calls that something is broken, it's enough to know that there 
are puppet reports that indicate a change happend to your servers within 
the last hour. As puppet runs happen, when they happen (and the time 
when puppet applies changes is hard to predict) an exact timestamp isn't 
useful as your cluster slowly starts to degrade over time.


- Timo

--
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] Foreman Icon Usage Guideline Proposal

[Timo Goebel]

Looks good to me. +1
I'm wondering if we could add proposed items to indicate that something is 
activated / deactivated. 

- Timo

> On 13 Mar 2017, at 04:45, June Zhang  wrote:
> 
> HI, All
> 
> Recently I have been working on the Foreman Icon Usage Analysis and created a 
> proposal for the icon usage.
> In this proposal, we addressed some things as following:
> 
> 1, Icon usage guideline - Icons must first and foremost communicate meaning 
> in a graphical user interface
> 2, Proposal for when to use icon alone - Icons alone should only be permitted 
> when at least two out of the following three conditions apply
>* Space is very limited (i.e., too small for text alone).
>* The icons are mostly universal recognition from users (e.g., Home, 
> Search, Edit)
>* The icon represents an object with a strong physical analog or a visual 
> attribute (e.g., a printer icon to access printer attributes).
>   Tooltips are required for icons when they are used alone.
> 3, Proposal for when to use icon+label, and label alone
>* If space allows, icons combined with text is best. Selective use of 
> icons with text makes certain items stand out more or add visual interest. It 
> may also improve the scanability of the items.
>* As mentioned in the previous page, Icons must first and foremost 
> communicate meaning, if there is an icon that can deliver this meaning, then 
> we will use Icon+Label, if not, use Label alone.
> 4, Proposal for how to use icon
>* In a button group, it should keep consistent for all buttons with or 
> without icons.
>* Not suggest to use icon on the navigation menu ( nav bar, tab ) unless 
> adding the status icons such as warning or error icons.
> 5, Proposal for some common icons in Foreman
> 6, Proposal for some status icons in Foreman.
> 
> The detail information is in the PDF file, please have a review.
> Before I begin to work on the next action[1], I’d love to get everyone’s 
> feedback.
> 
> [1]Next action: 1, Create xwiki page for the guideline
>2, Send PR to fix the inconsistent icon with PatternFly
> 
> Thanks
> June - UXD Team
> 
> 
> 
> -- 
> 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] Hosting katello repos on yum.theforeman.org

[Timo Goebel]

Am 09.03.17 um 17:54 schrieb Greg Sutcliffe:

I do think bandwidth/traffic may be an issue, as we already (I believe)
consume a large proportion of our Rackspace budget on the existing packages.


If that's the only reason we're not doing it, I'd consider using 
cloudflare.com as a (free-of-charge) CDN.


I personally are in favor of hosting Katello on yum.theforeman.org. I 
think, it's a (small) step in bringing Katello closer to being a proper 
plug-in. For users it'd be much easier to know which Katello version 
belongs to which Foreman version.
I believe that if we find a way to install Katello on top of an existing 
Foreman install, we can increase Katello's userbase and community 
support. By allowing users to install just a subset of Katello's plugins 
we can incease the chances even more. This still requires some effort, 
but let's do first things first.

Thanks for doing this.

- Timo

--
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] Re: Seeding templates overrides custom changes - should we lock templates we ship?

[Timo Goebel]

+1 to locking. This is the only workflow that makes sense imho.
Please note, that we need [1] merged first.

- Timo

[1] https://github.com/theforeman/foreman/pull/4283

Am Freitag, 17. Februar 2017 15:05:13 UTC+1 schrieb Marek Hulán:
>
> Hello foreman-devs, 
>
> recently I was told about the bug that we override all templates in 
> database 
> whenever we run db:seed. From the code [1] and commit message [2], it was 
> not 
> the intended behavior. It was supposed to check whether user made some 
> changes 
> and only apply the new version if the template was not touched. Sadly, the 
> method only checks the name attribute for changes [3], so if "only" 
> template 
> content was changed, we still override it. 
>
> While I can try to fix it to originally intended behavior, I'd like to ask 
> whether it wouldn't be better to use this opportunity and start locking 
> templates we ship by default. The recommended workflow for users would be 
> to 
> clone the template if custom changes are needed. We'd always update locked 
> templates. Obviously, user would need to merge new version to cloned 
> template 
> on his own. With foreman_templates plugin it should be easy enough to 
> export 
> templates and see the diff between default and customized template, apply 
> the 
> changes user wants and then reimport them back. 
>
> I think this would be overall better user experience and safer workflow. 
> The 
> originally intended behavior would never update a template that user 
> modified. 
> That means after update user ends up with template from old Foreman 
> version 
> (with custom changes) that might not be compatible with the new Foreman 
> version. This is more likely to happen than before because we now version 
> templates in community-repo and we don't keep backward compatibility as we 
> did 
> before. 
>
> Thanks for reading, thoughts? 
>
> [1] 
> https://github.com/theforeman/foreman/blob/1.14.0/db/seeds.d/07-provisioning_templates.rb#L98
>  
> [2] https://github.com/theforeman/foreman/commit/ 
> d4ed70154fa9f6c83597adc784240e3865845563 
> 
>  
> [3] https://github.com/theforeman/foreman/blob/1.14-stable/db/seeds.rb#L33 
>
> -- 
> 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.

Re: [foreman-dev] Plugin to update existing view - need help

[Timo Goebel]

Anthony,

I have replied on your github issue for this and proposed a workaround 
for this.


https://github.com/achevalet/foreman_openstack_v3/issues/1

- Timo


Am 06.02.17 um 16:25 schrieb Anthony Chevalet:

Hello,

I'm working on a plugin to support openstack v3 which can be found at 
https://github.com/achevalet/foreman_openstack_v3.
Initially I've patched foreman (see pr #4254 
) then I decided to 
write a plugin so that it can be available faster and back-ported to 
older releases.


I'm able to override the default provider model but it still uses the 
built-in form (app/views/compute_resources/form/_openstack.html.erb)
I've tried to update the compute resource controller (ie Add New 
Controller Action 
 
or Extending a Controller  or Add New View 
) 
or also using deface 
without 
success.


My current (dirty) workaround is to rename the built-in form 
(app/views/compute_resources/form/_openstack.html.erb.ori) and create 
this file at the same location within the plugin.
I'm wondering if there is a way to change the search path of the forms 
to have the plugin directory before the built-in one?


Or any other solution?

Any help would be much appreciated.

Cheers,
Anthony

--
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 idea: Templates rendering only through Proxies

[Timo Goebel]

Hi,

> our design of template proxying is not good

I don't think, it's that bad. Your suggestion does have it's advantages, 
though. From a security perspective it would be great if the smart-proxy 
wouldn't need any calls to Foreman.


> The downside is that Smart Proxy would be required in order to do 
templating


If we pre-render all templates in Foreman and just deploy text files to 
the proxy, why do we need templating on the proxy?


> There should not be any technical limitation, unless I miss something.

How do you want to handle the "built"-Url? I think, you still need a 
callback to Foreman when a Host has finished provisioning. That 
basically voids most of the advantages (like improving reliability - 
btw: a Foreman ha is easy vs. a smart-proxy ha setup is hard).
We currently setup puppetca orchestration when a Host requests the 
provisioning template. That would need to be changed first. Please see [1].


I do think, it's a good idea that Foreman knows the current state of an 
installation. We could even show valueable information on the 
provisioning progress or potential errors like with [2]. That would be a 
huge benefit for users, at least from my experience.


Timo

[1] https://github.com/theforeman/rfcs/pull/7/files
[2] https://github.com/ShimShtein/foreman_build_history

--
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] HoundCI - annoying?

[Timo Goebel]

Hi devs,

I'm usually not very easily annoyed. What get's me started though 
eventually is when things don't work properly.
HoundCI is one of those things.

My main concern is, that I get an e-mail and/or Github notification for 
every single comment. These can easily be ten or more e-mails. They're not 
grouped as other reviews.
In addition, the inline comments are very distracting when reviewing a PR 
imho. When the issues are fixed, I'd prefer for the comments to be removed.
When reviewing a PR, I usually don't care about the style issues. I just 
want to see if there are some problems or if all is fine.

Back in the days, code style was checked by Jenkins. I think, it did a far 
better job in displaying style issues. With the current Jenkins Github 
plugin it believe would be easily possible to show style issues as a 
separate line along with all the other CI checks.

One argument in favor of HoundCI is, that it checks JavaScript style. But I 
think, that can easily be set up in Jenkins as well by running eslint.

Any comments? How do others feel?

Timo

-- 
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] Re: Stateless DHCPv6

[Timo Goebel]

Perry,

Am Dienstag, 20. Dezember 2016 16:20:53 UTC+1 schrieb pga...@redhat.com:
>
>
> Will Foreman's provisioning support allow for "stateless" DHCPv6 described 
> here: https://tools.ietf.org/html/rfc3736
>
> Essentially the idea is the address assignment and routing info is left up 
> to SLAAC or manual configuration, and the DHCP server provides "stateless" 
> configuration like DNS, etc.  
>
> My question is how well this might work with foreman's process of 
> configuring the boot image info when doing host builds. 
>

Right now, this might be the only way DHCPv6 is working with Foreman. 
Foreman currently has no knowledge of DHCPv6 at all. The installer modules 
do not configure DHCPv6 at all.
What currently works is that Foreman can either set an IPv6 address 
manually or it can pick up an IPv6 address assigned via SLAAC through 
puppet facts. As it gains knowledge of the IPv6 address after the 
provisioning phase in the latter case, it cannot provision a DNS 
-record during provisioning of the host.

This basically limits IPv6 in Foreman to a dual-stacked network. IPv6 only 
PXE installations are currently not supported because that would require 
DHCPv6.
Foreman has an IPAM mode that basically does the same calculations as SLAAC 
to get an IPv6-address based on the mac address of a host. If you choose 
that mode, it can also deploy a -record during host provisioning.

I hope, this helps. Let me know if anything is still unclear or you need 
more information.

-- Timo 

-- 
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] Diploma projects - need ideas

[Timo Goebel]

Am 05.10.16 um 14:55 schrieb Ewoud Kohl van Wijngaarden:

On Wed, Oct 05, 2016 at 08:35:49AM -0400, Bryan Kearney wrote:

On 09/29/2016 11:57 AM, Lukas Zapletal wrote:

Hello,

few students of mine are considering doing Diploma Thesis for Red Hat.
Can you figure out some good Foreman topics? Unfortunately, it looks
like today UNIX and datacenter administration is uncool, as I have
learned the other day, so ideally they are looking for:

- JavaScript and UI/UX
- web app development in general
- mobile programming
- iOS / macOS / Swift (need to google that one out)

Ideal task is something isolated, that can be done as a different
project or plugin. Send me your ideas, thanks!


Some ideas I can think of...

A question I would have out to the community, what type of
reports/graphs/dashboards do your bosses like to see? Is there some sort of
visualization that, if included with the tool, would be useful for you to
have? This type of graph/eye candy may be good ideas here.

Maybe, something akin to:

Draw out the server, smart proxy, and all services. So I can generate a
picuture which shows this box has the server, which talk to that box with
the proxy, which in turn communicates with a DHCP server at XXX.

Around networks I think there's a great deal to be won. For example an
overview of networks and their usage (192.168.1.0/24 has used 60% of its
IPs), maybe a map of all subnets though currently Foreman doesn't track
routing.

I agree. There should be a "show" page for a Subnet that displays such 
information.
I have actually started a PR that adds usage statistics [1] to the 
subnet index page, but never got around to properly implement the 
smart-proxy side to work with all dhcp providers. A student could take a 
look at professional IPAM solutions and try to add the missing features 
to Foreman.


I talked to one of our network engineers yesterday and he asked if it 
would be possible to use Foreman to Manage network devices like switches 
or routers via Ansible. How great would it be if network devices were a 
first class citizen in Foreman? Foreman clould then be used as a source 
for dynamic inventory and show reports.


For reports/graphs we would really like to see a graph of the host count 
for capacity planning. Or the utilization of our hypervisors. It would 
also be great to have Foreman calculate and show the costs of a VM. In a 
cloud environment the costs are easy to calculate. But for an on-premise 
deployment that's harder.


Another field of ideas is the permissions system. I think, it should be 
possible to add CRUD permissions for Host Objects, e.g.:
I want a user to view all subnets, but only create hosts in two specific 
subnets. I believe, this is not possible right now and could be 
implemented in a Diploma project.

Or maybe a proper self-service.

Or what about managing SDNs or firewall rules with Foreman? Foreman 
could then orchestrate your network when a new host is deployed. Though 
I haven't tried it, I believe MAAS [2] from Ubuntu can do something 
similar for switches and bare-metal.


Timo

[1] https://github.com/theforeman/foreman/pull/3514
[2] http://maas.io/

--
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] Expanding Slave Capacity

[Timo Goebel]

Am 31.08.16 um 10:09 schrieb Dominic Cleal:


Thanks for the offer, I'd gladly take you up on it.

Similar specs to the current one would be great, but more disk space if
possible - the usage is increasing.
http://projects.theforeman.org/projects/foreman/wiki/Jenkins#Slave-requirements
lists current specs.

A regular EL7 installation with my SSH key
(https://m0dlx.com/ssh_redhat.pub) installed for root would be enough
for me to set it up.


I've setup another slave. Hope, it helps a little.

tfmslave01.timogoebel.net

You should be able to login with root and your ssh key.

I've already run the steps listed on [1]. The system is currently 
waiting for a puppet certificate. Dominic, do you cover the rest?



Timo


[1] 
http://projects.theforeman.org/projects/foreman/wiki/Jenkins#Slave-requirements


--
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: Automate IP allocation over specifying subnets in machine creation

[Timo Goebel]

On 31.08.2016, at 12:45, Lukas Zapletal  wrote:

>> BTW I also tried to work with the API of "Free IP" but couldn't managed to 
>> authenticate properly, can you give me an example of how to use it?
>> that way we could use the workaround I spoke of before...
> 
> The proxy API directly? That's not possible, unless you use HTTP client
> certificate. Sign it with your puppet ca and use it if you want.

... you can also get a free ip via Forman's API, without calling the proxy 
directly. Do you need any help doing that? I'm just not sure if support was 
added in 1.12 or 1.13. :-)

-- 
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] Jenkins slaves not responding

[Timo Goebel]

Dominic,

> On 31.08.2016, at 09:43, Dominic Cleal  wrote:
> 
> The slave that I attempted this on crashed within a day, so they'll
> remain on two slots each.

Do you know why these crashes happen? Are there any monitoring graphs, that 
show cpu/memory usage over time? The issue sounds like a oom problem judging 
from what i read here. Do you see anything related in the system's logs?

Timo

-- 
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] Call for help: Installer changes for UEFI

[Timo Goebel]

Lukas,

> On 26.08.2016, at 10:41, Lukas Zapletal  wrote:
> 
> 
> if Debian is found then
>  download 
> http://ftp.debian.org/debian/dists/jessie/main/installer-amd64/current/images/netboot/debian-installer/amd64/bootnetx64.efi

I think, we should not depend on downloads from the (evil/firewalled) internet.
What do you think of packaging this?
We should at least make the mirror url configurable.

-- 
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] Development of new plugin - assets

[Timo Goebel]

> On 04.07.2016, at 09:00, Dominic Cleal  wrote:
> 
>> On 04/07/16 03:00, Matthew Ceroni wrote:
>> I am attempting to develop a plugin.
>> 
>> The main functionality of the plugin is going to be to automatically set
>> the Virtual machine network based off the subnet set on the interface
>> tab. The initial version would just match the name set in the interface
>> tab to the name of the network on the virtual machine tab. Future
>> versions might take a config file to set that mapping.
>> 
>> I believe the change should be pretty simple, just run a javascript
>> function onchange when the subnet is selected. Therefore I need to
>> include a new javascript (asset) on the host edit page. I see that
>> plugins such as foreman_salt and foreman_bootdisk do just that. In my
>> plugin I created a new asset and created the javascript file. However I
>> am not sure how to tie that asset to the host edit page.
> 
> Using the Deface gem (https://github.com/spree/deface) is perhaps the
> easiest method, which will allow you to inject the following into the
> page template:
> 
>  <% javascript "foreman_example/your_asset" %>
> 
> Add deface ~> 1.0 as a dependency to the plugin, then create a file
> under app/overrides/ containing something like:
> 
>  Deface::Override.new(:virtual_path => "hosts/_form",
>   :name => "foreman_example/js",
>   :insert_before => "erb[loud]:contains(:javascript)",
>   :text => "<% javascript
> "foreman_example/your_asset" %>")
> 
> Untested, but the idea is that will match the <%= javascript %> at the
> top of app/views/hosts/_form.html.erb and insert your own line there.

You can also have a look at the forman_expire_hosts plugin as an example. The 
plugin injects an js asset via deface to the host show page.

-- 
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] Re: Re: Re: Nominating Timo Goebel for theforeman/foreman commit access

[Timo Goebel]

Thanks for trusting me with this and for all your support. I'm happy to 
work even closer with you guys and that we all have an aweseome Open 
Source experience.


Cheers from Germany!

Timo

Am 10.06.16 um 11:30 schrieb Daniel Lobato Garcia:

On 06/07, Daniel Lobato Garcia wrote:

Reminder - 2 days left if you have any objections or comments!

Done! Welcome to the core team and may Jenkins help you with your code
reviews :)


On 06/02, Daniel Lobato Garcia wrote:

Hi devs,

I'd like to nominate Timo Goebel (timogoebel on Github & IRC) for commit
access to theforeman/foreman repo.

He's been contributing to the puppet modules, community-templates, bootdisk
and Foreman for some time, particularly on the VMWare/vsphere side of things.
He's been running Foreman on production for years already and gave
local talks about it.(www.meetup.com/AWS-Meetup-Karlsruhe/events/229036956/)

Most importantly and the reason why I thought of him as a person that
could become a committer is his involvement on ipv6 support lately,
where he's been submitting consistently good code.

I think he understands very well the problem domain, and he will be
committed to maintain and improve the code quality of the project, as
well as providing good feedback from a production installations.

Some examples of his contributions:

https://github.com/theforeman/foreman/pull/3420
https://github.com/theforeman/foreman/pull/3424
https://github.com/theforeman/foreman/pull/3498
https://github.com/theforeman/foreman/pull/3499
https://github.com/theforeman/foreman/commit/5131edbfab258c0862c987f238049ee81a1cd13f
https://github.com/theforeman/foreman/commit/8ca6c6bbc5242c29a8039d1e6a1d09d1a454164c
https://github.com/theforeman/foreman/commit/2328beb569d3f0e51043202d3a00a3b30879d244
https://github.com/theforeman/puppet-puppet/pull/389
https://github.com/theforeman/foreman_bootdisk/pull/19

Lastly I'd encourage him to start reviewing already!

Objections or comments in private are welcome, but public replies to this
thread are preferred :)

Best,

--
Daniel Lobato Garcia

@dLobatog
blog.daniellobato.me
daniellobato.me

GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato



--
Daniel Lobato Garcia

@dLobatog
blog.daniellobato.me
daniellobato.me

GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato



--
Daniel Lobato Garcia

@dLobatog
blog.daniellobato.me
daniellobato.me

GPG: http://keys.gnupg.net/pks/lookup?op=get&search=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.