On 28/05/14 14:52, Sean Dague wrote:
I would agree this doesn't make sense in Neutron.
I do wonder if it makes sense in the Network program. I'm getting
suspicious of the programs for projects model if every new project
incubating in seems to need a new program. Which isn't really a
reflection o
> for juno we should just have a v1 api (there can still be a v1.1 endpoint,
> but it should be deprecated), and maybe a v2 api
>
> +1 any semantic changes require new major version number
>
> +1 api should only have a major number (no 1.1 or 2.1)
>
In this case we will end up with new major numbe
On Wed, May 28, 2014 at 1:52 PM, Sean Dague wrote:
> I would agree this doesn't make sense in Neutron.
>
> I do wonder if it makes sense in the Network program. I'm getting
> suspicious of the programs for projects model if every new project
> incubating in seems to need a new program. Which isn't
Hi Doug,
Thanks for the response! I agree with you in the cases where we are extending
things like panels; if you're extending those, you're extending the dashboard
itself. However, things such as workflows feel like they could reasonably live
independently of the dashboard for re-use elsewhere.
On 05/28/2014 03:50 PM, Andrew Lazarev wrote:
for juno we should just have a v1 api (there can still be a v1.1
endpoint, but it should be deprecated), and maybe a v2 api
+1 any semantic changes require new major version number
+1 api should only have a major number (no 1.1 or 2
It's sort of a silly point, but as someone who would likely consume the
split-off package outside of the OpenStack context, please give it a proper
name instead of "django_horizon". The module only works in Django, the name
adds both clutter and confusion, and it's against the Django community's
+1
This makes sense except that I'm not sure what the "Network Program"
is. Is there already such a thing formally?
Carl
On Wed, May 28, 2014 at 12:52 PM, Sean Dague wrote:
> I would agree this doesn't make sense in Neutron.
>
> I do wonder if it makes sense in the Network program. I'm getting
I'm not sure what the exact requirements are for this, but there is a spec
review under way for external attachment points into neutron networks.
It covers integration with ironic as well as other baremetal devices.
https://review.openstack.org/#/c/87825/
--
Kevin Benton
Ryota,
Thanks for your i
smime.p7m
Description: S/MIME encrypted message
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
We'll meet tomorrow at the regular time in #openstack-meeting-3.
Juno-1 is just two weeks away. We will discuss the distributed
virtual router (DVR) work to see what the community can do to help the
DVR team land the hard work that they've been doing. We'll move
quickly through the non-DVR topic
Sorry - not sure what happened there - as I was saying:
The "Networking Program" is Neutron.
https://wiki.openstack.org/wiki/Programs
Graham
On 28/05/2014 21:29, "Hayes, Graham" wrote:
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openst
Hi folks
OK, so it looks like this is consensus in the community,
Link bug or bp for most of commit
Exception for not linking bug:
(1) Infra sync
(2) minor fix. (typo, small code refactor, fix doc string etc)
> Ihar, Assaf
Sorry for taking time for this discussion, I'll remove my comment for
Hi All,
There is a lot of tags in the subject of this e-mail but believe me that
all listed projects (and even more) are relevant for the designs which I
am sending out.
Nodes management section in Horizon is being expected for a while and
finally I am sharing the results of designing around
That is what I was not sure about, if they are currently one in the same.
Thanks for the link.
Carl
On May 28, 2014 2:47 PM, "Hayes, Graham" wrote:
> Sorry - not sure what happened there - as I was saying:
>
> The "Networking Program" is Neutron.
>
> https://wiki.openstack.org/wiki/Programs
>
>
Hmm yes. Maybe the common base instances table could even be part of the
extensible stuff in Horizon
Sent from my iPhone
> On May 28, 2014, at 2:53 PM, Tzu-Mainn Chen wrote:
>
> Hi Doug,
>
> Thanks for the response! I agree with you in the cases where we are extending
> things like panels;
Hi,
I have two questions that previously were briefly discussed. Both of them
still cause discussions within advanced services community, so I'd like to
make final clarification in this email thread.
1. Usage of "Service Type Framework"
I think right now there is a consensus that letting user to
Hi Brandon!
Please see inline..
On Wed, May 28, 2014 at 12:01 PM, Brandon Logan wrote:
> Hi Vijay,
>
> On Tue, 2014-05-27 at 16:27 -0700, Vijay B wrote:
> > Hi Brandon,
> >
> >
> > The current reviews of the schema itself are absolutely valid and
> > necessary, and must go on. However, the p
On Thu, May 29, 2014 at 4:22 AM, Sean Dague wrote:
> I would agree this doesn't make sense in Neutron.
>
> I do wonder if it makes sense in the Network program. I'm getting
> suspicious of the programs for projects model if every new project
> incubating in seems to need a new program. Which isn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 28/05/14 12:04, Steve Martinelli wrote:
> Hey Angus,
>
> If I understand the scenario correctly, I think you might run into the same
> problem with OAuth Access Tokens.
>
> >> We currently use a trust token and that fails because both mistral an
Hi folks,
Let's keep our regular meetings on Thursday, 14-00 UTC
The agenda for the meeting:
https://wiki.openstack.org/wiki/Network/LBaaS#Agenda
Sorry for the short notice, I'm still catching up with everything.
Thanks,
Eugene.
___
OpenStack-dev maili
Devananda van der Veen writes:
> Hi all!
>
> This is a follow-up to several summit discussions on
> how-do-we-deprecate-baremetal, a summary of the plan forward, a call to
> raise awareness of the project's status, and hopefully gain some interest
> from folks on nova-core to help with spec and c
Hi Zang
Since, SSL-VPN for Juno bp is approved in neturon-spec,
I would like to restart this work.
Could you share your code if it is possible?
Also, Let's discuss how we can collaborate in here.
Best
Nachi
2014-05-01 14:40 GMT-07:00 Nachi Ueno :
> Hi folks
>
>> Clint
> Thanks, things get clear
Sean Dague writes:
> I would agree this doesn't make sense in Neutron.
>
> I do wonder if it makes sense in the Network program. I'm getting
> suspicious of the programs for projects model if every new project
> incubating in seems to need a new program. Which isn't really a
> reflection on desig
On 05/28/2014 07:11 PM, James E. Blair wrote:
> Sean Dague writes:
>
>> I would agree this doesn't make sense in Neutron.
>>
>> I do wonder if it makes sense in the Network program. I'm getting
>> suspicious of the programs for projects model if every new project
>> incubating in seems to need a
Hi Keshava,
To the best of my knowledge Nova does not have an explicit way to determine
VM placements based on network attributes. That said, it does have a
general mechanism called host-aggregates [1] that can be leveraged to
address what you are looking for. How certain hosts are grouped togethe
This is a development list, please ask usage questions on the users
list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Thanks.
-Ben
On 05/28/2014 07:58 AM, Ajaya Agrawal wrote:
> Hi All,
>
> We want to introduce a role of project admin in our cloud who can add users
> only in t
Hi Sergio,
On 28 May 2014 23:28, Cazzolato, Sergio J wrote:
> Hi Kieran,
>
> What do you think about the approach proposed in
> https://review.openstack.org/#/c/94519/ ?
>
> What we are trying to do is to simplify the way to manage default quotas
> through an API and keeping backward compatibil
On 28 May 2014 13:21, Joe Gordon wrote:
> Hi Kieran,
>
> Can you elaborate on this point. Do you actually use the full quota-class
> functionality that allows for quota classes, if so what provides the quota
> classes? If you only use this for setting the default quotas, why do you
> prefer the A
Hi,
I'm curious if other openstack clients implement this type of retry thing.
I think retrying on GET/DELETES/PUT's should probably be okay.
What types of errors do you see in the neutron-server when it fails to
respond? I think it would be better to move the retry logic into the server
around t
On Wed, May 28, 2014 at 7:39 AM, Assaf Muller wrote:
>
>
> - Original Message -
> > Hi,
> >
> > Sorry somehow I missed this email. I don't think you want to disable it,
> > though we can definitely have it run less often. The issue with
> disabling it
> > is if one of the notifications fr
An idea, and one that I've tried to apply in taskflow.
Since 3.0 added with http://legacy.python.org/dev/peps/pep-3134 if we can
*simulate* except chaining in our projects this would likely help even more
with traceability and debugging. I have a common exception that that I've been
using to ap
Hi, guys, I have two confused part in Ironic.
(1) if I use nova boot api to launch an physical instance, how does nova
boot command differentiate whether VM or physical node provision? From this
article, nova bare metal use "PlacementFilter" instead of
FilterScheduler.so does Ironic use the same
Hi All,
I am new to Openstack and want to understand the concepts of Openstack.
I am going through the pdf provided in Openstack ie Grizzly, but somewhat
from openstack website i found totally different releases such as Ironic,
Telemeter.
If anyone can point me the URL or PDF which is better to
"Armando M." wrote on 05/28/2014 07:35:52 PM:
> From: "Armando M."
> To: "OpenStack Development Mailing List (not for usage questions)"
> ,
> Date: 05/28/2014 07:37 PM
> Subject: Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network
> as input any consideration ?
>
> Hi Keshava,
>
> To
Hi,
You can find all the latest docs on OpenStack at http://docs.openstack.org/
On Thu, May 29, 2014 at 8:47 AM, Swaroop Jayanthi <
swaroop.jayan...@gmail.com> wrote:
> Hi All,
>
> I am new to Openstack and want to understand the concepts of Openstack.
>
> I am going through the pdf provided in
Hi Rado,
Thanks for this cool userscript!
It works great, and the only problem I found is TamperMonkey has some issue
with hash in @include pattern matching[1]. So I end up using
https://review.openstack.org/* instead of https://review.openstack.org/#/c/*
[1] http://tampermonkey.net/documentati
On 05/28/2014 07:43 PM, Ben Nemec wrote:
This is a development list, please ask usage questions on the users
list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Thanks.
Ordinarily I would ordinarily agree, but this is getting into stuff that
devs need to discuss.
-Ben
On 05
Hi Jarda,
These look pretty good! However, I'm having trouble evaluating from a purely
functional point of view, as I'm not entirely sure what the requirements
driving these design. Would it be possible to list those out. . . ?
Thanks,
Tzu-Mainn Chen
- Original Message -
> Hi All,
>
>
Hi Vijay,
On Wed, 2014-05-28 at 15:18 -0700, Vijay B wrote:
> Hi Brandon!
>
>
> Please see inline..
>
>
>
>
>
>
> On Wed, May 28, 2014 at 12:01 PM, Brandon Logan
> wrote:
> Hi Vijay,
>
> On Tue, 2014-05-27 at 16:27 -0700, Vijay B wrote:
> > Hi Brandon,
>
Hi Brandon,
I have one question. If we support LoadBalancer to Listener relationship M:N,
then one listener with IPV4 service members backend may be shared by a
loadbalancer instance with IPV6 forntend. Does it mean we also need to provide
IPV6 - IPV4 port forwarding functions in LBaaS services
Yes, agree on the use case. I suggest we introduce a series of callbacks and up calls to the scheduler so that we don't bloat the scheduler with information outside of its domain. Callbacks and up calls can be used to call external systems that keep detailed topology information. We can al
Hi Folks - I spoke with Michael at the summit about bug management for Juno.
Other than tagging the untagged bugs each week, I will also be driving a top
ten list of bugs at the nova meeting. The meeting is every Wednesday for 1/2
hour at 1630 UTC. Attendance has dropped off since the end of
> I think the problem being referred to in this thread is that the backup code
> assumes the *source* is a raw volume. The destination (i.e. swift) should
> absolutely remain universal across all volume back-ends - a JSON list with
> pointers. The JSON file is versioned, so there is scope to add mo
On 5/29/14 8:52 AM, James E. Blair wrote:
Devananda van der Veen writes:
Hi all!
This is a follow-up to several summit discussions on
how-do-we-deprecate-baremetal, a summary of the plan forward, a call to
raise awareness of the project's status, and hopefully gain some interest
from folks on
Thanks for putting this together Jaromir!
August 1 may be a problem for those of us from Australia - it's the day of
the OpenStack miniconf at Pycon-AU.
I don't know if any of us intended to go to that, but if we did we'd need
to leave no later than the 4:40pm flight on July 30 in order to make i
Hi Gabriel,
thanks for joining the conversation. It is a quite old discussion that was
also discussed at the Atlanta design summit, and it seems that the moment
this to happen had finally come. It is always nice to hear the opinion of a
real Django core developer.
Just a follow-up from the discus
On 28/05/14 17:57, Kyle Mestery wrote:
> On Wed, May 28, 2014 at 12:41 AM, mar...@redhat.com
> wrote:
>> On 27/05/14 17:14, Kyle Mestery wrote:
>>> Hi Neutron developers:
>>>
>>> I've spent some time cleaning up the BPs for Juno-1, and they are
>>> documented at the link below [1]. There are a la
Is there any wiggle room on those dates? As James Polley says, PyCon
AU (and the Openstack miniconf, which I'm organising with JHesketh)
overlap significantly - and I can't be in two places at once.
However July 21-25th would be totally doable :)
-Rob
On 28 May 2014 23:05, Jaromir Coufal wrote:
101 - 148 of 148 matches
Mail list logo
