Re: [Openstack] ZFS/ZVol + iscsi for volume

As Diego pointed out, this should all work already. You just point your nova-volume at your Solaris-like box, and it runs all the commands for you (over SSH). I wrote the original way-back-when as a stepping-stone to support for HP SANs (as I had much easier access to Solaris than real SANs), and

Re: [Openstack] Encrypted virtual machines

On Thu, Apr 26, 2012 at 3:08 PM, Justin Santa Barbara > wrote: > > I think that Intel's trusted cloud work is trying to solve that exact > > compute host problem. It may already have the framework to do so even if > > the software hasn't caught up (i.e. if we still have s

Re: [Openstack] Encrypted virtual machines

I think that Intel's trusted cloud work is trying to solve that exact compute host problem. It may already have the framework to do so even if the software hasn't caught up (i.e. if we still have some work to do!) It relies on a TPM chip, all code is measured before being run, and then there's a

Re: [Openstack] Encrypted virtual machines

On Thu, Apr 26, 2012 at 9:05 AM, Matt Joyce wrote: > >From a security stand point I am curious what you see the benefit as? I think that long-term there is the potential to have a cloud where you don't have to trust the cloud provider (e.g. Intel Trusted Compute). However, there are a huge num

[Openstack] How does everyone build OpenStack disk images?

How does everyone build OpenStack disk images? The official documentation describes a manual process (boot VM with ISO), which is sub-optimal in terms of repeatability / automation / etc. I'm hoping we can do better! I posted how I do it on my blog, here: http://blog.justinsb.com/blog/2012/04/25

Re: [Openstack] [OpenStack][Nova] Minimum required code coverage per file

one: 81% > swift: 80% > horizon: 91% > > Perhaps we get nova and glance up to 80 and then set the threshold for 80? > > Also, turns out we're not running this on the client libs... > > Monty > > On 04/25/2012 03:53 PM, Justin Santa Barbara wrote: > > If you

Re: [Openstack] [OpenStack][Nova] Minimum required code coverage per file

If you let me know in a bit more detail what you're looking for, I can probably whip something up. Email me direct? Justin On Wed, Apr 25, 2012 at 6:59 AM, Monty Taylor wrote: > > > On 04/24/2012 10:08 PM, Lorin Hochstein wrote: > > > > On Apr 24, 2012, at 4:11 PM, Joe Gordon wrote: > > > >>

Re: [Openstack] File injection and disk resize not working

I believe config-drive is the way to fix injection problems. I use it and it works great. (I just wish there was a way to use it from Horizon...) We'll never be able to inject into every image; also some people don't want us messing with their images. Config drive is effectively injection into

[Openstack] Public image repository via a synchronization script

nd yes, there is a real image up there - check out http://images.platformlayer.org/md5sum ... Justin --- Justin Santa Barbara Founder, FathomDB ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubs

Re: [Openstack] Canonical AWSOME

Thanks for the pointer. I found the etherpad: http://etherpad.openstack.org/VersioningNovaRPCAPIs Is there a blueprint that came / is coming out of that? I think the data representation is orthogonal e.g. in theory, we could even use XML schemas: PyDict --> XML --> XML Schema Validation --> Warn

Re: [Openstack] Canonical AWSOME

> > If EC2 API is limiting what we can do, that's not going to change just > because you move the EC2 API implementation into a proxy in front of the > OpenStack API. The only difference is that it's suddenly the AWSOME > development team's problem. > I think it's actually the EC2 API caller's pro

Re: [Openstack] Canonical AWSOME

On Mon, Apr 23, 2012 at 12:31 PM, Eric Windisch wrote: > There seemed to be a strong agreement at the summit regarding the need for > contracts on those "private" apis. This is because those APIs are no longer > really private, they're shared amongst incubated projects. Furthermore, it > seems th

Re: [Openstack] Canonical AWSOME

be made to scale in Nova, > but a REST endpoint won't be as reliable or scale as well. > > -- > Eric Windisch > > On Monday, April 23, 2012 at 11:15 AM, Justin Santa Barbara wrote: > > What's the advantage of replacing the native EC2 compatibility layer with >

Re: [Openstack] Canonical AWSOME

> > What's the advantage of replacing the native EC2 compatibility layer with > AWSOME from a user / operator point of view? > Although I wasn't able to attend the design summit session, right now we have two "native" APIs, which means we have two paths into the system. That is poor software engi

[Openstack] PlatformLayer adds support for Solr-as-a-Service

Inspired by the launch of AWS CloudSearch on Thursday, I added Solr-as-a-service to PlatformLayer so that we could have search-as-a-service on Openstack as well: http://news.ycombinator.com/item?id=3841826 I think it's a nice demonstration of what "everything as a service" means! My ecosystem tal

Re: [Openstack] Just JSON, and extensibility

> > >>- Each (known) extension has its own strongly-typed model object. >> >> > Does that mean that an extension cannot add properties to an existing > object (such as adding a new attribute an Image), or just that all of those > properties will be an a nested object (such as > Image.my_extensi

Re: [Openstack] Just JSON, and extensibility

It's easy when each new version is defined by a central body. The problem we face is that we want to allow HP, Rackspace, Nexenta etc to define their own extensions, without serializing through a central body. Some extensions may only apply to private clouds and never be shared publicly. This is

Re: [Openstack] Just JSON, and extensibility

I don't think that works for non-linear extensibility... I would be very happy if we could agree out how we're going to deal with extensibility in JSON. It is easy to support XML & JSON & any future formats, and have them all be nice if there's willingness to do so, but there's not, so let's drop

Re: [Openstack] Image API v2 Draft 4

I may disagree with a couple of the points along the way; but I agree with the conclusion for OpenStack. Thanks for writing it! Justin PS vim or emacs? On Thu, Apr 12, 2012 at 12:58 PM, Mark Nottingham wrote: > A little fuel for the fire / entertainment before the summit: > http://www.mnot

Re: [Openstack] [SWIFT] Looking for an approach to attach an account or a container in operating system . Like a NAS of SAN driver.

I made some patches to cloudfuse to get it to support Keystone auth: http://blog.justinsb.com/blog/2012/03/29/openstack-storage-with-fuse/ I'd like to get this merged upstream, but haven't heard anything on my pull request... Redbo? Bueller? :-) I also saw an SFTP gateway floating about somewhe

Re: [Openstack] minimal IaaS openstack installation FROM SOURCE on CentOS

I have it running from source in a more-production-environment than devstack, though on Debian... https://github.com/justinsb/openstack-simple-config Would you like to collaborate on fixing this up for CentOS & the Essex release? It was working a week or two before feature freeze, and post Keysto

Re: [Openstack] profiling nova-api

Both the profiling & the multi-process work are great - good stuff! Jay: Won't going multi-process just make it harder to profile? I think it's actually a good thing to profile without the multi-process patch, find & fix and the bottlenecks in single-request performance, and then use multi-proces

[Openstack] Metadata and File Injection (code summit session?)

On Tue, Apr 10, 2012 at 4:37 PM, Vishvananda Ishaya wrote: > On Apr 10, 2012, at 4:24 PM, Justin Santa Barbara wrote: > > One advantage of a network metadata channel is it allows for >> communication with cloud provider services without having to put a key into >> the vm. In oth

Re: [Openstack] Metadata and File Injection (code summit session?)

> > One advantage of a network metadata channel is it allows for communication > with cloud provider services without having to put a key into the vm. In > other words, the vm can be authenticated via its ipv6 address. > Did you have a use case in mind here? It seems that Keystone could use the I

Re: [Openstack] Metadata and File Injection (code summit session?)

> > The immediate use case I have in mind is to support this: > http://wiki.openstack.org/**PackageConfigForNova. > That design requires periodic checkins between an instance agent and a > nova driver. It certainly /could/ be implemented using ssh,

Re: [Openstack] Metadata and File Injection (code summit session?)

> > Having the ability to read config data from a runtime changeable > metadata server (rather then a config file on an injected disk) serves a > use case I am interested in. The only problem is horizontal scalability > of the metadata server in this model which may not be a problem with > some ti

Re: [Openstack] Metadata and File Injection (code summit session?)

I presume you're looking for more than SSH offers. What are the missing features you need? On Tue, Apr 10, 2012 at 12:36 PM, Andrew Bogott wrote: > What I crave is a communication channel between nova and running > instances. There was discussion at some point about extending the metadata > ap

Re: [Openstack] Image API v2 Draft 4

ages. It offers key benefits in terms of > extensibility and validation. I'd hate to lose it. > > -jOrGe W. > > On Apr 10, 2012, at 12:57 PM, Justin Santa Barbara wrote: > > It definitely has improved - thank you for all your work; I didn't mean > to put down

Re: [Openstack] Metadata and File Injection (code summit session?)

Config drive can support all EC2 functionality, I believe. Images would need to be respun for OpenStack with config-drive, unless we populated the config drive in a way that worked with cloud-init. (Scott?) Personally, I'd rather our effort went into producing great images for OpenStack, than in

Re: [Openstack] Image API v2 Draft 4

It definitely has improved - thank you for all your work; I didn't mean to put down anyone's work here. It's simply a Sisyphean task. Either way, though, if I had the choice, I'd rip all of nova's XML support > out tomorrow… > As a strong supporter of XML, who thinks JSON is for kids that haven

Re: [Openstack] Agreeing a common set of Image Properties

Signing would definitely be a great v2 feature. For v1, we just need some way to know that an image is provided by the cloud provider, and some idea of what that image "is". I believe every cloud is stuck respinning their own images, because we haven't been able to agree a "golden image" standard

Re: [Openstack] Announcing project Heat

Congratulations on your project! Just to clarify, PlatformLayer can run anything as a service, not just databases. I added support for running memcache as a service last night, and Zookeeper clusters on Sunday... I think RedDwarf is also moving away from just supporting DBs. A crowded space ind

Re: [Openstack] Metadata and File Injection (code summit session?)

I think config drive is "injection done right"; it doesn't need to figure out a partition because it creates its own. Config drive + the init script I've contributed is rock-solid for me. No metadata service to go slow or need special configuration, no DHCP problems etc. If there's a proliferati

Re: [Openstack] Image API v2 Draft 4

ion; just using what Nova had (and hopefully moving > it to openstack-common before bringing the code into Glance). > > Best, > -jay > > > On 04/10/2012 06:51 AM, Doug Hellmann wrote: > >> >> >> On Mon, Apr 9, 2012 at 5:14 PM, Justin Santa Barbara >> m

Re: [Openstack] Image API v2 Draft 4

> > Extensible lists are pointless. Lists have no attributes other than their > length. I made this point a couple design summits ago... but whatever :) Looks like the Sapir-Whorf hypothesis might be true after all ;-) Let's dust off the pugil-sticks for the design summit.. _

