Re: [foreman-dev] Proposal: Let's make notifications optional

[Tomas Strachota]

On Wed, Dec 20, 2017 at 9:09 AM, Ohad Levy  wrote:
>
>
> On Wed, Dec 20, 2017 at 10:07 AM, Lukas Zapletal  wrote:
>>
>> Hello,
>>
>> while I agree that notifications is useful feature to our users, its
>> one second polling mechanism is killing me during development, it
>> makes watching logs or debugging sessions a nightmare.
>>
>> I propose an Administer - Setting option to completely turn it off -
>> no notification bell icon, no polling. If there is someone who things
>> users should not be given this option, let's make this an
>> environmental variable.
>>
>> Opinions?
>
> 1. a Global setting, followed by a user setting sounds sane to me.
> 2. do you know that there is a global env already? just run:
>
> NOTIFICATIONS_POLLING=100 foreman start

Great, I didn't know that.

Polling annoys me in development as well, but this env variable is
enough for me. Thanks!

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

Re: [foreman-dev] speeding up tests

[Tomas Strachota]

On Tue, Nov 7, 2017 at 11:17 AM, Ivan Necas  wrote:
> On Tue, Nov 7, 2017 at 9:29 AM, Lukas Zapletal  wrote:
>> We should start tracking test breakages in time, if we have a test
>> that did not break for a year, lets delete it. As simple as that. It's
>> added value is almost zero.
>>
>> This is not out of my head, I've heard that on a talk somewhere.
>> Instead of deleting, we can move it to archive - run them on a nightly
>> basis, if we find this too much. Frankly, I prefer deletion.
>
> -1: the fact that the test doesn't fail in a year can be just due
> to fact that we have not worked on that area for some time. It might
> work for some project with strictly defined use-case, but for Foreman,
> I don't think thats' the case.
>

-1 as well for deleting the tests. They become useful once you start
refactoring things even when the code wasn't touched for a long time.

>>
>> Also, let's ditch unit tests in favor of integration tests. We have a
>> lot of areas covered with both and this is extra work and slowing down
>> things.
>
> +1 for integration tests > unit tests: and I'm willing to talk about deleting
> unit-tests once we know that integration tests are covering the same.
>
> I feel unit-tests more important, when working on specific algorithm etc.
> We don't do it that often. We mostly integrate.

+1 I see more value in integration tests in general. Unit tests for
algorithms are useful too.
I see less value in unit tests for attribute presence and simple
validations like uniqueness.

>
>>
>> LZ
>>
>> On Tue, Nov 7, 2017 at 9:19 AM, Ohad Levy  wrote:
>>> Hi,
>>>
>>> The challenge:
>>>
>>> As a developer, I feel under utilized waiting for tests, the current test
>>> suite for foreman core takes over an hour, multiply it by number of really
>>> simple code fixes based on comment and it takes up a good chunk of a day.
>>>
>>> I would like to suggest a short and long term solution, and would appreciate
>>> your feedback.
>>>
>>> Short-term:
>>>
>>> Break down test matrix into more specific groups, this will allow to
>>> re-trigger just a smaller part of the tests vs. the entire suit today, for
>>> example:
>>> * API tests
>>> * DB migrations
>>> * UI Integration tests
>>> * ...

That would definitely help to improve day-to-day developer's experience.

>>>
>>> Long term:
>>>
>>> Break down core into smaller repositories - This is probably a bigger topic
>>> then just tests, but its worth raising in this context as well.. the
>>> benefits i see are:
>>>
>>> * smaller repos - faster tests per repo (we would still need a plugin matrix
>>> kind of tests done at some point)
>>> * better review process - smaller repos would mean the maintainers of the
>>> repo actually care for all/most of the pr's - today its not the case - many
>>> PR's are handled by sub groups (e.g. anything under webpack folder is
>>> "someone else")
>>> * potentially better API between parts - e.g. we can create a schema
>>> specific repo (not saying its a good idea) - which will always work with a
>>> dummy rails app - in the long run - this will ensure our schema is resilient
>>> to upgrades and model changes in core.

The biggest benefit of splitting the repos is imho the need for
stabilizing the api between components.
I believe that there would be some transfer to stability of the whole project.

>>>
>>> I would even go further and enable auto merge after review + successful
>>> tests, e.g.
>>> 1. PR is sent
>>> 2. repo tests are executed and pass
>>> 3. reviewer approve the change
>>> 4. larger test matrix is executed and pass
>>> 5. code get auto merged.
>>>
>>> --
>>> 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.

Re: [foreman-dev] Proposed drop of supporting ruby 2.0 in hammer

[Tomas Strachota]

Thanks,
I removed ruby 2.0.0 from configuration matrix of the jenkins jobs
relavant to hammer. And created two redmine issues for removing the
old compatibility code:
* http://projects.theforeman.org/issues/21359
* http://projects.theforeman.org/issues/21360

T.

On Tue, Oct 10, 2017 at 2:44 PM, Andrew Kofink <akof...@redhat.com> wrote:
> +1 out with the old
>
> On Tue, Oct 10, 2017 at 8:00 AM, Michael Moll <kved...@kvedulv.de> wrote:
>>
>> On Tue, Oct 10, 2017 at 01:45:42PM +0200, Ewoud Kohl van Wijngaarden
>> wrote:
>> > On Tue, Oct 10, 2017 at 01:21:36PM +0200, Tomas Strachota wrote:
>> > >we recently encountered a compatibility issue with older version of
>> > >Clamp that we use on ruby 2.0 installations. Latest Clamp releases
>> > >require ruby 2.1+. See [1] for some more details.
>> > >
>> > >The easiest solution seems to be dropping ruby 2.0 support, which was
>> > >eol 2016-02-24 anyway. We use scl with ruby 2.2 on rpm based distros,
>> > >so we should be safe there.
>> > Support for Trusty has been dropped in 1.16 and 1.17 will drop Jessie.
>> > Focussing on 2.1+ or 2.2+ should be no problem.
>>
>> exactly.
>> --
>> Michael Moll
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Andrew Kofink
> akof...@redhat.com
> IRC: akofink
> Associate Software Engineer
> Red Hat Satellite
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[foreman-dev] Proposed drop of supporting ruby 2.0 in hammer

[Tomas Strachota]

Hi all,
we recently encountered a compatibility issue with older version of
Clamp that we use on ruby 2.0 installations. Latest Clamp releases
require ruby 2.1+. See [1] for some more details.

The easiest solution seems to be dropping ruby 2.0 support, which was
eol 2016-02-24 anyway. We use scl with ruby 2.2 on rpm based distros,
so we should be safe there.

