3:09 a.m.
In a nutshell, dwarf is OpenStack API on top of local libvirt/KVM. It
supports
a subset of the Keystone, Glance and Nova APIs to manage images and
instances
on the local machine.
Source and some more information: https://github.com/juergh/dwarf/
Package for F20: https://copr.fedoraproject.org/coprs/juergh/dwarf/
I had some issues with SELinux when running Dwarf in a F20 VM (libvirtd
fails to create temp directories when creating an instance). Not sure if
that was a problem with the VM or what's going on. I don't have Fedora on a
physical machine for testing so let me know if this is a problem for you.
...Juerg
6:19 a.m.
Hi,
Cool project! And very interesting approach... is this a "single-host
cloud"? :-)
Does it support enough of the underlying APIs to use Horizon as a dashboard?
Thanks,
Dave.
On 04/10/2014 10:09 AM, Juerg Haefliger wrote:
In a nutshell, dwarf is OpenStack API on top of local libvirt/KVM.
It
supports
a subset of the Keystone, Glance and Nova APIs to manage images and
instances
on the local machine.
Source and some more information: https://github.com/juergh/dwarf/
Package for F20: https://copr.fedoraproject.org/coprs/juergh/dwarf/
I had some issues with SELinux when running Dwarf in a F20 VM (libvirtd
fails to create temp directories when creating an instance). Not sure if
that was a problem with the VM or what's going on. I don't have Fedora
on a physical machine for testing so let me know if this is a problem
for you.
...Juerg
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
8:10 a.m.
Juerg, did you report a bugzilla?
On 04/10/2014 07:19 AM, Dave Neary wrote:
Hi,
Cool project! And very interesting approach... is this a "single-host
cloud"? :-)
Does it support enough of the underlying APIs to use Horizon as a dashboard?
Thanks,
Dave.
On 04/10/2014 10:09 AM, Juerg Haefliger wrote:
> In a nutshell, dwarf is OpenStack API on top of local libvirt/KVM. It
> supports
> a subset of the Keystone, Glance and Nova APIs to manage images and
> instances
> on the local machine.
>
> Source and some more information: https://github.com/juergh/dwarf/
>
> Package for F20: https://copr.fedoraproject.org/coprs/juergh/dwarf/
>
> I had some issues with SELinux when running Dwarf in a F20 VM (libvirtd
> fails to create temp directories when creating an instance). Not sure if
> that was a problem with the VM or what's going on. I don't have Fedora
> on a physical machine for testing so let me know if this is a problem
> for you.
>
> ...Juerg
>
>
>
> _______________________________________________
> cloud mailing list
> cloud(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
8:33 a.m.
On Thu, Apr 10, 2014 at 3:10 PM, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
Juerg, did you report a bugzilla?
No. Against what though? SELinux? The F20 cloud image?
...Juerg
On 04/10/2014 07:19 AM, Dave Neary wrote:
> Hi,
>
> Cool project! And very interesting approach... is this a "single-host
> cloud"? :-)
>
> Does it support enough of the underlying APIs to use Horizon as a
dashboard?
>
> Thanks,
> Dave.
>
> On 04/10/2014 10:09 AM, Juerg Haefliger wrote:
>> In a nutshell, dwarf is OpenStack API on top of local libvirt/KVM. It
>> supports
>> a subset of the Keystone, Glance and Nova APIs to manage images and
>> instances
>> on the local machine.
>>
>> Source and some more information: https://github.com/juergh/dwarf/
>>
>> Package for F20: https://copr.fedoraproject.org/coprs/juergh/dwarf/
>>
>> I had some issues with SELinux when running Dwarf in a F20 VM (libvirtd
>> fails to create temp directories when creating an instance). Not sure
if
>> that was a problem with the VM or what's going on. I
don't have Fedora
>> on a physical machine for testing so let me know if this is a problem
>> for you.
>>
>> ...Juerg
>>
>>
>>
>> _______________________________________________
>> cloud mailing list
>> cloud(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>>
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
8:48 a.m.
Report it against SELinux and we can take a look at it.
On 04/10/2014 09:33 AM, Juerg Haefliger wrote:
On Thu, Apr 10, 2014 at 3:10 PM, Daniel J Walsh
<dwalsh(a)redhat.com
<mailto:dwalsh@redhat.com>> wrote:
>
> Juerg, did you report a bugzilla?
No. Against what though? SELinux? The F20 cloud image?
...Juerg
> On 04/10/2014 07:19 AM, Dave Neary wrote:
> > Hi,
> >
> > Cool project! And very interesting approach... is this a "single-host
> > cloud"? :-)
> >
> > Does it support enough of the underlying APIs to use Horizon as a
dashboard?
> >
> > Thanks,
> > Dave.
> >
> > On 04/10/2014 10:09 AM, Juerg Haefliger wrote:
> >> In a nutshell, dwarf is OpenStack API on top of local libvirt/KVM. It
> >> supports
> >> a subset of the Keystone, Glance and Nova APIs to manage images and
> >> instances
> >> on the local machine.
> >>
> >> Source and some more information: https://github.com/juergh/dwarf/
> >>
> >> Package for F20: https://copr.fedoraproject.org/coprs/juergh/dwarf/
> >>
> >> I had some issues with SELinux when running Dwarf in a F20 VM
(libvirtd
> >> fails to create temp directories when creating an instance). Not
sure if
> >> that was a problem with the VM or what's going on. I don't have
Fedora
> >> on a physical machine for testing so let me know if this is a problem
> >> for you.
> >>
> >> ...Juerg
> >>
> >>
> >>
> >> _______________________________________________
> >> cloud mailing list
> >> cloud(a)lists.fedoraproject.org <mailto:cloud@lists.fedoraproject.org>
> >> https://admin.fedoraproject.org/mailman/listinfo/cloud
> >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> >>
>
> _______________________________________________
> cloud mailing list
> cloud(a)lists.fedoraproject.org <mailto:cloud@lists.fedoraproject.org>
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
7:13 a.m.
On Thu, Apr 10, 2014 at 10:09:06AM +0200, Juerg Haefliger wrote:
In a nutshell, dwarf is OpenStack API on top of local libvirt/KVM.
It
supports
a subset of the Keystone, Glance and Nova APIs to manage images and
instances
on the local machine.
This looks awesome! Finally, a good answer to the "how do I boot cloud
images locally and get them their ssh keys and userdata?"
Package for F20: https://copr.fedoraproject.org/coprs/juergh/dwarf/
Is the package ready to get into the distribution proper?
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
8:48 a.m.
On Thu, Apr 10, 2014 at 2:13 PM, Matthew Miller <mattdm(a)fedoraproject.org>
wrote:
On Thu, Apr 10, 2014 at 10:09:06AM +0200, Juerg Haefliger wrote:
> In a nutshell, dwarf is OpenStack API on top of local libvirt/KVM. It
> supports
> a subset of the Keystone, Glance and Nova APIs to manage images and
> instances
> on the local machine.
This looks awesome! Finally, a good answer to the "how do I boot cloud
images locally and get them their ssh keys and userdata?"
SSH keys import through cloud-init works. userdata is not yet supported.
And there's only a ec2 metadata server and no config drive.
> Package for F20:
https://copr.fedoraproject.org/coprs/juergh/dwarf/
Is the package ready to get into the distribution proper?
Don't think so. Look at it as a beta version that I just wanted to throw
out there. And quite frankly I'm not sure how much time I can spend on
bugfixes once they come flying in.
...Juerg
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
8:52 a.m.
On Thu, Apr 10, 2014 at 03:48:48PM +0200, Juerg Haefliger wrote:
> This looks awesome! Finally, a good answer to the "how do I
boot cloud
> images locally and get them their ssh keys and userdata?"
SSH keys import through cloud-init works. userdata is not yet supported.
And there's only a ec2 metadata server and no config drive.
ec2 metadata server is the more interesting, I think. Consider this a
request for implementation of userdata via that.
> > Package for F20:
https://copr.fedoraproject.org/coprs/juergh/dwarf/
> Is the package ready to get into the distribution proper?
Don't think so. Look at it as a beta version that I just wanted to throw
out there. And quite frankly I'm not sure how much time I can spend on
bugfixes once they come flying in.
Fair enough. Hopefully there will be enough interest that isn't just you. :)
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
10:43 a.m.
On 04/10/14 02:09, Juerg Haefliger wrote:
In a nutshell, dwarf is OpenStack API on top of local libvirt/KVM.
I suppose it's too late to suggest a name change? dwarf already has
long-time usage as the debugging format for various compilers, and
there's a matching libdwarf with an api for examining the format.
http://dwarfstd.org/
11:09 a.m.
On 04/10/2014 05:43 PM, Mats Wichmann wrote:
On 04/10/14 02:09, Juerg Haefliger wrote:
> In a nutshell, dwarf is OpenStack API on top of local libvirt/KVM.
I suppose it's too late to suggest a name change? dwarf already has
long-time usage as the debugging format for various compilers, and
there's a matching libdwarf with an api for examining the format.
http://dwarfstd.org/
Oh really, a naming discussion?
How about "puff"? (a tiny cloud)
Dave.
--
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
12:53 a.m.
On Fri, Apr 11, 2014 at 12:43 AM, Mats Wichmann <mats(a)wichmann.us> wrote:
On 04/10/14 02:09, Juerg Haefliger wrote:
> In a nutshell, dwarf is OpenStack API on top of local libvirt/KVM.
I suppose it's too late to suggest a name change? dwarf already has
long-time usage as the debugging format for various compilers, and
there's a matching libdwarf with an api for examining the format.
http://dwarfstd.org/
FWIW: It's also not very ideal because one of the OpenStack components
(I think it was Trove) used to be called Red Dwarf...
Anyway, thanks Juerg for packaging this and putting it into a copr
repo as requested. Will give it a try.
-- Sandro
4:21 a.m.
On Fri, Apr 11, 2014 at 2:53 PM, Sandro "red" Mathys
<red(a)fedoraproject.org> wrote:
On Fri, Apr 11, 2014 at 12:43 AM, Mats Wichmann
<mats(a)wichmann.us> wrote:
> On 04/10/14 02:09, Juerg Haefliger wrote:
>> In a nutshell, dwarf is OpenStack API on top of local libvirt/KVM.
>
> I suppose it's too late to suggest a name change? dwarf already has
> long-time usage as the debugging format for various compilers, and
> there's a matching libdwarf with an api for examining the format.
> http://dwarfstd.org/
FWIW: It's also not very ideal because one of the OpenStack components
(I think it was Trove) used to be called Red Dwarf...
Anyway, thanks Juerg for packaging this and putting it into a copr
repo as requested. Will give it a try.
-- Sandro
Let me start by saying I did not see any SELinux issues, before I get
to the bad (possibly TL;DR) news.
So, on the only system I could try this out, a few things are changed
from the defaults. I hope that didn't cause any of the issues I've
found. I hope I didn't either. ;)
If dwarf is started through systemd, it will log "sudo: sorry, you
must have a tty to run sudo" whenever it is:
1) trying to chown the console-log - and therefore, 'nova console-log
<server>' won't work:
2014-04-11 16:53:23,077 - INFO - dwarf.utils : execute(cmd=['chown',
991,
'/var/lib/dwarf/instances/997adba9-ba7c-4f2a-9fff-94e4cfe5d37c/console.log'],
check_exit_code=None, shell=False, run_as_root=True)
2014-04-11 16:53:23,106 - WARNING - dwarf.exception : Exception
caught: Failed to run command: ['sudo', 'chown', '991',
'/var/lib/dwarf/instances/997adba9-ba7c-4f2a-9fff-94e4cfe5d37c/console.log']
exit_code: 1
stdout:
stderr: sudo: sorry, you must have a tty to run sudo
(500)
2) trying to set up the nat prerouting rule for the ec2 metadata service:
2014-04-11 16:27:22,717 - INFO - dwarf.utils :
execute(cmd=['iptables', '-t', 'nat', '-D',
'PREROUTING', '-s', u'',
'-d', '169.254.169.254/32', '-p', 'tcp', '-m',
'tcp', '--dport', 80,
'-j', 'REDIRECT', '--to-port', 8080], check_exit_code=False,
shell=False, run_as_root=True)
2014-04-11 16:27:22,729 - INFO - dwarf.utils : execute(stderr=sudo:
sorry, you must have a tty to run sudo
)
...now, working around the issue by starting dwarf by hand instead of
through systemd should solve both based on the given sudo errors. But
it seems the iptables still isn't put into place (but the log shows no
issues). At least iptables -L -t nat shows no rules at all (yes, I
cleared them beforehand). Now, I noticed that the above log entry
shows "-s u" and wonder if "u" is ever replaced but since it's
not
logged anymore, I can't tell. Since that would result in an error I
figure it would turn up in the log if it was an issue. Anyway, because
of this cloud-init obviously can't reach the ec2 metadata. I tried to
execute the iptables command myself but didn't figure out what I
should replace u by. My guesses were either the instance's IP or
virbr0's IP or the network address but all failed like:
$ sudo iptables -t nat -D PREROUTING -s 192.168.111.1/24 -d
169.254.169.254/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-port 8080
iptables: No chain/target/match by that name.
(Yes, my libvirt is configured to use non-default IP ranges and yes, I
updated dwarf.conf accordingly). That's where my poor network-fu ends.
The work around successfully enables the console-log, though.
Also, when trying to work around this issue by configuring the ec2
metadata to listen on port 80 directly (and opening that port in the
firewall - or just shut it down as I did) and waiting for cloud-init
to fall back to the gateway IP instead of using 169.254.169.254, it
will be able to connect but get a 404 not found. I'd expect this to
work but either you really expect access through the special IP or you
don't expect a request for /latest/meta-data/instance-id but only for
/2009-04-04/meta-data-instance-id. I removed the workaround to try
other things before I came up with this idea and therefore couldn't
verify it right now.
-- Sandro
2:06 a.m.
Thanks for testing!
On Fri, Apr 11, 2014 at 11:21 AM, Sandro "red" Mathys
<red(a)fedoraproject.org>
wrote:
On Fri, Apr 11, 2014 at 2:53 PM, Sandro "red" Mathys
<red(a)fedoraproject.org> wrote:
> On Fri, Apr 11, 2014 at 12:43 AM, Mats Wichmann <mats(a)wichmann.us>
wrote:
>> On 04/10/14 02:09, Juerg Haefliger wrote:
>>> In a nutshell, dwarf is OpenStack API on top of local libvirt/KVM.
>>
>> I suppose it's too late to suggest a name change? dwarf already has
>> long-time usage as the debugging format for various compilers, and
>> there's a matching libdwarf with an api for examining the format.
>> http://dwarfstd.org/
>
> FWIW: It's also not very ideal because one of the OpenStack components
> (I think it was Trove) used to be called Red Dwarf...
>
> Anyway, thanks Juerg for packaging this and putting it into a copr
> repo as requested. Will give it a try.
>
> -- Sandro
Let me start by saying I did not see any SELinux issues, before I get
to the bad (possibly TL;DR) news.
So, on the only system I could try this out, a few things are changed
from the defaults. I hope that didn't cause any of the issues I've
found. I hope I didn't either. ;)
If dwarf is started through systemd, it will log "sudo: sorry, you
must have a tty to run sudo" whenever it is:
1) trying to chown the console-log - and therefore, 'nova console-log
<server>' won't work:
2014-04-11 16:53:23,077 - INFO - dwarf.utils : execute(cmd=['chown',
991,
'/var/lib/dwarf/instances/997adba9-ba7c-4f2a-9fff-94e4cfe5d37c/console.log'],
check_exit_code=None, shell=False, run_as_root=True)
2014-04-11 16:53:23,106 - WARNING - dwarf.exception : Exception
caught: Failed to run command: ['sudo', 'chown', '991',
'/var/lib/dwarf/instances/997adba9-ba7c-4f2a-9fff-94e4cfe5d37c/console.log']
exit_code: 1
stdout:
stderr: sudo: sorry, you must have a tty to run sudo
(500)
2) trying to set up the nat prerouting rule for the ec2 metadata service:
2014-04-11 16:27:22,717 - INFO - dwarf.utils :
execute(cmd=['iptables', '-t', 'nat', '-D',
'PREROUTING', '-s', u'',
'-d', '169.254.169.254/32', '-p', 'tcp', '-m',
'tcp', '--dport', 80,
'-j', 'REDIRECT', '--to-port', 8080], check_exit_code=False,
shell=False, run_as_root=True)
2014-04-11 16:27:22,729 - INFO - dwarf.utils : execute(stderr=sudo:
sorry, you must have a tty to run sudo
)
...now, working around the issue by starting dwarf by hand instead of
through systemd should solve both based on the given sudo errors.
I admit I don't understand this. Starting it through systemd works just
fine in my env (Fedora cloud image).
But
it seems the iptables still isn't put into place (but the log shows no
issues). At least iptables -L -t nat shows no rules at all (yes, I
cleared them beforehand). Now, I noticed that the above log entry
shows "-s u" and wonder if "u" is ever replaced but since it's
not
logged anymore, I can't tell.
-s is the source IP, i.e., the IP that your instance should receive from
dnsmasq. Did it get an IP at all?
You should see something like the following in the log:
2014-03-13 13:38:29,201 - INFO - dwarf.compute.servers :
_get_server_ip(mac=52:54:00:f7:db:92) : None
2014-03-13 13:38:31,203 - INFO - dwarf.compute.servers :
_get_server_ip(mac=52:54:00:f7:db:92) : None
2014-03-13 13:38:33,204 - INFO - dwarf.compute.servers :
_get_server_ip(mac=52:54:00:f7:db:92) : None
2014-03-13 13:38:35,205 - INFO - dwarf.compute.servers :
_get_server_ip(mac=52:54:00:f7:db:92) : None
2014-03-13 13:38:37,207 - INFO - dwarf.compute.servers :
_get_server_ip(mac=52:54:00:f7:db:92) : 192.168.122.157
Since that would result in an error I
figure it would turn up in the log if it was an issue. Anyway, because
of this cloud-init obviously can't reach the ec2 metadata. I tried to
execute the iptables command myself but didn't figure out what I
should replace u by. My guesses were either the instance's IP or
virbr0's IP or the network address but all failed like:
$ sudo iptables -t nat -D PREROUTING -s 192.168.111.1/24 -d
169.254.169.254/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-port 8080
iptables: No chain/target/match by that name.
(Yes, my libvirt is configured to use non-default IP ranges and yes, I
updated dwarf.conf accordingly). That's where my poor network-fu ends.
The work around successfully enables the console-log, though.
Also, when trying to work around this issue by configuring the ec2
metadata to listen on port 80 directly (and opening that port in the
firewall - or just shut it down as I did) and waiting for cloud-init
to fall back to the gateway IP instead of using 169.254.169.254, it
will be able to connect but get a 404 not found. I'd expect this to
work but either you really expect access through the special IP or you
don't expect a request for /latest/meta-data/instance-id but only for
/2009-04-04/meta-data-instance-id. I removed the workaround to try
other things before I came up with this idea and therefore couldn't
verify it right now.
I'm not a networking expert, obviously :-) The only way that I found for
the ec2 metadata server to function in this environment was to attach it to
the libvirt bridge's IP. The port doesn't really matter, as long as it's
not occupied by something else.
/latest/<foo> should work.
...Juerg
-- Sandro
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
3664
days inactive
3669
days old
12 comments
6 participants
participants (6)
-
Daniel J Walsh -
Dave Neary -
Juerg Haefliger -
Mats Wichmann -
Matthew Miller -
Sandro "red" Mathys