3:39 p.m.
Hi everyone,
I built the end of sprint RPMs in koji and put them in for update. Please take
them[1][2][3][4] for a spin and give feedback/karma.
If there are problems, the sooner we know, the better.
Thanks in advance,
Steve|eggmaster
[1] https://admin.fedoraproject.org/updates/aeolus-conductor-0.10.1-1.fc17
[2] https://admin.fedoraproject.org/updates/aeolus-configure-2.6.0-1.fc17
[3] https://admin.fedoraproject.org/updates/rubygem-aeolus-cli-0.5.0-1.fc17
[4] https://admin.fedoraproject.org/updates/rubygem-aeolus-image-0.5.0-1.fc17
4:45 p.m.
On Fri, Jun 08, 2012 at 03:39:34PM -0500, Steve Linabery wrote:
Hi everyone,
I built the end of sprint RPMs in koji and put them in for update. Please take
them[1][2][3][4] for a spin and give feedback/karma.
If there are problems, the sooner we know, the better.
Thanks in advance,
Steve|eggmaster
[1] https://admin.fedoraproject.org/updates/aeolus-conductor-0.10.1-1.fc17
[2] https://admin.fedoraproject.org/updates/aeolus-configure-2.6.0-1.fc17
[3] https://admin.fedoraproject.org/updates/rubygem-aeolus-cli-0.5.0-1.fc17
[4] https://admin.fedoraproject.org/updates/rubygem-aeolus-image-0.5.0-1.fc17
Thanks for doing this!
I'm running into a bunch of problems with aeolus-configure. I don't know
that they're related to our packages, but they're certainly causing
grief either way.
The overall set of failures:
https://gist.github.com/2898232
Line 18 shows a Deltacloud failure. Then line 40 begins a barrage of
database-related errors.
I have the Deltacloud-specific errors here:
https://gist.github.com/2898237 -- it seems like it's failing because
it can't find the user "nobody".
I don't know if there's a useful log for the database errors. Postgres
looks to be running fine. thin.log and rails.log are both blank.
configure's log doesn't look to have anything I didn't paste above.
I'm not sure that these are actually problems with our packages. The
first one, at least, looks to be a Deltacloud issue. I don't understand
the second one yet, and unfortunately won't have time to look into it on
Monday. But I thought I'd send this update out now so I don't forget
next week. :)
Best,
Matt
9:37 a.m.
On 09/06/2012, at 7:45 AM, Matt Wagner wrote:
On Fri, Jun 08, 2012 at 03:39:34PM -0500, Steve Linabery wrote:
> Hi everyone,
>
> I built the end of sprint RPMs in koji and put them in for update. Please take
them[1][2][3][4] for a spin and give feedback/karma.
>
> If there are problems, the sooner we know, the better.
>
> Thanks in advance,
> Steve|eggmaster
>
> [1] https://admin.fedoraproject.org/updates/aeolus-conductor-0.10.1-1.fc17
> [2] https://admin.fedoraproject.org/updates/aeolus-configure-2.6.0-1.fc17
> [3] https://admin.fedoraproject.org/updates/rubygem-aeolus-cli-0.5.0-1.fc17
> [4] https://admin.fedoraproject.org/updates/rubygem-aeolus-image-0.5.0-1.fc17
Thanks for doing this!
I'm running into a bunch of problems with aeolus-configure. I don't know
that they're related to our packages, but they're certainly causing
grief either way.
Tried a few things out to see what works on F16. The rubygem-aeolus-cli/image
and aeolus-configure packages from the initial repo.fedorapeople.org 0.10.0 repo
seem ok, with just the aeolus-configure package being broken.
So used those, plus the updated aeolus-configure-0.10.0-1 package as above but
recompiled from src.rpm for F16. Those seem to work together fine. Gets through
an aeolus-configure run ok (-p admin,rhevm2,ec2,vsphere), and initial mucking
around from there through the conductor webui seems fine too. (not tested in
depth yet).
As a convenience, placed them together into a temp repo here:
http://mirror.salasaga.org/aeolus/0.10.0-f16/
Also created a usable fedora-aeolus.repo file (F16 specific) which can be
installed into /etc/yum.repos.d/ using wget or curl:
http://mirror.salasaga.org/aeolus/0.10.0-f16/fedora-aeolus.repo
So far, this seems ok. ie add that repo file, yum install aeolus-all, good
to go.
Hope that helps. :)
Regards and best wishes,
Justin Clift
--
Aeolus Community Manager
http://www.aeolusproject.org
9:29 a.m.
On Fri, 8 Jun 2012 17:45:30 -0400, Matt Wagner <matt.wagner(a)redhat.com> wrote:
I'm running into a bunch of problems with aeolus-configure. I
don't know
that they're related to our packages, but they're certainly causing
grief either way.
The overall set of failures:
https://gist.github.com/2898232
Line 18 shows a Deltacloud failure. Then line 40 begins a barrage of
database-related errors.
I have the Deltacloud-specific errors here:
https://gist.github.com/2898237 -- it seems like it's failing because
it can't find the user "nobody".
Deltacloud fails because /usr/bin/ruby is not allowed read() on
/etc/passwd, so it is denied by SELinux.
Currently, on F17, deltacloud is being invoked by systemd via its
sysvinit script. Thin is trying to do the daemonization, which roughly
amounts to:
1. Start ruby (thin) as root
2. Read config, determine thin should run as 'nobody'
3. Read /etc/passwd to determine the uid of the 'nobody'
4. Fork and call setuid() to the nobody user
(3) is where it all goes wrong and it fails to start before daemonizing.
The easy and proper fix is to lauch deltacloud as a proper systemd
service unit. Then, systemd can manage all of the daemonization and
user switching (which it is permitted to do by policy). I'm attaching a
service unit I threw together, you can drop it in
/etc/systemd/system/deltacloud-core.service and see if it helps (it did
for me).
After fixing deltacloud, I'm also seeing failures for
conductor-delayed_job, conductor-dbomatic, and aeolus-conductor as well.
I haven't dug into those but I'm guessing they suffer from roughly the
same problem.
I don't know if there's a useful log for the database errors.
Postgres
looks to be running fine. thin.log and rails.log are both blank.
configure's log doesn't look to have anything I didn't paste above.
FWIW I can't reproduce the Postgres error.
[Unit]
Description=Deltacloud Core Daemon
[Service]
ExecStart=/usr/bin/deltacloudd -i mock -e production --port 3002 --host localhost
User=nobody
Group=nobody
[Install]
WantedBy=multi-user.target
10:22 a.m.
On 11/06/2012, at 12:37 AM, Justin Clift wrote:
<snip>
As a convenience, placed them together into a temp repo here:
http://mirror.salasaga.org/aeolus/0.10.0-f16/
Also created a usable fedora-aeolus.repo file (F16 specific) which can be
installed into /etc/yum.repos.d/ using wget or curl:
http://mirror.salasaga.org/aeolus/0.10.0-f16/fedora-aeolus.repo
So far, this seems ok. ie add that repo file, yum install aeolus-all, good
to go.
The "seems ok" bit might have been premature.
The good:
+ Creation of accounts for oVirt, vSphere, and EC2 works fine. Connection tests
pass.
+ Creating and launching instances in EC2 works. (only US West 1 tested)
The bad:
+ vSphere isn't working properly.
Newly launched instances change to "Vanished" status straight after launch,
even
though they're running fine according to the VMware windows gui. (VMware 4.1)
This *could* be just my setup, rather than Aeolus. ;)
The ugly:
+ oVirt instances are untested just yet. Upon bootup my oVirt host server decided
it doesn't want to talk to the oVirt engine server any more.
And the oVirt engine server point blank refuses to remove this host from its
configuration (ie to remove and re-add it).
So, probably have to reinstall both. (ugh)
Does anyone else have a vSphere setup around they can test on? Would be good to
know if the 0.10.0 rpms are ok with vSphere or not.
Regards and best wishes,
Justin Clift
--
Aeolus Community Manager
http://www.aeolusproject.org
12:50 p.m.
On Fri, Jun 08, 2012 at 03:39:34PM -0500, Steve Linabery wrote:
Hi everyone,
I built the end of sprint RPMs in koji and put them in for update. Please take
them[1][2][3][4] for a spin and give feedback/karma.
If there are problems, the sooner we know, the better.
Thanks in advance,
Steve|eggmaster
[1] https://admin.fedoraproject.org/updates/aeolus-conductor-0.10.1-1.fc17
[2] https://admin.fedoraproject.org/updates/aeolus-configure-2.6.0-1.fc17
[3] https://admin.fedoraproject.org/updates/rubygem-aeolus-cli-0.5.0-1.fc17
[4] https://admin.fedoraproject.org/updates/rubygem-aeolus-image-0.5.0-1.fc17
f16 branches updated to latest release.
https://admin.fedoraproject.org/updates/aeolus-conductor-0.10.1-1.fc16
https://admin.fedoraproject.org/updates/aeolus-configure-2.6.0-1.fc16
https://admin.fedoraproject.org/updates/rubygem-aeolus-cli-0.5.0-1.fc16
https://admin.fedoraproject.org/updates/rubygem-aeolus-image-0.5.0-1.fc16
hth
s|e
5:23 a.m.
On 12/06/2012, at 3:50 AM, Steve Linabery wrote:
On Fri, Jun 08, 2012 at 03:39:34PM -0500, Steve Linabery wrote:
> Hi everyone,
>
> I built the end of sprint RPMs in koji and put them in for update. Please take
them[1][2][3][4] for a spin and give feedback/karma.
>
> If there are problems, the sooner we know, the better.
>
> Thanks in advance,
> Steve|eggmaster
>
> [1] https://admin.fedoraproject.org/updates/aeolus-conductor-0.10.1-1.fc17
> [2] https://admin.fedoraproject.org/updates/aeolus-configure-2.6.0-1.fc17
> [3] https://admin.fedoraproject.org/updates/rubygem-aeolus-cli-0.5.0-1.fc17
> [4] https://admin.fedoraproject.org/updates/rubygem-aeolus-image-0.5.0-1.fc17
f16 branches updated to latest release.
https://admin.fedoraproject.org/updates/aeolus-conductor-0.10.1-1.fc16
https://admin.fedoraproject.org/updates/aeolus-configure-2.6.0-1.fc16
https://admin.fedoraproject.org/updates/rubygem-aeolus-cli-0.5.0-1.fc16
https://admin.fedoraproject.org/updates/rubygem-aeolus-image-0.5.0-1.fc16
Been trying these out all day. configure and conductor both seem "ok" enough
to
release. Haven't tried cli stuff yet.
Points worth noting:
+ deltacloud-core is consistently segfaulting at startup, but runs fine when
the service is manually restarted afterwards. (obviously not a problem
with the above rpms per se, but good to be aware of when testing)
+ Launching instances in oVirt and EC2 goes fine. Definitely usable.
+ Finally worked out the cause of launch failures for VMware.
... having spaces in instances names. (will file a BZ in a minute)
ie "Instance E" fails at launch, whereas "InstanceE" works.
Sounds like a string sanitisation problem to me. Extract from the
dbomatic log:
2012-06-12 19:51:40 INFO Deltacloud refresh started
2012-06-12 19:51:40 INFO Deltacloud instances refresh started
2012-06-12 19:51:41 WARN caught deltacloud exception bad URI(is not URI?):
http://localhost:3002/api/instances/Instance E-F16-vmware when updating instance Instance
E/F16-vmware
2012-06-12 19:51:41 INFO known instance missing from provider: Instance E/F16-vmware
Instance E-F16-vmware
2012-06-12 19:51:48 INFO updating instance state for InstanceD/F16-vmware:
InstanceD-F16-vmware
2012-06-12 19:51:54 INFO updating instance state for InstanceC/F16-vmware:
InstanceC-F16-vmware
2012-06-12 19:51:54 INFO Deltacloud instances refresh completed
2012-06-12 19:51:54 INFO Deltacloud refresh completed
Not a blocker IMHO, as we can just tell people not to use spaces in their
instance names for now (and that its a temp measure, should be fixed by
next release).
From my point of view, this will be workable as a stable release.
i.e. lets get release notes written up, screenshots done, updated install
instructions, etc.
How's that all sound to you?
+ Justin
--
Aeolus Community Manager
http://www.aeolusproject.org
5:37 a.m.
On 12/06/2012, at 8:23 PM, Justin Clift wrote:
<snip>
+ Finally worked out the cause of launch failures for VMware.
... having spaces in instances names. (will file a BZ in a minute)
ie "Instance E" fails at launch, whereas "InstanceE" works.
Sounds like a string sanitisation problem to me. Extract from the
dbomatic log:
2012-06-12 19:51:40 INFO Deltacloud refresh started
2012-06-12 19:51:40 INFO Deltacloud instances refresh started
2012-06-12 19:51:41 WARN caught deltacloud exception bad URI(is not URI?):
http://localhost:3002/api/instances/Instance E-F16-vmware when updating instance Instance
E/F16-vmware
2012-06-12 19:51:41 INFO known instance missing from provider: Instance E/F16-vmware
Instance E-F16-vmware
2012-06-12 19:51:48 INFO updating instance state for InstanceD/F16-vmware:
InstanceD-F16-vmware
2012-06-12 19:51:54 INFO updating instance state for InstanceC/F16-vmware:
InstanceC-F16-vmware
2012-06-12 19:51:54 INFO Deltacloud instances refresh completed
2012-06-12 19:51:54 INFO Deltacloud refresh completed
Filed as BZ# 831156.
+ Justin
--
Aeolus Community Manager
http://www.aeolusproject.org
8:10 a.m.
On 06/11/2012 04:29 PM, John Eckersberg wrote:
The easy and proper fix is to lauch deltacloud as a proper systemd
service unit. Then, systemd can manage all of the daemonization and
user switching (which it is permitted to do by policy). I'm attaching a
service unit I threw together, you can drop it in
/etc/systemd/system/deltacloud-core.service and see if it helps (it did
for me).
This workaround also works for me! Thanks!
Anyway, I also filed a BZ ticket:
https://bugzilla.redhat.com/show_bug.cgi?id=830684
Imre
4362
days inactive
4366
days old
aeolus-devel@lists.fedorahosted.org
8 comments
5 participants
participants (5)
-
Imre Farkas -
John Eckersberg -
Justin Clift -
Matt Wagner -
steve linabery