The question is how big deal it would be for Debian based distros. I
checked ruby versions on what we currently support:
- Debian Jessie - ruby 2.1 (https://packages.debian.org/jessie/ruby)
- Debian Stretch - ruby 2.3 (https://packages.debian.org/stretch/ruby)
- Ubuntu Trusty - ruby 1.9 (https://packages.ubuntu.com/trusty/ruby)
but we depend on a package ruby2.0
- Ubuntu Xenial - ruby 2.3 (https://packages.ubuntu.com/xenial/ruby)

So the only issue seems to be with Trusty, where we could bump the
dependency to ruby2.3.

What do you think, are there any objections against dropping it?

T.


[1] https://github.com/theforeman/hammer-cli/pull/251

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

[Tomas Strachota]

On Wed, Aug 23, 2017 at 5:37 PM, Ivan Necas  wrote:
>
> On Wed, 23 Aug 2017 at 15:10, Eric D Helms  wrote:
>>
>> There are a few different points to reply to, hopefully I did not miss
>> one. For the base topic, based on feedback and target for post 1.16, I think
>> we end up with:
>>
>>  * 2.2 - postgres
>>  * 2.3 - postgres
>>  * 2.4 - postgres
>>  * 2.2 - mysql
>>  * 2.2 - sqlite3
>

+1 that should provide enough coverage

>
> This selection works for me
>
>>
>> Jenkinsfile in Repos
>>
>> I think there are valid points and reasons for why this could be a good
>> idea. However, I lean more towards this meaning a later goal and not an
>> initial target. This would provide a more Travis like experience. I think to
>> achieve this we need enough stability in both our job definitions, but also
>> in the expectations that our Jenkins would be providing for plugins and
>> other projects. If we want to share common code to make writing of the jobs
>> easier, we need to have that common code stabilized or else we end up having
>> to update multiple repositories every time we make a change. Thus, I would
>> put this on the back burner as a goal when we stabilize. The centralized
>> infra repository allows easier job definitions, and code sharing and
>> development.
>>
>> Docker
>>
>> I would love to get to this point compared to how RVM setups work. I think
>> this should be a second pass update that we make across the board after we
>> make the first set of jobs given that we already know the slaves are
>> configured and work with the RVM and database setups. I think we need to do
>> some up front gathering and testing of information for things like:
>>
>>  a) what all do we need containers of? (versions of ruby, OSes, databases,
>> puppet availability etc.)
>>  b) which set of slaves can run docker? and label them
>>  c) what configuration updates do we need to make to slaves to run docker
>> on them
>>
>> I think this can be done in parallel to my efforts if someone would like
>> to take it on. We can add it to the wiki page as an item.
>>
>> Hound Dropping
>>
>> This probably deserves it's own thread whether we drop Hound in favor of
>> using Jenkins to do the linting.
>>
>>
>> Eric
>>
>> On Wed, Aug 23, 2017 at 5:05 AM, Michael Moll  wrote:
>>>
>>> Hi,
>>>
>>> On Tue, Aug 22, 2017 at 07:44:42PM -0400, Eric D Helms wrote:
>>> > I am beginning to look at updating some of our test infrastructure by
>>> > re-writing Jenkins jobs into the pipeline plugin [1]. This is a new
>>> > style,
>>> > with a different way of both writing and thinking about how jobs are
>>> > crafted. I've started this work by attempting to write jobs for both
>>> > Foreman and Katello [2].
>>>
>>> +1!
>>>
>>> >  ruby: 2.1, 2.2, 2.3, 3.4
>>> >  databases: mysql, postgresql, sqlite3
>>> >
>>> > I would like to propose the following:
>>> >
>>> >  1) We drop sqlite3 entirely
>>>
>>> At least one Ruby version should get tested with sqlite3, as almost all
>>> dev setups will be sqlite and that's making it easy to reproduce test
>>> failures.
>>>
>>> >  3) We pick the most widely used Ruby version and test mysql with that
>>>
>>> Sounds OK.
>>>
>>> >  2.2 -- used in RPM production
>>>
>>> This will need to get updated for Rails 5 anyway.
>>>
>>> >  2.1, 2.3, 2.4 -- used by Debian production
>>>
>>> 2.1 is Debian/jessie, which will be dropped with Rails 5. 2.4 is not
>>> used in any Debian or Ubuntu version and it's highly likely that
>>> Debian/unstable (and thus the next Ubuntu LTS 18.04) will go from 2.3 to
>>> 2.5 directly.
>>>
>>> At the end with Rails 5 only Ruby 2.3 and 2.4 would stay and 2.5 get
>>> added in Q1/2018. Depending on the RPM situation 2.4 could get dropped
>>> theroretically again in Q2/2018.
>>>
>>> Regards
>>> --
>>> Michael Moll
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "foreman-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to foreman-dev+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>>
>> --
>> Eric D. Helms
>> Red Hat Engineering
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [foreman-dev] API usage - getting Hosts in Hostgroup

[Tomas Strachota]

The search parameter can be used also in the api:
https://theforeman.org/api/1.15/index.html

The request will be something like:
https://foreman.mydomain.com/api/v2/hosts?search="hostgroup_id=1;

T.


On Wed, Aug 16, 2017 at 1:05 PM, Roy Burstein <burstein@gmail.com> wrote:
> Hi Thomas ,
>
>  Thanks for your response , any workaround for the rest api interface?
>
> Thanks ,
> Roy
>
> On Wednesday, August 16, 2017 at 11:10:25 AM UTC+3, Tomas Strachota wrote:
>>
>> Hello,
>> this is a known bug:
>> http://projects.theforeman.org/issues/20204
>>
>> As a workaround you can use the search parameter to filter hosts by
>> hostgroups:
>> "hostgroup = " or "hostgroup_id = "
>>
>> T.
>>
>>
>> On Tue, Aug 15, 2017 at 5:24 PM, roy.b via foreman-dev
>> <forem...@googlegroups.com> wrote:
>> > Hi all ,
>> >
>> > I am new here and hope it's OK to submit issues .
>> > I have created new Hostgroup in foreman and the group is empty .
>> >
>> > Querying the hosts table in foreman schema :
>> >
>> > mysql> select id from hostgroups h
>> > -> where h.name='myhostgroup';
>> > +-+
>> > | id  |
>> > +-+
>> > | 243 |
>> > +-+
>> > 1 row in set (0.00 sec)
>> >
>> > mysql> select * from hosts where hostgroup_id=243;
>> > Empty set (0.00 sec)
>> >
>> >
>> >
>> > when trying to do the same with the API :
>> >
>> > https://foreman.mydomain.com/api/v2/hostgroups/243/hosts
>> >
>> > -- I got as result all the servers in foreman .
>> >
>> > Am I doing something wrong ? or is it a bug ?
>> >
>> >
>> > Thanks ,
>> > Roy
>> >
>> > --
>> > 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...@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] kerberos auth for the API

[Tomas Strachota]

Hello,
yes, kerberos API authentication is tracked in the issue that you
sent. Unfortunately there's really no solution yet. Important
prerequisites have been released with the Foreman 1.15 (session
support in the API) but the API still lacks entry point for external
login (equivalent of /users/extlogin).

T.


On Tue, Aug 8, 2017 at 2:16 AM, Sergei Gerasenko  wrote:
> Hello,
>
> I was wondering if anything exists for API authentication using kerberos. I
> think this describes the issue and it looks like no solution exists yet, but
> I just want to make sure that's the case.
>
> 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.

-- 
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] Entry level hammer issues

