I posted a bug [1] which I may be able to resolve with a PR, and I have not
contributed to Foreman since before 1.0. I am hoping someone can help me
ensure this changes continue working via regression tests. I am familiar
with RSpec from the context of some Ruby on Rails development but mostly
with Puppet module development. I setup a CentOS 6.5 VM and installed RVM
with latest ruby-1.9.3. I've run the tests documented on the wiki [2] but
am getting a huge amount of failures without making any changes. My branch
is tracking the upstream 1.4-stable branch.
I am seeing Functional and Unit tests with "3 failures, 56 errors" and
Integration Tests "0 failures, 14 errors". The errors in full are
at http://pastebin.com/n4H1p557.
Is this expected?
The files I'm changing are app/models/concerns/orchestration/dns.rb
and app/models/nic/managed.rb. Maybe a pointer as to which functional and
integration test files I should focus on would be helpful since the tests
fail before my changes.
Thanks,
[1] Bug #4599: Managed interfaces do not create proper DNS records - Foreman
[2] Test environment - Foreman
Our test suite needs both organisations and locations enabled to run
without any errors (since it tests both), it looks like your test
failures all relate to this area.
In config/settings.yaml, enable both features and try re-running the tests.
Thanks for working on a patch, I look forward to your contributions!
···
On 19/03/14 15:33, Trey Dockendorf wrote:
> I posted a bug [1] which I may be able to resolve with a PR, and I have
> not contributed to Foreman since before 1.0. I am hoping someone can
> help me ensure this changes continue working via regression tests. I am
> familiar with RSpec from the context of some Ruby on Rails development
> but mostly with Puppet module development. I setup a CentOS 6.5 VM and
> installed RVM with latest ruby-1.9.3. I've run the tests documented on
> the wiki [2] but am getting a huge amount of failures without making any
> changes. My branch is tracking the upstream 1.4-stable branch.
>
> I am seeing Functional and Unit tests with "3 failures, 56 errors" and
> Integration Tests "0 failures, 14 errors". The errors in full are
> at http://pastebin.com/n4H1p557.
>
> Is this expected?
>
> The files I'm changing are app/models/concerns/orchestration/dns.rb
> and app/models/nic/managed.rb. Maybe a pointer as to which functional
> and integration test files I should focus on would be helpful since the
> tests fail before my changes.
>
> Thanks,
> - Trey
>
> [1] http://projects.theforeman.org/issues/4599
> [2] http://projects.theforeman.org/projects/foreman/wiki/Test_environment
–
Dominic Cleal
Red Hat Engineering
That seemed to do it, thanks.
Updated the wiki page 1 to mention those configuration values.
The issue I'm hoping to resolve with lack of FQDN being passed to Smart
Proxies for DNS and DHCP does not currently seem to be tested in the
regression tests. I applied my initial patch to the code and the tests
still pass. Do the current unit or functional tests work for
testing Orchestration::DNS ?
What's the best way to get input regarding my patch and the associated
tests? Would like to ensure the tests I'm adding fail without my patch and
pass with my patch.
Thanks
···
On Wednesday, March 19, 2014 10:35:56 AM UTC-5, Dominic Cleal wrote:
>
> On 19/03/14 15:33, Trey Dockendorf wrote:
> > I posted a bug [1] which I may be able to resolve with a PR, and I have
> > not contributed to Foreman since before 1.0. I am hoping someone can
> > help me ensure this changes continue working via regression tests. I am
> > familiar with RSpec from the context of some Ruby on Rails development
> > but mostly with Puppet module development. I setup a CentOS 6.5 VM and
> > installed RVM with latest ruby-1.9.3. I've run the tests documented on
> > the wiki [2] but am getting a huge amount of failures without making any
> > changes. My branch is tracking the upstream 1.4-stable branch.
> >
> > I am seeing Functional and Unit tests with "3 failures, 56 errors" and
> > Integration Tests "0 failures, 14 errors". The errors in full are
> > at http://pastebin.com/n4H1p557.
> >
> > Is this expected?
> >
> > The files I'm changing are app/models/concerns/orchestration/dns.rb
> > and app/models/nic/managed.rb. Maybe a pointer as to which functional
> > and integration test files I should focus on would be helpful since the
> > tests fail before my changes.
> >
> > Thanks,
> > - Trey
> >
> > [1] http://projects.theforeman.org/issues/4599
> > [2]
> http://projects.theforeman.org/projects/foreman/wiki/Test_environment
>
> Our test suite needs both organisations and locations enabled to run
> without any errors (since it tests both), it looks like your test
> failures all relate to this area.
>
> In config/settings.yaml, enable both features and try re-running the
> tests.
>
> Thanks for working on a patch, I look forward to your contributions!
>
> --
> Dominic Cleal
> Red Hat Engineering
>
Hi Trey,
You'll find some tests in test/unit/orchestration/dhcp_test.rb and
dns_test.rb, but they don't go particularly deep. They mostly seem to
test the logic around whether tasks should be queued.
It should be possible to unit test the set*/del* methods too which
perform the tasks, but I can't see any examples. The general principles
of using .stubs and .expects to check their behaviour before calling the
method on a host or NIC object should apply though.
In an ideal world you can write the tests first, but otherwise I'd
suggest using "git stash -p". git stash will literally stash away some
changes so they're not in your working tree or the git history - so you
could stash your changes to app/, leaving just the tests present which
you can run to make sure they're failing.
Cheers,
···
--
Dominic Cleal
Red Hat Engineering
On 19/03/14 18:05, Trey Dockendorf wrote:
That seemed to do it, thanks.
Updated the wiki page 1 to mention those configuration values.
The issue I’m hoping to resolve with lack of FQDN being passed to Smart
Proxies for DNS and DHCP does not currently seem to be tested in the
regression tests. I applied my initial patch to the code and the tests
still pass. Do the current unit or functional tests work for
testing Orchestration::DNS ?
What’s the best way to get input regarding my patch and the associated
tests? Would like to ensure the tests I’m adding fail without my patch
and pass with my patch.
Thanks
On Wednesday, March 19, 2014 10:35:56 AM UTC-5, Dominic Cleal wrote:
On 19/03/14 15:33, Trey Dockendorf wrote:
> I posted a bug [1] which I may be able to resolve with a PR, and I
have
> not contributed to Foreman since before 1.0. I am hoping someone can
> help me ensure this changes continue working via regression tests.
I am
> familiar with RSpec from the context of some Ruby on Rails
development
> but mostly with Puppet module development. I setup a CentOS 6.5
VM and
> installed RVM with latest ruby-1.9.3. I've run the tests
documented on
> the wiki [2] but am getting a huge amount of failures without
making any
> changes. My branch is tracking the upstream 1.4-stable branch.
>
> I am seeing Functional and Unit tests with "3 failures, 56 errors"
and
> Integration Tests "0 failures, 14 errors". The errors in full are
> at http://pastebin.com/n4H1p557.
>
> Is this expected?
>
> The files I'm changing are app/models/concerns/orchestration/dns.rb
> and app/models/nic/managed.rb. Maybe a pointer as to which
functional
> and integration test files I should focus on would be helpful
since the
> tests fail before my changes.
>
> Thanks,
> - Trey
>
> [1] http://projects.theforeman.org/issues/4599
<http://projects.theforeman.org/issues/4599>
> [2]
http://projects.theforeman.org/projects/foreman/wiki/Test_environment <http://projects.theforeman.org/projects/foreman/wiki/Test_environment>
Our test suite needs both organisations and locations enabled to run
without any errors (since it tests both), it looks like your test
failures all relate to this area.
In config/settings.yaml, enable both features and try re-running the
tests.
Thanks for working on a patch, I look forward to your contributions!
--
Dominic Cleal
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+unsubscribe@googlegroups.com
mailto:foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Dominic,
I was able to write some basic tests against the BMC fixtures in
test/unit/orchestration/dns_test.rb that validate the changes. I have
been unable to add fixtures for Nic::Managed objects. I've tried
various tricks, including adding a new test at
'test/unit/nic_managed_test.rb' and calling 'set_fixture_class :nics
=> Nic::Managed' at the top of that class. The tests run by
themselves work fine (rake test:nic_managed), but when I run the full
test (rake test) I get errors [1] that appear to be a complication
with Rails testing and STI models.
The set*/del* methods you referred to, those are part of
Net::DNS::ARecord and Net::DNS::PTRRecord, or some other class?
Thanks for the idea of using 'git stash'.
[1]:
NicManagedTest#test_0003_Nic::Managed should have hostname containing
domain name:
ActiveRecord::RecordNotFound: Couldn't find Nic::BMC with id=888466653
[WHERE "nics"."type" IN ('Nic::BMC')]
···
On Thu, Mar 20, 2014 at 3:53 AM, Dominic Cleal wrote:
> Hi Trey,
>
> You'll find some tests in test/unit/orchestration/dhcp_test.rb and
> dns_test.rb, but they don't go particularly deep. They mostly seem to
> test the logic around whether tasks should be queued.
>
> It should be possible to unit test the set*/del* methods too which
> perform the tasks, but I can't see any examples. The general principles
> of using .stubs and .expects to check their behaviour before calling the
> method on a host or NIC object should apply though.
>
> In an ideal world you can write the tests first, but otherwise I'd
> suggest using "git stash -p". git stash will literally stash away some
> changes so they're not in your working tree or the git history - so you
> could stash your changes to app/, leaving just the tests present which
> you can run to make sure they're failing.
>
> Cheers,
>
> --
> Dominic Cleal
> Red Hat Engineering
>
> On 19/03/14 18:05, Trey Dockendorf wrote:
>> That seemed to do it, thanks.
>>
>> Updated the wiki page [1] to mention those configuration values.
>>
>> The issue I'm hoping to resolve with lack of FQDN being passed to Smart
>> Proxies for DNS and DHCP does not currently seem to be tested in the
>> regression tests. I applied my initial patch to the code and the tests
>> still pass. Do the current unit or functional tests work for
>> testing Orchestration::DNS ?
>>
>> What's the best way to get input regarding my patch and the associated
>> tests? Would like to ensure the tests I'm adding fail without my patch
>> and pass with my patch.
>>
>> Thanks
>> - Trey
>>
>> [1]: http://projects.theforeman.org/projects/foreman/wiki/Test_environment
>>
>> On Wednesday, March 19, 2014 10:35:56 AM UTC-5, Dominic Cleal wrote:
>>
>> On 19/03/14 15:33, Trey Dockendorf wrote:
>> > I posted a bug [1] which I may be able to resolve with a PR, and I
>> have
>> > not contributed to Foreman since before 1.0. I am hoping someone can
>> > help me ensure this changes continue working via regression tests.
>> I am
>> > familiar with RSpec from the context of some Ruby on Rails
>> development
>> > but mostly with Puppet module development. I setup a CentOS 6.5
>> VM and
>> > installed RVM with latest ruby-1.9.3. I've run the tests
>> documented on
>> > the wiki [2] but am getting a huge amount of failures without
>> making any
>> > changes. My branch is tracking the upstream 1.4-stable branch.
>> >
>> > I am seeing Functional and Unit tests with "3 failures, 56 errors"
>> and
>> > Integration Tests "0 failures, 14 errors". The errors in full are
>> > at http://pastebin.com/n4H1p557.
>> >
>> > Is this expected?
>> >
>> > The files I'm changing are app/models/concerns/orchestration/dns.rb
>> > and app/models/nic/managed.rb. Maybe a pointer as to which
>> functional
>> > and integration test files I should focus on would be helpful
>> since the
>> > tests fail before my changes.
>> >
>> > Thanks,
>> > - Trey
>> >
>> > [1] http://projects.theforeman.org/issues/4599
>>
>> > [2]
>> http://projects.theforeman.org/projects/foreman/wiki/Test_environment
>>
>>
>> Our test suite needs both organisations and locations enabled to run
>> without any errors (since it tests both), it looks like your test
>> failures all relate to this area.
>>
>> In config/settings.yaml, enable both features and try re-running the
>> tests.
>>
>> Thanks for working on a patch, I look forward to your contributions!
>>
>> --
>> Dominic Cleal
>> 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+unsubscribe@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "foreman-dev" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/foreman-dev/afs2AyuehtU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Hi Trey,
Have a look at test/test_helper.rb:43, it appears that the "nics"
fixtures are forced to BMC here. It might be best to create a second
fixtures file for the Nic::Managed instances and add a similar line, or
perhaps we can even remove that entirely, I'm not sure if it serves a
purpose here.
The set/del methods are in the Orchestration concerns, so
app/models/concerns/orchestration/dhcp.rb and similar. When the host or
NIC is saved, the queue_dhcp method is called which checks that this
orchestration type is relevant and then calls either the create or
update method, which queues the appropriate tasks.
When the tasks run, they call set_dhcp or del_dhcp (see the :action bit
of the task registration) and it's these methods (which are present on
the NIC or Host object) that you could call directly to test their
behaviour. For example (untested…):
test "#set_dhcp creates a DHCP record"
record = mock("dhcp record")
record.expects(:create)
h = host(:example)
h.expects(:dhcp_record).returns(record)
h.set_dhcp
end
Or if you're just changing how the Net::DNS::ARecord etc are created,
you could simply .dns_a_record and check the object coming back.
Cheers,
···
--
Dominic Cleal
Red Hat Engineering
On 21/03/14 15:38, Trey Dockendorf wrote:
Dominic,
I was able to write some basic tests against the BMC fixtures in
test/unit/orchestration/dns_test.rb that validate the changes. I have
been unable to add fixtures for Nic::Managed objects. I’ve tried
various tricks, including adding a new test at
’test/unit/nic_managed_test.rb’ and calling ‘set_fixture_class :nics
=> Nic::Managed’ at the top of that class. The tests run by
themselves work fine (rake test:nic_managed), but when I run the full
test (rake test) I get errors 1 that appear to be a complication
with Rails testing and STI models.
The set*/del* methods you referred to, those are part of
Net::DNS::ARecord and Net::DNS::PTRRecord, or some other class?
Thanks for the idea of using ‘git stash’.
1:
NicManagedTest#test_0003_Nic::Managed should have hostname containing
domain name:
ActiveRecord::RecordNotFound: Couldn’t find Nic::BMC with id=888466653
[WHERE “nics”.“type” IN (‘Nic::BMC’)]
On Thu, Mar 20, 2014 at 3:53 AM, Dominic Cleal dcleal@redhat.com wrote:
Hi Trey,
You’ll find some tests in test/unit/orchestration/dhcp_test.rb and
dns_test.rb, but they don’t go particularly deep. They mostly seem to
test the logic around whether tasks should be queued.
It should be possible to unit test the set*/del* methods too which
perform the tasks, but I can’t see any examples. The general principles
of using .stubs and .expects to check their behaviour before calling the
method on a host or NIC object should apply though.
In an ideal world you can write the tests first, but otherwise I’d
suggest using “git stash -p”. git stash will literally stash away some
changes so they’re not in your working tree or the git history - so you
could stash your changes to app/, leaving just the tests present which
you can run to make sure they’re failing.
Cheers,
–
Dominic Cleal
Red Hat Engineering
On 19/03/14 18:05, Trey Dockendorf wrote:
That seemed to do it, thanks.
Updated the wiki page 1 to mention those configuration values.
The issue I’m hoping to resolve with lack of FQDN being passed to Smart
Proxies for DNS and DHCP does not currently seem to be tested in the
regression tests. I applied my initial patch to the code and the tests
still pass. Do the current unit or functional tests work for
testing Orchestration::DNS ?
What’s the best way to get input regarding my patch and the associated
tests? Would like to ensure the tests I’m adding fail without my patch
and pass with my patch.
Thanks
On Wednesday, March 19, 2014 10:35:56 AM UTC-5, Dominic Cleal wrote:
On 19/03/14 15:33, Trey Dockendorf wrote:
> I posted a bug [1] which I may be able to resolve with a PR, and I
have
> not contributed to Foreman since before 1.0. I am hoping someone can
> help me ensure this changes continue working via regression tests.
I am
> familiar with RSpec from the context of some Ruby on Rails
development
> but mostly with Puppet module development. I setup a CentOS 6.5
VM and
> installed RVM with latest ruby-1.9.3. I've run the tests
documented on
> the wiki [2] but am getting a huge amount of failures without
making any
> changes. My branch is tracking the upstream 1.4-stable branch.
>
> I am seeing Functional and Unit tests with "3 failures, 56 errors"
and
> Integration Tests "0 failures, 14 errors". The errors in full are
> at http://pastebin.com/n4H1p557.
>
> Is this expected?
>
> The files I'm changing are app/models/concerns/orchestration/dns.rb
> and app/models/nic/managed.rb. Maybe a pointer as to which
functional
> and integration test files I should focus on would be helpful
since the
> tests fail before my changes.
>
> Thanks,
> - Trey
>
> [1] http://projects.theforeman.org/issues/4599
<http://projects.theforeman.org/issues/4599>
> [2]
http://projects.theforeman.org/projects/foreman/wiki/Test_environment <http://projects.theforeman.org/projects/foreman/wiki/Test_environment>
Our test suite needs both organisations and locations enabled to run
without any errors (since it tests both), it looks like your test
failures all relate to this area.
In config/settings.yaml, enable both features and try re-running the
tests.
Thanks for working on a patch, I look forward to your contributions!
--
Dominic Cleal
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+unsubscribe@googlegroups.com
mailto:foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
You received this message because you are subscribed to a topic in the Google Groups “foreman-dev” group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/foreman-dev/afs2AyuehtU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
The fixtures with STI are very odd. If I added " set_fixture_class
:nics_managed => Nic::Managed" below the Nic::BMC line mentioned, then
create the nics_managed.yml file, running 'RAILS_ENV=test rake
test:nic' results in tests using the "nics()" fixture method fail.
ActiveRecord::RecordNotFound: Couldn't find Nic::BMC with id=374923053
[WHERE "nics"."type" IN ('Nic::BMC')]
I've pushed what I have so far,
https://github.com/treydock/foreman/tree/4599-fix_hostname_used_for_dns_and_dhcp.
Any input or suggestions to make the Nic subclass tests work would be
great.
I can make the tests and fixtures work as long as I only test the
Nic::BMC class, not both Nic::BMC and Nic::Managed.
Thanks,
···
On Fri, Mar 21, 2014 at 12:06 PM, Dominic Cleal wrote:
> Hi Trey,
>
> Have a look at test/test_helper.rb:43, it appears that the "nics"
> fixtures are forced to BMC here. It might be best to create a second
> fixtures file for the Nic::Managed instances and add a similar line, or
> perhaps we can even remove that entirely, I'm not sure if it serves a
> purpose here.
>
> The set/del methods are in the Orchestration concerns, so
> app/models/concerns/orchestration/dhcp.rb and similar. When the host or
> NIC is saved, the queue_dhcp method is called which checks that this
> orchestration type is relevant and then calls either the create or
> update method, which queues the appropriate tasks.
>
> When the tasks run, they call set_dhcp or del_dhcp (see the :action bit
> of the task registration) and it's these methods (which are present on
> the NIC or Host object) that you could call directly to test their
> behaviour. For example (untested..):
>
> test "#set_dhcp creates a DHCP record"
> record = mock("dhcp record")
> record.expects(:create)
> h = host(:example)
> h.expects(:dhcp_record).returns(record)
> h.set_dhcp
> end
>
> Or if you're just changing how the Net::DNS::ARecord etc are created,
> you could simply .dns_a_record and check the object coming back.
>
> Cheers,
>
> --
> Dominic Cleal
> Red Hat Engineering
>
> On 21/03/14 15:38, Trey Dockendorf wrote:
>> Dominic,
>>
>> I was able to write some basic tests against the BMC fixtures in
>> test/unit/orchestration/dns_test.rb that validate the changes. I have
>> been unable to add fixtures for Nic::Managed objects. I've tried
>> various tricks, including adding a new test at
>> 'test/unit/nic_managed_test.rb' and calling 'set_fixture_class :nics
>> => Nic::Managed' at the top of that class. The tests run by
>> themselves work fine (rake test:nic_managed), but when I run the full
>> test (rake test) I get errors [1] that appear to be a complication
>> with Rails testing and STI models.
>>
>> The set*/del* methods you referred to, those are part of
>> Net::DNS::ARecord and Net::DNS::PTRRecord, or some other class?
>>
>> Thanks for the idea of using 'git stash'.
>>
>> - Trey
>>
>> [1]:
>>
>> NicManagedTest#test_0003_Nic::Managed should have hostname containing
>> domain name:
>> ActiveRecord::RecordNotFound: Couldn't find Nic::BMC with id=888466653
>> [WHERE "nics"."type" IN ('Nic::BMC')]
>>
>>
>> On Thu, Mar 20, 2014 at 3:53 AM, Dominic Cleal wrote:
>>> Hi Trey,
>>>
>>> You'll find some tests in test/unit/orchestration/dhcp_test.rb and
>>> dns_test.rb, but they don't go particularly deep. They mostly seem to
>>> test the logic around whether tasks should be queued.
>>>
>>> It should be possible to unit test the set*/del* methods too which
>>> perform the tasks, but I can't see any examples. The general principles
>>> of using .stubs and .expects to check their behaviour before calling the
>>> method on a host or NIC object should apply though.
>>>
>>> In an ideal world you can write the tests first, but otherwise I'd
>>> suggest using "git stash -p". git stash will literally stash away some
>>> changes so they're not in your working tree or the git history - so you
>>> could stash your changes to app/, leaving just the tests present which
>>> you can run to make sure they're failing.
>>>
>>> Cheers,
>>>
>>> --
>>> Dominic Cleal
>>> Red Hat Engineering
>>>
>>> On 19/03/14 18:05, Trey Dockendorf wrote:
>>>> That seemed to do it, thanks.
>>>>
>>>> Updated the wiki page [1] to mention those configuration values.
>>>>
>>>> The issue I'm hoping to resolve with lack of FQDN being passed to Smart
>>>> Proxies for DNS and DHCP does not currently seem to be tested in the
>>>> regression tests. I applied my initial patch to the code and the tests
>>>> still pass. Do the current unit or functional tests work for
>>>> testing Orchestration::DNS ?
>>>>
>>>> What's the best way to get input regarding my patch and the associated
>>>> tests? Would like to ensure the tests I'm adding fail without my patch
>>>> and pass with my patch.
>>>>
>>>> Thanks
>>>> - Trey
>>>>
>>>> [1]: http://projects.theforeman.org/projects/foreman/wiki/Test_environment
>>>>
>>>> On Wednesday, March 19, 2014 10:35:56 AM UTC-5, Dominic Cleal wrote:
>>>>
>>>> On 19/03/14 15:33, Trey Dockendorf wrote:
>>>> > I posted a bug [1] which I may be able to resolve with a PR, and I
>>>> have
>>>> > not contributed to Foreman since before 1.0. I am hoping someone can
>>>> > help me ensure this changes continue working via regression tests.
>>>> I am
>>>> > familiar with RSpec from the context of some Ruby on Rails
>>>> development
>>>> > but mostly with Puppet module development. I setup a CentOS 6.5
>>>> VM and
>>>> > installed RVM with latest ruby-1.9.3. I've run the tests
>>>> documented on
>>>> > the wiki [2] but am getting a huge amount of failures without
>>>> making any
>>>> > changes. My branch is tracking the upstream 1.4-stable branch.
>>>> >
>>>> > I am seeing Functional and Unit tests with "3 failures, 56 errors"
>>>> and
>>>> > Integration Tests "0 failures, 14 errors". The errors in full are
>>>> > at http://pastebin.com/n4H1p557.
>>>> >
>>>> > Is this expected?
>>>> >
>>>> > The files I'm changing are app/models/concerns/orchestration/dns.rb
>>>> > and app/models/nic/managed.rb. Maybe a pointer as to which
>>>> functional
>>>> > and integration test files I should focus on would be helpful
>>>> since the
>>>> > tests fail before my changes.
>>>> >
>>>> > Thanks,
>>>> > - Trey
>>>> >
>>>> > [1] http://projects.theforeman.org/issues/4599
>>>>
>>>> > [2]
>>>> http://projects.theforeman.org/projects/foreman/wiki/Test_environment
>>>>
>>>>
>>>> Our test suite needs both organisations and locations enabled to run
>>>> without any errors (since it tests both), it looks like your test
>>>> failures all relate to this area.
>>>>
>>>> In config/settings.yaml, enable both features and try re-running the
>>>> tests.
>>>>
>>>> Thanks for working on a patch, I look forward to your contributions!
>>>>
>>>> --
>>>> Dominic Cleal
>>>> 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+unsubscribe@googlegroups.com
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the Google Groups "foreman-dev" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/topic/foreman-dev/afs2AyuehtU/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to foreman-dev+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "foreman-dev" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/foreman-dev/afs2AyuehtU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
