I added a bunch of (more) granular-level issues to
http://projects.theforeman.org/issues/3511 tracker.
Cheers,
-d
On Wed, Nov 22, 2017 at 2:13 PM, Dmitri Dolguikh
wrote:
> On Wed, Nov 22, 2017 at 9:33 AM, James Shewey wrote:
>
>> You may not be getting an ABRT because ruby was
On Wed, Nov 22, 2017 at 9:33 AM, James Shewey wrote:
> You may not be getting an ABRT because ruby was patched some time ago to
> catch this ABRT and a handler was created to make this a non-fatal error
> (ruby used to just core dump - see https://bugzilla.redhat.com/
> show_bug.cgi?id=717709). I
Do you have some examples how such an abort looks like with and without GDB?
with gdb + .gdbinit:
Program received signal SIGABRT, Aborted.
0x7fb45991e1f7 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig)
On Mon, Nov 20, 2017 at 2:05 AM, Lukas Zapletal wrote:
> Perhaps - can you bit elaborate the GDB
> thing? Is this some kind of hook that use used for FIPS stack to
> report "mistakes" (e.g. signal or exception when you attempt to use
> md5 hash)? I wonder if there is a way to catch these without
Another +1 from me -- quite like the UI, email integration seems to be (or
will be?) good enough. As long as the amount of maintenance isn't too big,
I think the move is a good idea.
-d
On Wed, Nov 15, 2017 at 7:05 AM, John Mitsch wrote:
> Also a +1 from me. Among other things, I like the catego
> Given we are targeting Rails 5.1 for the SCL we are building and it's the
> newest, does anything change here with using it?
>
The approach stays the same, I think. My bet would be the problems stay the
same too (i.e. use of MD5 in caches).
> I have heard that the teams that work on those back
What is FIPS?
>From Wikipedia [1]: The Federal Information Processing Standard (FIPS)
Publication 140-2, (FIPS PUB 140-2), is a U.S. government computer
security standard used to approve cryptographic modules. The title is
Security Requirements for Cryptographic Modules.
What are Implications of F
On Tue, Nov 7, 2017 at 12: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.
>
The only time tests should be deleted is when the functionality th
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
> * ...
>
>
Probably a re-hash of what most developers know, but I'm going to do this
an
> Today we package all required rubygems as RPMs and utilize a thirdparty
> Software Collection (SCL) for both the Ruby (rh-ruby22) and Rails stack
> (sclo-ror42). The team that manages the RHSCLs has already released Ruby
> 2.3 and RUby 2.4 SCLs and will continue to do so. However, there are no
>
Why not distribute the release process? Each component can have (probably
already does) multiple maintainers who are capable of doing most of the
leg-work. The role of the release nanny then becomes coordinating the
effort, making public announcements and such. Such an approach would help
avoid ove
On Sun, Aug 20, 2017 at 6:49 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:
> On Fri, Aug 18, 2017 at 12:48:06PM +0100, Greg Sutcliffe wrote:
>
>> Dominic Cleal:
>> - smart_proxy_dns_route53
>>
>
> I'd like to get added to this plugin.
>
> Ewoud Kohl van Wijngaarden:
>> - sma
FWIW, the approach I arrived at for smart-proxy plugins:
- Explain the original developer their options for hosting the plugin
(i.e. within Foreman github organization, and outside of it, and what
each option entails). The former implies that Foreman developers have
a say over technical matters t
On Tue, Apr 4, 2017 at 7:18 PM, wrote:
>
> I have an alternative, although I am not sure it's better:
> We can introduce "reachability" concept to our subnets. Something that would
> say "You can get from subnet X to subnet Y".
That sounds very much like you are suggesting that Foreman maintains
On Wed, Mar 15, 2017 at 8:10 AM, Tomas Strachota wrote:
> On Tue, Mar 14, 2017 at 2:28 PM, Daniel Lobato 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 co
On Fri, Mar 10, 2017 at 4:45 PM, Ewoud Kohl van Wijngaarden
wrote:
> On Fri, Mar 10, 2017 at 02:40:04PM +0000, Dmitri Dolguikh wrote:
>> After thinking about support for ipv6 + dhcpv6 in smart-poxy and
>> Foreman some more, I realized that:
>>
>> - while host duid m
On Fri, Mar 10, 2017 at 3:02 PM, Perry Gagne wrote:
> It also worth mentioning Kea. Which is the ISC next generation DHCP server.
>
> http://kea.isc.org/wiki
>
I’m aware of Kea. Unfortunately, there is no management api and the
only way to integrate with it is via db (not sure how stable the
sche
ow (IPv6 is old how much, 20 years? :-)
>
> Since you already did great amount of investigation in the IPv6 field,
> do you want to give dnsmasq a look in this regard? If this turns out
> to be a good workaround, maybe the ISC IPv6 would not be so hot topic
> then (when I finish with
of in-memory host records, and it doesn’t support ipv6 at
>> >> all.
>> >
>> > Maybe I am confused. Are you trying to add support for fixed-address6 or
>> > trying to work around the support not being there?
>>
>> The latter.
>> -d
>>
>
I am confused. Are you trying to add support for fixed-address6 or
> trying to work around the support not being there?
The latter.
-d
>
> On Mon, Mar 6, 2017 at 11:32 AM, Dmitri Dolguikh
> wrote:
>>
>> On Mon, Mar 6, 2017 at 4:11 PM, Perry Gagne wrote:
>> >
On Tue, Mar 7, 2017 at 1:46 PM, Lukas Zapletal wrote:
> On Mon, Mar 6, 2017 at 4:53 PM, Dmitri Dolguikh wrote:
>> - It is difficult to determine host’s client id (dhcp unique identifier, AKA
>> DUID)
>
> What you mean by that? If sysadmins let DUID to change, they are
>
On Mon, Mar 6, 2017 at 4:11 PM, Perry Gagne wrote:
>
> Doesn't ISC DHCPD use " fixed-address6", "range6", etc for DHCPv6. The code
> you linked seems to be related to "fixed-address" which is the ipv4 variant.
>
This is definitely the case as far as ipv6-specific dhcpd
configuration goes. The cod
I'm working on adding support for IPv6/DHCPv6 on smart-proxy side, and
have come across several issues on which I'd like to hear your
thoughts.
- It is not possible to assign ipv6 addresses to host records
(reservations) when ISC dhcpd is used.
This is due to a limitation in host record serializa
I think this is a good idea; and it can be pushed into separating
templates into a standalone service which would handle the whole
template lifecycle, not just serving of pre-rendered templates (if
eventually).
Also agreed re: “built” ping, it’s a special call, although the
responsibility for coll
I opened a PR in foreman-infra that removes ruby 1.9.3 from test
matrix: https://github.com/theforeman/foreman-infra/pull/256.
-d
On Monday, November 7, 2016 at 11:41:13 AM UTC, Dmitri Dolguikh wrote:
>
> Awhile ago when we announced end of support for ruby 1.8.7 for
> smart-proxy
Awhile ago when we announced end of support for ruby 1.8.7 for
smart-proxy, we also announced that we’ll likely drop support for
1.9.3 too.
While we are no longer running tests against 1.8.7 in smart-proxy
development branch, we still have ruby 1.9.3 in the test matrix. I’d
like to remove 1.9.3 fr
Here’s a partial list of smart-proxy api:
http://projects.theforeman.org/projects/smart-proxy/wiki/API. Please
keep in mind that the list doesn’t include any of the non-core plugin
apis.
Cheers,
-Dmitri
On Fri, Sep 2, 2016 at 3:29 PM, 'Gennady Voronkov' via foreman-dev
wrote:
>
>>You can create
> 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:
>
> - automated, better docs than what we have (example
>http://petstore.swagger.io/#!/pet/updatePet)
> - automated tests to
On Mon, Aug 1, 2016 at 11:56 AM, Daniel Lobato Garcia
wrote:
> Sorry, I meant 'more complicated'. It's more complicated to
> migrate all the config files when we don't provide a simple script like we
> do for the Foreman database.
>
But we do, "rake migrate_settings" will migrate smart-proxy’s co
> The migration would be complicated for users who run TFTP/DHCP/DNS
> (etc..) on the same host.
Why would it be complicated? Backup config files, restore them on the
new machine and run migrations.
-d
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" g
I’d like to see development of new features stopped on EL6:
- no more random build breakages due to dependencies not supporting
1.8.7 and/or 1.9.3
- older releases are still available for those who prefer to stay on EL6
- Backup/restore procedures are documented, support for config file
migratio
Support for vendor options is currently broken in MS dhcp provider:
- Vendor options have to be created before they can be assigned
values. We create vendor classes if they don’t exist, but don’t do the
same for options.
- A lesser problem is the way we name vendor classes in MS dhcp
differs from
I think the home page we have atm contains *way* too much information
(three screens or even more?). Some of it is duplicated/too
similar/should be grouped together (why do we have “introduction”,
“quckstart”, and “get started”? Should we have both “documentation”
and “learn more” links?. Do we ne
33 matches
Mail list logo