[Tomas Strachota]

Couple of people has asked me about some easy to fix issues in hammer
that would be good to start with if they wanted to learn hammer and
deep into its waters slowly.
I went through the backlog and picked a few tasks that I think should
be simple to fix. The current list is at [1] and I'll try to add more
items that I find suitable with time.

Feel free to ping me if you need some help with fixing them or some
additional info.

Happy coding!
Tomas

[1]  https://goo.gl/UQV6fn

-- 
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] Shareable makefile and rake tasks for extracting translations in hammer

[Tomas Strachota]

Past two hammer-cli and hammer-cli-foreman releases we experienced
some issues with merging translations, fuzzy matching or generating
.mo files, which caused us to update the rake tasks and Makefile we
use for extracting strings and merging translations. Probably all
translated hammer plugins contain a copy of the Makefile from hammer
core from the time the plugin was created and rarely update it so most
of them is most likely affected with some of that issues too. It's
also not very efficient to update all the plugins when there's a need
for a change in the process.

Therefore I created a common Makefile.def and rake task that can be
included from a hammer plugin:
https://github.com/theforeman/hammer-cli/pull/249

I'd appreciate if plugin authors could test and review the change.

I'll send one more announcement once the change is released and ready
for consumption.

Thank you
Tomas

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

[Tomas Strachota]

On Mon, Jun 5, 2017 at 4:14 PM, Lukas Zapletal  wrote:
> On Mon, Jun 5, 2017 at 2:48 PM, Tomer Brisker  wrote:
>> My suggestion is that we replace the katello test currently running on every
>> PR with a test that installs the top 5 plugins together and runs all of
>> their tests.
>
> +1 +1 +1
>
> Last week or two, Katello was red because of trivial regression in the
> testing framework, we did not block PRs at all, but eventually Daniel
> stepped up and fixed it. That sounds to me this works! If we can
> extend this to other plugins - big improvement for these. For
> discovery this would be huge improvement in overall stability.
>
> I agree that it should not make the jenkins load much worse, discovery
> and also other plugins has only dozens of tests, so the slowdown
> should not be significant I hope. We can stick with what Katello team
> does today - only test postgresql on particular ruby version (2.2 I
> think today). If we are able to run them all in one rake task, that
> would mean just one Rails boot as well.

+1 for testing a set of most used plugins on postgresql and one ruby
version for each PR. Together with that we can still keep testing for
the full matrix once a week.

>
> What others say? Next steps would be:
>
> - nominate the plugins for this and vote them (or we can simple take
> most downloaded from our survey)
> - modify katello job to test all of them
> - rename katello job perhaps to avoid confusion?
>
> --
> 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] Moments of Coffee Meeting: Fog and Compute Resrouces NG

[Tomas Strachota]

On Tue, May 23, 2017 at 10:07 AM, Ivan Necas  wrote:
> Timo Goebel  writes:
>
>>> 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.
>
>
> I think what's missing is not well-defined layer between Foreman and
> Fog, and we perhaps over-use the Fog as the unification layer.
>
> I feel quite a lot of risk in connecting the migration between oVirt v3
> vs. v4 with introduction of new layer into the Foreman to serve better
> for our purposes, that would not use the Fog. Especially when the APIv4
> is pretty close.
>
> If we make fog oVirt provider use APIv4, we still have chance that the
> code will be used outside of Foreman, that will make the implementation
> better: from the past - did we experience this happening in oVirt or
> other providers? (my feeling is that they did, but not monitoring that
> that much)
>
> Long story short:
>
> 1. I agree we should not expose Fog as THE layer we use in the UI/API,
> to add the entry points that are interesting for use but not for fog
> that much

+1 for adding a layer between our UI/API and fog or potentially some
other library we might decide to use (or write) in future. I think
it's an important step, regardless of whether we decide to use fog for
oVirt v4 api or not.

>
> 2. we should continue with fog-ovirt to use APIv4
>
> Even though it looks compelling to connecting this two, I would rather
> take it independent steps.
>
> -- Ivan
>
>>
>> - 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.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[foreman-dev] hammer-cli and hammer-cli-foreman 0.10.2 released

[Tomas Strachota]

New minor versions of hammer-cli and hammer-cli-foreman were released.
They contain fixes around fetching server CA certs and retry mechanism
when session expires.

This should go to the next foreman 1.15 RC.

PR into rpm packaging is open at:
https://github.com/theforeman/foreman-packaging/pull/1638

Cheers
Tomas

-- 
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] hammer-cli, -foreman version numbers on master

[Tomas Strachota]

Done, versions in both repos bumped to 0.11-develop and strings
extracted in the master.

Thanks
T.

On Fri, May 5, 2017 at 3:25 PM, Dominic Cleal <domi...@cleal.org> wrote:
> On 05/05/17 14:21, Tomas Strachota wrote:
>> Is it enough just to bump the version to 0.11-develop or do I need to
>> do whole new release?
>
> Bumping/changing the version number is fine, thanks.
>
> --
> Dominic Cleal
> domi...@cleal.org
>
> --
> 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] hammer-cli, -foreman version numbers on master

[Tomas Strachota]

Is it enough just to bump the version to 0.11-develop or do I need to
do whole new release?

T.

On Fri, May 5, 2017 at 11:11 AM, Dominic Cleal  wrote:
> The version numbers on hammer-cli and hammer-cli-foreman's master
> branches are currently behind the latest release (from the 0.10-stable
> branch) which is causing a small issue with RPM packaging tests -
> packages are built with the .1 spec files, but the version numbers are
> set to .0.
>
> Martin or Tomas, could you please increment the version on master to
> either match or exceed the latest released version? i.e. 0.10.1, .2, or
> 0.11.0
>
> There's also a change to the POT file on the 0.10-stable branches which
> won't be picked up by Transifex which uses master. This should be
> changed on master too, or Transifex needs reconfiguring to use the
> stable branch.
>
> Cheers,
>
> --
> Dominic Cleal
> domi...@cleal.org
>
> --
> 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] Proposal: make foreman STI to work even when an inherited class is not found in Ruby.

[Tomas Strachota]

This issue is tightly coupled with plugin uninstallation and I think
we should solve the two problems together. At the moment there's no
standard plugin uninstallation procedure that would take care of
cleaning up the system. This is something each plugin should provide.
One thing (imho the less important in this context) is where we put
such code. Should it be a rake task, part of installer, part of
maintanance script, somewhere else?

What I see as more important is to decide what data will the
uninstallation process remove (keep all vs. keep only settings vs.
wipe all) and how we want the plugin to behave if it's installed
again. This will affect how we approach missing STI classes.

I can see 3 options:

a) Remove all data
Plugin would remove all tables and records it created. In such case we
probably don't need to change the STI behavior. Plugin uninstallation
should take care of removing the data correctly. If it fails it's fine
to throw exception to indicate the system integrity is broken. This
approach is imho safer for us as developers and requires less
defensive coding.

