Re: Re: [foreman-dev] Revert removal of @host.params for host_param
I don't think it causes any problems. I don't see the reason why the whole commit should be reverted. If something then perhaps deprecation warning could be removed. I'd still prefer communuty-templates using macros instead of internal objects. -- Marek Odesláno pomocí AquaMail pro Android http://www.aqua-mail.com Dne 13. ledna 2017 18:27:13 "Sean O'Keeffe" napsal: 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&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
Re: Re: [foreman-dev] Revert removal of @host.params for host_param
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&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 forema
Re: [foreman-dev] Community template repository labels
If this will help with getting reviews or directing reviews then sounds all good. The bot could handle this afaik as long as they are predictable which is which. On Jan 12, 2017 6:26 AM, "Ewoud Kohl van Wijngaarden" < ew...@kohlvanwijngaarden.nl> wrote: > Hello all, > > Since there are multiple types of templates in community templates, I > wonder if it's time to (automatically) attach labels to PRs. I was > thinking: > > * Remote exection > * Provisioning > > Maybe we need to split up Provisioning into a label per distro. > > Any thoughts on this? Can the foreman bot be easily modified to do this > for us? > > -- > 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] Draft community survey questions
Thanks all, and sorry for the delay. Some inline comments and the final
draft attached separately :P
Ori Rabin wrote:
Maybe the question: How would you rate our user support? can have links
instead of bringing back the do you know our IRC question?
I like that, added.
Tomas Strachota wrote:
+1 for the raffle. It motivates you to respond even on the last day of
the survey.
Good point.
How about raffle for the foreman t-shirts? Or is it too
common and everybody already has one from conferences?
They (and stickers) are what we give out for free, and seems somewhat
stingy :)
I have a budget for a couple of decent items, 2 or 3 depending on price.
The question is what? It needs to be something available in multiple
countries (because that is likely cheaper than shipping from elsewhere),
a nice thing to win, and relevant to us. My current thinking is
something like a RaspberyyPi3 / oDroid / etc for running your own ARM
Foreman server on :P - thoughts?
Neil Hanlon wrote:
+1 for raffle and contributor survey. (I don't have a t-shirt...
Yet...)
Let me fix that for you - ping me an address and size :)
In general, it's been my experience that people who are going
to complete surveys will complete them regardless of length. By
that I mean most people won't be swayed into doing a survey because
it's short unless they already planned on completing it going in.
I know everyone is busy, but 15 minutes for something most users
probably
use multiple times a day isn't really that much to ask.
That's a great point. I've converted the draft to a multi-page format,
and tidied up the group to something which I hope is logical. It's also
enabled me to re-add many of the things I dropped due to trying to be
brief.
Ohad Levy wrote:
can we take back the input from Shlomi's tread about what people are
annoyed by, break it into categories, and have a question
Originally I wanted to leave this as an open text field ("what needs
fixing?") but I think we can combine it. I've added a few suggestions
from the thread and an Other box too.
Eric D Helms wrote:
Some question in line below. Could we add some questions around smart
proxies? I don't know that I have any idea about:
Great point. Page added for Proxies, and since it's short I put the
Hammer and API questions there too.
The plugin question would cover which configuration management project
users use, but it wouldn't indicate Puppet usage and Puppet 3 vs
Puppet 4 usage in our ecosystem. A question around those two might be
useful.
I added just one, but if there's more sing out.
+! to splitting out the OS distros into versions (e.g. RHEL6, RHEL7,
Fedora 24, CentOS 6, Debian Jessie) as that gives us a better idea of
where to focus and may help some plugins decide on what they want to
focus their support on.
Done.
Would it be worth asking an open ended question about what users pain
points are? I suppose the foreman-users post did this but still might
be worth it in the official survey.
Added as part of the final "What else would you like add?" question to
highlight pain points are definitely worth mentioning.
Something to consider to help Katello developers would be a question
around how many users do not currently manage content but plan to in
the future. You could perhaps ask this more broadly about plugins that
users plan to add to their environments.
That's a good question. The plugin page is already huge, so I wonder if
it makes more sense in the "wrap-up" section? For now, I've added an
open question to the main first page.
Do you Use Locations / Organization features?
Why drop this question? Given how hotly some developers discuss this,
I think this is valuable data.
I don't think there's anything new here. We gathered good feedback which
(to me) confirmed that moving to a tag-based system wouldn't break many
(if any) setups. Simply asking the same broad question again won't
extend that, I don't think - but if you've got something more specific
you'd like to ask, I can add it.
I'm mocking this up in Google Forms at the moment, but the markdown is
attached. I'll publish next week if there are no major concerns :)
Gre
--
IRC / Twitter: gwmngilfen
Diaspora: gwmngil...@joindiaspora.com
--
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.
# Draft Survey
## Page 1 - Foreman Core & Support
How long have you been using Foreman?
* 3 months
* 6 months
* 1 year
* 2 years
* 3+ years
How many people use Foreman in your organization
* 1-4
* 5-9
* 10-49
* 50+
What Foreman version are you using?
* nightly
* 1.14
* 1.13
* 1.12
* older
How many nodes do you manage with Foreman?
* 0-9
* 10-49
* 50-199
* 200-499
* 500-999
* 1000-
* 1-1
* 2+
What operating system do
Re: [foreman-dev] HoundCI - annoying?
On 01/11, Timo Goebel wrote: > 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. I don't think it did a better job displaying the issues. I do remember having to point up people to the exact jenkins page where rubocop failures showed up, as it wasn't immediately obvious what happened. Inline comments show new contributors what's failing right there. That was my motivation for using Hound, also Javascript linting and saving us the trouble of having more jobs in jenkins was also a nice side benefit > > 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. -- 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. signature.asc Description: PGP signature
Re: [foreman-dev] ERROR: Cannot find rabl template 'katello/api/v2/content_facet/base_with_root'
On 01/12, Daniel Kuffner wrote: > Hi All, > > Does anybody know how to fix the issue? I also saw it - https://github.com/Katello/katello/pull/6541 > > The template seems to exist: > > /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.2.1.1/app/views/katello/api/v2/content_facet/base_with_root.json.rabl > > > > *Issus:* > > Cannot find rabl template 'katello/api/v2/content_facet/base_with_root' > within registered (["/usr/share/foreman/app/views"]) view paths! > > *RuntimeError* > *Cannot find rabl template 'katello/api/v2/content_facet/base_with_root' > within registered (["/usr/share/foreman/app/views"]) view paths!* > /opt/theforeman/tfm/root/usr/share/gems/gems/rabl-0.12.0/lib/rabl/sources.rb:24:in > `block in fetch_source' > /opt/theforeman/tfm/root/usr/share/gems/gems/rabl-0.12.0/lib/rabl.rb:60:in > `source_cache' > /opt/theforeman/tfm/root/usr/share/gems/gems/rabl-0.12.0/lib/rabl/sources.rb:10:in > `fetch_source' > /opt/theforeman/tfm/root/usr/share/gems/gems/rabl-0.12.0/lib/rabl/partials.rb:12:in > `partial_as_engine' > /opt/theforeman/tfm/root/usr/share/gems/gems/rabl-0.12.0/lib/rabl/engine.rb:283:in > `partial' > (eval):45:in `block (2 levels) in eval_source' > /opt/theforeman/tfm/root/usr/share/gems/gems/rabl-0.12.0/lib/rabl/builder.rb:152:in > `call' > /opt/theforeman/tfm/root/usr/share/gems/gems/rabl-0.12.0/lib/rabl/builder.rb:152:in > `node' > /opt/theforeman/tfm/root/usr/share/gems/gems/rabl-0.12.0/lib/rabl/builder.rb:114:in > `block in compile_settings' > /opt/theforeman/tfm/root/usr/share/gems/gems/rabl-0.12.0/lib/rabl/builder.rb:113:in > `each' > /opt/theforeman/tfm/root/usr/share/gems/gems/rabl-0.12.0/lib/rabl/builder.rb:113:in > `compile_settings' > > > Packages: > foreman-release-scl-3-1.el7.noarch > foreman-installer-katello-3.2.3-1.el7.noarch > foreman-1.13.3-1.el7.noarch > > > thank you, > Daniel > > -- > 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. signature.asc Description: PGP signature
Re: Re: [foreman-dev] Revert removal of @host.params for host_param
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&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. signature.asc Description: PGP signature
Re: [foreman-dev] .ISO deploys with Discovery
+1 from me - image deployment for hardware makes sense IMO. It's definitely something others have been thinking about - I'll leave Lukas to go into more detail, but here's something you could go take a look at :) https://github.com/theforeman/foreman-discovery-image/pull/44 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.
