Re: [openstack-dev] iso8601 filling up nova logs

[Davanum Srinivas]

+1 - looks like this is where you need to add it [1], if so, the
change needs to be in oslo-incubator repo first [2], so please submit
a review there

[1] 
https://github.com/openstack/nova/blob/master/nova/openstack/common/log.py#L128
[2] 
https://github.com/openstack/oslo-incubator/blob/master/openstack/common/log.py#L130

On Thu, Nov 7, 2013 at 3:45 PM, Tracy Jones  wrote:
> My nova logs are full of this - is it ok if I make a change to the default
> log level to set iso8601 to WARN?
>
> 2:39:54.683 DEBUG iso8601.iso8601 [-] Parsed 2013-11-06T06:38:00Z into
> {'tz_sign': None, 'second_fraction': None, 'hour': u'06', 'tz_hour': None,
> 'month': u'11', 'timezone': u'Z', 'second': u'00', 'tz_minute': None,
> 'year': u'2013', 'separator': u'T', 'day': u'06', 'minute': u'38'} with
> default timezone  from (pid=14941)
> parse_date /usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:166
> 2013-11-05 22:39:54.684 DEBUG iso8601.iso8601 [-] Got u'2013' for 'year'
> with default None from (pid=14941) to_int
> /usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
> 2013-11-05 22:39:54.684 DEBUG iso8601.iso8601 [-] Got u'11' for 'month' with
> default None from (pid=14941) to_int
> /usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
> 2013-11-05 22:39:54.684 DEBUG iso8601.iso8601 [-] Got u'06' for 'day' with
> default None from (pid=14941) to_int
> /usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
> 2013-11-05 22:39:54.685 DEBUG iso8601.iso8601 [-] Got u'06' for 'hour' with
> default None from (pid=14941) to_int
> /usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
> 2013-11-05 22:39:54.685 DEBUG iso8601.iso8601 [-] Got u'38' for 'minute'
> with default None from (pid=14941) to_int
> /usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
> 2013-11-05 22:39:54.685 DEBUG iso8601.iso8601 [-] Got u'00' for 'second'
> with default None from (pid=14941) to_int
> /usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
> 2013-11-05 22:39:54.686 DEBUG iso8601.iso8601 [-] Parsed 2013-11-0
>
>
>
> ___
> 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] [Openstack] [Neutron] Security groups issue when running latest libvirt?

[Simon Pasquier]

Le 07/11/2013 03:18, Martinx - ジェームズ a écrit :

That is true... Back to "LibvirtHybridOVSBridgeDriver", Security Groups
is working again...


Thanks for the feedback Thiago. I've opened a bug on Launchpad:
https://bugs.launchpad.net/nova/+bug/1248859



On 6 November 2013 15:03, Simon Pasquier mailto:simon.pasqu...@bull.net>> wrote:

Answering myself as I investigated a little further and
cross-posting to openstack-dev because I'd like to get feedback from
Nova/Neutron devs.

Users running Havana should configure
libvirt_vif_driver=nova.virt.__libvirt.vif.__LibvirtHybridOVSBridgeDriver.
This driver is still available in the Havana release although
deprecated. AFAIU, this is the only option if you want effective
security groups with KVM & OVS.

For people using the master branch of nova, sorry but security
groups are currently broken because LibvirtHybridOVSBridgeDriver is
gone ([0]). Joe Gordon asked the Neutron devs about it few weeks ago
[1] but no answer and in another review [2], the conclusion was that
the Tempest tests passed with Neutron. However I don't see anywhere
in the tests ([3], [4]) that we check if the security rules
allow/block traffic.

It would be nice if core devs could confirm or refute.

Regards,

Simon

[0] https://review.openstack.org/#__/c/49660/

[1]

http://lists.openstack.org/__pipermail/openstack-dev/2013-__October/016886.html


[2] https://review.openstack.org/#__/c/44349

[3]

https://github.com/openstack/__tempest/blob/master/tempest/__api/network/test_security___groups.py


[4]

https://github.com/openstack/__tempest/blob/master/tempest/__api/network/test_security___groups_negative.py



Le 05/11/2013 14:57, Simon Pasquier a écrit :

Hi all,

I'm struggling with security groups on Havana with Neutron and OVS
plugin (GRE tunnels). No problem to create/delete security group
rules
but even though iptables configuration is updated, traffic to my
instances is never filtered [0].

I'm running DevStack on 2 nodes (1 controller + 1 compute):
- OS: Ubuntu 12.04.3 (LTS) with the Havana cloud archive repository.
- Open vSwitch package version: 1.10.2-0ubuntu2~cloud0
- libvirt package version: 1.1.1-0ubuntu8~cloud2
- localrc, nova.conf, neutron.conf and ovs_neutron_plugin.ini files
pasted at [1] (I didn't modify any of these files after the
DevStack run)

According to [2], [3] and [4], iptables is not compatible with TAP
devices connectd directly to Open vSwitch ports, this is why
there used
to be the additional veth + bridge interfaces [5]. But in my
setup, this
is not the case anymore as shown in [6] ('ovs-vsctl show' +
'iptables-save' ouptut). I've also pasted the libvirt XML
configuration
[7] that shows that the instance is directly connected to the
Open vSwitch.

Are the security groups supposed to work when the instance is
directly
connected to OVS? If yes, what am I doing wrong?

Regards,

[0] http://paste.openstack.org/__show/50490/

[1] http://paste.openstack.org/__show/50448/

[2]
http://www.spinics.net/linux/__fedora/libvirt-users/msg05384.__html

[3]
http://openvswitch.org/__pipermail/discuss/2013-__October/011461.html

[4]

http://docs.openstack.org/__havana/config-reference/__content/under_the_hood___openvswitch.html



[5]

http://docs.openstack.org/__havana/config-reference/__content/figures/7/a/a/common/__figures/under-the-hood-__scenario-2-ovs-compute.png



[6] http://paste.openstack.org/__show/50486/

[7] http://paste.openstack.org/__show/50487/




--
Simon Pasquier
Software Engineer
Bull, Architect of an Open World
Phone: + 33 4 76 29 71 49 
http://www.bull.com

[openstack-dev] [Heat] How do i implement this usecase:

[Nilakhya]

Currently my heat template works with AWS resource type:

  DatabaseIPAddress:
Type: AWS::EC2::EIP
  DatabaseIPAssoc :
Type: AWS::EC2::EIPAssociation
Properties:
  InstanceId: {Ref: BaseInstance}
  EIP: {Ref: MyIPAddress}

Now if i want to change to OpenStack ( OS ) namespace with a similar 
implementation :


  MyIPAddress:
Type: OS::Neutron::FloatingIP
Properties:
floating_network_id : String
  MyIPAssoc :
Type: OS::Neutron::FloatingIPAssociation
Properties:
  floatingip_id : {Ref: MyIPAddress}

I cannot problem is,

a) floating_network_id ( is not known ) which is a required property.
b) Even if its available / defaults to, its an overhead from AWS simplicity.


--
Consultant Engineering
Team: HPCS-Vertica
Location: Noida, India


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

Re: [openstack-dev] Bad review patterns

[Radomir Dopieralski]

On 06/11/13 23:07, Robert Collins wrote:
> On 6 November 2013 21:34, Radomir Dopieralski  wrote:

> [...] Firstly, things
> like code duplication is a sliding scale, and I think it's ok for a
> reviewer to say 'these look similar, give it a go please'. If the
> reviewee tries, and it's no good - thats fine. But saying 'hey, I
> won't even try' - thats not so good. Many times we get drive-by
> patches and no follow up, so there is a learnt response to require
> full satisfaction with each patch that comes in. Regular contributors
> get more leeway here I think.

This is of course a gut feeling thing, and different people have
different thresholds for when to deduplicate code. I came up with that
pattern for myself, because my feelings about the code often didn't
match the feelings of the rest of the team. Please note that the fact
that I notice a bad pattern in my review doesn't immediately mean I
shouldn't do it -- just that it is suspect and I should rethink it. So,
if it's a blatant copy-paste of code, of course I will point it out. If
the patch includes code that could be easily replaced by an existing
utility function, that the author might not know about, of course I will
point it out. But if the code is similar to some other code in some
other part of the project, I will try to treat it the same way as when I
spot a bug that is not related to the patch during the review -- either
follow up with a patch of my own, or report a bug if I don't have time
for this (this has a nice side effect of producing the low-hanging-fruit
bugs that teach refactoring to newcomers). I think it's important to
remember that you can always commit to that project, so not all changes
need to be mde by that single author (especially in OpenStack, where you
have the marvelous option of amending someone else's patch).

[...]
>> This is quite obvious. Just don't do it. It's OK to spend an hour
>> reviewing something, and then leaving no comments on it, because it's
>> simply fine, or because we had to means to test someting (see the first
>> pattern).
> 
> Core reviewers look for the /comments/ from people, not just the
> votes. A +1 from someone that isn't core is meaningless unless they
> are known to be a thoughtful code reviewer. A -1 with no comment is
> also bad, because it doesn't help the reviewee get whatever the issue
> is fixed.
>
> It's very much not OK to spend an hour reviewing something and then +1
> with no comment: if I, and I think any +2er across the project see a
> patch that needs an hour of review, with a commentless +1, we'll
> likely discount the +1 as being meaningful.

That is a very good point! We want reviews that have useful comments in
them, so it is indeed a very good rule of thumb to always ask yourself
"Is this comment that I am posting helpful?". What I meant here is that
if I do a review, and even after spending a lot of time on it, can't
come up with anything that would actually help the author make it a
better patch, then it is fine to not post anything at all, including no
score. I suppose it would be nice to +1 it if you find it basically
fine, but we didn't have separate +1s and +2s in my previous project.

-- 
Radomir Dopieralski

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

[openstack-dev] How to choose proper availablity-zone in Havana version with the same usage realized by JsonFilter in Folsom version?

[hzguanqi...@corp.netease.com]

Hi guys,

In Folsom version, availability-zone info is stored in compute_nodes db table, 
and so can be parsed by JsonFilter.
I can use JsonFilter to choose which(or except which) availability-zones to 
build my instance.

But in Havana version, availability-zone info is stored in aggregatemetadata, 
and so JsonFilter seems can not filter
the proper availatiliby-zones as the way in Folsom version.

So Is there any other existed resolution in H version that can satisfy my 
demand?

Thanks~
-- 
Best regards!
GuanQiang

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

Re: [openstack-dev] Bad review patterns

[Jiri Tomasek]

On 11/07/2013 08:25 AM, Daniel P. Berrange wrote:

On Thu, Nov 07, 2013 at 12:21:38AM +, Day, Phil wrote:

Leaving a mark.
===

You review a change and see that it is mostly fine, but you feel that since you
did so much work reviewing it, you should at least find
*something* wrong. So you find some nitpick and -1 the change just so that
they know you reviewed it.

This is quite obvious. Just don't do it. It's OK to spend an hour reviewing
something, and then leaving no comments on it, because it's simply fine, or
because we had to means to test someting (see the first pattern).



Another one that comes into this category is adding a -1 which just says "I 
agree with
the other -1's in here".   If you have some additional perspective and can 
expand on
it then that's fine - otherwise it adds very little and is just review count 
chasing.

I don't think that it is valueless as you describe. If I multiple people
add '-1' with a "same comments as ", then as a core reviewer I will
consider that initial -1 to be a much stronger nack, than if only one person
had added the -1. So I welcome people adding "I agree with " to any
review.


It's an unfortunate consequence of counting and publishing review stats that 
having
such a measure will inevitable also drive behavour.

IMHO what this shows is not people trying to game the stats, but rather the
inadequacy of gerrit. We don't have any way to distinguish a "-1 minor nice
to have nitpick" from a "-1 serious code issue that is a must-fix". Adding
a -2 is really too heavyweight because it is sticky, and implies "do not
ever merge this".

It would be nice to be able to use '-2' for "serious must-fix issue" without
it being sticky, and have a separate way for core reviewers to put an review
into a "block from being merged indefinitely" state - perhaps a new state
would be more useful eg a "Blocked" state, to add to New, Open, Merged,
Abadoned.

Daniel
The comment describing the  -1 should be enough to distinquish between 
minor nitpick and serious code issue IMHO. If it is a serious issue, 
other reviewers also giving -1 confirming the issue is probably a good 
thing. (Not with the minor nit though...)


Jirka

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

Re: [openstack-dev] [Heat] How do i implement this usecase:

[Denis Makogon]

SnowDust, hi, are there any needs of Neutron usage(in trove)? Since nova
supports nova-network i suppose we could keep networking with nova.


2013/11/7 Nilakhya 

>  Currently my heat template works with AWS resource type:
>
>   DatabaseIPAddress:
> Type: AWS::EC2::EIP
>   DatabaseIPAssoc :
> Type: AWS::EC2::EIPAssociation
> Properties:
>   InstanceId: {Ref: BaseInstance}
>   EIP: {Ref: MyIPAddress}
>
> Now if i want to change to OpenStack ( OS ) namespace with a similar
> implementation :
>
>   MyIPAddress:
> Type: OS::Neutron::FloatingIP
>  Properties:
>floating_network_id : String
>   MyIPAssoc :
> Type: OS::Neutron::FloatingIPAssociation
> Properties:
>   floatingip_id : {Ref: MyIPAddress}
>
> I cannot problem is,
>
> a) floating_network_id ( is not known ) which is a required property.
> b) Even if its available / defaults to, its an overhead from AWS
> simplicity.
>
>
> --
> Consultant Engineering
> Team: HPCS-Vertica
> Location: Noida, India
>
>
>
>
> ___
> 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] Bad review patterns

[Radomir Dopieralski]

On 06/11/13 21:23, Eugene Nikanorov wrote:
> Hi!
> 
> I would like do disagree with some of the points.
> First of all, '-1' mark may have a wrong perception especially among new
> contributors. 
> -1 doesn't mean reviewers don't want your code (which is -2), it means
> they either not sure it is good enough or they see how you could make it
> better.
> 
>> Not sure if that works
> If you as a reviewer have a gut feeling ('not sure') that it may not
> work - put a -1.
> Let submitter explain it to you. You can change your score later without
> requiring to change the patch.
> Also, there are plenty of cases when the code could not be tested
> because it requires specific environment to run.
> I think it's ok to put -1 in case of uncertainty. The only thing you
> should care about is that such -1 is not 'finished' because you don't
> require submitter to change anything, so you need to check if your
> concerns were addressed and potentially change the score.

In theory, a -1 can work as a "gee, I'm not sure" response, but you have
to be careful and consider what effects it has in practice. On top of
that, it's very easy to give a "I'm not sure" -1, but it doesn't really
add much value to the patch. That's why I use that pattern to remind
myself that when I'm reviewing somebody's code, I'm wearing a subject
matter expert's hat, and that it's my work to put in effort to figure
things out. If I don't do that, I will look like a victim of the
Dunnig-Kruger effect to the author of the patch.

Moreover, the author gets punished for writing smart code. Or at least
they feel like that, which amounts to the same. Back then I had in my
team so very technically talented and knowledgable members, who don't
enjoy politics or arguing or having to explain themselves in words. What
they love best is to build something and show that it works -- you can't
possible argue with a working prototype, can you? But by demanding that
they prove to you in words that a certain piece of code is in fact valid
is removing them from the area where they shine, and forcing them to do
a job that they don't enjoy and are not good at. After all, they have
already build it, and it works, why don't you just look at how it works?
Why do they have to explain it to you?

Of course, they won't tell you this. (Actually, I was very lucky that
they did, after work, after a couple of beers). They will just make a
mental note: "That guy doesn't understand list comprehensions, avoid
using list comprehensions so that you don't have to explain it to him".

Finally, if you don't understand it, and don't have access to the
specialized environment required to test it, why are you reviewing this?
What do you hope to contribute to the patch like that? Are you sure your
questions are actually helping the project, and not just your curiosity?

Remember, that all the bad patterns that I listed are not strict "I
never do something like that" for me. They are more like "if I catch
myself doing something like this, I should stop and reconsider". I'm
sure there are some justified situations when you actually *should* ask
for clarification -- possibly also ask to put a comment explaining it in
the code, because if it confused you, it may confuse others in the
future, and also maybe write a unit test that tests it.

> On point #2:
>>  Let something repeat a couple of times just to be sure it actually is
> reusable.
> I think code repetition is not desirable in most of the cases and only
> occasionally repeating code gets merged. That happens especially when
> someone didn't put reusable code in a common place so others unaware of
> its existance. Instead of doing refactoring later on (who will do this?)
> just rely on reviewer's opinion and check if generalization could be done.
> And this can grow as a snowball (oh, he has copy-pasted his stuff, why
> shouldn't I do the same?) so the earlier it is caught - the better.

So, as I already replied to Robert Collins, obvious mistakes like
blatant copy-pasting of code should immediately be pointed out, as
should be places where an existing utility function could be used.

As to how to deal with the other cases, and who will do the refactoring
-- I view this is as a great opportunity to either do some cleanup
myself (it really feels good to do it!) or create some "low-hanging
fruit" bugs for the newcomers, or for myself for one of my worse days,
when I don't feel like working on anything new. The worst thing I can do
it just let it go and forget about it.

> On other points: the patch is required to be self-consistent. It needs
> to solve something that is stated in the bug/commit message and no more
> (and hopefully not less) than that. So the scope really matters. I
> haven't see much comments from reviewers requesting to make occasional
> fixes. Although sometimes it make sense to ask for such, especially if
> they are related, reasonable and the patch is going to be improved
> anyways (due to some other issues). It also ma

Re: [openstack-dev] [Heat] How do i implement this usecase:

[Nilakhya]

Hello Denis,

I asked in icehouse design session about the Floating IP support in heat 
templates ( so that we can migrate from AWS to OS) and was guided to 
OS::neutron resource even i was thinking if neutron becomes a dependancy 
then (and not just a simple nova-network) even using OS::Neutron there 
the asked usecase is a problem so opening it to community.


Consultant Engineering
Team: HPCS-Vertica
Location: Noida, India

On 11/07/2013 03:22 PM, Denis Makogon wrote:
SnowDust, hi, are there any needs of Neutron usage(in trove)? Since 
nova supports nova-network i suppose we could keep networking with nova.



2013/11/7 Nilakhya >


Currently my heat template works with AWS resource type:

  DatabaseIPAddress:
Type: AWS::EC2::EIP
  DatabaseIPAssoc :
Type: AWS::EC2::EIPAssociation
Properties:
  InstanceId: {Ref: BaseInstance}
  EIP: {Ref: MyIPAddress}

Now if i want to change to OpenStack ( OS ) namespace with a
similar implementation :

  MyIPAddress:
Type: OS::Neutron::FloatingIP
Properties:
floating_network_id : String
  MyIPAssoc :
Type: OS::Neutron::FloatingIPAssociation
Properties:
  floatingip_id : {Ref: MyIPAddress}

I cannot problem is,

a) floating_network_id ( is not known ) which is a required property.
b) Even if its available / defaults to, its an overhead from AWS
simplicity.


-- 
Consultant Engineering

Team: HPCS-Vertica
Location: Noida, India



___
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] How do i implement this usecase:

[Denis Makogon]

Hm, you are right. I suppose we need backward compability with nova
network, without Neutron.


2013/11/7 Nilakhya 

