Re: [openstack-dev] [TripleO] UI Wireframes for Resource Management - ready for implementation

Thanks everybody for your feedback. Based on it, here is final version for Nodes registration. Thread: http://ask-openstackux.rhcloud.com/question/95/tripleo-ui-resource-management/?answer=113#post-id-113 Wireframes: http://people.redhat.com/~jcoufal/openstack/tripleo/2013-12-13_tripleo-ui_n

[openstack-dev] [oslo][glance] Oslo.cfg resets not really resetting the CONF

Hi, I stumbled into a situation today where in I had to write few tests that modifies the oslo.config.cfg and in turn resets the values back in a tear down. Acc to the docs, oslo.cfg reset() "*Clears the object state and unsets overrides and defaults." *but, it doesn't seem to be happening, as t

Re: [openstack-dev] OK to Use Flufl.enum

Hello, Adam. On Tue, Dec 10, 2013 at 6:55 PM, Adam Young wrote: > With only a change to the import and requirements, it builds and runs, > but raises: > > > Traceback (most recent call last): > File "keystone/tests/test_revoke.py", line 65, in test_list_is_sorted > valid_until=valid_until

Re: [openstack-dev] [TripleO] UI Wireframes for Resource Management - ready for implementation

These look good! Quick question - can you explain the purpose of Node Tags? Are they an additional way to filter nodes through nova-scheduler (is that even possible?), or are they there solely for display in the UI? Mainn - Original Message - > Thanks everybody for your feedback. >

[openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones

Hey folks, after a bit longer but very useful discussion about requirements (almost 60 e-mails so far) I think we need to get to some conclusion what to deliver in Icehouse, what are the steps and what we should continue discussing to get better understanding for. Time is running mercilessly

Re: [openstack-dev] Incubation Request for Barbican

Russell Bryant wrote: > $ git shortlog -s -e | sort -n -r >172John Wood >150jfwood > 65Douglas Mendizabal > 39Jarret Raim > 17Malini K. Bhandaru > 10Paul Kehrer > 10Jenkins > 8jqxin2006 > 7

Re: [openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones

Nice list! Questions and comments in-line: - Original Message - > Hey folks, > > after a bit longer but very useful discussion about requirements (almost > 60 e-mails so far) I think we need to get to some conclusion what to > deliver in Icehouse, what are the steps and what we should co

Re: [openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones

Nice list! Questions and comments in-line: - Original Message - > Hey folks, > > after a bit longer but very useful discussion about requirements (almost > 60 e-mails so far) I think we need to get to some conclusion what to > deliver in Icehouse, what are the steps and what we should co

Re: [openstack-dev] [bugs] definition of triaged

Robert Collins wrote: > " > Confirmed The bug was reproduced or confirmed as a genuine bug > Triaged The bug comments contain a full analysis on how to properly > fix the issue > " > > From wiki.openstack.org/wiki/Bugs > > Putting aside the difficulty of complete reproduction sometimes, I > don't

Re: [openstack-dev] [TripleO] UI Wireframes for Resource Management - ready for implementation

On 2013/13/12 11:20, Tzu-Mainn Chen wrote: These look good! Quick question - can you explain the purpose of Node Tags? Are they an additional way to filter nodes through nova-scheduler (is that even possible?), or are they there solely for display in the UI? Mainn We start easy, so that's

[openstack-dev] [Ironic][Neutron] How does ironic/nova-baremetal and neutron work together

Can neutron manage the networking for bare metal instance created by ironic/nova-baremetal Can we assign floating IPs using neutron to bare metal instances Also, what features of neutron can be used with ironic/nova-baremetal Thanks, Tushar Bankar -- *Disclaimer* The information contain

[openstack-dev] Tempest tests for Python-troveclient [Trove][Tempest]

Dear All, My blueprint for Python-troveclient tests ( https://blueprints.launchpad.net/tempest/+spec/add-python-troveclient-tests) has been approved. I have wrote the tests (https://review.openstack.org/#/c/61937/). Now wait for a trove infrastructure in tempest gates to verify the changes. Let

Re: [openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones

Quick note - I want to keep this discussion a bit high-level and not to get into big implementation details. For everyone, please, let's agree in this thread on the direction and approach and we can start follow-up threads with bigger details of how to get those things done. On 2013/13/12 12:0

Re: [openstack-dev] [TripleO] Tuskar CLI after architecture changes

On 12.12.2013 17:10, Mark McLoughlin wrote: On Wed, 2013-12-11 at 13:33 +0100, Jiří Stránský wrote: Hi all, TL;DR: I believe that "As an infrastructure administrator, Anna wants a CLI for managing the deployment providing the same fundamental features as UI." With the planned architecture chang

[openstack-dev] [Heat] Questions on configuration options.

Hi, Just noticed the following configuration options in heat.conf(.sample), I'm wondering if some of them are not so relevant now. Leaving these options there may cause some confusion, especially for new comers like me. Some of the options may be place holders for future extension, some co

Re: [openstack-dev] [OpenStack-dev] How to modify a bug across multiple repo?

Hi wu jiang, On Wed, Dec 11, 2013 at 12:26 PM, wu jiang wrote: > Hi Chris & Rob, > > > Thanks for your reply ,and sorry for my late response.. > > - I tested again. The modification won't effect tempest test because it's > an optional argument, so I can commit it later in tempest. Lucky. > > -

Re: [openstack-dev] [TripleO] Tuskar CLI after architecture changes

> On 12.12.2013 17:10, Mark McLoughlin wrote: > > On Wed, 2013-12-11 at 13:33 +0100, Jiří Stránský wrote: > >> Hi all, > >> > >> TL;DR: I believe that "As an infrastructure administrator, Anna wants a > >> CLI for managing the deployment providing the same fundamental features > >> as UI." With the

Re: [openstack-dev] Announcing Fuel

Hi Mike, On Thu, 2013-12-12 at 18:31 +0400, Mike Scherbakov wrote: > Folks, > > Most of you by now have heard of Fuel, which we’ve been working on as a > related OpenStack project for a period of time - > see https://launchpad.net/fuel and > https://wiki.o

Re: [openstack-dev] [Keystone] policy has no effect because of hard coded assert_admin?

On Thu, Dec 12, 2013 at 11:03 PM, Qiu Yu wrote: > On Fri, Dec 13, 2013 at 2:40 AM, Morgan Fainberg wrote: > >> As Dolph stated, V3 is where the policy file protects. This is one of >> the many reasons why I would encourage movement to using V3 Keystone over >> V2. >> >> The V2 API is officially

[openstack-dev] Mirantis OpenStack 4.0 will support Ceilometer service

Hello everyone, I would like to announce that Mirantis OpenStack 4.0 will have support for Ceilometer service. Here is the short demonstration of Ceilometer deployment by Mirantis OpenStack 4.0. In this

Re: [openstack-dev] Mirantis OpenStack 4.0 will support Ceilometer service

On 12/13/2013 07:48 AM, Roman Sokolkov wrote: > Hello everyone, > > I would like to announce that Mirantis OpenStack 4.0 will have support > for Ceilometer service. > > Here is the short demonstration >

Re: [openstack-dev] [bugs] definition of triaged

On 12/13/2013 06:13 AM, Thierry Carrez wrote: > Robert Collins wrote: >> " >> Confirmed The bug was reproduced or confirmed as a genuine bug >> Triaged The bug comments contain a full analysis on how to properly >> fix the issue >> " >> >> From wiki.openstack.org/wiki/Bugs >> >> Putting aside the d

Re: [openstack-dev] Announcing Fuel

On 2013/12/12 15:31, Mike Scherbakov wrote: Folks, Most of you by now have heard of Fuel, which we’ve been working on as a related OpenStack project for a period of time -see https://launchpad.net/fueland https://wiki.openstack.org/wiki/Fuel. The aim of

Re: [openstack-dev] [UX] Weekly topic - Horizon Navigation

On 2013/10/12 17:49, Lyle, David wrote: This topic has been available on ux-askbot and ux Google+ forum before that for months. Based on that alone, I don’t believe the vote was limited. All input was taken and considered. In the end, there are strong opinions on both sides. What the final o

Re: [openstack-dev] [Heat] Questions on configuration options.

On Fri, Dec 13, 2013 at 08:12:30PM +0800, Qi Ming Teng wrote: > > Hi, > >Just noticed the following configuration options in heat.conf(.sample), > I'm wondering if some of them are not so relevant now. Leaving these > options > there may cause some confusion, especially for new comers like m

Re: [openstack-dev] Incubation Request for Barbican

On 12/13/2013 05:50 AM, Thierry Carrez wrote: > Russell Bryant wrote: >> $ git shortlog -s -e | sort -n -r >>172 John Wood >>150 jfwood >> 65 Douglas Mendizabal >> 39 Jarret Raim >> 17 Malini K. Bhandaru >> 10 Paul Kehrer >> 10

Re: [openstack-dev] Incubation Request for Barbican

On 12/12/2013 05:26 PM, Dolph Mathews wrote: > My reason for keeping them separate is more practical: the Keystone > team is already somewhat overloaded. I know that a couple of us > have interest in contributing to Barbican, the question is time and > prioritization. I don't th

Re: [openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones

On 12/13/2013 11:36 AM, Jaromir Coufal wrote: *VERSION 0* === Enable user to deploy OpenStack with the simpliest TripleO way, no difference between hardware. Target: - end of icehouse-2 Features we need to get in: - Enable manual nodes registration (Ironic) - Get images available for u

[openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI merge

Horizoners, As discussed in TripleO and Horizon meetings, we are proposing to move Tuskar UI under the Horizon umbrella. Since we are building our UI solution on top of Horizon, we think this is a good fit. It will allow us to get feedback and reviews from the appropriate group of developers.

Re: [openstack-dev] [bugs] definition of triaged

On 12/12/2013 04:46 PM, Robert Collins wrote: > Hi, I'm trying to overhaul the bug triage process for nova (initially) > to make it much lighter and more effective. > > I'll be sending a more comprehensive mail shortly before you do, let's agree what we're trying to solve. Perhaps you were going

Re: [openstack-dev] Announcing Fuel

On Dec 13, 2013, at 8:04 AM, Jaromir Coufal wrote: > On 2013/12/12 15:31, Mike Scherbakov wrote: >> Folks, >> >> >> Most of you by now have heard of Fuel, which we’ve been working on as a >> related OpenStack project for a period of time >> -see >> http

Re: [openstack-dev] Unified Guest Agent proposal

On Tue, 10 Dec 2013, Ian Wells wrote: > On 10 December 2013 20:55, Clint Byrum wrote: > > > If it is just a network API, it works the same for everybody. This > > makes it simpler, and thus easier to scale out independently of compute > > hosts. It is also something we already support and can ver

Re: [openstack-dev] [Ceilometer] Nomination of Sandy Walsh to core team

+1 in support of Sandy. He is a proven contributor and reviewer and he brings a great business vision and experience to the team. Cheers, Nick On Wed, Dec 11, 2013 at 8:18 PM, Gordon Chung wrote: > > To that end, I would like to nominate Sandy Walsh from Rackspace to > > ceilometer-core. Sand

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

* ability to 'preview' changes going to the scheduler What does this give you? How detailed a preview do you need? What information is critical there? Have you seen the proposed designs for a heat template preview feature - would that be sufficient? Will will probably have a better answer to t

Re: [openstack-dev] [Tempest][Production] Tempest / the gate / real world load

Robert, As you've deliberately picked on me I feel compelled to reply! Jokes apart, I am going to retire that patch and push the new default in neutron. Regardless of considerations on real loads vs gate loads, I think it is correct to assume the default configuration should be one that will allow

[openstack-dev] [governance] Becoming a Program, before applying for incubation

Hi everyone, TL;DR: Incubation is getting harder, why not ask efforts to apply for a new program first to get the visibility they need to grow. Long version: Last cycle we introduced the concept of "Programs" to replace the concept of "Official projects" which was no longer working that well for

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

On 12/13/2013 09:53 AM, Thierry Carrez wrote: > Hi everyone, > > TL;DR: > Incubation is getting harder, why not ask efforts to apply for a new > program first to get the visibility they need to grow. > > Long version: > > Last cycle we introduced the concept of "Programs" to replace the > concep

Re: [openstack-dev] Unified Guest Agent proposal

Excerpts from Sylvain Bauza's message of 2013-12-12 23:43:40 -0800: > Why the notifications couldn't be handled by Marconi ? > > That would be up to Marconi's team to handle security issues while it is > part of their mission statement to deliver a messaging service in between > VMs. Fantastic po

Re: [openstack-dev] Generic question: Any tips for 'keeping up' with the mailing lists?

On 12/12/13 17:52 +0100, Thierry Carrez wrote: Russell Bryant wrote: On 12/12/2013 11:23 AM, Justin Hammond wrote: I am a developer who is currently having troubles keeping up with the mailing list due to volume, and my inability to organize it in my client. I am nearly forced to use Outlook 20

Re: [openstack-dev] [trove] configuration groups and datastores type/versions

Good point... In this case however, couldn't you solve this by simply allowing the user to specify a list of multiple id's for both the datastore-id's and datastore-version-id's? That way the user can directly control which configurations apply to different types and versions (choosing to apply 0

Re: [openstack-dev] Unified Guest Agent proposal

Excerpts from Scott Moser's message of 2013-12-13 06:28:08 -0800: > On Tue, 10 Dec 2013, Ian Wells wrote: > > > On 10 December 2013 20:55, Clint Byrum wrote: > > > > > If it is just a network API, it works the same for everybody. This > > > makes it simpler, and thus easier to scale out independe

Re: [openstack-dev] Unified Guest Agent proposal

Hi guys, This seems to become a pretty long thread with quite a lot of ideas. What do you think about setting up a meeting on IRC to talk about what direction to take? IMO this has the potential of becoming a completely separated project to be hosted on stackforge or similar. Generally speakin

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

On 13/12/13 15:53 +0100, Thierry Carrez wrote: Hi everyone, TL;DR: Incubation is getting harder, why not ask efforts to apply for a new program first to get the visibility they need to grow. Long version: Last cycle we introduced the concept of "Programs" to replace the concept of "Official pr

[openstack-dev] [Neutron] Cores - Prioritize merging migration fixes after tox change merges

As per Anita's email, we're not to approve anything until the following tox fix merges: https://review.openstack.org/#/c/60825 Please keep an eye on the change, and once it merges, make sure that the following patches merge before regular approval rules resume: https://review.openstack.org/#/c

Re: [openstack-dev] Unified Guest Agent proposal

Hi Alessandro, it's a good idea to setup an IRC meeting for the unified agents. IMO it'll seriously speedup discussion. The first one could be used to determine the correct direction, then we can use them to discuss details and coordinate efforts, it will be necessary regardless of the approach.

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

On 12/13/2013 10:37 AM, Flavio Percoco wrote: > On 13/12/13 15:53 +0100, Thierry Carrez wrote: >> Hi everyone, >> >> TL;DR: Incubation is getting harder, why not ask efforts to apply >> for a new program first to get the visibility they need to grow. >> >> Long version: >> >> Last cycle we intro

Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint

On Dec 12, 2013, at 1:39 PM, devdatta kulkarni wrote: > We followed on the Zuul question in this week's git-integration working group > meeting. > > mordred has created an etherpad with a high-level description of Zuul and how > it might > fit with Solum't git integration workflow > > https:

Re: [openstack-dev] Unified Guest Agent proposal

On 13 December 2013 16:13, Alessandro Pilotti < apilo...@cloudbasesolutions.com> wrote: > 2) The HTTP metadata service accessible from the guest with its magic > number is IMO quite far from an optimal solution. Since every hypervisor > commonly > used in OpenStack (e.g. KVM, XenServer, Hyper-V, E

[openstack-dev] [Neutron] blueprint ovs-firewall-driver follow-up meeting

Hello all, On Wednesday, at the ML2 meeting we had an agenda item[1] to discuss the blueprint ovs-firewall-driver’s progress and technical challenges. We didn’t have time to discuss everything, so at the suggestion of Bob K. I am scheduling a meeting for Monday. Looking at the calendar of Open

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

While I agree with most of what Thierry said, I need clarifications though, on what a Program is, and what is the key point where an idea should get its own Program instead of being headed by an already existing Program. For example, take Barbican which is providing extra features to Keystone, or

Re: [openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones

On Fri, Dec 13, 2013 at 03:04:09PM +0100, Imre Farkas wrote: > On 12/13/2013 11:36 AM, Jaromir Coufal wrote: > > > >*VERSION 0* > >=== > >Enable user to deploy OpenStack with the simpliest TripleO way, no > >difference between hardware. > > > >Target: > >- end of icehouse-2 > > > >Features

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

Sylvain Bauza wrote: > While I agree with most of what Thierry said, I need clarifications > though, on what a Program is, A "team" is a group of people working on a given mission. They can be freely created. They apply to become an "OpenStack Program" if they feel their (well-established) mission

Re: [openstack-dev] Unified Guest Agent proposal

Excerpts from Alessandro Pilotti's message of 2013-12-13 07:13:01 -0800: > Hi guys, > > This seems to become a pretty long thread with quite a lot of ideas. What do > you think about setting up a meeting on IRC to talk about what direction to > take? > IMO this has the potential of becoming a co

Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements

On Mon Dec 9 15:22:04 2013, Robert Collins wrote: > On 9 December 2013 23:56, Jaromir Coufal wrote: >> >> Ironic today will want IPMI address + MAC for each NIC + disk/cpu/memory >> stats >> >> For registration it is just Management MAC address which is needed right? Or >> does Ironic need also I

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

On 13/12/13 10:44 -0500, Russell Bryant wrote: On 12/13/2013 10:37 AM, Flavio Percoco wrote: On 13/12/13 15:53 +0100, Thierry Carrez wrote: Hi everyone, TL;DR: Incubation is getting harder, why not ask efforts to apply for a new program first to get the visibility they need to grow. Long vers

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

Thanks Thierry. AFAIK, Compute ("Nova") is not having yet its own mission statement, so I guess any project with different people than regular Nova ATCs should consider an request for new Program if they feel there is difference in terms of feature delivery ? -Sylvain 2013/12/13 Thierry Carrez

Re: [openstack-dev] [governance] Becoming a Program, before applying for incubation

Apologies for the miss, I just double-checked and Nova does have its own mission statement : http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml Thanks, -Sylvain 2013/12/13 Sylvain Bauza > Thanks Thierry. > > AFAIK, Compute ("Nova") is not having yet its own mission

Re: [openstack-dev] Unified Guest Agent proposal

Excerpts from Sergey Lukjanov's message of 2013-12-13 07:46:34 -0800: > Hi Alessandro, > > it's a good idea to setup an IRC meeting for the unified agents. IMO it'll > seriously speedup discussion. The first one could be used to determine the > correct direction, then we can use them to discuss de

Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint

-Original Message- From: "Krishna Raman" Sent: Friday, December 13, 2013 9:44am To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint On Dec 12, 2013, at 1:39 PM, devdatta kulkarni wrote: > We foll

Re: [openstack-dev] Unified Guest Agent proposal

That's a great idea. How about the proposal below be changed such that the metadata-proxy forwards the /connect like calls to marconi queue A, and the response like ur's go to queue B. The agent wouldn't need to know which queue's in marconi its talking to then, and could always talk to it. An

Re: [openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones

On 13/12/13 11:36 +0100, Jaromir Coufal wrote: *VERSION 0* === Enable user to deploy OpenStack with the simpliest TripleO way, no difference between hardware. Target: - end of icehouse-2 Features we need to get in: - Enable manual nodes registration (Ironic) - Get images available fo

Re: [openstack-dev] Unified Guest Agent proposal

I have some follow up information regarding the part of this discussion about the possibility of leveraging the Salt Minion for an agent. I discussed this with Tom Hatch and he said that it very feasible to make this work with Salt. That could entail using the Salt Master, or even subclassing the

Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint

Hi, After reading the etherpad for Solum\Zuul integration I feel that I need more clarity on this. First of all, what is missed is a positioning of Zuul in overall Solum architecture. Let me explain a bit why I have this question about positioning: 1. I don't see how Solum entities (Application,

Re: [openstack-dev] [oslo][glance] Oslo.cfg resets not really resetting the CONF

On 2013-12-13 02:44, Amala Basha Alungal wrote: > Hi, > > I stumbled into a situation today where in I had to write few tests that > modifies the oslo.config.cfg and in turn resets the values back in a tear > down. Acc to the docs, oslo.cfg reset() "_Clears the object state and unsets > o

Re: [openstack-dev] Unified Guest Agent proposal

That's exactly why I proposed Marconi : - Notifications ('Marconi') is already an incubated Openstack program and consequently we need to envisage any already existing solutions in the Openstack ecosystem before writing a new one (aka. "silos"...) - Salt and other any other solutions are good but

Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint

On Dec 13, 2013, at 8:56 AM, devdatta kulkarni wrote: > -Original Message- > From: "Krishna Raman" > Sent: Friday, December 13, 2013 9:44am > To: "OpenStack Development Mailing List (not for usage questions)" > > Subject: Re: [openstack-dev] [Solum] Using Zuul in the Git-pull bluepri

Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint

On Dec 13, 2013, at 9:32 AM, Georgy Okrokvertskhov wrote: > Hi, > > After reading the etherpad for Solum\Zuul integration I feel that I need more > clarity on this. First of all, what is missed is a positioning of Zuul in > overall Solum architecture. Let me explain a bit why I have this que

Re: [openstack-dev] [Nova] Support for Pecan in Nova

On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh wrote: > On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes wrote: > >> On 12/11/2013 11:47 PM, Mike Perez wrote: >> >>> On 10:06 Thu 12 Dec , Christopher Yeoh wrote: >>> On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann >>>

Re: [openstack-dev] Unified Guest Agent proposal

18:39 , Clint Byrum wrote: > Excerpts from Alessandro Pilotti's message of 2013-12-13 07:13:01 -0800: >> Hi guys, >> >> This seems to become a pretty long thread with quite a lot of ideas. What do >> you think about setting up a meeting on IRC to talk about what direction to >> take? >> IMO th

Re: [openstack-dev] Introducing the new OpenStack service for Containers

Hi, I have definitely seen a drop off in the proposed Container-Service API discussion. I think peple are still mauling over the ideas that were presented so far. However with looking at the discussion so far, and possibly trying to get the discussion going again, I don't think we are at the point

[openstack-dev] [Heat] [Murano] [Solum] Metadata repository initiative discussion for Glance

Hi, Recently a Heater proposal was announced in openstack-dev mailing list. This discussion lead to a decision to add unified metadata service \ catalog capabilities into Glance. On the Glance weekly meeting this initiative was discussed and Glance team agreed to take a look onto BPs and API docu

Re: [openstack-dev] [TripleO] UI Wireframes for Resource Management - ready for implementation

> On 2013/13/12 11:20, Tzu-Mainn Chen wrote: > > These look good! Quick question - can you explain the purpose of Node > > Tags? Are they > > an additional way to filter nodes through nova-scheduler (is that even > > possible?), or > > are they there solely for display in the UI? > > > > Mainn >

Re: [openstack-dev] [TripleO] [Tuskar] [UI] Icehouse Requirements - Summary, Milestones

> Quick note - I want to keep this discussion a bit high-level and not to > get into big implementation details. For everyone, please, let's agree > in this thread on the direction and approach and we can start follow-up > threads with bigger details of how to get those things done. I'm not sure h

Re: [openstack-dev] Performance Regression in Neutron/Havana compared to Quantum/Grizzly

Hello All, Update with my testing. I have installed one more VM as neutron-server host and configured under the Load Balancer. Currently I have 2 VMs running neutron-server process (one is Controller and other is dedicated neutron-server VM) With this configuration during the batch instance de

Re: [openstack-dev] Unified Guest Agent proposal

Hmm.. so If I understand right, the concern you started is something like: * You start up a vm * You make it available to your users to ssh into * They could grab the machine's metadata I hadn't thought about that use case, but that does sound like it would be a problem. Ok, so... the problem

Re: [openstack-dev] Unified Guest Agent proposal

Excerpts from Fox, Kevin M's message of 2013-12-13 11:32:01 -0800: > Hmm.. so If I understand right, the concern you started is something like: > * You start up a vm > * You make it available to your users to ssh into > * They could grab the machine's metadata > > I hadn't thought about that us

Re: [openstack-dev] Unified Guest Agent proposal

Still, what about one more server process users will have to run? I see unified agent as library which can be easily adopted by both exiting and new OpenStack projects. The need to configure and maintain Salt server process is big burden for end users. That idea will definitely scare off adoption o

Re: [openstack-dev] Unified Guest Agent proposal

On Fri, 13 Dec 2013, Fox, Kevin M wrote: > Hmm.. so If I understand right, the concern you started is something like: > * You start up a vm > * You make it available to your users to ssh into > * They could grab the machine's metadata > > I hadn't thought about that use case, but that does soun

Re: [openstack-dev] [Heat] [Murano] [Solum] [Glance]Metadata repository initiative discussion for Glance

Hi, It looks like I forgot to add Glance. Fixing this now. I am sorry for duplicating the thread. Thanks Georgy On Fri, Dec 13, 2013 at 12:02 PM, Georgy Okrokvertskhov < gokrokvertsk...@mirantis.com> wrote: > Yes. It is a Pacific Standard Time. > > Thanks > Georgy > > > On Fri, Dec 13, 2013 at

Re: [openstack-dev] Unified Guest Agent proposal

Ah, good point. So, disabling the route wouldn't work if you wanted to use the metadata proxy for ongoing events for the guest agent. But the nonce option would would work. Another option would be to add a 169.254.169.254/metadata/disable url that disables that part of the proxy after cloud-in

Re: [openstack-dev] Unified Guest Agent proposal

Excerpts from Dmitry Mescheryakov's message of 2013-12-13 12:01:01 -0800: > Still, what about one more server process users will have to run? I see > unified agent as library which can be easily adopted by both exiting and > new OpenStack projects. The need to configure and maintain Salt server > p

Re: [openstack-dev] Introducing the new OpenStack service for Containers

On Fri, Dec 13, 2013 at 1:19 PM, Chuck Short wrote: > Hi, > > I have definitely seen a drop off in the proposed Container-Service API > discussion > There was only one action item from the meeting, which was a compilation of use-cases from Krishna. Krishna, have you made progress on the use-case

Re: [openstack-dev] Unified Guest Agent proposal

2013/12/13 Fox, Kevin M > Yeah, I think the extra nic is unnecessary too. There already is a working > route to 169.254.169.254, and a metadata proxy -> server running on it. > > So... lets brainstorm for a minute and see if there are enough pieces > already to do most of the work. > > We already

Re: [openstack-dev] [Solum] Language pack attributes schema

On Mon, 2013-12-09 at 13:02 -0800, Georgy Okrokvertskhov wrote: > Hi, > > > As a part of Language pack workgroup session we created an etherpad > for language pack attributes definition. Please find a first draft of > language pack attributes > here: https://etherpad.openstack.org/p/Solum-Languag

Re: [openstack-dev] Unified Guest Agent proposal

2013/12/13 Sylvain Bauza > Why the notifications couldn't be handled by Marconi ? > > That would be up to Marconi's team to handle security issues while it is > part of their mission statement to deliver a messaging service in between > VMs. > Sylvain, very interesting suggestion! Marconi defini

Re: [openstack-dev] [Solum] Language pack attributes schema

I added some comments to the bottom specifically about lessons learned from operating things like language pack - I discuss the concept of version streams and how an operator spoon feeds base images for the language pack out to applications. > On Dec 9, 2013, at 4:05 PM, Georgy Okrokvertskho

Re: [openstack-dev] OK to Use Flufl.enum

On 12/13/2013 05:17 AM, Yuriy Taraday wrote: Hello, Adam. On Tue, Dec 10, 2013 at 6:55 PM, Adam Young > wrote: With only a change to the import and requirements, it builds and runs, but raises: Traceback (most recent call last): File "keystone/test

Re: [openstack-dev] Unified Guest Agent proposal

I think the Marconi idea mentioned earlier would work very similar over http but provide a simple to implement solution. I think we need to make the agent as simple as possible on the vm. an http client is easy as its likely already in the vm. AMQP or STOMP or whichever client is not as easy.

Re: [openstack-dev] [Nova][TripleO] Nested resources

On Tue, 2013-12-10 at 09:40 +1300, Robert Collins wrote: > On 6 December 2013 14:11, Fox, Kevin M wrote: > > I think the security issue can be handled by not actually giving the > > underlying resource to the user in the first place. > > > > So, for example, if I wanted a bare metal node's worth

Re: [openstack-dev] [keystone][heat] ec2tokens, v3 credentials and request signing

On Tue, 2013-12-10 at 15:13 +, Steven Hardy wrote: > I'm just thinking it would be really great (from a user-of-keystone > perspective) if we could avoid further fragmentation and just have one type > of shared secret (a keystone token), which can be configured flexibly > enough to satisfy the

Re: [openstack-dev] [Solum] Language pack attributes schema

Hi, I will change format to YAML. It should be pretty straightforward. I also like an idea of versioning for LP. I personally don't like name "Stream" but we can figure out naming later. Thanks Georgy On Fri, Dec 13, 2013 at 12:40 PM, Clayton Coleman wrote: > I added some comments to the bo

Re: [openstack-dev] [Nova] [Neutron] How do we know a host is ready to have servers scheduled onto it?

On Thu, 2013-12-12 at 21:01 +, Joshua Harlow wrote: > Maybe time to revive something like: > > https://review.openstack.org/#/c/12759/ > > > From experience, all sites (and those internal to yahoo) provide a /status > (or equivalent) that is used for all sorts of things (from basic > load-ba

Re: [openstack-dev] [Nova] Support for Pecan in Nova

On Fri, 2013-12-13 at 12:52 +1030, Christopher Yeoh wrote: > On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes wrote: > > +1. I agree with most of what Mike says above. The idea that > there are core "extensions" in Nova's v3 API doesn't make a > whole lot of sense to me

Re: [openstack-dev] [Nova] Support for Pecan in Nova

Unless there’s some other trickiness going on that I’m unaware of, the routes for the WSGI app are defined at application startup time (by methods called in the WSGI app’s __init__). --- Ryan Petrello Senior Developer, DreamHost ryan.petre...@dreamhost.com On Dec 13, 2013, at 12:56 PM, Doug Hel

Re: [openstack-dev] Unified Guest Agent proposal

2013/12/13 Alessandro Pilotti > Hi guys, > > This seems to become a pretty long thread with quite a lot of ideas. What > do you think about setting up a meeting on IRC to talk about what direction > to take? > IMO this has the potential of becoming a completely separated project to > be hosted on

Re: [openstack-dev] [Solum] Language pack attributes schema

> On Dec 13, 2013, at 4:25 PM, Georgy Okrokvertskhov > wrote: > > Hi, > > I will change format to YAML. It should be pretty straightforward. > > I also like an idea of versioning for LP. I personally don't like name > "Stream" but we can figure out naming later. Version is almost always to

Re: [openstack-dev] [TripleO][Tuskar] Terminology

On 13/12/13 16:20 +1300, Robert Collins wrote: On 12 December 2013 21:59, Jaromir Coufal wrote: On 2013/12/12 01:21, Robert Collins wrote: Avoiding cloud - ack. However, on instance - 'instance' is a very well defined term in Nova and thus OpenStack: Nova boot gets you an instance, nova de

Re: [openstack-dev] [Nova] Support for Pecan in Nova

That covers routes. What about the properties of the inputs and outputs? On Fri, Dec 13, 2013 at 4:43 PM, Ryan Petrello wrote: > Unless there’s some other trickiness going on that I’m unaware of, the > routes for the WSGI app are defined at application startup time (by methods > called in the WS

Re: [openstack-dev] Unified Guest Agent proposal

FWIW, Marconi can easily deliver sub-second latency even with lots of clients fast-polling. We are also considering a long-polling feature that will reduce latency further for HTTP clients. On 12/13/13, 2:41 PM, "Fox, Kevin M" wrote: >A second or two of latency perhaps shaved off by using someth

Re: [openstack-dev] [TripleO][Tuskar] Terminology

On Wed, 2013-12-11 at 14:15 -0500, Tzu-Mainn Chen wrote: > Hi, > > I'm trying to clarify the terminology being used for Tuskar, which may be > helpful so that we're sure > that we're all talking about the same thing :) I'm copying responses from > the requirements thread > and combining them wi

  1   2   >