[PATCH Conductor] Adding a script for QE to test deployable parsing
by Greg Blomquist
This script allows QE to test the deployable parsing outside of the context of
Conductor. This will allow QE to test the Audrey components without requiring
Conductor to parse the deployable.
The reason this patch is in Conductor and not the Audrey repo is because all of
the DeployableXML parsing code lives in Conductor. A reasonable next step could
be to extract the DeployableXML parsing code into a separate component that
other pieces (including Conductor) can pull in as a library.
For the time being, however, in the interest of not duplicating code, this patch
goes to Conductor.
---
Greg
12 years, 7 months
RFC: Commit Access Policy
by Matt Wagner
Hi all,
After a bit of discussion this morning, we decided to consolidate
permissions for commit access on GitHub across our projects. I think
this was a great decision, because it makes management easier,
recognizes that many contributors contribute to multiple projects, and
makes us feel more like an integrated family of projects.
However, as I've been going through adding existing contributors that
were overlooked earlier in the day, I'm starting to wonder what our
policy is on handing out commit access. It was never terribly clear to
me, at least for Conductor. Now that it affects multiple projects, I
think we should develop a concrete policy. (Once we do so, I'll document
it somewhere.)
For the sake of getting the conversation moving, here is what I propose:
We grant commit access to anyone who has (a) sent at least one patch
that has passed on-list code review, or (b) is vouched for by an
existing contributor. If someone has met (a) or (b), any of the existing
project admins can add them without further input.
My thinking with the above is that:
a.) Having more people with commit rights is a good thing.
b.) The policy above is simple. There's no nomination process that will
drag on on the mailing lists, and no, "So-and-so is out of the office so
we have to wait until next week for them to vote" nonsense.
c.) It's not as if we have had problems with accidentally permitted
crazed lunatics to contribute code, or that we're trying to change an
onerous process that scares away contributors. It's just that as I get
asked to add people to the project, I want to make sure I'm acting on
behalf of the community.
Of course, the above is just my own opinion and I'd love to have others'
input here.
Best,
Matt
12 years, 7 months
[PATCH conductor 0/1] #2463 - Set I18n locale from ACCEPT_LANGUAGE - FWIW
by Matt Wagner
This is fairly random as I don't own #2463, but my mind was here the other day and I threw this together, so I thought I'd clean it up and send it. It might be helfpul; feel free to disregard if not. (In any case, this is all I plan to do on the I18n task unless asked to do more; I don't want to step on any toes.)
I sort of wonder if I'm missing something; it amazes me that this code wasn't native to our I18n implementation.
-- Matt
12 years, 7 months
UI widgets in Conductor
by Chris Alfonso
I know there have been several people on the team designing the conductor UI and I've got a question that is not intended to disrupt current work on widget and theme design; however, has there been decisions made regarding reusing the same jquery widgets across Conductor and Katello? It seems to me we can save a bit of time from widget design if we take this approach. The process of implementing a widget requires imagining layout and behavior, creating images that represent the ideas, slicing the images up and then figuring out how to implement the behavior takes A LOT of time. I'm not sure if anyone has specifically decided to not look for a similar UI problem in Katello and just use the same solution in Conductor (or vice versa if Conductor solves a similar problem before Katello does). I'm not suggesting UI look and feel unification, I know that is a discussion that has happened and decisions were made. I'm suggesting widget reuse.
The specific problem that got me thinking about this was, I had looked at Ken's deployable design at roughly the same time I installed the Katello application. The idea of contextual display in Katallo for a content Provider using a jquery widget was very similar to the problem of contextual display of a Catalogs images. I'm not knocking Ken's Conductor designs, they are indeed stellar. It's just that I know it takes a tremendous amount of work to get from idea to implementation. Does anyone on the list have strong feelings for or against taking the widget reuse approach?
- Chris
12 years, 7 months
Re: [PATCH 1/2] Fixed failing deployment cucumber test.
by Hugh O. Brock
Can we nuke that deltacloud 0.5.0 rpm from orbit? It is broken and should never be used.
-h
Jan Provaznik <jprovazn(a)redhat.com> wrote:
On 10/10/2011 06:26 PM, Scott Seago wrote:
> On 10/10/2011 10:46 AM, Petr Blaho wrote:
>> On Friday, October 07, 2011 10:26:50 PM Scott Seago wrote:
>>> From: Tomas Hrcka<thrcka(a)redhat.com>
>>>
>>> edited by Scott Seago<sseago(a)redhat.com>
>>>
>>> This requires mfojtik's HWP validation patch on deltacloud-core
>> (probably
>>> pushed by now).
>>>
>>> --
>>> ---
>>> .../step_definitions/hardware_profile_steps.rb | 12 +++---
>>> src/features/step_definitions/pool_steps.rb | 2 +
>>> src/features/step_definitions/provider_steps.rb | 2 +-
>>> src/spec/factories/hardware_profile.rb | 12 ++++++-
>>> src/spec/factories/hardware_profile_property.rb | 34
>>> ++++++++++++++++++-- src/spec/factories/provider.rb
>> |
>>> 4 ++
>>> 6 files changed, 54 insertions(+), 12 deletions(-)
>>>
>>>
>> diff --git a/src/spec/factories/hardware_profile_property.rb
>>> b/src/spec/factories/hardware_profile_property.rb index 9ddde28..5fd4032100644
>>> --- a/src/spec/factories/hardware_profile_property.rb
>>> +++ b/src/spec/factories/hardware_profile_property.rb
>>> @@ -81,6 +81,34 @@ FactoryGirl.define do
>>> value 'x86_64'
>>> end
>>>
>>> + factory :mock_hwp_fake_memory, :parent => :hardware_profile_property do
>>> + name 'memory'
>>> + kind 'fixed'
>>> + unit 'MB'
>>> + value 1740.8
>>> + end
>>> +
>>> + factory :mock_hwp_fake_storage, :parent => :hardware_profile_property do
>>> + name 'storage'
>>> + kind 'fixed'
>>> + unit 'GB'
>>> + value 160
>>> + end
>>> +
>>> + factory :mock_hwp_fake_cpu, :parent => :hardware_profile_property do
>>> + name 'cpu'
>>> + kind 'fixed'
>>> + unit 'count'
>>> + value 1
>>> + end
>>> +
>>> + factory :mock_hwp_fake_arch, :parent => :hardware_profile_property do
>>> + name 'architecture'
>>> + kind 'fixed'
>>> + unit 'label'
>>> + value 'x86_64'
>>> + end
>>> +
>>> factory :front_hwp1_memory, :parent => :hardware_profile_property do
>>> name 'memory'
>>> kind 'fixed'
>> CONDITIONAL ACK - change value in factory :mock_hwp1_storage to
>> 1024 - it is affected by one of jprovazn's patches pushed before.
>
> I'm not sure I understand this. mock_hwp1 corresponds to the actual
> m1-small hwp in the mock driver -- if I change it to 1024, won't the
> validation fail (since it's a fixed HWP value of 160, so trying to set
> the instance to 1024 on launch -- because our db thinks the hwp is 1024
> instead of 160 -- will be invalid.
>
> There's now mock_hwp_fake -- I had to add this since some of the tests
> were overloading the use of the hwp1/hwp2 which use real mock hwp names
> -- so perhaps that one should be 1024?
>
> Scott
>
It seems to be a problem on deltacloud-core side:
with deltacloud-core 0.5.0 (which we currently have in aeolus-testing
repo) it fails with: "Deltacloud::Validation::Failure - Parameter
hwp_storage has value 160 which is not in 1024, 2048, 4096".
When changed to 160 -> 1024 tests passed if I remember correctly.
With deltacloud-core 0.4.0 nightly build (which is actually newer
version than 0.5.0) the test passes with value 160.
ACK to your orig patch
Jan
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel
12 years, 7 months
[PATCH conductor 0/1] humanize_error helper / BZ 718122 (v2)
by Matt Wagner
I'd sent this the other day, but jzigmund NACK'ed it after noting that it actually didn't work at all. Whoops.
This version should be free of boneheaded errors.
I do NOT think this needs to make its way into our 0.4.0 release so prioritize accordingly.
-- Matt
12 years, 7 months
Proposal for sharing IDS (and other data) between Aeolus and Katello
by Bryan Kearney
Katello is getting requirements which require that we know if a given
system is being managed by Aeolus. Katello will already have an in
system agent that can collect facts. It seems like this is a valid way
to get one data store with the IDS from both systems in it. Once we have
that.. Bob's your uncle.
My propasl is this. During Boot time, audrey will drop the instance UUID
and any other data into
/etc/sysconfig/aeolus/facts
data stored in facts should be key/value where the filename is the key,
and the body of the file is the value. Therefore, the instance UUID
would be stored in:
/etc/sysconfig/aeolus/facts/instance_uuid
if the image uuid is also known, it could be dropped into:
/etc/sysconfig/aeolus/facts/image_uuid
Katello's agent (susbcription-manager) will look for files and record
them as facts:
aeolus_instance_uuid = XYZ
aeolus_image_uuid = PDQ
The absence of the files would be an indicator that this machine is not
managed by aeolus.
Seem ok?
-- bk
12 years, 7 months
iwhd-0.99 released [stable]
by Jim Meyering
Here's the latest version of iwhd.
iwhd is Aeolus' (http://aeolusproject.org/)
rule-based cloud-to-cloud image manager.
See the NEWS section below for most of what's changed.
Here are the compressed sources:
http://people.redhat.com/meyering/iwhd/iwhd-0.99.tar.gz (1.3MB)
http://people.redhat.com/meyering/iwhd/iwhd-0.99.tar.xz (824KB)
Here are the GPG detached signatures[*]:
http://people.redhat.com/meyering/iwhd/iwhd-0.99.tar.gz.sig
http://people.redhat.com/meyering/iwhd/iwhd-0.99.tar.xz.sig
[*] You can use either of the above signature files to verify that
the corresponding file (without the .sig suffix) is intact. First,
be sure to download both the .sig file and the corresponding tarball.
Then, run a command like this:
gpg --verify iwhd-0.99.tar.gz.sig
If that command fails because you don't have the required public key,
then run this command to import it:
gpg --keyserver keys.gnupg.net --recv-keys 000BEEEE
and rerun the `gpg --verify' command.
This release was bootstrapped with the following tools:
Autoconf 2.68.79-5e017
Automake 1.11a
Gnulib v0.0-6363-g996ce97
NEWS
* Noteworthy changes in release 0.99 (2011-10-10) [stable]
** New features
A preliminary support is added for authorization with two-legged OAuth.
See the -o flag.
** Bug fixes
iwhd now continues to work properly when mongo dies and is restarted.
Before, it would dump core due to an unhandled SocketException.
iwhd's /etc/init.d startup script now reports failure reliably, for
example when failing to start because no MongoDB server is running.
Before it would print [FAILED], but mistakenly exit 0 (successful).
Now it exits with status 1.
Adapt to a slight variation in the status report of a template import
action in RHEV-M 2.x.
dc-rhev-image now allows a RHEV-M import to take 10 minutes.
Before, it would timeout after just 1 minute, which was often inadequate.
object deletion now succeeds for an object whose FS-backed file has been
removed behind iwhd's back.
** New features
The RHEV-M import timeout interval is now configurable.
You can set it via the optional new "timeout" key in /etc/iwhd/conf.js.
12 years, 7 months