b) Keep all the data
In this case the original data should be present when the plugin is
installed again. STI records without classes should be completely
hidden in the default scope. If all records are listed we should
return either instances of base class or some special class for the
missing types. I'm afraid this approach is quite fragile and can lead
to many surprises when a plugin is uninstalled, the foreman lives
without it for some time and then you install it again. I'm also not
sure how common is such usecase.

c) Combination of a) and b)
We can keep data where it's safe (like settings) and delete the rest.

I'm in favor of a) or c)

T.





On Sun, Apr 30, 2017 at 10:05 AM,   wrote:
>
> Hello,
>
> lately I was switching plugins on and off, and I stumbled upon an annoying
> issue: Many plugins that add some STI classes (for example Katello that adds
> settings, or Discovery that adds DiscoveredHost).
> A problem starts when such a plugin is removed from the system, since
> default STI implementation will throw an error if it can't load a class that
> corresponds to the :type column in the DB.
>
> I propose a custom handling for such cases, since they are not exactly
> exceptions in our system design.
> I was thinking about one of the following options to handle this case, and
> would like to see a voting which one you prefer. Of course other options can
> be proposed too.
>
> 1. Return a base class for such records (Maybe with an error already set)
> 2. Return nil/some kind of special AR object for such records (will require
> defensive coding while handling heterogeneous lists)
> 3. Filter those records out with default scope (will require more
> declaration in plugins, or more DB queries on system startup)
>
> Any thoughts in this area will be much appreciated,
>
> Shim
>
> --
> 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] Organization titles in CLI

[Tomas Strachota]

I'm not sure I understand. It is currently possible to update parents
of organizations. Did you mean to use the parent parameter as a
compound identifier together with names?

i.e. for changing a name and a parent you would use:
$ hammer organization update --name Brno --parent EMEA --new-name Krno
--new-parent ...

and for info:
$ hammer organization info --name Brno --parent EMEA

Did I understand it correctly?


On Mon, Apr 10, 2017 at 6:12 PM, Andrew Kofink <akof...@redhat.com> wrote:
> Tomas,
>
> Would it be easier to print the parent with list/info commands and allow
> updating that attribute (i.e. --parent/--parent-id)? We already have a
> handler in the ID resolver when multiple records are returned when only one
> is expected, though the error message does not tell the user how to further
> filter the results.
>
> - Andrew
>
> On Mon, Apr 10, 2017 at 11:09 AM, Tomas Strachota <tstra...@redhat.com>
> wrote:
>>
>> I recently found out hammer uses only short names for identifying
>> organizations. Names aren't globally unique, which makes it impossible
>> to modify or delete an org when there are two of the same name but
>> nested under a different parent org. See [1] for details.
>>
>> I opened a preliminary PR [2] that adds option --organization-title to
>> all commands that consume taxonomies and a column "Title" to output of
>> the list command. This is simple solution, consistent with how it
>> works in hostgroups, but I don't think it's the best from the
>> usability point of view. Both options --name and --title as well as
>> table column labels feel redundant (columns contain the same data if
>> orgs aren't nested).
>>
>> An alternative approach is to completely replace names with labels in
>> hammer internally. We would have to change id resolver and let the
>> list commands print titles (in a column labeled "Name"). That's how
>> it's displayed in UI.
>>
>> Pros:
>>   - users wouldn't notice the change, it should be seamless in most cases
>>   - no need to add extra options
>>   - consistent with the UI, where column labeled "Name" contains
>> titles in taxonomy tables
>>
>> Cons:
>>   - name isn't the same as title and it might not feel natural to update
>> as:
>> hammer location update --name 'emea/brno' --new-name 'krno' which
>> would then be displayed as 'emea/krno'
>>
>> The con I mentioned could be fixed by checking if a user passed a name
>> containing '/' and using only last part of title in such cases. That
>> would make even --new-name 'emea/krno' work.
>>
>> Theoretically it could be used also for changing organizations parent.
>> --name 'emea/brno' --new-name 'europe/krno' would change parent to an
>> organization with title 'europe' and rename to 'krno'. But that's
>> maybe too much.
>>
>> How do you find the alternative approach? Do you see any other options
>> how the commands could work? Any idea is welcome.
>> I'd like to change hostgroup commands to use the same style and make
>> it consistent across the whole cli when we find a good solution. Are
>> there any commands in plugins (looking mainly at hammer-cli-katello)
>> that use resources with nested names?
>>
>> T.
>>
>> [1] http://projects.theforeman.org/issues/19157/
>> [2] https://github.com/theforeman/hammer-cli-foreman/pull/299
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Andrew Kofink
> akof...@redhat.com
> IRC: akofink
> Associate Software Engineer
> Red Hat Satellite
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [foreman-dev] Re: 1.15 branching in approximately 2 weeks

[Tomas Strachota]

hammer_cli 0.10.0 and hammer_cli_foreman 0.10.0 released:

https://github.com/theforeman/hammer-cli/tree/0.10-stable
https://github.com/theforeman/hammer-cli-foreman/tree/0.10-stable

PR into foreman-packaging with scratchbuilds:
https://github.com/theforeman/foreman-packaging/pull/1585



On Tue, Mar 28, 2017 at 1:57 PM, Daniel Lobato <elobat...@gmail.com> wrote:
> Hi all,
>
> I will begin branching Foreman, theforeman.org, community-templates
> and translations in approximately 5 hours.
> If you have signed up to branch any of the projects in this thread,
> please feel free to do so any time today.
>
> Remember, after branching, we still have time to submit patches to
> ensure the release is stable during the RC period.
> Expect a new RC to come out every week approximately since now.
>
> Thanks for your collaboration!
>
> On Thu, Mar 16, 2017 at 11:45 AM, Dmitri Dolguikh <witlessb...@gmail.com> 
> wrote:
>> On Wed, Mar 15, 2017 at 8:10 AM, Tomas Strachota <tstra...@redhat.com> wrote:
>>> On Tue, Mar 14, 2017 at 2:28 PM, Daniel Lobato <elobat...@gmail.com> wrote:
>>>> We're planning to do the branching on all projects on March 28th -
>>>> please keep it in mind and try to get
>>>> things that would be important for 1.15 by then.
>>>>
>>>> I do not have commit access everywhere, so please check the following
>>>> list and reply if you
>>>> could take care of cherry-picking and branching:
>>>>
>>>> foreman - Daniel - dlobatog
>>>> foreman-installer - Stephen - stbenjam
>>>> smart-proxy - Daniel - dlobatog - (or Dmitri - witlessb if you prefer)
>>
>> yes can do.
>> -d
>>
>>>> foreman-selinux - Lukas - lzap
>>>> foreman-packaging - Eric - ehelms
>>>> theforeman.org - Daniel - dlobatog
>>>> translations - Daniel - dlobatog
>>>> community-templates - Daniel - dlobatog
>>>> hammer-cli - Tomas? Martin?
>>>> hammer-cli-foreman - Tomas? Martin?
>>>
>>> I'll take care of hammer branching and release.
>>>
>>>> puppet-foreman - ?
>>>> puppet-foreman_proxy - ?
>>>>
>>>>
>>>> On Fri, Mar 10, 2017 at 7:43 PM, Daniel Lobato Garcia
>>>> <elobat...@gmail.com> wrote:
>>>>> As per 
>>>>> http://projects.theforeman.org/projects/foreman/wiki/Foreman_115_Schedule,
>>>>> 1.15 is due to be branched soon, in 2 weeks approximately.
>>>>>
>>>>> Please help to make develop more stable during this process, be it through
>>>>> thorough testing, bugfixing or improving documentation.
>>>>>
>>>>> Help with updating the manual would be appreciated, see the list of
>>>>> tasks in:
>>>>>   - https://github.com/theforeman/theforeman.org/issues/765
>>>>>
>>>>> Some translations are nearing 100% completion, we welcome contributions
>>>>> that help finishing them for the next release:
>>>>>   - https://www.transifex.com/foreman/foreman/foreman/
>>>>>
>>>>> If you have any critical fixes that you think should be included in 1.15
>>>>> in any of the core projects, please reply to this read to raise
>>>>> attention over them. Maintainers feel free to set the 1.15 label to
>>>>> any PR of that nature.
>>>>>
>>>>> Best,
>>>>>
>>>>> --
>>>>> Daniel Lobato Garcia
>>>>>
>>>>> @dLobatog
>>>>> blog.daniellobato.me
>>>>> daniellobato.me
>>>>>
>>>>> GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
>>>>> Keybase: https://keybase.io/elobato
>>>>
>>>>
>>>>
>>>> --
>>>> Daniel Lobato
>>>>
>>>> @dlobatog
>>>> daniellobato.me
>>>>
>>>> GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
>>>>
>>>> --
>>>> 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 
>>> "forema

Re: [foreman-dev] Speed up rake apipie:cache:index

[Tomas Strachota]

On Mon, Mar 6, 2017 at 10:11 AM, Martin Bačovský
 wrote:
> The current state is that the apipie cache consists of  root index page and
> page per API resource and method and JSON desription of whole API
> (multiplied by number of languages). Currently we build all the resource
> specific pages during the package build time. The index and JSON need to
> contain all the resources according to current configuration including all
> the plugins that extends API. That is the reason we have to build this
> during installation.
>
> During my benchmarks the bottleneck was loading the whole rails env. Before
> the rake started to generate anything it took almost a minute on average
> machine. May be different now though.
>
> Where we can surely spare some time is rpm package installation. Every
> plugin extending API calls apipie:rake:index in %postrans resulting in about
> 3 consequent redundant calls for default Katello install. If we can add some
> state info that index was already built in this RPM transaction we could
> spare a few mins.

The state check could be useful.

>
> I'm not sure if JS would help us with creation of the JSON which is the most
> used part of the API docs (used for Hammer and bindings), but I can imagine
> it could be put together dynamically on first request from pieces generated
> during a build time and cached. This way we could avoid index creation
> completely.

Do you have any benchmark how long it takes to generate json only vs
json + html?

Since some plugins currently modify foreman api endpoints and can
potentially change (or remove) the api params too I don't think
there's easy way of generating docs json for each plugin and merging
it later.

>
> 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] Speed up rake apipie:cache:index

