://review.openstack.org/#/c/257596/
[3]
-http://docs.openstack.org/developer/nova/process.html#how-do-i-get-my-code-merged
Regards,
SURO
irc//freenode: suro-patz
On 1/8/16 4:47 AM, John Garbutt wrote:
On 7 January 2016 at 18:49, SURO <suro.p...@gmail.com> wrote:
Hi all,
I have proposed a nov
Hi all,
I have proposed a nova-spec[1] for a new scheduling filter based on
metrics thresholds. This is slightly different than weighted metrics
filter. The rationale and use-case is explained in detail in the spec[1].
The implementation is also ready for review[2]. The effort is tracked
e_count=10']
[1] -
https://etherpad.openstack.org/p/liberty-work-magnum-horizontal-scale
(Line 33)
Regards,
SURO
irc//freenode: suro-patz
On 12/17/15 8:10 AM, Hongbin Lu wrote:
Suro,
FYI. In before, we tried a distributed lock implementation for bay operations
(here are the patches [1,2,3,4,5]
in OpenStack space is managed
through config - a change in which would require a restart of the
conductor. If the conductor is restarted, then the 'window of
inconsistency' does not occur for the situation we are discussing.
Regards,
SURO
irc//freenode: suro-patz
On 12/16/15 11:39 PM, Joshua
,
blocking call is made. But in the present scenario, it is not much of a
concern, as the container-operation execution is lighter on the client
side, and mostly block for the response from the server, after issuing
the request.
I will update the proposal with this change.
Regards,
SURO
irc//freenode
Please find the reply inline.
Regards,
SURO
irc//freenode: suro-patz
On 12/16/15 7:19 PM, Adrian Otto wrote:
On Dec 16, 2015, at 6:24 PM, Joshua Harlow <harlo...@fastmail.com> wrote:
SURO wrote:
Hi all,
Please review and provide feedback on the following design proposal for
implem
gin with, we will use 'threading.Thread'
instead of 'eventlet.greenthread'.
Refs:-
[1] -
https://blueprints.launchpad.net/magnum/+spec/async-container-operations
--
Regards,
SURO
irc//freenode: suro-patz
__
OpenSt
On 12/16/15 11:39 PM, Joshua Harlow wrote:
SURO wrote:
Please find the reply inline.
Regards,
SURO
irc//freenode: suro-patz
On 12/16/15 7:19 PM, Adrian Otto wrote:
On Dec 16, 2015, at 6:24 PM, Joshua Harlow <harlo...@fastmail.com>
wrote:
SURO wrote:
Hi all,
Please review and p
Josh,
Please find my reply inline.
Regards,
SURO
irc//freenode: suro-patz
On 12/16/15 6:37 PM, Joshua Harlow wrote:
SURO wrote:
Hi all,
Please review and provide feedback on the following design proposal for
implementing the blueprint[1] on async-container-operations -
1. Magnum-conductor
to submit a different bp/bug to address the
staleness of the state of pod/rc.
Regards,
SURO
irc//freenode: suro-patz
On 8/3/15 5:33 PM, Kai Qiang Wu wrote:
Hi Suro and Jay,
I checked discussion below, and I do believe we also need
service-list(for just magnum-api and magnum-conductor
nova, but nova really has
a bunch of backend services, viz. nova-conductor, nova-cert,
nova-scheduler, nova-consoleauth, nova-compute[x N], whereas magnum not.
For magnum, at this point creating 'service-list' only for api/conductor
- do you see a strong need?
Regards,
SURO
irc//freenode: suro
suggest we should keep the concept/abstraction at Magnum level, as it is.
Regards,
SURO
irc//freenode: suro-patz
On 7/28/15 7:59 PM, Jay Lau wrote:
Hi Suro,
Sorry for late. IMHO, even the magnum service-list is getting data
from DB, but the DB is actually persisting some data for Kubernetes
and driver implementation. I think it is too early to declare
service/rc/pod as specific to k8s, as the other COEs may very well
converge onto similar/same concepts.
Regards,
SURO
irc//freenode: suro-patz
On 7/29/15 2:21 PM, Hongbin Lu wrote:
Suro,
I think service/pod/rc are k8s-specific. +1
Hi all,
As we did not hear back further on the requirement of this blueprint, I
propose to keep the existing behavior without any modification.
We would like to explore the decision on this blueprint on our next
weekly IRC meeting[1].
Regards,
SURO
irc//freenode: suro-patz
[1] - https
/openstack/magnum/blob/master/magnum/objects/service.py#L114
--
Regards,
SURO
irc//freenode: suro-patz
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
15 matches
Mail list logo