Re: [Openstack] Image API v2 Draft 4

> > How about we discuss this further at the summit :-) > I think that's a sensible proposal. We're not likely to reach a good conclusion here. I think my viewpoint is that even json-dressed-as-xml is fine; no end-user gives two hoots what our JSON/XML/HPSTR looks like. I'd wager most users of

[Openstack] Agreeing a common set of Image Properties

> > >> Are the major and minor numbers going to be sufficient versioning >>> information? See for example PEP 386 for more detailed version strings ( >>> http://www.python.org/dev/peps/pep-0386/). >>> >> >> For a distro, I believe yes. Do you have a counter-example? >> > > Not off the top of my he

Re: [Openstack] Image API v2 Draft 4

> > When you're designing JSON considering only JSON, you'd probably use { >> > key1: value1 } - as you have done. If you're designing generically, >> you'd probably use { key: key1, value: value1 }. >> > > You mean we'd have to do dumb crap because XML doesn't have the native > concept of a list?

Re: [Openstack] Agreeing a common set of Image Properties

I should probably clarify my terminology a little here, as I may have mangled it: - I'm talking about additional/extension properties, not properties that are well-known to Glance - However, we agree to use a common set of properties to mean certain things. In other words, we all agre

Re: [Openstack] Image API v2 Draft 4

> > Justin, what does "design a model which works with XML" mean? Simply avoiding the handful of things that are specific to JSON (or specific to XML). Nothing too onerous (no angle brackets)! > I think this is only done in the image properties. >> > > No, the image properties have been remove

Re: [Openstack] Image API v2 Draft 4

> > APPENDIX B: Outstanding issues > > 4) Need to write xsds :( > This is easy if you design a model which works with XML. If you have an XML compatible model, you can generate an XSD and a JSON model from that. Also, it means you can just use common middleware to map XML to JSON, rather than co

Re: [Openstack] Agreeing a common set of Image Properties

On Mon, Apr 9, 2012 at 8:18 AM, Doug Hellmann wrote: > I'm thinking of the os prefix as standing for OpenStack, not Operating >> System. >> > > I would never have guessed that from the context. Why OpenStack instead of > Operating System? > We reserve this limited region of the namespace (opensta

Re: [Openstack] Jcloud and openstack relation

There is also a (friendly rival) OpenStack Java binding being developed: https://github.com/platformlayer/openstack-java https://github.com/woorea/openstack-java-sdk/ That library supports a direct-to-OpenStack Jenkins plugin which I confidently predict will rapidly surpass any lowest-common-denom

Re: [Openstack] Agreeing a common set of Image Properties

day being populated automatically using these cool tools in future! Justin 2012/4/7 Nathanael Burton > Looks like Pádraig and I were thinking alike. > On Apr 7, 2012 8:49 PM, "Pádraig Brady" wrote: > >> On 04/07/2012 11:13 PM, Justin Santa Barbara wrote: >> > Is

Re: [Openstack] Agreeing a common set of Image Properties

ro that this image was originally based upon. > > I also need to denote things like managed service level for an image > that might be the same base distro as an unmanaged image. > > Sent from my iPhone > > On Apr 7, 2012, at 5:14 PM, "Justin Santa Barbara" > wrote

[Openstack] Agreeing a common set of Image Properties

have it behave more or less the same; I shouldn't have to second guess any additional tweaks. - I would like to be able to launch the clean image and install updates myself, in case I don't want a particular update. Providing a fast apt cache is much better than provi

Re: [Openstack] Introducing PlatformLayer: Everything-as-a-service, for OpenStack

et me show you the head-start PlatformLayer gives you; in return I'll get to see more of the areas where it is lacking! Justin On Fri, Apr 6, 2012 at 4:04 PM, Mark Collier wrote: > Justin-as-a-Service? > > > Justin Santa Barbara wrote: > > > FathomDB has just open-sou

[Openstack] Introducing PlatformLayer: Everything-as-a-service, for OpenStack

ests? RabbitMQ-as-a-service?) Read more: http://blog.justinsb.com/blog/2012/04/06/introducing-platformlayer/ Discussion on hacker news: http://news.ycombinator.com/item?id=3809221 Please contact me if you're interested in using it or helping out! Thanks, Justin --- Justin Santa