[Tomas Strachota]

It's used for generating both html doc pages and json (consumed by
apipie bindings). We can't get rid of iterating over languages, but
generating docs only in json format and having html page that loads it
async and generates the content dynamically would probably bring the
desired speedup. I like it.

T.


On Mon, Mar 6, 2017 at 9:06 AM, Lukas Zapletal  wrote:
> Perhaps, but AFAIK we generate index page in all supported i18ned
> languages, so the process is somehow repeated 12 times which makes is
> slow I believe.
>
> LZ
>
> On Fri, Mar 3, 2017 at 5:11 PM, Ewoud Kohl van Wijngaarden
>  wrote:
>> On Fri, Mar 03, 2017 at 04:34:49PM +0100, Lukas Zapletal wrote:
>>> the rake apipie:cache:index command which we do both in build phase
>>> and after RPM package installation is slow as hell. What is the reason
>>> for that? Can't we redesign this to completely avoid need of
>>> generating this kind of index? For example the page could be
>>> JavaScript based, plugins would simply drop some metadata files and JS
>>> would parse them hiding/showing appropriate sections on the index
>>> page. This should not be too hard, but it will increase user
>>> experience with installing and updating which we need to improve for
>>> sure.
>>
>> Isn't the cache also used by apipie client bindings (which are used by
>> tools like hammer)?
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to foreman-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Later,
>   Lukas @lzap Zapletal
>
> --
> You received this message because you are subscribed to the Google Groups 
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to foreman-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [foreman-dev] Host Creation

[Tomas Strachota]

On Thu, Feb 9, 2017 at 5:27 PM, Tom McKay  wrote:
> I like the "add" buttons (eg. operating system) but there were some
> resources that didn't have add buttons (eg. partition tables). Should all of
> the associated resources have buttons? Not UX specifically, but it would
> also be helpful if the choice lists were made api calls to populate choices
> when opened. This way when a resource is added (perhaps on a different
> browser page) that resource is selectable without a page refresh (very
> painful in current new host ui).
>
> I would also note that it is not uncommon, at least for me, to have the
> resource already existing (ie. don't need to create it) but it is either in
> the wrong org/loc or missing the association (eg. template not associated
> correctly). How would this case be handled?

One of ideas that came to my mind is to detect when a resource of the
same name exist in a different org and offer assigning it to the
current one. But that is probably problematic in terms of permissions.
When can you change taxonomy assignment of a resource that you can't
see in the current org? Probably only when you're an admin.

>
> Highlighting the fields red is great but when does that happen? Is the red
> persistent (ie. I leave the wizard and return later)? Having the wizard step
> number icons change color would be helpful too. Could be red if error but
> maybe some other color/style to indicate that the step is incomplete?
>
> Plugins would need to be able to add/remote steps (eg. ansible), and change
> forms. Any UX implications?
>
> Is there a pattern for sub-steps? Step 5, parameters, for example has three
> subsections. Would there be cases where each of those lettered sections have
> their own pages with a step progress bar? (Not sure if needed.)
>
> After I've created a host, does it become a "template" automatically? I
> would like a way to, from a host, go to its wizard and duplicate (could be
> just change the name and relaunch, for example).

The common approach I like in other systems is to ask whether the host
should be saved as a template right after it was created. What Tom
describes sounds to me like host cloning that is already implemented
in the Foreman.

Speaking about host templates, is it something that should exist side
by side with hostgroups or is it a replacement?

>
> Overall looks great!

+1 it would be huge improvement. Especially the fact that one can save
semi-configured hosts before they are provisioned.

>
>
>
>
> On Wed, Feb 8, 2017 at 3:24 PM, Roxanne Hoover  wrote:
>>
>> All -
>>
>> It was identified amongst users that the Host Creation process could use
>> some improvement.
>>
>> I've come up with a design to help reduce confusion, create a
>> clearer/unobstructed path to completion and that also integrates some
>> features asked for by users.
>>
>> I feel the design is complete in terms of the knowledge I posses, and am
>> now looking for feedback from the community who I'm sure will have thoughts
>> - technical or otherwise -  I hadn't yet considered.
>>
>> Looking forward to any feedback.
>>
>>
>>
>>
>> --
>> 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] Opinions from plugin maintainers wanted: permissions and roles

