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] 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] 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] 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.

[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] [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

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] 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] 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

[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] 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

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] 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

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

[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] 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

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

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

[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

[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

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] 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] 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

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] 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

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] 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] 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] 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

> > 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?

[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

> > 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

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

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] 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] 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] 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] 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] 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

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?)

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] 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?)

> > 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?)

> > 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

[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] 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

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] [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] 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] 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] 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

> > >>- 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

[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] 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

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

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

> > 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

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

[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] 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

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] [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

[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] 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

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 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] 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] 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] 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

[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] 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

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

> 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

[Openstack] Allowing clients to pass capability requests through tags?

Does anyone have any thoughts/objections on the blueprint I posted for allowing clients to pass capability-requests through tags? I'm planning on starting implementation soon, so if people think this is a bad idea I'd rather know before I start coding! Blueprint: https://blueprints.launchpad.net/

Re: [Openstack] Allowing clients to pass capability requests through tags?

request local volumes when > possible, yes? > > Devin > > On Feb 10, 2011, at 3:37 PM, Justin Santa Barbara > wrote: > > Does anyone have any thoughts/objections on the blueprint I posted for > allowing clients to pass capability-requests through tags? I'm planni

Re: [Openstack] Allowing clients to pass capability requests through tags?

> > > > On Feb 10, 2011, at 4:37 PM, Justin Santa Barbara wrote: > > > Does anyone have any thoughts/objections on the blueprint I posted for > allowing clients to pass capability-requests through tags? I'm planning on > starting implementation soon, so

Re: [Openstack] Allowing clients to pass capability requests through tags?

Can I try to summarize towards reaching a consensus: On Metadata for influencing schedulers / drivers: * I think people agree that it would be useful to be able to pass metadata in the request. e.g. for location, or to get specific hardware functionality (GPU or RAID), and for other things in f

[Openstack] Metadata schema design

I've coded support for metadata on instances. This is part of the CloudServers API, and I needed it for my idea about metadata hints to the scheduler. https://code.launchpad.net/~justin-fathomdb/nova/justinsb-metadata/+merge/49490 However, Jay Pipes has raised some (very valid) design questions o

Re: [Openstack] OpenStack Compute API 1.1

Some thoughts... General: - Are we writing the OpenStack API, or are we writing the document for the next version of Cloud Servers? In my opinion, the two need to be separate. For example, specifications of resource limits and rate limits, supported compression encodings, timeout o

Re: [Openstack] OpenStack Compute API 1.1

m. > I would propose that in the 1.2 or other future spec that /images move to an > action on /compute since that’s really what is happening. I don't know that > it makes sense to do so in 1.1 as changes are contentious enough without > being a total rewrite. > > Looking forward to

Re: [Openstack] OpenStack Compute API 1.1