[Openstack] Java 7 File Provider for OpenStack Storage

p any bugs you find! There's almost no documentation out there on how to do this, so I don't think any of the legacy clouds support this. Another small step forward for OpenStack! Justin --- Justin Santa Barbara Founder, FathomDB ___ Mail

Re: [Openstack] OpenStack Plugin for Jenkins

I've got Compute functionality working with the OpenStack Jenkins plugin, so it can launch nova instances as on-demand slaves now, run builds on them, and archive the results into swift. I'd like to open GitHub issues to track your requirements, but I have a few questions. > We need disposable m

Re: [Openstack] OpenStack Plugin for Jenkins

Thanks - there are some good feature requests here. Have you proposed a design summit session where you are going to talk about OpenStack features that you would like to see? Things like supporting cloud federation, instance pooling, or fixing that networking bug? The Jenkins features (e.g. asso

Re: [Openstack] OpenStack Plugin for Jenkins

at doesn't give OpenStack users anything. I hope the OpenStack CI team will join me in working on something that advances OpenStack, rather than spending any more time propping up the dying clouds :-) Justin On Wed, Apr 4, 2012 at 2:54 PM, Andrew Hutchings wrote: > On 04/04/12 20:42, Ju

[Openstack] OpenStack Plugin for Jenkins

ugin flattens all directories when copying artifacts, that just seems wrong to me, so I'd like to just fix it. Justin --- Justin Santa Barbara Founder, FathomDB ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.

Re: [Openstack] Performance diagnosis of metadata query

for critical bugs in a week > or so from release. I am not saying this is great, but if release dates > are fixed and features, performance the things that are allowed to vary, > then what else is there to do? Just my opinion. > > -David > > > On 3/29/2012 1:55 PM, Justi

Re: [Openstack] Performance diagnosis of metadata query

just fix X. On Thu, Mar 29, 2012 at 10:22 AM, David Kranz wrote: > On 3/29/2012 12:46 PM, Justin Santa Barbara wrote: > > Is there a good way to map back where in the code these calls are coming >> from? > > > There's not a great way currently. I'm trying to ge

Re: [Openstack] Performance diagnosis of metadata query

> > Is there a good way to map back where in the code these calls are coming > from? There's not a great way currently. I'm trying to get a patch in for Essex which will let deployments easily turn on SQL debugging (though this is proving contentious); it will have a configurable log level to al

Re: [Openstack] KVM crash.

The libvirt hang was a threading deadlock within libvirt, whereas this is a kernel crash. I'd be surprised if they are the same issue. The current theory on the kernel bugzilla is that it might be related to bridge + netfilter. That does tally with the observation of it happening under a network

[Openstack] Performance diagnosis of metadata query

The performance of the metadata query with cloud-init has been causing some people problems (it's so slow cloud-init times out!), and has led to the suggestion that we need lots of caching. (My hypothesis is that we don't...) By turning on SQL debugging in SQL Alchemy (for which I've proposed a p

Re: [Openstack] Caching strategies in Nova ...

This is great: hard numbers are exactly what we need. I would love to see a statement-by-statement SQL log with timings from someone that has a performance issue. I'm happy to look into any DB problems that demonstrates. The nova database is small enough that it should always be in-memory (if yo

Re: [Openstack] Please stop the devstack non-sense!

Hi Thomas, I think devstack has done a lot for the developer's use-case, but I believe we should also have a official / semi-official project that does some sort of packaging to help the production use-case. I've proposed a summit discussion: http://summit.openstack.org/sessions/view/26 The back

Re: [Openstack] Essex keystone with remote glance endpoint

> > # glance -I adminUser -K ... -S keystone -N > http://192.168.131.141:5000/v2.0' index > Failed to show index. Got error: > Response from Keystone does not contain a Glance endpoint. > I think that means that the glance client can't find a suitable glance endpoint in the response from Keystone

Re: [Openstack] [NOVA] Snapshotting may require significant disk space (in /tmp). How to properly solve disk space issues?

We're creating a (huge) temp file, uploading it, and then deleting it. So really we should be streaming the snapshot direct to the destination (glance?) Checking the code, we are writing it sequentially (particularly if we're writing in raw): https://github.com/qemu/QEMU/blob/master/qemu-img.c

[Openstack] Networking guru needed: problem with FlatManager ARP when guest and bridge MACs the same

We recently changed the MAC address assigned to guests so that they started with 0xfe, in the hope of avoiding (theoretical?) issues with MAC addresses changing on the bridge device as machines are shut down (because supposedly the bridge grabs the lowest MAC address numerically): https://bugs.laun

Re: [Openstack] Random libvirt hangs

e as well. I will be much happier if we just say "we aim to support X"; I don't really care what X is. I'm just going to be running OpenStack on the machine, so I'm not picking my distro e.g. based on how I feel about Unity. I'd imagine most users are in a similar camp.

Re: [Openstack] Random libvirt hangs

I just today was able to diagnose a libvirt hang. It appears to be (similar to) a known bug in libvirt, likely fixed in the latest Fedora, but it does not appear to be fixed in Ubuntu Oneirc; I think the fix is in Precise: https://bugs.launchpad.net/nova/+bug/953656 I believe this is the upstream

Re: [Openstack] Libvirt Snapshots

Thanks for the background. My thoughts: * Telling a user to build from source isn't a great option for them - it's painful, they don't get updates automatically etc. Are we going to start distributing packages again? * I can't imagine any open source project removing functionality like the QEMU

Re: [Openstack] Libvirt Snapshots

Pedantry: It's QEMU/KVM, not libvirt, that holds the disks open.  The pedantry does make a difference here I think... A more sustainable option than being on the bleeding edge of libvirt may be to try to bypass libvirt and issue those safe QEMU monitor commands directly.  Libvirt would normally pr

Re: [Openstack] Basic networking/configuration woes

> The instance firewall should be configured to only allow DHCP > responses from the IP it believes to be the correct DHCP server. > Perhaps it has the wrong idea? Ah yes - it probably does because of my unusual network "subrange" config. It seems I'm not "missing something", so I've proposed a i

Re: [Openstack] Basic networking/configuration woes

> If you're going to go the cloud-init route... you wouldn't need DHCP, right?   > There should be iptables rules to allow you to talk to the metadata service > over 169.254.*  (And linux should give you a default link-local address that > allows you to talk to the MD service magically) > > Do y

Re: [Openstack] Basic networking/configuration woes

should receive a link local address when there's no other IP assigned > which is in the 169.254.* range. > > Not sure if that helped much :) > > - Chris > > On Feb 23, 2012, at 3:12 PM, Justin Santa Barbara wrote: > >> I'm trying to use OpenStack in what

[Openstack] Basic networking/configuration woes

I'm trying to use OpenStack in what I think to be the typical non-public-cloud deployment, and my experience is not what it could/should be.  I'm hoping someone can point me to the "right way", or we can figure out what needs to change. My wishlist: * I want my instances to be on "my network" e.g.

Re: [Openstack] DeltaCloud

In my experience, the API is the most visible yet smallest problem of working with different clouds. For example, EC2 and Rackspace Cloud have completely different approaches to volumes, such that the way you backup your VMs has to be completely different (disk snapshot vs application level). Rac

Re: [Openstack] OpenStack Java API

e valid XSD files. My fork is here: https://github.com/justinsb/openstack-java-sdk I'd like to work together on this! Justin --- Justin Santa Barbara Founder, FathomDB On Mon, Feb 13, 2012 at 8:53 AM, Luis Gervaso wrote: > The Dasein Arch is great and the code is very clean

Re: [Openstack] Getting pagination right

I definitely agree that the paging logic is questionable; we definitely should be specifying the sort order if we're relying on it, as I believe a database is otherwise free to return results however it sees fit. I'm not convinced that the proposed logic around the queries and update timestamps is

Re: [Openstack] Proposal for Justin Santa Barbara to join Nova-Core

Great news - thank you all! Justin On Fri, Apr 15, 2011 at 1:24 AM, Soren Hansen wrote: > 2011/4/12 Soren Hansen : >> +1 from me, too. >> >> As per the process, if no-one objects within 5 business (my >> interpretation) days, i.e. before Thursday, I'll get Justin added to >> the nova-core tea

Re: [Openstack] Summit Talk: Information session on Zones? Any interest?

I'm not sure what you mean by an 'informational session'? That sounds rather didactic - is everything sufficiently agreed for a session of this type? I was under the impression that a lot of the details of zones were not yet agreed, and that a lot of the use cases we would like to see in future w

Re: [Openstack] Proposal to defer existing OS API v1.1 to Diablo, for greater stability in Cactus

I think there are a few distinct issues: 1) XML support. I was thinking that most XML issues would also be issues in the JSON, so validating the XML will also serve as validating the JSON. I'd appreciate an example here, but I agree in general that focusing on JSON is acceptable - as long as its