>  Hello Denis,
>
> I asked in icehouse design session about the Floating IP support in heat
> templates ( so that we can migrate from AWS to OS) and was guided to
> OS::neutron resource even i was thinking if neutron becomes a dependancy
> then (and not just a simple nova-network) even using OS::Neutron there the
> asked usecase is a problem so opening it to community.
>
> Consultant Engineering
> Team: HPCS-Vertica
> Location: Noida, India
>
> On 11/07/2013 03:22 PM, Denis Makogon wrote:
>
> SnowDust, hi, are there any needs of Neutron usage(in trove)? Since nova
> supports nova-network i suppose we could keep networking with nova.
>
>
>  2013/11/7 Nilakhya 
>
>>  Currently my heat template works with AWS resource type:
>>
>>   DatabaseIPAddress:
>> Type: AWS::EC2::EIP
>>   DatabaseIPAssoc :
>> Type: AWS::EC2::EIPAssociation
>> Properties:
>>   InstanceId: {Ref: BaseInstance}
>>   EIP: {Ref: MyIPAddress}
>>
>> Now if i want to change to OpenStack ( OS ) namespace with a similar
>> implementation :
>>
>>   MyIPAddress:
>> Type: OS::Neutron::FloatingIP
>>  Properties:
>>floating_network_id : String
>>   MyIPAssoc :
>> Type: OS::Neutron::FloatingIPAssociation
>> Properties:
>>   floatingip_id : {Ref: MyIPAddress}
>>
>> I cannot problem is,
>>
>> a) floating_network_id ( is not known ) which is a required property.
>> b) Even if its available / defaults to, its an overhead from AWS
>> simplicity.
>>
>>
>> --
>> Consultant Engineering
>> Team: HPCS-Vertica
>> Location: Noida, India
>>
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> ___
> OpenStack-dev mailing 
> listOpenStack-dev@lists.openstack.orghttp://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] [Neutron] Jenkins randomly fails?

[Siming Yin]

Hi Mike,

This tutorial is very helpful to me.

The chapter[1] you mentioned is also detailed, but I didn't read it
carefully ...


Thanks,

Siming

[1]: https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures



On Thu, Nov 7, 2013 at 3:47 PM, Michael Bright  wrote:

>
> Hi Siming,
>
> Yes there are some intermittent test failures which may be due to
> infrastructure and/or bugs.
>
> Here's my suggestion from recent experiences as a Noob.
>
> The e-mail you got from Jenkins includes this line, with a link telling
> you what to do:
> Build failed.  For information on how to proceed, see
> https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures
>
> In your case, at least for https://review.openstack.org/#/c/55370/ it
> seems that the build system recognized the
> failure as likely being due to a known bug #1239637.
> You should check the failing log file, which you can access via the link
> given in the e-mail or on the above 55370 change page:
>
>- 
> check-tempest-devstack-vm-neutron-pg
> FAILURE in 18m 27s
>
> to verify that this is indeed the same bug which has caused your build to
> fail.
>
> If this is the case, you can click on the "Review" button (for your patch
> set) and set Code to 0, add a comment ("Cover Message"):
> Recheck bug #x
> that's
> Recheck bug #1239637
> in your case (the bug number suggested by the "Elastic recheck").
>
> Hopefully that will pass.
>
> I hope this helps, I'm learning too ...
> Regards,
> Mike.
>
>
>
> On 7 November 2013 08:09, Siming Yin  wrote:
>
>> Hi all,
>>
>> Please have a look at these two changes:
>>
>> https://review.openstack.org/#/c/55370/
>> https://review.openstack.org/#/c/55221/
>>
>> The only change is to remove 4 duplicate definitions.  I'm sure this will
>> not cause any new problems, but it seems like the tests are randomly
>> failing in jenkins.
>>
>> Could anyone tell me how to handle this?
>>
>> Thanks,
>>
>> Siming
>>
>> ___
>> 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] Get more info about undocumented API calls

[Martin Pavlásek]

Hi all,

I'd like to fill some gaps in Tempest [1], but a lot of those calls are
rarely documented. If you are a bit familiar with some of that, please
write down note about that - tt will help me to write down test for it.
My working copy of that sheet [2] is not fully synchronized with
original [1], but it already contains some notes, insights.

Thank you for helping,
Martin

[1] 
https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc&usp=drive_web#gid=0
[2] 
https://docs.google.com/spreadsheet/ccc?key=0AnKZ7oAMtsxsdFFibDItWmhMV1BNUTlVMERXSDYxd0E&usp=drive_web#gid=0
Note: Everyone with link [1|2] can edit content.

-- 
Martin Pavlásek 
 OpenStack Associate Quality Engineer
 Red Hat Czech / BRQ
 irc: mpavlase




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

Re: [openstack-dev] [Heat] How do i implement this usecase:

[Simon Pasquier]

Hi,

The OS::Neutron::FloatingIP resource works in the same manner as the 
'neutron floating-create' command so currently there is no way to avoid 
passing the floating network id. The AWS::EC2::EIP resource doesn't 
require it because it uses the Nova API to allocate floating IPs. In 
turn, Nova API knowns the floating network with the 
default_floating_pool parameter defined in your nova.conf file.


I guess what you are looking for is a OS::Nova::FloatingIP resource. As 
a workaround, you could leverage environments [1] and map to the EC2 EIP 
resource:


resource_registry:
  "OS::Nova::FloatingIP": "AWS::EC2::EIP"

Simon

[1] http://docs.openstack.org/developer/heat/template_guide/environment.html

Le 07/11/2013 09:33, Nilakhya a écrit :

Currently my heat template works with AWS resource type:

   DatabaseIPAddress:
 Type: AWS::EC2::EIP
   DatabaseIPAssoc :
 Type: AWS::EC2::EIPAssociation
 Properties:
   InstanceId: {Ref: BaseInstance}
   EIP: {Ref: MyIPAddress}

Now if i want to change to OpenStack ( OS ) namespace with a similar
implementation :

   MyIPAddress:
 Type: OS::Neutron::FloatingIP
Properties:
floating_network_id : String
   MyIPAssoc :
 Type: OS::Neutron::FloatingIPAssociation
 Properties:
   floatingip_id : {Ref: MyIPAddress}

I cannot problem is,

a) floating_network_id ( is not known ) which is a required property.
b) Even if its available / defaults to, its an overhead from AWS simplicity.


--
Consultant Engineering
Team: HPCS-Vertica
Location: Noida, India




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




--
Simon Pasquier
Software Engineer
Bull, Architect of an Open World
Phone: + 33 4 76 29 71 49
http://www.bull.com

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

Re: [openstack-dev] Bad review patterns

[Radomir Dopieralski]

On 06/11/13 09:34, Radomir Dopieralski wrote:
> Hello,
> 
> I'm quite new in the OpenStack project, but I love it already. What is
> especially nifty is the automated review system -- I'm really impressed.
> I'm coming from a project in which we also did reviews of every change
> -- although it was mostly manual, and just one review was enough to
> merge -- and at some point in that project I noticed that it is very
> easy to give reviews that are unhelpful, frustrating and just get in the
> way of the actual work. I started paying attention to how I am reviewing
> code, and I managed to come up with several patterns that are bad. Once
> I know the patterns, it's easier to recognize when I'm doing something
> wrong and rethink the review. I would like to share the patterns that I
> noticed.

I created a page on the wiki,
https://wiki.openstack.org/wiki/CodeReviewGuidelines

I put some initial content there, based on the discussion in this
thread. Please feel free to discuss those points further here, and to
amend that page and add to it.

Any ideas of where we could put a link to it? I'm thinking about the
Gerrit Workflow page, maybe also some pages specific to particular teams
(I've seen there is a page with review tips for Nova).

-- 
Radomir Dopieralski




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

[openstack-dev] Reg Neutron security groups in Havana

[Kanthi P]

Hi,

I am trying to boot a VM which has a network without subnet in Havana, but
it throws an exception saying that subnet is mandatory if quantum security
groups are enabled.

Here are the commands I used.

neutron net-create testNet
[lcc@lcc devstack]$ neutron net-show testNet
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| id| 47208beb-2801-4729-bc7b-6532717232fc |
| name  | testNet  |
| provider:network_type | local|
| provider:physical_network |  |
| provider:segmentation_id  |  |
| router:external   | False|
| shared| False|
| status| ACTIVE   |
| subnets   |  |
| tenant_id | b5b591dcda2645cd9d15a4fe3eb1b50d |
+---+--+

nova boot --flavor 2 --image 30c1984c-8a4f-4e3f-8c9a-7de0b321caa2 --nic
net-id=47208beb-2801-4729-bc7b-6532717232fc testServer1

Here is the piece of code which generated this exception

nova/network/neutronv2/api.py

if (security_groups and not (
network['subnets']
and network.get('port_security_enabled', True))):

raise exception.SecurityGroupCannotBeApplied()


Can someone please explain why do we need this check?

To my understanding subnet is used for two purposes in terms of security
groups
1. To allow dhcp traffic if dhcp is enabled on the subnet, example given
below
-A quantum-openvswi-i7bf776d2-b -s 192.168.1.3/32 -p udp -m udp
--sport 67 --dport 68 -j RETURN
2. To avoid ip spoof
-A quantum-openvswi-o7bf776d2-b ! -s 192.168.1.2/32 -j DROP

Can we remove this so that we can have guests which has nic with just MAC
address, guest can configure its own ipaddress. Later if needed they can
enable their own security rules via quantum api.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] nova-api fails to start

[Krishanu Dhar]

Hi,

I was trying to install the devstack and it failed while starting the nova
api. below is a snippet from the console. Is it a bug?


+ screen -S stack -p n-api -X stuff 'cd /opt/stack/nova &&
/usr/local/bin/nova-a'i || echo "n-api failed to start" | tee
"/opt/stack/status/stack/n-api.failure"
+ echo 'Waiting for nova-api to start...'
Waiting for nova-api to start...
+ wait_for_service 60 http://10.0.2.15:8774
+ local timeout=60
+ local url=http://10.0.2.15:8774
+ timeout 60 sh -c 'while ! curl --noproxy '\''*'\'' -s
http://10.0.2.15:8774 >/dev/null; do sleep 1; done'
+ die 628 'nova-api did not start'
+ local exitcode=0
+ set +o xtrace
[Call Trace]
./stack.sh:1084:start_nova_api
/home/krish/devstack/lib/nova:628:die
[ERROR] /home/krish/devstack/lib/nova:628 nova-api did not start
krish@krish-VirtualBox:~/devstack$

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

Re: [openstack-dev] nova-api fails to start

[Noorul Islam K M]

Krishanu Dhar  writes:

> Hi,
>
> I was trying to install the devstack and it failed while starting the nova
> api. below is a snippet from the console. Is it a bug?
>
>
> + screen -S stack -p n-api -X stuff 'cd /opt/stack/nova &&
> /usr/local/bin/nova-a'i || echo "n-api failed to start" | tee
> "/opt/stack/status/stack/n-api.failure"
> + echo 'Waiting for nova-api to start...'
> Waiting for nova-api to start...
> + wait_for_service 60 http://10.0.2.15:8774
> + local timeout=60
> + local url=http://10.0.2.15:8774
> + timeout 60 sh -c 'while ! curl --noproxy '\''*'\'' -s
> http://10.0.2.15:8774 >/dev/null; do sleep 1; done'
> + die 628 'nova-api did not start'
> + local exitcode=0
> + set +o xtrace
> [Call Trace]
> ./stack.sh:1084:start_nova_api
> /home/krish/devstack/lib/nova:628:die
> [ERROR] /home/krish/devstack/lib/nova:628 nova-api did not start
> krish@krish-VirtualBox:~/devstack$

Did you try "screen -x stack" ?

Regards,
Noorul

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

Re: [openstack-dev] [swift] what does swift do if the auditor find that all 3 replicas are corrupt?

[Daniel Li]

Thanks very much for your help, and please see my inline comments/questions.

On Thu, Nov 7, 2013 at 2:30 AM, Samuel Merritt  wrote:

> On 11/6/13 7:12 AM, Daniel Li wrote:
>
>> Hi,
>>  I have a question about swift:  what does swift do if the auditor
>> find that all 3 replicas are corrupt?
>> will it notify the owner of the object(email to the account owner)?
>> what will happen if the GET request to the corrupted object?
>> will it return a special error telling that all the replicas are
>> corrupted?
>>   Or will it just say that the object is not exist?
>>   Or it just return one of the corrupted replica?
>>   Or something else?
>>
>
> If all 3 (or N) replicas are corrupt, then the auditors will eventually
> quarantine all of them, and subsequent GET requests will receive 404
> responses.
>
No notifications are sent, nor is it really feasible to start sending them.
> "The auditor" is not a single process; there is one Swift auditor process
> running on each node in a cluster. Therefore, when an object is
> quarantined, there's no way for its auditor to know if the other copies are
> okay or not.
>
> Note that this is highly unlikely to ever happen, at least with the
> default of 3 replicas. When an auditor finds a corrupt object, it
> quarantines it (moves it to a "quarantines" directory).

 Did you mean that when the auditor found the corruption, it did not copy
good replica from other object server to overwrite the corrupted one, it
just moved it to a quarantines directory?

Then, since that object is missing, the replication processes will recreate
> the object by copying it from a node with a good copy.

When did the replication processes recreated the object by copying it from
a node with a good copy? Does the auditor send a message to replication so
the replication will do the copy immediately? And what is a 'good' copy?
Does the good copy's MD5 value is checked before copying?

> You'd need to have all replicas become corrupt within a very short
> timespan so that the replicators don't get a chance to replace the damaged
> ones.
>
> ___
> 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-api fails to start

[Telles Nobrega]

Sometimes after ./unstack is ran, some process are still runnning for nova.
Try running this to kill them all (ps aux | grep -ie nova | awk '{print
$2}' | xargs kill -9) and try ./stack again


On Thu, Nov 7, 2013 at 9:14 AM, Noorul Islam K M  wrote:

> Krishanu Dhar  writes:
>
> > Hi,
> >
> > I was trying to install the devstack and it failed while starting the
> nova
> > api. below is a snippet from the console. Is it a bug?
> >
> >
> > + screen -S stack -p n-api -X stuff 'cd /opt/stack/nova &&
> > /usr/local/bin/nova-a'i || echo "n-api failed to start" | tee
> > "/opt/stack/status/stack/n-api.failure"
> > + echo 'Waiting for nova-api to start...'
> > Waiting for nova-api to start...
> > + wait_for_service 60 http://10.0.2.15:8774
> > + local timeout=60
> > + local url=http://10.0.2.15:8774
> > + timeout 60 sh -c 'while ! curl --noproxy '\''*'\'' -s
> > http://10.0.2.15:8774 >/dev/null; do sleep 1; done'
> > + die 628 'nova-api did not start'
> > + local exitcode=0
> > + set +o xtrace
> > [Call Trace]
> > ./stack.sh:1084:start_nova_api
> > /home/krish/devstack/lib/nova:628:die
> > [ERROR] /home/krish/devstack/lib/nova:628 nova-api did not start
> > krish@krish-VirtualBox:~/devstack$
>
> Did you try "screen -x stack" ?
>
> Regards,
> Noorul
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
--
Telles Mota Vidal Nobrega
Developer at PulsarOpenStack Project - HP/LSD-UFCG
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] Choice of API infrastructure

[Jay Pipes]

Hey Doug, following up, but realize you are likely very busy at the 
summit :)


On 11/04/2013 10:20 PM, Doug Hellmann wrote:

On Tue, Nov 5, 2013 at 10:37 AM, Jay Pipes 

I wasn't referring to the database representation, actually. I was 
referring to the data model, which is different in that it abstracts 
away any underlying schema or storage engine...



I would much rather see the Ceilometer models [1] actually be models
that can validate the data that is used to construct the model
object instead of having duplicated WSME "models" repeated in the
WSGI controller code [2]. The reason is because if/when I decide to
make a Ceilometer API that uses a different protocol, say AMQP,
instead of HTTP, now I need to duplicate all of the validation code
that WSME is providing on the data model layer... however if the
validation was in the models themselves, I could easily create an
API on a different protocol using just the models for validation.

We do that in some cases. However, there is also a difference in some
cases between the validation at the API layer (a value must be a number,
or a UUID, etc.) and the validation in the database layer (a number must
fall within a range or a UUID must refer to an existing object). So
there is a place for both, and the validation done in the WSME classes
is not meant to be the only validation performed.


OK, understood.


The benefits of declaring WSME classes include automatic
serialization
in JSON and XML, generating WADL files to be included in the API
docs
(work is already happening to make this available for everyone), and
consistent input and output types for API endpoints (making it
easier
for consumers of the API to use it and for implementers to validate
inputs and assume consistent defaults).


I can't stand XML. I believe it should be retired to the dustbin of
coding history, like Basic.

You've made that clear in the past. :-) I agree, for what it's worth.
Some of our users do seem to want it, and with WSME *you don't have to
care*.


Also understood. :)


That said, consumers of a RESTful API don't care how the API is
implemented. They care that it's documented and consistent, and if
WSME makes API documentation easier, then that's A Good Thing, agreed.

It's true that WSME includes some stuff to make validating inputs
"easier", but it does so, IMHO, at the expense of readability
because everything is decorated and hidden away somewhere other than
the models themselves. See note above...

I'm not sure what that means. Hidden where? The validation is either
described in the attribute specifier for the model, or in the model's
class, or in the controller (depending on the scope of the rule being
applied).


Sorry, "hidden" wasn't the best word to describe that. I meant more 
"it's less obvious to folks who expect to find validation of the data 
model at the data model layer" :)



And, to be clear, Pecan and WSME are integrated by Pecan can
definitely
be used without WSME. I included WSME in the proposal to replace the
home-grown WSGI framework because I thought it added significant
benefits, but it is not going to be appropriate for all situations
(streaming large image files is one example).


Yes, in one way it's a bit unfortanate that we're now comparing Falcon 
with Pecan + WSME as opposed to just comparing Falcon with Pecan and 
then evaluating whether WSME should be used (on top of either one...). 
It's unfortunate because we've spent all this email thread actually 
talking about WSME and not much at all about Pecan ;)



Here's a third reason I don't care for Pecan/WSME: it uses Webob.
Other than eventlet, I don't know of a single library that OpenStack
projects have used over the years that we've had more issues with
than Webob.

Yes, I felt the pain of updating us to the latest WebOb. The project has
evolved since those days, and the current maintainers are committed to
not breaking the API. That new attitude, combined with the long history
of addressing edge cases from misbehaving web client libraries makes m e
less reluctant to use WebOb than in the past.


OK, that's good to hear. However, I remain guarded and 
pessimistic...it's my nature I suppose :)



Secondly, it is the sign of strength that a contributor community
consider -- and continually consider -- alternative libraries or
implementations of various things. Change is good, and projects that
are just starting off are a good place to experiment with newer
libraries and see if something is better than what existed
previously. I seem to remember that was your position on Pecan when
the community was considering whether to standardize on some WSGI
pipeline. Why didn't you just use what was in other projects instead
of Pecan and WSME? Likely the same 

[openstack-dev] cinder metrics with nova-scheduler

[Abbass MAROUNI]

Hello,

We want to be able to launch a VM with a number of cinder volumes on the
same host (the host is a compute and a storage node).
We're looking for a way to tell nova-scheduler to work with
cinder-scheduler so that we can filter and weight hosts according to our
needs.

According to the documentation on nova-scheduler filters :

DiskFilter : Only schedule instances on hosts if there are sufficient Disk
available for ephemeral storage.

Is there any implementation of a filter to check the persistence storage on
a host ?
Do you think that this feature is doable ?

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

Re: [openstack-dev] A Tool for Making OpenStack Log Reading a Bit Easier

[Solly Ross]

Sure, that sounds like a good idea.  Count me in.

- Original Message -
From: "Sean Dague" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Wednesday, November 6, 2013 5:31:12 PM
Subject: Re: [openstack-dev] A Tool for Making OpenStack Log Reading a Bit  
Easier

First, very cool tool, nice work!

I wonder if it's reasonable (or interesting) to take these approaches
and bring them into os-loganalyze. That would mean there was common
parsing routines, and then we would just call out to different
functions if were were trying to do HTML or ANSI coloring. I
personally live so often off the weblogs that I honestly hadn't
thought about the local case, which would be definitely interesting.
It would also be really great if adding semantics to one use did it
for the other as well, so people would see the same output when they
were looking at test failures as when they were doing local
development.

If you are interested in trying to join efforts there, let me know.

