aeolus-devel October 2011

aeolus-devel@lists.fedorahosted.org

41 participants
246 discussions

packaging aeolus components
by Mo Morsi 19 Jan '12

19 Jan '12

Inorder to assist with the Aeolus packaging process, we are looking to split the end-of-development-cycle packaging tasks up among engineers working on the various components. The tentative list of lead packagers can be found below as well as on the wiki [1]. These packagers are responsible for making sure their component is tested against the supported Fedora versions at the time (currently F15, F16, and rawhide), and their component is pushed into Fedora with all of its dependencies (both new and updated ones). They may ask delegate some of this responsobility off to other team members as appropriate on a case by case basis. audrey - JoeVLcek conductor - sseago configure - mmorsi deltacloud - mfojtik imagefactory - sloranz iwhd - jmeyering oz - clalance If anyone feels that there are a better fits, feel free to suggest. -Mo [1] https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Packaging

2 2

Some musings about this sprint...
by Matt Wagner 10 Nov '11

10 Nov '11

Hi all, I've been spending a little bit of time thinking about the past few days, when we frantically reviewed patches and fixed bugs in advance of today's demo. Since having a code freeze ahead of the actual deadline is something relatively new for us, I don't necessarily see it as a tremendous failing that we didn't nail the execution on the first try, but I've been thinking about the places I could do better next time. I share these musings here hoping to start a constructive discussion. One thing is that I'd like to get into some sort of regular habit of reviewing patches on the mailing list. This sprint, I mostly thought, "I'm too busy writing code to bother with reviewing patches," which, in hindsight, was rather selfish to those who DID take time to review patches, and to those who needed patches approved. What I think I'd like to do is try to get into some sort of rhythm, where I maybe set aside 30 minutes each day to review patches on the list. It occurs to me that an added bonus of reviewing patches is that I get a better sense for what other people are doing on the project. (As long as I'm publicly admitting my faults, I'd also like to stop using the morning scrum reports to blindly dump my list of tasks, and actually look at what others are working on. That, of course, is what I'm meant to be doing anyway, but it's easy to get in the habit of just posting my status and moving on.) I'd also like to propose that we make a little more use of the Doctrine of Triviality. (I probably made that term up.) It seems like it's been acceptable for a long time to push trivial changes without sending them for review -- making a one-line change, reverting a broken commit, and so forth. While I am NOT proposing that developers push patches adding new features or making large changes on their own, there were a handful of patches on the list that were extremely trivial, or that were just obviously correct. Some of them sat for days waiting for someone to review them. I think it would be okay for people with commit access to push these things on their own, but note that they have a very high duty of care to make sure they're well-tested. How do other people feel about this concept? (For example -- I'd like to add some README files to the projects, just a quick overview mostly for the benefit of the GitHub pages. I sent one for Conductor some weeks ago that was ignored. I think it'd be fine to just push things like that.) As long as I'm proposing changes, I'd like to argue that we should consider test failures on master unacceptable, and revert any patch that introduces them. Checking in code with failing tests ends up causing huge headaches for other developers. For one, it prevents the demo server / Jenkins suite from running to completion. Second, it means that, for me to run tests on a patch, I need to run them twice -- once on the patch, and once on master, to make sure that the test failures I get aren't new failures in what I'm testing. What I'd propose is that, if code on master causes any test failures, we just revert the offending patch as soon as it's identified. (Of course, as with most of my other points, I don't mean to imply for a second that I'm not guilty of this myself.) In any event, I do think we're making great progress, and I'm really glad to be a part of this team. But I figured that if I was thinking about these things, other people probably were, too, so I hope this is the start of a constructive discussion. Please let me know what you think, good or bad. Best, Matt

10 18

TDL schema to support "persisted", "clientkey", and "clientcert" elements under "repository"
by Dmitri Dolguikh 09 Nov '11

09 Nov '11