[Openstack] Proposal to defer existing OS API v1.1 to Diablo, for greater stability in Cactus

I have been doing some work on getting XML support in our APIs in better shape in the OS API. However we feel about XML, the big benefit is that it gives us really strict validation for free. I am only at the point of adding namespace declarations, but this has already uncovered a lot of issues w

Re: [Openstack] Feature Freeze status

> > We'd all love to have more people working on OpenStack. > Though I'm loathe to continue this debate, I would suggest that blueprints may not be helping us on this front. Justin ___ Mailing list: https://launchpad.net/~openstack Post to : opensta

Re: [Openstack] Feature Freeze status

> > Rubbish. Open development means knowing the general directions and > specifications that people are working on by open discussions, open > blueprints/specs, and active communication between teams. I can go to > github and see how many people "forked this" (ugh.). That doesn't give > me any clue

Re: [Openstack] Feature Freeze status

No objection to a discussion during the summit, but I've been able to watch all of these branches and others evolve here: https://code.launchpad.net/nova For example, when I wanted to add VNC support because my system wouldn't boot, it was easy for me to look at the vnc_console branch and get the

Re: [Openstack] Instance IDs and Multiple Zones

> > So I'm going to implement a partition of 1 billion integers per zone, > which should allow for approximately 1 billion zones, given a 64 bit integer > for the PK. This should be workable for now, and after the design summit, > when we've come to a consensus on changing the API to accept someth