On Wed, Nov 6, 2013 at 9:36 AM, Joe Gordon  wrote:
>
>
>
> On Wed, Nov 6, 2013 at 9:10 AM, Clint Byrum  wrote:
>>
>> I often use ccze to look at logs. It has some built in things like
>> coloring the words "warn" or "warning" yellow and "error" red. It would
>> be great to have this filter added as another ccze plugin.
>>
>
> Sean Dague, wrote a really slick tool for logs.openstack.org that is
> similar:
>
> http://git.openstack.org/cgit/openstack-infra/os-loganalyze/tree/README.rst
>
> http://logs.openstack.org/98/54198/7/check/check-tempest-devstack-vm-neutron/a153156/logs/screen-q-svc.txt.gz?level=TRACE
>
>>
>> Excerpts from Solly Ross's message of 2013-11-06 05:58:02 +0800:
>> > Hello All,
>> > The other day, I was reading through a debug-level OpenStack log, and
>> > came to the realization that reading OpenStack debug-level logs was
>> > difficult, to say the least -- they can be very busy, and it is hard to
>> > quickly filter out relevant information.  Thus, I wrote a little Perl 
>> > script
>> > to make reading dense debug-level logs a bit easier:
>> > https://github.com/DirectXMan12/os_log_prettifier.  I figured that I'd 
>> > share
>> > it with other people.  Basically, the script highlights certain key details
>> > using color and bolding (via ANSI control codes), and can filter lines 
>> > based
>> > on subject (in the form of 'x.y.z') or message type, using regular
>> > expressions.  I hope people find it useful!
>> >
>> > Best Regards,
>> > Solly Ross
>> >
>>
>> ___
>> 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
>



-- 
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

Re: [openstack-dev] L3 advanced features blueprint mapping to IETF and IEEE standards

[Pedro Roque Marques]

Colin,
"The nice thing about standards is that there are so many of them to choose 
from."

For instance, if you take this Internet Draft:
http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-02 which is based on 
RFC4364.

It has already been implemented as a Neutron plugin via OpenContrail 
(http://juniper.github.io/contrail-vnc/README.html); With this implementation 
each OpenStack cluster can be configured as its own Autonomous System.

There is a blueprint
https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-mpls-vpn
that is discussing adding the provisioning of the autonomous system and peering 
to Neutron.

Please note that the work above does interoperate with 4364 using option B. 
Option C is possible but not that practical (as an operator you probably don't 
want to expose your internal topology between clusters).

If you want to give it a try you can use this devstack fork: 
https://github.com/dsetia/devstack.
You can use it to interoperate with a standard router that implements 4364 and 
support MPLS over GRE. Products from cisco/juniper/ALU/huwawei etc do.

I believe that the work i'm referencing implements interoperability while 
having very minimal changes to Neutron. It is based on the same concept of 
neutron virtual network and it hides the BGP/MPLS functionality from the user 
by translating policies that establish connectivity between virtual networks 
into RFC 4364 concepts.
Please refer to: 
https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron

Would it make sense to have an IRC/Web meeting around interoperability with 
RFC4364 an OpenStack managed clusters ? I believe that there is a lot of work 
that has already been done there by multiple vendors as well as some carriers.

  Pedro.

On Nov 7, 2013, at 12:35 AM, Colin McNamara  wrote:
> I have a couple concerns that I don’t feel I clearly communicated during the 
> L3 advanced features session. I’d like to take this opportunity to both 
> clearly communicate my thoughts, as well as start a discussion around them.
> 
> Building to the edge of the "autonomous system"
> The current state of neutron implementation is functionally the l2 domain and 
> simple l3 services that are part of a larger autonomous system. The routers 
> and switches northbound of the OpenStack networking layer handled the 
> abstraction and integration of the components.
> Note, I use the term “Autonomous System” to describe more then the notion of 
> BGP AS, but more broadly in the term of a system that is controlled within a 
> common framework and methodology, and integrates with a peer system that 
> doesn’t not share that same scope or method of control
> These components that composed the autonomous system boundary implement 
> protocols and standards that map into IETF and IEEE standards. The reasoning 
> for this is interoperability. Before vendors utilize IETF for 
> interoperability at this layer, the provider experience was horrible (this 
> was my personal experience in the late 90’s).
>  
> Wednesdays discussions in the Neutron Design Sessions
> A couple of the discussions, most notably the extension of l3 functionality 
> fell within the scope of starting the process of extending Neutron with 
> functionality that will result (eventually) in the ability for an OpenStack 
> installation to operate as it’s own Autonomous System.
> The discussions that occurred to support L3 advanced functionality 
> (northbound boundary), and the QOS extension functionality both fell into the 
> scope of Northbound and Southbound boundaries of this system.
> My comments in the session
> My comments in the session, while clouded with jet-lag were specifically 
> around two concepts that are used when integrating other types of systems 
> 1. In a simple (1-8) tenant environment integration with a northbound AS is 
> normally done in a PE-CE model that generally centers around mapping dot1q 
> tags into the appropriate northbound l3 segments and then handling the 
> availability of the L2 path that traverses with port channeling, MLAG, STP, 
> Etc.
> 2. In a complex environment (8+ for discussion) different Carrier Supporting 
> Carrier (CSC) methods defined in IETF RFC 4364 Section 10 type A, B or C are 
> used. These allow the mapping of segregated tenant networks together and 
> synchronizing between distributed systems. This normally extends the tagging 
> or tunneling mechanism and then allows for BGP to synchronize NLRI 
> information between AS’s.
> These are the standard ways of integrating between carriers, but also 
> components of these implementations are used to integrate and scale inside of 
> a single web scale data center. Commonly when you scale beyond a certain 
> physical port boundary (1000is edge ports in many implementations, much 
> larger in current implementations) the same designs for C2C integrations are 
> used to create network availability zones inside a web scale data center. 
> Support of these IETF and IEE

Re: [openstack-dev] Bad review patterns

[Pedro Roque Marques]

Radomir,
An extra issue that i don't believe you've covered so far is about comment 
ownership. I've just read an email on the list that follows a pattern that i've 
heard many complaints about:
-1 with a reasonable comment, submitter addresses the comment, reviewer 
never comes back.

Reviewers do need to allocate time to come back and follow up on the answers to 
their comments.

Perhaps there is an issue with the incentive system. You can earn karma by 
doing a code review... certainly you want to incentivise developers that help 
the project by improving the code quality. But if the incentive system allows 
for "drive by shooting" code reviews that can be a problem.

btw: this is not at all exclusive to OpenStack. The issues you have pointed out 
exist for instance in code reviews inside company's proprietary code bases when 
different teams are involved. I'm yet to see a perfect solution to the problem.

  Pedro.

On Nov 7, 2013, at 3:02 AM, Radomir Dopieralski  wrote:

> On 06/11/13 09:34, Radomir Dopieralski wrote:
>> Hello,
>> 
>> I'm quite new in the OpenStack project, but I love it already. What is
>> especially nifty is the automated review system -- I'm really impressed.
>> I'm coming from a project in which we also did reviews of every change
>> -- although it was mostly manual, and just one review was enough to
>> merge -- and at some point in that project I noticed that it is very
>> easy to give reviews that are unhelpful, frustrating and just get in the
>> way of the actual work. I started paying attention to how I am reviewing
>> code, and I managed to come up with several patterns that are bad. Once
>> I know the patterns, it's easier to recognize when I'm doing something
>> wrong and rethink the review. I would like to share the patterns that I
>> noticed.
> 
> I created a page on the wiki,
> https://wiki.openstack.org/wiki/CodeReviewGuidelines
> 
> I put some initial content there, based on the discussion in this
> thread. Please feel free to discuss those points further here, and to
> amend that page and add to it.
> 
> Any ideas of where we could put a link to it? I'm thinking about the
> Gerrit Workflow page, maybe also some pages specific to particular teams
> (I've seen there is a page with review tips for Nova).
> 
> -- 
> Radomir Dopieralski
> 
> 
> 
> 
> ___
> 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-api fails to start

[Krishanu Dhar]

below is an error that's probably the cause...

2013-11-07 23:24:14.758 TRACE nova IOError: [Errno 13] Permission denied:
'/etc/nova/api-paste.ini'
2013-11-07 23:24:14.758 TRACE nova
n-api failed to start

krish@krish-VirtualBox:/opt/stack/nova$ ls -l /etc/nova/api-paste.ini
-rw--- 1 nova nova 4260 Apr 23  2013 /etc/nova/api-paste.ini

isn't it expected to fail if the file is owned by "nova"... weird.




On Thu, Nov 7, 2013 at 11:18 PM, Krishanu Dhar  wrote:

> it did not even start the process in my case.
>
> I tried looking up email threads in google and looks like quite a few have
> run into this before, but couldn't find a working fix.
>
>
> On Thu, Nov 7, 2013 at 11:15 PM, Telles Nobrega 
> wrote:
>
>> Weird, i had the same problem, but when i kill the processes it works
>>
>>
>> On Thu, Nov 7, 2013 at 2:34 PM, Krishanu Dhar wrote:
>>
>>> Nothing was left behind.
>>>
>>> #ps aux|grep -ie nova did not return anything.
>>>
>>>
>>> On Thu, Nov 7, 2013 at 11:01 PM, Telles Nobrega >> > wrote:
>>>
 Did you check if there are any nova process left running?


 On Thu, Nov 7, 2013 at 2:28 PM, Krishanu Dhar wrote:

> Appreciate the responses. But there is something wrong with this. I
> ran unstack.sh again and retried the installation. it failed with the same
> message.
>
> So, what are my options right now?
>
>
> On Thu, Nov 7, 2013 at 7:31 PM, Telles Nobrega <
> tellesnobr...@gmail.com> wrote:
>
>> Sometimes after ./unstack is ran, some process are still runnning for
>> nova.
>> Try running this to kill them all (ps aux | grep -ie nova | awk
>> '{print $2}' | xargs kill -9) and try ./stack again
>>
>>
>> On Thu, Nov 7, 2013 at 9:14 AM, Noorul Islam K M 
>> wrote:
>>
>>> Krishanu Dhar  writes:
>>>
>>> > Hi,
>>> >
>>> > I was trying to install the devstack and it failed while starting
>>> the nova
>>> > api. below is a snippet from the console. Is it a bug?
>>> >
>>> >
>>> > + screen -S stack -p n-api -X stuff 'cd /opt/stack/nova &&
>>> > /usr/local/bin/nova-a'i || echo "n-api failed to start" | tee
>>> > "/opt/stack/status/stack/n-api.failure"
>>> > + echo 'Waiting for nova-api to start...'
>>> > Waiting for nova-api to start...
>>> > + wait_for_service 60 http://10.0.2.15:8774
>>> > + local timeout=60
>>> > + local url=http://10.0.2.15:8774
>>> > + timeout 60 sh -c 'while ! curl --noproxy '\''*'\'' -s
>>> > http://10.0.2.15:8774 >/dev/null; do sleep 1; done'
>>> > + die 628 'nova-api did not start'
>>> > + local exitcode=0
>>> > + set +o xtrace
>>> > [Call Trace]
>>> > ./stack.sh:1084:start_nova_api
>>> > /home/krish/devstack/lib/nova:628:die
>>> > [ERROR] /home/krish/devstack/lib/nova:628 nova-api did not start
>>> > krish@krish-VirtualBox:~/devstack$
>>>
>>> Did you try "screen -x stack" ?
>>>
>>> Regards,
>>> Noorul
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> --
>> Telles Mota Vidal Nobrega
>> Developer at PulsarOpenStack Project - HP/LSD-UFCG
>>
>
>
>
> --
> Krishanu
>



 --
 --
 Telles Mota Vidal Nobrega
 Developer at PulsarOpenStack Project - HP/LSD-UFCG

>>>
>>>
>>>
>>> --
>>> Krishanu
>>>
>>
>>
>>
>> --
>> --
>> Telles Mota Vidal Nobrega
>> Developer at PulsarOpenStack Project - HP/LSD-UFCG
>>
>
>
>
> --
> Krishanu
>



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

Re: [openstack-dev] [swift] what does swift do if the auditor find that all 3 replicas are corrupt?

[Samuel Merritt]

On 11/7/13 5:59 AM, Daniel Li wrote:


Thanks very much for your help, and please see my inline comments/questions.

On Thu, Nov 7, 2013 at 2:30 AM, Samuel Merritt mailto:s...@swiftstack.com>> wrote:

On 11/6/13 7:12 AM, Daniel Li wrote:

Hi,
  I have a question about swift:  what does swift do if the
auditor
find that all 3 replicas are corrupt?
will it notify the owner of the object(email to the account owner)?
what will happen if the GET request to the corrupted object?
will it return a special error telling that all the replicas are
corrupted?
   Or will it just say that the object is not exist?
   Or it just return one of the corrupted replica?
   Or something else?


If all 3 (or N) replicas are corrupt, then the auditors will
eventually quarantine all of them, and subsequent GET requests will
receive 404 responses.

No notifications are sent, nor is it really feasible to start
sending them. "The auditor" is not a single process; there is one
Swift auditor process running on each node in a cluster. Therefore,
when an object is quarantined, there's no way for its auditor to
know if the other copies are okay or not.

Note that this is highly unlikely to ever happen, at least with the
default of 3 replicas. When an auditor finds a corrupt object, it
quarantines it (moves it to a "quarantines" directory).

  Did you mean that when the auditor found the corruption, it did not
copy good replica from other object server to overwrite the corrupted
one, it just moved it to a quarantines directory?


That is correct. The object auditors don't perform any network IO, and 
in fact do not use the ring at all. All they do is scan the filesystems 
and quarantine bad objects in an infinite loop.


(Of course, there are also container and account auditors that do 
similar things, but for container and account databases.)



Then, since that object is missing, the replication processes will
recreate the object by copying it from a node with a good copy.

When did the replication processes recreated the object by copying it
from a node with a good copy? Does the auditor send a message to
replication so the replication will do the copy immediately? And what is
a 'good' copy? Does the good copy's MD5 value is checked before copying?


It'll happen whenever the other replicators, which are running on other 
nodes, get around to it.


Replication in Swift is push-based, not pull-based; there is no receiver 
here to which a message could be sent.


Currently, a "good" copy is one that hasn't been quarantined. Since 
replication uses rsync to push files around the network, there's no 
checking of MD5 at copy time. However, there is work underway to develop 
a replication protocol that avoids rsync entirely and uses the object 
server throughout the entire replication process, and that would give 
the object server a chance to check MD5 checksums on incoming writes.


Note that this is only important should 2 replicas experience 
near-simultaneous bitrot; in that case, there is a chance that bad-copy 
A will get quarantined and replaced with bad-copy B. Eventually, though, 
a bad copy will get quarantined and replaced with a good copy, and then 
you've got 2 good copies and 1 bad one, which reduces to a 
previously-discussed scenario.


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

Re: [openstack-dev] nova-api fails to start

[Krishanu Dhar]

Any other recommendations on how to have a successful devstack
installation?


On Thu, Nov 7, 2013 at 11:37 PM, Krishanu Dhar  wrote:

> below is an error that's probably the cause...
>
> 2013-11-07 23:24:14.758 TRACE nova IOError: [Errno 13] Permission denied:
> '/etc/nova/api-paste.ini'
> 2013-11-07 23:24:14.758 TRACE nova
> n-api failed to start
>
> krish@krish-VirtualBox:/opt/stack/nova$ ls -l /etc/nova/api-paste.ini
> -rw--- 1 nova nova 4260 Apr 23  2013 /etc/nova/api-paste.ini
>
> isn't it expected to fail if the file is owned by "nova"... weird.
>
>
>
>
> On Thu, Nov 7, 2013 at 11:18 PM, Krishanu Dhar wrote:
>
>> it did not even start the process in my case.
>>
>> I tried looking up email threads in google and looks like quite a few
>> have run into this before, but couldn't find a working fix.
>>
>>
>> On Thu, Nov 7, 2013 at 11:15 PM, Telles Nobrega 
>> wrote:
>>
>>> Weird, i had the same problem, but when i kill the processes it works
>>>
>>>
>>> On Thu, Nov 7, 2013 at 2:34 PM, Krishanu Dhar wrote:
>>>
 Nothing was left behind.

 #ps aux|grep -ie nova did not return anything.


 On Thu, Nov 7, 2013 at 11:01 PM, Telles Nobrega <
 tellesnobr...@gmail.com> wrote:

> Did you check if there are any nova process left running?
>
>
> On Thu, Nov 7, 2013 at 2:28 PM, Krishanu Dhar wrote:
>
>> Appreciate the responses. But there is something wrong with this. I
>> ran unstack.sh again and retried the installation. it failed with the 
>> same
>> message.
>>
>> So, what are my options right now?
>>
>>
>> On Thu, Nov 7, 2013 at 7:31 PM, Telles Nobrega <
>> tellesnobr...@gmail.com> wrote:
>>
>>> Sometimes after ./unstack is ran, some process are still runnning
>>> for nova.
>>> Try running this to kill them all (ps aux | grep -ie nova | awk
>>> '{print $2}' | xargs kill -9) and try ./stack again
>>>
>>>
>>> On Thu, Nov 7, 2013 at 9:14 AM, Noorul Islam K M 
>>> wrote:
>>>
 Krishanu Dhar  writes:

 > Hi,
 >
 > I was trying to install the devstack and it failed while starting
 the nova
 > api. below is a snippet from the console. Is it a bug?
 >
 >
 > + screen -S stack -p n-api -X stuff 'cd /opt/stack/nova &&
 > /usr/local/bin/nova-a'i || echo "n-api failed to start" | tee
 > "/opt/stack/status/stack/n-api.failure"
 > + echo 'Waiting for nova-api to start...'
 > Waiting for nova-api to start...
 > + wait_for_service 60 http://10.0.2.15:8774
 > + local timeout=60
 > + local url=http://10.0.2.15:8774
 > + timeout 60 sh -c 'while ! curl --noproxy '\''*'\'' -s
 > http://10.0.2.15:8774 >/dev/null; do sleep 1; done'
 > + die 628 'nova-api did not start'
 > + local exitcode=0
 > + set +o xtrace
 > [Call Trace]
 > ./stack.sh:1084:start_nova_api
 > /home/krish/devstack/lib/nova:628:die
 > [ERROR] /home/krish/devstack/lib/nova:628 nova-api did not start
 > krish@krish-VirtualBox:~/devstack$

 Did you try "screen -x stack" ?

 Regards,
 Noorul

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

>>>
>>>
>>>
>>> --
>>> --
>>> Telles Mota Vidal Nobrega
>>> Developer at PulsarOpenStack Project - HP/LSD-UFCG
>>>
>>
>>
>>
>> --
>> Krishanu
>>
>
>
>
> --
> --
> Telles Mota Vidal Nobrega
> Developer at PulsarOpenStack Project - HP/LSD-UFCG
>



 --
 Krishanu

>>>
>>>
>>>
>>> --
>>> --
>>> Telles Mota Vidal Nobrega
>>> Developer at PulsarOpenStack Project - HP/LSD-UFCG
>>>
>>
>>
>>
>> --
>> Krishanu
>>
>
>
>
> --
> Krishanu
>



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

Re: [openstack-dev] nova-api fails to start

[Cazzolato, Sergio J]

Hi, I had the same issue and fixed that doing a chwon and changing the 
ownership to my user of the files in /etc/nova where the owner was the user 
nova.

In my case the files were: api-paste.ini and policy.json

I posted the solution there too:

http://stackoverflow.com/questions/19843239/getting-nova628die-trying-to-start-openstack-nova-module

Thanks


From: Krishanu Dhar [mailto:rony.k...@gmail.com]
Sent: Thursday, November 07, 2013 3:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] nova-api fails to start

Any other recommendations on how to have a successful devstack installation?

On Thu, Nov 7, 2013 at 11:37 PM, Krishanu Dhar 
mailto:rony.k...@gmail.com>> wrote:
below is an error that's probably the cause...

2013-11-07 23:24:14.758 TRACE nova IOError: [Errno 13] Permission denied: 
'/etc/nova/api-paste.ini'
2013-11-07 23:24:14.758 TRACE nova
n-api failed to start
krish@krish-VirtualBox:/opt/stack/nova$ ls -l /etc/nova/api-paste.ini
-rw--- 1 nova nova 4260 Apr 23  2013 /etc/nova/api-paste.ini
isn't it expected to fail if the file is owned by "nova"... weird.



On Thu, Nov 7, 2013 at 11:18 PM, Krishanu Dhar 
mailto:rony.k...@gmail.com>> wrote:
it did not even start the process in my case.
I tried looking up email threads in google and looks like quite a few have run 
into this before, but couldn't find a working fix.

On Thu, Nov 7, 2013 at 11:15 PM, Telles Nobrega 
mailto:tellesnobr...@gmail.com>> wrote:
Weird, i had the same problem, but when i kill the processes it works

On Thu, Nov 7, 2013 at 2:34 PM, Krishanu Dhar 
mailto:rony.k...@gmail.com>> wrote:
Nothing was left behind.

#ps aux|grep -ie nova did not return anything.

On Thu, Nov 7, 2013 at 11:01 PM, Telles Nobrega 
mailto:tellesnobr...@gmail.com>> wrote:
Did you check if there are any nova process left running?

On Thu, Nov 7, 2013 at 2:28 PM, Krishanu Dhar 
mailto:rony.k...@gmail.com>> wrote:
Appreciate the responses. But there is something wrong with this. I ran 
unstack.sh again and retried the installation. it failed with the same message.

So, what are my options right now?

On Thu, Nov 7, 2013 at 7:31 PM, Telles Nobrega 
mailto:tellesnobr...@gmail.com>> wrote:
Sometimes after ./unstack is ran, some process are still runnning for nova.
Try running this to kill them all (ps aux | grep -ie nova | awk '{print $2}' | 
xargs kill -9) and try ./stack again

On Thu, Nov 7, 2013 at 9:14 AM, Noorul Islam K M 
mailto:noo...@noorul.com>> wrote:
Krishanu Dhar mailto:rony.k...@gmail.com>> writes:

> Hi,
>
> I was trying to install the devstack and it failed while starting the nova
> api. below is a snippet from the console. Is it a bug?
>
>
> + screen -S stack -p n-api -X stuff 'cd /opt/stack/nova &&
> /usr/local/bin/nova-a'i || echo "n-api failed to start" | tee
> "/opt/stack/status/stack/n-api.failure"
> + echo 'Waiting for nova-api to start...'
> Waiting for nova-api to start...
> + wait_for_service 60 http://10.0.2.15:8774
> + local timeout=60
> + local url=http://10.0.2.15:8774
> + timeout 60 sh -c 'while ! curl --noproxy '\''*'\'' -s
> http://10.0.2.15:8774 >/dev/null; do sleep 1; done'
> + die 628 'nova-api did not start'
> + local exitcode=0
> + set +o xtrace
> [Call Trace]
> ./stack.sh:1084:start_nova_api
> /home/krish/devstack/lib/nova:628:die
> [ERROR] /home/krish/devstack/lib/nova:628 nova-api did not start
> krish@krish-VirtualBox:~/devstack$
Did you try "screen -x stack" ?

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



--
--
Telles Mota Vidal Nobrega
Developer at PulsarOpenStack Project - HP/LSD-UFCG


--
Krishanu



--
--
Telles Mota Vidal Nobrega
Developer at PulsarOpenStack Project - HP/LSD-UFCG


--
Krishanu



--
--
Telles Mota Vidal Nobrega
Developer at PulsarOpenStack Project - HP/LSD-UFCG


--
Krishanu


--
Krishanu



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

Re: [openstack-dev] nova-api fails to start

[Krishanu Dhar]

thanks man, incidentally i ran into your post too and it got me going.
However, I was wondering if the fix should go in stack.sh.stack.sh


On Fri, Nov 8, 2013 at 12:32 AM, Cazzolato, Sergio J <
sergio.j.cazzol...@intel.com> wrote:

>  Hi, I had the same issue and fixed that doing a chwon and changing the
> ownership to my user of the files in /etc/nova where the owner was the user
> nova.
>
>
>
> In my case the files were: api-paste.ini and policy.json
>
>
>
> I posted the solution there too:
>
>
>
>
> http://stackoverflow.com/questions/19843239/getting-nova628die-trying-to-start-openstack-nova-module
>
>
>
> Thanks
>
>
>
>
>
> *From:* Krishanu Dhar [mailto:rony.k...@gmail.com]
> *Sent:* Thursday, November 07, 2013 3:40 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] nova-api fails to start
>
>
>
> Any other recommendations on how to have a successful devstack
> installation?
>
>
>
> On Thu, Nov 7, 2013 at 11:37 PM, Krishanu Dhar 
> wrote:
>
> below is an error that's probably the cause...
>
> 2013-11-07 23:24:14.758 TRACE nova IOError: [Errno 13] Permission denied:
> '/etc/nova/api-paste.ini'
> 2013-11-07 23:24:14.758 TRACE nova
> n-api failed to start
>
> krish@krish-VirtualBox:/opt/stack/nova$ ls -l /etc/nova/api-paste.ini
> -rw--- 1 nova nova 4260 Apr 23  2013 /etc/nova/api-paste.ini
>
> isn't it expected to fail if the file is owned by "nova"... weird.
>
>
>
>
>
>
>
> On Thu, Nov 7, 2013 at 11:18 PM, Krishanu Dhar 
> wrote:
>
> it did not even start the process in my case.
>
> I tried looking up email threads in google and looks like quite a few have
> run into this before, but couldn't find a working fix.
>
>
>
> On Thu, Nov 7, 2013 at 11:15 PM, Telles Nobrega 
> wrote:
>
> Weird, i had the same problem, but when i kill the processes it works
>
>
>
> On Thu, Nov 7, 2013 at 2:34 PM, Krishanu Dhar  wrote:
>
> Nothing was left behind.
>
> #ps aux|grep -ie nova did not return anything.
>
>
>
> On Thu, Nov 7, 2013 at 11:01 PM, Telles Nobrega 
> wrote:
>
> Did you check if there are any nova process left running?
>
>
>
> On Thu, Nov 7, 2013 at 2:28 PM, Krishanu Dhar  wrote:
>
> Appreciate the responses. But there is something wrong with this. I ran
> unstack.sh again and retried the installation. it failed with the same
> message.
>
> So, what are my options right now?
>
>
>
> On Thu, Nov 7, 2013 at 7:31 PM, Telles Nobrega 
> wrote:
>
> Sometimes after ./unstack is ran, some process are still runnning for
> nova.
>
> Try running this to kill them all (ps aux | grep -ie nova | awk '{print
> $2}' | xargs kill -9) and try ./stack again
>
>
>
> On Thu, Nov 7, 2013 at 9:14 AM, Noorul Islam K M 
> wrote:
>
>   Krishanu Dhar  writes:
>
> > Hi,
> >
> > I was trying to install the devstack and it failed while starting the
> nova
> > api. below is a snippet from the console. Is it a bug?
> >
> >
> > + screen -S stack -p n-api -X stuff 'cd /opt/stack/nova &&
> > /usr/local/bin/nova-a'i || echo "n-api failed to start" | tee
> > "/opt/stack/status/stack/n-api.failure"
> > + echo 'Waiting for nova-api to start...'
> > Waiting for nova-api to start...
> > + wait_for_service 60 http://10.0.2.15:8774
> > + local timeout=60
> > + local url=http://10.0.2.15:8774
> > + timeout 60 sh -c 'while ! curl --noproxy '\''*'\'' -s
> > http://10.0.2.15:8774 >/dev/null; do sleep 1; done'
> > + die 628 'nova-api did not start'
> > + local exitcode=0
> > + set +o xtrace
> > [Call Trace]
> > ./stack.sh:1084:start_nova_api
> > /home/krish/devstack/lib/nova:628:die
> > [ERROR] /home/krish/devstack/lib/nova:628 nova-api did not start
> > krish@krish-VirtualBox:~/devstack$
>
> Did you try "screen -x stack" ?
>
> Regards,
> Noorul
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> --
>
> --
> Telles Mota Vidal Nobrega
> Developer at PulsarOpenStack Project - HP/LSD-UFCG
>
>
>
>   --
> Krishanu
>
>
>
>
>
> --
>
> --
> Telles Mota Vidal Nobrega
> Developer at PulsarOpenStack Project - HP/LSD-UFCG
>
>
>
>   --
> Krishanu
>
>
>
>
>
> --
>
> --
> Telles Mota Vidal Nobrega
> Developer at PulsarOpenStack Project - HP/LSD-UFCG
>
>
>
>   --
> Krishanu
>
>
>
>   --
> Krishanu
>
>
>
>
> --
> Krishanu
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] L3 advanced features blueprint mapping to IETF and IEEE standards

[Rochelle.Grober]

From: Pedro Roque Marques [mailto:pedro.r.marq...@gmail.com]
Colin,
"The nice thing about standards is that there are so many of them to choose 
from."

For instance, if you take this Internet Draft:
http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-02 which is based on 
RFC4364.

It has already been implemented as a Neutron plugin via OpenContrail 
(http://juniper.github.io/contrail-vnc/README.html); With this implementation 
each OpenStack cluster can be configured as its own Autonomous System.

There is a blueprint
https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-mpls-vpn
that is discussing adding the provisioning of the autonomous system and peering 
to Neutron.

Please note that the work above does interoperate with 4364 using option B. 
Option C is possible but not that practical (as an operator you probably don't 
want to expose your internal topology between clusters).

If you want to give it a try you can use this devstack fork: 
https://github.com/dsetia/devstack.
You can use it to interoperate with a standard router that implements 4364 and 
support MPLS over GRE. Products from cisco/juniper/ALU/huwawei etc do.

I believe that the work i'm referencing implements interoperability while 
having very minimal changes to Neutron. It is based on the same concept of 
neutron virtual network and it hides the BGP/MPLS functionality from the user 
by translating policies that establish connectivity between virtual networks 
into RFC 4364 concepts.
Please refer to: 
https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron

Would it make sense to have an IRC/Web meeting around interoperability with 
RFC4364 an OpenStack managed clusters ? I believe that there is a lot of work 
that has already been done there by multiple vendors as well as some carriers.

+1  And it should be scheduled and announced a reasonable time in advance 
developers can plan to participate.

--Rocky

  Pedro.

On Nov 7, 2013, at 12:35 AM, Colin McNamara 
mailto:co...@2cups.com>> wrote:

I have a couple concerns that I don't feel I clearly communicated during the L3 
advanced features session. I'd like to take this opportunity to both clearly 
communicate my thoughts, as well as start a discussion around them.

Building to the edge of the "autonomous system"

The current state of neutron implementation is functionally the l2 domain and 
simple l3 services that are part of a larger autonomous system. The routers and 
switches northbound of the OpenStack networking layer handled the abstraction 
and integration of the components.

Note, I use the term "Autonomous System" to describe more then the notion of 
BGP AS, but more broadly in the term of a system that is controlled within a 
common framework and methodology, and integrates with a peer system that 
doesn't not share that same scope or method of control

These components that composed the autonomous system boundary implement 
protocols and standards that map into IETF and IEEE standards. The reasoning 
for this is interoperability. Before vendors utilize IETF for interoperability 
at this layer, the provider experience was horrible (this was my personal 
experience in the late 90's).


Wednesdays discussions in the Neutron Design Sessions

A couple of the discussions, most notably the extension of l3 functionality 
fell within the scope of starting the process of extending Neutron with 
functionality that will result (eventually) in the ability for an OpenStack 
installation to operate as it's own Autonomous System.

The discussions that occurred to support L3 advanced functionality (northbound 
boundary), and the QOS extension functionality both fell into the scope of 
Northbound and Southbound boundaries of this system.

My comments in the session

My comments in the session, while clouded with jet-lag were specifically around 
two concepts that are used when integrating other types of systems

1. In a simple (1-8) tenant environment integration with a northbound AS is 
normally done in a PE-CE model that generally centers around mapping dot1q tags 
into the appropriate northbound l3 segments and then handling the availability 
of the L2 path that traverses with port channeling, MLAG, STP, Etc.

2. In a complex environment (8+ for discussion) different Carrier Supporting 
Carrier (CSC) methods defined in IETF RFC 4364 Section 10 type A, B or C are 
used. These allow the mapping of segregated tenant networks together and 
synchronizing between distributed systems. This normally extends the tagging or 
tunneling mechanism and then allows for BGP to synchronize NLRI information 
between AS's.

These are the standard ways of integrating between carriers, but also 
components of these implementations are used to integrate and scale inside of a 
single web scale data center. Commonly when you scale beyond a certain physical 
port boundary (1000is edge ports in many implementations, much larger in 
current implementations) the same designs for C2C 

Re: [openstack-dev] Bad review patterns

[Robert Collins]

On 7 November 2013 13:15, Day, Phil  wrote:
>
>

>>
>> Core reviewers look for the /comments/ from people, not just the votes. A
>> +1 from someone that isn't core is meaningless unless they are known to be
>> a thoughtful code reviewer. A -1 with no comment is also bad, because it
>> doesn't help the reviewee get whatever the issue is fixed.
>>
>> It's very much not OK to spend an hour reviewing something and then +1
>> with no comment: if I, and I think any +2er across the project see a patch 
>> that
>> needs an hour of review, with a commentless +1, we'll likely discount the +1
>> as being meaningful.
>>
>
> I don't really get what you're saying here Rob.   It seems to me an almost 
> inevitable
> part of the review process that useful comments are going to be mostly 
> negative.
> If someone has invested that amount of effort because the patch is complex, or
> It took then a while to work their way back into that part of the systems, 
> etc, but
> having given the code careful consideration they decide it's good - do you 
> want
> comments in there saying "I really like your code", "Well done on fixing such 
> a
> complex problem" or some such ?

Negative comments are fine: I was saying that statistically, having an
hour-long patch (which BTW puts it waaay past the diminishing returns
on patch size tradeoff) to review and then having nothing at all to
say about it is super suspect. Sure, having nothing to say on a 10
line patch - hit a +1, move on. But something that takes an hour to
review? I'd expect at minimum the thing to prompt some suggestions
*even while it gets a +1*.

> I just don't see how you can use a lack or presence of positive feedback in a 
> +1 as
> any sort of indication on the quality of that +1.   Unless you start asking 
> reviewers
> to précis the change in their own words to show that they understood it I 
> don't
> really see how additional positive comments help in most cases.   Perhaps if 
> you
> have some specific examples of this it would help to clarify

It might even be negative feedback. Like - "this patch is correct but
the fact it had to be done as one patch shows our code structure here
is wonky. If you could follow up with something to let us avoid future
mammoth patches, that would be awesome."

Again, I'm talking about hour long reviews, which is the example Radomir gave.

Another way of presenting what I'm saying is this: Code reviews are a
dialogue. How often in a discussion with a live human would you have
no feedback at all, if they were reading a speech to you. You might go
'that was a great speech' (+2) and *still* have something to add. As
an observer given a very long speech, and an audience, I'd suspect
folk went to sleep if they didn't have commentary :)


-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] Bad review patterns

[Robert Collins]

On 8 November 2013 00:02, Radomir Dopieralski  wrote:

> I created a page on the wiki,
> https://wiki.openstack.org/wiki/CodeReviewGuidelines
>
> I put some initial content there, based on the discussion in this
> thread. Please feel free to discuss those points further here, and to
> amend that page and add to it.

Thank you. I thought we might have a similar page already, but I only found:
https://wiki.openstack.org/wiki/ReviewChecklist
[what to look for]
and
https://wiki.openstack.org/wiki/ReviewWorkflowTips
[what reviewees should do]

I suspect we probably need to tie all three together somehow.

> Any ideas of where we could put a link to it? I'm thinking about the
> Gerrit Workflow page, maybe also some pages specific to particular teams
> (I've seen there is a page with review tips for Nova).

So https://wiki.openstack.org/wiki/Gerrit_Workflow and the
ReviewWorkflowTips page above overlap a lot.

I think we should merge ReviewWorkflowTips into Gerrit_Workflow, and
link to the review checklist and guidlines pages from Gerrit_Workflow.

-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] nova-api fails to start

[Telles Nobrega]

Now i have something like your problem, im getting
die 609 'nova-api did not start'


On Thu, Nov 7, 2013 at 4:11 PM, Krishanu Dhar  wrote:

> thanks man, incidentally i ran into your post too and it got me going.
> However, I was wondering if the fix should go in stack.sh.stack.sh
>
>
> On Fri, Nov 8, 2013 at 12:32 AM, Cazzolato, Sergio J <
> sergio.j.cazzol...@intel.com> wrote:
>
>>  Hi, I had the same issue and fixed that doing a chwon and changing the
>> ownership to my user of the files in /etc/nova where the owner was the user
>> nova.
>>
>>
>>
>> In my case the files were: api-paste.ini and policy.json
>>
>>
>>
>> I posted the solution there too:
>>
>>
>>
>>
>> http://stackoverflow.com/questions/19843239/getting-nova628die-trying-to-start-openstack-nova-module
>>
>>
>>
>> Thanks
>>
>>
>>
>>
>>
>> *From:* Krishanu Dhar [mailto:rony.k...@gmail.com]
>> *Sent:* Thursday, November 07, 2013 3:40 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] nova-api fails to start
>>
>>
>>
>> Any other recommendations on how to have a successful devstack
>> installation?
>>
>>
>>
>> On Thu, Nov 7, 2013 at 11:37 PM, Krishanu Dhar 
>> wrote:
>>
>> below is an error that's probably the cause...
>>
>> 2013-11-07 23:24:14.758 TRACE nova IOError: [Errno 13] Permission denied:
>> '/etc/nova/api-paste.ini'
>> 2013-11-07 23:24:14.758 TRACE nova
>> n-api failed to start
>>
>> krish@krish-VirtualBox:/opt/stack/nova$ ls -l /etc/nova/api-paste.ini
>> -rw--- 1 nova nova 4260 Apr 23  2013 /etc/nova/api-paste.ini
>>
>> isn't it expected to fail if the file is owned by "nova"... weird.
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Nov 7, 2013 at 11:18 PM, Krishanu Dhar 
>> wrote:
>>
>> it did not even start the process in my case.
>>
>> I tried looking up email threads in google and looks like quite a few
>> have run into this before, but couldn't find a working fix.
>>
>>
>>
>> On Thu, Nov 7, 2013 at 11:15 PM, Telles Nobrega 
>> wrote:
>>
>> Weird, i had the same problem, but when i kill the processes it works
>>
>>
>>
>> On Thu, Nov 7, 2013 at 2:34 PM, Krishanu Dhar 
>> wrote:
>>
>> Nothing was left behind.
>>
>> #ps aux|grep -ie nova did not return anything.
>>
>>
>>
>> On Thu, Nov 7, 2013 at 11:01 PM, Telles Nobrega 
>> wrote:
>>
>> Did you check if there are any nova process left running?
>>
>>
>>
>> On Thu, Nov 7, 2013 at 2:28 PM, Krishanu Dhar 
>> wrote:
>>
>> Appreciate the responses. But there is something wrong with this. I ran
>> unstack.sh again and retried the installation. it failed with the same
>> message.
>>
>> So, what are my options right now?
>>
>>
>>
>> On Thu, Nov 7, 2013 at 7:31 PM, Telles Nobrega 
>> wrote:
>>
>> Sometimes after ./unstack is ran, some process are still runnning for
>> nova.
>>
>> Try running this to kill them all (ps aux | grep -ie nova | awk '{print
>> $2}' | xargs kill -9) and try ./stack again
>>
>>
>>
>> On Thu, Nov 7, 2013 at 9:14 AM, Noorul Islam K M 
>> wrote:
>>
>>   Krishanu Dhar  writes:
>>
>> > Hi,
>> >
>> > I was trying to install the devstack and it failed while starting the
>> nova
>> > api. below is a snippet from the console. Is it a bug?
>> >
>> >
>> > + screen -S stack -p n-api -X stuff 'cd /opt/stack/nova &&
>> > /usr/local/bin/nova-a'i || echo "n-api failed to start" | tee
>> > "/opt/stack/status/stack/n-api.failure"
>> > + echo 'Waiting for nova-api to start...'
>> > Waiting for nova-api to start...
>> > + wait_for_service 60 http://10.0.2.15:8774
>> > + local timeout=60
>> > + local url=http://10.0.2.15:8774
>> > + timeout 60 sh -c 'while ! curl --noproxy '\''*'\'' -s
>> > http://10.0.2.15:8774 >/dev/null; do sleep 1; done'
>> > + die 628 'nova-api did not start'
>> > + local exitcode=0
>> > + set +o xtrace
>> > [Call Trace]
>> > ./stack.sh:1084:start_nova_api
>> > /home/krish/devstack/lib/nova:628:die
>> > [ERROR] /home/krish/devstack/lib/nova:628 nova-api did not start
>> > krish@krish-VirtualBox:~/devstack$
>>
>> Did you try "screen -x stack" ?
>>
>> Regards,
>> Noorul
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>>
>> --
>>
>> --
>> Telles Mota Vidal Nobrega
>> Developer at PulsarOpenStack Project - HP/LSD-UFCG
>>
>>
>>
>>   --
>> Krishanu
>>
>>
>>
>>
>>
>> --
>>
>> --
>> Telles Mota Vidal Nobrega
>> Developer at PulsarOpenStack Project - HP/LSD-UFCG
>>
>>
>>
>>   --
>> Krishanu
>>
>>
>>
>>
>>
>> --
>>
>> --
>> Telles Mota Vidal Nobrega
>> Developer at PulsarOpenStack Project - HP/LSD-UFCG
>>
>>
>>
>>   --
>> Krishanu
>>
>>
>>
>>   --
>> Krishanu
>>
>>
>>
>>
>> --
>> Krishanu
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/op

Re: [openstack-dev] nova-api fails to start

[Krishanu Dhar]

Hey Telies - Were you trying to recreate the failure? or is it a new
installation?


On Fri, Nov 8, 2013 at 2:13 AM, Telles Nobrega wrote:

> Now i have something like your problem, im getting
> die 609 'nova-api did not start'
>
>
> On Thu, Nov 7, 2013 at 4:11 PM, Krishanu Dhar  wrote:
>
>> thanks man, incidentally i ran into your post too and it got me going.
>> However, I was wondering if the fix should go in stack.sh.stack.sh
>>
>>
>> On Fri, Nov 8, 2013 at 12:32 AM, Cazzolato, Sergio J <
>> sergio.j.cazzol...@intel.com> wrote:
>>
>>>  Hi, I had the same issue and fixed that doing a chwon and changing the
>>> ownership to my user of the files in /etc/nova where the owner was the user
>>> nova.
>>>
>>>
>>>
>>> In my case the files were: api-paste.ini and policy.json
>>>
>>>
>>>
>>> I posted the solution there too:
>>>
>>>
>>>
>>>
>>> http://stackoverflow.com/questions/19843239/getting-nova628die-trying-to-start-openstack-nova-module
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>>>
>>> *From:* Krishanu Dhar [mailto:rony.k...@gmail.com]
>>> *Sent:* Thursday, November 07, 2013 3:40 PM
>>> *To:* OpenStack Development Mailing List (not for usage questions)
>>> *Subject:* Re: [openstack-dev] nova-api fails to start
>>>
>>>
>>>
>>> Any other recommendations on how to have a successful devstack
>>> installation?
>>>
>>>
>>>
>>> On Thu, Nov 7, 2013 at 11:37 PM, Krishanu Dhar 
>>> wrote:
>>>
>>> below is an error that's probably the cause...
>>>
>>> 2013-11-07 23:24:14.758 TRACE nova IOError: [Errno 13] Permission
>>> denied: '/etc/nova/api-paste.ini'
>>> 2013-11-07 23:24:14.758 TRACE nova
>>> n-api failed to start
>>>
>>> krish@krish-VirtualBox:/opt/stack/nova$ ls -l /etc/nova/api-paste.ini
>>> -rw--- 1 nova nova 4260 Apr 23  2013 /etc/nova/api-paste.ini
>>>
>>> isn't it expected to fail if the file is owned by "nova"... weird.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Nov 7, 2013 at 11:18 PM, Krishanu Dhar 
>>> wrote:
>>>
>>> it did not even start the process in my case.
>>>
>>> I tried looking up email threads in google and looks like quite a few
>>> have run into this before, but couldn't find a working fix.
>>>
>>>
>>>
>>> On Thu, Nov 7, 2013 at 11:15 PM, Telles Nobrega 
>>> wrote:
>>>
>>> Weird, i had the same problem, but when i kill the processes it works
>>>
>>>
>>>
>>> On Thu, Nov 7, 2013 at 2:34 PM, Krishanu Dhar 
>>> wrote:
>>>
>>> Nothing was left behind.
>>>
>>> #ps aux|grep -ie nova did not return anything.
>>>
>>>
>>>
>>> On Thu, Nov 7, 2013 at 11:01 PM, Telles Nobrega 
>>> wrote:
>>>
>>> Did you check if there are any nova process left running?
>>>
>>>
>>>
>>> On Thu, Nov 7, 2013 at 2:28 PM, Krishanu Dhar 
>>> wrote:
>>>
>>> Appreciate the responses. But there is something wrong with this. I ran
>>> unstack.sh again and retried the installation. it failed with the same
>>> message.
>>>
>>> So, what are my options right now?
>>>
>>>
>>>
>>> On Thu, Nov 7, 2013 at 7:31 PM, Telles Nobrega 
>>> wrote:
>>>
>>> Sometimes after ./unstack is ran, some process are still runnning for
>>> nova.
>>>
>>> Try running this to kill them all (ps aux | grep -ie nova | awk '{print
>>> $2}' | xargs kill -9) and try ./stack again
>>>
>>>
>>>
>>> On Thu, Nov 7, 2013 at 9:14 AM, Noorul Islam K M 
>>> wrote:
>>>
>>>   Krishanu Dhar  writes:
>>>
>>> > Hi,
>>> >
>>> > I was trying to install the devstack and it failed while starting the
>>> nova
>>> > api. below is a snippet from the console. Is it a bug?
>>> >
>>> >
>>> > + screen -S stack -p n-api -X stuff 'cd /opt/stack/nova &&
>>> > /usr/local/bin/nova-a'i || echo "n-api failed to start" | tee
>>> > "/opt/stack/status/stack/n-api.failure"
>>> > + echo 'Waiting for nova-api to start...'
>>> > Waiting for nova-api to start...
>>> > + wait_for_service 60 http://10.0.2.15:8774
>>> > + local timeout=60
>>> > + local url=http://10.0.2.15:8774
>>> > + timeout 60 sh -c 'while ! curl --noproxy '\''*'\'' -s
>>> > http://10.0.2.15:8774 >/dev/null; do sleep 1; done'
>>> > + die 628 'nova-api did not start'
>>> > + local exitcode=0
>>> > + set +o xtrace
>>> > [Call Trace]
>>> > ./stack.sh:1084:start_nova_api
>>> > /home/krish/devstack/lib/nova:628:die
>>> > [ERROR] /home/krish/devstack/lib/nova:628 nova-api did not start
>>> > krish@krish-VirtualBox:~/devstack$
>>>
>>> Did you try "screen -x stack" ?
>>>
>>> Regards,
>>> Noorul
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> --
>>> Telles Mota Vidal Nobrega
>>> Developer at PulsarOpenStack Project - HP/LSD-UFCG
>>>
>>>
>>>
>>>   --
>>> Krishanu
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> --
>>> Telles Mota Vidal Nobrega
>>> Developer at PulsarOpenStack Project - HP/LSD-UFCG
>>>
>>>
>>>
>>>   --
>>> Krishanu
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> --
>>

Re: [openstack-dev] [Solum] Choice of API infrastructure

[Steven Dake]

On 11/07/2013 07:28 AM, Jay Pipes wrote:
Hey Doug, following up, but realize you are likely very busy at the 
summit :)


On 11/04/2013 10:20 PM, Doug Hellmann wrote:

On Tue, Nov 5, 2013 at 10:37 AM, Jay Pipes declaring the models for the consumer of the API, rather than 
the

implementer of the API.


I don't really see the point of the distinction. At the end of the
day, the consumer of the API is using the API to manipulate and
retrieve data. That data is really the model, with some syntactic
sugar like Atom links, etc. Even in a control API -- as opposed to a
data API like Glance, Ceilometer or Swift -- the benefits of a heavy
API layer like Pecan and WSME are pretty small, IMO.


That approach binds your API tightly to the database representation,
which we were trying to avoid.


I wasn't referring to the database representation, actually. I was 
referring to the data model, which is different in that it abstracts 
away any underlying schema or storage engine...



I would much rather see the Ceilometer models [1] actually be models
that can validate the data that is used to construct the model
object instead of having duplicated WSME "models" repeated in the
WSGI controller code [2]. The reason is because if/when I decide to
make a Ceilometer API that uses a different protocol, say AMQP,
instead of HTTP, now I need to duplicate all of the validation code
that WSME is providing on the data model layer... however if the
validation was in the models themselves, I could easily create an
API on a different protocol using just the models for validation.

We do that in some cases. However, there is also a difference in some
cases between the validation at the API layer (a value must be a number,
or a UUID, etc.) and the validation in the database layer (a number must
fall within a range or a UUID must refer to an existing object). So
there is a place for both, and the validation done in the WSME classes
is not meant to be the only validation performed.


OK, understood.


The benefits of declaring WSME classes include automatic
serialization
in JSON and XML, generating WADL files to be included in the API
docs
(work is already happening to make this available for 
everyone), and

consistent input and output types for API endpoints (making it
easier
for consumers of the API to use it and for implementers to 
validate

inputs and assume consistent defaults).


I can't stand XML. I believe it should be retired to the dustbin of
coding history, like Basic.

You've made that clear in the past. :-) I agree, for what it's worth.
Some of our users do seem to want it, and with WSME *you don't have to
care*.


Also understood. :)


That said, consumers of a RESTful API don't care how the API is
implemented. They care that it's documented and consistent, and if
WSME makes API documentation easier, then that's A Good Thing, 
agreed.


It's true that WSME includes some stuff to make validating inputs
"easier", but it does so, IMHO, at the expense of readability
because everything is decorated and hidden away somewhere other than
the models themselves. See note above...

I'm not sure what that means. Hidden where? The validation is either
described in the attribute specifier for the model, or in the model's
class, or in the controller (depending on the scope of the rule being
applied).


Sorry, "hidden" wasn't the best word to describe that. I meant more 
"it's less obvious to folks who expect to find validation of the data 
model at the data model layer" :)



And, to be clear, Pecan and WSME are integrated by Pecan can
definitely
be used without WSME. I included WSME in the proposal to 
replace the

home-grown WSGI framework because I thought it added significant
benefits, but it is not going to be appropriate for all 
situations

(streaming large image files is one example).


Yes, in one way it's a bit unfortanate that we're now comparing Falcon 
with Pecan + WSME as opposed to just comparing Falcon with Pecan and 
then evaluating whether WSME should be used (on top of either one...). 
It's unfortunate because we've spent all this email thread actually 
talking about WSME and not much at all about Pecan ;)



Here's a third reason I don't care for Pecan/WSME: it uses Webob.
Other than eventlet, I don't know of a single library that OpenStack
projects have used over the years that we've had more issues with
than Webob.

Yes, I felt the pain of updating us to the latest WebOb. The project has
evolved since those days, and the current maintainers are committed to
not breaking the API. That new attitude, combined with the long history
of addressing edge cases from misbehaving web client libraries makes m e
less reluctant to use WebOb than in the past.


OK, that's good to hea

Re: [openstack-dev] [Solum]: Workshop dates at SFO

[Roshan Agrawal]

Based on what I am seeing on the doodle poll, we are sticking to the original 
dates for the workshop [Nov 19, 20]

Eventbrite registration page https://www.eventbrite.com/event/9130831563
Etherpad planning page for the event  
https://etherpad.openstack.org/p/SolumSFOCommunityWorkshop

See you all for a great set of discussions!

From: Roshan Agrawal
Sent: Wednesday, November 06, 2013 8:45 PM
To: openstack-dev@lists.openstack.org
Subject: [Solum]: Workshop dates at SFO

Folks, some of us indicated they cannot make Nov 19,20, so I created a doodle 
poll to finalize a date that works for most of us. Please take a moment to 
indicate your preference on the doodle link below -

http://www.doodle.com/6yey9nfgfapzv4f8

Please get this done by EOD if you can.

Thanks,
Roshan

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

[openstack-dev] [Swift] log line length

[Pecoraro, Alex]

Is there any way for me to change the logging so that it doesn't truncate the 
output - so basically the length of the line printed to the log is not limited 
to a certain length?

Thanks.

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

Re: [openstack-dev] [Solum] Choice of API infrastructure

[Adrian Otto]

Solum Team,

First of all I wanted to say that I have been thinking a lot about this thread, 
and have been seeking input from a number of you who attended the Summit this 
week. I do *not* see this decision as a critical one, because if something 
really mattered a ton we could rip our one framework and put another in. 

What I love about this discussion is that we are having a healthy debate about 
different points of view, which was very thought provoking. I have heard input 
from skeptics who think that engineering decisions have to be made in a small 
group in order to be efficient. I know that thinking is wrong, and it's 
examples like these that convince me further that discussions like these help 
us make better choices, and make development more efficient over the long run.

We should give the most weight to the preferences of the engineers who will 
write and maintain the code. If there are team members who are volunteering to 
write and maintain the bulk of our API code over a period of time who really 
want Falcon over Pecan, then we should give that fair consideration. The API is 
exceedingly important to Solum, and all of us will be working on it, so we need 
a choice that all of us can live with.

I suggest that we settle on Pecan+WSME, for the following reasons:

1) It is a known quantity, and is likely to work well for Solum's needs, 
considering that Solum is primarily a control plane API system, and that 
performance is not a primary motivator.

2) Pecan+WSME allows us to offer data serializations in both JSON and XML to 
help satisfy the preferences of the API consumers. 

3) It allows us to have multiple models that are loosely coupled, which can aid 
in data validation.

4) At this point in time, other OpenStack core/integrated/ecosystem projects 
are using Pecan+WSME, and several Solum contributors will be switching between 
projects. There is an advantage to a higher level of consistency among various 
projects.

I accept that Webob may be problematic for us, that performance may be less 
than ideal, and that some Solum developers may dislike working with WSME, and 
that Falcon may actually be more pleasant to work with. We have team members 
with a deep understanding of Falcon, and could definitely make it work. We can 
proceed with Pecan+WSME accepting these (and  other) trade-offs.

Are there any other critically important considerations that we should consider 
before converging on this choice? I'd like to hear that input prior to our next 
IRC meeting.

Thanks,

Adrian


On Nov 8, 2013, at 5:59 AM, Steven Dake  wrote:

> On 11/07/2013 07:28 AM, Jay Pipes wrote:
>> Hey Doug, following up, but realize you are likely very busy at the summit :)
>> 
>> On 11/04/2013 10:20 PM, Doug Hellmann wrote:
>>> On Tue, Nov 5, 2013 at 10:37 AM, Jay Pipes >> 
>>>The "models" defined in WSME are completely different from the
>>>database
>>>models, and should not be used outside of the API code. Think of
>>>them as
>>>declaring the models for the consumer of the API, rather than the
>>>implementer of the API.
>>> 
>>> 
>>>I don't really see the point of the distinction. At the end of the
>>>day, the consumer of the API is using the API to manipulate and
>>>retrieve data. That data is really the model, with some syntactic
>>>sugar like Atom links, etc. Even in a control API -- as opposed to a
>>>data API like Glance, Ceilometer or Swift -- the benefits of a heavy
>>>API layer like Pecan and WSME are pretty small, IMO.
>>> 
>>> 
>>> That approach binds your API tightly to the database representation,
>>> which we were trying to avoid.
>> 
>> I wasn't referring to the database representation, actually. I was referring 
>> to the data model, which is different in that it abstracts away any 
>> underlying schema or storage engine...
>> 
>>>I would much rather see the Ceilometer models [1] actually be models
>>>that can validate the data that is used to construct the model
>>>object instead of having duplicated WSME "models" repeated in the
>>>WSGI controller code [2]. The reason is because if/when I decide to
>>>make a Ceilometer API that uses a different protocol, say AMQP,
>>>instead of HTTP, now I need to duplicate all of the validation code
>>>that WSME is providing on the data model layer... however if the
>>>validation was in the models themselves, I could easily create an
>>>API on a different protocol using just the models for validation.
>>> 
>>> We do that in some cases. However, there is also a difference in some
>>> cases between the validation at the API layer (a value must be a number,
>>> or a UUID, etc.) and the validation in the database layer (a number must
>>> fall within a range or a UUID must refer to an existing object). So
>>> there is a place for both, and the validation done in the WSME classes
>>> is not meant to be the only validation performed.
>> 
>> OK, understood.
>

Re: [openstack-dev] [Solum] Choice of API infrastructure

[Jay Pipes]

On 11/07/2013 06:41 PM, Adrian Otto wrote:

Solum Team,

First of all I wanted to say that I have been thinking a lot about this thread, 
and have been seeking input from a number of you who attended the Summit this 
week. I do *not* see this decision as a critical one, because if something 
really mattered a ton we could rip our one framework and put another in.

What I love about this discussion is that we are having a healthy debate about 
different points of view, which was very thought provoking. I have heard input 
from skeptics who think that engineering decisions have to be made in a small 
group in order to be efficient. I know that thinking is wrong, and it's 
examples like these that convince me further that discussions like these help 
us make better choices, and make development more efficient over the long run.

We should give the most weight to the preferences of the engineers who will 
write and maintain the code. If there are team members who are volunteering to 
write and maintain the bulk of our API code over a period of time who really 
want Falcon over Pecan, then we should give that fair consideration. The API is 
exceedingly important to Solum, and all of us will be working on it, so we need 
a choice that all of us can live with.

I suggest that we settle on Pecan+WSME, for the following reasons:

1) It is a known quantity, and is likely to work well for Solum's needs, 
considering that Solum is primarily a control plane API system, and that 
performance is not a primary motivator.

2) Pecan+WSME allows us to offer data serializations in both JSON and XML to 
help satisfy the preferences of the API consumers.

3) It allows us to have multiple models that are loosely coupled, which can aid 
in data validation.

4) At this point in time, other OpenStack core/integrated/ecosystem projects 
are using Pecan+WSME, and several Solum contributors will be switching between 
projects. There is an advantage to a higher level of consistency among various 
projects.

I accept that Webob may be problematic for us, that performance may be less 
than ideal, and that some Solum developers may dislike working with WSME, and 
that Falcon may actually be more pleasant to work with. We have team members 
with a deep understanding of Falcon, and could definitely make it work. We can 
proceed with Pecan+WSME accepting these (and  other) trade-offs.

Are there any other critically important considerations that we should consider 
before converging on this choice? I'd like to hear that input prior to our next 
IRC meeting.


None that I can think of. I'll get behind the decision, then, and if all 
are in consensus, I'll abandon the Falcon API patch.


We do need to get the Pecan/WSME patch to pass the gates though :) Doug, 
I'm hoping you might give Noorul a hand with that next week upon your 
return from Hong Kong?


All the best,
-jay


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

Re: [openstack-dev] Bad review patterns

[Sean Dague]

On 11/07/2013 01:56 PM, James Bottomley wrote:
> On Thu, 2013-11-07 at 00:21 +, Day, Phil wrote:
>>>
>>> Leaving a mark.
>>> ===
>>>
>>> You review a change and see that it is mostly fine, but you feel that since 
>>> you
>>> did so much work reviewing it, you should at least find
>>> *something* wrong. So you find some nitpick and -1 the change just so that
>>> they know you reviewed it.
>>>
>>> This is quite obvious. Just don't do it. It's OK to spend an hour reviewing
>>> something, and then leaving no comments on it, because it's simply fine, or
>>> because we had to means to test someting (see the first pattern).
>>>
>>>
>>
>> Another one that comes into this category is adding a -1 which just says "I 
>> agree with
>> the other -1's in here".   If you have some additional perspective and can 
>> expand on
>> it then that's fine - otherwise it adds very little and is just review count 
>> chasing.
>>
>> It's an unfortunate consequence of counting and publishing review stats that 
>> having
>> such a measure will inevitable also drive behavour.
> 
> Perhaps a source of the problem is early voting.  Feeling pressure to
> add a +/-1 (or even 2) without fully asking what's going on in the code
> leads to premature adjudication.
> 
> For instance, I have to do a lot of reviews in SCSI; I'm a subject
> matter expert, so I do recognise some bad coding patterns and ask for
> them to be changed unconditionally, but a lot of the time I don't
> necessarily understand why the code was done in the way it was, so I
> ask.  Before I get the answer I'm not really qualified to judge the
> merits.

+1 to this.

Realistically if I have questions in the code and am unsure how I'd
score it I'll often leave a 0 review with questions inline to help me
understand. I consider this generally good form, and it's helpful to
everyone in the learning process about the code.

-Sean

-- 
Sean Dague
http://dague.net



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

Re: [openstack-dev] Bad review patterns

[Sean Dague]

On 11/07/2013 05:35 PM, Jiri Tomasek wrote:
> On 11/07/2013 08:25 AM, Daniel P. Berrange wrote:
>> On Thu, Nov 07, 2013 at 12:21:38AM +, Day, Phil wrote:
 Leaving a mark.
 ===

 You review a change and see that it is mostly fine, but you feel
 that since you
 did so much work reviewing it, you should at least find
 *something* wrong. So you find some nitpick and -1 the change just
 so that
 they know you reviewed it.

 This is quite obvious. Just don't do it. It's OK to spend an hour
 reviewing
 something, and then leaving no comments on it, because it's simply
 fine, or
 because we had to means to test someting (see the first pattern).


>>> Another one that comes into this category is adding a -1 which just
>>> says "I agree with
>>> the other -1's in here".   If you have some additional perspective
>>> and can expand on
>>> it then that's fine - otherwise it adds very little and is just
>>> review count chasing.
>> I don't think that it is valueless as you describe. If I multiple people
>> add '-1' with a "same comments as ", then as a core reviewer I will
>> consider that initial -1 to be a much stronger nack, than if only one
>> person
>> had added the -1. So I welcome people adding "I agree with " to any
>> review.
>>
>>> It's an unfortunate consequence of counting and publishing review
>>> stats that having
>>> such a measure will inevitable also drive behavour.
>> IMHO what this shows is not people trying to game the stats, but
>> rather the
>> inadequacy of gerrit. We don't have any way to distinguish a "-1 minor
>> nice
>> to have nitpick" from a "-1 serious code issue that is a must-fix".
>> Adding
>> a -2 is really too heavyweight because it is sticky, and implies "do not
>> ever merge this".
>>
>> It would be nice to be able to use '-2' for "serious must-fix issue"
>> without
>> it being sticky, and have a separate way for core reviewers to put an
>> review
>> into a "block from being merged indefinitely" state - perhaps a new state
>> would be more useful eg a "Blocked" state, to add to New, Open, Merged,
>> Abadoned.
>>
>> Daniel
> The comment describing the  -1 should be enough to distinquish between
> minor nitpick and serious code issue IMHO. If it is a serious issue,
> other reviewers also giving -1 confirming the issue is probably a good
> thing. (Not with the minor nit though...)

Agreed, the comments are there for a reason. It's also handy to provide
forward looking statements to other reviewers in case you don't get back
to the review queue right away.

For instance when I know that might happen I tend to leave comments like
"I'm +2 after the following  is addressed." That's also extremely
helpful to provide incentive to the submitter to make those kinds of
changes.

Not all submissions fit into this kind of category, some really need to
iterate through sets of issues to get ready for the code base. But when
they are close, defining the end state for the contributor and other
reviewers that won't feel like they need to wait for your comments on
the updated review (because you clearly explained what you thought
needed to change) is helpful.

-Sean

-- 
Sean Dague
http://dague.net



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

Re: [openstack-dev] Bad review patterns

[Sean Dague]

On 11/08/2013 01:37 AM, Pedro Roque Marques wrote:
> Radomir,
> An extra issue that i don't believe you've covered so far is about comment 
> ownership. I've just read an email on the list that follows a pattern that 
> i've heard many complaints about:
>   -1 with a reasonable comment, submitter addresses the comment, reviewer 
> never comes back.
> 
> Reviewers do need to allocate time to come back and follow up on the answers 
> to their comments.
> 
> Perhaps there is an issue with the incentive system. You can earn karma by 
> doing a code review... certainly you want to incentivise developers that help 
> the project by improving the code quality. But if the incentive system allows 
> for "drive by shooting" code reviews that can be a problem.

It's not really an incentive system problem, this is some place where
there are some gerrit limitations (especially when your list of reviewed
code is long). Hopefully once we get a gerrit upgrade we can dashboard
out some new items like that via the new rest API.

I agree that reviewers could be doing better. But definitely also
realize that part of this is just that there is *so* much code to review.

Realize that most core reviewers aren't ignoring or failing to come back
on patches intentionally. There is just *so* much of it. I feel guilty
all the time by how big a review queue I have, but I also need a few
hours a day not doing OpenStack (incredible to believe). This is where
non core reviewers can really help in addressing the first couple of
rounds of review to prune and improve the easy stuff.

We're all in this together,

-Sean

-- 
Sean Dague
http://dague.net



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

Re: [openstack-dev] nova-api fails to start

[Telles Nobrega]

It was a new installation, but i tried a couple more times, removed all the 
component folders and it worked

--
___
Telles Mota Vidal Nóbrega

Undergraduated in Computer Science at Federal University of Campina Grande 
(UFCG)
Developer at PulsarOpenStack Project - HP

On 07 Nov 2013, at 17:54, Krishanu Dhar  wrote:

> Hey Telies - Were you trying to recreate the failure? or is it a new 
> installation?
> 
> 
> On Fri, Nov 8, 2013 at 2:13 AM, Telles Nobrega  
> wrote:
> Now i have something like your problem, im getting 
> die 609 'nova-api did not start'
> 
> 
> On Thu, Nov 7, 2013 at 4:11 PM, Krishanu Dhar  wrote:
> thanks man, incidentally i ran into your post too and it got me going. 
> However, I was wondering if the fix should go in stack.sh.stack.sh
> 
> 
> On Fri, Nov 8, 2013 at 12:32 AM, Cazzolato, Sergio J 
>  wrote:
> Hi, I had the same issue and fixed that doing a chwon and changing the 
> ownership to my user of the files in /etc/nova where the owner was the user 
> nova.
> 
>  
> 
> In my case the files were: api-paste.ini and policy.json
> 
>  
> 
> I posted the solution there too:
> 
>  
> 
> http://stackoverflow.com/questions/19843239/getting-nova628die-trying-to-start-openstack-nova-module
> 
>  
> 
> Thanks
> 
>  
> 
>  
> 
> From: Krishanu Dhar [mailto:rony.k...@gmail.com] 
> Sent: Thursday, November 07, 2013 3:40 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] nova-api fails to start
> 
>  
> 
> Any other recommendations on how to have a successful devstack installation?
> 
>  
> 
> On Thu, Nov 7, 2013 at 11:37 PM, Krishanu Dhar  wrote:
> 
> below is an error that's probably the cause...
> 
> 2013-11-07 23:24:14.758 TRACE nova IOError: [Errno 13] Permission denied: 
> '/etc/nova/api-paste.ini'
> 2013-11-07 23:24:14.758 TRACE nova 
> n-api failed to start
> 
> krish@krish-VirtualBox:/opt/stack/nova$ ls -l /etc/nova/api-paste.ini
> -rw--- 1 nova nova 4260 Apr 23  2013 /etc/nova/api-paste.ini
> 
> isn't it expected to fail if the file is owned by "nova"... weird.
> 
>  
> 
>  
> 
>  
> 
> On Thu, Nov 7, 2013 at 11:18 PM, Krishanu Dhar  wrote:
> 
> it did not even start the process in my case.
> 
> I tried looking up email threads in google and looks like quite a few have 
> run into this before, but couldn't find a working fix.
> 
>  
> 
> On Thu, Nov 7, 2013 at 11:15 PM, Telles Nobrega  
> wrote:
> 
> Weird, i had the same problem, but when i kill the processes it works
> 
>  
> 
> On Thu, Nov 7, 2013 at 2:34 PM, Krishanu Dhar  wrote:
> 
> Nothing was left behind. 
> 
> #ps aux|grep -ie nova did not return anything.
> 
>  
> 
> On Thu, Nov 7, 2013 at 11:01 PM, Telles Nobrega  
> wrote:
> 
> Did you check if there are any nova process left running?
> 
>  
> 
> On Thu, Nov 7, 2013 at 2:28 PM, Krishanu Dhar  wrote:
> 
> Appreciate the responses. But there is something wrong with this. I ran 
> unstack.sh again and retried the installation. it failed with the same 
> message. 
> 
> So, what are my options right now?
> 
>  
> 
> On Thu, Nov 7, 2013 at 7:31 PM, Telles Nobrega  
> wrote:
> 
> Sometimes after ./unstack is ran, some process are still runnning for nova. 
> 
> Try running this to kill them all (ps aux | grep -ie nova | awk '{print $2}' 
> | xargs kill -9) and try ./stack again
> 
>  
> 
> On Thu, Nov 7, 2013 at 9:14 AM, Noorul Islam K M  wrote:
> 
> Krishanu Dhar  writes:
> 
> > Hi,
> >
> > I was trying to install the devstack and it failed while starting the nova
> > api. below is a snippet from the console. Is it a bug?
> >
> >
> > + screen -S stack -p n-api -X stuff 'cd /opt/stack/nova &&
> > /usr/local/bin/nova-a'i || echo "n-api failed to start" | tee
> > "/opt/stack/status/stack/n-api.failure"
> > + echo 'Waiting for nova-api to start...'
> > Waiting for nova-api to start...
> > + wait_for_service 60 http://10.0.2.15:8774
> > + local timeout=60
> > + local url=http://10.0.2.15:8774
> > + timeout 60 sh -c 'while ! curl --noproxy '\''*'\'' -s
> > http://10.0.2.15:8774 >/dev/null; do sleep 1; done'
> > + die 628 'nova-api did not start'
> > + local exitcode=0
> > + set +o xtrace
> > [Call Trace]
> > ./stack.sh:1084:start_nova_api
> > /home/krish/devstack/lib/nova:628:die
> > [ERROR] /home/krish/devstack/lib/nova:628 nova-api did not start
> > krish@krish-VirtualBox:~/devstack$
> 
> Did you try "screen -x stack" ?
> 
> Regards,
> Noorul
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
>  
> 
> --
> 
> --
> Telles Mota Vidal Nobrega
> Developer at PulsarOpenStack Project - HP/LSD-UFCG
> 
> 
> 
> 
> -- 
> Krishanu
> 
> 
> 
> 
>  
> 
> --
> 
> --
> Telles Mota Vidal Nobrega
> Developer at PulsarOpenStack Project - HP/LSD-UFCG
> 
> 
> 
> 
> -- 
> Krishanu
> 
> 
> 
> 
>  
> 
>

[openstack-dev] [nova][api] Is this a potential issue

[Jiang, Yunhong]

Hi, all
I'm a bit confused of followed code in ./compute/api.py, which will be 
invoked by api/openstack/compute/servers.py, _action_revert_resize(). 
From the code seems there is a small windows between get the migration 
object and update migration.status. If another API request comes at this small 
window, it means two utility will try to revert resize at same time. Is this a 
potential issue?
Currently implementation already roll back the reservation if something 
wrong, but not sure if we should update state to "reverting" as a transaction 
in get_by_instance_and_status()?

--jyh

def revert_resize(self, context, instance):
"""Reverts a resize, deleting the 'new' instance in the process."""
elevated = context.elevated()
migration = migration_obj.Migration.get_by_instance_and_status(
elevated, instance.uuid, 'finished')
>>Here we get the migration object

# reverse quota reservation for increased resource usage
deltas = self._reverse_upsize_quota_delta(context, migration)
reservations = self._reserve_quota_delta(context, deltas)

instance.task_state = task_states.RESIZE_REVERTING
instance.save(expected_task_state=None)

migration.status = 'reverting'  >>Here we 
update the status.
migration.save()

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

Re: [openstack-dev] Bad review patterns

[David Ripton]

On 11/07/2013 07:54 PM, Sean Dague wrote:

On 11/08/2013 01:37 AM, Pedro Roque Marques wrote:

Radomir,
An extra issue that i don't believe you've covered so far is about comment 
ownership. I've just read an email on the list that follows a pattern that i've 
heard many complaints about:
-1 with a reasonable comment, submitter addresses the comment, reviewer 
never comes back.

Reviewers do need to allocate time to come back and follow up on the answers to 
their comments.

Perhaps there is an issue with the incentive system. You can earn karma by doing a code 
review... certainly you want to incentivise developers that help the project by improving 
the code quality. But if the incentive system allows for "drive by shooting" 
code reviews that can be a problem.


It's not really an incentive system problem, this is some place where
there are some gerrit limitations (especially when your list of reviewed
code is long). Hopefully once we get a gerrit upgrade we can dashboard
out some new items like that via the new rest API.

I agree that reviewers could be doing better. But definitely also
realize that part of this is just that there is *so* much code to review.

Realize that most core reviewers aren't ignoring or failing to come back
on patches intentionally. There is just *so* much of it. I feel guilty
all the time by how big a review queue I have, but I also need a few
hours a day not doing OpenStack (incredible to believe). This is where
non core reviewers can really help in addressing the first couple of
rounds of review to prune and improve the easy stuff.

We're all in this together,


Is there a way for Gerrit to only send email when action is required, 
rather than on any change to any review you've touched?  If Gerrit sent 
less mail, it would be easier to treat its mails as a critical call to 
action to re-review.  (There's probably a way to use fancy message 
filtering to accomplish this, but that would only work for people 
willing/able to set up such filtering.)


--
David Ripton   Red Hat   drip...@redhat.com

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

Re: [openstack-dev] [Solum] Some initial code copying for db/migration

[Clayton Coleman]

- Original Message -
> >   
> > https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L420
> >   
> > https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L43
> 
> This API and these models are what we are trying to avoid exposing to
> the rest of nova. By wrapping these in our NovaObject-based structures,
> we can bundle versioned data and methods together which is what we need
> for cross-version compatibility and parity for the parts of nova that
> are not allowed to talk to the database directly.
> 
> See the code in nova/objects/* for the implementations. Right now, these
> just call into the db_api.py, but eventually we want to move the actual
> database implementation into the objects themselves and hopefully
> dispense with most or all of the sqlalchemy/* stuff. This also provides
> us the ability to use other persistence backends that aren't supported
> by sqlalchemy, or that don't behave like it does.
> 
> If you're going to be at the summit, come to the "objects" session on
> Thursday where we'll talk about this in more detail. Other projects have
> expressed interest in moving the core framework into Oslo so that we're
> all doing things in roughly the same way. It would be good to get you
> started on "the right way" early on before you have the migration hassle
> we're currently "enjoying" in Nova :)
> 
> --Dan
> 

The summit session was excellent - next step for me is to look through what the 
right abstraction is going to be for objects that keeps the db details properly 
isolated and the API surface on /objects suitably coarse (in line with the long 
discussion in Nova about non-SQL backends, the consensus of which is that the 
domain object model needs to abstract whole interaction flows, vs granular 
steps).  I'll try to have some example code to debate after I get back from 
summit.

Even assuming Solum has a fairly small persistence model, in the long run I 
believe it's fair to say that the ability to perform live upgrades will become 
critical for all operators.  One of the side effects of supporting potentially 
millions of applications (at the high end, and not an unreasonable estimate for 
hosted environments) is that any period of downtime at the API level will 
prevent users from making deployments, which is a direct line-of-business 
concern.  Designing around live upgrades - specifically, the requirement that 
code must be aware of two versions of a schema at the same time - implies that 
the domain model must be able to be aware of those versions on an object basis. 
 For reference, [1] and [2] contain some of the Nova discussion, and Nova in 
icehouse is going to be moving this way.  I'd prefer (it's important to Red 
Hat) to design for that from the beginning and be working towards that end.

Do folks have additional questions or concerns about my exploration of a 
versioned domain object model from day one?  Are there others who would like to 
embrace quick and dirty and explicitly ignore this issue until we have a Solum 
prototype running?  

[1] https://etherpad.openstack.org/p/NovaIcehouseSummitUpgrades
[2] https://etherpad.openstack.org/p/NovaIcehouseSummitObjects

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

[openstack-dev] Shall backward compatibility env. vars be removed from python-clients?

[Leandro Costantino]

Hi all,

Clients like python-novaclient/cinderclient/trove still support NOVA_*, 
CINDER_*, TROVE_* variables for 
backward compatibility support,while clients like 
python-neutronclient/keystoneclient only supports OS_* env vars.


The following bug (#1061491, see review), mentions that it may be confusing if 
novaclient for instance, 
silently accept those variables without even being mentioned on the current 
help/documentation neither warning the user at all. 
(User has exported NOVA_USERNAME/CINDER_USERNAME/etc instead of OS_USERNAME 
etc.)
 
As Kevin suggested on the review, (https://review.openstack.org/#/c/55588/) 
“we need to make sure that we have consensus that enough time has  passed to 
drop the old variables”.

I would like to hear opinions about this. Some options that i can think of are:

1) Remove NOVA_USERNAME, NOVA_PASSWORD and NOVA_PROJECT_ID support 
   from novaclient. Same for other clients allowing vars other than OS_USERNAME,
   OS_PASSWORD, OS_TENANT_ID for this specific options.
2) Warn about deprecation if they are being used.
3) Ignore this topic, keep everything as today and just close the 
'bug/suggestion'.
4) Other?

Best Regards
-Leandro

PS: shall this message belong to another ML, please, let me know.








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

Re: [openstack-dev] [Neutron] IPv6 sub-team?

[Collins, Sean (Contractor)]

How about scheduling an IRC meeting in close proximity to the other
Neutron meetings on Mondays?

* 20:00 to 21:00 UTC, before the Neutron meeting

OR

* 23:00 UTC - after the distributed virtual router meeting?

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

Re: [openstack-dev] What key strings can we set in "scheduler_hints" param when boot an instance?

[Day, Phil]

The hints are coded into the various scheduler filters, so the set supported on 
any install depends on what filters have been  configured.

I have a change under way (I need to just find the time to go back and fix the 
last wave of review comments) to expose what is supported via an API call

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


From: openstack learner [mailto:openstacklea...@gmail.com]
Sent: 06 November 2013 20:01
To: openstack-dev@lists.openstack.org; openst...@lists.openstack.org
Subject: [openstack-dev] What key strings can we set in "scheduler_hints" param 
when boot an instance?

Hi all,
I am using the nova python api and recently i need to use the filter schedule 
hint when i boot up an instance.  In the 
novaclient.v1_1.client.Client.servers.create() method, there is a
:param scheduler_hints: (optional extension) arbitrary key-value pairs
  specified by the client to help boot an instance

which we can specify the key-value pairs to help boot an instance.
However, i don't know what "key string" can I specify in my key-values pairs. I 
search online but did not get any information about that?  Is there any 
document that list all the keystrings we can specify in the scheduler_hints?  I 
would like to have a list of all the "keys" that we can specify in the 
scheduler_hints.
Thanks a lot
xin
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Climate Project Slides

[Dina Belova]

Guys, there was presentation about Climate Project (Reservation Service for
OpenStack) on this Hong Kong Summit. Please take a look on Slideshare
slides if you are interested in it:

Climate project
slides

Thank everybody who have come on our session!

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Nova] [Climate] Reservation service called Climate

[Dina Belova]

Guys, there are Slideshare slides if it is more comfortable to use them for
you:

Slideshare Climate
Slides

Thanks!


On Wed, Nov 6, 2013 at 5:47 PM, Sylvain Bauza wrote:

>  Hi,
>
> During the Design session
> https://etherpad.openstack.org/p/NovaIcehouse-Instance-Group-API we
> discussed the fact that this is not the role of Nova for doing atomic
> reservations in order to ensure the user needs will be met.
>
> I raised the point (and sorry for my bad accent, was stressy) that we're
> already trying to provide a reservation system for Openstack, called
> Climate (a Stackforge project).
> I would really like to discuss with you all, Nova community, about the
> reservation system and ensure that we, at Climate, are on the good path.
>
> Climate is planning to reserve both virtual instances and physical hosts,
> but for the discussion we had, only physical hosts usecase is relevant.
>
> We had an unconference session today at 2pm, I can share you the slides :
>
>
> https://docs.google.com/presentation/d/1BJGmtzGees6tg_Np7JuKFtuLGiCaguVYD8hYJ2eVKAc/edit#slide=id.p
>
> (please focus on slides 11-14, they're talking on the design for host
> reservations)
>
> All the code is located on Stackforge, but please note the most important
> part of physical host reservations is still under review there :
>
> https://review.openstack.org/#/q/project:+stackforge/climate+status:open,n,z
>
> (We're missing reviewers, by the way !)
>
>
> I'm open to discuss and waiting your thoughts,
> -Sylvain
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Best regards,

Dina Belova

Software Engineer

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

Re: [openstack-dev] [Heat] How do i implement this usecase:

[Steve Baker]

On 11/07/2013 06:42 PM, Simon Pasquier wrote:
> Hi,
>
> The OS::Neutron::FloatingIP resource works in the same manner as the
> 'neutron floating-create' command so currently there is no way to
> avoid passing the floating network id. The AWS::EC2::EIP resource
> doesn't require it because it uses the Nova API to allocate floating
> IPs. In turn, Nova API knowns the floating network with the
> default_floating_pool parameter defined in your nova.conf file.
>
> I guess what you are looking for is a OS::Nova::FloatingIP resource.
> As a workaround, you could leverage environments [1] and map to the
> EC2 EIP resource:
>
> resource_registry:
>   "OS::Nova::FloatingIP": "AWS::EC2::EIP"
>
> Simon
>
> [1]
> http://docs.openstack.org/developer/heat/template_guide/environment.html
>

I had assumed that nova-networking was sufficiently deprecated that it
is not worth writing native heat resources for things like floating-ip.
I certainly won't be working on them but I currently have no problem
with some blueprints being raised and these resources being contributed.

> Le 07/11/2013 09:33, Nilakhya a écrit :
>> Currently my heat template works with AWS resource type:
>>
>>DatabaseIPAddress:
>>  Type: AWS::EC2::EIP
>>DatabaseIPAssoc :
>>  Type: AWS::EC2::EIPAssociation
>>  Properties:
>>InstanceId: {Ref: BaseInstance}
>>EIP: {Ref: MyIPAddress}
>>
>> Now if i want to change to OpenStack ( OS ) namespace with a similar
>> implementation :
>>
>>MyIPAddress:
>>  Type: OS::Neutron::FloatingIP
>> Properties:
>> floating_network_id : String
>>MyIPAssoc :
>>  Type: OS::Neutron::FloatingIPAssociation
>>  Properties:
>>floatingip_id : {Ref: MyIPAddress}
>>
>> I cannot problem is,
>>
>> a) floating_network_id ( is not known ) which is a required property.
>> b) Even if its available / defaults to, its an overhead from AWS
>> simplicity.
>>
As an aside, you only need to use OS::Neutron::FloatingIPAssociation if
the floating IP reference is passed in as a template parameter. If it is
all in a self-contained template, just do the association with
OS::Neutron::FloatingIP.



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

Re: [openstack-dev] [Swift] log line length

[Peter Portante]

Hi Alex,

It seems that this is likely an rsyslog limit, so you might want to
check out: http://www.rsyslog.com/doc/rsyslog_conf_global.html
Specifically, the info on "$MaxMessageSize"

Regards, -peter

On Thu, Nov 7, 2013 at 5:42 PM, Pecoraro, Alex  wrote:
> Is there any way for me to change the logging so that it doesn’t truncate
> the output – so basically the length of the line printed to the log is not
> limited to a certain length?
>
>
>
> Thanks.
>
>
>
> Alex
>
>
> ___
> 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] [sqlalchemy-migrate] Blueprint for review: Add DB2 10.5 Support

[Joe Gordon]

With OpenStacks test and gating oriented mindset, how can we gate on this
functionality working going forward?


On Fri, Nov 1, 2013 at 3:30 AM, Matt Riedemann  wrote:

> I've got a sqlalchemy-migrate blueprint up for review to add DB2 support
> in migrate.
>
> *https://blueprints.launchpad.net/sqlalchemy-migrate/+spec/add-db2-support*
>
> This is a pre-req for getting DB2 support into Nova so I'm targeting
> icehouse-1.  We've been running with the migrate patches internally since
> Folsom, but getting them into migrate was difficult before OpenStack took
> over maintenance of the project.
>
> Please let me know if there are any questions/issues or something I need
> to address here.
>
> Thanks,
>
> Matt Riedemann
> Cloud Solutions and OpenStack Development
> Email: mrie...@us.ibm.com
> Office Phone: 507-253-7622
> ___
> 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] [climate][neutron] The good way of integration

[Nikolay Starodubtsev]

Hi, everyone!
In Climate we have plans to integrate with Neutron and make possible
networks, subnets, etc. reservations. What's the best way to start the
dialogue about this? Shall I create bp at first or the discussion in
dev-list ara also a good thing? However, today is the last day of summit,
so may be I can catch someone from Neutron team and discuss the
possibilities of integration?
p.s. We have an unconference session on the summit and you can find slides
here
http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg07933.html


Nikolay Starodubtsev

Software Engineer

Mirantis Inc.

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

[openstack-dev] Dev help....

[Krishanu Dhar]

Hi,

I have few very basic questions. It would be really nice if someone can
assist.

1. I have a program that gathers details from a db in a server and is meant
to update the backend db (by backend db, I mean trove). Whats the easiest
way to do this?

2. How to host a webserver on openstack?

3. How do I run code from the webserver?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] How do i implement this usecase:

[Nilakhya]

Ok,

Thank you steve, Simon, Denis

I created the following blueprint :

https://blueprints.launchpad.net/heat/+spec/aws-compatible-resource-for-floating-ip-support


Consultant Engineering
Team: HPCS-Vertica
Location: Noida, India

On 11/08/2013 09:03 AM, Steve Baker wrote:

On 11/07/2013 06:42 PM, Simon Pasquier wrote:

Hi,

The OS::Neutron::FloatingIP resource works in the same manner as the
'neutron floating-create' command so currently there is no way to
avoid passing the floating network id. The AWS::EC2::EIP resource
doesn't require it because it uses the Nova API to allocate floating
IPs. In turn, Nova API knowns the floating network with the
default_floating_pool parameter defined in your nova.conf file.

I guess what you are looking for is a OS::Nova::FloatingIP resource.
As a workaround, you could leverage environments [1] and map to the
EC2 EIP resource:

resource_registry:
   "OS::Nova::FloatingIP": "AWS::EC2::EIP"

Simon

[1]
http://docs.openstack.org/developer/heat/template_guide/environment.html


I had assumed that nova-networking was sufficiently deprecated that it
is not worth writing native heat resources for things like floating-ip.
I certainly won't be working on them but I currently have no problem
with some blueprints being raised and these resources being contributed.


Le 07/11/2013 09:33, Nilakhya a écrit :

Currently my heat template works with AWS resource type:

DatabaseIPAddress:
  Type: AWS::EC2::EIP
DatabaseIPAssoc :
  Type: AWS::EC2::EIPAssociation
  Properties:
InstanceId: {Ref: BaseInstance}
EIP: {Ref: MyIPAddress}

Now if i want to change to OpenStack ( OS ) namespace with a similar
implementation :

MyIPAddress:
  Type: OS::Neutron::FloatingIP
Properties:
floating_network_id : String
MyIPAssoc :
  Type: OS::Neutron::FloatingIPAssociation
  Properties:
floatingip_id : {Ref: MyIPAddress}

I cannot problem is,

a) floating_network_id ( is not known ) which is a required property.
b) Even if its available / defaults to, its an overhead from AWS
simplicity.


As an aside, you only need to use OS::Neutron::FloatingIPAssociation if
the floating IP reference is passed in as a template parameter. If it is
all in a self-contained template, just do the association with
OS::Neutron::FloatingIP.



___
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] How to choose proper availablity-zone in Havana version with the same usage realized by JsonFilter in Folsom version?

[Tiantian Gao]

i have the same question. if there is no existed work around, i think we
can pin AZ information with host state in sheduler. then jsonfilter can
work as before.
在 2013-11-7 下午5:15，"hzguanqi...@corp.netease.com" <
hzguanqi...@corp.netease.com>写道：

>   Hi guys,
>
> In Folsom version, availability-zone info is stored in compute_nodes db
> table, and so can be parsed by JsonFilter.
> I can use JsonFilter to choose which(or except which)
> availability-zones to build my instance.
>
> But in Havana version, availability-zone info is stored in
> aggregatemetadata, and so JsonFilter seems can not filter
> the proper availatiliby-zones as the way in Folsom version.
>
> So Is there any other existed resolution in H version that can satisfy my
> demand?
>
> Thanks~
> --
> Best regards!
> GuanQiang
>
> 2013-11-07
>
> ___
> 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] Dev help....

[Noorul Islam K M]

Krishanu Dhar  writes:

> Hi,
>
> I have few very basic questions. It would be really nice if someone can
> assist.
>
> 1. I have a program that gathers details from a db in a server and is meant
> to update the backend db (by backend db, I mean trove). Whats the easiest
> way to do this?
>
> 2. How to host a webserver on openstack?
>
> 3. How do I run code from the webserver?

Are you looking for https://wiki.openstack.org/wiki/Heat

Regards,
Noorul

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

Re: [openstack-dev] [Solum] Choice of API infrastructure

[Doug Hellmann]

On Fri, Nov 8, 2013 at 8:02 AM, Jay Pipes  wrote:

> On 11/07/2013 06:41 PM, Adrian Otto wrote:
>
>> Solum Team,
>>
>> First of all I wanted to say that I have been thinking a lot about this
>> thread, and have been seeking input from a number of you who attended the
>> Summit this week. I do *not* see this decision as a critical one, because
>> if something really mattered a ton we could rip our one framework and put
>> another in.
>>
>> What I love about this discussion is that we are having a healthy debate
>> about different points of view, which was very thought provoking. I have
>> heard input from skeptics who think that engineering decisions have to be
>> made in a small group in order to be efficient. I know that thinking is
>> wrong, and it's examples like these that convince me further that
>> discussions like these help us make better choices, and make development
>> more efficient over the long run.
>>
>> We should give the most weight to the preferences of the engineers who
>> will write and maintain the code. If there are team members who are
>> volunteering to write and maintain the bulk of our API code over a period
>> of time who really want Falcon over Pecan, then we should give that fair
>> consideration. The API is exceedingly important to Solum, and all of us
>> will be working on it, so we need a choice that all of us can live with.
>>
>> I suggest that we settle on Pecan+WSME, for the following reasons:
>>
>> 1) It is a known quantity, and is likely to work well for Solum's needs,
>> considering that Solum is primarily a control plane API system, and that
>> performance is not a primary motivator.
>>
>> 2) Pecan+WSME allows us to offer data serializations in both JSON and XML
>> to help satisfy the preferences of the API consumers.
>>
>> 3) It allows us to have multiple models that are loosely coupled, which
>> can aid in data validation.
>>
>> 4) At this point in time, other OpenStack core/integrated/ecosystem
>> projects are using Pecan+WSME, and several Solum contributors will be
>> switching between projects. There is an advantage to a higher level of
>> consistency among various projects.
>>
>> I accept that Webob may be problematic for us, that performance may be
>> less than ideal, and that some Solum developers may dislike working with
>> WSME, and that Falcon may actually be more pleasant to work with. We have
>> team members with a deep understanding of Falcon, and could definitely make
>> it work. We can proceed with Pecan+WSME accepting these (and  other)
>> trade-offs.
>>
>> Are there any other critically important considerations that we should
>> consider before converging on this choice? I'd like to hear that input
>> prior to our next IRC meeting.
>>
>
> None that I can think of. I'll get behind the decision, then, and if all
> are in consensus, I'll abandon the Falcon API patch.
>
> We do need to get the Pecan/WSME patch to pass the gates though :) Doug,
> I'm hoping you might give Noorul a hand with that next week upon your
> return from Hong Kong?
>

I'd be happy to help. Please add me as a reviewer on the patch set if I'm
not already listed.

Doug


>
> All the best,
>
> -jay
>
>
> ___
> 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 sub-team?

[Brian Haley]

On 11/08/2013 11:21 AM, Collins, Sean (Contractor) wrote:

How about scheduling an IRC meeting in close proximity to the other
Neutron meetings on Mondays?

* 20:00 to 21:00 UTC, before the Neutron meeting


+0


OR

* 23:00 UTC - after the distributed virtual router meeting?


-1

I'd prefer a different day altogether since three meetings in a row 
would be tough, but that's just my opinion...


-Brian


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

Re: [openstack-dev] L3 advanced features blueprint mapping to IETF and IEEE standards

[Pedro Roque Marques]

What about an IRC meeting on this topic 11/19 at 9 p.m. PST ? This is 2 p.m in 
Japan and 6 a.m CET on the 20th.
It is not ideal but i suspect we will have interest in participating from both 
Europe and Asia.
I volunteer myself and Nachi Ueno na...@ntti3.com (the author of the BGP MPLS 
blueprint) as agenda organizers; please drop us a note if you intend to attend 
and wether you would like to present something to the group.

  Pedro.

On Nov 7, 2013, at 11:27 AM, Rochelle.Grober  wrote:

>  
>  
> From: Pedro Roque Marques [mailto:pedro.r.marq...@gmail.com]
> Colin,
> "The nice thing about standards is that there are so many of them to choose 
> from."
>  
> For instance, if you take this Internet Draft:
> http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-02 which is based on 
> RFC4364.
>  
> It has already been implemented as a Neutron plugin via OpenContrail 
> (http://juniper.github.io/contrail-vnc/README.html); With this implementation 
> each OpenStack cluster can be configured as its own Autonomous System.
>  
> There is a blueprint
> https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-mpls-vpn
> that is discussing adding the provisioning of the autonomous system and 
> peering to Neutron.
>  
> Please note that the work above does interoperate with 4364 using option B. 
> Option C is possible but not that practical (as an operator you probably 
> don't want to expose your internal topology between clusters).
>  
> If you want to give it a try you can use this devstack fork: 
> https://github.com/dsetia/devstack.
> You can use it to interoperate with a standard router that implements 4364 
> and support MPLS over GRE. Products from cisco/juniper/ALU/huwawei etc do.
>  
> I believe that the work i'm referencing implements interoperability while 
> having very minimal changes to Neutron. It is based on the same concept of 
> neutron virtual network and it hides the BGP/MPLS functionality from the user 
> by translating policies that establish connectivity between virtual networks 
> into RFC 4364 concepts.
> Please refer to: 
> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron
>  
> Would it make sense to have an IRC/Web meeting around interoperability with 
> RFC4364 an OpenStack managed clusters ? I believe that there is a lot of work 
> that has already been done there by multiple vendors as well as some carriers.
>  
> +1  And it should be scheduled and announced a reasonable time in advance 
> developers can plan to participate.
>  
> --Rocky
>  
>   Pedro.
>  
> On Nov 7, 2013, at 12:35 AM, Colin McNamara  wrote:
> I have a couple concerns that I don’t feel I clearly communicated during the 
> L3 advanced features session. I’d like to take this opportunity to both 
> clearly communicate my thoughts, as well as start a discussion around them.
>  
> Building to the edge of the "autonomous system"
> The current state of neutron implementation is functionally the l2 domain and 
> simple l3 services that are part of a larger autonomous system. The routers 
> and switches northbound of the OpenStack networking layer handled the 
> abstraction and integration of the components.
> Note, I use the term “Autonomous System” to describe more then the notion of 
> BGP AS, but more broadly in the term of a system that is controlled within a 
> common framework and methodology, and integrates with a peer system that 
> doesn’t not share that same scope or method of control
> These components that composed the autonomous system boundary implement 
> protocols and standards that map into IETF and IEEE standards. The reasoning 
> for this is interoperability. Before vendors utilize IETF for 
> interoperability at this layer, the provider experience was horrible (this 
> was my personal experience in the late 90’s).
>  
> Wednesdays discussions in the Neutron Design Sessions
> A couple of the discussions, most notably the extension of l3 functionality 
> fell within the scope of starting the process of extending Neutron with 
> functionality that will result (eventually) in the ability for an OpenStack 
> installation to operate as it’s own Autonomous System.
> The discussions that occurred to support L3 advanced functionality 
> (northbound boundary), and the QOS extension functionality both fell into the 
> scope of Northbound and Southbound boundaries of this system.
> My comments in the session
> My comments in the session, while clouded with jet-lag were specifically 
> around two concepts that are used when integrating other types of systems 
> 1. In a simple (1-8) tenant environment integration with a northbound AS is 
> normally done in a PE-CE model that generally centers around mapping dot1q 
> tags into the appropriate northbound l3 segments and then handling the 
> availability of the L2 path that traverses with port channeling, MLAG, STP, 
> Etc.
> 2. In a complex environment (8+ for discussion) different Carrier Supporting 
> Carrier (CSC) methods defined in I

Re: [openstack-dev] L3 advanced features blueprint mapping to IETF and IEEE standards

[Nachi Ueno]

Hi folks

let's use #openstack-meeting on the meetings.

I have also created an etherpad for this discussion
(If you have any slide, please link to the page)

https://etherpad.openstack.org/p/NeutronDynamicRoutingIceHouse

Best
Nachi



2013/11/8 Pedro Roque Marques :
> What about an IRC meeting on this topic 11/19 at 9 p.m. PST ? This is 2 p.m
> in Japan and 6 a.m CET on the 20th.
> It is not ideal but i suspect we will have interest in participating from
> both Europe and Asia.
> I volunteer myself and Nachi Ueno na...@ntti3.com (the author of the BGP
> MPLS blueprint) as agenda organizers; please drop us a note if you intend to
> attend and wether you would like to present something to the group.
>
>   Pedro.
>
> On Nov 7, 2013, at 11:27 AM, Rochelle.Grober 
> wrote:
>
>
>
> From: Pedro Roque Marques [mailto:pedro.r.marq...@gmail.com]
> Colin,
> "The nice thing about standards is that there are so many of them to choose
> from."
>
> For instance, if you take this Internet Draft:
> http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-02 which is based on
> RFC4364.
>
> It has already been implemented as a Neutron plugin via OpenContrail
> (http://juniper.github.io/contrail-vnc/README.html); With this
> implementation each OpenStack cluster can be configured as its own
> Autonomous System.
>
> There is a blueprint
> https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-mpls-vpn
> that is discussing adding the provisioning of the autonomous system and
> peering to Neutron.
>
> Please note that the work above does interoperate with 4364 using option B.
> Option C is possible but not that practical (as an operator you probably
> don't want to expose your internal topology between clusters).
>
> If you want to give it a try you can use this devstack fork:
> https://github.com/dsetia/devstack.
> You can use it to interoperate with a standard router that implements 4364
> and support MPLS over GRE. Products from cisco/juniper/ALU/huwawei etc do.
>
> I believe that the work i'm referencing implements interoperability while
> having very minimal changes to Neutron. It is based on the same concept of
> neutron virtual network and it hides the BGP/MPLS functionality from the
> user by translating policies that establish connectivity between virtual
> networks into RFC 4364 concepts.
> Please refer to:
> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron
>
> Would it make sense to have an IRC/Web meeting around interoperability with
> RFC4364 an OpenStack managed clusters ? I believe that there is a lot of
> work that has already been done there by multiple vendors as well as some
> carriers.
>
> +1  And it should be scheduled and announced a reasonable time in advance
> developers can plan to participate.
>
> --Rocky
>
>   Pedro.
>
> On Nov 7, 2013, at 12:35 AM, Colin McNamara  wrote:
>
> I have a couple concerns that I don’t feel I clearly communicated during the
> L3 advanced features session. I’d like to take this opportunity to both
> clearly communicate my thoughts, as well as start a discussion around them.
>
>
> Building to the edge of the "autonomous system"
>
> The current state of neutron implementation is functionally the l2 domain
> and simple l3 services that are part of a larger autonomous system. The
> routers and switches northbound of the OpenStack networking layer handled
> the abstraction and integration of the components.
>
> Note, I use the term “Autonomous System” to describe more then the notion of
> BGP AS, but more broadly in the term of a system that is controlled within a
> common framework and methodology, and integrates with a peer system that
> doesn’t not share that same scope or method of control
>
> These components that composed the autonomous system boundary implement
> protocols and standards that map into IETF and IEEE standards. The reasoning
> for this is interoperability. Before vendors utilize IETF for
> interoperability at this layer, the provider experience was horrible (this
> was my personal experience in the late 90’s).
>
>
>
> Wednesdays discussions in the Neutron Design Sessions
>
> A couple of the discussions, most notably the extension of l3 functionality
> fell within the scope of starting the process of extending Neutron with
> functionality that will result (eventually) in the ability for an OpenStack
> installation to operate as it’s own Autonomous System.
>
> The discussions that occurred to support L3 advanced functionality
> (northbound boundary), and the QOS extension functionality both fell into
> the scope of Northbound and Southbound boundaries of this system.
>
> My comments in the session
>
> My comments in the session, while clouded with jet-lag were specifically
> around two concepts that are used when integrating other types of systems
>
> 1. In a simple (1-8) tenant environment integration with a northbound AS is
> normally done in a PE-CE model that generally centers around mapping dot1q
> tags into the appropriate 

[openstack-dev] [stable-havana][cinder] [scheduler] Found a potential bug while setting up multiple cinder-volume instances on single cinder node

[gans developer]

Hi All,

I was trying to setup multiple cinder-volume instances on a single node
setup.I edited the cinder.conf file as per the instructions given in the
openstack docs for multi-backend cinder.

http://docs.openstack.org/admin-guide-cloud/content//multi_backend.html

I setup two backends and was able to see both the backend hosts in cinder
service-list.

PART 1 :
I tried to create a volume using the volume-type(configures for the
backends), but it failed saying "No valid host was found". I tried to debug
the code and got the point where the process was stalling.

*cinder/openstack/common/scheduler/filter.py : get_filtered_objects :*

*for filter_cls in filter_classes:*
*objs = filter_cls().filter_all(objs, filter_properties)*
*return list(objs)*

In these lines of code, the objs will contain the list of hosts as per the
filter classes.
In my case , the code was able to find the list of host for one of the
classes in the first iteration only and in second and third iteration the
list was empty.As the return is after the loop is over , it was always
sending the empty list and hence the error : "No valid host found"

I changed the code to this and it was then returning the list of hosts.
Changed code :
*for filter_cls in filter_classes:*
*objs = filter_cls().filter_all(objs, filter_properties)*
*if objs:*
*return list(objs)*
*return list(objs)*

PART 2 :
After making the above changes , i tried to create the volume using one of
the volume-type and got success. Then i tried to use the other volume-type
to create the volume , but it used the other host and not the host
associated with this volume-type.

I went through the logs and found that it was discovering both the hosts in
the file
*cinder/cinder/scheduler : filter_scheduler.py : _get_weighted_candidates :
line 222*

after getting the hosts list it was choosing the first host in the list in
file
*cinder/cinder/scheduler : filter_scheduler.py : _schedule : line 239*

My doubts:
==> was the host list filtered as per the volume-type provided during the
create volume process?
==> Why we are using the first host from the "weighed_hosts" list?

Please help me out here.

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

Re: [openstack-dev] L3 advanced features blueprint mapping to IETF and IEEE standards

[Colin McNamara]

I absolutely agree that there are many standards to choose from. The point I am 
trying to make is that there are common integration methods that map into 
certain standards. If we diverge from these, it is likely that integration into 
brownfield networks will become an issue.

Regards,

Colin

Colin McNamara
People | Process | Technology

Mobile: 858-208-8105
Twitter:@colinmcnamara
Linkedin:   www.linkedin.com/colinmcnamara
Blog:   www.colinmcnamara.com
Email:  co...@2cups.com 






On Nov 8, 2013, at 2:18 PM, Nachi Ueno  wrote:

> Hi folks
> 
> let's use #openstack-meeting on the meetings.
> 
> I have also created an etherpad for this discussion
> (If you have any slide, please link to the page)
> 
> https://etherpad.openstack.org/p/NeutronDynamicRoutingIceHouse
> 
> Best
> Nachi
> 
> 
> 
> 2013/11/8 Pedro Roque Marques :
>> What about an IRC meeting on this topic 11/19 at 9 p.m. PST ? This is 2 p.m
>> in Japan and 6 a.m CET on the 20th.
>> It is not ideal but i suspect we will have interest in participating from
>> both Europe and Asia.
>> I volunteer myself and Nachi Ueno na...@ntti3.com (the author of the BGP
>> MPLS blueprint) as agenda organizers; please drop us a note if you intend to
>> attend and wether you would like to present something to the group.
>> 
>>  Pedro.
>> 
>> On Nov 7, 2013, at 11:27 AM, Rochelle.Grober 
>> wrote:
>> 
>> 
>> 
>> From: Pedro Roque Marques [mailto:pedro.r.marq...@gmail.com]
>> Colin,
>> "The nice thing about standards is that there are so many of them to choose
>> from."
>> 
>> For instance, if you take this Internet Draft:
>> http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-02 which is based on
>> RFC4364.
>> 
>> It has already been implemented as a Neutron plugin via OpenContrail
>> (http://juniper.github.io/contrail-vnc/README.html); With this
>> implementation each OpenStack cluster can be configured as its own
>> Autonomous System.
>> 
>> There is a blueprint
>> https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-mpls-vpn
>> that is discussing adding the provisioning of the autonomous system and
>> peering to Neutron.
>> 
>> Please note that the work above does interoperate with 4364 using option B.
>> Option C is possible but not that practical (as an operator you probably
>> don't want to expose your internal topology between clusters).
>> 
>> If you want to give it a try you can use this devstack fork:
>> https://github.com/dsetia/devstack.
>> You can use it to interoperate with a standard router that implements 4364
>> and support MPLS over GRE. Products from cisco/juniper/ALU/huwawei etc do.
>> 
>> I believe that the work i'm referencing implements interoperability while
>> having very minimal changes to Neutron. It is based on the same concept of
>> neutron virtual network and it hides the BGP/MPLS functionality from the
>> user by translating policies that establish connectivity between virtual
>> networks into RFC 4364 concepts.
>> Please refer to:
>> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron
>> 
>> Would it make sense to have an IRC/Web meeting around interoperability with
>> RFC4364 an OpenStack managed clusters ? I believe that there is a lot of
>> work that has already been done there by multiple vendors as well as some
>> carriers.
>> 
>> +1  And it should be scheduled and announced a reasonable time in advance
>> developers can plan to participate.
>> 
>> --Rocky
>> 
>>  Pedro.
>> 
>> On Nov 7, 2013, at 12:35 AM, Colin McNamara  wrote:
>> 
>> I have a couple concerns that I don’t feel I clearly communicated during the
>> L3 advanced features session. I’d like to take this opportunity to both
>> clearly communicate my thoughts, as well as start a discussion around them.
>> 
>> 
>> Building to the edge of the "autonomous system"
>> 
>> The current state of neutron implementation is functionally the l2 domain
>> and simple l3 services that are part of a larger autonomous system. The
>> routers and switches northbound of the OpenStack networking layer handled
>> the abstraction and integration of the components.
>> 
>> Note, I use the term “Autonomous System” to describe more then the notion of
>> BGP AS, but more broadly in the term of a system that is controlled within a
>> common framework and methodology, and integrates with a peer system that
>> doesn’t not share that same scope or method of control
>> 
>> These components that composed the autonomous system boundary implement
>> protocols and standards that map into IETF and IEEE standards. The reasoning
>> for this is interoperability. Before vendors utilize IETF for
>> interoperability at this layer, the provider experience was horrible (this
>> was my personal experience in the late 90’s).
>> 
>> 
>> 
>> Wednesdays discussions in the Neutron Design Sessions
>> 
>> A couple of the discussions, most notably the extension of l3 functionality
>> fell within the scope of starting the pr

Re: [openstack-dev] RFC: reverse the default Gerrit sort order

[Joe Gordon]

On Thu, Nov 7, 2013 at 7:36 AM, Robert Collins wrote:

> I've been thinking about review queues recently (since here at the
> summit everyone is talking about reviews! :)).
>
> One thing that struck me today was that Gerrit makes it easier to
> review the newest changes first, rather than the changes that have
> been in the queue longest, or the changes that started going through
> the review process first.
>
> So... is it possible to change the default sort order for Gerrit? How
> hard is it to do - could we do an experiment on that and see if it
> nudges the dial for reviewstats (just make the change, not ask anyone
> to change their behaviour)?
>
> As for what sort order to choose, I'd be happy just getting data on a
> different default sort order - it seems like the easiest thing would
> be to reverse the current order, vs doing something more
> sophisticated.
>
>
++, This sounds like an interesting idea. and we could try it out for a few
weeks to see what happen.


> If folk are about to jump up and say 'hey, reviewday' or 'hey
> next-review' : I specifically want to see what the effect on changing
> the Gerrit web UI is, because my sense is that that is the default
> place folk do reviews, and I want to change the default-experience
> folk have, not the optional experience folk can opt into.
>
> -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 mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] L3 advanced features blueprint mapping to IETF and IEEE standards

[Colin McNamara]

That time works for me (I fly back to America the night before)
Regards,

Colin

Colin McNamara
People | Process | Technology

Mobile: 858-208-8105
Twitter:@colinmcnamara
Linkedin:   www.linkedin.com/colinmcnamara
Blog:   www.colinmcnamara.com
Email:  co...@2cups.com 






On Nov 8, 2013, at 2:01 PM, Pedro Roque Marques  
wrote:

> What about an IRC meeting on this topic 11/19 at 9 p.m. PST ? This is 2 p.m 
> in Japan and 6 a.m CET on the 20th.
> It is not ideal but i suspect we will have interest in participating from 
> both Europe and Asia.
> I volunteer myself and Nachi Ueno na...@ntti3.com (the author of the BGP MPLS 
> blueprint) as agenda organizers; please drop us a note if you intend to 
> attend and wether you would like to present something to the group.
> 
>   Pedro.
> 
> On Nov 7, 2013, at 11:27 AM, Rochelle.Grober  
> wrote:
> 
>>  
>>  
>> From: Pedro Roque Marques [mailto:pedro.r.marq...@gmail.com]
>> Colin,
>> "The nice thing about standards is that there are so many of them to choose 
>> from."
>>  
>> For instance, if you take this Internet Draft:
>> http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-02 which is based on 
>> RFC4364.
>>  
>> It has already been implemented as a Neutron plugin via OpenContrail 
>> (http://juniper.github.io/contrail-vnc/README.html); With this 
>> implementation each OpenStack cluster can be configured as its own 
>> Autonomous System.
>>  
>> There is a blueprint
>> https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-mpls-vpn
>> that is discussing adding the provisioning of the autonomous system and 
>> peering to Neutron.
>>  
>> Please note that the work above does interoperate with 4364 using option B. 
>> Option C is possible but not that practical (as an operator you probably 
>> don't want to expose your internal topology between clusters).
>>  
>> If you want to give it a try you can use this devstack fork: 
>> https://github.com/dsetia/devstack.
>> You can use it to interoperate with a standard router that implements 4364 
>> and support MPLS over GRE. Products from cisco/juniper/ALU/huwawei etc do.
>>  
>> I believe that the work i'm referencing implements interoperability while 
>> having very minimal changes to Neutron. It is based on the same concept of 
>> neutron virtual network and it hides the BGP/MPLS functionality from the 
>> user by translating policies that establish connectivity between virtual 
>> networks into RFC 4364 concepts.
>> Please refer to: 
>> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron
>>  
>> Would it make sense to have an IRC/Web meeting around interoperability with 
>> RFC4364 an OpenStack managed clusters ? I believe that there is a lot of 
>> work that has already been done there by multiple vendors as well as some 
>> carriers.
>>  
>> +1  And it should be scheduled and announced a reasonable time in advance 
>> developers can plan to participate.
>>  
>> --Rocky
>>  
>>   Pedro.
>>  
>> On Nov 7, 2013, at 12:35 AM, Colin McNamara  wrote:
>> I have a couple concerns that I don’t feel I clearly communicated during the 
>> L3 advanced features session. I’d like to take this opportunity to both 
>> clearly communicate my thoughts, as well as start a discussion around them.
>>  
>> Building to the edge of the "autonomous system"
>> The current state of neutron implementation is functionally the l2 domain 
>> and simple l3 services that are part of a larger autonomous system. The 
>> routers and switches northbound of the OpenStack networking layer handled 
>> the abstraction and integration of the components.
>> Note, I use the term “Autonomous System” to describe more then the notion of 
>> BGP AS, but more broadly in the term of a system that is controlled within a 
>> common framework and methodology, and integrates with a peer system that 
>> doesn’t not share that same scope or method of control
>> These components that composed the autonomous system boundary implement 
>> protocols and standards that map into IETF and IEEE standards. The reasoning 
>> for this is interoperability. Before vendors utilize IETF for 
>> interoperability at this layer, the provider experience was horrible (this 
>> was my personal experience in the late 90’s).
>>  
>> Wednesdays discussions in the Neutron Design Sessions
>> A couple of the discussions, most notably the extension of l3 functionality 
>> fell within the scope of starting the process of extending Neutron with 
>> functionality that will result (eventually) in the ability for an OpenStack 
>> installation to operate as it’s own Autonomous System.
>> The discussions that occurred to support L3 advanced functionality 
>> (northbound boundary), and the QOS extension functionality both fell into 
>> the scope of Northbound and Southbound boundaries of this system.
>> My comments in the session
>> My comments in the session, while clouded with jet-lag were specifically 

Re: [openstack-dev] Dev help....

[Krishanu Dhar]

Thanks. I tried hooking onto the IRC but it just doesn't seem to connect.
Below is the error I got.

[11:59] -herbert.freenode.net- *** Looking up your hostname...
[11:59] -herbert.freenode.net- *** Checking Ident
[11:59] -herbert.freenode.net- *** No Ident response
[11:59] -herbert.freenode.net- *** Couldn't look up your hostname
[11:59] == CGI:IRC host/IP set to gateway/web/freenode/session 202.3.120.4
[11:59] == krish Nick/channel is temporarily unavailable



On Fri, Nov 8, 2013 at 10:07 AM, Noorul Islam K M  wrote:

> Krishanu Dhar  writes:
>
> > Hi,
> >
> > I have few very basic questions. It would be really nice if someone can
> > assist.
> >
> > 1. I have a program that gathers details from a db in a server and is
> meant
> > to update the backend db (by backend db, I mean trove). Whats the easiest
> > way to do this?
> >
> > 2. How to host a webserver on openstack?
> >
> > 3. How do I run code from the webserver?
>
> Are you looking for https://wiki.openstack.org/wiki/Heat
>
> Regards,
> Noorul
>



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

[openstack-dev] [TripleO] Contributing hardware to the TripleO CD cloud

[Robert Collins]

Hi,
over this week a number of organisations have expressed interest
in contributing to the TripleO CD cloud, to help OpenStack bare metal
testing, and testing of things that cannot run in nested environments
- some hypervisors, savannah etc.

I've drawn up a draft of whats involved in such a contribution -
https://wiki.openstack.org/wiki/TripleO/TripleOCloud/Regions#Contributing_a_region_to_the_TripleOCloud
- it's subject to review based on your feedback etc, but I'm pretty
excited by this.

Please contact me (off-list (rbtcoll...@hp.com) or on-list - up to
you) if you're interested in contributing a region.

We're not sure how large the cloud needs to be to test everything that
we need to test, but we are sure that it's not big enough yet -
testing just the gate for bare metal deployed KVM clouds would have
required 80 machines during the H release period : 20 patches landing
per hour, but re-tests when things failed in the gate means more like
40 runs per hour, 2 machines per run, an hour budget for bare metal
deployed runs.

Cheers,
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] [Openstack-security] Neutron security groups for L2 networks in Havana

[Aaron Rosen]

On Thu, Nov 7, 2013 at 12:23 PM, Kanthi P  wrote:

> Hi,
>
> I am trying to boot a VM which has a network without subnet in Havana, but
> it throws an exception saying that subnet is mandatory if quantum security
> groups are enabled.
>
> Here are the commands I used.
>
> neutron net-create testNet
> neutron net-show testNet
> +---+--+
> | Field | Value|
> +---+--+
> | admin_state_up| True |
> | id| 47208beb-2801-4729-bc7b-6532717232fc |
> | name  | testNet  |
> | provider:network_type | local|
> | provider:physical_network |  |
> | provider:segmentation_id  |  |
> | router:external   | False|
> | shared| False|
> | status| ACTIVE   |
> | subnets   |  |
> | tenant_id | b5b591dcda2645cd9d15a4fe3eb1b50d |
> +---+--+
>
> nova boot --flavor 2 --image 30c1984c-8a4f-4e3f-8c9a-7de0b321caa2 --nic
> net-id=47208beb-2801-4729-bc7b-6532717232fc testServer1
>
> Here is the piece of code which generated this exception
>
> nova/network/neutronv2/api.py
>
> if (security_groups and not (
> network['subnets']
> and network.get('port_security_enabled', True))):
>
> raise exception.SecurityGroupCannotBeApplied()
>
>
> Can someone please explain why do we need this check?
>

Hi Kanthi,

We need this check because because in order to enforce security groups the
port needs to have an ip_address (i.e: network needs a subnet) since
Security groups only map to L3/4 headers. Today, nova automatically adds a
default security group to all instances when booted. Hopefully we can punt
this task off to neutron in this release by moving the port-creation up on
the stack to nova-api instead of nova-compute though this isn't the case
right now.

Aaron

>
> To my understanding subnet is used for two purposes in terms of security
> groups
> 1. To allow dhcp traffic if dhcp is enabled on the subnet, example given
> below
> -A quantum-openvswi-i7bf776d2-b -s 192.168.1.3/32 -p udp -m udp
> --sport 67 --dport 68 -j RETURN
> 2. To avoid ip spoof
> -A quantum-openvswi-o7bf776d2-b ! -s 192.168.1.2/32 -j DROP
>
> Can we remove this so that we can have guests which has nic with just MAC
> address, guest can configure its own ipaddress. Later if needed they can
> enable their own security rules via quantum api.
>
> ___
> Openstack-security mailing list
> openstack-secur...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev