All,
This is a small thing, but it can mean one less papercut when running tests on Conductor.
The gist of it is, that the tests rely on Deltacloud mock instance running on port 3001, while aeolus-configure sets up one on 3002.
That causes 2 things: first, everybody who runs the tests for the first time sees a bunch of failures because they don't have the mock server running.
Second, they learn to run one, even though it's unnecessary since there is a mock server up and ready just a port_num++ away.
Is there a reason why we wouldn't want the tests to look for the port 3002 instead of 3001? And is there reason worth the confusion to newcommers?
Please, let me know what you think.
Thomas
From: Tomas Sedovic tsedovic@redhat.com
This tends to trip people up: aeolus-configure sets up a Deltacloud server with the Mock driver on the port 3002.
However, our tests look for the mock dc instance on 3001, which means that to run the tests, one must start another Mock Deltacloud server.
This makes tests use 3002 instead. Therefore, if you have the Conductor set up for production (e.g. installed from RPMs), the tests will use the Deltacloud server that came with it.
Otherwise, you'll still have to start it manually -- listening on the port 3002 from now on. --- src/features/provider.feature | 8 ++++---- src/spec/factories/provider.rb | 12 ++---------- 2 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/src/features/provider.feature b/src/features/provider.feature index ef89ea5..78f4de8 100644 --- a/src/features/provider.feature +++ b/src/features/provider.feature @@ -35,9 +35,9 @@ Feature: Manage Providers And each provider should have "provider_type" And there should be these provider: | name | url | provider_type | - | provider1 | http://localhost:3001/api | mock | - | provider2 | http://localhost:3001/api | mock | - | provider3 | http://localhost:3001/api | mock | + | provider1 | http://localhost:3002/api | mock | + | provider2 | http://localhost:3002/api | mock | + | provider3 | http://localhost:3002/api | mock |
Scenario: Show provider details Given there is a provider named "testprovider" @@ -52,7 +52,7 @@ Feature: Manage Providers When I follow "New Provider" Then I should be on the new provider page When I fill in "provider[name]" with "testprovider" - And I fill in "provider[url]" with "http://localhost:3001/api" + And I fill in "provider[url]" with "http://localhost:3002/api" And I select "Amazon EC2" from "provider_provider_type_id" And I press "Save" Then I should be on the providers page diff --git a/src/spec/factories/provider.rb b/src/spec/factories/provider.rb index 243a7e4..e10a879 100644 --- a/src/spec/factories/provider.rb +++ b/src/spec/factories/provider.rb @@ -6,7 +6,7 @@ end
Factory.define :mock_provider, :parent => :provider do |p| p.provider_type {ProviderType.find_by_codename("mock")} - p.url 'http://localhost:3001/api' + p.url 'http://localhost:3002/api' p.hardware_profiles { |hp| [hp.association(:mock_hwp1), hp.association(:mock_hwp2)] } p.after_create { |p| p.realms << Factory(:realm1, :provider => p) << Factory(:realm2, :provider => p) } end @@ -14,21 +14,13 @@ end Factory.define :mock_provider2, :parent => :provider do |p| p.name 'mock2' p.provider_type { ProviderType.find_by_codename("mock") } - p.url 'http://localhost:3001/api' + p.url 'http://localhost:3002/api' p.after_create { |p| p.realms << Factory(:realm3, :provider => p) } end
Factory.define :ec2_provider, :parent => :provider do |p| p.name 'amazon-ec2' p.provider_type { ProviderType.find_by_codename("ec2") } - p.url 'http://localhost:3001/api' - p.hardware_profiles { |hp| [hp.association(:ec2_hwp1)] } - p.after_create { |p| p.realms << Factory(:realm4, :provider => p) } -end - -Factory.define :ec2_provider_no_builds, :parent => :provider do |p| - p.name 'amazon-ec2-no-builds' - p.provider_type { ProviderType.find_by_codename("ec2") } p.url 'http://localhost:3002/api' p.hardware_profiles { |hp| [hp.association(:ec2_hwp1)] } p.after_create { |p| p.realms << Factory(:realm4, :provider => p) }
Hi Tomas,
On Tue, 2011-07-26 at 16:54 +0200, tsedovic@redhat.com wrote:
From: Tomas Sedovic tsedovic@redhat.com
This tends to trip people up: aeolus-configure sets up a Deltacloud server with the Mock driver on the port 3002.
However, our tests look for the mock dc instance on 3001, which means that to run the tests, one must start another Mock Deltacloud server.
This makes tests use 3002 instead. Therefore, if you have the Conductor set up for production (e.g. installed from RPMs), the tests will use the Deltacloud server that came with it.
Otherwise, you'll still have to start it manually -- listening on the port 3002 from now on.
Snap! Pretty much identical to my "Use port 3002 for mock provider in tests", so ACK :-)
(Could you ACK my other patches?)
Factory.define :ec2_provider, :parent => :provider do |p| p.name 'amazon-ec2' p.provider_type { ProviderType.find_by_codename("ec2") }
- p.url 'http://localhost:3001/api'
- p.hardware_profiles { |hp| [hp.association(:ec2_hwp1)] }
- p.after_create { |p| p.realms << Factory(:realm4, :provider => p) }
-end
-Factory.define :ec2_provider_no_builds, :parent => :provider do |p|
- p.name 'amazon-ec2-no-builds'
- p.provider_type { ProviderType.find_by_codename("ec2") } p.url 'http://localhost:3002/api' p.hardware_profiles { |hp| [hp.association(:ec2_hwp1)] } p.after_create { |p| p.realms << Factory(:realm4, :provider => p) }
I didn't have this bit, but it looks like :ec2_provider_no_builds is unused for a long time now ... so this is fine
Thanks, Mark.
On 27/07/2011, at 1:35 AM, Mark McLoughlin wrote: <snip>
This tends to trip people up: aeolus-configure sets up a Deltacloud server with the Mock driver on the port 3002.
However, our tests look for the mock dc instance on 3001, which means that to run the tests, one must start another Mock Deltacloud server.
Quickly trying out Mock in the 0.3.0 RHEL 6.1 release rpms, and it's broken "out of the box". :(
Both /etc/init.d/deltacloud-core and /etc/init.d/deltacloud-mock are set to use port 3002. The core one starts first, so the mock one silently fails. (!). Changing the port number to 3005 for mock in the mock startup script, then adjusting the port through the Conductor UI (mock provider account) lets it work.
So, is the -core startup script wrong, or the -mock startup one? If the -mock one is wrong, we'll need to move the mock port from 3002 anyway.
Regards and best wishes,
Justin Clift
-- Aeolus Community Manager http://www.aeolusproject.org
On 07/28/2011 02:27 PM, Justin Clift wrote:
On 27/07/2011, at 1:35 AM, Mark McLoughlin wrote:
<snip> >> This tends to trip people up: aeolus-configure sets up a Deltacloud server >> with the Mock driver on the port 3002. >> >> However, our tests look for the mock dc instance on 3001, which means that to >> run the tests, one must start another Mock Deltacloud server.
Quickly trying out Mock in the 0.3.0 RHEL 6.1 release rpms, and it's broken "out of the box". :(
Both /etc/init.d/deltacloud-core and /etc/init.d/deltacloud-mock are set to use port 3002. The core one starts first, so the mock one silently fails. (!). Changing the port number to 3005 for mock in the mock startup script, then adjusting the port through the Conductor UI (mock provider account) lets it work.
So, is the -core startup script wrong, or the -mock startup one? If the -mock one is wrong, we'll need to move the mock port from 3002 anyway.
I checked this on my Fedora setup and I have both -core and -mock init scripts there. They're both using 3002, but according to chkconfig deltacloud-core doen't get started automatically.
In addition to that, I have deltacloud-ec2-us-east-1 and deltacloud-ec2-us-west-1 scripts, each with their own unique port.
This is what I think is going on: Conductor uses separate deltacloud daemons for mock, ec2-east and ec2-west locations. These get in when the user installs the RPMs and runs aeolus-configure.
Deltacloud-core comes with the deltacloud-core RPM (a package Conductor depends on) and happens to use the same port as our mock by default.
When we install Conductor, aeolus-configure makes sure the vanilla deltacloud-core is stopped and we set up our own services.
I think it's unfortunate that both mock and the vanilla core use the same port, but it shouldn't matter unless the user wants to start a separate core instance manually. In that case, they can change the ports as needed.
Anyway, the latest release of Deltacloud supports connecting to multiple providers on a single deltacloud instance listening on a single port.
After we start using that, we can use the vanilla deltacloud-core script and it will work for all the providers we want to connect to.
I'm not terribly familiar with this topic, however. Can someone from the aeolus-configure team elaborate?
Thomas
Regards and best wishes,
Justin Clift
-- Aeolus Community Manager http://www.aeolusproject.org
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
On 07/28/11 - 03:05:47PM, Tomas Sedovic wrote:
Anyway, the latest release of Deltacloud supports connecting to multiple providers on a single deltacloud instance listening on a single port.
After we start using that, we can use the vanilla deltacloud-core script and it will work for all the providers we want to connect to.
Right, I think we should switch to this on master ASAP. Which of course requires someone to go in and fix the conductor to do it.
That being said, we'll need to fix the bug in 0.3.0, because the above will probably be too invasive there. So we either need to move deltacloud-mock, or think of another (not invasive) solution.
On 07/28/2011 10:29 AM, Chris Lalancette wrote:
On 07/28/11 - 03:05:47PM, Tomas Sedovic wrote:
Anyway, the latest release of Deltacloud supports connecting to multiple providers on a single deltacloud instance listening on a single port.
After we start using that, we can use the vanilla deltacloud-core script and it will work for all the providers we want to connect to.
Right, I think we should switch to this on master ASAP. Which of course requires someone to go in and fix the conductor to do it.
That being said, we'll need to fix the bug in 0.3.0, because the above will probably be too invasive there. So we either need to move deltacloud-mock, or think of another (not invasive) solution.
Yes, there's no chance of us switching to multi-provider core in 0.3.0. This will require non-trivial model and UI changes. We definitely want this on the 0.4.0 roadmap, though.
Scott
On 28/07/2011, at 11:05 PM, Tomas Sedovic wrote:
I checked this on my Fedora setup and I have both -core and -mock init scripts there. They're both using 3002, but according to chkconfig deltacloud-core doen't get started automatically.
Just tried fresh installs of F14 and RHEL 6.1 (x64) in VM's. For both, using the public 0.3.0 "new stable" repo, both -core and -mock are enabled in run levels 3 and 5 after aeolus-configure:
$ sudo chkconfig --list | grep -i delta deltacloud-core 0:off 1:off 2:off 3:on 4:on 5:on 6:off deltacloud-ec2-us-east-1 0:off 1:off 2:on 3:on 4:on 5:on 6:off deltacloud-ec2-us-west-1 0:off 1:off 2:on 3:on 4:on 5:on 6:off deltacloud-mock 0:off 1:off 2:on 3:on 4:on 5:on 6:off
On the Fedora setup you checked, is there any chance it's not a fresh install?
Regards and best wishes,
Justin Clift
-- Aeolus Community Manager http://www.aeolusproject.org
aeolus-devel@lists.fedorahosted.org
-
Chris Lalancette -
Justin Clift -
Mark McLoughlin -
Scott Seago -
Tomas Sedovic