[Tomas Strachota]

On Mon, Jan 16, 2017 at 6:55 PM, oprazak  wrote:
> Hi,
> I recently started identifying problematic areas in Permissions and Roles,
> especially with regard to plugins. Foreman provides 'Viewer' and 'Manager'
> roles out of the box and users expect these roles to work for plugins as
> well. But plugins generally do not add their permissions to core's roles,
> some of them just have their own plugin-specific roles, some not. So if a
> plugin is installed, user has to go and find what role/permission is missing
> or ask someone who can grant permissions.
>
> After a brief discussion in team C, it was decided that plugins should add
> their permissions to 'Manager' role and their 'view_' permissions to
> 'Viewer' role. They should also keep their plugin-specific roles (or create
> them) for higher granularity and backward compatibility.
> I started initial work which should allow plugin maintainers to do this, it
> can be found at [1]. I decided to create 2 methods that would be called from
> Engine, but we could take a different approach and add permissions from
> plugins automatically by modifying the 'permission' method that is called
> from 'security_block'.
>
> The way I see things:
>
> * adding permissions explicitly, using DSL
>   - extra work for plugin maintainers
>   - permissions can be ommited/forgotten
>  # can be covered with tests? something like the already existing
> AccessPermissionsTest
>   - extra code in Engine
>   - better control, can handle special cases
>
> * adding permissions automatically without plugin knowing about it by
> modifying 'permission' method
>   - no need for plugin maintainers to do anything
>   - cannot handle special cases
>   - if user removes permission from these default roles, there is no way to
> detect it and permissions get added again on server restart

I'm afraid this could be quite frustrating if you try to modify your
roles. I'm not entirely sure what part of permissions is stored in the
db and what is in the code, but would it be possible to add
permissions during seed and don't touch it on server start?

> # users do not modify default roles, they can clone it and modify the
> cloned one
> # if the default roles are not meant to be modified, they should be
> 'frozen' and user should not be able to modify them, implementing this would
> add code and complexity

Even though it's more work for plugin maintainers I prefer option A
because it gives you more control over what gets added.

BTW how would both approaches behave on migration of existing
installations? Would it add the permissions too?

>
> Anything that I have missed? Where do you stand as a plugin maintainers? Can
> you think of other ways to go?
>
> Ondra
>
> [1] https://github.com/theforeman/foreman/pull/4168
>
> --
> 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

[Tomas Strachota]

On Wed, Dec 21, 2016 at 9:04 PM, Greg Sutcliffe
 wrote:
> Hi all,
>
> Last year I rushed the community survey, and forgot to get feedback on the
> questions it contained - I'm not making that mistake again :)
>
> Below is the draft question set - fair warning, its a big email :P. My aim
> is to either make it shorter, or at least break it up into a couple of
> logical pages. I've tried to indicate where the departures from last year
> are (especially the dropped/potentially-dropped ones). Feedback on what to
> change or things to add is very welcome - if you have a burning question to
> ask, lets hear it!
>
> Additionally, I may be able to fund some small incentive strategy to get a
> larger sample size. I can see two ways to do that:
>
> * Some small reward for the first X people to fill out the survey (eg $5
> gift card or something)
> * All response go into a raffle for some nice (more expensive) things

+1 for the raffle. It motivates you to respond even on the last day of
the survey. How about raffle for the foreman t-shirts? Or is it too
common and everybody already has one from conferences?

>
> Clearly this would require the user to identify themselves (an email is
> probably all I'd need) - that would be optional, of course. Do people
> support this? What would be your preferred option?
>
> The plan is to gather feedback on this in the New Year, publish the survey
> by mid January with a big push for early responders (hence the swag
> incentive above) and then re-push in person at the conferences. We then
> close it after about a month (mid Feb) and do the analysis.
>
> Anyway, the questions:
>
> ### To keep from last year - self-explanatory
>
> How long have you been using Foreman?
> [3m, 6m, 1yr, 2y, 3+yr]
>
> How many people use Foreman in your organization
> [1, 5, 10, 50+]
>
> What Foreman version are you using?
> [nightly, stable, old-stable, older]
>
> How many nodes do you manage with Foreman?
> [0, 10, 50, 200, 500, 1000, 1, 2+]
>
> What operating system do most of your Foreman servers use?
> [RHEL/CentOS/Fedora, Debian, Ubuntu, SUSE, Other]
>   (do we need to split this more, eg Fedora vs RHEL?)
>
> Which Compute Resources do you use with Foreman?
> Which Foreman plugins do you use?
>   these two need better structuring, the lists are long & stats were skewed
>   last year due to missing options. See end of post for the actual lists.
>
> How would you rate our user support?
> [mailing list, IRC, website, docs], 1-5 score
>
> How well do major releases (e.g. 1.9, 1.10) meet your needs?
> [frequency, features, bugs, stability], 1-5 score
>
> Any other feedback about our support and documentation? [text]
>
> Overall, how well does Foreman meets your requirements? [text]
>
> What's the most important thing you'd like to see done next in Foreman?
> [text]
>
> Do you have any additional comments or special requests? [text]
>
> ### New additions
>
> Would you accept Foreman gathering anonymous usage stats to help improve the
> project? This would have an opt-out and a way to see the data before sending
> (see https://github.com/theforeman/rfcs/pull/31 for a proposed design -
> comments
>  welcome!)
>   I really want to hear user feedback on this to avoid backlash later. Not
>   sure if it should be a simple yes/no or text-field for comments.
>
> What geographical area are you in?
> [Europe, N America, S America, Africa, Asia, Oceania]
>   We don't really know where our userbase is, although we have a hunch. I've
>   tried to keep it coarse, and it'll obviously be optional.
>
> ### Dropped from last year
>
> What do you use Foreman for at your organization?
>   I think our problem domain is fairly well specified, and knowledge of
>   specific plugins/CRs is more specific & valuable. Anything really ugent
> will
>   end up in the "most important thing" or "additional comments" boxes
>
> What are your top 3 from the following potential future features?
>   Basically the same thing as "what's most important to add", just ask it
> once
>
> Why did you choose it instead of alternatives?
>   I think I'd rather focus on Foreman than go off on a tangent. People who
>   are switching away won't fill in the survey anyway.
>
> Do you Use Locations / Organization features?
> Could you tell us more about your usage of Locations/Organizations?
> Any other feedback on your Locations/Organizations usage that you'd share?
>   I think we've gathered all the feedback we can on this last year.
>
> Would you be interested participating in a foreman community event?
> Would you be willing to help organise Foreman events in your area?
>   We saw good responses to the birthday events, but these questions don't
> work
>   on an *anonymous* survey. Potential to add back in if we ask for email
> addrs
>
> ### Optional from last year - comments welcome
>
> Do you use the Foreman API or Hammer?
>   I guess people are more aware of this now? Could add back in, or rephrase.
>   What things 

Re: [foreman-dev] New community-templates structure

[Tomas Strachota]

On Fri, Nov 25, 2016 at 3:40 PM, Marek Hulán  wrote:
> Hello foreman devs,
>
> As I demonstrated on last community demo [1] templates can be now easily
> exported from Foreman. I also mentioned that I'm working [2] on
> foreman_templates feature to easily export all templates to a given git repo.
> Since the plugin can be used with any git repo, not just the community-
> templates [3] one, I'd like to standardize the format of such repository.
>
> When we export templates from Foreman, we can only use template attributes to
> determine the resulting path in the repo. First obvious idea is to name the
> template file according to it's name in Foreman. That's probably not enough
> since it wold result in one directory mixing all partition tables,
> provisioning templates and job templates. So I came up with structure like
> $template_type/$name. For better look and feel of what it means, you can see
> it in one of my branches [4].
>
> Currently we also separate provisioning templates into more directories. I
> don't think the rule is well defined today. I think we could separate it per
> template kind. Again you can see this demonstrated in another branch at [5].
> It applies only to provisioning templates, other types don't have template
> kind attribute.
>
> Please share your ideas for other structuring or which of schema mentioned
> above you find better. The level of nesting does not matter from technical
> point of view but I think 2 or 3 directories is the limit.
>

I like kind + subkind the most.

> The ultimate goal of making foreman_templates exporting compatible with
> community-templates is making sharing of user changes easy, in fact just a
> matter of opening PR from the forked repo. Another nice benefit would be that
> future changes in metadata, e.g. adding organizations and locations keys would
> be much easier, we'd just reexport all templates from Foreman with updated
> export code.
>
> Since we now have metadata as a part of each template we could also improve
> seeding to avoid hard coding the list in seed files [6]
>
> [1] https://www.youtube.com/watch?v=M0-3x8AUfFQ
> [2] https://github.com/theforeman/foreman_templates/pull/36
> [3] https://github.com/theforeman/community-templates
> [4] https://github.com/ares/community-templates/tree/develop_kind_only
> [5] https://github.com/ares/community-templates/tree/develop_kind_and_subkind
> [6] 
> https://github.com/theforeman/foreman/blob/develop/db/seeds.d/07-provisioning_templates.rb#L21-L94
>
> Thanks for all comments
>
> --
> 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.

Re: [foreman-dev] Smart or Foreman Proxy? Let's do Foreman Smart Proxy

[Tomas Strachota]

On 10/17/2016 03:26 PM, Greg Sutcliffe wrote:

On 17 October 2016 at 14:12, Lukas Zapletal > wrote:


> This appears more inconsistent than the current situation, as there will
> now be three terms, differing between the UI names ("Foreman Smart
> Proxy"), API/module names ("smart proxy"), and package names ("foreman
> proxy").

That's indeed a very true statement, I'll add that the new term aims to
be the glue between the other two.


I think I agree with Dominic, a third standard to fix two other
standards is a common mistake.


To be honest, I'd rather kill "Smart Proxy" than "Foreman Proxy" if I
had to choose just one.


+1 to that, Foreman Proxy would be my choice.


+1 for Foreman Proxy



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] hammer requires ruby >= 2.1.0

[Tomas Strachota]

On 08/31/2016 01:13 PM, David Davis wrote:

We probably need to pin the version to 1.1.0. It looks like 1.2.0 which
came out this month requires ruby >= 2.1.0.



Yes, the requirement is quite new, but we actually need 1.2.0 to get the 
performance improvements it received recently. As Tomer wrote, git 
installation should be fine. More details about how we (plan to) 
approach the problem for various distributions is here:


https://groups.google.com/forum/#!msg/foreman-dev/kDPl1hgP9lQ/uvfEToYCCAAJ;context-place=forum/foreman-dev



David

On Tue, Aug 30, 2016 at 8:27 PM, Tom McKay > wrote:

Am I doing something wrong? Trying to install hammer (from github)
on RHEL-7Server fails because fast_gettext requires ruby >= 2.1.0.

--
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] Re: RFC for foreman_api_v3

[Tomas Strachota]

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


On Fri, Aug 26, 2016 at 10:47 AM, Dominic Cleal <domi...@cleal.org
<mailto:domi...@cleal.org>> wrote:

On 26/08/16 06:58, Joseph Magen wrote:
> I created a RFC for a plugin called foreman_api_v3
>
<https://github.com/isratrade/rfcs/blob/master/-foreman-api-v3.md 
<https://github.com/isratrade/rfcs/blob/master/-foreman-api-v3.md>>
and
> the initial repo at github.com/isratrade/foreman_api_v3
<http://github.com/isratrade/foreman_api_v3>
> <https://github.com/isratrade/foreman_api_v3
<https://github.com/isratrade/foreman_api_v3>>. If the community
accepts,
> I am happy to move this repo to theforeman/foreman_api_v3
>
> I choose to make this a plugin rather than a PR so it is optional for
> users and doesn't affect the core code.

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


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

GET api/api/v21/hosts

What do you think?




--
Dominic Cleal
domi...@cleal.org <mailto:domi...@cleal.org>



On Fri, Aug 26, 2016 at 11:36 PM, Tomas Strachota <tstrach...@redhat.com
<mailto:tstrach...@redhat.com>> wrote:

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

Hi all,

I created a RFC for a plugin called foreman_api_v3
<https://github.com/isratrade/rfcs/blob/master/-foreman-api-v3.md
<https://github.com/isratrade/rfcs/blob/master/-foreman-api-v3.md>>
and
the initial repo at github.com/isratrade/foreman_api_v3
<http://github.com/isratrade/foreman_api_v3>
<https://github.com/isratrade/foreman_api_v3
<https://github.com/isratrade/foreman_api_v3>>. If the community
accepts,
I am happy to move this repo to theforeman/foreman_api_v3

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

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

module Api
  module V3
class DomainsController < V2::DomainsController

but the response is changed.

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

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

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


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


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


That was all. I can't think of anything else at the moment besides the 
inconsistency that you mentioned.




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

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


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

[foreman-dev] Re: RFC for foreman_api_v3

[Tomas Strachota]

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

Hi all,

I created a RFC for a plugin called foreman_api_v3
 and
the initial repo at github.com/isratrade/foreman_api_v3
. If the community accepts,
I am happy to move this repo to theforeman/foreman_api_v3

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

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

module Api
  module V3
class DomainsController < V2::DomainsController

but the response is changed.

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

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

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



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


Speaking about the format change, since getting consistent with katello 
is one of motivations for the change, I'd like to hear from somebody 
with expertise in that field how difficult would be to bend the UI code 
to use the new format. Just to make sure we actually won't 
unintentionally put more obstacles in katello's way.


If we decide that jsonapi is the way to go for v3 I think it would be 
better to implement it as part of the foreman core. We can clearly mark 
it as devel preview with no guarantees, let it evolve alongside with v2 
and freeze when we're happy with it.


[1] http://jsonapi.org/format/#crud-updating-relationships
[2] http://jsonapi.org/format/#errors