Re: [Openstack] Instance IDs and Multiple Zones

> > Migrations outside of a zone would require a new > instance ID, but this should be fine, since other things would also > change (such as IP, available volumes, ...). A cross-zone migration > will be more of a copy+delete than a proper move. +1 on this. If the IP is changing, there's little p

Re: [Openstack] Instance IDs and Multiple Zones

Indeed, migrations are a major fly in the ointment for any strategy for meaningful naming (i.e. anything that doesn't use a central DB). It's not clear to me with cross-zone migrations that we (a) can keep the same ID and (b) want to keep the same ID even if we could... We could look at tricks li

Re: [Openstack] Instance IDs and Multiple Zones

> Pure numeric ids will not work in a federated model at scale. > Agreed > Maybe I'm missing something, but I don't see how you could inject a > collision ID downstream - you can just shoot yourself in your own foot. I think that you can get away with it only in simple hierarchical structures.

Re: [Openstack] Openstack API - Volumes?

1 at 1:20 PM, Jay Pipes wrote: > On Tue, Mar 22, 2011 at 3:21 PM, Justin Santa Barbara > wrote: > > So: When can we expect volume support in nova? If I repackaged my > volumes > > API as an extension, can we get it merged into Cactus? > > I would personally support t

Re: [Openstack] Instance IDs and Multiple Zones

string version for > now. > > Vish > > On Mar 22, 2011, at 12:51 PM, Justin Santa Barbara wrote: > > EC2 uses xsd:string for their instance id. I can't find any additional > guarantees. > > Here's a (second hand) quote from Amazon: > > > http:

Re: [Openstack] Instance IDs and Multiple Zones

er we have to provide a way for ec2 style ids to be > assigned to instances, perhaps through a central authority that hands out > unique ids. > > Vish > > On Mar 22, 2011, at 12:30 PM, Justin Santa Barbara wrote: > > The API spec doesn't seem to preclude us from doing a f

Re: [Openstack] Instance IDs and Multiple Zones

need a zone identifier prefix on the > >IDs. I think we need to get away from numbers. I don't see any reason > >why they need to be numbers. But, even if they did, you can pick very > >large numbers and reserve some bits for zone ID. > > > >- Chris > >

Re: [Openstack] Openstack API - Volumes?

There are many existing volume solutions. Some are in production use (AoE, iSCSI). There are enterprise-class SAN providers (Solaris, HP/LeftHand SANs). There are existing projects to build 'cloud' storage solutions that are shaping up very well (SheepDog, RBD). It's great that you're thinking

Re: [Openstack] Instance IDs and Multiple Zones

Totally agree with Eric. Two questions that I think can help us move forward: 1. Is the decision to stick with integers still valid? Can someone that was there give us the reason for the decision? Is it documented anywhere? 2. If "we must have integers" means that we get 128 bit 'rand

Re: [Openstack] Instance IDs and Multiple Zones

I think _if_ we want to stick with straight numbers, the following are the 'traditional' choices: 1) "Skipping" - so zone1 would allocate numbers 1,3,5, zone2 numbers 2,4,6. Requires that you know in advance how many zones there are. 2) Prefixing - so zone0 would get 0xxx, zone1 1xx. 3) C

