Re: [openstack-dev] [Neutron] IPv6 & DHCP options for dnsmasq

[Luke Gorrie]

On 21 October 2013 19:51, Sean M. Collins  wrote:

> The motivation is to help Neutron work with IPv6 - which is a must-have
> for Comcast.
>

Deutsche Telekom too. We are working on making Neutron interoperate well
with a service provider network that's based on IPv6. I look forward to
talking about this with people in Hong Kong :)

Cheers,
-Luke
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] HOT Software configuration proposal

[Thomas Spatzier]

> Steve Baker  wrote on 21.10.2013 23:02:47:
> From: Steve Baker 
> To: openstack-dev@lists.openstack.org,
> Date: 21.10.2013 23:06
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
>> On 10/22/2013 08:45 AM, Mike Spreitzer wrote:
>> Steve Baker  wrote on 10/15/2013 06:48:53 PM:
>>
>> > I've just written some proposals to address Heat's HOT software
>> > configuration needs, and I'd like to use this thread to get some
feedback:
>> > https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config
>> > https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-
>> bootstrap-config
>> >
>> > Please read the proposals and reply to the list with any comments or
>> > suggestions.
>>
>> Can you confirm whether I have got the big picture right?  I think
>> some of my earlier remarks were mistaken.
>>
>> You propose to introduce the concept of component and recognize
>> software configuration as a matter of invoking components --- with a
>> DAG of data dependencies among the component invocations.  While
>> this is similar to what today's heat engine does for resources, you
>> do NOT propose that the heat engine will get in the business of
>> invoking components.  Rather: each VM will run a series of component
>> invocations, and in-VM mechanisms will handle the cross-component
>> synchronization and data communication.
> This is basically correct, except that in-VM mechanisms won't know
> much about cross-component synchronization and data communication.
> They will just execute whatever components are available to be
> executed, and report back values to heat-engine by signalling to
> waitconditions.
>>  You propose to add a bit of sugaring for the wait condition&handle
>> mechanism, and the heat engine will do the de-sugaring.
> Yes, I think improvements can be made on what I proposed, such as
> every component signalling when it is complete, and optionally
> including a return value in that signal.

Being able to handle completion of single components inside a VM and being
able to pass outputs of those components seems important to me. I think
that should mostly address the requirements for declaring data dependencies
between components that have been discussed before in this thread. If
wait-conditions are the underlying mechanism, fine, as longs as we can hid
it from the template syntax.

For example, something like this should be possible:

components:
  comp_a:
type: OS::Heat::SomeCMProvider
properties:
  prop1: { get_param: param1 }
  prop2: ...
  comp_b:
type: OS::Heat::SomeCMProvider
properties:
  propA: { get_attr: [ comp_a, some_attr ] }

resources:
  serverA:
type: OS::Nova::Server
# ...
components:
  - comp_a
  serverB:
type: OS::Nova::Server
# ...
components:
  - comp_b

I.e. there are two components comp_a and comp_b on two different servers.
comp_a has a data dependency on an attribute of comp_b. If we treat
'properties' as input to components and 'attributes' as output (the way it
is currently done for resources), that should be doable.
BTW, the convention of properties being input and attributes being output,
i.e. that subtle distinction between properties and attributes is not
really intuitive, at least not to me as non-native speaker, because I used
to use both words as synonyms.
Anyway it seems like the current proposal is a starting point with
enhancements on the roadmap, right?

>>  Each component is written in one of a few supported configuration
>> management (CM) frameworks, and essentially all component
>> invocations on a given VM invoke components of the same CM framework
>> (with possible exceptions for one or two really basic ones).
> Rather than being limited to a few supported CM tools, I like the
> idea of some kind of provider mechanism so that users or heat admins
> can add support for new CM tools. This implies that it needs to be
> possible to add a component type without requiring custom python
> that runs on heat engine.
>> The heat engine gains the additional responsibility of making sure
>> that the appropriate CM framework(s) is(are) bootstrapped in each VM.
> Maybe. Or it might be up to the user to invoke images that already
> have the CM tools installed, or the user can provide a custom
> component provider which installs the tool in the way that they want.
>
> As for the cross-component synchronization and data communication
> question, at this stage I'm not comfortable with bringing something
> like zookeeper into the mix for a general solution for inter-
> component communication.  If heat engine handles resource
> dependencies and zookeeper handles software configuration
> dependencies this would result in the state of the stack being split
> between two different co-ordination mechanisms.

I think that zookeeper could be an _optional_ backend for this, but using
the current mechanisms in Heat should probably be the primary or default
way of doing this.

>
> We've put quite s

[openstack-dev] Merge multiple OVS bridges ?

[Gopi Krishna B]

Hi
Currently in Neutron the integration bridge (br-int) and other bridges
configured over each physical nic (e.g. br-eth0, br-eth1 etc) are being
configured in Compute and Network nodes. What is the logic behind or
advantages having 2 OVS bridges in the physical host?

Can we have only one bridge for each physical NIC, similar to what linux
bridge setup has. And configure/modify the flows such that VLAN conversion
is appropriately setup for ingress and egress traffic within the single
bridge.
Thus also eliminating the veth pairs used to connect the bridges together.
Is this a feasible proposal, and can it be worked on?

-- 
Regards
Gopi Krishna
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Merge multiple OVS bridges ?

[P Balaji-B37839]

Are the below observations on Havana?

From: Gopi Krishna B [mailto:gopi97...@gmail.com]
Sent: Tuesday, October 22, 2013 12:52 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] Merge multiple OVS bridges ?


Hi
Currently in Neutron the integration bridge (br-int) and other bridges 
configured over each physical nic (e.g. br-eth0, br-eth1 etc) are being 
configured in Compute and Network nodes. What is the logic behind or advantages 
having 2 OVS bridges in the physical host?

Can we have only one bridge for each physical NIC, similar to what linux bridge 
setup has. And configure/modify the flows such that VLAN conversion is 
appropriately setup for ingress and egress traffic within the single bridge.
Thus also eliminating the veth pairs used to connect the bridges together.
Is this a feasible proposal, and can it be worked on?

--
Regards
Gopi Krishna


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)

[Mark McLoughlin]

On Tue, 2013-10-22 at 14:19 +0800, Thomas Goirand wrote:
> On 10/22/2013 04:48 AM, Mark McLoughlin wrote:
> > On Tue, 2013-10-22 at 01:55 +0800, Thomas Goirand wrote:
> >> On 10/21/2013 09:28 PM, Mark McLoughlin wrote:
> >>> In other words, what exactly is a list of copyright holders good for?
> >>
> >> At least avoid pain and reject when uploading to the Debian NEW queue...
> > 
> > I'm sorry, that is downstream Debian pain.
> 
> I agree, it is painful, though it is a necessary pain. Debian has always
> been strict with copyright stuff. This should be seen as a freeness Q/A,
> so that we make sure everything is 100% free, rather than an annoyance.

A list of copyright holders does nothing to improve the "freeness" of
OpenStack.

> > It shouldn't be inflicted on
> > upstream unless it is generally a useful thing.
> 
> There's no other ways to do things, unfortunately. How would I make sure
> a software is free, and released in the correct license, if upstream
> doesn't declare it properly? There's been some cases on packages I
> wanted to upload, where there was just:
> 
> Classifier: License :: OSI Approved :: MIT License
> 
> in *.egg-info/PKG-INFO, and that's it. If the upstream authors don't fix
> this by adding a clear LICENSE file (with the correct definition of the
> MIT License, which is confusing because there's been many of them), then
> the package couldn't get in. Lucky, upstream authors of that python
> module fixed that, and the package was re-uploaded and validated by the
> FTP masters.

I fully understand the importance of making it completely clear what the
license of a project is and have had to package projects that don't make
this clear. Fedora's guidelines on the subject are e.g.

https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text

> I'm not saying that this was the case for Trove (the exactitude of the
> copyright holder list in debian/copyright is less of an issue), though
> I'm just trying to make you understand that you can't just ignore the
> issue and say "I don't care, that's Debian's problem". This simply
> doesn't work (unless you would prefer OpenStack package to *not* be in
> Debian, which I'm sure isn't the case here).

I can say "Debian policies that no-one can provide any justification for
is Debian's problem". And that's the case with this supposed "Debian
requires a complete list of copyright holders" policy.

Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)

[Robert Collins]

On 22 October 2013 20:39, Mark McLoughlin  wrote:
> On Tue, 2013-10-22 at 14:19 +0800, Thomas Goirand wrote:
>> I agree, it is painful, though it is a necessary pain. Debian has always
>> been strict with copyright stuff. This should be seen as a freeness Q/A,
>> so that we make sure everything is 100% free, rather than an annoyance.

What Debian asks for is more than anyone else needs, and I've never
seen a satisfactory explanation for why Debian requires it. The
concordance of licence terms is useful, but the concordance of
copyright holders isn't - a) it's usually wrong and b) it's usually
wrong and c) unless there is a use case like 'I don't want to use code
written by person X', it doesn't serve any purpose ... and it doesn't
serve that case, because copyright claimants != authors.

It saddens me everytime I put a new package together, because it's
such a monumental waste of time.

> A list of copyright holders does nothing to improve the "freeness" of
> OpenStack.

Ack.

>> I'm not saying that this was the case for Trove (the exactitude of the
>> copyright holder list in debian/copyright is less of an issue), though
>> I'm just trying to make you understand that you can't just ignore the
>> issue and say "I don't care, that's Debian's problem". This simply
>> doesn't work (unless you would prefer OpenStack package to *not* be in
>> Debian, which I'm sure isn't the case here).
>
> I can say "Debian policies that no-one can provide any justification for
> is Debian's problem". And that's the case with this supposed "Debian
> requires a complete list of copyright holders" policy.

I agree - and I say this as a Debian Developer :).

The actual policy is:
http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
"In addition, the copyright file must say where the upstream sources
(if any) were obtained, and should name the original authors. "

The 'copyright information' for the package is not well defined.
Currently the FTP masters look for a concordance. I think it would be
reasonable to raise a discussion about this - seeking to clarify what
needs to be captured - e.g. 'the package has to have a distribution
license granted by the copyright holders -or- a statement from the
copyright holders that it is in the public domain'. As long as all the
claimed copyright holders are claiming the same license, there is
nothing more needed for either Debian or it's derivatives to be able
to:
 a) use the package
 b) redistribute it [per whatever licence]
 c) filter it if they have license specific policies for some
project/environment

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OpenStack][Swift] how does swift update obj count of container or account?

[Gareth]

Hi

How does Swift update container object count or account object count after
PUT an object? Counting per request or something else?

-- 
Gareth

*Cloud Computing, OpenStack, Fitness, Basketball*
*OpenStack contributor*
*Company: UnitedStack *
*My promise: if you find any spelling or grammar mistakes in my email from
Mar 1 2013, notify me *
*and I'll donate $1 or ￥1 to an open organization you specify.*
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] extend Network topology view in horizon

[Ofer Blaut]

Hi

It will be helpful to extend Network topology view in horizon 

1. Admin should be able to see the entire/per tenant network topology (we might 
need a flag to enable/disable it). 

2. Supporting ICON for FWaaS/LBaaS/VPNaaS on both admin & tenant level, so it 
will be easy to see the deployments   

Are there any blueprints to support it ? 

Thanks

Ofer 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Reminder: Project & release status meeting - 21:00 UTC

[Thierry Carrez]

Today we'll have the first release meeting of the Icehouse cycle.
We'll do a quick post-mortem of the Havana release week, then spend most
of the meeting time looking at the Design Summit schedule (discussing,
and potentially moving or grouping, cross-topic sessions).

Feel free to add extra topics to the agenda:
[1] http://wiki.openstack.org/Meetings/ProjectMeeting

All program leads should be present (if you can't make it, please name a
substitute on [1]). Everyone else is very welcome to attend.

The meeting will be held at 21:00 UTC on the #openstack-meeting channel
on Freenode IRC. You can look up how this time translates locally at:
[2] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20131022T21

See you there,

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Merge multiple OVS bridges ?

[Gopi Krishna B]

Are the below observations on Havana?

My observations are w.r.t. Grizzly, but I didnot see any changes in Havana
reg. the same.
-- 
Regards
Gopi Krishna
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack][Swift] how does swift update obj count of container or account?

[Alex Yang]

Hi Gareth:

The process of update object count to container db is synchronized. After
the DiskFile finish writing the data to disk, the object-server will make a
request to container servers and update the object count. If the request
failed, the request will be serialized on the disk, and the object-update
will update it to container servers asynchronously.

The process of update object count from container db to account db is
asynchronized. The container-updater will loop all the container db files
in disk and update the object count the account servers.




2013/10/22 Gareth 

> Hi
>
> How does Swift update container object count or account object count after
> PUT an object? Counting per request or something else?
>
> --
> Gareth
>
> *Cloud Computing, OpenStack, Fitness, Basketball*
> *OpenStack contributor*
> *Company: UnitedStack *
> *My promise: if you find any spelling or grammar mistakes in my email
> from Mar 1 2013, notify me *
> *and I'll donate $1 or ￥1 to an open organization you specify.*
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
  杨雨
  Email:   alex890...@gmail.com
GitHub:   https://github.com/AlexYangYu
 Weibo:   http://www.weibo.com/alexyangyu
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [stackalytics] team meeting minutes October 21

[Ilya Shakhat]

Thanks everyone who have joined Stackalytics meeting.

The team reviewed and prioritized blueprints. For the next 0.4 release the
following bps were selected:
 * 
module-review-backlog-stats
-
reports on review activity for modules
 * 
review-punchcard
-
report usual working hours for engineer, similar to
https://github.com/stackforge/stackalytics/graphs/punch-card
 * 
web-filters-caching
-
cache search queries to improve performance

The full logs are available below:

Minutes:
http://eavesdrop.openstack.org/meetings/stackalytics/2013/stackalytics.2013-10-21-15.01.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/stackalytics/2013/stackalytics.2013-10-21-15.01.txt
Log:
http://eavesdrop.openstack.org/meetings/stackalytics/2013/stackalytics.2013-10-21-15.01.log.html


Sincerely yours,
Ilya Shakhat
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Bootstrap 3 update and problems with lesscpy

[Jiri Tomasek]

Hi,

I have updates on my work towards getting Horizon updated to Bootstrap 3.

I have finished Bootstrap 3 update for Horizon using the old lessc 
compiler to review the work and I have created two versions:
1. patch that uses original lessc library to be able to review the 
bootstrap 3 in current Horizon [1]
2. patch that uses Lesscpy but does not compile css properly - for 
reviewing of the compilation issues [2]

(see commit messages for details)

I marked these as work in progress because of lesscpy problems but 
please feel free to have a look and give feedback.


So what is remaining is to get lesscpy up to speed with Bootstrap 3. 
Sascha Peilicke has created a fix to "support semicolons in mixin 
arguments" [3] some time agobut it still needs to get into original 
repository as pull request. The other issues reported are still valid. 
Buggest issue at the moment seems to be in @media declaration including 
variable [4]. I have tried 
to have a look at this but the solution is probably not the best... [5]. 
I have contacted Sascha regarding this and so far I am waiting for response.


Any feedback or help with getting Lesscpy fixed is highly welcome.

[1] https://review.openstack.org/#/c/49710/
[2] https://review.openstack.org/#/c/49712/
[3] https://github.com/saschpe/Lesscpy/commits/master
[4] https://github.com/robotis/Lesscpy/issues/18
[5] https://github.com/jtomasek/Lesscpy/commits/var_in_media

Thanks

Jirka


On 09/19/2013 01:44 AM, Gabriel Hurley wrote:

I'm also strongly against reverting the move to lesscpy. As David said, that 
change was highly-requested by the downstream distros and other folks packaging 
Horizon in various ways.

Since there's no evidence that lesscpy does not intend to support bootstrap 3 
in a reasonable timeframe, reverting the patch in the interim would simply be 
impatience. The better thing to do as a member of the larger open source 
community is to contribute your own energy to lesscpy and to help them improve 
their project in a timely manner. I'm glad to hear that Sasha is already 
working on that. I'm sure they're happy for the assistance and for having their 
work utilized by a significant project like Horizon.

We'll get to bootstrap 3, but not by undoing work we've already done.

Please keep us all updated on the progress upstream, I know I for one look 
forward to seeing the benefits we can derive from the newer bootstrap code.

 - Gabriel


-Original Message-
From: Lyle, David (Cloud Services) [mailto:david.l...@hp.com]
Sent: Wednesday, September 18, 2013 8:44 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Horizon] Bootstrap 3 update and problems
with lesscpy

Right now, master in Horizon is still working toward Havana-rc1.  We are still
likely more than a week away from master moving to Icehouse-1.  As this is
the case, reverting a highly desired Havana change to address a blueprint for
Icehouse that can be addressed properly upstream in lesscpy does not seem
like a good course of action.  I understand the amount of work involved in
updating Bootstrap, but our goal should be to properly resolve the conflict
once we are working on Icehouse.

-David

On Wednesday, September 18, 2013 6:27 AM Jiri Tomasek
[mailto:jtoma...@redhat.com] wrote:


Hi all,
I've started working on updating Bootstrap to version 3 in Horizon.

https://blueprints.launchpad.net/horizon/+spec/bootstrap-update


As I have described in blueprint whiteboard, I am experiencing compile

problems with the new lesscpy compiler that we started using recently. The
compiled css code is incorrect and when running the compilation from
terminal, about 200 syntax errors occur. This is related to certain features of
Less not being supported by lesscpy. I have created a GIthub issue for
lesscpy here: https://github.com/robotis/Lesscpy/issues/22 .


Sasha Peilicke has already started working on updating the lesscpy library to

support all less features needed to compile Bootstrap 3 properly. Although I
think that it will take more than a few weeks before lesscpy is there where
we need it.


I have part of Bootstrap 3 update ready and as it is quite a large patch I

would like to get this in as soon as possible because any rebase to a new
Horizon master is quite tedious process. Also there are another blueprints
that depend on this update (font-icons and css-breakdown, see dependency
tree).


So I would like to propose to revert the patch that introduces lesscpy library

(a0739c9423 Drop NodeJS dependency in favor of pure-python lesscpy) and
use the lessc library for the time being untill lesscpy is capable of compiling
Bootstrap 3.


I have revert patch ready together with update of lessc library in

horizon/bin, which I can make part of Bootstrap-update blueprint and send
them right away to gerrit for a review. I have also tested that with this >
setup the Bootstrap 3 updated Horizon less file compiles properly.


When

Re: [openstack-dev] [OpenStack][Swift] how does swift update obj count of container or account?

[Gareth]

On Tue, Oct 22, 2013 at 5:33 PM, Alex Yang  wrote:

> Hi Gareth:
>
> The process of update object count to container db is synchronized. After
> the DiskFile finish writing the data to disk, the object-server will make a
> request to container servers and update the object count. If the request
> failed, the request will be serialized on the disk, and the object-update
> will update it to container servers asynchronously.
>
> The process of update object count from container db to account db is
> asynchronized. The container-updater will loop all the container db files
> in disk and update the object count the account servers
>

If I start my services like "swift-init main start"(container-updater will
not be launched), the obj-count of account will be 0? for the reason that
no container-updater reports data to account.
But the truth is not that. The obj-count of account and container is
correct in most of simple cases.


>
>
>
> 2013/10/22 Gareth 
>
>> Hi
>>
>> How does Swift update container object count or account object count
>> after PUT an object? Counting per request or something else?
>>
>> --
>> Gareth
>>
>> *Cloud Computing, OpenStack, Fitness, Basketball*
>> *OpenStack contributor*
>> *Company: UnitedStack *
>> *My promise: if you find any spelling or grammar mistakes in my email
>> from Mar 1 2013, notify me *
>> *and I'll donate $1 or ￥1 to an open organization you specify.*
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>   杨雨
>   Email:   alex890...@gmail.com
> GitHub:   https://github.com/AlexYangYu
>  Weibo:   http://www.weibo.com/alexyangyu
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Gareth

*Cloud Computing, OpenStack, Fitness, Basketball*
*OpenStack contributor*
*Company: UnitedStack *
*My promise: if you find any spelling or grammar mistakes in my email from
Mar 1 2013, notify me *
*and I'll donate $1 or ￥1 to an open organization you specify.*
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] Update: Nova API List for Missing Tempest Tests

[Masayuki Igawa]

Hi, Ivan

Thank you for your information. And I'm sorry for delay reply.

> Hi, 
> 
> I also collect the tests status for nova v3 api manually. You can find the 
> status of v3 tests in this link: 
> https://etherpad.openstack.org/p/nova-v3-tests
> 
> Because there are some extensions that just extend the attribute of specific 
> api reponse, or convert some input before specific api
> called. There is no url for these extension, but I think we also need check 
> them. I collect the tempest tests according to the nova api code. check tests 
> to the action
> one by one, list the status file by file. 

I have a question. Is there any way to list the nova v3 apis?
If so, I think the checking process of the test implementation can be 
automatically.

Best Regards,
-- Masayuki Igawa


> 
> Due to these patch https://review.openstack.org/#/c/39609/ and 
> https://review.openstack.org/#/c/39621/ are still under reviewing. so we 
> can't add tempest test for nova v3 api. (almost existing tests have been 
> ported into v3, but these patches depend on the 39609 and 39621).  The status 
> of porting existing tests is also listed in this link. we will add the 
> missing tests in v2
> firstly, when it can be ported into v3, will port it.
> 
> Best Regards
> Ivan Zhu
> 
> On 2013年10月15日 14:25, Masayuki Igawa wrote:
> 
> 
>   Hi, 
>   
>   First, thank you to an anonymous for updating this list!
>   -> GET /{project_id}/servers/:server_id/diagnostics
>   
>   And, I have updated: Nova API List for Missing Tempest Tests.
> 
> https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc
>   
>   The summary of this list:
>   different count from
>   Tested or not # of APIs ratio   the last time
>   ---
>   Tested API  124  49.6%  +2
>   Not Tested API   66  26.4%  -2
>   Not Need to Test(*1) 60  24.0%   0
>   ---
>   Total(*2):  250 100.0%   0
>   (*1) Because they are deprecated APIs such as nova-network and volume.
>   (*2) not included v3 APIs
>   
>   The tempest version is:
>commit f55f4e54ceab7c6a4d330f92c8059e46233e3560
>Merge: 86ab238 062e30a
>Author: Jenkins  
>  
>Date:   Mon Oct 14 15:55:59 2013 +
>   
>   By the way, I saw a design summit proposal related to this topic(*3). I 
> think
>   this information should be generated automatically. So I'd like to talk 
> about
>   this topic at the summit session.
>   (*3) Coverage analysis tooling: 
> http://summit.openstack.org/cfp/details/171
>   
>   This information would be useful for creating Tempest tests.
>   Any comments/questions/suggestions are welcome.
>   
>   Best Regards,
>   -- Masayuki Igawa
>   
>   
> 
>   Hi,
>   
>   # I'm sorry for this resending because my last mail has 
> unnecessary messages.
>   
>   
>   I have updated: Nova API List for Missing Tempest Tests.
>
> https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc
>   
>   The summary of this list:
>   different count from
>   Tested or not# of APIs  ratio   the last time
>   ---
>   Tested API  122  48.8%  +5
>   Not Tested API   68  27.2%  -5
>   Not Need to Test(*1) 60  24.0%   0
>   ---
>   Total(*2):  250 100.0%   0
>   
>   (*1) Because they are deprecated APIs such as nova-network and 
> volume.
>   (*2) not included v3 APIs
>   
>   I hope this information would be helpful for creating Tempest 
> tests.
>   Any comments and questions are welcome.
>   
>   Best Regards,
>   -- Masayuki Igawa
>   
>   
> 
>   Hi, Tempest developers
>   
>   I have made:
>Nova API List for Missing Tempest Tests.
>
> https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc
>   
>   This list shows what we should test. That is:
>* Nova has 250 APIs(not include v3 APIs).
>* 117 APIs are executed(maybe tested)

[openstack-dev] [qa] Update: Nova API List for Missing Tempest Tests

[Masayuki Igawa]

Hi,

Thanks many guys for updating this list!

And, I have updated: Nova API List for Missing Tempest Tests.
  
https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc

The summary of this list:
different count from
Tested or not # of APIs ratio   the last time
---
Tested API  126  50.4%  +2
Not Tested API(*1)   64  25.6%  -2
Not Need to Test(*2) 60  24.0%   0
---
Total(*3):  250 100.0%   0
(*1) included 9 Doings
(*2) Because they are deprecated APIs such as nova-network and volume.
(*3) not included v3 APIs

The tempest version is:
-
  commit 7ca13ed9daa710cbe1ac348cb903ffada4f8f6d2
  Merge: 66ff406 72d7d5b
  Author: Jenkins 
  Date:   Mon Oct 21 04:29:49 2013 +

  Merge "add test for updating server's disk_config test"
-

This information would be useful for creating Tempest tests.
Any comments/questions/suggestions are welcome.

And if you notice any mistakes on this list, feel free to correct/update it 
please.

Best Regards,
-- Masayuki Igawa