I was asked to add support for "persisted", "clientkey", and "clientcert" elements under "repository" element in TDL export in katello, something along these lines: <repository name='unsigned-custom-repo'> <url>http://custom-rpackage-site2.redhat.com/repos/signed_custom_repo/</url> <clientcert>### BIG BASE64 BLOB</clientcert> <clientkey>## ADDITIONAL BASE 64 BLOB</clientkey> <persisted>No</persisted> </repository> It appears that the version of TDL.xsd in master in imagefactory repository doesn't support these at the moment. Attached is a patch that introduces the said elements to TDL schema (although without any validation for the format of the cert and the key). As a side note - would it make sense to introduce a 'certificate' element that would in turn contain 'cert' and 'key' elements? <repository name='unsigned-custom-repo'> ... <certificate> <cert>### BIG BASE64 BLOB</cert> <key>## ADDITIONAL BASE 64 BLOB</key> </certificate> ... </repository> Cheers, -d

4 3

Aeolus Tech School?
by Martyn Taylor 07 Nov '11

07 Nov '11

Hi Gents, It's pretty hard work keeping up to speed with all the latest tech stuff we use in aeolus such as rails and various other libraries, Agile processes and all that jazz. I and I guess a lot of you guys don't really get much time to branch out and research something new and interesting that you feel would help your work, the team or just something you'd like to look into. To help a little, I'm hoping to set up a monthly meet, where anyone who wants to get involved can go away and research a new technical topic by either reading a technical book or just research a topic online; then present their findings to the rest of the group. It's a win win situation, on an individual basis you get say 5 for the price of 1 (i.e. you read 1 book but get the knowledge of 5) and it's a win for the Team as a whole as it brings in a whole new set of skills and knowledge into the group. I'm thinking we could pull together a list of topics/skills that we feel we are lacking in the project. Then once a month we get a list of people who want to take part and their chosen topic (doesn't have to be an aeolus one, but preferably one that others might be interested in). Then at the end of the month we schedule say 30mins to an hour for each person to present their findings. We could just distribute a set of slides and do a conf call or use elluminate oir what ever people are comfortable with. Let me know if you are interested so I can get an idea of numbers to see if its worth while organising. Thanks Martyn

9 22

Trademarked image included in conductor
by James Laska 01 Nov '11

01 Nov '11

Greetings gang, Not sure whether branding is a high priority at the moment, but I did want to highlight that aeolus-conductor includes a trademarked Red Hat logo (/usr/share/aeolus-conductor/public/images/rh_logo.png). From https://fedoraproject.org/wiki/Legal:Trademark_guidelines#Logo_Usage_Guidel… ... "Red Hat, Inc. ("Red Hat") does not permit use of its registered trademarks without permission. If you are aware of any such use, please contact us at fedora-legal(a)redhat.com." Some options that come to mind ... 1. If the red hat logo is needed in Fedora, Spot is willing to add rh-logo to the fedora-logos package. Other packages that need the rh-logo would just need to %requires fedora-logos 2. Another option would be to rely on the system-logos %provides, and just reference the logo provided there. Both Fedora and RHEL offer %provides for system-logos [1]. For conductor in Fedora, you'd get a Fedora logo. For conductor in RHEL, you'd get the Red Hat logo. A symlink would be needed in the %files for conductor to ensure the logo is accessible in the web root? 3. Another option ... remove the logo usage from the web-ui entirely 4. Yet another option ... create some sort of custom upstream logo? Thoughts/comments/concerns? Thanks, James [1] Okay I lied, redhat-logos doesn't appear to offer the %provides yet, but it should. Investigating... Either way, it should be straightforward to special case the %{dist} in the .spec file.

4 5

[PATCH conductor 0/2] Fixing conductor tests
by Chris Alfonso 31 Oct '11

31 Oct '11

* The deployment launch test now passes using the m1-xlarge hardware profile, although it still takes a long time to execute. * The pools test that looks up the provider images now passes if the warehouse is not running. I also added a message in the UI to tell the user the warehouse is not reachable.

1 3

Fixed and polished catalog dropdown
by Jirka Tomasek 31 Oct '11

31 Oct '11

The catalogs dropdown is almost perfect now :)

1 2

iwhd-1.0 released [stable]
by Jim Meyering 31 Oct '11

31 Oct '11

Here's the latest version of iwhd. iwhd is Aeolus' (http://aeolusproject.org/) rule-based cloud-to-cloud image manager. This is almost a mere relabeling of iwhd-0.991. There have been two minor improvements since 0.991: - log messages showing when iwhd is started and stopped - an improvement in a regression test script The "issue" noted in NEWS below is not new to 0.991, and we have a fix already (thanks, Pete!), but it seems prudent to defer applying that until after 1.0. Here are the compressed sources: http://people.redhat.com/meyering/iwhd/iwhd-1.0.tar.gz (1.3MB) http://people.redhat.com/meyering/iwhd/iwhd-1.0.tar.xz (824KB) Here are the GPG detached signatures[*]: http://people.redhat.com/meyering/iwhd/iwhd-1.0.tar.gz.sig http://people.redhat.com/meyering/iwhd/iwhd-1.0.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-1.0.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.95-e0cb9 Automake 1.11a Gnulib v0.0-6363-g996ce97 NEWS * Noteworthy changes in release 1.0 (2011-10-31) [stable] ** Known issue (minor) iwhd is not very useful without mongod. Ideally, iwhd would communicate its inability to do useful work during that period, and when mongod becomes usable again iwhd would, too. However, currently, attempting to do things like create an object or an attribute in iwhd makes iwhd dereference NULL whenever mongod is unreachable.

1 0

[PATCH configure] Remove RHEV-M specific conf.js iwhd configuration file - v2
by Richard Su 31 Oct '11

31 Oct '11

v2 - iwhd-conf.js can be removed, was missing from original patch The default iwhd configuration file now works with RHEV-M. This makes the RHEV-M specific config file unnecessary. --- recipes/aeolus/manifests/profiles/rhevm.pp | 13 ------------- recipes/aeolus/templates/iwhd-conf.js | 7 ------- 2 files changed, 0 insertions(+), 20 deletions(-) delete mode 100644 recipes/aeolus/templates/iwhd-conf.js diff --git a/recipes/aeolus/manifests/profiles/rhevm.pp b/recipes/aeolus/manifests/profiles/rhevm.pp index 93d8bad..39680f2 100644 --- a/recipes/aeolus/manifests/profiles/rhevm.pp +++ b/recipes/aeolus/manifests/profiles/rhevm.pp @@ -18,11 +18,6 @@ class aeolus::profiles::rhevm { mode => 755, require => Package['aeolus-conductor-daemons'] } - file {"/etc/iwhd/conf.js": - content => template("aeolus/iwhd-conf.js"), - mode => 755, - require => Package['aeolus-conductor-daemons'] } - file {"$rhevm_nfs_mount_point": ensure => 'directory'} @@ -33,14 +28,6 @@ class aeolus::profiles::rhevm { options => "rw", require => File["$rhevm_nfs_mount_point"]} - # give iwhd a restart to pick up new configuration files - # in the event iwhd had already initialized at /var/lib/iwhd - exec { "/sbin/service iwhd restart": - require => [Service['iwhd'], - Mount["$rhevm_nfs_mount_point"], - File["/etc/imagefactory/rhevm.json"], - File["/etc/iwhd/conf.js"]]} - aeolus::create_bucket{"aeolus":} aeolus::conductor::site_admin{"admin": diff --git a/recipes/aeolus/templates/iwhd-conf.js b/recipes/aeolus/templates/iwhd-conf.js deleted file mode 100644 index d0be7fd..0000000 --- a/recipes/aeolus/templates/iwhd-conf.js +++ /dev/null @@ -1,7 +0,0 @@ -[ - { - "name": "rhevm", - "type": "fs-rhev-m", - "path": "/var/lib/iwhd" - } -] -- 1.7.6.4

2 1

Announcing aeolus community release 0.5.0
by steve linabery 31 Oct '11

31 Oct '11

Hello aeolus community! I'm pleased to announce the availability of aeolus release 0.5.0. Thanks to our developers, testers, documenters, and everyone who contributed to this release. Yum repos[1] and a fresh tarball[2] are now available for your gratification. Cheers, Steve Linabery irc: eggs [1] http://repos.fedorapeople.org/repos/aeolus/conductor/0.5.0/ [2] http://repos.fedorapeople.org/repos/aeolus/conductor/0.5.0/tarball/aeolus-c…

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

aeolus-devel October 2011