[PetiteCloud] site changes
Aryeh Friedman
aryeh.friedman at gmail.com
Tue Feb 11 12:37:32 PST 2014
Our typical non-openstack use case is to have a number of test machines
that developers can test stuff on... web development is a good example of
what we want:
1. Make the site on your local machine (we recommend unix with full SCM
support like devel/aegis [devel/aegis and devel/cook are the foundation of
PetiteCloud's build system)
2. The site is uploaded to a private instance that is as identical to the
public hosting environment as possible for testing and client review
3. Once the client approves the site it is transferred to the public
hosting (likely AWS or RatSh*t)
All the above except the creative part of item 1 is streamed lined into a
single push button web front end. BTW when we talk of cloud
"applications" we mean stuff like this (stuff that can only be done on
cloud computing, not just a collection of instances). Note Dee should
have the first version of our API done sometime today (it will only have
instance start/stop for now) so you can automate things like this.
This is a small example of what we call the "N+1" problem... namely no
matter how many machines a computer professional (or serious hobbyist) has
access to they always need "just one more".... sadly to give our users the
illusion of solving the N+1 problem we have created a N*M problem for us (N
machines on M host configs).
On apps even though the in code support is still quiet primitive (Dee will
be improving it drastically over the course of the spring) we encourage
people to make Apps for PetiteCloud... Our business model itself is that
PetiteCloud is the only cloud platform good enough for certain kinds of
apps which we will sell commercially. But we see no way to make money of
the platform itself (or even the types of apps it enables without making on
such app ourselves) therefor we have open sourced PetiteCloud and the only
way we will have a relatively good market to sell our apps to is if there
is already a well supported ecosystem (even if many of the members are
direct competitors of our commercial work). In other words we never plan
to make money of our open source work and only make money of the stuff said
work enables.
On Tue, Feb 11, 2014 at 3:23 PM, Michael Thoreson <m.thoreson at c4labs.ca>wrote:
> I assume you are trying the following:
>
> Guest nic #1 \
> Brige to physical nic
> Guest nic #2 /
>
> Have you tried?
>
> Guest nic #1 --- Bridge to physical nic #1
> Guest nic #2 --- Bridge to physical nic #2
>
> If you have only one physical nic on the host you could try:
>
> Guest nic #1 -- Bridge to physical nic
>
> and then just add aliases to the Guest nic. I do see any advantage trying
> to bridge multiple vnics to one physical nic.
>
> Michael Thoreson,
>
>
> On 11/02/2014 2:05 PM, Aryeh Friedman wrote:
>
>> Ok this is baffling the single NIC version of Linux the script works but
>> as soon I add a second NIC to the bridge it bricks up... any ideas?
>>
>>
>> On Tue, Feb 11, 2014 at 2:47 PM, Aryeh Friedman <aryeh.friedman at gmail.com<mailto:
>> aryeh.friedman at gmail.com>> wrote:
>>
>> Found the issue I think (deleteing the iface as soon I make it...
>> now to figure out how on earth the tare down for tap3 came before
>> the hyperv call):
>>
>> #!/bin/sh
>>
>> tunctl -d tap3
>> ip link set tap3 up
>> sleep 1s
>> brctl addif br0 tap3
>> tunctl -d tap4
>> ip link set tap4 up
>> sleep 1s
>> brctl addif br0 tap4
>> brctl delif eth0 tap3
>> ip link set tap3 down
>> tunctl -d tap3
>>
>> qemu-system-x86_64 -vnc :0 -display none -drive
>> cache=writeback,format=raw,if=virtio,file=/dev/sdb -net
>> nic,model=virtio -net tap,ifname
>> =tap3 -net nic,model=virtio -net tap,ifname=tap4 -smb 1 -m 512
>> echo $!>/var/run/petitecloud/6opn0hm7uh
>>
>>
>>
>> On Tue, Feb 11, 2014 at 2:24 PM, Aryeh Friedman
>> <aryeh.friedman at gmail.com <mailto:aryeh.friedman at gmail.com>> wrote:
>>
>> Turns out I got mistaken about what the host OS I was testing
>> on (I was testing on linux under QEMU) and this is zero issue
>> in FreeBSD:
>>
>> aryeh at com-dev:/home/aryeh% ifconfig -a
>> vtnet0:
>> flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
>> metric 0 mtu 1500
>> options=80028<VLAN_MTU,JUMBO_MTU,LINKSTATE>
>> ether 00:a0:98:53:65:98
>> inet 10.0.10.6 netmask 0xffffff00 broadcast 10.0.10.255
>> inet6 fe80::2a0:98ff:fe53:6598%vtnet0 prefixlen 64 scopeid
>> 0x1
>> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>> media: Ethernet 10Gbase-T <full-duplex>
>> status: active
>> vtnet1: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST> metric
>> 0 mtu 1500
>> options=80028<VLAN_MTU,JUMBO_MTU,LINKSTATE>
>> ether 00:a0:98:b6:a2:a9
>> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>> media: Ethernet 10Gbase-T <full-duplex>
>> status: active
>> vtnet2: flags=8902<BROADCAST,PROMISC,SIMPLEX,MULTICAST> metric
>> 0 mtu 1500
>> options=80028<VLAN_MTU,JUMBO_MTU,LINKSTATE>
>> ether 00:a0:98:20:ee:f7
>> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>> media: Ethernet 10Gbase-T <full-duplex>
>> status: active
>> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
>> options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
>> inet6 ::1 prefixlen 128
>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
>> inet 127.0.0.1 netmask 0xff000000
>> nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
>> aryeh at com-dev:/home/aryeh% sudo su -
>> root at com-dev:~ # ifconfig vtnet1 192.168.0.1
>> root at com-dev:~ # logout
>> aryeh at com-dev:/home/aryeh% logout
>> Connection to 10.0.10.6 closed.
>> aryeh at pc-dev:~/o-petitecloud.C112 % sudo su -
>> root at pc-dev:~ # ifconfig -a
>> vtnet0:
>> flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
>> metric 0 mtu 1500
>> options=80028<VLAN_MTU,JUMBO_MTU,LINKSTATE>
>> ether 00:a0:98:8f:e1:e2
>> inet 10.0.10.3 netmask 0xffffff00 broadcast 10.0.10.255
>> inet6 fe80::2a0:98ff:fe8f:e1e2%vtnet0 prefixlen 64 scopeid
>> 0x1
>> nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
>> media: Ethernet 10Gbase-T <full-duplex>
>> status: active
>> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
>> options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
>> inet6 ::1 prefixlen 128
>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
>> inet 127.0.0.1 netmask 0xff000000
>> nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
>> bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
>> metric 0 mtu 1500
>> ether 02:38:f4:6e:71:00
>> nd6 options=9<PERFORMNUD,IFDISABLED>
>> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
>> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
>> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
>> member: tap5 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>> ifmaxaddr 0 port 7 priority 128 path cost 2000000
>> member: tap4 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>> ifmaxaddr 0 port 6 priority 128 path cost 2000000
>> member: tap10 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>> ifmaxaddr 0 port 5 priority 128 path cost 2000000
>> member: tap3 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>> ifmaxaddr 0 port 4 priority 128 path cost 2000000
>> tap3:
>> flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
>> metric 0 mtu 1500
>> options=80000<LINKSTATE>
>> ether 00:bd:3a:92:00:03
>> inet6 fe80::2bd:3aff:fe92:3%tap3 prefixlen 64 scopeid 0x4
>> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>> media: Ethernet autoselect
>> status: no carrier
>> tap10:
>> flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
>> metric 0 mtu 1500
>> options=80000<LINKSTATE>
>> ether 00:bd:6d:95:00:0a
>> inet6 fe80::2bd:6dff:fe95:a%tap10 prefixlen 64 scopeid 0x5
>> nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
>> media: Ethernet autoselect
>> status: no carrier
>> tap4:
>> flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
>> metric 0 mtu 1500
>> options=80000<LINKSTATE>
>> ether 00:bd:b4:cd:00:04
>> inet6 fe80::2bd:b4ff:fecd:4%tap4 prefixlen 64 scopeid 0x6
>> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>> media: Ethernet autoselect
>> status: no carrier
>> tap5:
>> flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
>> metric 0 mtu 1500
>> options=80000<LINKSTATE>
>> ether 00:bd:52:d7:00:05
>> inet6 fe80::2bd:52ff:fed7:5%tap5 prefixlen 64 scopeid 0x7
>> nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
>> media: Ethernet autoselect
>> status: no carrier
>> root at pc-dev:~ # ifconfig vtnet0 alias 192.168.0.2
>> root at pc-dev:~ # ping 192.168.0.2
>> PING 192.168.0.2 (192.168.0.2): 56 data bytes
>> 64 bytes from 192.168.0.2 <http://192.168.0.2>: icmp_seq=0
>> ttl=64 time=0.112 ms
>> 64 bytes from 192.168.0.2 <http://192.168.0.2>: icmp_seq=1
>>
>> ttl=64 time=0.016 ms
>> ^C
>> --- 192.168.0.2 ping statistics ---
>> 2 packets transmitted, 2 packets received, 0.0% packet loss
>> round-trip min/avg/max/stddev = 0.016/0.064/0.112/0.048 ms
>> root at pc-dev:~ # ping 192.168.0.1
>> PING 192.168.0.1 (192.168.0.1): 56 data bytes
>> 64 bytes from 192.168.0.1 <http://192.168.0.1>: icmp_seq=0
>> ttl=64 time=0.231 ms
>> 64 bytes from 192.168.0.1 <http://192.168.0.1>: icmp_seq=1
>>
>> ttl=64 time=0.107 ms
>> ^C
>> --- 192.168.0.1 ping statistics ---
>> 2 packets transmitted, 2 packets received, 0.0% packet loss
>> round-trip min/avg/max/stddev = 0.107/0.169/0.231/0.062 ms
>>
>>
>>
>> On Tue, Feb 11, 2014 at 1:59 PM, Michael Thoreson
>> <m.thoreson at c4labs.ca <mailto:m.thoreson at c4labs.ca>> wrote:
>>
>> Below is an older article but still talks about sysctl I
>> had to set when using jails in FreeNAS.
>>
>> http://www.cyberciti.biz/faq/freebsd-jail-allow-ping-
>> tracerouter-commands/
>>
>> I had to set it in order to allow the jail guest to
>> ping\traceroute to the outside and it was the only way I
>> could access services running on the jail guest from
>> outside the guest.
>>
>> Michael Thoreson,
>>
>>
>> On 11/02/2014 12:28 PM, Aryeh Friedman wrote:
>>
>> Please respond to the list so I don't have to keep
>> forwarding it.... I am unfamiliar with jail issue but
>> I do know that when reusing a NIC you need to do a
>> "hard reset" of it (delete the iface and then remake
>> and readd to the bridge)... where is a good pointer to
>> this?
>>
>>
>> On Tue, Feb 11, 2014 at 1:23 PM, Michael Thoreson
>> <m.thoreson at c4labs.ca <mailto:m.thoreson at c4labs.ca>
>> <mailto:m.thoreson at c4labs.ca
>> <mailto:m.thoreson at c4labs.ca>>> wrote:
>>
>> Could the traffic issue be similar to the sysctl
>> raw socket issue
>> with BSD jails?
>>
>> On a side note with the FreeBSD instructions I
>> have to change
>>
>> tar fvz port.tar.gz
>>
>> to
>>
>> tar*x*fvz port.tar.gz
>>
>> for the extraction to work properly.
>>
>> Michael Thoreson,
>>
>>
>> On 11/02/2014 12:13 PM, Aryeh Friedman wrote:
>>
>> A few additions to this (learned in the last
>> few mins):
>>
>> * PetiteCloud assumes that drives are vtbdXsY
>> (will be looked
>> into later) and thus once you get the bootable
>> drive to do a
>> partial loading you will need to edit
>> /etc/fstab to make it so
>> it points to something more reasonable like
>> adaXsY.
>>
>> * The NIC's appear in the bridge on the host
>> and are on the
>> instance but seem to not allow any traffic
>> (likely an issue
>> with how to setup multiple NIC's).. i.e. the
>> interface is
>> pingable from inside the instance but not from
>> the outside world
>>
>>
>> On Tue, Feb 11, 2014 at 1:08 PM, Michael Thoreson
>> <m.thoreson at c4labs.ca
>> <mailto:m.thoreson at c4labs.ca>
>> <mailto:m.thoreson at c4labs.ca
>> <mailto:m.thoreson at c4labs.ca>>
>> <mailto:m.thoreson at c4labs.ca
>> <mailto:m.thoreson at c4labs.ca>
>> <mailto:m.thoreson at c4labs.ca
>> <mailto:m.thoreson at c4labs.ca>>>>
>>
>> wrote:
>>
>> Awesome will start testing it today.
>>
>>
>> On 11/02/2014 3:36 AM, Aryeh Friedman wrote:
>>
>> Just booted FreeBSD 10-RELEASE on
>> Ubuntu 12.04.3 LTS
>> using a
>> 2.5" raw disk as a backing store with
>> 3 virtual NIC's
>> and it
>> seems to work
>>
>>
>> On Tue, Feb 11, 2014 at 4:30 AM, Aryeh
>> Friedman
>> <aryeh.friedman at gmail.com
>> <mailto:aryeh.friedman at gmail.com>
>> <mailto:aryeh.friedman at gmail.com
>> <mailto:aryeh.friedman at gmail.com>>
>> <mailto:aryeh.friedman at gmail.com
>> <mailto:aryeh.friedman at gmail.com>
>> <mailto:aryeh.friedman at gmail.com
>> <mailto:aryeh.friedman at gmail.com>>>
>> <mailto:aryeh.friedman at gmail.com
>> <mailto:aryeh.friedman at gmail.com>
>> <mailto:aryeh.friedman at gmail.com
>> <mailto:aryeh.friedman at gmail.com>>
>>
>> <mailto:aryeh.friedman at gmail.com
>> <mailto:aryeh.friedman at gmail.com>
>> <mailto:aryeh.friedman at gmail.com
>> <mailto:aryeh.friedman at gmail.com>>>>> wrote:
>>
>> I just bumped 0.2.5 to the release
>> version because
>> without
>> advanced settings it works just
>> fine it is the
>> advanced
>> options
>> that are untested... just get it
>> from the download
>> page
>>
>>
>> On Tue, Feb 11, 2014 at 4:19 AM,
>> Aryeh M. Friedman
>> <aryeh at cloud.fnwe.net
>> <mailto:aryeh at cloud.fnwe.net>
>> <mailto:aryeh at cloud.fnwe.net
>> <mailto:aryeh at cloud.fnwe.net>>
>> <mailto:aryeh at cloud.fnwe.net <mailto:aryeh at cloud.fnwe.net
>> >
>> <mailto:aryeh at cloud.fnwe.net
>> <mailto:aryeh at cloud.fnwe.net>>>
>> <mailto:aryeh at cloud.fnwe.net
>> <mailto:aryeh at cloud.fnwe.net>
>> <mailto:aryeh at cloud.fnwe.net
>> <mailto:aryeh at cloud.fnwe.net>>
>> <mailto:aryeh at cloud.fnwe.net <mailto:aryeh at cloud.fnwe.net
>> >
>> <mailto:aryeh at cloud.fnwe.net
>> <mailto:aryeh at cloud.fnwe.net>>>>>
>>
>> wrote:
>>
>> Michael I have forwarded this
>> message to the
>> mailing list
>> because I think it is an
>> interesting use case
>> and I am a
>> strong proponent of the
>> FreeBSD model of open
>> knowledge
>> (everything is in public unless some reason it
>> can't be).
>>
>> Comments on content:
>>
>> 1. 0.2.5 (currently in testing
>> you need go to
>> http://downloads.petitecloud.org/petitecloud-aryeh-0.2.5.
>> tar.gz
>> add
>> -0.2.5 to the port file name
>> also to grab it)
>> is 99% (only
>> reason for not saying 100% is
>> it is untested)
>> of the
>> way to
>> being able to run all possible
>> configurations of
>> OpenStack. See the current
>> change_history on
>> the site
>> for details.
>>
>> 2. We are looking at using
>> something like
>> FreeNAS to
>> provide
>> SAN like services for small
>> clouds (OpenStack
>> assumes a
>> certain layout to the cloud
>> that is only
>> typical in data
>> centers). That is if native
>> iSCSI is not
>> sufficent.
>>
>> 3. I will fix these links
>> (that will teach me
>> to rely on
>> automated testing only) as
>> soon I send this
>> message
>>
>> 4. We will be writting a set
>> of full tutorials
>> showing
>> how to
>> do I full OpenStack install
>> using nothing but
>> VM's. We will
>> also discuss how to improve
>> the stability and
>> robustness of
>> OpenStack along the way (using
>> FreeBSD instead of
>> Linux is a
>> good start)
>>
>> ---------------------- FORWARDED MESSAGE
>> -------------------------
>> FreeBSD and Linux install
>> instruction links
>> are still
>> broken.
>> Otherwise
>> everything else works. I
>> especially am going
>> to try the
>> DevStack\OpenStack you described. It looks like an
>> easy way to
>> get a ZFS
>> backed cloud.
>>
>> Michael Thoreson,
>> _______________________________________________
>> petitecloud-general mailing list
>> petitecloud-general at lists.petitecloud.nyclocal.net
>> <mailto:petitecloud-general@
>> lists.petitecloud.nyclocal.net>
>> <mailto:petitecloud-general@
>> lists.petitecloud.nyclocal.net
>> <mailto:petitecloud-general@
>> lists.petitecloud.nyclocal.net>>
>> <mailto:
>> petitecloud-general at lists.petitecloud.nyclocal.net
>> <mailto:petitecloud-general@
>> lists.petitecloud.nyclocal.net>
>> <mailto:petitecloud-general@
>> lists.petitecloud.nyclocal.net
>> <mailto:petitecloud-general@
>> lists.petitecloud.nyclocal.net>>>
>> <mailto:petitecloud-general@
>> lists.petitecloud.nyclocal.net
>> <mailto:petitecloud-general@
>> lists.petitecloud.nyclocal.net>
>> <mailto:petitecloud-general@
>> lists.petitecloud.nyclocal.net
>> <mailto:petitecloud-general@
>> lists.petitecloud.nyclocal.net>>
>>
>> <mailto:
>> petitecloud-general at lists.petitecloud.nyclocal.net
>> <mailto:petitecloud-general@
>> lists.petitecloud.nyclocal.net>
>> <mailto:petitecloud-general@
>> lists.petitecloud.nyclocal.net
>> <mailto:petitecloud-general@
>> lists.petitecloud.nyclocal.net>>>>
>>
>> http://lists.petitecloud.nyclocal.net/listinfo.cgi/
>> petitecloud-general-petitecloud.nyclocal.net
>>
>>
>>
>>
>> -- Aryeh M. Friedman, Lead
>> Developer,
>> http://www.PetiteCloud.org
>>
>>
>>
>>
>> -- Aryeh M. Friedman, Lead
>> Developer,
>> http://www.PetiteCloud.org
>>
>>
>>
>>
>>
>> -- Aryeh M. Friedman, Lead Developer,
>> http://www.PetiteCloud.org
>>
>>
>>
>>
>>
>> -- Aryeh M. Friedman, Lead Developer,
>> http://www.PetiteCloud.org
>>
>>
>>
>>
>>
>> -- Aryeh M. Friedman, Lead Developer,
>> http://www.PetiteCloud.org
>>
>>
>>
>>
>> -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
>>
>>
>>
>>
>> --
>> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
>>
>
>
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.petitecloud.nyclocal.net/pipermail/petitecloud-general-petitecloud.nyclocal.net/attachments/20140211/cfcea146/attachment-0003.htm>
More information about the petitecloud-general
mailing list