Here's some more links that could be helpful in addition
to http://jsonapi.org/

http://blog.arkency.com/2016/02/how-and-why-should-you-use-json-api-in-your-rails-api/

*JSON API  is a great solution to not waste hours
on reinventing the wheel in terms of your API responses design.* It is a
great, extensible response standard which can save your time - both on
the backend side and the client side. Your clients can leverage you’re
using an established standard to implement an integration with your API
in a cleaner and faster way.

*Building a Rails API with the JSON API Spec
*http://www.slideshare.net/SonjaPeterson2/building-a-rails-api-with-the-json-api-spec

I look forward to hearing you feedback and receiving contributions to
the repo.

Joseph Magen (@isratrade)
Red Hat



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

[Tomas Strachota]

On 08/26/2016 10:39 AM, Daniel Lobato Garcia wrote:

On 08/26, Joseph Magen wrote:

Hi all,

I created a RFC for a plugin called foreman_api_v3
 and
the initial repo at github.com/isratrade/foreman_api_v3. If the community
accepts, I am happy to move this repo to theforeman/foreman_api_v3

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


Given more testing, and full functionality, I don't see why not making
this part of Foreman itself vs a plugin. Using json:api sounds great to
me, so thanks for doing it.

Having said that (and derailing a bit), I would want v3 not only to
comply with json:api but also to be documented with http://swagger.io/
instead. This gives us:


I'm not very familiar with swagger. Would that mean replacing apipie 
completely or exporting from apipie to swagger's format?




 - automated, better docs than what we have (example
   http://petstore.swagger.io/#!/pet/updatePet)
 - automated tests to ensure docs do what they say
 - generates an SDK for the API in many languages
   automatically through https://github.com/swagger-api/swagger-codegen

--
Daniel Lobato Garcia

@dLobatog
blog.daniellobato.me
daniellobato.me

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



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

Re: [foreman-dev] Webpack merged into develop branch

[Tomas Strachota]

On 08/10/2016 02:01 PM, Tomer Brisker wrote:

Hello,

I am happy to inform you that Webpack has finally been added to Foreman.
This step which will help us modernize our front-end code, take
advantage of the blooming javascript eco-system, and easily integrate
technologies such as ES2015, React, js unit testing and more.
A deep-dive will be scheduled soon to explain all the changes, but there
are a few details that require your attention for running the current
develop branch.


Great news!



This change requires a slight change to your workflow in the development
environment. First, you need to run `npm install` to get all of the
needed node modules to install (similar to `bundle install` for gems).
​Second, to run your server in development environment, you should use
`foreman start` which will run ​both the rails server and the webpack
live-reload development server. If you wish to use a non-default setting
for the rails server (e.g. using puma), you can set the RAILS_STARTUP
environment variable with the relevant command (see Procfile for an
example).

Please note that running this way will limit the ability to use pry for
debugging, as foreman prevents stdin echo. To use with pry, you can run
both servers separately in different terminals - run rails as usual in
one, and run `./node_modules/.bin/webpack-dev-server --config
config/webpack.config.js` in the other.


I noticed that when I run rails in development env, the webpack's 
hostname in assets is set to localhost. So of course it doesn't work 
when you're developing on a different host. Can this be tuned right away 
in some config or does it need additional patches to switch the hostname?




Also, new javascript code should be put in webpack/assets/javascript and
placed inside modules, using ES2015 syntax, whenever possible. Old code
will be gradually migrated into that location.


I'm glad it's finally merged. Good job!

Tomas



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

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


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

Re: [foreman-dev] Possible to move redmine Katello project under Foreman?

[Tomas Strachota]

On 08/03/2016 06:30 PM, Tom McKay wrote:



On Wed, Aug 3, 2016 at 10:26 AM, Lukas Zapletal > wrote:

> Is there a case for keeping katello separate any longer, or can we 
combine?

Because it's a plugin? And plugins have its own release cadence, own
planning (Release versions, Target versions) and Categories. I don't see
enough benefits of merging when I consider all the above.

I don't know, I would not like to see Discovery project merged into the
Core. I'd like to keep all plugins separate.


I'm suggesting that we make katello a subproject of foreman. There are
already plugin subprojects (eg. discovery). By moving it under the
single parent project other redmine features become usable (eg. loading
a sprint with issues from both foreman and katello).



+1 for moving it into a subproject and treating it the same as other 
plugins.



--
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] Hammer CLI Options for ID Resolution

[Tomas Strachota]

On 07/22/2016 09:01 PM, Andrew Kofink wrote:

Hi Team (especially Martin and Tomas),

I've been banging my head on the table for a few days now, so I thought
I would just ask:

I want to resolve a content view by its name; currently,
content_views#index has no required parameters, so no automatic options
are generated. I would like to add the option to search for the content
view by organization_id, and I also want hammer to add the options for
resolving that organization_id from the organization_name and
organization_label. Lastly, and probably most important, I want this to
happen any time the option --content-view-id is added to a command.

This works downstream because organization_id is a required parameter on
content_views#index, but upstream is currently broken due to a change in
the API that removes that requirement. Any thoughts?


Hi Andrew,
I don't think there's a simple way to achieve this across the whole 
hammer. You can either create a module with such behaviour and include 
it into each command that uses content views (annoying I know) or create 
a custom option builder for katello commands (descendant of [1]). It 
will probably require some tuning of the resolver too, but should give 
you what you want in the end.


T.

[1] 
https://github.com/theforeman/hammer-cli-foreman/blob/master/lib/hammer_cli_foreman/option_builders.rb#L103




Regards,

Andrew Kofink

​akofink on IRC​
Software Engineering Intern
Red Hat Satellite 6
akof...@redhat.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.


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

[Tomas Strachota]

On 05/31/2016 05:02 PM, Dominic Cleal wrote:

On 31/05/16 15:03, Dominic Cleal wrote:

In preparation for the first 1.12 release candidate, I've branched the
develop branch on these repos to 1.12-stable: foreman, smart-proxy,
foreman-installer, foreman-selinux, community-templates, foreman-packaging.

I'd like to be able to release RC1 in the next week or so, and would
love some help to get the following items complete:

1) Fixing regressions in 1.12:
http://projects.theforeman.org/projects/foreman/issues?query_id=99
https://github.com/theforeman/foreman/labels/1.12.0

2) Documenting 1.12 changes - we've got lots of Puppet and smart proxy
changes to document in this release. The full task list is at:
https://github.com/theforeman/theforeman.org/issues/555

3) Installer releases - we need to start releasing new major/minor
versions of our installer modules to the Forge. I think they're mostly
ready.


4) Hammer CLI releases - currently we'll be shipping Hammer CLI 0.6.1
with 0.6.2 of hammer_cli_foreman, but if a new version could be cut from
master if there's something to release, these can be updated.


There are some changes worth releasing. I'll do 0.7 this week.



5) Translations - the Transifex resource for Foreman itself now points
to the 1.12-stable branch and will be updated tomorrow with what should
be a pretty much final set of strings to translate.



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