Re: [Openstack] GLANCE: How to deal with SQLAlchemy-migrate problems

Do we have patches for approach #3? I'm thinking that if we have a few specific issues, that maybe we could maintain our own branch and/or monkey-patch SA-migrate, and get a better handle on the problem, and the upstream's project receptiveness to patches (rather than bug reports). It's a bit mor

Re: [Openstack] A single cross-zone database?

e stick here? Are these our choices? Justin On Wed, Mar 16, 2011 at 1:13 PM, Ed Leafe wrote: > On Mar 16, 2011, at 3:39 PM, Justin Santa Barbara wrote: > > > I agree that we could have a better marker, but I'm just going off the > spec at the moment. > > > >

Re: [Openstack] A single cross-zone database?

I agree that we could have a better marker, but I'm just going off the spec at the moment. I've checked the agreed blueprint, and caching in zones is out of scope for Cactus. Please propose a discussion topic for the Design Summit. Justin On Wed, Mar 16, 2011 at 12:21 PM, Eric Day wrote:

Re: [Openstack] A single cross-zone database?

Inline... > Can someone explain _why_ we need caching? > > We don't *need* caching - it is simply the most direct way to avoid > multiple expensive calls. So if we don't need it...? You cite avoiding expensive calls, but I think it's entirely unproven that those call are too expensive.

Re: [Openstack] A single cross-zone database?

n for compatibility) Justin --- Justin Santa Barbara Founder, FathomDB On Wed, Mar 16, 2011 at 11:14 AM, Andrew Shafer wrote: > > Global temporal consistency is a myth. > > If you decide not to cache and support pagination then querying every zone > for every page is potent

Re: [Openstack] A single cross-zone database?

Good point that pagination makes this harder. However, thankfully the limit is implemented using a token (the last ID seen), not an absolute offset, so I believe we can still do pagination even in loosely coordinated DBs. Good job whoever dodged that bullet (Jorge?) (Aside #1: Sorting by uptime

Re: [Openstack] A single cross-zone database?

Thanks for raising this Sandy: +1 on keeping separate DBs until a problem arises. I don't see a performance problem with recursively querying child zones. I guess this will partially depend on our zone topology: if the intent is to have child zones that are geographically distributed where the la

Re: [Openstack] [Nova] Review and bug priorities

I've been moaning about the fact that Nova is like a happy oblivious little child for way too long, so I'll take on the two bugs that teach it that things can go wrong in the real world: When a node dies, its instances should be marked !running https://bugs.launchpad.net/nova/+bug/661214 nova-com

  1   2   >