> Hi, 
> 
> First, thank you to an anonymous for updating this list!
> -> GET /{project_id}/servers/:server_id/diagnostics
> 
> And, I have updated: Nova API List for Missing Tempest Tests.
>   
> https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc
> 
> The summary of this list:
>   different count from
> Tested or not # of APIs   ratio   the last time
> ---
> Tested API124  49.6%  +2
> Not Tested API 66  26.4%  -2
> Not Need to Test(*1)   60  24.0%   0
> ---
> Total(*2):250 100.0%   0
> (*1) Because they are deprecated APIs such as nova-network and volume.
> (*2) not included v3 APIs
> 
> The tempest version is:
>  commit f55f4e54ceab7c6a4d330f92c8059e46233e3560
>  Merge: 86ab238 062e30a
>  Author: Jenkins 
>  Date:   Mon Oct 14 15:55:59 2013 +
> 
> By the way, I saw a design summit proposal related to this topic(*3). I think
> this information should be generated automatically. So I'd like to talk about
> this topic at the summit session.
> (*3) Coverage analysis tooling: http://summit.openstack.org/cfp/details/171
> 
> This information would be useful for creating Tempest tests.
> Any comments/questions/suggestions are welcome.
> 
> Best Regards,
> -- Masayuki Igawa
> 
> 
> > Hi,
> > 
> > # I'm sorry for this resending because my last mail has unnecessary 
> > messages.
> > 
> > 
> > I have updated: Nova API List for Missing Tempest Tests.
> >  
> > https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc
> > 
> > The summary of this list:
> > different count from
> > Tested or not# of APIs  ratio   the last time
> > ---
> > Tested API  122  48.8%  +5
> > Not Tested API   68  27.2%  -5
> > Not Need to Test(*1) 60  24.0%   0
> > ---
> > Total(*2):  250 100.0%   0
> > 
> > (*1) Because they are deprecated APIs such as nova-network and volume.
> > (*2) not included v3 APIs
> > 
> > I hope this information would be helpful for creating Tempest tests.
> > Any comments and questions are welcome.
> > 
> > Best Regards,
> > -- Masayuki Igawa
> > 
> > 
> > > Hi, Tempest developers
> > > 
> > > I have made:
> > >  Nova API List for Missing Tempest Tests.
> > >  
> > > https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc
> > > 
> > > This list shows what we should test. That is:
> > >  * Nova has 250 APIs(not include v3 APIs).
> > >  * 117 APIs are executed(maybe tested).
> > >  * 73 APIs are not executed.
> > >  * 60 APIs are not executed. But they maybe not need to test.
> > >  -> Because they are deprecated APIs such as nova-network and volume.
> > > 
> > > So I think we need more tempest test cases.
> > > If this idea is acceptable, can you put your name to 'assignee' at your 
> > > favorites,
> > > and implement tempest tests.
> > > 
> > > Any comments are welcome.
> > > 
> > > Additional information:
> > >  I made this API list with modification of nova's code that based on 
> > >  https://review.openstack.org/#/c/25882/ (Abandoned).
> > > 
> > > Best Regards,
> > > -- Masayuki Igawa
> > > 
> > > 
> > 
> > 
> 
> 
> 


smime.p7s
Description: S/MIME cryptographic signature
_

[openstack-dev] [Sheepdog Announcement] Erasure coding is fully functional with Sheepdog now

[Liu Yuan]

Hello all,

Apologies if this mail sounds annoying to you.

Sheepdog is a distributed object storage system for QEMU VM and RESTful 
services (in progress).

Openstack users can make use of Sheepdog as Cinder and Glance storage as of now 
and Swift compatitable API is working in progress.

Yuan will introduce sheepdog in the openstack Hong Kong summit and slides are
already available at
http://www.slideshare.net/multics/sheepdog-yet-another-all-inone-storage-for-openstack-27402520

You can see more info about this talk at
http://openstacksummitnovember2013.sched.org/event/706dc3952a8917aa74998e047d015e6a#.UmZnNYYW31E

Erasure coding is now seamlessly functional with all other features such as
snapshot/clone/cluster-wide snapshot/multi-disk/auto-healing e.c with following
characteristics:

1 Data is erasure coded automatically while being written to sheepdog storage, 
no extra operations.
2 Support random read/write, in-place-update, misaligned read/write
3 Support to run any type VM images or attach as a vdisk of a VM
4 User-defined coding scheme on a VDI basis
5 Better read/write performance compared to fully replication scheme
6 A single cluster can both support replicated VDI or erasure-coded VDI

You can get more info at

https://github.com/sheepdog/sheepdog/wiki for a general wiki
https://github.com/sheepdog/sheepdog/wiki/Erasure-Code-Support for erasure 
coding

Anyone who is interested can give it a try if you are confortable with command
line:

 $ git clone https://github.com/sheepdog/sheepdog.git

For a 10 minutes quick start with a single machine, you can try:
(Assume you are debian based system)

# Compile from the source

 $ sudo apt-get install liburcu-dev
 $ git clone git://github.com/sheepdog/sheepdog.git
 $ cd sheepdog
 $ ./autogen.sh; ./configure --disable-corosync
 $ make; sudo make install

# Create a 6 node cluster with local driver
 $ for i in `seq 0 5`; do sheep /tmp/store$i -n -c local -z $i -p 700$i;done
 $ dog cluster format

# Create a replicated thin-provisioned 20G volume with 3 copies
 $ dog vdi create -c 3 replica 20G
 $ dog vdi list # show vdi list
 $ dog node info # show node information
 $ dog cluster info # show cluster infomation

# Create a erasure-coded (4 data strips and 2 parity strips) 20G volume
 $ dog vdi create -c 4:2 erasure 20G

# Now you should have 2 vdi created
 $ dog vdi list

# You can install OS on these volumes with upstream QEMU
 $ qemu-system-x86_64 -m 1024 --enable-kvm \
   -drive file=sheepdog:erasure,if=virtio -cdrom path_to_your_iso

# or attach the volumes with existant VM
 $ qemu-system-x86_64 -m 1024 --enable-kvm \
   -drive file=your_image,if=virtio -drive file=sheepdog:erasure,if=virtio

# Take a live disk-only snapshot of running VM
 $ dog vdi snapshot -s tag erasure

# Mount the volume(vdi) to local storage file system
 $ sheepfs dir
 $ echo erasure > dir/vdi/mount
# then you can do whatever with the mounted file at dir/vdi/volume/erasure

Have fun

And feedbacks are always welcome.

Thanks
Yuan

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] openstack-dev][nova][neturon] NoopFirewallDriver lead nova boot/show/list failure.

[Bence Romsics]

Hi Eric,

Instead of the new patch you may consider reverting an old one:
https://review.openstack.org/#/c/23160/
https://bugs.launchpad.net/neutron/+bug/1124117

IMHO there's some confusion in bug #1124117 and in the patch in review
#23160 about how a noop driver is expected to work. I believe a noop driver
should look like it is present (in the list of available extensions), but
does nothing. The patch in review #23160 believes an other way and makes
the noop driver look like as if it wasn't even present. Which may lead to
your current bug.

Best regards,
Bence Romsics


On Sat, Oct 19, 2013 at 10:09 AM, Chang Bo Guo  wrote:

> Hi ALL,
>
> There is bug https://bugs.launchpad.net/python-neutronclient/+bug/1232965.
>
> When set "firewall_driver = neutron.agent.firewall.NoopFirewallDriver" in 
> /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini
> ,
> Nova operations (list/show/boot) will fail. due to Nuetron client raises
>  NotFound security_group exception. I submit a patch for Nova to fix nova
> show/list failure. See https://review.openstack.org/#/c/52597/
>
> My question is , which side (Neutron, NeutronClient ,Nova) should fix this
> , what's the best solution , current I just catch the exception and return
> empty list of security_group .
>
> Any thoughts ?
>
> Best Regards
> ---
> Eric Guo  郭长波
> Cloud Solutions and Openstack Development
> China System & Technology Laboratories (CSTL), IBM
> Tel:86-10-82452019
> Internet Mail: guoc...@cn.ibm.com
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Merge multiple OVS bridges ?

[Kyle Mestery (kmestery)]

On Oct 22, 2013, at 2:21 AM, Gopi Krishna B  wrote:

> Hi
> Currently in Neutron the integration bridge (br-int) and other bridges 
> configured over each physical nic (e.g. br-eth0, br-eth1 etc) are being 
> configured in Compute and Network nodes. What is the logic behind or 
> advantages having 2 OVS bridges in the physical host?
> Can we have only one bridge for each physical NIC, similar to what linux 
> bridge setup has. And configure/modify the flows such that VLAN conversion is 
> appropriately setup for ingress and egress traffic within the single bridge.
> Thus also eliminating the veth pairs used to connect the bridges together.
> Is this a feasible proposal, and can it be worked on?
> 
Sure, please file a blueprint and submit a patch for this, I would review this 
for sure! :)

There are optimizations underway around this area. For example, we're looking 
at possibly collapsing the individual Linuxbridge and OVS agents into a single 
agent. In the context of ML2, this makes sense. I've thought a bit about 
collapsing the bridges from two to one and this is something which seems quite 
doable frankly.

Thanks,
Kyle


> -- 
> Regards
> Gopi Krishna
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Error while executing 'git review'

[S Sridhar]

Hi All,
I worked on bug # 1176683 and fixed it. Commit is successful.
sridhar@ubuntu:~/repo/neutron$ git status # On branch bug_id_1176683nothing to 
commit (working directory clean)sridhar@ubuntu:~/repo/neutron$
But getting following error while posting for review.
sridhar@ubuntu:~/repo/neutron$ git reviewremote: Resolving deltas: 100% 
(4/4)remote: Processing changes: refs: 1, doneTo 
ssh://saggezz...@review.openstack.org:29418/openstack/neutron.git ! [remote 
rejected] HEAD -> refs/for/master/bug/1176683 (change 52949 closed)error: 
failed to push some refs to 
'ssh://saggezz...@review.openstack.org:29418/openstack/neutron.git'sridhar@ubuntu:~/repo/neutron$
 
Could anyone help in resolving this issue ?
RegardsSridhar___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [UX] OpenStack UX tools - up and running

[Jaromir Coufal]

Dear OpenStack UX community,

Anybody who is interested in UX work on OpenStack, I would like to 
invite you to join OpenStack UX Askbot tool:


http://ask-openstackux.rhcloud.com
(you can use log through launchpad)

Together with that, I managed to deploy and setup few other tools for 
us, so we can better organize the whole UX work and make it more 
transparent to all contributors.


1) Firstly, I created *Launchpad for OpenStack UX* [0]. I prefilled it 
with several blueprints which were already discussed earlier. Each entry 
contains prefix with project name, where it is targeted.
2) With jomara's help I managed to get running deployment of *OpenStack 
UX Askbot* [1] as mentioned above. It is on temporary address for now, 
but it's working :) If we want to move forward, not to wait very long, 
we need to be on temporary location (openshift) and after official 
deployment on OpenStack servers is done, we can relocate permanently.

3) IRC channel *#openstack-ux on FreeNode*.
3) Ongoing question is about *git repository*, which I am going to work on.

My vision of using above mentioned tools together is following:
* In Launchpad, I would like us to track blueprints and bugs - planning, 
keeping track on ongoing work and improve our organization in general.
* Cooperate on each topic on AskBot. There we can analyze, discuss ideas 
and design solutions together with whoever is interested in that issue, 
so we have focused groups and we can come to final solutions. Also 
anybody can raise various ideas, proposals, issues etc. there. I hope it 
will become a place where we all meet and discussed UX topics.
* Propose solutions at gerrit and do final check before merging to our 
documents repository there (+2+2 principle).

* Real time communication on IRC channel.

Thank you all for your hard work so far.

Cheers
-- Jarda


[0] https://launchpad.net/openstack-ux
[1] http://ask-openstackux.rhcloud.com (temporary address)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)

[Zane Bitter]

On 21/10/13 19:45, Thomas Goirand wrote:

On 10/20/2013 09:00 PM, Jeremy Stanley wrote:

On 2013-10-20 22:20:25 +1300 (+1300), Robert Collins wrote:
[...]

OTOH registering one's nominated copyright holder on the first
patch to a repository is probably a sustainable overhead. And it's
probably amenable to automation - a commit hook could do it locally
and a check job can assert that it's done.


I know the Foundation's got work underway to improve the affiliate
map from the member database, so it might be possible to have some
sort of automated job which proposes changes to a copyright holders
list in each project by running a query with the author and date of
each commit looking for new affiliations. That seems like it would
be hacky, fragile and inaccurate, but probably still more reliable
than expecting thousands of contributors to keep that information up
to date when submitting patches?


My request wasn't to go *THAT* far. The main problem I was facing was
that troveclient has a few files stating that HP was the sole copyright
holder, when it clearly was not (since I have discussed a bit with some
the dev team in Portland, IIRC some of them are from Rackspace...).

Just writing HP as copyright holder to please the FTP masters because it
would match some of the source content, then seemed wrong to me, which
is why I raised the topic. Also, they didn't like that I list the
authors (from a "git log" output) in the copyright files.


Can't we just write "Copyright OpenStack Contributors"? (Where 
'contributors' means individuals or organisations who have signed the 
CLA.) As others have pointed out, this is how other large projects 
handle it.


It's not that knowing the copyright holders isn't important - it *is* 
important because the licence is meaningless unless granted/permitted by 
the actual copyright holders. But the actual individual names are 
irrelevant to Debian. Gerrit ensures that only OpenStack Contributors 
(those that have signed the CLA) can contribute to OpenStack, and 
contributors declare via the CLA that they have the legal right to 
licence the code (which is the best that you can do here). The paper 
trail is complete, everybody should be happy.



So, for me, the clean and easy way to fix this problem is to have a
simple copyright-holder.txt file, containing a list of company or
individuals. It doesn't really mater if some entities forget to write
themselves in. After all, that'd be their fault, no? The point is, at
least I'd have an upstream source file to show to the FTP masters as
something which has a chance to be a bit more accurate than
second-guessing through "git log" or reading a few source code files
which represent a wrong view of the reality.


This seems like an orthogonal question, but if we're going to relitigate 
it then I remain +1 on maintaining it in one file per project as you 
suggest, and -10 on trying to maintain it in every single source file. 
Not because that would be inaccurate - though clearly it would be worse 
than useless in terms of accuracy - but because it would add a whole 
layer of overhead that's as annoying as it is pointless.


cheers,
Zane.



Any thoughts?

Thomas Goirand (zigo)

P.S: I asked the FTP masters to write in this thread, though it seems
nobody had time to do so...



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Error while executing 'git review'

[Subramanian]

Looks like a change id conflict with https://review.openstack.org/#/c/52949.
You are letting "git review" auto generate the change id right? For this
case you could try "git commit --amend", remove the change id line if it
matches the change id from this review and then run "git review" again. HTH.

- Subbu


On Tue, Oct 22, 2013 at 6:34 PM, S Sridhar  wrote:

> Hi All,
>
> I worked on bug # 1176683 and
> fixed it. Commit is successful.
>
> sridhar@ubuntu:~/repo/neutron$ git status
> # On branch bug_id_1176683
> nothing to commit (working directory clean)
> sridhar@ubuntu:~/repo/neutron$
>
> But getting following error while posting for review.
>
> sridhar@ubuntu:~/repo/neutron$ git review
> remote: Resolving deltas: 100% (4/4)
> remote: Processing changes: refs: 1, done
> To ssh://saggezz...@review.openstack.org:29418/openstack/neutron.git
>  ! [remote rejected] HEAD -> refs/for/master/bug/1176683 (change 52949
> closed)
> error: failed to push some refs to 'ssh://
> saggezz...@review.openstack.org:29418/openstack/neutron.git'
> sridhar@ubuntu:~/repo/neutron$
>
> Could anyone help in resolving this issue ?
>
> Regards
> Sridhar
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] HOT Software configuration proposal

[Zane Bitter]

On 22/10/13 09:15, Thomas Spatzier wrote:

BTW, the convention of properties being input and attributes being output,
i.e. that subtle distinction between properties and attributes is not
really intuitive, at least not to me as non-native speaker, because I used
to use both words as synonyms.


As a native speaker, I can confidently state that it's not intuitive to 
anyone ;)


We unfortunately inherited these names from the Properties section and 
the Fn::GetAtt function in cfn templates. It's even worse than that, 
because there's a whole category of... uh... things (DependsOn, 
DeletionPolicy, &c.) that don't even have a name - I always have to 
resist the urge to call them 'attributes' too.


- ZB

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] openstack-dev][nova][neturon] NoopFirewallDriver lead nova boot/show/list failure.

[Akihiro Motoki]

Hi,

Thank you for moving it to the mailing list.

>> Nova operations (list/show/boot) will fail. due to Nuetron client raises
>> NotFound security_group exception. I submit a patch for Nova to fix nova
>> show/list failure. See https://review.openstack.org/#/c/52597/

Regarding on this point, security group extension is not supported by
some Neutron plugins
and I think it is some kind of configuration issues.

IMO it is better to keep raising an exception (or at least ERROR level
log should be recorded)
to find this kind of configuration mismatch.
If neutron plugin does not support security group extension,
security_group_driver in nova.conf should be "nova".
IMO, similarly if NoopFirewallDriver is used in neutron agent, Neutron
security group does nothing
and security_group_driver in nova.conf should be "nova" to make
security group work.

An alternative is to change nova security group driver to check if
security group extension is enabled in Neutron
and if it is not supported not to issue API calls to Neutron related
to security group.

I think both approaches should work even after nova-network is removed
(in the future).

> IMHO there's some confusion in bug #1124117 and in the patch in review
> #23160 about how a noop driver is expected to work. I believe a noop driver
> should look like it is present (in the list of available extensions), but
> does nothing. The patch in review #23160 believes an other way and makes the
> noop driver look like as if it wasn't even present. Which may lead to your
> current bug.

When firewall_driver is set to NoopFirwallDriver in Neutron agent,
uses can create security group and its rules, but no packet filtering
is enforced.
If neutron security group is enabled, users should expect packet
filtering is enabled
I think this behavior is confusing from Neutron API perspective,
and if no packet filtering is enforced, we cannot say security group
feature is provided.
This is the background of the change.

On the other hand, we can consider NoopFirewallDriver means just
packet filtering is disabled.
I understand there is a need to disable security group completely for
debugging or some cases.
(Nova security group implementation takes this approach, but it is not
a reason.)

When we discuss this topic, we need to consider it from the two views:
API perspective and agent behavior perspective.
When I wrote the patch, my vote was to keep consistent between API
level and its actual behavior,
but I am open to the community consensus.

Which is better or is there any alternative?

Thanks,
Akihiro

On Tue, Oct 22, 2013 at 9:29 PM, Bence Romsics  wrote:
> Hi Eric,
>
> Instead of the new patch you may consider reverting an old one:
> https://review.openstack.org/#/c/23160/
> https://bugs.launchpad.net/neutron/+bug/1124117
>
> IMHO there's some confusion in bug #1124117 and in the patch in review
> #23160 about how a noop driver is expected to work. I believe a noop driver
> should look like it is present (in the list of available extensions), but
> does nothing. The patch in review #23160 believes an other way and makes the
> noop driver look like as if it wasn't even present. Which may lead to your
> current bug.
>
> Best regards,
> Bence Romsics
>
>
> On Sat, Oct 19, 2013 at 10:09 AM, Chang Bo Guo  wrote:
>>
>> Hi ALL,
>>
>> There is bug https://bugs.launchpad.net/python-neutronclient/+bug/1232965.
>>
>> When set "firewall_driver = neutron.agent.firewall.NoopFirewallDriver" in
>> /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini ,
>> Nova operations (list/show/boot) will fail. due to Nuetron client raises
>> NotFound security_group exception. I submit a patch for Nova to fix nova
>> show/list failure. See https://review.openstack.org/#/c/52597/
>>
>> My question is , which side (Neutron, NeutronClient ,Nova) should fix this
>> , what's the best solution , current I just catch the exception and return
>> empty list of security_group .
>>
>> Any thoughts ?
>>
>> Best Regards
>> ---
>> Eric Guo  郭长波
>> Cloud Solutions and Openstack Development
>> China System & Technology Laboratories (CSTL), IBM
>> Tel:86-10-82452019
>> Internet Mail: guoc...@cn.ibm.com
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] HOT Software configuration proposal

[Lakshminaraya Renganarayana]

Zane Bitter  wrote on 10/22/2013 09:24:28 AM:

>
> On 22/10/13 09:15, Thomas Spatzier wrote:
> > BTW, the convention of properties being input and attributes being
output,
> > i.e. that subtle distinction between properties and attributes is not
> > really intuitive, at least not to me as non-native speaker, because I
used
> > to use both words as synonyms.
>
> As a native speaker, I can confidently state that it's not intuitive to
> anyone ;)
>
> We unfortunately inherited these names from the Properties section and
> the Fn::GetAtt function in cfn templates. It's even worse than that,
> because there's a whole category of... uh... things (DependsOn,
> DeletionPolicy, &c.) that don't even have a name - I always have to
> resist the urge to call them 'attributes' too.

At least for the components construct being proposed (by Steve Baker),
shall we adopt a more explicit convention and require component definitions
to explicitly name their inputs and outputs?

Thanks,
LN___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] [qa] Ceilometer ERRORS in normal runs

[Mehdi Abaakouk]

Hi,

On Mon, Oct 21, 2013 at 02:27:44PM +, Neal, Phil wrote:
> 
> https://blueprints.launchpad.net/tempest/+spec/basic-tempest-integration-for-ceilometer

Some works have been done behind an other blueprint: 

https://blueprints.launchpad.net/tempest/+spec/add-basic-ceilometer-tests

Most of this code have been written since a while, and need to be
rebased. And some other have showed bugs in ceilometer.

Bugs discovered with gate already have fixed in gerrit, and should be merged 
soon.

> > -Original Message-
> > From: Sean Dague [mailto:s...@dague.net]
> > Sent: Sunday, October 20, 2013 7:39 AM
> > To: OpenStack Development Mailing List
> > 
> > Ceilometer is currently one of the largest offenders in dumping ERRORs
> > in the gate -
> > http://logs.openstack.org/68/52768/1/check/check-tempest-devstack-vm-
> > full/76f83a4/console.html#_2013-10-19_14_51_51_271
> > (that item isn't in our whitelist yet, so you'll see a lot of it at the
> > end of every run)
> > 
> > and
> > http://logs.openstack.org/68/52768/1/check/check-tempest-devstack-vm-
> > full/76f83a4/logs/screen-ceilometer-collector.txt.gz?level=TRACE
> > for full details

I have planned to take a look on this, this week.

Regards, 

-- 
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht


signature.asc
Description: Digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack][Swift] how does swift update obj count of container or account?

[Alex Yang]

I think you can try it again with a clean environment.


2013/10/22 Gareth 

>
>
>
> On Tue, Oct 22, 2013 at 5:33 PM, Alex Yang  wrote:
>
>> Hi Gareth:
>>
>> The process of update object count to container db is synchronized. After
>> the DiskFile finish writing the data to disk, the object-server will make a
>> request to container servers and update the object count. If the request
>> failed, the request will be serialized on the disk, and the object-update
>> will update it to container servers asynchronously.
>>
>> The process of update object count from container db to account db is
>> asynchronized. The container-updater will loop all the container db files
>> in disk and update the object count the account servers
>>
>
> If I start my services like "swift-init main start"(container-updater will
> not be launched), the obj-count of account will be 0? for the reason that
> no container-updater reports data to account.
> But the truth is not that. The obj-count of account and container is
> correct in most of simple cases.
>
>
>>
>>
>>
>> 2013/10/22 Gareth 
>>
>>> Hi
>>>
>>> How does Swift update container object count or account object count
>>> after PUT an object? Counting per request or something else?
>>>
>>> --
>>> Gareth
>>>
>>> *Cloud Computing, OpenStack, Fitness, Basketball*
>>> *OpenStack contributor*
>>> *Company: UnitedStack *
>>> *My promise: if you find any spelling or grammar mistakes in my email
>>> from Mar 1 2013, notify me *
>>> *and I'll donate $1 or ￥1 to an open organization you specify.*
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>>   杨雨
>>   Email:   alex890...@gmail.com
>> GitHub:   https://github.com/AlexYangYu
>>  Weibo:   http://www.weibo.com/alexyangyu
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Gareth
>
> *Cloud Computing, OpenStack, Fitness, Basketball*
> *OpenStack contributor*
> *Company: UnitedStack *
> *My promise: if you find any spelling or grammar mistakes in my email
> from Mar 1 2013, notify me *
> *and I'll donate $1 or ￥1 to an open organization you specify.*
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
  杨雨
  Email:   alex890...@gmail.com
GitHub:   https://github.com/AlexYangYu
 Weibo:   http://www.weibo.com/alexyangyu
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] [qa] Ceilometer ERRORS in normal runs

[Sean Dague]

On 10/21/2013 10:27 AM, Neal, Phil wrote:

Sean, we currently have a BP out there to investigate basic tempest
integration and I think this might fall under the same umbrella.
Unfortunately I've not been able to free up my development time
for it, but I've assigned it out to someone who can take a look and
report back.

https://blueprints.launchpad.net/tempest/+spec/basic-tempest-integration-for-ceilometer


This is kind of worse than tempest integration issues. As far as I can 
tell ceilometer via devstack is basically non functional at all. And 
sort of worse than non functional, it's spewing errors, a lot.


This really ought to be a top ceilometer item to address, otherwise we 
should probably turn off celiometer in devstack by default, because it's 
really not working at the moment.


-Sean

--
Sean Dague
http://dague.net

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Fwd: Secure live VM migration in cloud (openstack)

[Naveed Ahmad]

Hi,

I need some assistance.  i am very confused in one thing of Openstack. How
it manages VM's . i mean to say where i can find all files related to
single VM . i have Vbox on my system and in the VM main folder i have 3
files and 1 folder. I have attached snapshot of it.

How can i see those files for VM in Openstack. I know it uses XEN/KVM
hypervisor but where it store the VM all related files.

I tried to find it on Openstack but no success yet.

I would be very thankful to you

Regards
Naveed








On Wed, Oct 2, 2013 at 12:02 AM, Joshua Harlow wrote:

