On 10/11/2011 09:02 PM, Mark Nottingham wrote:
Linear versioning is of very limited use.
If OpenStack wants to keep a clear definition of what the OpenStack CORE
is, then this needs to evolve linearly (austin, bexar, cactus, diablo,
essex, etc...). I think you could make an argument that this s
Hi!
Could someone answer for my question?
2011/10/7 Roman Sokolkov
> Hi! For my research I think Diablo doesn't support LVM block devices for
> VMs, does it?
>
> In /usr/share/nova/libvirt.xml.template only file supports for main disk
> device. I am right?
>
> #if $getVar('rescue', False)
>
On 10/11/2011 10:27 AM, George Reese wrote:
Yes, my proposed solution requires OpenStack implementations to support ALL
major versions of ALL APIs. That's absolutely critical for building a healthy
ecosystem.
That may be completely impossible if different versions require
incompatible underlyi
On 10/11/2011 12:15 PM, Brian Waldon wrote:
That is one case that would require a major version change where a
URI is still valid. However, changes to the URI are still allowed
across major versions. That causes me to think content-types are
not good
Hey Everyone,
We had a great design summit. Lots of new features were presented, along with
some great proposals for cleanup, stability, upgradability, etc. I'm
attempting to capture all of the proposed action items in one etherpad, with
links to specific blueprints. You can find the etherpa
I logon dashboard and when I click to images/instances web, error occurs on
terminal.
Traceback (most recent call last):
File "/usr/lib/pymodules/python2.7/eventlet/greenpool.py", line 80, in
_spawn_n_impl
func(*args, **kwargs)
File "/usr/lib/pymodules/python2.7/eventlet/wsgi.py", line 508, in
pro
I've started a list of proposed goals here:
http://wiki.openstack.org/Governance/Proposed/APIGoals
Please pile on...
On 11/10/2011, at 11:53 PM, Jay Pipes wrote:
> On Tue, Oct 11, 2011 at 1:11 AM, Mark Nottingham wrote:
>> +1 (sorry for the lag, been travelling).
>>
>> I'd like to start tw
It might help to talk about *what* might change, and what kinds of versioning
are available.
E.g.,
* Changing the methods supported by a resource, or their semantics (in the
case of POST)
* Changing the URI query parameters available to a resource
* Changing the range of formats that a res
On 12/10/2011, at 12:51 AM, Mark McLoughlin wrote:
>
> - Version numbers aren't necessarily the best way to advertise the
> availability of features - if we made clients query for the
> availability of the features they're using, you could version the
> features independently.
>
> For
On 12/10/2011, at 1:00 AM, Mark McLoughlin wrote:
>
> We're not attempting to enumerating all the valid ways that POST can be
> used, we're trying to narrow down those possibilities to a set of
> guidelines which describe the general style and idioms of OpenStack
> APIs.
Understood. I've been i
Hi All,
As it was discussed during the Design Summit, there was a desire to create a
Working Group for Nova Volume changes.
If you would like to participate, pls feel free to add yourself to:
https://launchpad.net/~openstack-volume
and/or its mailing list:
openstack-vol...@lists.launchpa
+3
On Oct 11, 2011, at 1:59 PM, Brian Waldon wrote:
> I would like to propose we remove our implementation of OSAPI v1.0 from Nova
> for the following reasons:
>
> 1) Our implementation is incomplete, and there are no (visible) plans to
> complete it. Shared IP Groups and Backup Schedules h
On Tue, 2011-10-11 at 16:59 -0400, Brian Waldon wrote:
> I would like to propose we remove our implementation of OSAPI v1.0
> from Nova for the following reasons:
[snip]
+1
--
Kevin L. Mitchell
This email may include confidential information. If you received it in error,
please delete it.
Hi, I'd like to request merge reviews on the following. These have been
outstanding since September 24.
https://review.openstack.org/#change,642 (Soren has +1'd)
https://review.openstack.org/#change,643
These are related to the Open vSwitch rules applied in a Xen domain 0, for
multi-tenant ne
> -Original Message-
> From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
> [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net]
> On Behalf Of Stefano Maffulli
> Sent: 11 October 2011 08:43
> To: Alexandre Haguiar
> Cc: openstack@lists.launchpad.net
> Subje
HTTP methods are well defined and the system should behave in accordance with
those definitions. Otherwise, even saying the word REST is a joke.
On Oct 11, 2011, at 9:10 PM, Caitlin Bestler wrote:
> George Reese wrote:
>
>> No, not at all.
>
>> The object is /servers/1234 regardless of the ver
On Oct 11, 2011, at 4:10 PM, Caitlin Bestler wrote:
> George Reese wrote:
>
>> No, not at all.
>
>> The object is /servers/1234 regardless of the versioning of the API.
> It's an object that exists
>> independent of your API and its version. A URI should represent a
> single, persistent referen
++
On Tue, Oct 11, 2011 at 2:46 PM, Josh Kearney wrote:
> ++
>
> On Tue, Oct 11, 2011 at 3:59 PM, Brian Waldon
> wrote:
>>
>> I would like to propose we remove our implementation of OSAPI v1.0 from
>> Nova for the following reasons:
>>
>> 1) Our implementation is incomplete, and there are no (vi
+1
On Tue, Oct 11, 2011 at 3:59 PM, Brian Waldon wrote:
> I would like to propose we remove our implementation of OSAPI v1.0 from
> Nova for the following reasons:
>
> 1) Our implementation is incomplete, and there are no (visible) plans to
> complete it. Shared IP Groups and Backup Schedules hav
+1
On Tue, Oct 11, 2011 at 6:01 PM, Trey Morris wrote:
> +1
> On Tue, Oct 11, 2011 at 3:59 PM, Brian Waldon
> wrote:
>>
>> I would like to propose we remove our implementation of OSAPI v1.0 from
>> Nova for the following reasons:
>>
>> 1) Our implementation is incomplete, and there are no (visib
++
On Tue, Oct 11, 2011 at 3:59 PM, Brian Waldon wrote:
> I would like to propose we remove our implementation of OSAPI v1.0 from
> Nova for the following reasons:
>
> 1) Our implementation is incomplete, and there are no (visible) plans to
> complete it. Shared IP Groups and Backup Schedules hav
On 10/11/2011 02:15 PM, Vishvananda Ishaya wrote:
> For some reason tables are getting created as default type. There is
> a migration in the history to convert tables to InnoDB, but anything
> created after that migration will go in as the default type. We can
> add another migration to conver
OK, I get it now :-)
http://en.wikipedia.org/wiki/The_Treachery_of_Images
-
Brian Schott, CTO
Nimbis Services, Inc.
brian.sch...@nimbisservices.com
ph: 443-274-6064 fx: 443-274-6060
On Oct 11, 2011, at 2:53 PM, Lorin Hochstein wrote:
> Ceci
I do not know from where that comes, but I would consider it a bug and
that there is no good reason in this context to be using MyISAM for any
purpose.
On 10/11/2011 01:55 PM, Nick Sokolov wrote:
> Hi stackers!
>
> I noticed, that tables in database use two database engines instead of
> two, but
I would like to propose we remove our implementation of OSAPI v1.0 from Nova
for the following reasons:
1) Our implementation is incomplete, and there are no (visible) plans to
complete it. Shared IP Groups and Backup Schedules have been unimplemented
since I started on the project.
2) The v1.
Hi everyone,
Last week at the conference in Boston we had a great session talking about
project governance and the creation of a foundation for OpenStack. One of the
to-do items out of the meeting was setting up some group communication methods
for ongoing discussion. The first piece is a maili
For some reason tables are getting created as default type. There is a
migration in the history to convert tables to InnoDB, but anything created
after that migration will go in as the default type. We can add another
migration to convert all of the other tables, but I think the right method h
Hi stackers!
I noticed, that tables in database use two database engines instead of two,
but model descriptions does not override __table_args__ = {'mysql_engine':
'InnoDB'}.
This is design decision or migration_repo bug, or something else?
mysql> select table_name, table_type, engine FROM inform
On Oct 11, 2011, at 1:53 PM, Lorin Hochstein wrote:
> Ceci n'est pas un pipe. ;)
Exactly!
-- Ed Leafe
This email may include confidential information. If you received it in error,
please delete it.
___
Mailing list: https://launchpad.net/~
Hi Stefano,
This event is an iniciative from some friends from SERPRO and CISL to
present a day with talks about private clouds with open software.
*Event date:* 19/10/2011
*Program*
1 - Connectivity Architecture for Cloud Computing Environments - Herlon
Fernandes - 9:00 to 10:00 - São Paulo
2 -
George Reese wrote:
> No, not at all.
> The object is /servers/1234 regardless of the versioning of the API.
It's an object that exists
> independent of your API and its version. A URI should represent a
single, persistent reference to that object.
> The version is really an attribute of the con
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As Jorge was pointing out last week
(https://lists.launchpad.net/openstack/msg04596.html), the problem seems
to be iptables related. When I added these two rules, I was able to ping
google.com with 10.0.1.1 as the nameserver.
# iptables -I nova-netwo
Putting the version in the URI is a "variant" resource just like adding
.xml or .json . If you want the ability to get to a specific
representation in a browser (as opposed to a custom client) you can't
rely on content negotiation because browsers hard code their accepts clause.
REST is media
++ Like the idea..yes I think we should aim to include all OpenStack APIs --
whatever that means :-)
-jOrGe W.
On Oct 11, 2011, at 9:52 AM, Jay Pipes wrote:
> On Tue, Oct 11, 2011 at 10:08 AM, Mark McLoughlin wrote:
>> On Tue, 2011-10-11 at 16:11 +1100, Mark Nottingham wrote:
>>> +1 (sorry for
Ceci n'est pas un pipe. ;)
--
Lorin Hochstein, Computer Scientist
USC Information Sciences Institute
703.812.3710
http://www.east.isi.edu/~lorin
On Oct 11, 2011, at 11:28 AM, George Reese wrote:
> It's wildly inappropriate to equate a thing with its representation.
>
> On Oct 11, 2011, at 4:06
That is one case that would require a major version change where a URI is still
valid. However, changes to the URI are still allowed across major versions.
That causes me to think content-types are not good enough to handle versioning.
On Oct 11, 2011, at 11:21 AM, Kiall Mac Innes wrote:
> Pret
hello folks,
a group of people interested in academia met in Boston during the
unconference. I was there to take notes and facilitate this community
run initiative. Here is what we agreed so far. I'm sharing it on the
list to gather more ideas.
/stef
OpenStack Academic Initiative
Mission:
Hi
We are planning to have regular meets/syncups for Donabe. Possible
timings include Wed 2pm PST (since 2pm seems to work for openstack
meets). Please unicast myself/Rick if you want to participate but this
time doesn't work for you ... and please suggest some alternatives. Will
do my best
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have noticed another weird issue with dnsmasq which might be related
to the problem.
# tail -1 /etc/nova/nova.conf
- --dnsmasq_config_file=/etc/dnsmasq.conf
#killall dnsmasq
# /etc/init.d/openstack-nova-network restart
Stopping OpenStack Nova Netw
Yes, my proposed solution requires OpenStack implementations to support ALL
major versions of ALL APIs. That's absolutely critical for building a healthy
ecosystem.
See EC2 for someone doing it damn well. I've never had to write new code to
talk to them unless I want to take advantage of new fu
It's wildly inappropriate to equate a thing with its representation.
On Oct 11, 2011, at 4:06 PM, Soren Hansen wrote:
> I see what you're saying. I guess I'm just used to equating a thing
> with its representation.
>
> --
> Soren Hansen| http://linux2go.dk/
> Ubuntu Developer| http:
Hello Alexandre
On Tue, 2011-10-11 at 08:42 -0300, Alexandre Haguiar wrote:
> We work at SERPRO (serpro.gov.br), a Brazilian government TI company
> and also in the CISL (Brazilian federal government committee for open
> source implementation). We are organizing an event on next 19 with a
> full d
Pretending we are talking about "User" resource for me, "kiall" for moment.
The v1 API might represent the kiall user resource as {"name":"kiall"} while
the v2 API might represent the kiall user resource as {"USERname":"kiall"}.
The kiall resource has not changed, only the API representation. Hen
I see what you're saying. I guess I'm just used to equating a thing
with its representation.
--
Soren Hansen | http://linux2go.dk/
Ubuntu Developer | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/
___
Mailing list: htt
Your proposed solution to my example implies we would have to support *all*
major versions of the compute API to some degree. I absolutely don't want to
track redirects from v1 to v2 to v3 to v4 when we are developing v5. That seems
like a painful thing to have to do. We also couldn't guarantee
On Tue, Oct 11, 2011 at 10:08 AM, Mark McLoughlin wrote:
> On Tue, 2011-10-11 at 16:11 +1100, Mark Nottingham wrote:
>> +1 (sorry for the lag, been travelling).
>>
>> I'd like to start two wiki pages; one collecting goals for the APIs,
>> one for collecting common patterns of use in the APIs (not
No, not at all.
The object is /servers/1234 regardless of the versioning of the API. It's an
object that exists independent of your API and its version. A URI should
represent a single, persistent reference to that object.
The version is really an attribute of the content type you are accepting
On Tue, 2011-10-11 at 16:40 +0200, Soren Hansen wrote:
> 2011/10/11 Mark McLoughlin :
> > I think the versioning rules below are fine, but there are some other
> > things to think about:
> >
> > - As others raised, what version (if any) should be in the URIs?
> >
> > We could put the full versio
Hey all,
Below, please find a summary of the decisions/actions that came out of
the design summit last week. Feedback and comments are most welcome.
1) Release Cycle
Glance will follow a similar cadence to Nova and Keystone during the
Essex release cycle, with the exception that Glance will rele
In the example you use, the proper HTTP behavior is for the API should allow
for a HTTP 302 response and clients should follow the permanent move. This
provides both a persistent reference based on the URI and a way to handle the
alteration of URI structure.
-George
On Oct 11, 2011, at 2:56 PM
On Tue, Oct 11, 2011 at 9:56 AM, Brian Waldon
wrote:
> I'm not sure I agree with that. A URI should be a persistent reference to a
> resource within the context of a major version of an API. Between major
> versions, the URI structure can change completely (for example /servers ->
> /instances)
I agree only the major version should be in the URL, and the major version
must be bumped if any API is changed such that the 'API contract' with existing
clients
is broken somehow. (Standard 'old manager/new agent' stuff.)
Traditionally, the software release version IDs need to be precise,
so w
2011/10/11 Mark McLoughlin :
> I think the versioning rules below are fine, but there are some other
> things to think about:
>
> - As others raised, what version (if any) should be in the URIs?
>
> We could put the full version number in the URIs so long as we
> maintain support for the older
Hi Mark,
On Tue, 2011-10-11 at 16:17 +1100, Mark Nottingham wrote:
> On 19/09/2011, at 4:03 PM, Mark McLoughlin wrote:
>
> > OTOH, POST to update the object's metadata doesn't make much sense. We
> > don't "accept the entity enclosed in the request as a new subordinate".
> > PATCH[1] would probab
On Tue, 2011-10-11 at 16:11 +1100, Mark Nottingham wrote:
> +1 (sorry for the lag, been travelling).
>
> I'd like to start two wiki pages; one collecting goals for the APIs,
> one for collecting common patterns of use in the APIs (not rules, not
> even guidelines).
Yeah, it'd be awesome to have t
Thanks for the feedback, Mark! Comments inline:
On Oct 11, 2011, at 9:51 AM, Mark McLoughlin wrote:
> Hi Brian,
>
> I think the versioning rules below are fine, but there are some other
> things to think about:
>
> - As others raised, what version (if any) should be in the URIs?
>
> We could
2011/10/11 George Reese :
> Versioning should not be included in the URI. It belongs in the headers. A
> URI should be a persistent reference to a resource. As such, versioning
> always breaks that persistent reference.
I don't follow. If the version is included in the URI, that's got to
be a mo
I'm not sure I agree with that. A URI should be a persistent reference to a
resource within the context of a major version of an API. Between major
versions, the URI structure can change completely (for example /servers ->
/instances), destroying your persistent reference.
Additionally, if we o
Just added slides for Orchestration and Advanced Scheduling to wiki.
(sparse etherpad URL's on title slides)
-Sandy
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf o
Hi,
We work at SERPRO (serpro.gov.br), a Brazilian government TI company and
also in the CISL (Brazilian federal government committee for open source
implementation). We are organizing an event on next 19 with a full day of
talks about free software and private clouds. We are seeking an Openstack
Hi Brian,
I think the versioning rules below are fine, but there are some other
things to think about:
- As others raised, what version (if any) should be in the URIs?
We could put the full version number in the URIs so long as we
maintain support for the older, compatible versions i.e. t
I filed this as a bug. We'll need to fix it so special characters get encoded
correctly: https://bugs.launchpad.net/keystone/+bug/872287
Thanks,
Ziad
From: DeadSun mailto:mwjpi...@gmail.com>>
Date: Tue, 11 Oct 2011 16:29:21 +0800
To: mailto:openstack@lists.launchpad.net>>
Subject: [Openstack] Ca
Hello everyone,
Our first post-design-summit meeting will take place at 21:00 UTC this
Tuesday in #openstack-meeting on IRC. PTLs, if you can't make it, please
name a substitute on [2].
We'll discuss the final Essex release schedule, get early status on the
Essex themes and blueprints for all cor
On Tue, Oct 11, 2011 at 1:11 AM, Mark Nottingham wrote:
> +1 (sorry for the lag, been travelling).
>
> I'd like to start two wiki pages; one collecting goals for the APIs, one for
> collecting common patterns of use in the APIs (not rules, not even
> guidelines).
>
> Maybe split each one into "p
On Tue, Oct 11, 2011 at 6:08 AM, Julien Danjou
wrote:
> Hi there,
>
> As far as I understand, each Glance app uses its own configuration file.
> However, it seems to me that it induces a couple of weird things.
>
> Today, I started taking a look on images cache and prefetch stuff, and
> bumping my
Versioning should not be included in the URI. It belongs in the headers. A URI
should be a persistent reference to a resource. As such, versioning always
breaks that persistent reference.
-George
On Oct 11, 2011, at 1:40 PM, Brian Waldon wrote:
> I'm all for exposing only the major version in
I'm all for exposing only the major version in the URI (/v1). We have fallen
into a trap with v1.0 and v1.1 as they are not backckwards-compatible specs
while their versioning implies they are. I think we can have a whole separate
discussion on how to solve that problem, so like I said earlier,
I have just installed nova/glance/keystone/dashboard on one controller and
compute/network nodes.
Images and instances are stored in local disk. I know the instances are (base
image + Copy-On-Write) files.
Which file should I backup that are enough to restore a instance in another
disk?
If m
Hi there,
As far as I understand, each Glance app uses its own configuration file.
However, it seems to me that it induces a couple of weird things.
Today, I started taking a look on images cache and prefetch stuff, and
bumping my head on the wall because something was not working.
Then I discove
I use a token ")", tht last char is ")", then when I logon dashboard
to instances or images or keypairs web. it occurs:
Unable to get instance list: 401 Unauthorized This server could not verify
that you are authorized to
access the document you requested. Either you supplied the wrong cre
70 matches
Mail list logo
