On 31 March 2014 18:53, John Garbutt wrote:
> Hi,
>
> I would like to run for the OpenStack Compute (Nova) PTL position.
>
> I find it really rewarding to help resolve conflict. Gallup says I am
> a: Learner, Arranger, Achiever, Relator, Includer. I like to listen to
> a
I think writing this up as a nova-spec is going to make this process
much easier:
https://wiki.openstack.org/wiki/Blueprints#Nova
It will save you having to re-write your document once you want to
submit a blueprint, and we can all see each others comments in gerrit,
and more clearly see how thing
Apologies, that came out all wrong...
On 10 April 2014 09:28, John Garbutt wrote:
> I think writing this up as a nova-spec is going to make this process
> much easier:
> https://wiki.openstack.org/wiki/Blueprints#Nova
>
> It will save you having to re-write your document o
Hi.
I would like to announce my TC candidacy.
I work full time as a Software Developer on OpenStack at Rackspace,
part of the team working on Rackspace Cloud Servers, Rackspace's
public cloud. I am a Nova core reviewer, a member of nova-drivers,
leader of the XenAPI Nova sub-team, and the Nova "b
Hi,
A big thank you to jogo who has done a great job writing up plans for
kilo blueprints and specs:
1) Allow more code that doesn't need a blueprint and spec:
https://review.openstack.org/#/c/116699/3
Specs are a heavy process, so hopefully this will strike a better
balance between process and
On 25 September 2014 11:44, Daniel P. Berrange wrote:
> To use the runway system, we need to have a frequently updated list
> of blueprints which are a priority to review / merge. Once we have
> such a list, IMHO, adding the fixed runway slots around that does
> not do anything positive for me as
On 25 September 2014 14:10, Daniel P. Berrange wrote:
>> The proposal is to keep kilo-1, kilo-2 much the same as juno. Except,
>> we work harder on getting people to buy into the priorities that are
>> set, and actively provoke more debate on their "correctness", and we
>> reduce the bar for what
On 27 September 2014 00:31, Joe Gordon wrote:
> On Thu, Sep 25, 2014 at 9:21 AM, John Garbutt wrote:
>> On 25 September 2014 14:10, Daniel P. Berrange
>> wrote:
>> >> The proposal is to keep kilo-1, kilo-2 much the same as juno. Except,
>> >> we work h
ng a single +2 for re-approval if there are no major changes to
>> them.
>>
>>>
>>>
>>> Otherwise we'll end up wasting weeks of development time just when
>>> there is lots of review bandwidth available and the CI system is
>>> lightl
On 30 September 2014 14:04, joehuang wrote:
> Hello, Dear TC and all,
>
> Large cloud operators prefer to deploy multiple OpenStack instances(as
> different zones), rather than a single monolithic OpenStack instance because
> of these reasons:
>
> 1) Multiple data centers distributed geographica
Hi,
I would like to run for a seat on the Technical Committee, to help
serve the whole OpenStack community during this time of change.
I am employed by Rackspace, working on their public cloud. I am
currently focus mostly on Nova. I am nova-core, and currently nova's
blueprint czar. I am johnthet
On 17 October 2014 02:28, Matt Riedemann wrote:
>
>
> On 10/16/2014 7:26 PM, Christopher Aedo wrote:
>>
>> On Tue, Sep 9, 2014 at 2:19 PM, Mike Scherbakov
>> wrote:
On Tue, Sep 9, 2014 at 6:02 PM, Clint Byrum wrote:
>>>
>>> The idea is not simply deny or hang requests from clients, but
> On 11/11/2014 3:04 PM, Andrew Laski wrote:
>>
>> We had a great discussion on cells at the summit which is captured at
>> https://etherpad.openstack.org/p/kilo-nova-cells. One of the tasks we
>> agreed upon there was to form a subgroup to co-ordinate this effort
>> and
>>
On 18 June 2014 21:57, Jay Pipes wrote:
> On 06/17/2014 05:42 PM, Daniel P. Berrange wrote:
>>
>> On Tue, Jun 17, 2014 at 04:32:36PM +0100, Pádraig Brady wrote:
>>>
>>> On 06/13/2014 02:22 PM, Day, Phil wrote:
I guess the question I’m really asking here is: “Since we know resize
do
So just to keep the ML up with some of the discussion we had in IRC
the other day...
Most resources in Nova are owned by a particular nova-compute. So the
locks on the resources are effectively held by the nova-compute that
owns the resource.
We already effectively have a cross nova-compute "lock
Seems like we all agree on the basic idea here, which is great.
I think just not concentrating on nova-spec reviews is fine, at least,
it is the simplest way to implement the freeze (as Russell pointed
out).
I so worry about setting the right expectations for the poor souls
who's specs might stic
As previously (quietly) announced, today we are trying to do a push on
nova-specs reviews.
https://review.openstack.org/#/q/status:open+project:openstack/nova-specs,n,z
The hope is we get through some of the backlog, with some interactive
chat on IRC in #openstack-nova
If someone has better stat
On 24 June 2014 16:40, Jay Pipes wrote:
> On 06/24/2014 07:32 AM, Daniel P. Berrange wrote:
>>
>> On Tue, Jun 24, 2014 at 10:55:41AM +, Day, Phil wrote:
>>>>
>>>> -----Original Message-
>>>> From: John Garbutt [mailto:j...@johngarbutt.co
Thanks all, I think we made a real dent in the review queue yesterday.
On 25 June 2014 22:58, Russell Bryant wrote:
> The majority of specs are waiting on an update from the submitter. I
> didn't grab these stats before today, but I believe we made some good
> progress.
> Using: $ openreviews -u
Hi,
As announced:
http://lists.openstack.org/pipermail/openstack-dev/2014-June/038475.html
The nova-specs dates:
* all juno nova-specs ready for review by the end of today, 3rd July
(in local time for you)
* all blueprints we can take for juno (yes juno-2 and juno-3) approved
by 10th July
We wil
On 10 July 2014 16:59, Sylvain Bauza wrote:
> Le 10/07/2014 15:47, Russell Bryant a écrit :
>> On 07/10/2014 05:06 AM, Sylvain Bauza wrote:
>>> Hi all,
>>>
>>> ===
>>> tl;dr: Now that we agree on waiting for the split prereqs to be done, we
>>> debate on if ResourceTracker should be part of the sc
On 10 July 2014 16:52, Matthew Booth wrote:
> Currently we create a rescue instance by creating a new VM with the
> original instance's image, then adding the original instance's first
> disk to it, and booting. This means we have 2 VMs, which we need to be
> careful of when cleaning up. Also when
On 12 July 2014 05:07, Jay Pipes wrote:
> On 07/11/2014 07:14 AM, John Garbutt wrote:
>> While I am not against moving the resource tracker, I feel we could
>> move this to Gantt after the core scheduling has been moved.
>
> Big -1 from me on this, John.
>
> Frankly,
Hi all,
Some friendly reminders from your Blueprint Czar...
Juno-2 is just over a week away:
https://launchpad.net/nova/+milestone/juno-2
I have moved most blueprints that don't have all their code ready to
be reviewed to Juno-3. Reviewers, if something is really not going to
make it for Juno-2
On 16 July 2014 14:07, Thierry Carrez wrote:
> Daniel P. Berrange wrote:
>> On Wed, Jul 16, 2014 at 11:57:33AM +, Tim Bell wrote:
>>> It seems a pity to archive the comments and reviewer lists along
>>> with losing a place to continue the discussions even if we are not
>>> expecting to see cod
On 19 July 2014 03:53, Johannes Erdfelt wrote:
> I'm requestion a spec freeze exception for online schema changes.
>
> https://review.openstack.org/102545
>
> This work is being done to try to minimize the downtime as part of
> upgrades. Database migrations have historically been a source of long
On 19 July 2014 00:56, Alessandro Pilotti
wrote:
> Hi everyone,
>
> I’d like to propose the following driver feature parity blueprint spec for an
> expection:
>
> https://review.openstack.org/#/c/105042
>
> This blueprint introduces rescue instance support in the Nova Hyper-V
> driver for feature
On 18 July 2014 09:10, Sylvain Bauza wrote:
> Hi team,
>
> I would like to put your attention on https://review.openstack.org/89893
> This spec targets to isolate access within the filters to only Scheduler
> bits. This one is a prerequisite for a possible split of the scheduler
> into a separate
On 18 July 2014 14:28, Andrew Laski wrote:
> Hello everybody,
>
> I would like to request a spec proposal extension for instance tasks,
> described in https://review.openstack.org/#/c/86938/ . This has been a long
> discussed and awaited feature with a lot of support from the community.
>
> This
OK, I think this is important as well, so thats 2-3 cores signed up.
Lets assume the exception is granted I guess, or at least, lets clear
it up in the nova-meeting.
Thanks,
John
On 24 July 2014 14:20, Day, Phil wrote:
> According to: https://etherpad.openstack.org/p/nova-juno-spec-priorities
On 6 August 2014 18:54, Jay Pipes wrote:
> So, Liyi Meng has an interesting patch up for Nova:
>
> https://review.openstack.org/#/c/104876
>
> 1) We should just deprecate both the options, with a note in the option help
> text that these options are not used when volume size is not 0, and that the
Exposing the detailed info in private cloud, sure makes sense. For
public clouds, not so sure. Would be nice to find something that works
for both.
We let the user express their intent through the instance groups api.
The scheduler will then do a best effort to meet that criteria, using
its privat
Hi,
There is some information in the EC2 metadata, or at least I have a
patch up for that:
https://review.openstack.org/#/c/46286/
I am raising some ideas to improve things here:
http://summit.openstack.org/cfp/details/191
John
On 15 October 2013 08:24, Vijay Venkatachalam
wrote:
> Hi,
>
>
Is there a reason why you could not just use a Cinder Volume for your
data, in this case?
While at a first glance, it feels rather wrong, and un-cloudy, I do
see something useful about refreshing the base disk, and leaving the
data disks alone. Prehaps it's something that could be described in
the
On 25 October 2013 11:52, Nikola Đipanov wrote:
> On 23/10/13 17:33, Russell Bryant wrote:
>> 4) Blueprint Prioritization
>> I would like to do a better job of using priorities in Icehouse. The
>> priority field services a couple of purposes:
>>
>> - helps reviewers prioritize their time
>>
>>
On 25 October 2013 10:18, Joe Gordon wrote:
> On Oct 24, 2013 9:14 PM, "Robert Collins" wrote:
>> On 24 October 2013 04:33, Russell Bryant wrote:
>> > Greetings,
>> >
>> > At the last Nova meeting we started talking about some updates to the
>> > Nova blueprint process for the Icehouse cycle. I
On 28 October 2013 15:39, Anne Gentle wrote:
> On Mon, Oct 28, 2013 at 9:24 AM, John Garbutt wrote:
>> Here is a really bad attempt at codifying what I think about features vs
>> bugs:
>> 1) If its a new API call, or a change in behaviour, or a new config
>> setting,
> John Garbutt wrote:
>> On 25 October 2013 11:52, Nikola Đipanov wrote:
>>> I don't have the numbers but I have a feeling that what happened in
>>> Havana was that a lot of blueprints slipped until the time for feature
>>> freeze. Reviewers thought it wa
On 29 October 2013 10:20, Robert Collins wrote:
> On 29 October 2013 23:06, Day, Phil wrote:
>> Hi Rob,
>>
>> I think it looks like a good option - but I'd like to see it exposed as
>> such to the user rather than a change in the default behavior as such. I.e.
>> "rebuild --keep-ephemenral=Tr
I would love to see a symmetry between Cinder local volumes and
Neutron PCI passthrough VIFs.
Not entirely sure I have that clear in my head right now, but I just
wanted to share the idea:
* describe resource external to nova that is attached to VM in the API
(block device mapping and/or vif refer
On 29 October 2013 06:46, Yathiraj Udupi (yudupi) wrote:
> The Instance Group API document is now updated with a simple example request
> payload of a nested group, and some description of how the API
> implementation should handle the registration of the components of a nested
> instance group.
>
On 28 October 2013 23:40, Christopher Yeoh wrote:
> On Tue, Oct 29, 2013 at 7:22 AM, David Kranz wrote:
>>
>> As I looked at the havana release notes that talk about the v3 api, and as
>> I was reviewing
>> "port test_images and test_server_actions into v3 part2"
>> https://review.openstack.org/#
On 25 October 2013 23:23, Chris Behrens wrote:
> On Oct 25, 2013, at 3:46 AM, "Day, Phil" wrote:
>> Hi Folks,
>>
>> We're very occasionally seeing problems where a thread processing a create
>> hangs (and we've seen when taking to Cinder and Glance). Whilst those
>> issues need to be hunted do
Going back to Joe's comment:
> Can both of these cases be covered by configuring the keystone catalog?
+1
If both v1 and v2 are present, pick v2, otherwise just pick what is in
the catalogue. That seems cool. Not quite sure how the multiple glance
endpoints works in the keystone catalog, but shoul
On 29 October 2013 11:56, haruka tanizawa wrote:
> Hi Joe!
>
> Thank you for your help.
> I wrote BP
> https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token again.
> Could you review it when you have time.
>
>
>>>
>>> I like the idea but two comments:
>>>
>>> * Can you fill out the
Its intentional. Cells is there to split up your nodes into more
manageable chunks.
There are quite a few design summit sessions on looking into
alternative approaches to our current scheduler.
While I would love a single scheduler to make everyone happy, I am
thinking we might end up with severa
On 31 October 2013 16:57, Johannes Erdfelt wrote:
> On Thu, Oct 31, 2013, Sean Dague wrote:
>> So there is a series of patches starting with -
>> https://review.openstack.org/#/c/53417/ that go back and radically
>> change existing migration files.
I initially agreed with the -2, but actually I
On 29 October 2013 16:11, Eddie Sheffield wrote:
>
> "John Garbutt" said:
>
>> Going back to Joe's comment:
>>> Can both of these cases be covered by configuring the keystone catalog?
>> +1
>>
>> If both v1 and v2 are present, pick v2, ot
On 30 October 2013 01:51, haruka tanizawa wrote:
> Hi John!
>
> Thank you for your reply:)
> Sorry for inline comment.
>
>
>> We also need something that doesn't clash with the cross-service
>> request id, as that is doing something slightly different. Would
>> "idempotent-request-id" work better?
On 29 October 2013 20:18, Mike Spreitzer wrote:
> John Garbutt wrote on 10/29/2013 07:29:19 AM:
>> ...
>
>> Its looking good, but I was thinking about a slightly different approach:
>>
>> * I would like to see instance groups be used to describe all
>> sched
I like the idea of a more general config validation phase to help
people when first starting out.
My worry is that it would slow down the starting back up of servers
for people deploying their code using CI, where the have already
verified their configuration. But maybe its so fast I don't care, b
On 11 November 2013 10:27, Rosa, Andrea (HP Cloud Services)
wrote:
> Hi
>
>>Generally mock is supposed to be used over mox now for python 3 support.
>
> That is my understanding too
+1
But I don't think we should waste all our time re-writing all our mox
and stub tests. Lets just leave this to h
It seems we still agreed that terminate should be able to happen at any time.
I thought I remembered some code in the manager that treats
InstanceNotFound errors differently.
I would rather we ensure InstanceNotFound is raised to indicate we
have hit this race condition, and let the compute manag
On 11 November 2013 23:18, Mark McLoughlin wrote:
> On Mon, 2013-11-11 at 12:07 +0000, John Garbutt wrote:
>> On 11 November 2013 10:27, Rosa, Andrea (HP Cloud Services)
>> wrote:
>> > Hi
>> >
>> >>Generally mock is supposed to be used over mox n
On 11 November 2013 22:12, Joe Gordon wrote:
> On Nov 11, 2013 9:53 AM, "Russell Bryant" wrote:
>> On 11/11/2013 07:38 AM, Nikola Đipanov wrote:
>> > On 11/11/13 12:55, John Garbutt wrote:
>> >> I like the idea of a more general config validation phase
On 11 November 2013 12:04, Alexander Kuznetsov wrote:
> Hi all,
>
> While studying Hadoop performance in a virtual environment, I found an
> interesting problem with Nova scheduling. In OpenStack cluster, we have
> overcommit policy, allowing to put on one compute more vms than resources
> availab
Hi,
I am attempting to extract the consensus we reached in all the design
summit sessions here:
https://etherpad.openstack.org/p/IcehouseNovaSummit
Help to verify that I have not miss-represented things would be very
gratefully received.
John
___
Open
Hi,
A quick note to say we will have our regular subteam meeting today, as normal:
http://wiki.openstack.org/Meetings/XenAPI
The plan is go through the next steps after the summit:
https://etherpad.openstack.org/p/IcehouseXenAPIRoadmap
Thanks,
John
__
On 13 November 2013 23:22, Andrew Laski wrote:
> On 11/13/13 at 11:12pm, Jiang, Yunhong wrote:
>>
>> Hi, Dan Smith and all,
>> I noticed followed statement in 'Icehouse tasks' in
>> https://etherpad.openstack.org/p/IcehouseNovaExtensibleSchedulerMetrics
>>
>> convert resour
On 13 November 2013 14:51, Khanh-Toan Tran
wrote:
> Well, I don't know what John means by "modify the over-commit calculation in
> the scheduler", so I cannot comment.
I was talking about this code:
https://github.com/openstack/nova/blob/master/nova/scheduler/filters/core_filter.py#L64
But I am
Hi,
I have had some discussions about if I should add a config flag in this change:
https://review.openstack.org/#/c/32760/
I am looking to support adding a large amount of ephemeral disk space
to a VM, but the VHD format has a limit of around 2TB per disk. To
work around this in XenServer, I pla
We spoke about some nice validation frameworks at the summit, and here
and there.
Could we get away with XML->JSON then validate the JSON request (and
assume XML parse error also means bad request)?
John
On 20 June 2013 17:44, Russell Bryant wrote:
> On 06/20/2013 12:00 PM, Thierry Carrez wrote
or, rather than a config value.
John
On 20 June 2013 18:21, Russell Bryant wrote:
> On 06/20/2013 01:02 PM, John Garbutt wrote:
>> Hi,
>>
>> I have had some discussions about if I should add a config flag in this
>> change:
>> https://review.openstack.org/#/c/32
+1 for a world class JSON API, tooling and docs.
I was +1 for a cheap XML API, but maybe that will make those who want
XML even more unhappy?
John
On 20 June 2013 21:57, Kevin L. Mitchell wrote:
> On Thu, 2013-06-20 at 16:02 -0400, Sean Dague wrote:
>> There are lots of nice things we could do,
So in the current review, I have just gone for switching between
2000GB and 1024 GB.
I figure we can try this simpler approach, and worry about
generalizing it if people need it later.
John
On 24 June 2013 16:13, Russell Bryant wrote:
> On 06/21/2013 05:55 AM, John Garbutt wrote:
>>
Don't like dragging up old threads, but I spoke to Navneet on IRC, and
I missed this thread first time.
The Disk_Config setting is used by XenAPI to decide when it should
resize the server's partition and filesystem, but nova currently only
does this root disks that have a single partition where t
+1 for this being in Nova.
Who holds the trigger for removing a shelved instance from the
hypervisor may eventually be in the hands of an uber-conductor outside
of Nova, but clearly will still need all this plumbing in Nova to make
the feature work. We probably need an admin API to trigger the
off
I haven't seen any plans to change this.
The way I see it, the states make most sense for resize, which is the
end-user facing operation.
Personally I see migrate as a more admin focused operation.
So to help simplify the code, I am OK with slightly confusing states
for those users.
The exception
states too.
John
On 28 June 2013 09:18, guohliu wrote:
> On 06/27/2013 07:05 PM, John Garbutt wrote:
>>
>> I haven't seen any plans to change this.
>>
>> The way I see it, the states make most sense for resize, which is the
>> end-user facing operation.
>>
Interesting, thanks for trying that. I think this is the time people
"feel" the most.
It should help set expectations on how long it will take to get your
change into trunk. It seems, on average, to take two weeks.
Hopefully it is useful to spot reviews that are proving tricky to get
in, and they
On 1 July 2013 15:49, Andrew Laski wrote:
> On 07/01/13 at 11:23am, Mauro S M Rodrigues wrote:
>> One more though, about os-multiple-create: I was also thinking to remove
>> it, I don't see any real advantage to use it since it doesn't offer any kind
>> of flexibility like chose different flavors,
The confirm will happen automatically, after a period of time.
Maybe 0 is a valid option there, I can't remember.
John
On 1 July 2013 03:18, guohliu wrote:
> On 06/28/2013 05:58 PM, John Garbutt wrote:
>>
>> I am not sure its worth the extra calls.
>>
>> Hopeful
This seems a fair way of doing it.
Gives users and developers a fair warning.
If its not tested, because we will keep breaking it by accident, and
thats not fair on anyone, so those drivers shouldn't be in the main
tree
I wonder if we should requiring a certain level of testing or unit testing?
L
On 22 July 2013 13:23, Boris Pavlovic wrote:
> I see only one race condition. (in current solution we have the same
> situtaiton)
> Between request to compute node and data is updated in DB, we could use
> wrong state of compute node.
> By the way it is fixed by retry.
This race turns out to be a
> Joe Gordon wrote:
> time python -c "print 'test'"
Is this a fair test, because I assume we don't need to compile
rootwrap each time?
Having said that, I believe you that there is overhead in starting python.
>>> Mike Wilson wrote:
In my opinion:
1. Stop using rootwrap completely
Given we seem to be leaning towards WSME:
http://lists.openstack.org/pipermail/openstack-dev/2013-August/012954.html
Could we not try to make WSME give us the documentation we need?
Not sure if its feasible, but it seems like there is a good start to
that already available:
https://wsme.readthedo
On 3 August 2013 03:07, Christopher Yeoh wrote:
> Some people had concerns about exposing the glance api publicly and so
> wanted to retain the images support in Nova.
> So the consensus seemed to be to leave the images support in, but to demote
> it from core. So people who don't want it exclude
Hi Anne,
On 5 August 2013 15:15, Anne Gentle wrote:
> On Mon, Aug 5, 2013 at 8:55 AM, John Garbutt wrote:
>>
>> Given we seem to be leaning towards WSME:
>> http://lists.openstack.org/pipermail/openstack-dev/2013-August/012954.html
>>
>> Could we not try to ma
multi-nic added an extra virtual interface on a seprate network, like
adding a port:
http://docs.openstack.org/trunk/openstack-compute/admin/content/using-multi-nics.html
I think we need to keep a nova-network focused api extension, and a
separate neutron focused api extension, because we have not
I have been looking at ConfigDrive and wondering if we should update it.
ConfigDrive is only really useful if you can't/don't use DHCP.
I have thought about a (slightly messy) alternative:
* use ConfigDrive only for basic networking config on the first nic
(i.e. just enough to get to the metadata
+1 to Russell's proposal. I came to similar conclusions when looking
at snapshots for the XenAPI NFS driver (seems similar to the qemu NFS
option, except uses VHD not qcow2).
I wondered about, but discarded, the idea about a new cinder-compute
worker on each compute node for all volume operations
On 6 August 2013 23:06, Ian McLeod wrote:
> The proof of concept approach is limited to full-virt hypervisors. It's
> unclear to me if there's a way we can make this work for Xen-backed
> installs without the kind of lower level access to the virt environment
> that we'll get if we exist inside o
I guess this is the same issue we faced with the capabilities filters
and things, when drivers don't report stats in a consistent format.
If we dictate the driver reports things in a standard format, it will
make our lives much easier, I think.
Currently, some report their own format, and a few (
+1 I meant to raise that myself when I saw some changes there the other day.
On 4 September 2013 15:52, Thierry Carrez wrote:
> Russell Bryant wrote:
>> On 09/04/2013 10:26 AM, Dan Smith wrote:
>>> Hi all,
>>>
>>> As someone who has felt about as much pain as possible from the
>>> dual-maintenanc
To me this sounds like extra docs and bugs, which is exactly what we
need to tidy up before RC.
So I think this should be given an exception.
John
On 6 September 2013 01:31, Christopher Yeoh wrote:
> Hi,
>
> I'd just like to clarify whether adding api samples for the V3 API
> is considered a fe
On 22 October 2015 at 10:20, Nikola Đipanov wrote:
> On 10/21/2015 10:17 PM, Joshua Harlow wrote:
>> Question on some things seen in the below paste.
>>
>> What is with 'finished' -> 'reverted' and 'finished' -> 'confirmed'?
>>
>> Why does it jump over 'reverting' or 'confirming'? Should it?
>>
>>
On 19 October 2015 at 12:14, John Garbutt wrote:
> Hi,
>
> Due to the summit, we decided the next meeting will be:
> November 4th 2015 2100 UTC, #openstack-meeting
> http://www.timeanddate.com/worldclock/fixedtime.html?iso=20151104T21
>
> For more details, as usual
On 31 October 2015 at 23:06, Armando M. wrote:
> On 30 October 2015 at 23:59, Matt Riedemann
> wrote:
>> On 10/30/2015 7:41 AM, Armando M. wrote:
>>> On 30 October 2015 at 18:41, Francesco Santoro
>>> mailto:francesco.sant...@6wind.com>> wrote:
>>> Hi Armando,
>>> thanks for you answer.
>
In terms of adding this into master, we can go for a spec-less
blueprint in Nova.
Reach out to me on IRC if I can help you through the process.
Thanks,
johnthetubaguy
PS
We are working on making this easier in the future, by using OS VIF Lib.
On 4 November 2015 at 08:56, Michał Dubiel wrote:
>
On 4 November 2015 at 14:49, Jay Pipes wrote:
> On 11/04/2015 09:32 AM, Sean Dague wrote:
>>
>> On 11/04/2015 09:00 AM, Jay Pipes wrote:
>>>
>>> On 11/03/2015 05:20 PM, Boris Pavlovic wrote:
Hi stackers,
Usually such projects like Heat, Tempest, Rally, Scalar, and other tool
>>
On 4 November 2015 at 15:00, Sean Dague wrote:
> On 11/04/2015 09:49 AM, Jay Pipes wrote:
>> On 11/04/2015 09:32 AM, Sean Dague wrote:
>>> On 11/04/2015 09:00 AM, Jay Pipes wrote:
On 11/03/2015 05:20 PM, Boris Pavlovic wrote:
> Hi stackers,
>
> Usually such projects like Heat, Tem
On 5 November 2015 at 09:46, Richard Jones wrote:
> As a consumer of such APIs on the Horizon side, I'm all for consistency in
> pagination, and more of it, so yes please!
>
> On 5 November 2015 at 13:24, Tony Breeds wrote:
>>
>> On Thu, Nov 05, 2015 at 01:09:36PM +1100, Tony Breeds wrote:
>> > H
Hi,
Here is a catch up on a few release details...
For Nova specific deadlines and dates, please see:
https://wiki.openstack.org/wiki/Nova/Mitaka_Release_Schedule
Please note:
Dec 3: spec and blueprint freeze
Jan 21: non-priority feature freeze
The list of Mitaka priorities can be found here:
h
On 6 November 2015 at 09:49, Daniel P. Berrange wrote:
> On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote:
>> Hello all,
>> I came across [1] which is notionally an ironic bug in that horizon
>> presents
>> VM operations (like suspend) to users. Clearly these options don't make
>
On 6 November 2015 at 12:09, Sean Dague wrote:
> On 11/06/2015 04:49 AM, Daniel P. Berrange wrote:
>> On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote:
>>> Hello all,
>>> I came across [1] which is notionally an ironic bug in that horizon
>>> presents
>>> VM operations (like suspen
On 6 November 2015 at 12:11, Sean Dague wrote:
> On 11/06/2015 04:13 AM, Salvatore Orlando wrote:
>> It makes sense to have a single point were response pagination is made
>> in API processing, rather than scattering pagination across Nova REST
>> controllers; unfortunately if I am not really able
On 5 November 2015 at 19:31, Rafael Folco wrote:
> Is there any way to know what hypervisor features[1] were tested in a
> Tempest run?
> From what I’ve seen, currently there is no way to tell what tests cover what
> features.
> Looks like Tempest has UUID and service tagging, but no reference to
On 6 November 2015 at 03:31, Alex Xu wrote:
> Hi, folks
>
> Nova API sub-team is working on the swagger generation. And there is PoC
> https://review.openstack.org/233446
>
> But before we are going to next step, I really hope we can get agreement
> with how to support Microversions and Actions. T
On 6 November 2015 at 13:38, Markus Zoeller wrote:
> Jeremy Stanley wrote on 11/05/2015 07:11:37 PM:
>
>> From: Jeremy Stanley
>> To: "OpenStack Development Mailing List (not for usage questions)"
>>
>> Date: 11/05/2015 07:17 PM
>> Subject: Re: [openstack-dev] [all][bugs] Developers Guide: Who'
On 6 November 2015 at 14:09, Sean Dague wrote:
> On 11/06/2015 08:44 AM, Alex Xu wrote:
>>
>>
>> 2015-11-06 20:59 GMT+08:00 Sean Dague > <mailto:s...@dague.net>>:
>>
>> On 11/06/2015 07:28 AM, John Garbutt wrote:
>> > On 6 November
101 - 200 of 486 matches
Mail list logo