>  Sure, I'd like to hear about it :)
>
>   From: Naveed Ahmad <12msccsnah...@seecs.edu.pk>
> Date: Tuesday, October 1, 2013 11:22 AM
>
> To: Joshua Harlow 
> Subject: Re: [openstack-dev] Secure live VM migration in cloud (openstack)
>
>Hi
>  Respected Sir,
>
>  Hopefully you will be fine. previously i discussed with you about my
> thesis.  can i share with you flow of secure live vm migration process w r
> t cloud . i almost completed the design that i will implement in
> libvirt/openstack.
>
>
>  Regards
>
>
>
>
> On Tue, Aug 27, 2013 at 11:12 AM, Naveed Ahmad <12msccsnah...@seecs.edu.pk
> > wrote:
>
>>
>>  Sir i have seen openstack code yet and you are right , it is possible
>> with nova. i will update you soon about my plan.
>>
>>  Thanks for sharing useful links and thanks for nice discussion.
>>
>>
>>  Regards
>>
>>
>>
>>
>>
>>
>> On Tue, Aug 27, 2013 at 9:29 AM, Joshua Harlow wrote:
>>
>>>  Cool, so are u thinking about doing most of this at the openstack code
>>> level then or at the libvirt level??
>>>
>>>  I could see it being possible to do this in nova itself, or at a lower
>>> level in libvirt.
>>>
>>>  U might be interested in a wiki I made a while ago @
>>> https://wiki.openstack.org/wiki/LiveMigrationWorkflows
>>>
>>>  It might not be fully accurate, but u can likely determine the places
>>> u would need to change from that.
>>>
>>>  Also https://blueprints.launchpad.net/nova/+spec/unified-migrations might
>>> be interesting to u.
>>>
>>>   From: Naveed Ahmad <12msccsnah...@seecs.edu.pk>
>>> Date: Monday, August 26, 2013 9:04 PM
>>> To: Joshua Harlow 
>>>
>>> Subject: Re: [openstack-dev] Secure live VM migration in cloud
>>> (openstack)
>>>
>>>Respected  Joshua Harlow,
>>>
>>>  no i did not talk with libvirt team. but i have seen feature list of
>>> libvirt only and documentation of openstack.
>>>
>>>  Regards
>>>
>>>
>>>
>>> On Tue, Aug 27, 2013 at 2:58 AM, Joshua Harlow 
>>> wrote:
>>>
  Hi,

  Those ideas sounds pretty good to me. Although I'm not an expert in
 the security area, have u talked with the libvirt folks. I wonder if they
 have any of this planned?

   From: Naveed Ahmad <12msccsnah...@seecs.edu.pk>
 Reply-To: OpenStack Development Mailing List <
 openstack-dev@lists.openstack.org>
 Date: Monday, August 26, 2013 11:10 AM
 To: OpenStack Development Mailing List <
 openstack-dev@lists.openstack.org>
 Subject: Re: [openstack-dev] Secure live VM migration in cloud
 (openstack)

 Respected Joshua Harlow,

  Thanks for reply,

  Based on literature survey i found that following techniques are used
 for secure live migration of vm.

  1. RSA with SSL protocol for authentication and encryption.
 As you mentioned earlier same problem is in RSA based authentication.
 we have to add public keys of all other hypervisors.

  In Blackhat 2013, security research found vulnerability in SSL so it
 can be breakable in very short time.
  please check

 http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/

  2. SSH is used for secure tunnel before live vm migration.

  Authentication is not discussed, only secure tunnel is used to
 achieve  confidentiality.

  3. Openstack uses libvirtd with kvm to provide secure vm migration
 between src and dst machine.
  SSL is used for encrypted channel and SASL  is used for
 authentication.



  so i am interested to implement authentication level's in live vm
 migration.

  1.no authentication
  2. Certificate base
  3.smart card based authentication

  and similarly ssl provide secure channel but after that seaprate VLAN
 is used for vm migration traffic. if we use ipsec then we can achieve same
 goal on network layer to hide all communication of vm migration.



  Regards
  Naveed









 On Mon, Aug 26, 2013 at 2:44 AM, Joshua Harlow 
 wrote:

>  Arg, hit send to quick.
>
>  *likely these problems would require some managed migration "thing"
> that would temporarily open the network access, issue temporary auth keys
> and the initiate the migration between the 2 hypervisors. Is this in your
> scope, to make this thing??
>>>

Re: [openstack-dev] CLA (was: Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects)

[Jeremy Stanley]

(Disclaimers: I am not a lawyer, which likely explains my lack of
interest in perversely pointless paperwork. Also, these opinions are
my own and do not necessarily reflect those of my employer. Setting
MFT to legal-discuss as a more appropriate forum for these sorts of
discussions.)

On 2013-10-22 15:11:25 +0200 (+0200), Zane Bitter wrote:
[...]
> Can't we just write "Copyright OpenStack Contributors"? (Where
> 'contributors' means individuals or organisations who have signed
> the CLA.)
[...]

Actually, technically not. There are other avenues through which
patches come (posts on mailing lists, attachments to bugs) and I
know that from time to time contributors git-am other authors' bug
fixes without first asking them to go agree to an OpenStack CLA and
prove that they have done so. The actual copyright belongs with the
author (or their employer under a work-for-hire agreement), not the
contributor who uploaded that work--and they aren't necessarily
always the same people.

> Gerrit ensures that only OpenStack Contributors (those that have
> signed the CLA) can contribute to OpenStack
[...]

To echo Monty's sentiments earlier in the thread, and also as the
person who spear-headed the current CLA enforcement configuration in
our project's Gerrit instance, I don't see how our CLAs add anything
of value. It's patronizing, almost insulting, to ask developers to
pinky-swear that they're authorized to license the code they
contribute under the license included with the code they contribute.
At best it may provide a warm fuzzy feeling for companies who are
unfamiliar with contributing to free software projects, since free
software licenses are all about waiving your rights rather than
enforcing them and that might sound scary to the uninitiated... but
better efforts toward educating them about free software may prove
more productive than relying on a legal security blanket.

Also as mentioned above, Gerrit does not enforce that the copyright
holder has agreed to this, it only enforces that the person
*uploading* the code into Gerrit has agreed to it... and section 7
of the ICLA has some interesting things to say about submitting
third-party contributions, which looks to me like a permitted
loophole for getting ASL code into the project without the author
directly agreeing to a CLA at all.

> > 7. Should You wish to submit work that is not Your original
> > creation, You may submit it to the Project Manager separately
> > from any Contribution, identifying the complete details of its
> > source and of any license or other restriction (including, but
> > not limited to, related patents, trademarks, and license
> > agreements) of which you are personally aware, and conspicuously
> > marking the work as "Submitted on behalf of a third-party:
> > [named here]".

I wonder if the current de facto practice of allowing git's author
header to reflect the identity of the third-party counts as a
conspicuous mark for the purposes of ICLA section 7? And whether
submitting it to Gerrit where it can be openly inspected by the
entire project counts as a submission to the Project Manager (the
OpenStack Foundation) as well? At any rate, it seems that the
agreement boils down to "copyright holders promise that they're
contributing code under this license, or that they're submitting
someone else's work who probably is okay with it."
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] HOT Software configuration proposal

[Thomas Spatzier]

Zane Bitter  wrote on 22.10.2013 15:24:28:
> From: Zane Bitter 
> To: openstack-dev@lists.openstack.org,
> Date: 22.10.2013 15:27
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
> On 22/10/13 09:15, Thomas Spatzier wrote:
> > BTW, the convention of properties being input and attributes being
output,
> > i.e. that subtle distinction between properties and attributes is not
> > really intuitive, at least not to me as non-native speaker, because I
used
> > to use both words as synonyms.
>
> As a native speaker, I can confidently state that it's not intuitive to
> anyone ;)

Phew, good to read that ;-)

>
> We unfortunately inherited these names from the Properties section and
> the Fn::GetAtt function in cfn templates. It's even worse than that,
> because there's a whole category of... uh... things (DependsOn,
> DeletionPolicy, &c.) that don't even have a name - I always have to
> resist the urge to call them 'attributes' too.

So is this something we should try to get straight in HOT while we still
have the flexibility?
Regarding properties/attributes for example, to me I would call both just
properties of a resource or component, and then I can write them or read
them like:

components:
  my_component:
type: ...
properties:
  my_prop: { get_property: [ other_component, other_component_prop ] }

  other_component:
# ...

I.e. you write property 'my_prop' of 'my_component' in its properties
section, and you read property 'other_component_prop' of 'other_component'
using the get_property function.
... we can also call them attributes, but use one name, not two different
names for the same thing.

>
> - ZB
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] Tuskar UI L2-Group Creation and Nodes Registering wireframes

[Jaromir Coufal]

Hi everybody,

you can find updated version of workflows for Creating L2-Group and 
Adding New Nodes at new discussion tool for UX:


http://ask-openstackux.rhcloud.com/question/7/tuskar-ui-l2-groups-and-nodes/

For any feedback, please follow the conversation there

Thanks
-- Jarda
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] [qa] Ceilometer ERRORS in normal runs

[David Kranz]

On 10/22/2013 10:19 AM, Sean Dague wrote:

On 10/21/2013 10:27 AM, Neal, Phil wrote:

Sean, we currently have a BP out there to investigate basic tempest
integration and I think this might fall under the same umbrella.
Unfortunately I've not been able to free up my development time
for it, but I've assigned it out to someone who can take a look and
report back.

https://blueprints.launchpad.net/tempest/+spec/basic-tempest-integration-for-ceilometer 



This is kind of worse than tempest integration issues. As far as I can 
tell ceilometer via devstack is basically non functional at all. And 
sort of worse than non functional, it's spewing errors, a lot.


This really ought to be a top ceilometer item to address, otherwise we 
should probably turn off celiometer in devstack by default, because 
it's really not working at the moment.


-Sean

Here are the two errors showing up persistently that are not 
whitelisted. Such log errors are now being shown in the console log 
right after the tempest tests finish.


https://bugs.launchpad.net/ceilometer/+bug/1243251
2013-10-21 21:11:00.229 | 2013-10-21 21:05:20.046 5624 ERROR 
ceilometer.collector.dispatcher.database [-] Failed to record metering 
data: QueuePool limit of size 5 overflow 10 reached, connection timed 
out, timeout 30



https://bugs.launchpad.net/ceilometer/+bug/1243249
2013-10-21 20:22:27.600 | Log File: ceilometer-alarm-evaluator
2013-10-21 20:22:27.600 | 2013-10-21 20:14:33.038 22760 ERROR 
ceilometer.alarm.service [-] alarm evaluation cycle failed


See also https://bugs.launchpad.net/ceilometer/+bug/1237671

 -David


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Hyper-V Meeting Agenda

[Peter Pouliot]

Hi everyone,

In today's meeting we will discuss the following topics.

* Havana Release

* Installer Update

* Puppet updates


Peter J. Pouliot, CISSP
Senior SDET, OpenStack

Microsoft
New England Research & Development Center
One Memorial Drive,Cambridge, MA 02142
ppoul...@microsoft.com | Tel: +1(857) 453 6436

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] [qa] Ceilometer ERRORS in normal runs

[Nadya Privalova]

Hi guys,

I can share my experience with devstack+ceilometer. There is certainly a
problem with MongoDB, because Ceilometer requires more fresh Mongo than
devstack provides. But I didn't experienced problems with SQL.
And just a quick question about testing: are there any plans to test
Ceilometer with different db-backends in devstack? Or do you suggest that
it is not devstack's responsibility?

Thanks,
Nadya


On Tue, Oct 22, 2013 at 6:55 PM, David Kranz  wrote:

> On 10/22/2013 10:19 AM, Sean Dague wrote:
>
>> On 10/21/2013 10:27 AM, Neal, Phil wrote:
>>
>>> Sean, we currently have a BP out there to investigate basic tempest
>>> integration and I think this might fall under the same umbrella.
>>> Unfortunately I've not been able to free up my development time
>>> for it, but I've assigned it out to someone who can take a look and
>>> report back.
>>>
>>> https://blueprints.launchpad.**net/tempest/+spec/basic-**
>>> tempest-integration-for-**ceilometer
>>>
>>
>> This is kind of worse than tempest integration issues. As far as I can
>> tell ceilometer via devstack is basically non functional at all. And sort
>> of worse than non functional, it's spewing errors, a lot.
>>
>> This really ought to be a top ceilometer item to address, otherwise we
>> should probably turn off celiometer in devstack by default, because it's
>> really not working at the moment.
>>
>> -Sean
>>
>>  Here are the two errors showing up persistently that are not
> whitelisted. Such log errors are now being shown in the console log right
> after the tempest tests finish.
>
> https://bugs.launchpad.net/**ceilometer/+bug/1243251
> 2013-10-21 21:11:00.229 | 2013-10-21 21:05:20.046 5624 ERROR
> ceilometer.collector.**dispatcher.database [-] Failed to record metering
> data: QueuePool limit of size 5 overflow 10 reached, connection timed out,
> timeout 30
>
>
> https://bugs.launchpad.net/**ceilometer/+bug/1243249
> 2013-10-21 20:22:27.600 | Log File: ceilometer-alarm-evaluator
> 2013-10-21 20:22:27.600 | 2013-10-21 20:14:33.038 22760 ERROR
> ceilometer.alarm.service [-] alarm evaluation cycle failed
>
> See also 
> https://bugs.launchpad.net/**ceilometer/+bug/1237671
>
>  -David
>
>
>
> __**_
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.**org 
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Tuskar UI - Resource Class Creation Wireframes - updated

[Jaromir Coufal]

We moved the whole conversation to new OpenStack UX discussion tool, 
feel free to follow the thread there:


http://ask-openstackux.rhcloud.com/question/5/tuskar-ui-resource-class-creation/


On 2013/21/10 20:59, Liz Blanchard wrote:

Hi Jarda,

Below you will find my comments and questions on the latest version of 
the Resource Class Creation wireframes.


Please let me know if you have any questions.

Thanks,
Liz
On Oct 16, 2013, at 12:31 PM, Jaromir Coufal > wrote:



Hey folks,

I am sending an updated version of wireframes for Resource Class 
Creation. Thanks everybody for your feedback, I tried to cover most 
of your concerns and I am sending updated version for your reviews. 
If you have any concerns, I am happy to discuss it with you.


http://people.redhat.com/~jcoufal/openstack/tuskar/2013-10-16_tuskar_resource_class_creation_wireframes.pdf


1) Will the user be able to click on any of the wizard steps in the 
menu at the top?


2) There shouldn't be a "Back" button on the first step of the wizard. 
The user will never have an opportunity to go back from here.


3) First class should be selected by default. Especially if the field 
that changes below is just the description.


4) Rather than labeling the class description with the class name, it 
should be "Class Description:".


5) The "Assist" checkbox labeling is confusing. Perhaps "Assist with 
proper halving of resources" would be better?


6) If the user unselects the "Assist" checkbox, it would be great if 
that section could collapse to save space. Alternatively, it would 
reappear if the user selects the checkbox again.


7) How come the user can't click the back button from the 2nd page? It 
looks greyed out like the "Hardware Profile" button.


8) I think we need a clearer design for when a table is empty. Maybe 
even a small message within the table along the lines of "There are 
currently no items."


9) Rather than "Yes" and "No" in the confirmation dialog, I think it 
would make it more clear to the user if the action they were taking is 
used. For example "Start Over" or "Enable Assistant" would be more 
descriptive.


10) Is the Node Profile name going to be reflected in the tab name 
above? If so, it might be nice to fill in the field for "Profile Name" 
to be "Node Profile 1" by default. Then it could change as the user 
changes it in the field.


11) It would be better to name the "Add Row" link more specifically to 
the action. Probably "Add Requirement" in this case.


12) Is the "Associated Images" field supposed to be a drop down? Or 
should there be a Browse button? I'm just wondering why it has the 
helper text "Choose an image".


13) Would the image have an extension associated with it? If so, it 
might be good to show different examples here (Ex. QCOW2, ISO, IMG)


14) Are you sure we should select Nodes to assign to this resource 
class by default? It would be nice to ask some sample users this type 
of thing.


15) I think we can combine the label of "4 Matching Available Nodes" 
and the select action. This way, it would be clear that the user would 
be selecting the 4 matching nodes...


16) The filter/search should be aligned closer to the table that it is 
filtering.


17) Where does the "L2-default_group" name come from in this list?

18) The filter description should probably be shortened to read 
"Current Filter: group 2". Also, I think the number of results might 
make sense to be on a different level. This might start to feel more 
organized if the search/filter control comes down to this level so 
that it's closer to the table.


19) If the user unselects the "Select all available" after filtering, 
it should still unselect all 4 matching nodes. In your example you've 
shown that only 2 of the 4 are unselected and then in screen 29 th 
user is in a weird state where they have unselected all matching 
nodes, but the table still shows that 2 nodes are selected. I think 
instead, it might make sense to have a "Select All/Unselected All" 
action at the table level.




Thanks
-- Jarda
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org 


http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Tempest] Do we need more people reviewing tempest?

[Clint Byrum]

I recently submitted a _tiny_ change to tempest to enable Python3
porting in python-keystoneclient.

https://review.openstack.org/#/c/51736/

It has one +2 now, but 8 days after submitting it is still waiting for
a second +2. It is not special though, there are 59 "waiting on reviewer":

http://russellbryant.net/openstack-stats/tempest-openreviews.html

Do we need to put out a call for more people to do reviews on tempest? Is
the team just temporarily short-handed?

Anyway, tempest is pretty important to OpenStack quality, so it feels
like something we should all be helping with. I'd be happy to carve out
a small bit of my usual review time to do tempest reviews, but I don't
think I can solve the problem with what I can add. Since we all bring
knowledge of the systems being tested, I wonder if all core reviewers
from all projects can commit just a little time to tempest (rather than
just having the core reviewers for tempest be a small team) ?

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] HOT Software configuration proposal

[Zane Bitter]

On 22/10/13 16:35, Thomas Spatzier wrote:

Zane Bitter  wrote on 22.10.2013 15:24:28:

From: Zane Bitter 
To: openstack-dev@lists.openstack.org,
Date: 22.10.2013 15:27
Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal

On 22/10/13 09:15, Thomas Spatzier wrote:

BTW, the convention of properties being input and attributes being

output,

i.e. that subtle distinction between properties and attributes is not
really intuitive, at least not to me as non-native speaker, because I

used

to use both words as synonyms.


As a native speaker, I can confidently state that it's not intuitive to
anyone ;)


Phew, good to read that ;-)



We unfortunately inherited these names from the Properties section and
the Fn::GetAtt function in cfn templates. It's even worse than that,
because there's a whole category of... uh... things (DependsOn,
DeletionPolicy, &c.) that don't even have a name - I always have to
resist the urge to call them 'attributes' too.


So is this something we should try to get straight in HOT while we still
have the flexibility?


Y-yes. Provided that we can do it without making things *more* 
confusing, +1. That's hard though, because there are a number of places 
we have to refer to them, all with different audiences:

 - HOT users
 - cfn users
 - Existing developers
 - New developers
 - Plugin developers

and using different names for the same thing can cause problems. My test 
for this is: if you were helping a user on IRC debug an issue, is there 
a high chance you would spend 15 minutes talking past each other because 
they misunderstand the terminology?



Regarding properties/attributes for example, to me I would call both just
properties of a resource or component, and then I can write them or read
them like:

components:
   my_component:
 type: ...
 properties:
   my_prop: { get_property: [ other_component, other_component_prop ] }

   other_component:
 # ...

I.e. you write property 'my_prop' of 'my_component' in its properties
section, and you read property 'other_component_prop' of 'other_component'
using the get_property function.
... we can also call them attributes, but use one name, not two different
names for the same thing.


IMO inputs (Properties) and outputs (Fn::GetAtt) are different things 
(and they exist in different namespaces), so -1 for giving them the same 
name.


In an ideal world I'd like HOT to use something like get_output_data (or 
maybe just get_data), but OTOH we have e.g. FnGetAtt() and 
attributes_schema baked in to the plugin API that we can't really 
change, so it seems likely to lead to developers and users adopting 
different terminology, or making things very difficult for new 
developers, or both :(


cheers,
Zane.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 & DHCP options for dnsmasq

[Sean M. Collins]

On Tue, Oct 22, 2013 at 08:58:52AM +0200, Luke Gorrie wrote:
> Deutsche Telekom too. We are working on making Neutron interoperate well
> with a service provider network that's based on IPv6. I look forward to
> talking about this with people in Hong Kong :)

I may be mistaken, but I don't see a summit proposal for Neutron, on the
subject of IPv6. Are there plans to have one?

-- 
Sean M. Collins


pgpFNUoI1OtIP.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

[Tim Simpson]

> Are you saying you must have a default version defined to have > 1 active 
> versions?
No, my point was using a default version field in the db rather than also 
picking from active versions may be confusing.


From: Michael Basnight [mbasni...@gmail.com]
Sent: Monday, October 21, 2013 4:04 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Trove] How users should specify a datastore   
type when creating an instance

On Oct 21, 2013, at 1:40 PM, Tim Simpson wrote:

>>> 2. I also think a datastore_version alone should be sufficient since the 
>>> associated datastore type will be implied:
>
>> When i brought this up it was generally discussed as being confusing. Id 
>> like to use type and rely on having a default (or active) version behind the 
>> scenes.
>
> Can't we do both? If a user wants a specific version, most likely they had to 
> enumerate all datastore_versions, spot it in a list, and grab the guid. Why 
> force them to also specify the datastore_type when we can easily determine 
> what that is?

Fair enough.

>
>>> 4. Additionally, in the current pull request to implement this it is 
>>> possible to avoid passing a version, but only if no more than one version 
>>> of the datastore_type exists in the database.
>>>
>>> I think instead the datastore_type row in the database should also have a 
>>> "default_version_id" property, that an operator could update to the most 
>>> recent version or whatever other criteria they wish to use, meaning the 
>>> call could become this simple:
>
>> Since we have determined from this email thread that we have an active 
>> status, and that > 1 version can be active, we have to think about the 
>> precedence of active vs default. My question would be, if we have a 
>> default_version_id and a active version, what do we choose on behalf of the 
>> user? If there is > 1 active version and a user does not specify the 
>> version, the api will error out, unless a default is defined. We also need a 
>> default_type in the config so the existing APIs can maintain compatibility. 
>> We can re-discuss this for v2 of the API.
>
> Imagine that an operator sets up Trove and only has one active version. They 
> then somehow fumble setting up the default_version, but think they succeeded 
> as the API works for users the way they expect anyway. Then they go to add 
> another active version and suddenly their users get error messages.
>
> If we only use the "default_version" field of the datastore_type to define a 
> default would honor the principle of least surprise.

Are you saying you must have a default version defined to have > 1 active 
versions?

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

[Tim Simpson]

> This is also true that we dont want to define the _need_ to have custom 
> images for the datastores. You can, quite easily, deploy mysql or redis on a 
> vanilla image.

Additionally there could be server code at some point soon that will need to 
know what datastore type is associated with an instance to determine what db 
engine is in use. So for example, if a call such as "users" isn't supported by 
a certain datastore used by an instance, the server side code will be able to 
determine that and something such as a bad request or not found status code.


From: Michael Basnight [mbasni...@gmail.com]
Sent: Monday, October 21, 2013 4:05 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Trove] How users should specify a datastore   
type when creating an instance

On Oct 21, 2013, at 1:57 PM, Nikhil Manchanda wrote:

>
> The image approach works fine if Trove only supports deploying a single
> datastore type (mysql in your case). As soon as we support
> deploying more than 1 datastore type, Trove needs to have some knowledge
> of which guestagent manager classes to load. Hence the need
> for having a datastore type API.
>
> The argument for needing to keep track of the version is
> similar. Potentially a version increment -- especially of the major
> version -- may require for a different guestagent manager. And Trove
> needs to have this information.

This is also true that we dont want to define the _need_ to have custom images 
for the datastores. You can, quite easily, deploy mysql or redis on a vanilla 
image.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)

[Clint Byrum]

Excerpts from Monty Taylor's message of 2013-10-21 17:09:41 -0700:
> 
> On 10/21/2013 10:44 PM, Clint Byrum wrote:
> > Excerpts from Mark McLoughlin's message of 2013-10-21 13:45:21 -0700:
> > 
> > If you don't know who the copyright holders are, you cannot know that
> > the license being granted is actually enforceable. What if the Trove
> > developers just found some repo lying out in the world and slapped an
> > Apache license on it? We aren't going to do an ehaustive investigation,
> > but we want to know _who_ granted said license.
> 
> You know I think you're great, but this argument doesn't hold up.
> 
> If the trove developers found some repo in the world and slapped an
> apache license AND said:
> 
> Copyright 2012 Michael Basnight
> 
> in the header, and Thomas put that in debian/copyright, the Debian FTP
> masters would very happily accept it.
> 

The copyright header is a data point. Now somebody looking to vet the
license situation can go and contact Michael Basnight, and look at the
history of the code itself. They can validate that Michael Basnight was
an early author, made announcements, isn't a habitual code stealer, etc.

Is this correct? No, but it gives someone looking to do due diligence
confirmation that Michael had the right to license the code.

No headers, and no information anywhere just makes an investigation that
much harder.

So it is just a data point for auditing. The problem, which Robert
Collins alluded to, is that nobody is actually auditing things this way.

This is something to bring up in Debian. I think I'll work off list with
Thomas to draft something for Debian which proposes a clarification
or relaxation of the copyright holder interpretation of Debian policy
currently adopted by the FTP masters.

> I think that authors should attribute their work, because I think that
> they should care. However, if they don't, that's fine. There is SOME
> attribution in the file, and that attribution itself is correct. HP did
> write some of the file. Rackspace also did but did not bother to claim
> having done so.
> 
> debian/copyright should reflect what's in the files - it's what the
> project is stating through the mechanisms that we have available to us.
> I appreciate Thomas trying to be more precise here, but I think it's
> actually too far. If you think that there is a bug in the copyright
> header, you need to contact the project, via email, bug or patch, and
> fix it. At THAT point, you can fix the debian/copyright file.
> 
> Until then, you need to declare to Debian what we are declaring to you.
> 

Indeed, this hasn't come up, presumably, because the other
debian/copyright files have done just that. That is definitely the path of
least resistance, and the one I have taken. This is not trivial either,
As somebody who made a feeble attempt at documenting the copyright
holders for MySQL (all of you reading this have no idea how hard Monty
is cackling right now), I can say that it is basically pointless to do
anything except automatically generate from existing sources and spot
check.

> > 
> > I'm not sure that was me, but I would object to conflating it, yes. They
> > are not the same thing, but they are related. Only a copyright holder
> > can grant a copyright license.
> 
> Listing the holders in debian/copyright does not prove that the asserted
> holder is a valid holder. It only asserts that _someone_ has asserted
> that copyright.
> 
> It means that, should someone sue you for copyright infringement, there
> is someone you can go to for clarification.
> 

That sounds pretty valuable to me. Imagine Debian has some big
corporation sending them cease and desist letters and threats of
copyright infringement lawsuits. It would be useful to be able to
deflect that efficiently given their limited resources.

> >> Our CLA process for new contributors is documented here:
> >>
> >>   
> >> https://wiki.openstack.org/wiki/How_To_Contribute#Contributors_License_Agreement
> >>
> >> The key thing for Debian to understand is that all OpenStack
> >> contributors agree to license their code under the terms of the Apache
> >> License. I don't see why a list of copyright holders would clarify the
> >> licensing situation any further.
> >>
> > 
> > So Debian has a rule that statements like these need to be delivered to
> > their users along with the end-user binaries (it relates to the social
> > contract and the guidelines attached to the contract.
> > 
> > https://review.openstack.org/static/cla.html
> > 
> > Article 2 is probably sufficient to say that it only really matters that
> > all of the copyrighted material came from people who signed the CLA,
> > and that the "Project Manager" (OpenStack Foundation) grants the license
> > on the code. I assume the other CLA's have the same basic type of
> > license being granted to the OpenStack Foundation.
> > 
> > So my recommendation stands, that we can clarify it in the released
> > tarballs with a single document. I suggest that docume

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

[Tim Simpson]

>  i think we have to use default version only if type contains > 1
True, but a default should be settable even if there's only one type.

> And default version should be active, otherwise -
> error.
Agreed. 


From: Andrey Shestakov [ashesta...@mirantis.com]
Sent: Monday, October 21, 2013 4:40 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Trove] How users should specify a datastore type 
when creating an instance

On Mon, Oct 21, 2013 at 11:40 PM, Tim Simpson  wrote:
>
> >> 4. Additionally, in the current pull request to implement this it is 
> >> possible to avoid passing a version, but only if no more than one version 
> >> of the datastore_type exists in the database.
> >>
> >> I think instead the datastore_type row in the database should also have a 
> >> "default_version_id" property, that an operator could update to the most 
> >> recent version or whatever other criteria they wish to use, meaning the 
> >> call could become this simple:
>
> > Since we have determined from this email thread that we have an active 
> > status, and that > 1 version can be active, we have to think about the 
> > precedence of active vs default. My question would be, if we have a 
> > default_version_id and a active version, what do we choose on behalf of the 
> > user? If there is > 1 active version and a user does not specify the 
> > version, the api will error out, unless a default is defined. We also need 
> > a default_type in the config so the existing APIs can maintain 
> > compatibility. We can re-discuss this for v2 of the API.
>
> Imagine that an operator sets up Trove and only has one active version. They 
> then somehow fumble setting up the default_version, but think they succeeded 
> as the API works for users the way they expect anyway. Then they go to add 
> another active version and suddenly their users get error messages.
>
> If we only use the "default_version" field of the datastore_type to define a 
> default would honor the principle of least surprise.

if default version is inactive? there will more cases for error

also, i think we have to use default version only if type contains > 1
active version. And default version should be active, otherwise -
error.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

[Tim Simpson]

> It's not intuitive to the User, if they are specifying a version alone.  You 
> don't boot a 'version' of something, with specifying what that some thing is. 
>  I would rather they only specified the datastore_type alone, and not have 
> them specify a version at all.

I agree for most users just selecting the datastore_type would be most intutive.

However, when they specify a version it's going to a be GUID which they could 
only possibly know if they have recently enumerated all versions and thus 
*know* the version is for the given type they want. In that case I don't think 
most users would appreciate having to also pass the type- it would just be 
redundant. So in that case why not make it optional?


From: Vipul Sabhaya [vip...@gmail.com]
Sent: Monday, October 21, 2013 5:09 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Trove] How users should specify a datastore type 
when creating an instance




On Mon, Oct 21, 2013 at 2:04 PM, Michael Basnight 
mailto:mbasni...@gmail.com>> wrote:

On Oct 21, 2013, at 1:40 PM, Tim Simpson wrote:

>>> 2. I also think a datastore_version alone should be sufficient since the 
>>> associated datastore type will be implied:
>
>> When i brought this up it was generally discussed as being confusing. Id 
>> like to use type and rely on having a default (or active) version behind the 
>> scenes.
>
> Can't we do both? If a user wants a specific version, most likely they had to 
> enumerate all datastore_versions, spot it in a list, and grab the guid. Why 
> force them to also specify the datastore_type when we can easily determine 
> what that is?

Fair enough.


It's not intuitive to the User, if they are specifying a version alone.  You 
don't boot a 'version' of something, with specifying what that some thing is.  
I would rather they only specified the datastore_type alone, and not have them 
specify a version at all.

>
>>> 4. Additionally, in the current pull request to implement this it is 
>>> possible to avoid passing a version, but only if no more than one version 
>>> of the datastore_type exists in the database.
>>>
>>> I think instead the datastore_type row in the database should also have a 
>>> "default_version_id" property, that an operator could update to the most 
>>> recent version or whatever other criteria they wish to use, meaning the 
>>> call could become this simple:
>
>> Since we have determined from this email thread that we have an active 
>> status, and that > 1 version can be active, we have to think about the 
>> precedence of active vs default. My question would be, if we have a 
>> default_version_id and a active version, what do we choose on behalf of the 
>> user? If there is > 1 active version and a user does not specify the 
>> version, the api will error out, unless a default is defined. We also need a 
>> default_type in the config so the existing APIs can maintain compatibility. 
>> We can re-discuss this for v2 of the API.
>
> Imagine that an operator sets up Trove and only has one active version. They 
> then somehow fumble setting up the default_version, but think they succeeded 
> as the API works for users the way they expect anyway. Then they go to add 
> another active version and suddenly their users get error messages.
>
> If we only use the "default_version" field of the datastore_type to define a 
> default would honor the principle of least surprise.

Are you saying you must have a default version defined to have > 1 active 
versions?


I think it makes sense to have a 'Active' flag on every version -- and a 
default flag for the version that should be used as a default in the event the 
user doesn't specify.  It also makes sense to require the deployer to set this 
accurately, and if one doesn't exist instance provisioning errors out.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Hyper-V meeting minutes

[Peter Pouliot]

Hi All,

Here are the minutes from today's meeting.


Minutes:
http://eavesdrop.openstack.org/meetings/hyper_v/2013/hyper_v.2013-10-22-16.01.html
Minutes (text): 
http://eavesdrop.openstack.org/meetings/hyper_v/2013/hyper_v.2013-10-22-16.01.txt
Log:
http://eavesdrop.openstack.org/meetings/hyper_v/2013/hyper_v.2013-10-22-16.01.log.html


Peter J. Pouliot, CISSP
Senior SDET, OpenStack

Microsoft
New England Research & Development Center
One Memorial Drive,Cambridge, MA 02142
ppoul...@microsoft.com | Tel: +1(857) 453 6436

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] CLA

[Zane Bitter]

On 22/10/13 16:22, Jeremy Stanley wrote:

(Disclaimers: I am not a lawyer, which likely explains my lack of
interest in perversely pointless paperwork. Also, these opinions are
my own and do not necessarily reflect those of my employer. Setting
MFT to legal-discuss as a more appropriate forum for these sorts of
discussions.)

On 2013-10-22 15:11:25 +0200 (+0200), Zane Bitter wrote:
[...]

Can't we just write "Copyright OpenStack Contributors"? (Where
'contributors' means individuals or organisations who have signed
the CLA.)

[...]

Actually, technically not. There are other avenues through which
patches come (posts on mailing lists, attachments to bugs) and I
know that from time to time contributors git-am other authors' bug
fixes without first asking them to go agree to an OpenStack CLA and
prove that they have done so. The actual copyright belongs with the
author (or their employer under a work-for-hire agreement), not the
contributor who uploaded that work--and they aren't necessarily
always the same people.


Fair point, although as you note below if the contributor does not 
identify the actual copyright holder in the submission, that is their 
responsibility not OpenStack's responsibility. Likely a few copyright 
holders will fall through the cracks here (e.g. from legitimately 
identified external code like https://review.openstack.org/#/c/40330/), 
but many, many *more* will fall through the cracks in trying to compile 
a list of them.


I'm not suggesting here that the CLA can provide an accurate list of 
copyright holders (which is impossible anyway), I'm saying that it 
provides a paper-trail back to somebody who warrants that they have the 
right to licence the code under the ASL (however mistaken they may be 
about that), and that this is precisely the paper trail that the Debian 
FTP masters are looking for.



Gerrit ensures that only OpenStack Contributors (those that have
signed the CLA) can contribute to OpenStack

[...]

To echo Monty's sentiments earlier in the thread, and also as the
person who spear-headed the current CLA enforcement configuration in
our project's Gerrit instance, I don't see how our CLAs add anything
of value. It's patronizing, almost insulting, to ask developers to
pinky-swear that they're authorized to license the code they
contribute under the license included with the code they contribute.


It's exactly as silly as Debian requiring the copyright holders to be 
identified alongside the licence. As an engineer, I'm inclined to agree 
that it's pretty silly, because it doesn't actually change anything - 
nobody is ever surprised when their contribution to open source ends up 
as open source, and if it turns out that they were not entitled to so 
licence it then it's still effectively everyone's problem, CLA or no. 
Clearly there are lawyers who disagree though.



At best it may provide a warm fuzzy feeling for companies who are
unfamiliar with contributing to free software projects, since free
software licenses are all about waiving your rights rather than
enforcing them and that might sound scary to the uninitiated... but
better efforts toward educating them about free software may prove
more productive than relying on a legal security blanket.

Also as mentioned above, Gerrit does not enforce that the copyright
holder has agreed to this, it only enforces that the person
*uploading* the code into Gerrit has agreed to it... and section 7
of the ICLA has some interesting things to say about submitting
third-party contributions, which looks to me like a permitted
loophole for getting ASL code into the project without the author
directly agreeing to a CLA at all.


7. Should You wish to submit work that is not Your original
creation, You may submit it to the Project Manager separately
from any Contribution, identifying the complete details of its
source and of any license or other restriction (including, but
not limited to, related patents, trademarks, and license
agreements) of which you are personally aware, and conspicuously
marking the work as "Submitted on behalf of a third-party:
[named here]".


I wonder if the current de facto practice of allowing git's author
header to reflect the identity of the third-party counts as a
conspicuous mark for the purposes of ICLA section 7? And whether
submitting it to Gerrit where it can be openly inspected by the
entire project counts as a submission to the Project Manager (the
OpenStack Foundation) as well? At any rate, it seems that the
agreement boils down to "copyright holders promise that they're
contributing code under this license, or that they're submitting
someone else's work who probably is okay with it."


That's exactly what it boils down to, and coincidentally exactly what 
the requirement to list copyright holders in Debian also boils down to 
afaict. We should leverage the synergies, or something ;)


cheers,
Zane.

___
OpenStack-dev mailing list
OpenStack-dev@list

Re: [openstack-dev] [Heat] HOT Software configuration proposal

[Thomas Spatzier]

Zane Bitter  wrote on 22.10.2013 17:23:52:
> From: Zane Bitter 
> To: openstack-dev@lists.openstack.org,
> Date: 22.10.2013 17:26
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
> On 22/10/13 16:35, Thomas Spatzier wrote:
> > Zane Bitter  wrote on 22.10.2013 15:24:28:
> >> From: Zane Bitter 
> >> To: openstack-dev@lists.openstack.org,
> >> Date: 22.10.2013 15:27
> >> Subject: Re: [openstack-dev] [Heat] HOT Software configuration
proposal
> >>
> >> On 22/10/13 09:15, Thomas Spatzier wrote:
> >>> BTW, the convention of properties being input and attributes being
> > output,
> >>> i.e. that subtle distinction between properties and attributes is not
> >>> really intuitive, at least not to me as non-native speaker, because I
> > used
> >>> to use both words as synonyms.
> >>
> >> As a native speaker, I can confidently state that it's not intuitive
to
> >> anyone ;)
> >
> > Phew, good to read that ;-)
> >
> >>
> >> We unfortunately inherited these names from the Properties section and
> >> the Fn::GetAtt function in cfn templates. It's even worse than that,
> >> because there's a whole category of... uh... things (DependsOn,
> >> DeletionPolicy, &c.) that don't even have a name - I always have to
> >> resist the urge to call them 'attributes' too.
> >
> > So is this something we should try to get straight in HOT while we
still
> > have the flexibility?
>
> Y-yes. Provided that we can do it without making things *more*
> confusing, +1. That's hard though, because there are a number of places
> we have to refer to them, all with different audiences:
>   - HOT users
>   - cfn users
>   - Existing developers
>   - New developers
>   - Plugin developers
>
> and using different names for the same thing can cause problems. My test
> for this is: if you were helping a user on IRC debug an issue, is there
> a high chance you would spend 15 minutes talking past each other because
> they misunderstand the terminology?

Hm, good point. Seems like it would really cause more confusion than it
helps. So back away from the general idea of renaming things that exist
both in cfn and HOT.
What we should try of course is to give new concepts that will only exist
in HOT intuitive names.

>
> > Regarding properties/attributes for example, to me I would call both
just
> > properties of a resource or component, and then I can write them or
read
> > them like:
> >
> > components:
> >my_component:
> >  type: ...
> >  properties:
> >my_prop: { get_property: [ other_component,
other_component_prop ] }
> >
> >other_component:
> >  # ...
> >
> > I.e. you write property 'my_prop' of 'my_component' in its properties
> > section, and you read property 'other_component_prop' of
'other_component'
> > using the get_property function.
> > ... we can also call them attributes, but use one name, not two
different
> > names for the same thing.
>
> IMO inputs (Properties) and outputs (Fn::GetAtt) are different things
> (and they exist in different namespaces), so -1 for giving them the same
> name.
>
> In an ideal world I'd like HOT to use something like get_output_data (or
> maybe just get_data), but OTOH we have e.g. FnGetAtt() and
> attributes_schema baked in to the plugin API that we can't really
> change, so it seems likely to lead to developers and users adopting
> different terminology, or making things very difficult for new
> developers, or both :(
>
> cheers,
> Zane.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 & DHCP options for dnsmasq

[Matt Riedemann]

FWIW, we've wanted IPv6 support too but there are limitations in 
sqlalchemy and python 2.6 and since openstack is still supporting both of 
those, we are gated on that.



Thanks,

MATT RIEDEMANN
Advisory Software Engineer
Cloud Solutions and OpenStack Development

Phone: 1-507-253-7622 | Mobile: 1-507-990-1889
E-mail: mrie...@us.ibm.com


3605 Hwy 52 N
Rochester, MN 55901-1407
United States




From:   "Sean M. Collins" 
To: OpenStack Development Mailing List 
, 
Date:   10/22/2013 10:33 AM
Subject:Re: [openstack-dev] [Neutron] IPv6 & DHCP options for 
dnsmasq



On Tue, Oct 22, 2013 at 08:58:52AM +0200, Luke Gorrie wrote:
> Deutsche Telekom too. We are working on making Neutron interoperate well
> with a service provider network that's based on IPv6. I look forward to
> talking about this with people in Hong Kong :)

I may be mistaken, but I don't see a summit proposal for Neutron, on the
subject of IPv6. Are there plans to have one?

-- 
Sean M. Collins
[attachment "att18car.dat" deleted by Matt Riedemann/Rochester/IBM] 
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

<>___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Debian Jessie freeze date announced: 5th of November 2014

[Thomas Goirand]

On 10/20/2013 05:25 AM, Cristian Tomoiaga wrote:
> Hello Thomas,
> 
> I am sorry to send a reply a little late on this. I plan on working with
> Debian for my Openstack setups (now I'm on a rhel based setup) and I
> would really like the "latest" OpenStack release available.
> I was initially planning to setup my own mirrors since I always seem to
> need features from the next OpenStack release. For example Grizzly for
> me looks "too old" and some features that were "supposed" to land on
> Havana are now scheduled for Icehouse.
> Given this, I would pretty much like to have "J" in Debian Jessie.
> I'm not sure how to approach this or if it's worth the effort on your
> part given the latest issues you submitted for Havana and since most
> likely some features in "K" will probably make me switch to separate
> mirrors anyway. However, taking into account the rapid development of
> OpenStack my guess is that the "J" release should land in Jessie if
> possible.
> I will also try to find some time and help out as much as I can with this.
> Let me know what you decide , probably after the summit.

Hi Cristian,

Thanks for your above comments.

Unfortunately, even if I agree with you that the latest is best, and
that having a maximum of feature is just cool, my decision will *not* be
motivated by that. The only thing will care will be the ease
maintainability in the Debian stable release.

Maintaining security for OpenStack Essex in Wheezy is currently a major
pain, because it's not supported upstream. It'd be really great, from my
point of view, if the OpenStack community decided to have an LTS
release. Maybe it didn't make sense at the time of Essex. Probably, as
the time passes and OpenStack matures, it will make more sense now and
later to have an LTS. Though this isn't my decision, and my
understanding of it, is that the amount of people interested by doing
the security backport work this is close to one (eg: only myself).

So, if there's still no "LTS" for OpenStack next April, and things
continue to be maintained the way they are right now in OpenStack (that
is, release + 1 year), then I have 2 options. Either I will follow
Canonical, and hope that we can have a joined effort for security fixing
(currently, it's not happening at all, so this would have to change), or
just package the very latest (release "J"), so that backporting of
patches is less painful that backporting to Icehouse. This way, I'd also
get 1 year of "free" security support instead of 6 months, which is
something already...

Also, another problem is being able to get enough patches of the point
release into the frozen Testing distribution. When OpenStack releases,
there's always a bug here and there that are annoying, but discovered
later, on point releases. So 2013.1.4 could make more sense, quality
wise, as it will have the time to be polished and cleaned. Wheezy has
been released with 2012.1.1, and not 2012.1.4, because it was frozen at
the end of June, and nobody took care of applying the upstream patches
and convincing the release team that they are needed. To get this
happening with the J release of OpenStack, every patch will be reviewed
and will need justification, which takes a lot of time for both the
package maintainer and the release team, so it'd be nice to avoid it.

Last thing: I will need to support upgrades from Essex to whatever will
be in Jessie. It'd be nice if I can avoid doing this alone. I'm not sure
if the OpenStack project is bound to support that, or if Canonical will
be doing the work.

Oh, and one last thing: whatever happen, I will continue to package the
very latest OpenStack version either in Sid, or in Experimental, and
continue to provide Wheezy / Jessie backports. So if you want the very
latest version of OpenStack in Debian, you'll have it available.

I hope the above gives you a more clear picture of what's going on in my
mind. I have a year to take a decision... :)

Cheers,

Thomas Goirand (zigo)

P.S: CC-ing the Debian release team list, to get their opinion.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Common requirements for services' discussion

[Sumit Naiksatam]

Hi All,

Here is a log of today's discussion:

http://eavesdrop.openstack.org/meetings/networking_advanced_services/2013/networking_advanced_services.2013-10-22-15.32.log.html

(some action items for a few folks who were present, we will follow up in
the next meeting.)

Thanks,

~Sumit.




On Mon, Oct 21, 2013 at 11:08 PM, Sumit Naiksatam
wrote:

> Hi All,
>
> This is a reminder for the next IRC meeting on Tuesday (Oct 22nd) 15.30
> UTC (8.30 AM PDT) on the #openstack-meeting-alt channel.
>
> The proposed agenda is:
> * Service insertion and chaining
> * Service agents
> * Service VMs - mechanism
> * Service VMs - policy
> * Extensible APIs for services
> and anything else you may want to discuss in this context.
>
> Meeting wiki page (has pointer to the first meeting logs):
> https://wiki.openstack.org/wiki/Meetings/AdvancedServices
>
> Thanks,
> ~Sumit.
>
> On Thu, Oct 17, 2013 at 12:02 AM, Sumit Naiksatam <
> sumitnaiksa...@gmail.com> wrote:
>
>> Hi All,
>>
>> We will have the "advanced services" and the common requirements IRC
>> meeting on Tuesdays 15.30 UTC (8.30 AM PDT) on the #openstack-meeting-alt 
>> channel.
>> The meeting time was chosen to accommodate requests by folks in Asia and
>> will hopefully suit most people involved. Please note that this is the
>> alternate meeting channel.
>>
>> The agenda will be a continuation of discussion from the previous meeting
>> with some additional agenda items based on the sessions already proposed
>> for the summit. The current discussion is being captured in this etherpad:
>> https://etherpad.openstack.org/p/NeutronAdvancedServices
>>
>> Hope you can make it and participate.
>>
>> Thanks,
>> ~Sumit.
>>
>>
>> On Mon, Oct 14, 2013 at 8:15 PM, Sumit Naiksatam <
>> sumitnaiksa...@gmail.com> wrote:
>>
>>> Thanks all for attending the IRC meeting today for the Neutron "advanced
>>> services" discussion. We have an etherpad for this:
>>> https://etherpad.openstack.org/p/NeutronAdvancedServices
>>>
>>> It was also felt that we need to have more ongoing discussions, so we
>>> will have follow up meetings. We will try to propose a more convenient time
>>> for everyone involved for a meeting next week. Meanwhile, we can continue
>>> to use the mailing list, etherpad, and/or comment on the specific proposals.
>>>
>>> Thanks,
>>> ~Sumit.
>>>
>>>
>>> On Tue, Oct 8, 2013 at 8:30 PM, Sumit Naiksatam <
>>> sumitnaiksa...@gmail.com> wrote:
>>>
 Hi All,

 We had a VPNaaS meeting yesterday and it was felt that we should have a
 separate meeting to discuss the topics common to all services. So, in
 preparation for the Icehouse summit, I am proposing an IRC meeting on Oct
 14th 22:00 UTC (immediately after the Neutron meeting) to discuss common
 aspects related to the FWaaS, LBaaS, and VPNaaS.

 We will begin with service insertion and chaining discussion, and I
 hope we can collect requirements for other common aspects such as service
 agents, services instances, etc. as well.

 Etherpad for service insertion & chaining can be found here:

 https://etherpad.openstack.org/icehouse-neutron-service-insertion-chaining

 Hope you all can join.

 Thanks,
 ~Sumit.



>>>
>>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Error while executing 'git review'

[S Sridhar]

Thanks Subbu. It worked for me. Here is the review created: 
https://review.openstack.org/#/c/53160/. Also found some useful info here on 
Gerrit errors: https://wiki.openstack.org/wiki/GerritJenkinsGit.
RegardsSridhar
Looks like a change id conflict with https://review.openstack.org/#/c/52949.
You are letting "git review" auto generate the change id right? For this
case you could try "git commit --amend", remove the change id line if it
matches the change id from this review and then run "git review" again. HTH.

- Subbu
From: sridha...@outlook.com
To: openstack-dev@lists.openstack.org
Subject: Error while executing 'git review'
Date: Tue, 22 Oct 2013 18:34:29 +0530




Hi All,
I worked on bug # 1176683 and fixed it. Commit is successful.
sridhar@ubuntu:~/repo/neutron$ git status # On branch bug_id_1176683nothing to 
commit (working directory clean)sridhar@ubuntu:~/repo/neutron$
But getting following error while posting for review.
sridhar@ubuntu:~/repo/neutron$ git reviewremote: Resolving deltas: 100% 
(4/4)remote: Processing changes: refs: 1, doneTo 
ssh://saggezz...@review.openstack.org:29418/openstack/neutron.git ! [remote 
rejected] HEAD -> refs/for/master/bug/1176683 (change 52949 closed)error: 
failed to push some refs to 
'ssh://saggezz...@review.openstack.org:29418/openstack/neutron.git'sridhar@ubuntu:~/repo/neutron$
 
Could anyone help in resolving this issue ?
RegardsSridhar  
  ___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] HOT Software configuration proposal

[Stan Lagun]

Hello,

I've been reading through the thread and the wiki pages and I'm still
confused by the terms. Is there a clear definition of what do we understand
by component from user's and developer's point of view. If I write
"component, type:MySQL" what is behind that definition? I mean how does the
system know what exactly MySQL is and how to install it? What MySQL version
is it gonna be? Will it be x86 or x64? How does the system understand that
I need MySQL for Windows on Windows VM rather then Linux MySQL? What do I
as a developer need to do so that it would be possible to have "type:
MyCoolComponentType"?


On Tue, Oct 22, 2013 at 8:35 PM, Thomas Spatzier  wrote:

> Zane Bitter  wrote on 22.10.2013 17:23:52:
> > From: Zane Bitter 
> > To: openstack-dev@lists.openstack.org,
> > Date: 22.10.2013 17:26
> > Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
> >
> > On 22/10/13 16:35, Thomas Spatzier wrote:
> > > Zane Bitter  wrote on 22.10.2013 15:24:28:
> > >> From: Zane Bitter 
> > >> To: openstack-dev@lists.openstack.org,
> > >> Date: 22.10.2013 15:27
> > >> Subject: Re: [openstack-dev] [Heat] HOT Software configuration
> proposal
> > >>
> > >> On 22/10/13 09:15, Thomas Spatzier wrote:
> > >>> BTW, the convention of properties being input and attributes being
> > > output,
> > >>> i.e. that subtle distinction between properties and attributes is not
> > >>> really intuitive, at least not to me as non-native speaker, because I
> > > used
> > >>> to use both words as synonyms.
> > >>
> > >> As a native speaker, I can confidently state that it's not intuitive
> to
> > >> anyone ;)
> > >
> > > Phew, good to read that ;-)
> > >
> > >>
> > >> We unfortunately inherited these names from the Properties section and
> > >> the Fn::GetAtt function in cfn templates. It's even worse than that,
> > >> because there's a whole category of... uh... things (DependsOn,
> > >> DeletionPolicy, &c.) that don't even have a name - I always have to
> > >> resist the urge to call them 'attributes' too.
> > >
> > > So is this something we should try to get straight in HOT while we
> still
> > > have the flexibility?
> >
> > Y-yes. Provided that we can do it without making things *more*
> > confusing, +1. That's hard though, because there are a number of places
> > we have to refer to them, all with different audiences:
> >   - HOT users
> >   - cfn users
> >   - Existing developers
> >   - New developers
> >   - Plugin developers
> >
> > and using different names for the same thing can cause problems. My test
> > for this is: if you were helping a user on IRC debug an issue, is there
> > a high chance you would spend 15 minutes talking past each other because
> > they misunderstand the terminology?
>
> Hm, good point. Seems like it would really cause more confusion than it
> helps. So back away from the general idea of renaming things that exist
> both in cfn and HOT.
> What we should try of course is to give new concepts that will only exist
> in HOT intuitive names.
>
> >
> > > Regarding properties/attributes for example, to me I would call both
> just
> > > properties of a resource or component, and then I can write them or
> read
> > > them like:
> > >
> > > components:
> > >my_component:
> > >  type: ...
> > >  properties:
> > >my_prop: { get_property: [ other_component,
> other_component_prop ] }
> > >
> > >other_component:
> > >  # ...
> > >
> > > I.e. you write property 'my_prop' of 'my_component' in its properties
> > > section, and you read property 'other_component_prop' of
> 'other_component'
> > > using the get_property function.
> > > ... we can also call them attributes, but use one name, not two
> different
> > > names for the same thing.
> >
> > IMO inputs (Properties) and outputs (Fn::GetAtt) are different things
> > (and they exist in different namespaces), so -1 for giving them the same
> > name.
> >
> > In an ideal world I'd like HOT to use something like get_output_data (or
> > maybe just get_data), but OTOH we have e.g. FnGetAtt() and
> > attributes_schema baked in to the plugin API that we can't really
> > change, so it seems likely to lead to developers and users adopting
> > different terminology, or making things very difficult for new
> > developers, or both :(
> >
> > cheers,
> > Zane.
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Sincerely yours
Stanislav (Stan) Lagun
Senior Developer
Mirantis
35b/3, Vorontsovskaya St.
Moscow, Russia
Skype: stanlagun
www.mirantis.com
sla...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openst

Re: [openstack-dev] [Neutron] IPv6 & DHCP options for dnsmasq

[Jay Pipes]

On 10/22/2013 12:48 PM, Matt Riedemann wrote:

FWIW, we've wanted IPv6 support too but there are limitations in
sqlalchemy and python 2.6 and since openstack is still supporting both
of those, we are gated on that.


What limitations re: IPv6 does SQLAlchemy present?

-jay


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance

[Michael Basnight]

On Oct 22, 2013, at 9:34 AM, Tim Simpson wrote:

> > It's not intuitive to the User, if they are specifying a version alone.  
> > You don't boot a 'version' of something, with specifying what that some 
> > thing is.  I would rather they only specified the datastore_type alone, and 
> > not have them specify a version at all.
> 
> I agree for most users just selecting the datastore_type would be most 
> intutive. 
> 
> However, when they specify a version it's going to a be GUID which they could 
> only possibly know if they have recently enumerated all versions and thus 
> *know* the version is for the given type they want. In that case I don't 
> think most users would appreciate having to also pass the type- it would just 
> be redundant. So in that case why not make it optional?]

im ok w/ making either "optional" if the criteria for selecting the _other_ is 
not ambiguous. 


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Error while executing 'git review'

[Stefano Maffulli]

On 10/22/2013 06:04 AM, S Sridhar wrote:
> But getting following error while posting for review.
> 
> sridhar@ubuntu:~/repo/neutron$ git review
> remote: Resolving deltas: 100% (4/4)
> remote: Processing changes: refs: 1, done
> To ssh://saggezz...@review.openstack.org:29418/openstack/neutron.git
>  ! [remote rejected] HEAD -> refs/for/master/bug/1176683 (change 52949
> closed)
> error: failed to push some refs to
> 'ssh://saggezz...@review.openstack.org:29418/openstack/neutron.git'
> sridhar@ubuntu:~/repo/neutron$ 
> 
> Could anyone help in resolving this issue ?

Glad to read the issue was solved. To prevent this from happening in the
future please follow the suggested 'normal' workflow

https://wiki.openstack.org/wiki/GerritWorkflow#Normal_Workflow

HTH
/stef

-- 
Ask and answer questions on https://ask.openstack.org

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] openstack-dev][nova][neturon] NoopFirewallDriver lead nova boot/show/list failure.

[Bence Romsics]

Hi,

> When firewall_driver is set to NoopFirwallDriver in Neutron agent,
> uses can create security group and its rules, but no packet filtering
> is enforced.
> If neutron security group is enabled, users should expect packet
> filtering is enabled
> I think this behavior is confusing from Neutron API perspective,
> and if no packet filtering is enforced, we cannot say security group
> feature is provided.
> This is the background of the change.

In my thoughts there are three players here, the developer, the
administrator and the users (close to what is the API perspective in
your terms).

If the administrator decides to use the noop implementation of an API
and he does not tell his users this is the case, that's definitely
confusing for the users. If the administrator wants to use the noop
implementation and instead of getting a noop behaviour the whole
extension disappears that's also confusing, but for the administrator.

I also get that an API user typically does not know the configuration
against his code will run.

The noop implementation cannot be turned on accidentally. The
administrator has to do it for whatever reason - likely debugging as
you mentioned. I believe it's not the developer's responsibility to
protect the users from the administrator's intentional configuration
decision.

Anyway I can live with the other proposed alternatives too. I just
wanted to point out that for me the current behavior was the
surprising one. And also wanted to connect the discussion to its
origins.

Thanks,
Bence

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 & DHCP options for dnsmasq

[Davanum Srinivas]

I am guessing Matt is talking about running openstack in a pure ipv6
environment. So it would be this bug
https://bugs.launchpad.net/nova/+bug/1190454


On Tue, Oct 22, 2013 at 1:10 PM, Jay Pipes  wrote:

> On 10/22/2013 12:48 PM, Matt Riedemann wrote:
>
>> FWIW, we've wanted IPv6 support too but there are limitations in
>> sqlalchemy and python 2.6 and since openstack is still supporting both
>> of those, we are gated on that.
>>
>
> What limitations re: IPv6 does SQLAlchemy present?
>
> -jay
>
>
> __**_
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.**org 
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev
>



-- 
Davanum Srinivas :: http://davanum.wordpress.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] A prototype for cross-vm synchronization and communication

[Lakshminaraya Renganarayana]

Hi Steven,

Steven Hardy  wrote on 10/21/2013 11:27:43 AM:
>
> On Fri, Oct 18, 2013 at 02:45:01PM -0400, Lakshminaraya Renganarayana
wrote:
> 
> > The prototype is implemented in Python and Ruby is used for chef
> > interception.
>
> Where can we find the code?

What part of the code are you interested in? The python pre-processor part
or the Ruby chef interceptor part? I need to get clearance from IBM to post
it on the Git. I am guessing it might be easy to get clearance for the
pre-processor code and a bit harder for the chef interceptor code.

BTW, will you be attending the OpenStack summit in HongKong? I am planning
to and I can show you a demo of this pre-processor there (if the IBM
clearance takes too long).

Thanks,
LN___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)

[Michael Basnight]

Top posting cuz im a baller. We will get this fixed today. PS clint i like the 
way you think ;)

https://review.openstack.org/#/c/53176/

On Oct 22, 2013, at 9:21 AM, Clint Byrum wrote:

> Excerpts from Monty Taylor's message of 2013-10-21 17:09:41 -0700:
>> 
>> On 10/21/2013 10:44 PM, Clint Byrum wrote:
>>> Excerpts from Mark McLoughlin's message of 2013-10-21 13:45:21 -0700:
>>> 
>>> If you don't know who the copyright holders are, you cannot know that
>>> the license being granted is actually enforceable. What if the Trove
>>> developers just found some repo lying out in the world and slapped an
>>> Apache license on it? We aren't going to do an ehaustive investigation,
>>> but we want to know _who_ granted said license.
>> 
>> You know I think you're great, but this argument doesn't hold up.
>> 
>> If the trove developers found some repo in the world and slapped an
>> apache license AND said:
>> 
>> Copyright 2012 Michael Basnight
>> 
>> in the header, and Thomas put that in debian/copyright, the Debian FTP
>> masters would very happily accept it.
>> 
> 
> The copyright header is a data point. Now somebody looking to vet the
> license situation can go and contact Michael Basnight, and look at the
> history of the code itself. They can validate that Michael Basnight was
> an early author, made announcements, isn't a habitual code stealer, etc.
> 
> Is this correct? No, but it gives someone looking to do due diligence
> confirmation that Michael had the right to license the code.
> 
> No headers, and no information anywhere just makes an investigation that
> much harder.
> 
> So it is just a data point for auditing. The problem, which Robert
> Collins alluded to, is that nobody is actually auditing things this way.
> 
> This is something to bring up in Debian. I think I'll work off list with
> Thomas to draft something for Debian which proposes a clarification
> or relaxation of the copyright holder interpretation of Debian policy
> currently adopted by the FTP masters.
> 
>> I think that authors should attribute their work, because I think that
>> they should care. However, if they don't, that's fine. There is SOME
>> attribution in the file, and that attribution itself is correct. HP did
>> write some of the file. Rackspace also did but did not bother to claim
>> having done so.
>> 
>> debian/copyright should reflect what's in the files - it's what the
>> project is stating through the mechanisms that we have available to us.
>> I appreciate Thomas trying to be more precise here, but I think it's
>> actually too far. If you think that there is a bug in the copyright
>> header, you need to contact the project, via email, bug or patch, and
>> fix it. At THAT point, you can fix the debian/copyright file.
>> 
>> Until then, you need to declare to Debian what we are declaring to you.
>> 
> 
> Indeed, this hasn't come up, presumably, because the other
> debian/copyright files have done just that. That is definitely the path of
> least resistance, and the one I have taken. This is not trivial either,
> As somebody who made a feeble attempt at documenting the copyright
> holders for MySQL (all of you reading this have no idea how hard Monty
> is cackling right now), I can say that it is basically pointless to do
> anything except automatically generate from existing sources and spot
> check.
> 
>>> 
>>> I'm not sure that was me, but I would object to conflating it, yes. They
>>> are not the same thing, but they are related. Only a copyright holder
>>> can grant a copyright license.
>> 
>> Listing the holders in debian/copyright does not prove that the asserted
>> holder is a valid holder. It only asserts that _someone_ has asserted
>> that copyright.
>> 
>> It means that, should someone sue you for copyright infringement, there
>> is someone you can go to for clarification.
>> 
> 
> That sounds pretty valuable to me. Imagine Debian has some big
> corporation sending them cease and desist letters and threats of
> copyright infringement lawsuits. It would be useful to be able to
> deflect that efficiently given their limited resources.
> 
 Our CLA process for new contributors is documented here:
 
  
 https://wiki.openstack.org/wiki/How_To_Contribute#Contributors_License_Agreement
 
 The key thing for Debian to understand is that all OpenStack
 contributors agree to license their code under the terms of the Apache
 License. I don't see why a list of copyright holders would clarify the
 licensing situation any further.
 
>>> 
>>> So Debian has a rule that statements like these need to be delivered to
>>> their users along with the end-user binaries (it relates to the social
>>> contract and the guidelines attached to the contract.
>>> 
>>> https://review.openstack.org/static/cla.html
>>> 
>>> Article 2 is probably sufficient to say that it only really matters that
>>> all of the copyrighted material came from people who signed the CLA,
>>> and that the "Project Manager" (O

Re: [openstack-dev] [Neutron] IPv6 & DHCP options for dnsmasq

[Jay Pipes]

Interesting, thx! :)

On 10/22/2013 01:18 PM, Davanum Srinivas wrote:

I am guessing Matt is talking about running openstack in a pure ipv6
environment. So it would be this bug
https://bugs.launchpad.net/nova/+bug/1190454


On Tue, Oct 22, 2013 at 1:10 PM, Jay Pipes mailto:jaypi...@gmail.com>> wrote:

On 10/22/2013 12:48 PM, Matt Riedemann wrote:

FWIW, we've wanted IPv6 support too but there are limitations in
sqlalchemy and python 2.6 and since openstack is still
supporting both
of those, we are gated on that.


What limitations re: IPv6 does SQLAlchemy present?

-jay


_
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.__org

http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev 





--
Davanum Srinivas :: http://davanum.wordpress.com


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] HOT Software configuration proposal

[Georgy Okrokvertskhov]

Hi,

I would agree with Stan that we need to discuss definitions before going
deeply to the implementation.

The first example on the
https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config shows
components like install_mysql and install_wordpress.
I would say that this is a bit confusing because I expected to see
component definitions instead of software deployment definition process. I
think this is a quite dangerous path here because this example shows us
that we can use components as installation steps definition instead of real
component definition.
If one continue to do this approach and defines more and more granular
steps as a components they will come to workflow definition composed in
terms of components. This approach does not add either simplicity or
clarity in the HOT template.

Thanks
Georgy



On Tue, Oct 22, 2013 at 10:02 AM, Stan Lagun  wrote:

> Hello,
>
> I've been reading through the thread and the wiki pages and I'm still
> confused by the terms. Is there a clear definition of what do we understand
> by component from user's and developer's point of view. If I write
> "component, type:MySQL" what is behind that definition? I mean how does the
> system know what exactly MySQL is and how to install it? What MySQL version
> is it gonna be? Will it be x86 or x64? How does the system understand that
> I need MySQL for Windows on Windows VM rather then Linux MySQL? What do I
> as a developer need to do so that it would be possible to have "type:
> MyCoolComponentType"?
>
>
> On Tue, Oct 22, 2013 at 8:35 PM, Thomas Spatzier <
> thomas.spatz...@de.ibm.com> wrote:
>
>> Zane Bitter  wrote on 22.10.2013 17:23:52:
>> > From: Zane Bitter 
>> > To: openstack-dev@lists.openstack.org,
>> > Date: 22.10.2013 17:26
>> > Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>> >
>> > On 22/10/13 16:35, Thomas Spatzier wrote:
>> > > Zane Bitter  wrote on 22.10.2013 15:24:28:
>> > >> From: Zane Bitter 
>> > >> To: openstack-dev@lists.openstack.org,
>> > >> Date: 22.10.2013 15:27
>> > >> Subject: Re: [openstack-dev] [Heat] HOT Software configuration
>> proposal
>> > >>
>> > >> On 22/10/13 09:15, Thomas Spatzier wrote:
>> > >>> BTW, the convention of properties being input and attributes being
>> > > output,
>> > >>> i.e. that subtle distinction between properties and attributes is
>> not
>> > >>> really intuitive, at least not to me as non-native speaker, because
>> I
>> > > used
>> > >>> to use both words as synonyms.
>> > >>
>> > >> As a native speaker, I can confidently state that it's not intuitive
>> to
>> > >> anyone ;)
>> > >
>> > > Phew, good to read that ;-)
>> > >
>> > >>
>> > >> We unfortunately inherited these names from the Properties section
>> and
>> > >> the Fn::GetAtt function in cfn templates. It's even worse than that,
>> > >> because there's a whole category of... uh... things (DependsOn,
>> > >> DeletionPolicy, &c.) that don't even have a name - I always have to
>> > >> resist the urge to call them 'attributes' too.
>> > >
>> > > So is this something we should try to get straight in HOT while we
>> still
>> > > have the flexibility?
>> >
>> > Y-yes. Provided that we can do it without making things *more*
>> > confusing, +1. That's hard though, because there are a number of places
>> > we have to refer to them, all with different audiences:
>> >   - HOT users
>> >   - cfn users
>> >   - Existing developers
>> >   - New developers
>> >   - Plugin developers
>> >
>> > and using different names for the same thing can cause problems. My test
>> > for this is: if you were helping a user on IRC debug an issue, is there
>> > a high chance you would spend 15 minutes talking past each other because
>> > they misunderstand the terminology?
>>
>> Hm, good point. Seems like it would really cause more confusion than it
>> helps. So back away from the general idea of renaming things that exist
>> both in cfn and HOT.
>> What we should try of course is to give new concepts that will only exist
>> in HOT intuitive names.
>>
>> >
>> > > Regarding properties/attributes for example, to me I would call both
>> just
>> > > properties of a resource or component, and then I can write them or
>> read
>> > > them like:
>> > >
>> > > components:
>> > >my_component:
>> > >  type: ...
>> > >  properties:
>> > >my_prop: { get_property: [ other_component,
>> other_component_prop ] }
>> > >
>> > >other_component:
>> > >  # ...
>> > >
>> > > I.e. you write property 'my_prop' of 'my_component' in its properties
>> > > section, and you read property 'other_component_prop' of
>> 'other_component'
>> > > using the get_property function.
>> > > ... we can also call them attributes, but use one name, not two
>> different
>> > > names for the same thing.
>> >
>> > IMO inputs (Properties) and outputs (Fn::GetAtt) are different things
>> > (and they exist in different namespaces), so -1 for giving them the same
>> > name.
>> >
>> > In an ideal world I'd like HOT to use so

[openstack-dev] [Glance] Team Meeting Reminder

[Mark Washenberger]

Hi folks,

Just reminding you that we'll have our meeting during the early timeslot
this week, at 14:00 UTC on October 24th. In your locale, that's
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Glance+Meeting&iso=20131022T14&ah=1.
The channel as always is #openstack-meeting-alt and all are welcome to
attend.

The agenda is currently forming at
https://etherpad.openstack.org/p/glance-team-meeting-agenda so feel free to
add any items you want to discuss.

Cheers,
markwash
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Common requirements for services' discussion

[Gary Duan]

I am sorry that I missed this morning's meeting.

Reading through the log, one thing that was briefly touch upon is to
support Service Type Framework for L3 router service. As all other services
(vpn, fw, lb, metering) will be integrated to the service framework in
I-release, L3 router service, as a major building block, shouldn't be
missed.

What we are thinking is to make L3 agent as one of plugin-drivers of L3
router services. This seems to align with comments during the meeting. I
wonder if there are enough interests to push this forward.

Thanks,
Gary


On Tue, Oct 22, 2013 at 9:55 AM, Sumit Naiksatam
wrote:

> Hi All,
>
> Here is a log of today's discussion:
>
>
> http://eavesdrop.openstack.org/meetings/networking_advanced_services/2013/networking_advanced_services.2013-10-22-15.32.log.html
>
> (some action items for a few folks who were present, we will follow up in
> the next meeting.)
>
> Thanks,
>
> ~Sumit.
>
>
>
>
> On Mon, Oct 21, 2013 at 11:08 PM, Sumit Naiksatam <
> sumitnaiksa...@gmail.com> wrote:
>
>> Hi All,
>>
>> This is a reminder for the next IRC meeting on Tuesday (Oct 22nd) 15.30
>> UTC (8.30 AM PDT) on the #openstack-meeting-alt channel.
>>
>> The proposed agenda is:
>> * Service insertion and chaining
>> * Service agents
>> * Service VMs - mechanism
>> * Service VMs - policy
>> * Extensible APIs for services
>> and anything else you may want to discuss in this context.
>>
>> Meeting wiki page (has pointer to the first meeting logs):
>> https://wiki.openstack.org/wiki/Meetings/AdvancedServices
>>
>> Thanks,
>> ~Sumit.
>>
>> On Thu, Oct 17, 2013 at 12:02 AM, Sumit Naiksatam <
>> sumitnaiksa...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> We will have the "advanced services" and the common requirements IRC
>>> meeting on Tuesdays 15.30 UTC (8.30 AM PDT) on the
>>> #openstack-meeting-alt channel. The meeting time was chosen to
>>> accommodate requests by folks in Asia and will hopefully suit most people
>>> involved. Please note that this is the alternate meeting channel.
>>>
>>> The agenda will be a continuation of discussion from the previous
>>> meeting with some additional agenda items based on the sessions already
>>> proposed for the summit. The current discussion is being captured in this
>>> etherpad:
>>> https://etherpad.openstack.org/p/NeutronAdvancedServices
>>>
>>> Hope you can make it and participate.
>>>
>>> Thanks,
>>> ~Sumit.
>>>
>>>
>>> On Mon, Oct 14, 2013 at 8:15 PM, Sumit Naiksatam <
>>> sumitnaiksa...@gmail.com> wrote:
>>>
 Thanks all for attending the IRC meeting today for the Neutron
 "advanced services" discussion. We have an etherpad for this:
 https://etherpad.openstack.org/p/NeutronAdvancedServices

 It was also felt that we need to have more ongoing discussions, so we
 will have follow up meetings. We will try to propose a more convenient time
 for everyone involved for a meeting next week. Meanwhile, we can continue
 to use the mailing list, etherpad, and/or comment on the specific 
 proposals.

 Thanks,
 ~Sumit.


 On Tue, Oct 8, 2013 at 8:30 PM, Sumit Naiksatam <
 sumitnaiksa...@gmail.com> wrote:

> Hi All,
>
> We had a VPNaaS meeting yesterday and it was felt that we should have
> a separate meeting to discuss the topics common to all services. So, in
> preparation for the Icehouse summit, I am proposing an IRC meeting on Oct
> 14th 22:00 UTC (immediately after the Neutron meeting) to discuss common
> aspects related to the FWaaS, LBaaS, and VPNaaS.
>
> We will begin with service insertion and chaining discussion, and I
> hope we can collect requirements for other common aspects such as service
> agents, services instances, etc. as well.
>
> Etherpad for service insertion & chaining can be found here:
>
> https://etherpad.openstack.org/icehouse-neutron-service-insertion-chaining
>
> Hope you all can join.
>
> Thanks,
> ~Sumit.
>
>
>

>>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion

[Robin Wang]

Hi Artem,

Very happy to see more stackers working on this feature. : )

"Note that the images in your document are badly corrupted - maybe my questions 
could already be answered by your diagrams. "
I met the same issue at first. Downloading the doc and open it locally may 
help. It works for me.

Also, a wiki page for DVR/VDR feature is created, including some interesting 
performance test output. Thanks.
https://wiki.openstack.org/wiki/Distributed_Router_for_OVS

Best,
Robin Wang

From: Artem Dmytrenko
Date: 2013-10-22 02:51
To: yong sheng gong \(gong...@unitedstack.com\); cloudbe...@gmail.com; 
OpenStack Development Mailing List
Subject: Re: [openstack-dev] Distributed Virtual Router Discussion
Hi Swaminathan.

I work for a virtual networking startup called Midokura and I'm very interested 
in joining the discussion. We currently have distributed router implementation 
using existing Neutron API. Could you clarify why distributed vs centrally 
located routing implementation need to be distinguished? Another question is 
that are you proposing distributed routing implementation for tenant routers or 
for the router connecting the virtual cloud to the external network? The reason 
that I'm asking this question is because our company would also like to propose 
a router implementation that would eliminate a single point uplink failures. We 
have submitted a couple blueprints on that topic 
(https://blueprints.launchpad.net/neutron/+spec/provider-router-support, 
https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing) and would 
appreciate an opportunity to collaborate on making it a reality.

Note that the images in your document are badly corrupted - maybe my questions 
could already be answered by your diagrams. Could you update your document with 
legible diagrams?

Looking forward to further discussing this topic with you!

Sincerely,
Artem Dmytrenko


On Mon, 10/21/13, Vasudevan, Swaminathan (PNB Roseville) 
 wrote:

 Subject: [openstack-dev] Distributed Virtual Router Discussion
 To: "yong sheng gong (gong...@unitedstack.com)" , 
"cloudbe...@gmail.com" , "OpenStack Development Mailing 
List (openstack-dev@lists.openstack.org)" 
 Date: Monday, October 21, 2013, 12:18 PM



  
  




 Hi Folks, 
 I am currently working on a
 blueprint for Distributed Virtual Router. 
 If anyone interested in
 being part of the discussion please let me know. 
 I have put together a first
 draft of my blueprint and have posted it on Launchpad for
 review. 
 https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr



 Thanks. 

 Swaminathan Vasudevan 
 Systems Software Engineer
 (TC) 


 HP Networking 
 Hewlett-Packard 
 8000 Foothills Blvd 
 M/S 5541 
 Roseville, CA - 95747 
 tel: 916.785.0937 
 fax: 916.785.1815 
 email: swaminathan.vasude...@hp.com







 -Inline Attachment Follows-

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion

[Vasudevan, Swaminathan (PNB Roseville)]

Hi Folks,
Thanks for your interests in the DVR feature.
We should get together to start discussing the details in the DVR.
Please let me know who else is interested, probably the time slot and we can 
start nailing down the details.
 https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
https://wiki.openstack.org/wiki/Distributed_Router_for_OVS
Thanks
Swami

From: Robin Wang [mailto:cloudbe...@gmail.com]
Sent: Tuesday, October 22, 2013 11:45 AM
To: Artem Dmytrenko; yong sheng gong (gong...@unitedstack.com); OpenStack 
Development Mailing List; Vasudevan, Swaminathan (PNB Roseville)
Subject: Re: Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion

Hi Artem,

Very happy to see more stackers working on this feature. : )

"Note that the images in your document are badly corrupted - maybe my questions 
could already be answered by your diagrams. "
I met the same issue at first. Downloading the doc and open it locally may 
help. It works for me.

Also, a wiki page for DVR/VDR feature is created, including some interesting 
performance test output. Thanks.
https://wiki.openstack.org/wiki/Distributed_Router_for_OVS

Best,
Robin Wang

From: Artem Dmytrenko
Date: 2013-10-22 02:51
To: yong sheng gong 
\(gong...@unitedstack.com\); 
cloudbe...@gmail.com; OpenStack Development 
Mailing List
Subject: Re: [openstack-dev] Distributed Virtual Router Discussion
Hi Swaminathan.

I work for a virtual networking startup called Midokura and I'm very interested 
in joining the discussion. We currently have distributed router implementation 
using existing Neutron API. Could you clarify why distributed vs centrally 
located routing implementation need to be distinguished? Another question is 
that are you proposing distributed routing implementation for tenant routers or 
for the router connecting the virtual cloud to the external network? The reason 
that I'm asking this question is because our company would also like to propose 
a router implementation that would eliminate a single point uplink failures. We 
have submitted a couple blueprints on that topic 
(https://blueprints.launchpad.net/neutron/+spec/provider-router-support, 
https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing) and would 
appreciate an opportunity to collaborate on making it a reality.

Note that the images in your document are badly corrupted - maybe my questions 
could already be answered by your diagrams. Could you update your document with 
legible diagrams?

Looking forward to further discussing this topic with you!

Sincerely,
Artem Dmytrenko


On Mon, 10/21/13, Vasudevan, Swaminathan (PNB Roseville) 
mailto:swaminathan.vasude...@hp.com>> wrote:

 Subject: [openstack-dev] Distributed Virtual Router Discussion
 To: "yong sheng gong 
(gong...@unitedstack.com)" 
mailto:gong...@unitedstack.com>>, 
"cloudbe...@gmail.com" 
mailto:cloudbe...@gmail.com>>, "OpenStack Development 
Mailing List 
(openstack-dev@lists.openstack.org)" 
mailto:openstack-dev@lists.openstack.org>>
 Date: Monday, October 21, 2013, 12:18 PM









 Hi Folks,
 I am currently working on a
 blueprint for Distributed Virtual Router.
 If anyone interested in
 being part of the discussion please let me know.
 I have put together a first
 draft of my blueprint and have posted it on Launchpad for
 review.
 https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr



 Thanks.

 Swaminathan Vasudevan
 Systems Software Engineer
 (TC)


 HP Networking
 Hewlett-Packard
 8000 Foothills Blvd
 M/S 5541
 Roseville, CA - 95747
 tel: 916.785.0937
 fax: 916.785.1815
 email: swaminathan.vasude...@hp.com







 -Inline Attachment Follows-

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Gerrit tools

[Joshua Harlow]

Sure I'll look it over :-)

Btw just uploaded: https://pypi.python.org/pypi/gerrit-view

Making it easier to install the 2 tools.

Have fun!

On 10/21/13 11:37 PM, "Flavio Percoco"  wrote:

>On 21/10/13 15:55 +, Joshua Harlow wrote:
>>I am using gerritlib in the curses ui; seems to work nicely.
>>
>>Only 1 thing that I don't like so much is that it silences
>>connection/other errors from what I can tell.
>>
>>See _run() method in
>>https://github.com/openstack-infra/gerritlib/blob/master/gerritlib/gerrit
>>.py
>
>I started migrating some of the OpenStack tools to python-gerrit a
>couple of months ago, I still have that code somewhere in my laptop, I
>hope.
>
>I think that gerritlib API could be improved a lot from python-gerrit,
>plus query combinations in gerritlib are a bit limited due to how
>they're expressed there. At least the last time I checked.
>
>I'll take some time in the next few weeks to work on that.
>
>@Joshua, do you mind taking a look at python-gerrit and provide some
>feedback or use it? :D
>
>Cheers,
>FF
>
>>
>>Otherwise pretty easy to use.
>>
>>Sent from my really tiny device...
>>
>>> On Oct 21, 2013, at 4:46 AM, "Sean Dague"  wrote:
>>>
 On 10/21/2013 04:04 AM, Flavio Percoco wrote:
> On 20/10/13 05:01 +, Joshua Harlow wrote:
> I created some gerrit tools that I think others might find useful.
>
> https://github.com/harlowja/gerrit_view


 I worked on this Python library for Gerrit[0] a couple of months ago
and
 I've been using it for this gerrit-cli[1] tool. I was wondering if
you'd
 like to migrate your Gerrit queries and make them use python-gerrit
 instead? I can do that for you.

 [0] https://github.com/FlaPer87/python-gerrit
 [1] https://github.com/FlaPer87/gerrit-cli

 BTW, Big +1 for the curses UI!
>>>
>>> Also realize that OpenStack maintains gerritlib -
>>>https://github.com/openstack-infra/gerritlib
>>>
>>> Which anyone can contribute to (and is the code that every message
>>>posted back to gerrit by a bot users). It would actually be nice to
>>>enhance gerritlib if there were enough features missing that are in
>>>python-gerrit.
>>>
>>>-Sean
>>>
>>> --
>>> Sean Dague
>>> http://dague.net
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>___
>>OpenStack-dev mailing list
>>OpenStack-dev@lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>-- 
>@flaper87
>Flavio Percoco
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] HOT Software configuration proposal

[Thomas Spatzier]

Stan Lagun  wrote on 22.10.2013 19:02:38:
> From: Stan Lagun 
> To: OpenStack Development Mailing List
,
> Date: 22.10.2013 19:06
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
> Hello,

> I've been reading through the thread and the wiki pages and I'm
> still confused by the terms. Is there a clear definition of what do
> we understand by component from user's and developer's point of
> view. If I write "component, type:MySQL" what is behind that
> definition? I mean how does the system know what exactly MySQL is

I think the current proposal is not that Heat would support very specific
component types (like MySQL, Apache, Tomcat etc.) but component is more of
a generic construct to represent a piece of software. The type attribute of
a component then just calls out the config management tool (e.g. Chef) to
install and configure that piece of software. By pointing a component to,
say, a Chef cookbook for setting up MySQL the runtime type would be MySQL.
That is at least my view on this.

I agree, however, that it needs to be straightened out how the term
"component" is really used.

> and how to install it? What MySQL version is it gonna be? Will it be
> x86 or x64? How does the system understand that I need MySQL for
> Windows on Windows VM rather then Linux MySQL? What do I as a
> developer need to do so that it would be possible to have "type:
> MyCoolComponentType"?
>

> On Tue, Oct 22, 2013 at 8:35 PM, Thomas Spatzier
 > wrote:
> Zane Bitter  wrote on 22.10.2013 17:23:52:
> > From: Zane Bitter 
> > To: openstack-dev@lists.openstack.org,
> > Date: 22.10.2013 17:26
> > Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
> >
> > On 22/10/13 16:35, Thomas Spatzier wrote:
> > > Zane Bitter  wrote on 22.10.2013 15:24:28:
> > >> From: Zane Bitter 
> > >> To: openstack-dev@lists.openstack.org,
> > >> Date: 22.10.2013 15:27
> > >> Subject: Re: [openstack-dev] [Heat] HOT Software configuration
> proposal
> > >>
> > >> On 22/10/13 09:15, Thomas Spatzier wrote:
> > >>> BTW, the convention of properties being input and attributes being
> > > output,
> > >>> i.e. that subtle distinction between properties and attributes is
not
> > >>> really intuitive, at least not to me as non-native speaker, because
I
> > > used
> > >>> to use both words as synonyms.
> > >>
> > >> As a native speaker, I can confidently state that it's not intuitive
> to
> > >> anyone ;)
> > >
> > > Phew, good to read that ;-)
> > >
> > >>
> > >> We unfortunately inherited these names from the Properties section
and
> > >> the Fn::GetAtt function in cfn templates. It's even worse than that,
> > >> because there's a whole category of... uh... things (DependsOn,
> > >> DeletionPolicy, &c.) that don't even have a name - I always have to
> > >> resist the urge to call them 'attributes' too.
> > >
> > > So is this something we should try to get straight in HOT while we
> still
> > > have the flexibility?
> >
> > Y-yes. Provided that we can do it without making things *more*
> > confusing, +1. That's hard though, because there are a number of places
> > we have to refer to them, all with different audiences:
> >   - HOT users
> >   - cfn users
> >   - Existing developers
> >   - New developers
> >   - Plugin developers
> >
> > and using different names for the same thing can cause problems. My
test
> > for this is: if you were helping a user on IRC debug an issue, is there
> > a high chance you would spend 15 minutes talking past each other
because
> > they misunderstand the terminology?

> Hm, good point. Seems like it would really cause more confusion than it
> helps. So back away from the general idea of renaming things that exist
> both in cfn and HOT.
> What we should try of course is to give new concepts that will only exist
> in HOT intuitive names.
>
> >
> > > Regarding properties/attributes for example, to me I would call both
> just
> > > properties of a resource or component, and then I can write them or
> read
> > > them like:
> > >
> > > components:
> > >    my_component:
> > >      type: ...
> > >      properties:
> > >        my_prop: { get_property: [ other_component,
> other_component_prop ] }
> > >
> > >    other_component:
> > >      # ...
> > >
> > > I.e. you write property 'my_prop' of 'my_component' in its properties
> > > section, and you read property 'other_component_prop' of
> 'other_component'
> > > using the get_property function.
> > > ... we can also call them attributes, but use one name, not two
> different
> > > names for the same thing.
> >
> > IMO inputs (Properties) and outputs (Fn::GetAtt) are different things
> > (and they exist in different namespaces), so -1 for giving them the
same
> > name.
> >
> > In an ideal world I'd like HOT to use something like get_output_data
(or
> > maybe just get_data), but OTOH we have e.g. FnGetAtt() and
> > attributes_schema baked in to the plugin API that we can't really
> > change, so it seems likely to lead to developers and users 

Re: [openstack-dev] [Heat] HOT Software configuration proposal

[Thomas Spatzier]

Georgy Okrokvertskhov  wrote on 22.10.2013
20:01:19:
> From: Georgy Okrokvertskhov 
> To: OpenStack Development Mailing List
,
> Date: 22.10.2013 20:05
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
> Hi,
>
> I would agree with Stan that we need to discuss definitions before
> going deeply to the implementation.
>
> The first example on the https://wiki.openstack.org/wiki/Heat/
> Blueprints/hot-software-config shows components like install_mysql
> and install_wordpress.

Good point. I also think that at least the examples currently used are more
of an "automation step" than a "component".
IMO component should represent some kind of software installation (e.g. a
web server, a DBMS, etc.), where automation is used under the covers to
install and configure that piece of software.
>From an orchestration point of view, a reasonable semantics would be that
when a component is in state CREATE_COMPLETE it is ready to use, e.g. a web
server is ready to serve applications. With respect to the automation that
was used to bring up the component, it would return successful (and this
would be signaled to Heat) when the component setup is done.

For example, the following could represent an Apache web server component,
installed using Chef:

components:
  apache:
type: OS::Heat::SoftwareConfig_Chef
cookbook: http://www.example.com/my_apache_cookbook.zip
properties:
  http_port: 8080

'apache' is just a name here that indicates of course what you get. The
type indicates that a component provide able to invoke Chef automation is
used. The cookbook attribute points to the cookbook to use, which will
install and configure apache. By setting the http_port property to 8080,
you provide input to the Chef cookbook. The SoftwareConfig_Chef component
provider will implement the logic to pass properties to the Chef invocation
in the right syntax.

> I would say that this is a bit confusing because I expected to see
> component definitions instead of software deployment definition
> process. I think this is a quite dangerous path here because this
> example shows us that we can use components as installation steps
> definition instead of real component definition.
> If one continue to do this approach and defines more and more
> granular steps as a components they will come to workflow definition
> composed in terms of components. This approach does not add either
> simplicity or clarity in the HOT template.
>
> Thanks
> Georgy
>
>

> On Tue, Oct 22, 2013 at 10:02 AM, Stan Lagun  wrote:
> Hello,

> I've been reading through the thread and the wiki pages and I'm
> still confused by the terms. Is there a clear definition of what do
> we understand by component from user's and developer's point of
> view. If I write "component, type:MySQL" what is behind that
> definition? I mean how does the system know what exactly MySQL is
> and how to install it? What MySQL version is it gonna be? Will it be
> x86 or x64? How does the system understand that I need MySQL for
> Windows on Windows VM rather then Linux MySQL? What do I as a
> developer need to do so that it would be possible to have "type:
> MyCoolComponentType"?
>

> On Tue, Oct 22, 2013 at 8:35 PM, Thomas Spatzier
 > wrote:
> Zane Bitter  wrote on 22.10.2013 17:23:52:
> > From: Zane Bitter 
> > To: openstack-dev@lists.openstack.org,
> > Date: 22.10.2013 17:26
> > Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
> >
> > On 22/10/13 16:35, Thomas Spatzier wrote:
> > > Zane Bitter  wrote on 22.10.2013 15:24:28:
> > >> From: Zane Bitter 
> > >> To: openstack-dev@lists.openstack.org,
> > >> Date: 22.10.2013 15:27
> > >> Subject: Re: [openstack-dev] [Heat] HOT Software configuration
> proposal
> > >>
> > >> On 22/10/13 09:15, Thomas Spatzier wrote:
> > >>> BTW, the convention of properties being input and attributes being
> > > output,
> > >>> i.e. that subtle distinction between properties and attributes is
not
> > >>> really intuitive, at least not to me as non-native speaker, because
I
> > > used
> > >>> to use both words as synonyms.
> > >>
> > >> As a native speaker, I can confidently state that it's not intuitive
> to
> > >> anyone ;)
> > >
> > > Phew, good to read that ;-)
> > >
> > >>
> > >> We unfortunately inherited these names from the Properties section
and
> > >> the Fn::GetAtt function in cfn templates. It's even worse than that,
> > >> because there's a whole category of... uh... things (DependsOn,
> > >> DeletionPolicy, &c.) that don't even have a name - I always have to
> > >> resist the urge to call them 'attributes' too.
> > >
> > > So is this something we should try to get straight in HOT while we
> still
> > > have the flexibility?
> >
> > Y-yes. Provided that we can do it without making things *more*
> > confusing, +1. That's hard though, because there are a number of places
> > we have to refer to them, all with different audiences:
> >   - HOT users
> >   - cfn users
> >   - Existing developers
> > 

[openstack-dev] [Trove] Replication and Clustering API

[Daniel Salinas]

We have drawn up a new spec for the clustering api which removes the
concept of a /clusters path as well as the need for the /clustertypes
path.  The spec lives here now:

https://wiki.openstack.org/wiki/Trove-Replication-And-Clustering-API

Initially I'd like to get eyes on this and see if we can't generate some
discussion.  This proposal is far reaching and will ultimately require a
major versioning of the trove API to support.  It is an amalgam of ideas
from Vipul, hub_cap and a few others but we feel like this gets us much
closer to having a more intuitive interface for users.  Please peruse the
document and lets start working through any issues.

I would like to discuss the API proposal tomorrow during our weekly meeting
but I would welcome comments/concerns on the mailing list as well.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] EC2 Compatibility metadata on config drive, fixed IP info

[Mate Lakat]

Hi,

We are looking at config drive use cases, and saw this in the official
docs:

  Do not rely on the presence of the EC2 metadata present in the config
  drive (i.e., files under the ec2 directory), as this content may be
  removed in a future release.

  http://docs.openstack.org/user-guide/content/config-drive.html
  
Do we have any information on when will that EC2 metadata be dropped?

I would like to get the fixed ip from the metadata, and I only found it
in the EC2 section.

Are there any plans to include the IP info in the OS metadata?

Thanks,
Mate

-- 
Mate Lakat

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [savanna] What's the recipe to build Oozie-4.0.0.tar.gz?

[Matthew Farrellee]

Having diskimage-create.sh is a great addition for the Savanna user 
community. It greatly simplifies the image building process (using DIB 
for those of you not familiar), making it repeatable and giving everyone 
a hope of debugging issues.


One thing it does is install oozie. It pulls oozie from 
http://savanna-files.mirantis.com/oozie-4.0.0.tar.gz


What's the recipe to create oozie-4.0.0.tar.gz?

Best,


matt

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Glance] Summit proposal deadline

[Mark Washenberger]

Hi folks,

Please submit any design summit session proposals in the next 24 hours.

markwash
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] Meeting Tuesday October 22nd at 19:00 UTC

[Elizabeth Krumbach Joseph]

On Mon, Oct 21, 2013 at 4:20 PM, Elizabeth Krumbach Joseph
 wrote:
> The OpenStack Infrastructure (Infra) team is hosting our weekly
> meeting tomorrow, Tuesday October 22nd, at 19:00 UTC in
> #openstack-meeting

Thanks to everyone who attended, meeting minutes and logs here:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-10-22-19.01.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-10-22-19.01.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-10-22-19.01.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2
http://www.princessleia.com

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [reviewstats] approved patches no longer count towards open reviews

[Robert Collins]

Russell instant-fixed an issue we found in the TripleO meeting this
morning: a patch ( https://review.openstack.org/#/c/52236/ ) was
approved but stalled waiting on a dependency to get fixed and land. We
noticed that patch because it was in the list of 'oldest patches', but
it was entirely non-actionable :).

Now, such patches are not listed at all, and won't contribute to the
statistics for open reviews. This makes sense because their status
isn't a reflection on the project at all : the submitter could rebase
the patch (if it's not a real dependency), or if it is a real
dependency, the dependency status will reflect appropriately (how long
it's been open, has it got reviews etc).

Anyhow, this is just a) thanks Russell! and b) a headsup if you notice
an old review but your stats are better - this is why - approved
reviews are not 'open'.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] meeting minutes

[Robert Collins]

09:01 <@openstack> Meeting ended Tue Oct 22 20:01:03 2013 UTC.
Information about MeetBot at
   http://wiki.debian.org/MeetBot . (v 0.1.4)
09:01 <@openstack> Minutes:

http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-10-22-19.01.html
09:01 <@openstack> Minutes (text):

http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-10-22-19.01.txt
09:01 <@openstack> Log:
http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-10-22-19.01.log.html

Thanks everyone for coming.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion

[Kyle Mestery (kmestery)]

Count me in on this discussion as well. May make sense to have a lightning talk 
at the summit, or an unconference slot.

On Oct 22, 2013, at 1:50 PM, "Vasudevan, Swaminathan (PNB Roseville)" 
 wrote:

> Hi Folks,
> Thanks for your interests in the DVR feature.
> We should get together to start discussing the details in the DVR.
> Please let me know who else is interested, probably the time slot and we can 
> start nailing down the details.
>  https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
> https://wiki.openstack.org/wiki/Distributed_Router_for_OVS
> Thanks
> Swami
>  
> From: Robin Wang [mailto:cloudbe...@gmail.com] 
> Sent: Tuesday, October 22, 2013 11:45 AM
> To: Artem Dmytrenko; yong sheng gong (gong...@unitedstack.com); OpenStack 
> Development Mailing List; Vasudevan, Swaminathan (PNB Roseville)
> Subject: Re: Re: [openstack-dev] [Neutron] Distributed Virtual Router 
> Discussion
>  
> Hi Artem,
>  
> Very happy to see more stackers working on this feature. : )
>  
> "Note that the images in your document are badly corrupted - maybe my 
> questions could already be answered by your diagrams. "
> I met the same issue at first. Downloading the doc and open it locally may 
> help. It works for me.
>  
> Also, a wiki page for DVR/VDR feature is created, including some interesting 
> performance test output. Thanks.
> https://wiki.openstack.org/wiki/Distributed_Router_for_OVS
>  
> Best,
> Robin Wang
>  
> From: Artem Dmytrenko
> Date: 2013-10-22 02:51
> To: yong sheng gong \(gong...@unitedstack.com\); cloudbe...@gmail.com; 
> OpenStack Development Mailing List
> Subject: Re: [openstack-dev] Distributed Virtual Router Discussion
> Hi Swaminathan.
>  
> I work for a virtual networking startup called Midokura and I'm very 
> interested in joining the discussion. We currently have distributed router 
> implementation using existing Neutron API. Could you clarify why distributed 
> vs centrally located routing implementation need to be distinguished? Another 
> question is that are you proposing distributed routing implementation for 
> tenant routers or for the router connecting the virtual cloud to the external 
> network? The reason that I'm asking this question is because our company 
> would also like to propose a router implementation that would eliminate a 
> single point uplink failures. We have submitted a couple blueprints on that 
> topic 
> (https://blueprints.launchpad.net/neutron/+spec/provider-router-support, 
> https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing) and would 
> appreciate an opportunity to collaborate on making it a reality.
>  
> Note that the images in your document are badly corrupted - maybe my 
> questions could already be answered by your diagrams. Could you update your 
> document with legible diagrams?
>  
> Looking forward to further discussing this topic with you!
>  
> Sincerely,
> Artem Dmytrenko
>  
> 
> On Mon, 10/21/13, Vasudevan, Swaminathan (PNB Roseville) 
>  wrote:
>  
>  Subject: [openstack-dev] Distributed Virtual Router Discussion
>  To: "yong sheng gong (gong...@unitedstack.com)" , 
> "cloudbe...@gmail.com" , "OpenStack Development Mailing 
> List (openstack-dev@lists.openstack.org)" 
>  Date: Monday, October 21, 2013, 12:18 PM
>  
>  
>  
>   
>   
>  
>  
>  
>  
>  Hi Folks, 
>  I am currently working on a
>  blueprint for Distributed Virtual Router. 
>  If anyone interested in
>  being part of the discussion please let me know. 
>  I have put together a first
>  draft of my blueprint and have posted it on Launchpad for
>  review. 
>  https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
>  
> 
> 
>  Thanks. 
> 
>  Swaminathan Vasudevan 
>  Systems Software Engineer
>  (TC) 
> 
> 
>  HP Networking 
>  Hewlett-Packard 
>  8000 Foothills Blvd 
>  M/S 5541 
>  Roseville, CA - 95747 
>  tel: 916.785.0937 
>  fax: 916.785.1815 
>  email: swaminathan.vasude...@hp.com
>  
> 
> 
>  
>  
>  
>  
>  -Inline Attachment Follows-
>  
>  ___
>  OpenStack-dev mailing list
>  OpenStack-dev@lists.openstack.org
>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] HOT Software configuration proposal

[Georgy Okrokvertskhov]

Hi Thomas,

I agree with you on semantics part. At the same time I see a potential
question which might appear - if semantics is limited by few states visible
for Heat engine, then who actually does software orchestration?
Will it be reasonable then to have software orchestration as separate
subproject for Heat as a part of "Orchestration" OpenStack program? Heat
engine will then do dependency tracking and will use components as a
reference for software orchestration engine which will perform actual
deployment and high level software components coordination.

This separated software orchestration engine may address all specific
requirements proposed by different teams in this thread without affecting
existing Heat engine.

Thanks
Georgy


On Tue, Oct 22, 2013 at 12:06 PM, Thomas Spatzier <
thomas.spatz...@de.ibm.com> wrote:

> Georgy Okrokvertskhov  wrote on 22.10.2013
> 20:01:19:
> > From: Georgy Okrokvertskhov 
> > To: OpenStack Development Mailing List
> ,
> > Date: 22.10.2013 20:05
> > Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
> >
> > Hi,
> >
> > I would agree with Stan that we need to discuss definitions before
> > going deeply to the implementation.
> >
> > The first example on the https://wiki.openstack.org/wiki/Heat/
> > Blueprints/hot-software-config shows components like install_mysql
> > and install_wordpress.
>
> Good point. I also think that at least the examples currently used are more
> of an "automation step" than a "component".
> IMO component should represent some kind of software installation (e.g. a
> web server, a DBMS, etc.), where automation is used under the covers to
> install and configure that piece of software.
> From an orchestration point of view, a reasonable semantics would be that
> when a component is in state CREATE_COMPLETE it is ready to use, e.g. a web
> server is ready to serve applications. With respect to the automation that
> was used to bring up the component, it would return successful (and this
> would be signaled to Heat) when the component setup is done.
>
> For example, the following could represent an Apache web server component,
> installed using Chef:
>
> components:
>   apache:
> type: OS::Heat::SoftwareConfig_Chef
> cookbook: http://www.example.com/my_apache_cookbook.zip
> properties:
>   http_port: 8080
>
> 'apache' is just a name here that indicates of course what you get. The
> type indicates that a component provide able to invoke Chef automation is
> used. The cookbook attribute points to the cookbook to use, which will
> install and configure apache. By setting the http_port property to 8080,
> you provide input to the Chef cookbook. The SoftwareConfig_Chef component
> provider will implement the logic to pass properties to the Chef invocation
> in the right syntax.
>
> > I would say that this is a bit confusing because I expected to see
> > component definitions instead of software deployment definition
> > process. I think this is a quite dangerous path here because this
> > example shows us that we can use components as installation steps
> > definition instead of real component definition.
> > If one continue to do this approach and defines more and more
> > granular steps as a components they will come to workflow definition
> > composed in terms of components. This approach does not add either
> > simplicity or clarity in the HOT template.
> >
> > Thanks
> > Georgy
> >
> >
>
> > On Tue, Oct 22, 2013 at 10:02 AM, Stan Lagun 
> wrote:
> > Hello,
>
> > I've been reading through the thread and the wiki pages and I'm
> > still confused by the terms. Is there a clear definition of what do
> > we understand by component from user's and developer's point of
> > view. If I write "component, type:MySQL" what is behind that
> > definition? I mean how does the system know what exactly MySQL is
> > and how to install it? What MySQL version is it gonna be? Will it be
> > x86 or x64? How does the system understand that I need MySQL for
> > Windows on Windows VM rather then Linux MySQL? What do I as a
> > developer need to do so that it would be possible to have "type:
> > MyCoolComponentType"?
> >
>
> > On Tue, Oct 22, 2013 at 8:35 PM, Thomas Spatzier
>  > > wrote:
> > Zane Bitter  wrote on 22.10.2013 17:23:52:
> > > From: Zane Bitter 
> > > To: openstack-dev@lists.openstack.org,
> > > Date: 22.10.2013 17:26
> > > Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
> > >
> > > On 22/10/13 16:35, Thomas Spatzier wrote:
> > > > Zane Bitter  wrote on 22.10.2013 15:24:28:
> > > >> From: Zane Bitter 
> > > >> To: openstack-dev@lists.openstack.org,
> > > >> Date: 22.10.2013 15:27
> > > >> Subject: Re: [openstack-dev] [Heat] HOT Software configuration
> > proposal
> > > >>
> > > >> On 22/10/13 09:15, Thomas Spatzier wrote:
> > > >>> BTW, the convention of properties being input and attributes being
> > > > output,
> > > >>> i.e. that subtle distinction between properties and attributes is
> not
> > 

[openstack-dev] [Neutron] FWaaS zone proposal - seeking feedback

[Sumit Naiksatam]

Hi All,

The Neutron FWaaS team would like to solicit your feedback on a proposal
for supporting Zones as a part of firewall support. The common definition
for zones involves the use of interfaces. In Neutron interfaces have a
one-to-one correspondence with Neutron ports. The current proposal is to
define zones based on Neutron ports. Source and destination zone arguments
can be added to the firewall rule. Placeholder blueprint is available here:
https://blueprints.launchpad.net/neutron/+spec/fwaas-zones-api

We will discuss this in tomorrow's FWaaS IRC meeting. Please join.

Thanks,
~Sumit.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] FWaaS IceHouse summit prep and IRC meeting

[Sumit Naiksatam]

Reminder - we will have the Neutron FWaaS IRC meeting tomorrow Wednesday
18:00 UTC (11 AM PDT).

Agenda:
* Tempest tests
* Definition and use of zones
* Address Objects
* Counts API
* Service Objects
* Integration with service type framework
* Open discussion - any other topics you would like to bring up for
discussion during the summit.

https://wiki.openstack.org/wiki/Meetings/FWaaS

Thanks,
~Sumit.


On Sun, Oct 13, 2013 at 1:56 PM, Sumit Naiksatam
wrote:

> Hi All,
>
> For the next of phase of FWaaS development we will be considering a number
> of features. I am proposing an IRC meeting on Oct 16th Wednesday 18:00 UTC
> (11 AM PDT) to discuss this.
>
> The etherpad for the summit session proposal is here:
> https://etherpad.openstack.org/p/icehouse-neutron-fwaas
>
> and has a high level list of features under consideration.
>
> Thanks,
> ~Sumit.
>
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion

[Ravi Chunduru]

Count me in as well.


On Tue, Oct 22, 2013 at 1:20 PM, Kyle Mestery (kmestery)  wrote:

> Count me in on this discussion as well. May make sense to have a lightning
> talk at the summit, or an unconference slot.
>
> On Oct 22, 2013, at 1:50 PM, "Vasudevan, Swaminathan (PNB Roseville)" <
> swaminathan.vasude...@hp.com> wrote:
>
> > Hi Folks,
> > Thanks for your interests in the DVR feature.
> > We should get together to start discussing the details in the DVR.
> > Please let me know who else is interested, probably the time slot and we
> can start nailing down the details.
> >  https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
> > https://wiki.openstack.org/wiki/Distributed_Router_for_OVS
> > Thanks
> > Swami
> >
> > From: Robin Wang [mailto:cloudbe...@gmail.com]
> > Sent: Tuesday, October 22, 2013 11:45 AM
> > To: Artem Dmytrenko; yong sheng gong (gong...@unitedstack.com);
> OpenStack Development Mailing List; Vasudevan, Swaminathan (PNB Roseville)
> > Subject: Re: Re: [openstack-dev] [Neutron] Distributed Virtual Router
> Discussion
> >
> > Hi Artem,
> >
> > Very happy to see more stackers working on this feature. : )
> >
> > "Note that the images in your document are badly corrupted - maybe my
> questions could already be answered by your diagrams. "
> > I met the same issue at first. Downloading the doc and open it locally
> may help. It works for me.
> >
> > Also, a wiki page for DVR/VDR feature is created, including some
> interesting performance test output. Thanks.
> > https://wiki.openstack.org/wiki/Distributed_Router_for_OVS
> >
> > Best,
> > Robin Wang
> >
> > From: Artem Dmytrenko
> > Date: 2013-10-22 02:51
> > To: yong sheng gong \(gong...@unitedstack.com\); cloudbe...@gmail.com;
> OpenStack Development Mailing List
> > Subject: Re: [openstack-dev] Distributed Virtual Router Discussion
> > Hi Swaminathan.
> >
> > I work for a virtual networking startup called Midokura and I'm very
> interested in joining the discussion. We currently have distributed router
> implementation using existing Neutron API. Could you clarify why
> distributed vs centrally located routing implementation need to be
> distinguished? Another question is that are you proposing distributed
> routing implementation for tenant routers or for the router connecting the
> virtual cloud to the external network? The reason that I'm asking this
> question is because our company would also like to propose a router
> implementation that would eliminate a single point uplink failures. We have
> submitted a couple blueprints on that topic (
> https://blueprints.launchpad.net/neutron/+spec/provider-router-support,
> https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing) and
> would appreciate an opportunity to collaborate on making it a reality.
> >
> > Note that the images in your document are badly corrupted - maybe my
> questions could already be answered by your diagrams. Could you update your
> document with legible diagrams?
> >
> > Looking forward to further discussing this topic with you!
> >
> > Sincerely,
> > Artem Dmytrenko
> >
> > 
> > On Mon, 10/21/13, Vasudevan, Swaminathan (PNB Roseville) <
> swaminathan.vasude...@hp.com> wrote:
> >
> >  Subject: [openstack-dev] Distributed Virtual Router Discussion
> >  To: "yong sheng gong (gong...@unitedstack.com)" <
> gong...@unitedstack.com>, "cloudbe...@gmail.com" ,
> "OpenStack Development Mailing List (openstack-dev@lists.openstack.org)" <
> openstack-dev@lists.openstack.org>
> >  Date: Monday, October 21, 2013, 12:18 PM
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >  Hi Folks,
> >  I am currently working on a
> >  blueprint for Distributed Virtual Router.
> >  If anyone interested in
> >  being part of the discussion please let me know.
> >  I have put together a first
> >  draft of my blueprint and have posted it on Launchpad for
> >  review.
> >  https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
> >
> >
> >
> >  Thanks.
> >
> >  Swaminathan Vasudevan
> >  Systems Software Engineer
> >  (TC)
> >
> >
> >  HP Networking
> >  Hewlett-Packard
> >  8000 Foothills Blvd
> >  M/S 5541
> >  Roseville, CA - 95747
> >  tel: 916.785.0937
> >  fax: 916.785.1815
> >  email: swaminathan.vasude...@hp.com
> >
> >
> >
> >
> >
> >
> >
> >  -Inline Attachment Follows-
> >
> >  ___
> >  OpenStack-dev mailing list
> >  OpenStack-dev@lists.openstack.org
> >  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Ravi
___
OpenStack-dev ma

Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion

[Carl Baldwin]

Swami,

I would like to participate in discussions as well.

Carl

On Tue, Oct 22, 2013 at 12:50 PM, Vasudevan, Swaminathan (PNB
Roseville)  wrote:
> Hi Folks,
>
> Thanks for your interests in the DVR feature.
>
> We should get together to start discussing the details in the DVR.
>
> Please let me know who else is interested, probably the time slot and we can
> start nailing down the details.
>
>  https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
>
> https://wiki.openstack.org/wiki/Distributed_Router_for_OVS
>
> Thanks
>
> Swami
>
>
>
> From: Robin Wang [mailto:cloudbe...@gmail.com]
> Sent: Tuesday, October 22, 2013 11:45 AM
> To: Artem Dmytrenko; yong sheng gong (gong...@unitedstack.com); OpenStack
> Development Mailing List; Vasudevan, Swaminathan (PNB Roseville)
> Subject: Re: Re: [openstack-dev] [Neutron] Distributed Virtual Router
> Discussion
>
>
>
> Hi Artem,
>
>
>
> Very happy to see more stackers working on this feature. : )
>
>
>
> "Note that the images in your document are badly corrupted - maybe my
> questions could already be answered by your diagrams. "
>
> I met the same issue at first. Downloading the doc and open it locally may
> help. It works for me.
>
>
>
> Also, a wiki page for DVR/VDR feature is created, including some interesting
> performance test output. Thanks.
>
> https://wiki.openstack.org/wiki/Distributed_Router_for_OVS
>
>
>
> Best,
>
> Robin Wang
>
>
>
> From: Artem Dmytrenko
>
> Date: 2013-10-22 02:51
>
> To: yong sheng gong \(gong...@unitedstack.com\); cloudbe...@gmail.com;
> OpenStack Development Mailing List
>
> Subject: Re: [openstack-dev] Distributed Virtual Router Discussion
>
> Hi Swaminathan.
>
>
>
> I work for a virtual networking startup called Midokura and I'm very
> interested in joining the discussion. We currently have distributed router
> implementation using existing Neutron API. Could you clarify why distributed
> vs centrally located routing implementation need to be distinguished?
> Another question is that are you proposing distributed routing
> implementation for tenant routers or for the router connecting the virtual
> cloud to the external network? The reason that I'm asking this question is
> because our company would also like to propose a router implementation that
> would eliminate a single point uplink failures. We have submitted a couple
> blueprints on that topic
> (https://blueprints.launchpad.net/neutron/+spec/provider-router-support,
> https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing) and
> would appreciate an opportunity to collaborate on making it a reality.
>
>
>
> Note that the images in your document are badly corrupted - maybe my
> questions could already be answered by your diagrams. Could you update your
> document with legible diagrams?
>
>
>
> Looking forward to further discussing this topic with you!
>
>
>
> Sincerely,
>
> Artem Dmytrenko
>
>
>
> 
>
> On Mon, 10/21/13, Vasudevan, Swaminathan (PNB Roseville)
>  wrote:
>
>
>
>  Subject: [openstack-dev] Distributed Virtual Router Discussion
>
>  To: "yong sheng gong (gong...@unitedstack.com)" ,
> "cloudbe...@gmail.com" , "OpenStack Development
> Mailing List (openstack-dev@lists.openstack.org)"
> 
>
>  Date: Monday, October 21, 2013, 12:18 PM
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>  Hi Folks,
>
>  I am currently working on a
>
>  blueprint for Distributed Virtual Router.
>
>  If anyone interested in
>
>  being part of the discussion please let me know.
>
>  I have put together a first
>
>  draft of my blueprint and have posted it on Launchpad for
>
>  review.
>
>  https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
>
>
>
>
>
>
>
>  Thanks.
>
>
>
>  Swaminathan Vasudevan
>
>  Systems Software Engineer
>
>  (TC)
>
>
>
>
>
>  HP Networking
>
>  Hewlett-Packard
>
>  8000 Foothills Blvd
>
>  M/S 5541
>
>  Roseville, CA - 95747
>
>  tel: 916.785.0937
>
>  fax: 916.785.1815
>
>  email: swaminathan.vasude...@hp.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>  -Inline Attachment Follows-
>
>
>
>  ___
>
>  OpenStack-dev mailing list
>
>  OpenStack-dev@lists.openstack.org
>
>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Incorporate Auditing Support / Usage Notifications

[Angus Salkeld]

On 21/10/13 15:11 -1000, Angus Salkeld wrote:

Hi all

There has been some interest in Heat generating usage notifications
http://summit.openstack.org/cfp/details/87

so I thought I'd implement the blueprint:
https://blueprints.launchpad.net/heat/+spec/send-notification

I'd like to ask for suggestions on the content of the notifications.
I have added a section for Heat here (please tell me if this is the
wrong place): https://wiki.openstack.org/wiki/SystemUsageData

My plan was to generate the notification on each stack state change
so as the wiki page says:
orchestration.stack.{create,update,delete,suspend,resume}.{start,error,end}

start maps to IN_PROGRESS
end maps to COMPLETE

If you have any other needs of the notification please respond.


I have a WIP here: https://review.openstack.org/#/c/53239/

-Angus



Thanks
Angus

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] HOT Software configuration proposal

[Clint Byrum]

Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40 -0700:
> Hi Thomas,
> 
> I agree with you on semantics part. At the same time I see a potential
> question which might appear - if semantics is limited by few states visible
> for Heat engine, then who actually does software orchestration?
> Will it be reasonable then to have software orchestration as separate
> subproject for Heat as a part of "Orchestration" OpenStack program? Heat
> engine will then do dependency tracking and will use components as a
> reference for software orchestration engine which will perform actual
> deployment and high level software components coordination.
> 
> This separated software orchestration engine may address all specific
> requirements proposed by different teams in this thread without affecting
> existing Heat engine.
> 

I'm not sure I know what "software orchestration" is, but I will take a
stab at a succinct definition:

Coordination of software configuration across multiple hosts.

If that is what you mean, then I believe what you actually want is
workflow. And for that, we have the Mistral project which was recently
announced [1].

Use that and you will simply need to define your desired workflow and
feed it into Mistral using a Mistral Heat resource. We can create a
nice bootstrapping resource for Heat instances that shims the mistral
workflow execution agent into machines (or lets us use one already there
via custom images).

I can imagine it working something like this:

resources:
  mistral_workflow_handle:
type: OS::Mistral::WorkflowHandle
  web_server:
type: OS::Nova::Server
components:
  mistral_agent:
component_type: mistral
params:
  workflow_: {ref: mistral_workflow_handle}
  mysql_server:
type: OS::Nova::Server
components:
  mistral_agent:
component_type: mistral
params:
  workflow_handle: {ref: mistral_workflow_handle}
  mistral_workflow:
type: OS::Mistral::Workflow
properties:
  handle: {ref: mistral_workflow_handle}
  workflow_reference: mysql_webapp_workflow
  params:
mysql_server: {ref: mysql_server}
webserver: {ref: web_server}


And then the workflow is just defined outside of the Heat template (ok
I'm sure somebody will want to embed it, but I prefer stronger
separation). Something like this gets uploaded as
"mysql_webapp_workflow":

[ 'step1': 'install_stuff',
  'step2': 'wait(step1)',
  'step3': 'allocate_sql_user(server=%mysql_server%)'
  'step4': 'credentials=wait_and_read(step3)'
  'step5': 'write_config_file(server=%webserver%)' ]

Or maybe it is declared as a graph, or whatever, but it is not Heat's
problem how to do workflows, it just feeds the necessary data from
orchestration into the workflow engine. This also means you can use a
non OpenStack workflow engine without any problems.

I think after having talked about this, we should have workflow live in
its own program.. we can always combine them if we want to, but having a
clear line would mean keeping the interfaces clean.

[1] http://lists.openstack.org/pipermail/openstack-dev/2013-October/016605.html

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Trove] Replication and Clustering API

[Georgy Okrokvertskhov]

Hi,

I don't see the replication type in the metadata replication contract. For
example someone can use MySQL Galera cluster with synchronous replication +
asynchronous replication master-slave for backup to remote site.

MS SQL offers alwaysON availability groups clustering with pair of
synchronous replication plus up to 3 nodes with asynchronous replication.
Also there are some existing different mechanisms like data mirroring
(synchronous or asynchronous) or log shipping.

So my point is that when you say replication, it is not obvious which type
of replication is used.

Thanks
Georgy




On Tue, Oct 22, 2013 at 12:37 PM, Daniel Salinas wrote:

> We have drawn up a new spec for the clustering api which removes the
> concept of a /clusters path as well as the need for the /clustertypes
> path.  The spec lives here now:
>
> https://wiki.openstack.org/wiki/Trove-Replication-And-Clustering-API
>
> Initially I'd like to get eyes on this and see if we can't generate some
> discussion.  This proposal is far reaching and will ultimately require a
> major versioning of the trove API to support.  It is an amalgam of ideas
> from Vipul, hub_cap and a few others but we feel like this gets us much
> closer to having a more intuitive interface for users.  Please peruse the
> document and lets start working through any issues.
>
> I would like to discuss the API proposal tomorrow during our weekly
> meeting but I would welcome comments/concerns on the mailing list as well.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Georgy Okrokvertskhov
Technical Program Manager,
Cloud and Infrastructure Services,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)

[Michael Basnight]

On Oct 22, 2013, at 10:35 AM, Michael Basnight wrote:

> Top posting cuz im a baller. We will get this fixed today. PS clint i like 
> the way you think ;)
> 
> https://review.openstack.org/#/c/53176/
> 

Now that this is merged, and there is no stable/havana for clients, Ive got a 
question. What do the package maintainers use for clients? the largest 
versioned tag? If so i can push a new version of the client for packaging.


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Openstack on power pc/Freescale linux

[Qing He]

All,
I'm wondering if anyone tried OpenStack on Power PC/ free scale Linux?

Thanks,
Qing

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Openstack on power pc/Freescale linux

[Matt Riedemann]

We run openstack on ppc64 with RHEL 6.4 using the powervm nova virt 
driver.  What do you want to know?



Thanks,

MATT RIEDEMANN
Advisory Software Engineer
Cloud Solutions and OpenStack Development

Phone: 1-507-253-7622 | Mobile: 1-507-990-1889
E-mail: mrie...@us.ibm.com


3605 Hwy 52 N
Rochester, MN 55901-1407
United States




From:   Qing He 
To: OpenStack Development Mailing List 
, 
Date:   10/22/2013 05:49 PM
Subject:[openstack-dev]  [nova] Openstack on power pc/Freescale 
linux



All,
I'm wondering if anyone tried OpenStack on Power PC/ free scale Linux?

Thanks,
Qing

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


<>___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] EC2 Compatibility metadata on config drive, fixed IP info

[Michael Still]

On Wed, Oct 23, 2013 at 6:48 AM, Mate Lakat  wrote:
> Hi,
>
> We are looking at config drive use cases, and saw this in the official
> docs:
>
>   Do not rely on the presence of the EC2 metadata present in the config
>   drive (i.e., files under the ec2 directory), as this content may be
>   removed in a future release.

Huh. That's news to me. I wonder why we'd bother implementing it if we
don't want people to use it?

>   http://docs.openstack.org/user-guide/content/config-drive.html
>
> Do we have any information on when will that EC2 metadata be dropped?
>
> I would like to get the fixed ip from the metadata, and I only found it
> in the EC2 section.
>
> Are there any plans to include the IP info in the OS metadata?

It shouldn't be hard to do... Can you file a bug to track it and let
me know the bug id?

Thanks,
Michael

-- 
Rackspace Australia

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] HOT Software configuration proposal

[Joshua Harlow]

Sounds like taskflow could be that program (+1 from me, ha)?

Mistral to me is a nice authenticated REST api + other goodies ontop of
something that reliably executes workflows.

But then what I described is also the majority of what openstack does
(authenticated REST api + other goodies ontop of VM/volume/network/...
workflows).

On 10/22/13 3:28 PM, "Clint Byrum"  wrote:

>Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40
>-0700:
>> Hi Thomas,
>> 
>> I agree with you on semantics part. At the same time I see a potential
>> question which might appear - if semantics is limited by few states
>>visible
>> for Heat engine, then who actually does software orchestration?
>> Will it be reasonable then to have software orchestration as separate
>> subproject for Heat as a part of "Orchestration" OpenStack program? Heat
>> engine will then do dependency tracking and will use components as a
>> reference for software orchestration engine which will perform actual
>> deployment and high level software components coordination.
>> 
>> This separated software orchestration engine may address all specific
>> requirements proposed by different teams in this thread without
>>affecting
>> existing Heat engine.
>> 
>
>I'm not sure I know what "software orchestration" is, but I will take a
>stab at a succinct definition:
>
>Coordination of software configuration across multiple hosts.
>
>If that is what you mean, then I believe what you actually want is
>workflow. And for that, we have the Mistral project which was recently
>announced [1].
>
>Use that and you will simply need to define your desired workflow and
>feed it into Mistral using a Mistral Heat resource. We can create a
>nice bootstrapping resource for Heat instances that shims the mistral
>workflow execution agent into machines (or lets us use one already there
>via custom images).
>
>I can imagine it working something like this:
>
>resources:
>  mistral_workflow_handle:
>type: OS::Mistral::WorkflowHandle
>  web_server:
>type: OS::Nova::Server
>components:
>  mistral_agent:
>component_type: mistral
>params:
>  workflow_: {ref: mistral_workflow_handle}
>  mysql_server:
>type: OS::Nova::Server
>components:
>  mistral_agent:
>component_type: mistral
>params:
>  workflow_handle: {ref: mistral_workflow_handle}
>  mistral_workflow:
>type: OS::Mistral::Workflow
>properties:
>  handle: {ref: mistral_workflow_handle}
>  workflow_reference: mysql_webapp_workflow
>  params:
>mysql_server: {ref: mysql_server}
>webserver: {ref: web_server}
>
>
>And then the workflow is just defined outside of the Heat template (ok
>I'm sure somebody will want to embed it, but I prefer stronger
>separation). Something like this gets uploaded as
>"mysql_webapp_workflow":
>
>[ 'step1': 'install_stuff',
>  'step2': 'wait(step1)',
>  'step3': 'allocate_sql_user(server=%mysql_server%)'
>  'step4': 'credentials=wait_and_read(step3)'
>  'step5': 'write_config_file(server=%webserver%)' ]
>
>Or maybe it is declared as a graph, or whatever, but it is not Heat's
>problem how to do workflows, it just feeds the necessary data from
>orchestration into the workflow engine. This also means you can use a
>non OpenStack workflow engine without any problems.
>
>I think after having talked about this, we should have workflow live in
>its own program.. we can always combine them if we want to, but having a
>clear line would mean keeping the interfaces clean.
>
>[1] 
>http://lists.openstack.org/pipermail/openstack-dev/2013-October/016605.htm
>l
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] HOT Software configuration proposal

[Georgy Okrokvertskhov]

Hi Clint,

Thank you for the detailed analysis.

>I'm not sure I know what "software orchestration" is, but I will take a
>stab at a succinct definition:

>Coordination of software configuration across multiple hosts.

Having this definition of "software orchestration" what will Heat
software orchestration component BP cover? I just trying to clarify for
myself what is Heat position and view on software orchestration based on
components and Heat view on workflows.

Right now it is not clear where is the separation line between component
and workflow. I think this blurred line introduced a lot of confusion in
this thread as some guys had a workflows based approach in mind and some
had component based view.

Thanks
Georgy



On Tue, Oct 22, 2013 at 3:28 PM, Clint Byrum  wrote:

> Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40 -0700:
> > Hi Thomas,
> >
> > I agree with you on semantics part. At the same time I see a potential
> > question which might appear - if semantics is limited by few states
> visible
> > for Heat engine, then who actually does software orchestration?
> > Will it be reasonable then to have software orchestration as separate
> > subproject for Heat as a part of "Orchestration" OpenStack program? Heat
> > engine will then do dependency tracking and will use components as a
> > reference for software orchestration engine which will perform actual
> > deployment and high level software components coordination.
> >
> > This separated software orchestration engine may address all specific
> > requirements proposed by different teams in this thread without affecting
> > existing Heat engine.
> >
>
> I'm not sure I know what "software orchestration" is, but I will take a
> stab at a succinct definition:
>
> Coordination of software configuration across multiple hosts.
>
> If that is what you mean, then I believe what you actually want is
> workflow. And for that, we have the Mistral project which was recently
> announced [1].
>
> Use that and you will simply need to define your desired workflow and
> feed it into Mistral using a Mistral Heat resource. We can create a
> nice bootstrapping resource for Heat instances that shims the mistral
> workflow execution agent into machines (or lets us use one already there
> via custom images).
>
> I can imagine it working something like this:
>
> resources:
>   mistral_workflow_handle:
> type: OS::Mistral::WorkflowHandle
>   web_server:
> type: OS::Nova::Server
> components:
>   mistral_agent:
> component_type: mistral
> params:
>   workflow_: {ref: mistral_workflow_handle}
>   mysql_server:
> type: OS::Nova::Server
> components:
>   mistral_agent:
> component_type: mistral
> params:
>   workflow_handle: {ref: mistral_workflow_handle}
>   mistral_workflow:
> type: OS::Mistral::Workflow
> properties:
>   handle: {ref: mistral_workflow_handle}
>   workflow_reference: mysql_webapp_workflow
>   params:
> mysql_server: {ref: mysql_server}
> webserver: {ref: web_server}
>
>
> And then the workflow is just defined outside of the Heat template (ok
> I'm sure somebody will want to embed it, but I prefer stronger
> separation). Something like this gets uploaded as
> "mysql_webapp_workflow":
>
> [ 'step1': 'install_stuff',
>   'step2': 'wait(step1)',
>   'step3': 'allocate_sql_user(server=%mysql_server%)'
>   'step4': 'credentials=wait_and_read(step3)'
>   'step5': 'write_config_file(server=%webserver%)' ]
>
> Or maybe it is declared as a graph, or whatever, but it is not Heat's
> problem how to do workflows, it just feeds the necessary data from
> orchestration into the workflow engine. This also means you can use a
> non OpenStack workflow engine without any problems.
>
> I think after having talked about this, we should have workflow live in
> its own program.. we can always combine them if we want to, but having a
> clear line would mean keeping the interfaces clean.
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2013-October/016605.html
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Georgy Okrokvertskhov
Technical Program Manager,
Cloud and Infrastructure Services,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] HOT Software configuration proposal

[Georgy Okrokvertskhov]

Hi Joshua,

>Sounds like taskflow could be that program (+1 from me, ha)?

>Mistral to me is a nice authenticated REST api + other goodies ontop of
>something that reliably executes workflows.

I would say that Mistral is a way to do this. My arguments are the
following:
1. Mistral decouples code. Heat can use API calls to invoke a workflows
execution instead of linking with taskflow library in the code. This is
standard SOA approach which OpenStack uses a lot.
2. Mistral will expose DSL to define tasks while taskflow will require
python code for task definition.

Mistral itself uses taskflow library to execute workflows but Mistral in
addition does parsing and translation from DSL task definition to actual
python code.

Heat can use taskflow for other purposes but workflows execution is not a
good reason for that. Just because of nature of workflows for deployment,
there is no knowledge about workflow until end user uploads it, so you can
not use taskflow itself and code this workflow in python without
preliminary knowledge about workflow.

If Heat uses just taskflow it should do all the work on workflow parsing
and translation to a code that Heat team wants to avoid. At least this is
my understanding.

Thanks
Georgy



On Tue, Oct 22, 2013 at 4:34 PM, Joshua Harlow wrote:

> Sounds like taskflow could be that program (+1 from me, ha)?
>
> Mistral to me is a nice authenticated REST api + other goodies ontop of
> something that reliably executes workflows.
>
> But then what I described is also the majority of what openstack does
> (authenticated REST api + other goodies ontop of VM/volume/network/...
> workflows).
>
> On 10/22/13 3:28 PM, "Clint Byrum"  wrote:
>
> >Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40
> >-0700:
> >> Hi Thomas,
> >>
> >> I agree with you on semantics part. At the same time I see a potential
> >> question which might appear - if semantics is limited by few states
> >>visible
> >> for Heat engine, then who actually does software orchestration?
> >> Will it be reasonable then to have software orchestration as separate
> >> subproject for Heat as a part of "Orchestration" OpenStack program? Heat
> >> engine will then do dependency tracking and will use components as a
> >> reference for software orchestration engine which will perform actual
> >> deployment and high level software components coordination.
> >>
> >> This separated software orchestration engine may address all specific
> >> requirements proposed by different teams in this thread without
> >>affecting
> >> existing Heat engine.
> >>
> >
> >I'm not sure I know what "software orchestration" is, but I will take a
> >stab at a succinct definition:
> >
> >Coordination of software configuration across multiple hosts.
> >
> >If that is what you mean, then I believe what you actually want is
> >workflow. And for that, we have the Mistral project which was recently
> >announced [1].
> >
> >Use that and you will simply need to define your desired workflow and
> >feed it into Mistral using a Mistral Heat resource. We can create a
> >nice bootstrapping resource for Heat instances that shims the mistral
> >workflow execution agent into machines (or lets us use one already there
> >via custom images).
> >
> >I can imagine it working something like this:
> >
> >resources:
> >  mistral_workflow_handle:
> >type: OS::Mistral::WorkflowHandle
> >  web_server:
> >type: OS::Nova::Server
> >components:
> >  mistral_agent:
> >component_type: mistral
> >params:
> >  workflow_: {ref: mistral_workflow_handle}
> >  mysql_server:
> >type: OS::Nova::Server
> >components:
> >  mistral_agent:
> >component_type: mistral
> >params:
> >  workflow_handle: {ref: mistral_workflow_handle}
> >  mistral_workflow:
> >type: OS::Mistral::Workflow
> >properties:
> >  handle: {ref: mistral_workflow_handle}
> >  workflow_reference: mysql_webapp_workflow
> >  params:
> >mysql_server: {ref: mysql_server}
> >webserver: {ref: web_server}
> >
> >
> >And then the workflow is just defined outside of the Heat template (ok
> >I'm sure somebody will want to embed it, but I prefer stronger
> >separation). Something like this gets uploaded as
> >"mysql_webapp_workflow":
> >
> >[ 'step1': 'install_stuff',
> >  'step2': 'wait(step1)',
> >  'step3': 'allocate_sql_user(server=%mysql_server%)'
> >  'step4': 'credentials=wait_and_read(step3)'
> >  'step5': 'write_config_file(server=%webserver%)' ]
> >
> >Or maybe it is declared as a graph, or whatever, but it is not Heat's
> >problem how to do workflows, it just feeds the necessary data from
> >orchestration into the workflow engine. This also means you can use a
> >non OpenStack workflow engine without any problems.
> >
> >I think after having talked about this, we should have workflow live in
> >its own program.. we can always combine them if we want to, but having a
> >clear line would mean keeping t

Re: [openstack-dev] [Heat] HOT Software configuration proposal

[Joshua Harlow]

Ah,

Seems like a reasonable approach then :-)

I guess then heat is mainly doing top-level orchestration, and then mistral 
does the workflow middle-level, and taskflow is (hopefully) at the 
lowest-level??

Thanks Georgy!

From: Georgy Okrokvertskhov 
mailto:gokrokvertsk...@mirantis.com>>
Reply-To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, October 22, 2013 4:53 PM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal

Hi Joshua,

>Sounds like taskflow could be that program (+1 from me, ha)?

>Mistral to me is a nice authenticated REST api + other goodies ontop of
>something that reliably executes workflows.

I would say that Mistral is a way to do this. My arguments are the following:
1. Mistral decouples code. Heat can use API calls to invoke a workflows 
execution instead of linking with taskflow library in the code. This is 
standard SOA approach which OpenStack uses a lot.
2. Mistral will expose DSL to define tasks while taskflow will require python 
code for task definition.

Mistral itself uses taskflow library to execute workflows but Mistral in 
addition does parsing and translation from DSL task definition to actual python 
code.

Heat can use taskflow for other purposes but workflows execution is not a good 
reason for that. Just because of nature of workflows for deployment, there is 
no knowledge about workflow until end user uploads it, so you can not use 
taskflow itself and code this workflow in python without preliminary knowledge 
about workflow.

If Heat uses just taskflow it should do all the work on workflow parsing and 
translation to a code that Heat team wants to avoid. At least this is my 
understanding.

Thanks
Georgy



On Tue, Oct 22, 2013 at 4:34 PM, Joshua Harlow 
mailto:harlo...@yahoo-inc.com>> wrote:
Sounds like taskflow could be that program (+1 from me, ha)?

Mistral to me is a nice authenticated REST api + other goodies ontop of
something that reliably executes workflows.

But then what I described is also the majority of what openstack does
(authenticated REST api + other goodies ontop of VM/volume/network/...
workflows).

On 10/22/13 3:28 PM, "Clint Byrum" mailto:cl...@fewbar.com>> 
wrote:

>Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40
>-0700:
>> Hi Thomas,
>>
>> I agree with you on semantics part. At the same time I see a potential
>> question which might appear - if semantics is limited by few states
>>visible
>> for Heat engine, then who actually does software orchestration?
>> Will it be reasonable then to have software orchestration as separate
>> subproject for Heat as a part of "Orchestration" OpenStack program? Heat
>> engine will then do dependency tracking and will use components as a
>> reference for software orchestration engine which will perform actual
>> deployment and high level software components coordination.
>>
>> This separated software orchestration engine may address all specific
>> requirements proposed by different teams in this thread without
>>affecting
>> existing Heat engine.
>>
>
>I'm not sure I know what "software orchestration" is, but I will take a
>stab at a succinct definition:
>
>Coordination of software configuration across multiple hosts.
>
>If that is what you mean, then I believe what you actually want is
>workflow. And for that, we have the Mistral project which was recently
>announced [1].
>
>Use that and you will simply need to define your desired workflow and
>feed it into Mistral using a Mistral Heat resource. We can create a
>nice bootstrapping resource for Heat instances that shims the mistral
>workflow execution agent into machines (or lets us use one already there
>via custom images).
>
>I can imagine it working something like this:
>
>resources:
>  mistral_workflow_handle:
>type: OS::Mistral::WorkflowHandle
>  web_server:
>type: OS::Nova::Server
>components:
>  mistral_agent:
>component_type: mistral
>params:
>  workflow_: {ref: mistral_workflow_handle}
>  mysql_server:
>type: OS::Nova::Server
>components:
>  mistral_agent:
>component_type: mistral
>params:
>  workflow_handle: {ref: mistral_workflow_handle}
>  mistral_workflow:
>type: OS::Mistral::Workflow
>properties:
>  handle: {ref: mistral_workflow_handle}
>  workflow_reference: mysql_webapp_workflow
>  params:
>mysql_server: {ref: mysql_server}
>webserver: {ref: web_server}
>
>
>And then the workflow is just defined outside of the Heat template (ok
>I'm sure somebody will want to embed it, but I prefer stronger
>separation). Something like this gets uploaded as
>"mysql_webapp_workflow":
>
>[ 'step1': 'install_stuff',
>  'step2': 'wait(step1)',
>  'step3': 'allocate_sql_user(server=%mysql_server%)'
>  'step4': 'credentials=wait_and_read(step3)'
>  'step5': 'write_config_file(server=

Re: [openstack-dev] [Heat] HOT Software configuration proposal

[Georgy Okrokvertskhov]

Hi,

>I guess then heat is mainly doing top-level orchestration, and then
mistral does the workflow middle-level, and >taskflow is (hopefully) at the
lowest-level??

You drove the right picture. I can not say who is top-level and who is
low-level orchestration. This is all gear wheels which should work all
together well to achieve the result while Het is probably the driving wheel
among them who makes sure that everything  is working.

Thanks
Georgy


On Tue, Oct 22, 2013 at 5:14 PM, Joshua Harlow wrote:

>  Ah,
>
>  Seems like a reasonable approach then :-)
>
>  I guess then heat is mainly doing top-level orchestration, and then
> mistral does the workflow middle-level, and taskflow is (hopefully) at the
> lowest-level??
>
>  Thanks Georgy!
>
>   From: Georgy Okrokvertskhov 
> Reply-To: OpenStack Development Mailing List <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, October 22, 2013 4:53 PM
>
> To: OpenStack Development Mailing List 
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
>   Hi Joshua,
>
>  >Sounds like taskflow could be that program (+1 from me, ha)?
>
> >Mistral to me is a nice authenticated REST api + other goodies ontop of
> >something that reliably executes workflows.
>
>  I would say that Mistral is a way to do this. My arguments are the
> following:
> 1. Mistral decouples code. Heat can use API calls to invoke a workflows
> execution instead of linking with taskflow library in the code. This is
> standard SOA approach which OpenStack uses a lot.
> 2. Mistral will expose DSL to define tasks while taskflow will require
> python code for task definition.
>
>  Mistral itself uses taskflow library to execute workflows but Mistral in
> addition does parsing and translation from DSL task definition to actual
> python code.
>
>  Heat can use taskflow for other purposes but workflows execution is not
> a good reason for that. Just because of nature of workflows for deployment,
> there is no knowledge about workflow until end user uploads it, so you can
> not use taskflow itself and code this workflow in python without
> preliminary knowledge about workflow.
>
>  If Heat uses just taskflow it should do all the work on workflow parsing
> and translation to a code that Heat team wants to avoid. At least this is
> my understanding.
>
>  Thanks
> Georgy
>
>
>
> On Tue, Oct 22, 2013 at 4:34 PM, Joshua Harlow wrote:
>
>> Sounds like taskflow could be that program (+1 from me, ha)?
>>
>> Mistral to me is a nice authenticated REST api + other goodies ontop of
>> something that reliably executes workflows.
>>
>> But then what I described is also the majority of what openstack does
>> (authenticated REST api + other goodies ontop of VM/volume/network/...
>> workflows).
>>
>> On 10/22/13 3:28 PM, "Clint Byrum"  wrote:
>>
>> >Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40
>> >-0700:
>> >> Hi Thomas,
>> >>
>> >> I agree with you on semantics part. At the same time I see a potential
>> >> question which might appear - if semantics is limited by few states
>> >>visible
>> >> for Heat engine, then who actually does software orchestration?
>> >> Will it be reasonable then to have software orchestration as separate
>> >> subproject for Heat as a part of "Orchestration" OpenStack program?
>> Heat
>> >> engine will then do dependency tracking and will use components as a
>> >> reference for software orchestration engine which will perform actual
>> >> deployment and high level software components coordination.
>> >>
>> >> This separated software orchestration engine may address all specific
>> >> requirements proposed by different teams in this thread without
>> >>affecting
>> >> existing Heat engine.
>> >>
>> >
>> >I'm not sure I know what "software orchestration" is, but I will take a
>> >stab at a succinct definition:
>> >
>> >Coordination of software configuration across multiple hosts.
>> >
>> >If that is what you mean, then I believe what you actually want is
>> >workflow. And for that, we have the Mistral project which was recently
>> >announced [1].
>> >
>> >Use that and you will simply need to define your desired workflow and
>> >feed it into Mistral using a Mistral Heat resource. We can create a
>> >nice bootstrapping resource for Heat instances that shims the mistral
>> >workflow execution agent into machines (or lets us use one already there
>> >via custom images).
>> >
>> >I can imagine it working something like this:
>> >
>> >resources:
>> >  mistral_workflow_handle:
>> >type: OS::Mistral::WorkflowHandle
>> >  web_server:
>> >type: OS::Nova::Server
>> >components:
>> >  mistral_agent:
>> >component_type: mistral
>> >params:
>> >  workflow_: {ref: mistral_workflow_handle}
>> >  mysql_server:
>> >type: OS::Nova::Server
>> >components:
>> >  mistral_agent:
>> >component_type: mistral
>> >params:
>> >  workflow_handle: {ref: mistral_workflow_handle}
>> >  mistral_workflow:
>

Re: [openstack-dev] [nova] Openstack on power pc/Freescale linux

[Qing He]

Thanks Matt.
I'd like know if anyone has tried to run the controller, API server and MySql 
database, msg queue, etc-the brain of the openstack, on ppc.
Qing

From: Matt Riedemann [mailto:mrie...@us.ibm.com]
Sent: Tuesday, October 22, 2013 4:17 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [nova] Openstack on power pc/Freescale linux

We run openstack on ppc64 with RHEL 6.4 using the powervm nova virt driver.  
What do you want to know?



Thanks,

MATT RIEDEMANN
Advisory Software Engineer
Cloud Solutions and OpenStack Development


Phone: 1-507-253-7622 | Mobile: 1-507-990-1889
E-mail: mrie...@us.ibm.com

[IBM]

3605 Hwy 52 N
Rochester, MN 55901-1407
United States






From:Qing He mailto:qing...@radisys.com>>
To:OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>,
Date:10/22/2013 05:49 PM
Subject:[openstack-dev]  [nova] Openstack on power pc/Freescale linux




All,
I'm wondering if anyone tried OpenStack on Power PC/ free scale Linux?

Thanks,
Qing

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

<>___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Distributed Virtual Router Discussion

[Brian Haley]

Hi Swami,

I would like to participate as well.

-Brian

On 10/21/2013 12:18 PM, Vasudevan, Swaminathan (PNB Roseville) wrote:
> Hi Folks,
> 
> I am currently working on a blueprint for Distributed Virtual Router.
> 
> If anyone interested in being part of the discussion please let me know.
> 
> I have put together a first draft of my blueprint and have posted it on
> Launchpad for review.
> 
> https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
> 
>  
> 
>  
> 
> Thanks.
> 
>  
> 
> Swaminathan Vasudevan
> 
> Systems Software Engineer (TC)
> 
>  
> 
>  
> 
> HP Networking
> 
> Hewlett-Packard
> 
> 8000 Foothills Blvd
> 
> M/S 5541
> 
> Roseville, CA - 95747
> 
> tel: 916.785.0937
> 
> fax: 916.785.1815
> 
> email: swaminathan.vasude...@hp.com 
> 
>  
> 
>  
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Openstack on power pc/Freescale linux

[Matt Riedemann]

Yeah, my team does.  We're using openvswitch 1.10, qpid 0.22, DB2 10.5 
(but MySQL also works).  Do you have specific issues/questions?

We're working on getting continuous integration testing working for the 
nova powervm driver in the icehouse release, so you can see some more 
details about what we're doing with openstack on power in this thread:

http://lists.openstack.org/pipermail/openstack-dev/2013-October/016395.html 




Thanks,

MATT RIEDEMANN
Advisory Software Engineer
Cloud Solutions and OpenStack Development

Phone: 1-507-253-7622 | Mobile: 1-507-990-1889
E-mail: mrie...@us.ibm.com


3605 Hwy 52 N
Rochester, MN 55901-1407
United States




From:   Qing He 
To: OpenStack Development Mailing List 
, 
Date:   10/22/2013 07:43 PM
Subject:Re: [openstack-dev] [nova] Openstack on power pc/Freescale 
linux



Thanks Matt.
I’d like know if anyone has tried to run the controller, API server and 
MySql database, msg queue, etc—the brain of the openstack, on ppc.
Qing
 
From: Matt Riedemann [mailto:mrie...@us.ibm.com] 
Sent: Tuesday, October 22, 2013 4:17 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [nova] Openstack on power pc/Freescale linux
 
We run openstack on ppc64 with RHEL 6.4 using the powervm nova virt 
driver.  What do you want to know?



Thanks, 

MATT RIEDEMANN
Advisory Software Engineer
Cloud Solutions and OpenStack Development 


Phone: 1-507-253-7622 | Mobile: 1-507-990-1889
E-mail: mrie...@us.ibm.com 


3605 Hwy 52 N
Rochester, MN 55901-1407
United States





From:Qing He  
To:OpenStack Development Mailing List <
openstack-dev@lists.openstack.org>, 
Date:10/22/2013 05:49 PM 
Subject:[openstack-dev]  [nova] Openstack on power pc/Freescale 
linux 




All,
I'm wondering if anyone tried OpenStack on Power PC/ free scale Linux?

Thanks,
Qing

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


<><>___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Openstack on power pc/Freescale linux

[Qing He]

Matt,

Great.
Yes, what processor and free scale version you are running on? Do you have 
something for tryout?

Thanks,
Qing

From: Matt Riedemann [mailto:mrie...@us.ibm.com]
Sent: Tuesday, October 22, 2013 8:11 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [nova] Openstack on power pc/Freescale linux

Yeah, my team does.  We're using openvswitch 1.10, qpid 0.22, DB2 10.5 (but 
MySQL also works).  Do you have specific issues/questions?

We're working on getting continuous integration testing working for the nova 
powervm driver in the icehouse release, so you can see some more details about 
what we're doing with openstack on power in this thread:

http://lists.openstack.org/pipermail/openstack-dev/2013-October/016395.html



Thanks,

MATT RIEDEMANN
Advisory Software Engineer
Cloud Solutions and OpenStack Development


Phone: 1-507-253-7622 | Mobile: 1-507-990-1889
E-mail: mrie...@us.ibm.com

[IBM]

3605 Hwy 52 N
Rochester, MN 55901-1407
United States






From:Qing He mailto:qing...@radisys.com>>
To:OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>,
Date:10/22/2013 07:43 PM
Subject:Re: [openstack-dev] [nova] Openstack on power pc/Freescale linux




Thanks Matt.
I’d like know if anyone has tried to run the controller, API server and MySql 
database, msg queue, etc—the brain of the openstack, on ppc.
Qing

From: Matt Riedemann [mailto:mrie...@us.ibm.com]
Sent: Tuesday, October 22, 2013 4:17 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [nova] Openstack on power pc/Freescale linux

We run openstack on ppc64 with RHEL 6.4 using the powervm nova virt driver.  
What do you want to know?



Thanks,

MATT RIEDEMANN
Advisory Software Engineer
Cloud Solutions and OpenStack Development


Phone: 1-507-253-7622 | Mobile: 1-507-990-1889
E-mail: mrie...@us.ibm.com

[IBM]

3605 Hwy 52 N
Rochester, MN 55901-1407
United States







From:Qing He mailto:qing...@radisys.com>>
To:OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>,
Date:10/22/2013 05:49 PM
Subject:[openstack-dev]  [nova] Openstack on power pc/Freescale linux






All,
I'm wondering if anyone tried OpenStack on Power PC/ free scale Linux?

Thanks,
Qing

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<>___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] Update: Nova API List for Missing Tempest Tests

[Christopher Yeoh]

On Tue, Oct 22, 2013 at 9:22 PM, Masayuki Igawa wrote:

> Hi, Ivan
>
> Thank you for your information. And I'm sorry for delay reply.
>
> > Hi,
> >
> > I also collect the tests status for nova v3 api manually. You can find
> the status of v3 tests in this link:
> https://etherpad.openstack.org/p/nova-v3-tests
> >
> > Because there are some extensions that just extend the attribute of
> specific api reponse, or convert some input before specific api
> > called. There is no url for these extension, but I think we also need
> check them. I collect the tempest tests according to the nova api code.
> check tests to the action
> > one by one, list the status file by file.
>
> I have a question. Is there any way to list the nova v3 apis?
> If so, I think the checking process of the test implementation can be
> automatically.
>

Should be able to dump the api list in a similar way for V2 as well as V3 -
print the mapper
in APIRouter or APIRouterV3. It does look like the V2 list is not complete.
Still need to make sure those that
just extend the functionality of existing routes is included as well though
(I think that may have to be done
manually)

Regards,

Chris







> Best Regards,
> -- Masayuki Igawa
>
>
> >
> > Due to these patch https://review.openstack.org/#/c/39609/ and
> https://review.openstack.org/#/c/39621/ are still under reviewing. so we
> can't add tempest test for nova v3 api. (almost existing tests have been
> ported into v3, but these patches depend on the 39609 and 39621).  The
> status of porting existing tests is also listed in this link. we will add
> the missing tests in v2
> > firstly, when it can be ported into v3, will port it.
> >
> > Best Regards
> > Ivan Zhu
> >
> > On 2013年10月15日 14:25, Masayuki Igawa wrote:
> >
> >
> >   Hi,
> >
> >   First, thank you to an anonymous for updating this list!
> >   -> GET /{project_id}/servers/:server_id/diagnostics
> >
> >   And, I have updated: Nova API List for Missing Tempest Tests.
> >
> https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc
> >
> >   The summary of this list:
> >   different count from
> >   Tested or not # of APIs ratio   the last time
> >   ---
> >   Tested API  124  49.6%  +2
> >   Not Tested API   66  26.4%  -2
> >   Not Need to Test(*1) 60  24.0%   0
> >   ---
> >   Total(*2):  250 100.0%   0
> >   (*1) Because they are deprecated APIs such as nova-network and
> volume.
> >   (*2) not included v3 APIs
> >
> >   The tempest version is:
> >commit f55f4e54ceab7c6a4d330f92c8059e46233e3560
> >Merge: 86ab238 062e30a
> >Author: Jenkins   jenk...@review.openstack.org>
> >Date:   Mon Oct 14 15:55:59 2013 +
> >
> >   By the way, I saw a design summit proposal related to this
> topic(*3). I think
> >   this information should be generated automatically. So I'd like to
> talk about
> >   this topic at the summit session.
> >   (*3) Coverage analysis tooling:
> http://summit.openstack.org/cfp/details/171
> >
> >   This information would be useful for creating Tempest tests.
> >   Any comments/questions/suggestions are welcome.
> >
> >   Best Regards,
> >   -- Masayuki Igawa
> >
> >
> >
> >   Hi,
> >
> >   # I'm sorry for this resending because my last mail has
> unnecessary messages.
> >
> >
> >   I have updated: Nova API List for Missing Tempest Tests.
> >
> https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc
> >
> >   The summary of this list:
> >   different count
> from
> >   Tested or not# of APIs  ratio   the last time
> >   ---
> >   Tested API  122  48.8%  +5
> >   Not Tested API   68  27.2%  -5
> >   Not Need to Test(*1) 60  24.0%   0
> >   ---
> >   Total(*2):  250 100.0%   0
> >
> >   (*1) Because they are deprecated APIs such as nova-network
> and volume.
> >   (*2) not included v3 APIs
> >
> >   I hope this information would be helpful for creating
> Tempest tests.
> >   Any comments and questions are welcome.
> >
> >   Best Regards,
> >   -- Masayuki Igawa
> >
> >
> >
> >   Hi, Tempest developers
> >
> >   I have made:
> >Nova API List for Missing Tempest Tests.
> >
> https://docs.g

Re: [openstack-dev] [scheduler] APIs for Smart Resource Placement - Updated Instance Group Model and API extension model - WIP Draft

[Mike Spreitzer]

"Yathiraj Udupi (yudupi)"  wrote on 10/15/2013 03:08:32 
AM:

> I have made some edits to the document: https://docs.google.com/
> document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?pli=1# 
> ...

One other minor thing to discuss in the modeling is metadata.  I am not 
eager to totally gorp up the model, but shouldn't all sorts of things 
allow metadata?

Thanks,
Mike___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev