[openstack-dev] What does NASA not using OpenStack mean to OS's future
http://www.quora.com/Why-would-the-creators-of-OpenStack-the-market-leader-in-cloud-computing-platforms-refuse-to-use-it-and-use-AWS-instead -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] What does NASA not using OpenStack mean to OS's future
1. Sorry wrong list 2. Your answers just confirm NASA was right On Mon, Aug 25, 2014 at 12:22 PM, Steve Martinelli wrote: > This is hardly a development related question. > > > Regards, > > *Steve Martinelli* > Software Developer - OpenStack > Keystone Core Member > -- > *Phone:* 1-905-413-2851 > * E-mail:* *steve...@ca.ibm.com* > 8200 Warden Ave > Markham, ON L6G 1C7 > Canada > > > > Aryeh Friedman wrote on 08/25/2014 12:08:50 PM: > > > From: Aryeh Friedman > > To: "OpenStack Development Mailing List (not for usage questions)" > > , > > Date: 08/25/2014 12:12 PM > > Subject: [openstack-dev] What does NASA not using OpenStack mean to > > OS's future > > > > http://www.quora.com/Why-would-the-creators-of-OpenStack-the-market- > > > leader-in-cloud-computing-platforms-refuse-to-use-it-and-use-AWS-instead > > > > -- > > Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org > <http://www.petitecloud.org/> > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] What does NASA not using OpenStack mean to OS's future
Do you call Martin Meckos having no clue... he is the one that leveled the second worse criticism after mine... or is Euclapytus not one the founding members of OpenStack (after all many of the glance commands still use it's name) On Mon, Aug 25, 2014 at 1:30 PM, Endre Karlson wrote: > 1. If you're wanting to start a fire you need to somewhere else then a > development mailing list. > 2. Get your facts together, much of what you're writing on Quota as many > has pointed out is totally wrong. > > Also what Anita noted earlier about OS != OpenStack in that sense. > > Please keep topics like this off the ML. > > Regards > Endre > > > > 2014-08-25 18:48 GMT+02:00 Aryeh Friedman : > > 1. Sorry wrong list >> 2. Your answers just confirm NASA was right >> >> >> On Mon, Aug 25, 2014 at 12:22 PM, Steve Martinelli >> wrote: >> >>> This is hardly a development related question. >>> >>> >>> Regards, >>> >>> *Steve Martinelli* >>> Software Developer - OpenStack >>> Keystone Core Member >>> -- >>> *Phone:* 1-905-413-2851 >>> * E-mail:* *steve...@ca.ibm.com* >>> 8200 Warden Ave >>> Markham, ON L6G 1C7 >>> Canada >>> >>> >>> >>> Aryeh Friedman wrote on 08/25/2014 12:08:50 >>> PM: >>> >>> > From: Aryeh Friedman >>> > To: "OpenStack Development Mailing List (not for usage questions)" >>> > , >>> > Date: 08/25/2014 12:12 PM >>> > Subject: [openstack-dev] What does NASA not using OpenStack mean to >>> > OS's future >>> > >>> > http://www.quora.com/Why-would-the-creators-of-OpenStack-the-market- >>> >>> > >>> leader-in-cloud-computing-platforms-refuse-to-use-it-and-use-AWS-instead >>> > >>> > -- >>> > Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org >>> <http://www.petitecloud.org/> >>> >>> > ___ >>> > OpenStack-dev mailing list >>> > OpenStack-dev@lists.openstack.org >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] What does NASA not using OpenStack mean to OS's future
If I was doing that then I would be promoting the platform by name (which I am not). I was just pointing out in our own internal ananylis OS came in dead last among all the open source IaaS/PaaS's (the current version of mine is not #1 btw) On Mon, Aug 25, 2014 at 2:03 PM, Ian Wells wrote: > On 25 August 2014 10:34, Aryeh Friedman wrote: > >> Do you call Martin Meckos having no clue... he is the one that leveled >> the second worse criticism after mine... or is Euclapytus not one the >> founding members of OpenStack (after all many of the glance commands still >> use it's name) >> > > You appear to be trolling, and throwing around amazingly easy-to-disprove > 'factoids', in an inappropriate forum, in order to drum up support for your > own competing open source cloud platform. Please stop. > > Your time would be much better spent improving your platform rather than > coming up with frankly bizarre criticism of the competitors. > -- > Ian. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] request for testing new cloud foundation layer on bare metal
PetiteCloud is a 100% Free Open Source and Open Knowledge bare metal capable Cloud Foundation Layer for Unix-like operating systems. It has the following features: * Support for bhyve (FreeBSD only) and QEMU * Any x86 OS as a guest (FreeBSD and Linux via bhyve or QEMU; all others via QEMU only) and all supported software (including running OpenStack on VM's) * Install, import, start, stop and reboot instances safely (guest OS needs to be controlled independently) * Clone, backup/export, delete stopped instances 100% safely * Keep track of all your instances on one screen * All transactions that change instance state are password protected at all critical stages * Advanced options: * Ability to use/make bootable bare metal disks for backing stores * Multiple NIC's and disks * User settable (vs. auto assigned) backing store locations * A growing number of general purpose and specialized instances/applications are available for PetiteCloud We would like to know if people a) find this useful and b) does it live up to it's claims for a wide variety of open stack installs -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] request for testing new cloud foundation layer on bare metal
We apologize for the unclearness of our wording both here and on our site (http://www.petitecloud.org). Over the next few weeks we will work on improving our descriptions of various aspects of what PetiteCloud is and what it is not. We will also add a set of tutorials showing what a cloud foundation layer (CFL) is and how it can make OpenStack more stable and robust in non-data-center environments. In the meantime, hopefully my answers below will help with some immediate clarification. For general answers as to what a CFL is, see our 25 words or less answer on our site (http://petitecloud.org/cloudFoundation.jsp) or see the draft notes for a forthcoming white paper on the topic ( http://lists.petitecloud.nyclocal.net/private.cgi/petitecloud-general-petitecloud.nyclocal.net/attachments/20140213/3fee4df0/attachment-0001.pdf). OpenStack does not currently have a cloud foundation layer of its own (creating one might be a good sub-project for OpenStack). Your specfic questions are answered inline: On Fri, Feb 14, 2014 at 11:28 PM, Robert Collins wrote: > I'm sorry if this sounds rude, but I've been seeing your emails come > in, and I've read your website, and I still have 0% clue about what > PetiteCloud is. > > On 12 February 2014 21:56, Aryeh Friedman > wrote: > > PetiteCloud is a 100% Free Open Source and Open Knowledge bare metal > capable > > Cloud Foundation Layer for Unix-like operating systems. It has the > following > > features: > > What is a Cloud Foundation Layer? Whats the relevance of OK here (I > presume you mean http://okfn.org/ ?). > We have no connection with the above site. Personally we agree with its goals, but our use of the term "Open Knowledge" is different and pertains only to technical knowledge. See our web site for details on what we mean by that term. http://petitecloud.org/fosok.jsp > > > * Support for bhyve (FreeBSD only) and QEMU > > * Any x86 OS as a guest (FreeBSD and Linux via bhyve or QEMU; all > others > > via QEMU only) and all supported software (including running OpenStack on > > VM's) > > * Install, import, start, stop and reboot instances safely (guest OS > > needs to be controlled independently) > > * Clone, backup/export, delete stopped instances 100% safely > > So far it sounds like a hypervisor management layer - which is what Nova > is. > Nova is for running end user instances. PetiteCloud is designed (see below) to run instances that OpenStack can run on and then partition into end-user instances. > > > * Keep track of all your instances on one screen > > I think you'll need a very big screen eventually :) > Not a huge one. A CFL needs to run only a relatively small number of instances itself. Remember that a cloud foundation layer's instances can be used as hosts (a.k.a. nodes) for a full-fledged IAAS platform such as OpenStack. Thus, for example, a set of just four PetiteCloud instances might serve as the complete compute, networking, storage, etc. nodes for an OpenStack installation which in turn is running, say 10 instances. Addtional compute, storage and/or hybrid nodes (real and virtual) can be added to the deploy via any combination of bare metal openstack nodes and CFL'ed ones. Since PetiteCloud does not, yet, have any API hooks you would need to limit this to a small number of PetiteCloud hosts. > > > * All transactions that change instance state are password protected > at > > all critical stages > > * Advanced options: > > * Ability to use/make bootable bare metal disks for backing > stores > > * Multiple NIC's and disks > > * User settable (vs. auto assigned) backing store locations > > if backing store == virtual disk, this sounds fairly straight forward, > though 'bootable bare metal disks' is certainly an attention grabbing > statement for a hypervisor. > As explained in the white paper, since we are a full layer 0 cloud platform instead of just a hypervisor manager we can do stuff that would normally not be possible for a unmanaged hypervisor (or even wise if not managed by a full layer 0 platform). One of them is you can make the storage target of your layer 0 instances be a physical disk. Additionally since petitecloud does not require any "guest modifications" when you install the OS (which is managed by the hypervisor) you can make your root disk be a physical drive. You can take this to some really interesting extremes like one of our core team members (not me) posted a few nights ago to our mailing list how to make a "cloud on a stick". http://lists.petitecloud.nyclocal.net/private.cgi/petitecloud-general-petitecloud.nyclocal.net/2014-February/000106.htmlNamely how have a bootable U
Re: [openstack-dev] request for testing new cloud foundation layer on bare metal
Very quick note it turns out our mailing lists archives where private I have no marked them as public. If the links didn't work for you in the last 24 hrs try again. On Sat, Feb 15, 2014 at 2:40 AM, Aryeh Friedman wrote: > We apologize for the unclearness of our wording both here and on > our site (http://www.petitecloud.org). Over the next few weeks we will > work on improving our descriptions of various aspects of what PetiteCloud > is and what it is not. We will also add a set of tutorials showing what a > cloud foundation layer (CFL) is and how it can make OpenStack more stable > and robust in non-data-center environments. In the meantime, hopefully my > answers below will help with some immediate clarification. > > For general answers as to what a CFL is, see our 25 words or less > answer on our site (http://petitecloud.org/cloudFoundation.jsp) or see > the draft notes for a forthcoming white paper on the topic ( > http://lists.petitecloud.nyclocal.net/private.cgi/petitecloud-general-petitecloud.nyclocal.net/attachments/20140213/3fee4df0/attachment-0001.pdf). > OpenStack does not currently have a cloud foundation layer of its own > (creating one might be a good sub-project for OpenStack). > > Your specfic questions are answered inline: > > > > On Fri, Feb 14, 2014 at 11:28 PM, Robert Collins < > robe...@robertcollins.net> wrote: > >> I'm sorry if this sounds rude, but I've been seeing your emails come >> in, and I've read your website, and I still have 0% clue about what >> PetiteCloud is. >> >> On 12 February 2014 21:56, Aryeh Friedman >> wrote: >> > PetiteCloud is a 100% Free Open Source and Open Knowledge bare metal >> capable >> > Cloud Foundation Layer for Unix-like operating systems. It has the >> following >> > features: >> >> What is a Cloud Foundation Layer? Whats the relevance of OK here (I >> presume you mean http://okfn.org/ ?). >> > > > We have no connection with the above site. Personally we agree with its > goals, but our use of the term "Open Knowledge" is different and pertains > only to technical knowledge. See our web site for details on what we mean > by that term. http://petitecloud.org/fosok.jsp > > >> >> > * Support for bhyve (FreeBSD only) and QEMU >> > * Any x86 OS as a guest (FreeBSD and Linux via bhyve or QEMU; all >> others >> > via QEMU only) and all supported software (including running OpenStack >> on >> > VM's) >> > * Install, import, start, stop and reboot instances safely (guest OS >> > needs to be controlled independently) >> > * Clone, backup/export, delete stopped instances 100% safely >> >> So far it sounds like a hypervisor management layer - which is what Nova >> is. >> > > Nova is for running end user instances. PetiteCloud is designed (see > below) to run instances that OpenStack can run on and then partition into > end-user instances. > > >> >> > * Keep track of all your instances on one screen >> >> I think you'll need a very big screen eventually :) >> > Not a huge one. A CFL needs to run only a relatively small number of > instances itself. Remember that a cloud foundation layer's instances can be > used as hosts (a.k.a. nodes) for a full-fledged IAAS platform such as > OpenStack. Thus, for example, a set of just four PetiteCloud instances > might serve as the complete compute, networking, storage, etc. nodes for an > OpenStack installation which in turn is running, say 10 instances. > Addtional compute, storage and/or hybrid nodes (real and virtual) can be > added to the deploy via any combination of bare metal openstack nodes and > CFL'ed ones. Since PetiteCloud does not, yet, have any API hooks you would > need to limit this to a small number of PetiteCloud hosts. > > >> >> > * All transactions that change instance state are password >> protected at >> > all critical stages >> > * Advanced options: >> > * Ability to use/make bootable bare metal disks for backing >> stores >> > * Multiple NIC's and disks >> > * User settable (vs. auto assigned) backing store locations >> >> if backing store == virtual disk, this sounds fairly straight forward, >> though 'bootable bare metal disks' is certainly an attention grabbing >> statement for a hypervisor. >> > > As explained in the white paper, since we are a full layer 0 cloud > platform instead of just a hypervisor manager we can do stuff that would > normally not be
Re: [openstack-dev] FreeBSD/bhyve support for nova with libvirt
How do you handle the fact that as it stands bhyve can only run *nix like OS's (specifically FreeBSD and Linux only)? The long term answer seems to be a working kqemu or use something like PetiteCloud ( http://www.petitecloud.org) as a bridge (run OS nested on bhyve under PC) On Mon, Mar 31, 2014 at 1:01 PM, Michał Dubiel wrote: > Hi All, > > I have prepared commits I would like to have it reviewed and eventually > merged that add initial, limited support for FreeBSD as a host to nova. It > includes basic networking via freebsd_net driver (similar to the linux_net) > and few addons to libvirt compute driver in order to support the bhyve > hypervisor. Intent for those commits is let other play with openstack on > FreeBSD and to provide a code base for further development, as the current > version comes with many limitations like: > > - Only FreeBSD guest OSes can be used > - No support for the config drive > - Only one disk and one Ethernet interface > - No pause/resume functionality > - No VM migration support > - No files injection to VMs filesystem > - Only works with bridged networking using nova-network with Flat/FlatDHCP > multi-host mode > > Unit test are included, however, for all that to work on a real system you > have to use a slightly patched version of libvirt as not all features has > been merged to the official repository yet. My question is if that is > applicable to be merged at all, or should I wait for all necessary stuff to > be in libvirt official repository at first? I want also mention that there > is an active work underway in libvirt community to have all them > implemented and included in the libvirt code. > > Regards, > Michal > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Call for Testing: PetiteCloud's support for linux as a Cloud Foundation Layer
PetiteCloud is a Free Open Source and Open Knowledge Cloud Foundation Layer Tool that is designed to make OpenStack more stable and robust. See http://www.petitecloud.org for more details. We have recently added support for Linux (Ubuntu 12.04.3 LTS) as a host, we have had a FreeBSD production machine running PetiteCloud since september internally (there are about 40 or 50 FreeBSD users by our estimate). PetiteCloud 0.2.5 is our first widely usable version (all previous versions ran on FreeBSD). Since we are not Linux experts we have likely done a number of minor things wrong, as far we can tell nothing critical though, in the porting and would like help in tracking them down. -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Validating Addressing and Routing configuration
On Mon, Feb 10, 2014 at 3:38 PM, Veiga, Anthony < anthony_ve...@cable.comcast.com> wrote: > > > Question 1) Should we allow the user to build a potentially broken > network, knowing that there may be a use case we haven't covered? > In my non-OpenStack work I have found that if your using bridge-tools then if there is an open end point (connected to the bridge but not to an instance) and there is a packet in transit when this happens then the entire bridge bricks. > > Question 2) How do we alert the user of either a potentially invalid > configuration or a configuration that we have blocked? > It might be impossible to detect all possible modes... wouldn't it be offering false hope if you advertise the alert system to be anywhere near robust? -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] heartbleed
What components (if any) are vulnerable to heartbleed? -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
Theoretically impossible to reduce disk unless you have some really nasty guest additions. On Fri, Jun 13, 2014 at 6:02 AM, Day, Phil wrote: > Hi Folks, > > > > I was looking at the resize code in libvirt, and it has checks which raise > an exception if the target root or ephemeral disks are smaller than the > current ones – which seems fair enough I guess (you can’t drop arbitary > disk content on resize), except that the because the check is in the virt > driver the effect is to just ignore the request (the instance remains > active rather than going to resize-verify). > > > > It made me wonder if there were any hypervisors that actually allow this, > and if not wouldn’t it be better to move the check to the API layer so that > the request can be failed rather than silently ignored ? > > > > As far as I can see: > > > > baremetal: Doesn’t support resize > > > > hyperv: Checks only for root disk ( > https://github.com/openstack/nova/blob/master/nova/virt/hyperv/migrationops.py#L99-L108 > ) > > > > libvirt: fails for a reduction of either root or ephemeral ( > https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4918-L4923 > ) > > > > vmware: doesn’t seem to check at all ? > > > > xen: Allows resize down for root but not for ephemeral ( > https://github.com/openstack/nova/blob/master/nova/virt/xenapi/vmops.py#L1015-L1032 > ) > > > > > > It feels kind of clumsy to have such a wide variation of behavior across > the drivers, and to have the check performed only in the driver ? > > > > Phil > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do any hyperviors allow disk reduction as part of resize ?
Also ZFS needs to know what is on the guest for example bhyve (the only working hv for bsd currency [vbox kind of also works]) stores the backing store (unless bare metal) as single block file. It is impossible to make that non-opaque to the outside world unless you can run commands on the instance. On Fri, Jun 13, 2014 at 11:53 AM, Darren J Moffat wrote: > > > On 06/13/14 16:37, Daniel P. Berrange wrote: > >> The xenapi implementation only works on ext[234] filesystems. That rules >>> >out *BSD, Windows and Linux distributions that don't use ext[234]. RHEL7 >>> >defaults to XFS for instance. >>> >> Presumably it'll have a hard time if the guest uses LVM for its image >> or does luks encryption, or anything else that's more complex than just >> a plain FS in a partition. >> > > For example ZFS, which doesn't currently support device removal (except > for mirror detach) or device size shrink (but does support device grow). > ZFS does support file system resize but file systems are "just" logical > things within a storage pool (made up of 1 or more devices) so that has > nothing to do with the block device size. > > -- > Darren J Moffat > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