> How would this work if someone didn't run a volume service or glance? > Should the api listen for that? > > My expectation is that if someone didn't run a volume service, we should expose that just as if there were insufficient resources (because that's not far from the case.) We'd return an er

Re: [Openstack] OpenStack Compute API 1.1

wrote: > > On Feb 15, 2011, at 1:06 PM, Justin Santa Barbara wrote: > > > OK - so it sounds like volumes are going to be in the core API (?) - > good. Let's get that into the API spec. It also sounds like extensions > (swift / glance?) are not going to be in the same API

Re: [Openstack] OpenStack Compute API 1.1

tly of each other. > > If you look at the diagram, the changes would entail moving from an amqp > protocol to a http protocol that a worker would hit on the public/admin > interfaces to accomplish the same work as before. > > Lets keep the thread going. > > Pvo > > >

Re: [Openstack] OpenStack Compute API 1.1

ive internal re-architecting. On Thu, Feb 17, 2011 at 4:18 PM, Jay Pipes wrote: > On Thu, Feb 17, 2011 at 6:57 PM, Justin Santa Barbara > wrote: > > Pulling volumes & images out into separate services (and moving from AMQP > to > > REST) sounds like a huge breaki

Re: [Openstack] OpenStack Compute API 1.1

> > >Sorry, I don't view the proposed changes from AMQP to REST as being > >"customer facing API changes". Could you explain? These are internal > >interfaces, no? > > > >-jay > > > >On Thu, Feb 17, 2011 at 8:13 PM, Justin Santa Barbara >

Re: [Openstack] OpenStack Compute API 1.1

ders will but I see this as entirely optional, not > required to use the services. > > The push to get a completed compute api is the desire move away from the > ec2 api to something that we can guide, extend and vote on as a community. > The sooner we do the the better. > > H

Re: [Openstack] OpenStack Compute API 1.1

t; important and would encourage dialog amongst the community to come to a > consensus on this. Per my points above, I would prefer to avoid separate > APIs for the same service. Let's see if we can get behind a per service API > that becomes THE defacto standard way for au

[Openstack] Should the OpenStack API re-use the EC2 credentials?

I previously fixed OpenStack authentication so it would use the same credentials as EC2. This bugfix was just reverted, because it caused OpenStack API users to have to enter in different credentials (sorry!), but primarily because it hadn't been discussed on the mailing list. So here goes! Here

Re: [Openstack] Should the OpenStack API re-use the EC2 credentials?

ually. > > Vish > > On Feb 23, 2011, at 5:56 PM, Justin Santa Barbara wrote: > > I previously fixed OpenStack authentication so it would use the same > credentials as EC2. This bugfix was just reverted, because it caused > OpenStack API users to have to enter in different cr

Re: [Openstack] Should the OpenStack API re-use the EC2 credentials?

I consumers out there already. It's likely that most just haven't > pulled trunk since it landed. > > I think we all agree that a decision on a standard needs to be made to > avoid further pain down the road, even if it's just between us devs. > > > On Wed, Feb

Re: [Openstack] Should the OpenStack API re-use the EC2 credentials?

an > example this is already done in the S3 compatibility layer for Swift. > > -- > Chuck > > On Wed, Feb 23, 2011 at 7:56 PM, Justin Santa Barbara > wrote: > >> I previously fixed OpenStack authentication so it would use the same >> credentials as EC2. This bugf

Re: [Openstack] Should the OpenStack API re-use the EC2 credentials?

The issue is that _if_ you're also running the EC2 API over non-SSL (which is supposed to be safe - other than for replay attacks?), then you send the api_key in the clear (the api_secret remains secret because it's only 'passed' via the one-way-hashed signature.) However, api_key is currently the

Re: [Openstack] Should the OpenStack API re-use the EC2 credentials?

open to talking about how to better the auth system and > make > > improvements. Dragon has already discussed some alternatives and > suggestions > > on the BP page below. I think this is the right way to continue the > dialog > > and we all can agree on a good way f

Re: [Openstack] Should the OpenStack API re-use the EC2 credentials?

nt trunk. We > just need the tests. No matter how many stability levels of trunk we have, > without better tests we can't guarantee stability. > > On Thu, Feb 24, 2011 at 11:15 AM, Justin Santa Barbara < > jus...@fathomdb.com> wrote: > >> Hi Jay, >> >> I co

Re: [Openstack] Working on fixing code after a review? Please mark merge proposal Work In Progress!

Good call Jay - I'll do my best to remember to do this! Why are branches with unmerged pre-reqs showing up in that list? If reviewers are working from that list, that just seems to be creating extra work, which you probably don't need! Justin On Fri, Feb 25, 2011 at 10:07 AM, Jay Pipes wrote:

[Openstack] How to deal with 'tangential' bugs?

Jay and I have been having an interesting discussion about how to deal with bugs that mean that unit tests _should_ fail. So, if I find a bug, I should write a failing unit test first, and fix it (in one merge). However, if I can't fix it, I can't get a failing unit test merged into the trunk (be

Re: [Openstack] server affinity

Yes - the use case I'm working towards is to use metadata to specify "openstack:near=volume-01" when creating a machine, and I will provide a scheduler that will take that information and will assign you a machine e.g. in the same rack as the volume storage. It's unclear right now whether this

Re: [Openstack] How to deal with 'tangential' bugs?

s+tim.simpson=rackspace@lists.launchpad.net[openstack-bounces+tim.simpson= > rackspace@lists.launchpad.net] on behalf of Clay Gerrard [ > clay.gerr...@rackspace.com] > Sent: Monday, February 28, 2011 3:09 PM > To: Dan Prince; Justin Santa Barbara > Cc: open

Re: [Openstack] server affinity

ple, we don't set the image type with > metadata, instances are created by providing an image type. Perhaps the two > aren't analogous because if "openstack:near" changes the instance would > migrate to another location? Or if "volume-01" was moved, d

Re: [Openstack] server affinity

). However, we have no choice but to reserve the "aws:" prefix or be incompatible down the road. And if "aws" has a prefix in our API, probably "openstack" shouldn't be the only API without a prefix, otherwise it would be unhAPI. Justin > -Original Messag

  1   2   >