Re: [openstack-dev] how to deploy juno devstack without multiple backend

[Manickam, Kanagaraj]

HP MSA is supported by cinder and use the following guidelines:
http://docs.openstack.org/trunk/config-reference/content/hp-msa-driver.html

you could install devstack and follow the above wiki or update the above 
defined HP MSA param as suggested by devstack at 
http://devstack.org/configuration.html

[[post-config|$NOVA_CONF]]
HERE ADD THE HP MSA CONFIG DETAILS.


From: Nikesh Kumar Mahalka [mailto:nikeshmaha...@vedams.com]
Sent: Tuesday, September 16, 2014 11:50 AM
To: openst...@lists.openstack.org; openstack-dev@lists.openstack.org
Subject: [openstack-dev] how to deploy juno devstack without multiple backend

 Hi,
I want to delploy a juno devstack without multiple backends.
I want only one backend different from lvm,say HP MSA.
Can any one tell me what to modify in local.conf  of devstack for this?
By default,it is enabling multiple lvm backends.
Also,if i want multiple backends different from lvm backends ,what to modify in 
local.conf?
i have gone through Devstack documentation,but it is not straightforward like 
openstack documentation.








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

[openstack-dev] [neutron] support resilient network boot of ironic server

[Carlino, Chuck]

Hi,

Below is the beginning of a spec I'd like to get into Kilo.  Before
going into detail, it occurred to me that a basic decision needs to be
made, so I'd like to get thoughts on the api Alternatives mentioned below.

Thanks,
Chuck Carlino (ChuckC)

==
Enable Resilient Network Boot
==

https://blueprints.launchpad.net/neutron/+spec/resilient-network-boot

Today, if a user deploying workloads via Ironic wants to the server to
be able
to network boot in spite of a failure of an interface card, Neutron's DHCP
service cannot provide an alternate interface card connected to the same
network with the same IP address.

We propose to allow resilient boot in ironic configurations by enhancing
Neutron's api to provide an association between the NICs and the IP address
and by enhancing Neutron's DHCP service to vend the IP address to any of
the NICs.


Problem description
===

Ironic represents compute hardware as Nova instances.  Each instance's
interface (NIC) to a network is represented by a Neutron port.  A port has a
single mac address and an IP address that cannot be shared with other ports.
So neutron cannot configure its DHCP service to serve a single IP address to
more than 1 mac because it cannot associate multiple macs with an IP.


Alternatives


* A port for all instance NICs on the network

  - requires multiple mac addresses

* A port per instance NIC

  - requires relationship between ports (e.g. common subnet)


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

[openstack-dev] [nova] Support starting index when auto naming multiple instances

[Yingjun Li]

Currently when booting multiple instances, the instance display-names will be 
something like 'test-1,test-2' if we set
multi_instance_display_name_template = %(name)s-%(count)s. Here is the problem, 
if we need more instances 
and want the instance names start with 'test-3', there is no such way to do so 
now.

So a new template is introduced to solve the issue: '%(name)s-%(index)s’ If we 
enter instance name like `test-12`
when booting multiple instances, the display name of the remaining instances 
will be auto plus with 1 and begin with `12`.

And here is the patch related to this: 
https://review.openstack.org/#/c/38/, i’m proposing this
for discussion as Andrew suggested, any feedback would be appreciated, thanks!___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [gantt] Cancel the IRC meeting this week?

[Sylvain Bauza]

Le 15/09/2014 20:20, Dugger, Donald D a écrit :


I’d like to propose that we defer the meeting this week and reconvene 
next Tues, 9/23.  I don’t think there’s much new to talk about right 
now and we’re waiting for a write up on the claims process.  I’d like 
to get that write up when it’s ready, have everyone review it and then 
we can talk more concretely on what our next steps should be.


If anyone does have a topic they want to talk about let me know but, 
failing anything new, let’s wait a week.




Well, that's a fair question, thanks for raising it. I don't have a 
clear opinion on this but I can propose to open the meeting with open 
questions and see if people are there. FWIW, people could also have 
questions about the split and the next steps we decided.


-Sylvain

PS: I can chair this one Don, no worries.



--

Don Dugger

"Censeo Toto nos in Kansa esse decisse." - D. Gale

Ph: 303/443-3786



___
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] gettext question about oslo.i18n library

[Peng Wu]

Hi Ben,
  Thanks very much for the information!
  I moved the blueprint to:
  https://blueprints.launchpad.net/oslo.i18n/+spec/more-gettext-support
Best Regards,
  Peng Wu

On Tue, 2014-08-26 at 10:05 -0500, Ben Nemec wrote:
> Hi Peng,
> 
> We're using the spec process described in
> https://wiki.openstack.org/wiki/Oslo#Design_Proposals to manage
> blueprints now.  You'll need to create a spec review as described in the
> wiki for this.  Unfortunately, I don't think we've opened up Kilo specs
> yet, so you might want to either wait for just put it in Juno for now
> and rebase to Kilo when that's available.
> 
> -Ben
> 
> On 08/26/2014 02:27 AM, Peng Wu wrote:
> > Hi Doug,
> > 
> > I created a i18n blueprint for oslo.i18n.
> > URL:
> > https://blueprints.launchpad.net/openstack-i18n/+spec/more-gettext-supports
> > 
> > Could you review it?
> > 
> > I am reading django gettext code, I think I will use a similar approach
> > for the "contextual markers" gettext function.
> > 
> > Thanks,
> >   Peng Wu
> > 
> > On Mon, 2014-08-18 at 10:05 -0400, Doug Hellmann wrote:
> >> Yes, that would be a good next step.
> >>
> >> Doug
> >>
> >> On Aug 17, 2014, at 10:03 PM, Peng Wu  wrote:
> >>
> >>>  Yes, I am interested in adding these missing gettext functions to
> >>> oslo.i18n library.
> >>>
> >>>  Guess the next step is to create a blueprint for Kilo?
> >>>
> >>> Thanks,
> >>>  Peng Wu
> >>>
> >>>
> >>> On Fri, 2014-08-15 at 16:02 -0400, Doug Hellmann wrote:
>  On Aug 15, 2014, at 3:18 AM, Peng Wu  wrote:
> 
> > Hi,
> >
> > Recently I just read the code of oslo.i18n library,
> > The lazy translation idea is great!
> >
> > But I found a question about gettext "contextual markers"
> > and "plural form", such as pgettext and ungettext functions,
> > see [3].
> >
> > It seems the two gettext functions are missing in the oslo.i18n
> > library.
> > Is it correct? or will support it?
> >
> > Thanks,
> > Peng Wu
> 
>  You’re right, those are not present.
> 
>  We apparently haven’t used them anywhere, yet, because they weren’t 
>  exposed via the old gettextutils module in the incubator. We should add 
>  them. Are you interested in working on a blueprint for Kilo to do that?
> 
>  Doug
> 
> >
> > Refer URL:
> > 1. https://github.com/openstack/oslo.i18n
> > 2.
> > http://lists.openstack.org/pipermail/openstack-dev/2014-July/039217.html
> > 3. https://wiki.openstack.org/wiki/I18n/TranslatableStrings
> >
> >
> >
> > ___
> > 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 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 mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Heat dependency visualisation

[Steven Hardy]

On Tue, Sep 16, 2014 at 03:34:28PM +1200, Steve Baker wrote:
> On 16/09/14 03:24, Alexis Lee wrote:
> > For your amusement,
> >
> > https://github.com/lxsli/heat-viz
> >
> > This produces HTML which shows which StructuredDeployments (boxes)
> > depends_on each other (bold arrows). It also shows the
> > StructuredDeployments which StructuredConfigs (ovals) feed into (normal
> > arrows).
> >
> > Both CFN + HOT format files should be supported. Thanks to Steve Baker
> > for the code I nicked, ahem, reused from merge.py.
> >
> >
> >
> Nice. What would be even nicer is a change to python-heatclient so that
> heat resource-list has an option to output in dotfile format.

larsks and I were discussing the exact same thing a few days ago:

http://blog.oddbit.com/2014/09/02/visualizing-heat-stacks/

Steve

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

Re: [openstack-dev] [Zaqar] Zaqar graduation (round 2) [was: Comments on the concerns arose during the TC meeting]

[Flavio Percoco]

On 09/15/2014 09:33 PM, Clint Byrum wrote:
> Excerpts from Zane Bitter's message of 2014-09-15 12:05:09 -0700:
>> On 15/09/14 13:28, Clint Byrum wrote:
>>> Excerpts from Flavio Percoco's message of 2014-09-15 00:57:05 -0700:
 On 09/12/2014 07:13 PM, Clint Byrum wrote:
> Excerpts from Thierry Carrez's message of 2014-09-12 02:16:42 -0700:
>> Clint Byrum wrote:
>>> Excerpts from Flavio Percoco's message of 2014-09-11 04:14:30 -0700:
 Is Zaqar being optimized as a *queuing* service? I'd say no. Our goal 
 is
 to optimize Zaqar for delivering messages and supporting different
 messaging patterns.
>>>
>>> Awesome! Just please don't expect people to get excited about it for
>>> the lighter weight queueing workloads that you've claimed as use cases.
>>>
>>> I totally see Horizon using it to keep events for users. I see Heat
>>> using it for stack events as well. I would bet that Trove would benefit
>>> from being able to communicate messages to users.
>>>
>>> But I think in between Zaqar and the backends will likely be a lighter
>>> weight queue-only service that the users can just subscribe to when they
>>> don't want an inbox. And I think that lighter weight queue service is
>>> far more important for OpenStack than the full blown random access
>>> inbox.
>>>
>>> I think the reason such a thing has not appeared is because we were all
>>> sort of running into "but Zaqar is already incubated". Now that we've
>>> fleshed out the difference, I think those of us that need a lightweight
>>> multi-tenant queue service should add it to OpenStack.  Separately. I 
>>> hope
>>> that doesn't offend you and the rest of the excellent Zaqar developers. 
>>> It
>>> is just a different thing.
>>>
 Should we remove all the semantics that allow people to use Zaqar as a
 queue service? I don't think so either. Again, the semantics are there
 because Zaqar is using them to do its job. Whether other folks may/may
 not use Zaqar as a queue service is out of our control.

 This doesn't mean the project is broken.
>>>
>>> No, definitely not broken. It just isn't actually necessary for many of
>>> the stated use cases.
>>
>> Clint,
>>
>> If I read you correctly, you're basically saying the Zaqar is overkill
>> for a lot of people who only want a multi-tenant queue service. It's
>> doing A+B. Why does that prevent people who only need A from using it ?
>>
>> Is it that it's actually not doing A well, from a user perspective ?
>> Like the performance sucks, or it's missing a key primitive ?
>>
>> Is it that it's unnecessarily complex to deploy, from a deployer
>> perspective, and that something only doing A would be simpler, while
>> covering most of the use cases?
>>
>> Is it something else ?
>>
>> I want to make sure I understand your objection. In the "user
>> perspective" it might make sense to pursue both options as separate
>> projects. In the "deployer perspective" case, having a project doing A+B
>> and a project doing A doesn't solve anything. So this affects the
>> decision we have to take next Tuesday...
>
> I believe that Zaqar does two things, inbox semantics, and queue
> semantics. I believe the queueing is a side-effect of needing some kind
> of queue to enable users to store and subscribe to messages in the
> inbox.
>
> What I'd rather see is an API for queueing, and an API for inboxes
> which integrates well with the queueing API. For instance, if a user
> says "give me an inbox" I think Zaqar should return a queue handle for
> sending into the inbox the same way Nova gives you a Neutron port if
> you don't give it one. You might also ask for a queue to receive push
> messages from the inbox. Point being, the queues are not the inbox,
> and the inbox is not the queues.
>
> However, if I just want a queue, just give me a queue. Don't store my
> messages in a randomly addressable space, and don't saddle the deployer
> with the burden of such storage. Put the queue API in front of a scalable
> message queue and give me a nice simple HTTP API. Users would likely be
> thrilled. Heat, Nova, Ceilometer, probably Trove and Sahara, could all
> make use of just this. Only Horizon seems to need a place to keep the
> messages around while users inspect them.
>
> Whether that is two projects, or one, separation between the two API's,
> and thus two very different types of backends, is something I think
> will lead to more deployers wanting to deploy both, so that they can
> bill usage appropriately and so that their users can choose wisely.

 This is one of the use-cases we designed flavors for. One of the mail
 ideas behind flavors is giving

Re: [openstack-dev] [neutron] Ipset, merge refactor for J?

[Thierry Carrez]

Miguel Angel Ajo Pelayo wrote:
> During the ipset implementatio, we designed a refactor [1] to cleanup 
> the firewall driver a bit, and move all the ipset low-level knowledge 
> down into the  IpsetManager.
> 
> I'd like to see this merged for J, and, it's a bit of an urgent matter 
> to decide, because we keep adding small changes [2] [3] fruit of the
> early testing which break the refactor, and will add extra work which
> needs to be refactored too.
> 
> The advantage of merging now, vs in J, is having K & J share a more common 
> code base, which would help us during bug backports/etc in the future.
> 
> Shihanzhang and I, are happy to see this merge during K, as it doesn't 
> incur in functional changes, just code blocks are moved from the iptables
> firewall driver to IpsetManager, and the corresponding tests are moved too.
> [...]

IMHO code refactoring should be considered a superfluous change at this
point in the cycle. The risk/benefit ratio is too high, and focus should
be on bugfixing at this point.

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [neutron][security-groups] Neutron default security groups

[Fawad Khaliq]

Folks,

I have had discussions with some folks individually about this but I would
like bring this to a broader audience.

I have been playing with security groups and I see the notion of 'default'
security group seems to create some nuisance/issues.

There are list of things I have noticed so far:

   - Tenant for OpenStack services (normally named service/services) also
   ends up having default security group.
   - Port create operation ends up ensuring default security groups for all
   the tenants as this completely seems out of the context of the tenant the
   port operation takes place. (bug?)
   - Race conditions where if system is stressed and Neutron tries to
   ensure the first default security group and in parallel another call comes,
   Neutron ends up trying to create multiple default security groups as the
   checks for duplicate groups are invalidated as soon as the call make past a
   certain point in code.
   - API performance where orchestration chooses to spawn 1000 tenants and
   we see unnecessary overhead.
   - For plugins that use RESTful proxy backends require the backend
   systems to be up at the time neutron starts. [Minor, but affects some
   packaging solutions]


To summarize, is there a way to disable default security groups? Expected
answer is no; can we introduce a way to disable it? If that does not make
sense, should we go ahead and fix the issues around it?

I am sure some of you must have seen some of these issues and solved them
already. Please do share how do tackle these issues?

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

[openstack-dev] [devstack] [cinder] [driver] Not able to create volume on a 3rd party driver backend

[Amit Das]

Hi All,

While trying to create a volume using my cinder driver (on devstack), i get
below issue w.r.t num_attempts.

Am i missing any configuration here ?

^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher
^[[01;35m^[[00m  File
"/opt/stack/cinder/cinder/scheduler/filter_scheduler.py", line 271, in
_get_weighted_candidates
^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher
^[[01;35m^[[00mself._populate_retry(filter_properties,
resource_properties)
^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher
^[[01;35m^[[00m  File
"/opt/stack/cinder/cinder/scheduler/filter_scheduler.py", line 232, in
_populate_retry
^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher
^[[01;35m^[[00mretry['num_attempts'] += 1
^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher
^[[01;35m^[[00mKeyError: 'num_attempts'
^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher
^[[01;35m^[[00m
2014-09-16 13:20:37.841 ^[[01;31mERROR oslo.messaging._drivers.common
[^[[01;36mreq-86b97f06-3f32-4107-8f41-e22b9538e73f
^[[00;36m41b264d0e8064e51a8e2e5ab78813c1a
db2eb368b9ab4c8b93bb8f765ca55244^[[01;31m] ^[[01;35m^[[01;31mReturning
exception 'num_attempts' to caller^[[00m

stack trace  - http://paste.openstack.org/show/112074/
cinder.conf - http://paste.openstack.org/show/112075/


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

Re: [openstack-dev] [Nova] What's holding nova development back?

[Daniel P. Berrange]

On Tue, Sep 16, 2014 at 07:30:26AM +1000, Michael Still wrote:
> On Tue, Sep 16, 2014 at 12:30 AM, Russell Bryant  wrote:
> > On 09/15/2014 05:42 AM, Daniel P. Berrange wrote:
> >> On Sun, Sep 14, 2014 at 07:07:13AM +1000, Michael Still wrote:
> >>> Just an observation from the last week or so...
> >>>
> >>> The biggest problem nova faces at the moment isn't code review latency. 
> >>> Our
> >>> biggest problem is failing to fix our bugs so that the gate is reliable.
> >>> The number of rechecks we've done in the last week to try and land code is
> >>> truly startling.
> >>
> >> I consider both problems to be pretty much equally as important. I don't
> >> think solving review latency or test reliabilty in isolation is enough to
> >> save Nova. We need to tackle both problems as a priority. I tried to avoid
> >> getting into my concerns about testing in my mail on review team 
> >> bottlenecks
> >> since I think we should address the problems independantly / in parallel.
> >
> > Agreed with this.  I don't think we can afford to ignore either one of them.
> 
> Yes, that was my point. I don't mind us debating how to rearrange
> hypervisor drivers. However, if we think that will solve all our
> problems we are confused.
> 
> So, how do we get people to start taking bugs / gate failures more
> seriously?

I think we should have formal "Bug squash wednesdays"  (or pick another
day). By this I mean that the core reviewers will focus their attention
on just reviews that are related to bug fixing. They will also try to
work on bugs if they have time and encourage everyone else involved in
Nova todo the same. We'd have a team of people in the Nova IRC channel
to publicise & co-ordinate bug squashing, perhaps  with a list of top
20 bugs we want to attack this week. I wouldn't focus just on gate bugs
here since many a pretty darn hard & so would put off many people. Have
a mix of bugs of varying difficulties to point people to. Make this a
regular fortnightly or even weekly event which we publicise in advance
on mailing lists, etc.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [openstack-dev] how to deploy juno devstack without multiple backend

[Swapnil Kulkarni]

On Tue, Sep 16, 2014 at 12:31 PM, Manickam, Kanagaraj <
kanagaraj.manic...@hp.com> wrote:

>  HP MSA is supported by cinder and use the following guidelines:
>
> http://docs.openstack.org/trunk/config-reference/content/hp-msa-driver.html
>
>
>
> you could install devstack and follow the above wiki or update the above
> defined HP MSA param as suggested by devstack at
> http://devstack.org/configuration.html
>
>
>
> [[post-config|$NOVA_CONF]]
>
I think it would be  [[post-config|$CINDER_CONF]]

>  HERE ADD THE HP MSA CONFIG DETAILS.
>
>
>
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] What's holding nova development back?

[Michael Still]

I think bug days are a good idea. We've had them sporadically in the
past, but never weekly. We stopped mostly because people stopped
showing up.

If we think we have critical mass again, or if it makes more sense to
run one during the RC period, then let's do it.

So... Who would show up for a bug day if we ran one?

Michael

On Tue, Sep 16, 2014 at 6:12 PM, Daniel P. Berrange  wrote:
> On Tue, Sep 16, 2014 at 07:30:26AM +1000, Michael Still wrote:
>> On Tue, Sep 16, 2014 at 12:30 AM, Russell Bryant  wrote:
>> > On 09/15/2014 05:42 AM, Daniel P. Berrange wrote:
>> >> On Sun, Sep 14, 2014 at 07:07:13AM +1000, Michael Still wrote:
>> >>> Just an observation from the last week or so...
>> >>>
>> >>> The biggest problem nova faces at the moment isn't code review latency. 
>> >>> Our
>> >>> biggest problem is failing to fix our bugs so that the gate is reliable.
>> >>> The number of rechecks we've done in the last week to try and land code 
>> >>> is
>> >>> truly startling.
>> >>
>> >> I consider both problems to be pretty much equally as important. I don't
>> >> think solving review latency or test reliabilty in isolation is enough to
>> >> save Nova. We need to tackle both problems as a priority. I tried to avoid
>> >> getting into my concerns about testing in my mail on review team 
>> >> bottlenecks
>> >> since I think we should address the problems independantly / in parallel.
>> >
>> > Agreed with this.  I don't think we can afford to ignore either one of 
>> > them.
>>
>> Yes, that was my point. I don't mind us debating how to rearrange
>> hypervisor drivers. However, if we think that will solve all our
>> problems we are confused.
>>
>> So, how do we get people to start taking bugs / gate failures more
>> seriously?
>
> I think we should have formal "Bug squash wednesdays"  (or pick another
> day). By this I mean that the core reviewers will focus their attention
> on just reviews that are related to bug fixing. They will also try to
> work on bugs if they have time and encourage everyone else involved in
> Nova todo the same. We'd have a team of people in the Nova IRC channel
> to publicise & co-ordinate bug squashing, perhaps  with a list of top
> 20 bugs we want to attack this week. I wouldn't focus just on gate bugs
> here since many a pretty darn hard & so would put off many people. Have
> a mix of bugs of varying difficulties to point people to. Make this a
> regular fortnightly or even weekly event which we publicise in advance
> on mailing lists, etc.
>
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o- http://virt-manager.org :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|



-- 
Rackspace Australia

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

Re: [openstack-dev] [Openstack] how to deploy juno devstack without multiple backend

[Nikesh Kumar Mahalka]

Hi i already tried many things but it was not working.
By default lvm multi-bakends is enabled in juno devstack.

then i went through devstack juno code and

*enabling only single backend:*
i didnot find exact solution so after installing devstack, i am changing
cinder.conf for
single backend and restarting cinder services.

*enabling multiple backends:*
i am adding this extra line in [local|localrc]] of local.conf
*CINDER_ENABLED_BACKENDS=hp_msa:hp_msa_driver,lvm:lvmdriver-1*

and outside [local|localrc]] of local.conf

[[post-config|$CINDER_CONF]]
[hp_msa_driver]
volume_driver = cinder.volume.drivers.san.hp.hp_msa_fc.HPMSAFCDriver
san_ip = 192.168.2.192
san_login = demo
san_password =!demo
volume_backend_name=HPMSA_FC

[lvmdriver-1]
volume_group=stack-volumes-1
volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
volume_backend_name=LVM_iSCSI

and again i am seeing cinder.conf file and if some thing is extra, i am
removing and restarting cinder services


Regards
Nikesh


On Tue, Sep 16, 2014 at 1:44 PM, Swapnil Kulkarni 
wrote:

>
>
> On Tue, Sep 16, 2014 at 12:31 PM, Manickam, Kanagaraj <
> kanagaraj.manic...@hp.com> wrote:
>
>>  HP MSA is supported by cinder and use the following guidelines:
>>
>>
>> http://docs.openstack.org/trunk/config-reference/content/hp-msa-driver.html
>>
>>
>>
>> you could install devstack and follow the above wiki or update the above
>> defined HP MSA param as suggested by devstack at
>> http://devstack.org/configuration.html
>>
>>
>>
>> [[post-config|$NOVA_CONF]]
>>
> I think it would be  [[post-config|$CINDER_CONF]]
>
>>  HERE ADD THE HP MSA CONFIG DETAILS.
>>
>>
>>
>>
>>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

[Flavio Percoco]

On 09/16/2014 01:10 AM, Clint Byrum wrote:
> Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
>> On 09/15/2014 07:00 PM, Mark Washenberger wrote:
>>> Hi there logging experts,
>>>
>>> We've recently had a little disagreement in the glance team about the
>>> appropriate log levels for http requests that end up failing due to user
>>> errors. An example would be a request to get an image that does not
>>> exist, which results in a 404 Not Found request.
>>>
>>> On one hand, this event is an error, so DEBUG or INFO seem a little too
>>> low. On the other hand, this error doesn't generally require any kind of
>>> operator investigation or indicate any actual failure of the service, so
>>> perhaps it is excessive to log it at WARN or ERROR.
>>>
>>> Please provide feedback to help us resolve this dispute if you feel you can!
>>
>> My feeling is this is an INFO level. There is really nothing the admin
>> should care about here.
> 
> Agree with Sean. INFO are useful for investigations. WARN and ERROR are
> cause for alarm.

+1 this is what we do in Zaqar as well.


-- 
@flaper87
Flavio Percoco

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

Re: [openstack-dev] [Openstack] how to deploy juno devstack without multiple backend

[Swapnil Kulkarni]

On Tue, Sep 16, 2014 at 2:18 PM, Nikesh Kumar Mahalka <
nikeshmaha...@vedams.com> wrote:

> Hi i already tried many things but it was not working.
> By default lvm multi-bakends is enabled in juno devstack.
>
> then i went through devstack juno code and
>
> *enabling only single backend:*
> i didnot find exact solution so after installing devstack, i am changing
> cinder.conf for
> single backend and restarting cinder services.
>
> *enabling multiple backends:*
> i am adding this extra line in [local|localrc]] of local.conf
> *CINDER_ENABLED_BACKENDS=hp_msa:hp_msa_driver,lvm:lvmdriver-1*
>
This thing would not work, I do not see a script for enabling hp_msa as
 cinder_backends

>
> and outside [local|localrc]] of local.conf
>
> [[post-config|$CINDER_CONF]]
> [hp_msa_driver]
> volume_driver = cinder.volume.drivers.san.hp.hp_msa_fc.HPMSAFCDriver
> san_ip = 192.168.2.192
> san_login = demo
> san_password =!demo
> volume_backend_name=HPMSA_FC
>
> [lvmdriver-1]
> volume_group=stack-volumes-1
> volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
> volume_backend_name=LVM_iSCSI
>
> and again i am seeing cinder.conf file and if some thing is extra, i am
> removing and restarting cinder services
>
if this thing does not work, I would suggest you to configure default
devstack, add the configuration  [hp_msa_driver] in cinder.conf and restart.
I will try the configuration you are trying and let you know in some time.

>
>
> Regards
> Nikesh
>
>
> On Tue, Sep 16, 2014 at 1:44 PM, Swapnil Kulkarni 
> wrote:
>
>>
>>
>> On Tue, Sep 16, 2014 at 12:31 PM, Manickam, Kanagaraj <
>> kanagaraj.manic...@hp.com> wrote:
>>
>>>  HP MSA is supported by cinder and use the following guidelines:
>>>
>>>
>>> http://docs.openstack.org/trunk/config-reference/content/hp-msa-driver.html
>>>
>>>
>>>
>>> you could install devstack and follow the above wiki or update the above
>>> defined HP MSA param as suggested by devstack at
>>> http://devstack.org/configuration.html
>>>
>>>
>>>
>>> [[post-config|$NOVA_CONF]]
>>>
>> I think it would be  [[post-config|$CINDER_CONF]]
>>
>>>  HERE ADD THE HP MSA CONFIG DETAILS.
>>>
>>>
>>>
>>>
>>>
>> ___
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to : openst...@lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] What's holding nova development back?

[Gary Kotton]

On 9/16/14, 11:12 AM, "Daniel P. Berrange"  wrote:

>On Tue, Sep 16, 2014 at 07:30:26AM +1000, Michael Still wrote:
>> On Tue, Sep 16, 2014 at 12:30 AM, Russell Bryant 
>>wrote:
>> > On 09/15/2014 05:42 AM, Daniel P. Berrange wrote:
>> >> On Sun, Sep 14, 2014 at 07:07:13AM +1000, Michael Still wrote:
>> >>> Just an observation from the last week or so...
>> >>>
>> >>> The biggest problem nova faces at the moment isn't code review
>>latency. Our
>> >>> biggest problem is failing to fix our bugs so that the gate is
>>reliable.
>> >>> The number of rechecks we've done in the last week to try and land
>>code is
>> >>> truly startling.
>> >>
>> >> I consider both problems to be pretty much equally as important. I
>>don't
>> >> think solving review latency or test reliabilty in isolation is
>>enough to
>> >> save Nova. We need to tackle both problems as a priority. I tried to
>>avoid
>> >> getting into my concerns about testing in my mail on review team
>>bottlenecks
>> >> since I think we should address the problems independantly / in
>>parallel.
>> >
>> > Agreed with this.  I don't think we can afford to ignore either one
>>of them.
>> 
>> Yes, that was my point. I don't mind us debating how to rearrange
>> hypervisor drivers. However, if we think that will solve all our
>> problems we are confused.
>> 
>> So, how do we get people to start taking bugs / gate failures more
>> seriously?
>
>I think we should have formal "Bug squash wednesdays"  (or pick another
>day). By this I mean that the core reviewers will focus their attention
>on just reviews that are related to bug fixing. They will also try to
>work on bugs if they have time and encourage everyone else involved in
>Nova todo the same. We'd have a team of people in the Nova IRC channel
>to publicise & co-ordinate bug squashing, perhaps  with a list of top
>20 bugs we want to attack this week. I wouldn't focus just on gate bugs
>here since many a pretty darn hard & so would put off many people. Have
>a mix of bugs of varying difficulties to point people to. Make this a
>regular fortnightly or even weekly event which we publicise in advance
>on mailing lists, etc.

I am in favor of that. This is similar to what I suggested in
http://lists.openstack.org/pipermail/openstack-dev/2014-September/045440.ht
ml

Thanks
Gary
>
>Regards,
>Daniel
>-- 
>|: 
>https://urldefense.proofpoint.com/v1/url?u=http://berrange.com/&k=oIvRg1%2
>BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%
>3D%0A&m=%2BBB%2BI2z%2F47JBRJ4B1mOkFOq0SW%2F4bOrVdaRdWsCsYn0%3D%0A&s=23d33d
>afdd513f39cce7f5f3ab73352c456981edc8f0aa6c4861d61f1ce0528c  -o-
>https://urldefense.proofpoint.com/v1/url?u=http://www.flickr.com/photos/db
>errange/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfD
>tysg45MkPhCZFxPEq8%3D%0A&m=%2BBB%2BI2z%2F47JBRJ4B1mOkFOq0SW%2F4bOrVdaRdWsC
>sYn0%3D%0A&s=2d1a888a2988ac4dd3736b5e3cbd83af371bb5155b92ed769a7dd5516d7ed
>a31 :|
>|: 
>https://urldefense.proofpoint.com/v1/url?u=http://libvirt.org/&k=oIvRg1%2B
>dGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3
>D%0A&m=%2BBB%2BI2z%2F47JBRJ4B1mOkFOq0SW%2F4bOrVdaRdWsCsYn0%3D%0A&s=c2a7391
>a88982f704eb0c1d17acfcb531f6388d637bc72d0fa6dbd5f2ee5077e
>-o- 
>https://urldefense.proofpoint.com/v1/url?u=http://virt-manager.org/&k=oIvR
>g1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxP
>Eq8%3D%0A&m=%2BBB%2BI2z%2F47JBRJ4B1mOkFOq0SW%2F4bOrVdaRdWsCsYn0%3D%0A&s=8f
>e922c5cb03f8a55c11b821bf9f4c011b6a3403db100266dba66e2e5f0c69ff :|
>|: 
>https://urldefense.proofpoint.com/v1/url?u=http://autobuild.org/&k=oIvRg1%
>2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8
>%3D%0A&m=%2BBB%2BI2z%2F47JBRJ4B1mOkFOq0SW%2F4bOrVdaRdWsCsYn0%3D%0A&s=3eb04
>79ea977e54c5203c70c9a8043195c3addd86cb4f2d0aca9ee34deff3f9f   -o-
>
>https://urldefense.proofpoint.com/v1/url?u=http://search.cpan.org/~danberr
>/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45M
>kPhCZFxPEq8%3D%0A&m=%2BBB%2BI2z%2F47JBRJ4B1mOkFOq0SW%2F4bOrVdaRdWsCsYn0%3D
>%0A&s=a13745c2c9636ce6c906c4467ba453cd8a2011fde467959cde586abc69cc0717 :|
>|: 
>https://urldefense.proofpoint.com/v1/url?u=http://entangle-photo.org/&k=oI
>vRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZF
>xPEq8%3D%0A&m=%2BBB%2BI2z%2F47JBRJ4B1mOkFOq0SW%2F4bOrVdaRdWsCsYn0%3D%0A&s=
>53d5c4828d9a4c7529bb8bb589b686af7eb1026f0bb7355655b32b06350c85f2
>-o-   
>https://urldefense.proofpoint.com/v1/url?u=http://live.gnome.org/gtk-vnc&k
>=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPh
>CZFxPEq8%3D%0A&m=%2BBB%2BI2z%2F47JBRJ4B1mOkFOq0SW%2F4bOrVdaRdWsCsYn0%3D%0A
>&s=427473a2fc971ad2586cfc228d80b49c48a730603946888ed33085a30da98985 :|
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___

Re: [openstack-dev] [Nova] What's holding nova development back?

[Kashyap Chamarthy]

On Tue, Sep 16, 2014 at 06:29:53PM +1000, Michael Still wrote:
> I think bug days are a good idea. We've had them sporadically in the
> past, but never weekly. We stopped mostly because people stopped
> showing up.
> 
> If we think we have critical mass again, or if it makes more sense to
> run one during the RC period, then let's do it.
> 
> So... Who would show up for a bug day if we ran one?

I'm not a Nova dev, but FWIW, I can spend time doing triage and root
cause analysis of areas involving virt drivers - libvirt, QEMU, KVM and
any other related areas in Nova.

PS: Next four weeks are going to be hectic for me personally due to some
travel, but I should be more active and available after that.

--
/kashyap

> 
> On Tue, Sep 16, 2014 at 6:12 PM, Daniel P. Berrange  
> wrote:
> > On Tue, Sep 16, 2014 at 07:30:26AM +1000, Michael Still wrote:
> >> On Tue, Sep 16, 2014 at 12:30 AM, Russell Bryant  
> >> wrote:
> >> > On 09/15/2014 05:42 AM, Daniel P. Berrange wrote:
> >> >> On Sun, Sep 14, 2014 at 07:07:13AM +1000, Michael Still wrote:
> >> >>> Just an observation from the last week or so...
> >> >>>
> >> >>> The biggest problem nova faces at the moment isn't code review 
> >> >>> latency. Our
> >> >>> biggest problem is failing to fix our bugs so that the gate is 
> >> >>> reliable.
> >> >>> The number of rechecks we've done in the last week to try and land 
> >> >>> code is
> >> >>> truly startling.
> >> >>
> >> >> I consider both problems to be pretty much equally as important. I don't
> >> >> think solving review latency or test reliabilty in isolation is enough 
> >> >> to
> >> >> save Nova. We need to tackle both problems as a priority. I tried to 
> >> >> avoid
> >> >> getting into my concerns about testing in my mail on review team 
> >> >> bottlenecks
> >> >> since I think we should address the problems independantly / in 
> >> >> parallel.
> >> >
> >> > Agreed with this.  I don't think we can afford to ignore either one of 
> >> > them.
> >>
> >> Yes, that was my point. I don't mind us debating how to rearrange
> >> hypervisor drivers. However, if we think that will solve all our
> >> problems we are confused.
> >>
> >> So, how do we get people to start taking bugs / gate failures more
> >> seriously?
> >
> > I think we should have formal "Bug squash wednesdays"  (or pick another
> > day). By this I mean that the core reviewers will focus their attention
> > on just reviews that are related to bug fixing. They will also try to
> > work on bugs if they have time and encourage everyone else involved in
> > Nova todo the same. We'd have a team of people in the Nova IRC channel
> > to publicise & co-ordinate bug squashing, perhaps  with a list of top
> > 20 bugs we want to attack this week. I wouldn't focus just on gate bugs
> > here since many a pretty darn hard & so would put off many people. Have
> > a mix of bugs of varying difficulties to point people to. Make this a
> > regular fortnightly or even weekly event which we publicise in advance
> > on mailing lists, etc.
> >
> > Regards,
> > Daniel


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

Re: [openstack-dev] [Nova] What's holding nova development back?

[Thierry Carrez]

Michael Still wrote:
> Yes, that was my point. I don't mind us debating how to rearrange
> hypervisor drivers. However, if we think that will solve all our
> problems we are confused.
> 
> So, how do we get people to start taking bugs / gate failures more seriously?

I think we need to build a cross-project team working on that. Having
gate liaisons designated in every project should help bootstrap that
team -- it doesn't mean it's a one-person-per-project job, but at least
you have a contact person when you need an expert in some project that
is also versed in the arts of the gate.

I also think we need to do a slightly better job at visualizing issues.
Like Dims said, even with tabs opened to the right places, it's
non-trivial to determine which is the killer bug from which isn't. And
without carefully checking IRC backlog in 4 different channels, it's
also hard to find out that a bug is already taken care of. I woke up one
morning with gate being obviously stuck on some issue, investigated it,
only to realize after 30 minutes that the fix was already in the gate
queue. That's a bit of a frustrating experience.

Finally, it's not completely crazy to use a specific channel
(#openstack-gate ?) for that. Yes, there is a lot of overlap with -qa
and -infra channels, but those channels aren't dedicated to that
problem, so 25% of the issues are discussed on one, 25% on the other,
25% on the project-specific channel, and the remaining 25% on some
random channel the right people happen to be in. Having a clear channel
where all the gate liaisons hang out and all issues are discussed may go
a long way into establishing a team to work on that (rather than
continue to rely on the same set of willing individuals).

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [Nova] Its time to start identifying release critical bugs

[Michael Still]

Hi.

Is time to start identifying (and working on) release critical bugs in
nova before we ship RC1.

My initial position is that any critical bug is release critical.
There are currently critical bugs not targeted to rc1, but that should
change in the next day or so. If we're not interested in fixing a
critical bug in rc1, I think we should start to question if it is
really critical.

I'd also like help in deciding what other bugs are critical to be
fixed before release. Please use this thread to suggest such things.

Thanks,
Michael

-- 
Rackspace Australia

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

Re: [openstack-dev] tempest error

[Duncan Thomas]

Looks like your glance upload is sufficiently slow that you're hitting
a timeout. Check your glance daemon logs to see if you can figure out
why it is slow.

On 15 September 2014 07:24, Nikesh Kumar Mahalka
 wrote:
> Hi I deployed a Icehouse devstack on ubuntu 14.04.
> When i am running tempest test on volume,i am getting errors.
>  I also attached my cinder.conf and tempest.conf file.
>
> I am running tempest tests by below command:
> ./run_tempest.sh tempest.api.volume
>
> Below is error:
>
> Traceback (most recent call last):
>   File "/opt/stack/tempest/tempest/test.py", line 128, in wrapper
> return f(self, *func_args, **func_kwargs)
>   File "/opt/stack/tempest/tempest/api/volume/test_volumes_actions.py", line
> 105, in test_volume_upload
> self.image_client.wait_for_image_status(image_id, 'active')
>   File "/opt/stack/tempest/tempest/services/image/v1/json/image_client.py",
> line 304, in wait_for_image_status
> raise exceptions.TimeoutException(message)
> TimeoutException: Request timed out
> Details: (VolumesV2ActionsTestXML:test_volume_upload) Time Limit Exceeded!
> (196s)while waiting for active, but we got saving.
>
> Ran 248 tests in 2671.199s
>
> FAILED (failures=26)
>
>
>
> Regrads
> Nikesh
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Duncan Thomas

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

Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

[Kuvaja, Erno]

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: 16 September 2014 10:08
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
> level
> guidelines
> 
> On 09/16/2014 01:10 AM, Clint Byrum wrote:
> > Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
> >> On 09/15/2014 07:00 PM, Mark Washenberger wrote:
> >>> Hi there logging experts,
> >>>
> >>> We've recently had a little disagreement in the glance team about
> >>> the appropriate log levels for http requests that end up failing due
> >>> to user errors. An example would be a request to get an image that
> >>> does not exist, which results in a 404 Not Found request.
> >>>
> >>> On one hand, this event is an error, so DEBUG or INFO seem a little
> >>> too low. On the other hand, this error doesn't generally require any
> >>> kind of operator investigation or indicate any actual failure of the
> >>> service, so perhaps it is excessive to log it at WARN or ERROR.
> >>>
> >>> Please provide feedback to help us resolve this dispute if you feel you
> can!
> >>
> >> My feeling is this is an INFO level. There is really nothing the
> >> admin should care about here.
> >
> > Agree with Sean. INFO are useful for investigations. WARN and ERROR
> > are cause for alarm.
> 
> +1 this is what we do in Zaqar as well.
> 
> 
> --
> @flaper87
> Flavio Percoco
> 

I think the debate here does not only limit to 404s. By the logging guidelines 
INFO level messages should not contain any error related messages but rather 
stuff like certain components starting/stopping, config info, etc. WARN should 
not be anything that gets the ops pulled out of bed and so on. 

Also all information that would be in interest of ops should be logged INFO+.

Now if we are logging user errors as WARN that makes the environment 
supportable even if the logging has been set as high as WARN cleaning the 
output a lot (as INFO shouldn't contain anything out of order anyways). Current 
situation is that logging at DEBUG level is the only option to get the needed 
information to actually run the services and get the data needed to support it 
as well. If we log user errors on INFO we get one step higher but we still have 
all that clutter like every single request in the logs and if that's the 
direction we want to go, we should revisit our logging guidelines as well.

Thus my two euro cents goes towards WARN rather than debug and definitely not 
INFO.

- Erno (jokke) Kuvaja

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

Re: [openstack-dev] [devstack] [cinder] [driver] Not able to create volume on a 3rd party driver backend

[Amit Das]

Hi All,

If I set *max_attempts = 1* in /etc/cinder/cinder.conf, then the volume
creation via 3rd party driver is success.
However, this setting does not work for volume deletion.

The volume gets deleted at openstack but never executes the driver code.

I did above changes based on the error stack trace.
*/opt/stack/cinder/cinder/scheduler/filter_scheduler.py
-> _populate_retry*

However, i  am not sure if this is a bug or an issue of missing
configuration.


Regards,
Amit
*CloudByte Inc.* 

On Tue, Sep 16, 2014 at 1:34 PM, Amit Das  wrote:

> Hi All,
>
> While trying to create a volume using my cinder driver (on devstack), i
> get below issue w.r.t num_attempts.
>
> Am i missing any configuration here ?
>
> ^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher
> ^[[01;35m^[[00m  File
> "/opt/stack/cinder/cinder/scheduler/filter_scheduler.py", line 271, in
> _get_weighted_candidates
> ^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher
> ^[[01;35m^[[00mself._populate_retry(filter_properties,
> resource_properties)
> ^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher
> ^[[01;35m^[[00m  File
> "/opt/stack/cinder/cinder/scheduler/filter_scheduler.py", line 232, in
> _populate_retry
> ^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher
> ^[[01;35m^[[00mretry['num_attempts'] += 1
> ^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher
> ^[[01;35m^[[00mKeyError: 'num_attempts'
> ^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher
> ^[[01;35m^[[00m
> 2014-09-16 13:20:37.841 ^[[01;31mERROR oslo.messaging._drivers.common
> [^[[01;36mreq-86b97f06-3f32-4107-8f41-e22b9538e73f
> ^[[00;36m41b264d0e8064e51a8e2e5ab78813c1a
> db2eb368b9ab4c8b93bb8f765ca55244^[[01;31m] ^[[01;35m^[[01;31mReturning
> exception 'num_attempts' to caller^[[00m
>
> stack trace  - http://paste.openstack.org/show/112074/
> cinder.conf - http://paste.openstack.org/show/112075/
>
>
> Regards,
> Amit
> *CloudByte Inc.* 
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] OpenStack bootstrapping hour - Friday Sept 19th - 3pm EST

[André Aranha]

This is a great idea, and will be hugely useful for new people in
Openstack, like me.

Thank you!

On 16 September 2014 03:31, Ricardo Carrillo Cruz <
ricardo.carrillo.c...@gmail.com> wrote:

> This is awesome, thanks for this guys!
>
> Regards
>
> 2014-09-16 7:09 GMT+02:00 Angelo Matarazzo :
>
>> You are great!!!
>> As newbie I tell you: thank you a lot
>> Angelo
>> Il giorno 16/set/2014 00:58, "Sean Dague"  ha scritto:
>>
>> A few of us have decided to pull together a regular (cadence to be
>>> determined) video series taking on deep dives inside of OpenStack,
>>> looking at code, explaining why things work that way, and fielding
>>> questions from anyone interested.
>>>
>>> For lack of a better title, I've declared it OpenStack Bootstrapping
>>> Hour.
>>>
>>> Episode 0 - Mock best practices will kick off this Friday, Sept 19th,
>>> from 3pm - 4pm EST. Our experts for this will be Jay Pipes and Dan
>>> Smith. It will be done as a Google Hangout on Air, which means there
>>> will be a live youtube stream while it's on, and a recorded youtube
>>> video that's publicly accessible once we're done.
>>>
>>> We'll be using an etherpad during the broadcast to provide links to the
>>> content people are looking at, as well as capture questions. That will
>>> be our backchannel, and audience participation forum, with the advantage
>>> that it creates a nice concise document at the end of the broadcast that
>>> pairs well with the video. (Also: the tech test showed that while code
>>> examples are perfectly viewable during in the final video, during the
>>> live stream they are a little hard to read, etherpad links will help
>>> people follow along at home).
>>>
>>> Assuming this turns out to be useful, we're thinking about lots of other
>>> deep dives. The intent is that these are indepth dives. We as a
>>> community have learned so many things over the last 4 years, but as
>>> OpenStack has gotten so large, being familiar with more than a narrow
>>> slice is hard. This is hopefully a part of the solution to address that.
>>> As I've told others, if nothing else, I'm looking forward to learning a
>>> ton in the process.
>>>
>>> Final links for the hangout + etherpad will be posted a little later in
>>> the week. Mostly wanted to make people aware it was coming.
>>>
>>> -Sean
>>>
>>> --
>>> Sean Dague
>>> http://dague.net
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> 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] oslo.db 0.5.0 released

[Victor Sergeyev]

Hello All!

Oslo team is pleased to announce the new Oslo database handling library
release - oslo.db 0.5.0

List of changes:

$ git log --oneline --no-merges 0.4.0..0.5.0
c785bee Updated from global requirements
ac05c2a Imported Translations from Transifex
57f499e Add a check for SQLite transactional state
bdcfb4a Let oslotest manage the six.move setting for mox
4ed63fa Fix DBReferenceError on MySQL and SQLite
49ae6c0 Renaming in WalkVersionsMixin
cae1202 Clean up documentation
fb577ec Use single quotes for db schema sanity check
ab47516 warn against sorting requirements
be6f9a0 ModelsMigrationsSync:Override compare_server_default
e187a4c Updated from global requirements
cbf995e Imported Translations from Transifex
f2f0960 Add doc8 to tox environment docs
92d9a1c Use oslo.i18n
78fd290 Repair pysqlite transaction support
41dada1 Extract logging setup into a separate function
7c57798 Updated from global requirements
977869d Remove reliance on create_engine() from TestsExceptionFilter
626d762 Consolidate sqlite and mysql event listeners
5ab43ee Use dialect dispatch for engine initiailization.
4683475 Add get_non_innodb_tables() to utils
686005e Added check to see whether oslotest is installed

Please report issues to the bug tracker: https://bugs.launchpad.net/oslo.db
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

[Sean Dague]

On 09/16/2014 06:44 AM, Kuvaja, Erno wrote:
>> -Original Message-
>> From: Flavio Percoco [mailto:fla...@redhat.com]
>> Sent: 16 September 2014 10:08
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
>> level
>> guidelines
>>
>> On 09/16/2014 01:10 AM, Clint Byrum wrote:
>>> Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
 On 09/15/2014 07:00 PM, Mark Washenberger wrote:
> Hi there logging experts,
>
> We've recently had a little disagreement in the glance team about
> the appropriate log levels for http requests that end up failing due
> to user errors. An example would be a request to get an image that
> does not exist, which results in a 404 Not Found request.
>
> On one hand, this event is an error, so DEBUG or INFO seem a little
> too low. On the other hand, this error doesn't generally require any
> kind of operator investigation or indicate any actual failure of the
> service, so perhaps it is excessive to log it at WARN or ERROR.
>
> Please provide feedback to help us resolve this dispute if you feel you
>> can!

 My feeling is this is an INFO level. There is really nothing the
 admin should care about here.
>>>
>>> Agree with Sean. INFO are useful for investigations. WARN and ERROR
>>> are cause for alarm.
>>
>> +1 this is what we do in Zaqar as well.
>>
>>
>> --
>> @flaper87
>> Flavio Percoco
>>
> 
> I think the debate here does not only limit to 404s. By the logging 
> guidelines INFO level messages should not contain any error related messages 
> but rather stuff like certain components starting/stopping, config info, etc. 
> WARN should not be anything that gets the ops pulled out of bed and so on. 
> 
> Also all information that would be in interest of ops should be logged INFO+.
> 
> Now if we are logging user errors as WARN that makes the environment 
> supportable even if the logging has been set as high as WARN cleaning the 
> output a lot (as INFO shouldn't contain anything out of order anyways). 
> Current situation is that logging at DEBUG level is the only option to get 
> the needed information to actually run the services and get the data needed 
> to support it as well. If we log user errors on INFO we get one step higher 
> but we still have all that clutter like every single request in the logs and 
> if that's the direction we want to go, we should revisit our logging 
> guidelines as well.
> 
> Thus my two euro cents goes towards WARN rather than debug and definitely not 
> INFO.

Part of it is how often you expect things to happen as well. Remember
glanceclient opperates in the context of "other" processes. When it hits
a 404 in Glance, it's not running in the glance context, it's running in
the Nova context. Which means it needs to think of itself in that context.

In that context we got the exception back from Glance, we know the image
wasn't there. And we know whether or not that's a problem (glanceclient
actually has no idea if it's a problem or not, we might be checking to
make sure a thing isn't there, and success for us is the 404).

So actually, I'm back to Jay on this, it should be DEBUG. Nova (or
whoever the caller is) can decide if the issue warents something larger
than that.

This is really the biggest issue with logging in the clients, people
don't think about the context that they are running in.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Nova] What's holding nova development back?

[Sean Dague]

On 09/16/2014 05:44 AM, Thierry Carrez wrote:
> Michael Still wrote:
>> Yes, that was my point. I don't mind us debating how to rearrange
>> hypervisor drivers. However, if we think that will solve all our
>> problems we are confused.
>>
>> So, how do we get people to start taking bugs / gate failures more seriously?
> 
> I think we need to build a cross-project team working on that. Having
> gate liaisons designated in every project should help bootstrap that
> team -- it doesn't mean it's a one-person-per-project job, but at least
> you have a contact person when you need an expert in some project that
> is also versed in the arts of the gate.
> 
> I also think we need to do a slightly better job at visualizing issues.
> Like Dims said, even with tabs opened to the right places, it's
> non-trivial to determine which is the killer bug from which isn't. And
> without carefully checking IRC backlog in 4 different channels, it's
> also hard to find out that a bug is already taken care of. I woke up one
> morning with gate being obviously stuck on some issue, investigated it,
> only to realize after 30 minutes that the fix was already in the gate
> queue. That's a bit of a frustrating experience.
>
> Finally, it's not completely crazy to use a specific channel
> (#openstack-gate ?) for that. Yes, there is a lot of overlap with -qa
> and -infra channels, but those channels aren't dedicated to that
> problem, so 25% of the issues are discussed on one, 25% on the other,
> 25% on the project-specific channel, and the remaining 25% on some
> random channel the right people happen to be in. Having a clear channel
> where all the gate liaisons hang out and all issues are discussed may go
> a long way into establishing a team to work on that (rather than
> continue to rely on the same set of willing individuals).

Honestly, I'm pretty anti 'add another channel'. Especially because
there seems to be some assumption that you can address this problem
without understanding our integration environment (devstack / tempest /
d-g). This is not a problem in isolation, it's a problem about the
synthesis of all the parts. The diving on these issues is already
happening in a place, we should build on that, and not synthetically
create some 3rd place esperanto channel thinking that will fix the issue.

I've thought about the visualization problem a lot... some of the output
included the os-loganalyze and elastic-recheck projects as well as
pretty-tox in tempest to ensure we see which worker each test is running
in so you can figure out what's happening simultaneously.

Here's the root problem I ran into. What kinds of visualizations are
useful changes at a pretty good clip. These bugs are hard to find and
fix because they are typically the interaction of a bunch of moving parts.

So the tools you need to fix them are some combination of
visualizations, plus a reasonable mental model in your head of how all
of OpenStack fits together (and how components expose to operators what
they are doing). I actually think part 2 is actually the weak spot for
most folks. Knowing that glanceclient's logging is rediculous, and you
should ignore it (for instance), because it spews a ton of ERRORS for no
good reason.

Basically that's the key skill. Understanding the request flows that go
through OpenStack, understanding how to read OpenStack logs, and being
mindful that the issue might be caused by other things happening at the
same time that you are trying to do a thing (so keep an eye out for those).

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [neutron] Ipset, merge refactor for J?

[Sean Dague]

On 09/16/2014 03:57 AM, Thierry Carrez wrote:
> Miguel Angel Ajo Pelayo wrote:
>> During the ipset implementatio, we designed a refactor [1] to cleanup 
>> the firewall driver a bit, and move all the ipset low-level knowledge 
>> down into the  IpsetManager.
>>
>> I'd like to see this merged for J, and, it's a bit of an urgent matter 
>> to decide, because we keep adding small changes [2] [3] fruit of the
>> early testing which break the refactor, and will add extra work which
>> needs to be refactored too.
>>
>> The advantage of merging now, vs in J, is having K & J share a more common 
>> code base, which would help us during bug backports/etc in the future.
>>
>> Shihanzhang and I, are happy to see this merge during K, as it doesn't 
>> incur in functional changes, just code blocks are moved from the iptables
>> firewall driver to IpsetManager, and the corresponding tests are moved too.
>> [...]
> 
> IMHO code refactoring should be considered a superfluous change at this
> point in the cycle. The risk/benefit ratio is too high, and focus should
> be on bugfixing at this point.

+1.

Hold the refactoring until Kilo.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Nova] What's holding nova development back?

[Daniel P. Berrange]

On Tue, Sep 16, 2014 at 06:29:53PM +1000, Michael Still wrote:
> I think bug days are a good idea. We've had them sporadically in the
> past, but never weekly. We stopped mostly because people stopped
> showing up.
> 
> If we think we have critical mass again, or if it makes more sense to
> run one during the RC period, then let's do it.
> 
> So... Who would show up for a bug day if we ran one?

IMHO that question is attacking this the wrong way. We should have the
nova core & PTL team lead by example, by all agreeing to actively take
part in formally scheduled bug days. Use this to set the expectations
for the rest of the community, to encourage them to join in too, and
not just rely on a handful of people to volunteer.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [openstack-dev] [Nova] What's holding nova development back?

[Jay Pipes]

On 09/16/2014 04:29 AM, Michael Still wrote:

I think bug days are a good idea. We've had them sporadically in the
past, but never weekly. We stopped mostly because people stopped
showing up.

If we think we have critical mass again, or if it makes more sense to
run one during the RC period, then let's do it.

So... Who would show up for a bug day if we ran one?


I would.

-jay


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

Re: [openstack-dev] [Nova] What's holding nova development back?

[Jay Pipes]

On 09/16/2014 04:12 AM, Daniel P. Berrange wrote:

On Tue, Sep 16, 2014 at 07:30:26AM +1000, Michael Still wrote:

On Tue, Sep 16, 2014 at 12:30 AM, Russell Bryant  wrote:

On 09/15/2014 05:42 AM, Daniel P. Berrange wrote:

On Sun, Sep 14, 2014 at 07:07:13AM +1000, Michael Still wrote:

Just an observation from the last week or so...

The biggest problem nova faces at the moment isn't code review latency. Our
biggest problem is failing to fix our bugs so that the gate is reliable.
The number of rechecks we've done in the last week to try and land code is
truly startling.


I consider both problems to be pretty much equally as important. I don't
think solving review latency or test reliabilty in isolation is enough to
save Nova. We need to tackle both problems as a priority. I tried to avoid
getting into my concerns about testing in my mail on review team bottlenecks
since I think we should address the problems independantly / in parallel.


Agreed with this.  I don't think we can afford to ignore either one of them.


Yes, that was my point. I don't mind us debating how to rearrange
hypervisor drivers. However, if we think that will solve all our
problems we are confused.

So, how do we get people to start taking bugs / gate failures more
seriously?


I think we should have formal "Bug squash wednesdays"  (or pick another
day). By this I mean that the core reviewers will focus their attention
on just reviews that are related to bug fixing. They will also try to
work on bugs if they have time and encourage everyone else involved in
Nova todo the same. We'd have a team of people in the Nova IRC channel
to publicise & co-ordinate bug squashing, perhaps  with a list of top
20 bugs we want to attack this week. I wouldn't focus just on gate bugs
here since many a pretty darn hard & so would put off many people. Have
a mix of bugs of varying difficulties to point people to. Make this a
regular fortnightly or even weekly event which we publicise in advance
on mailing lists, etc.


+1, I've suggested similar in the past.

-jay


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

Re: [openstack-dev] [Heat] Defining what is a SupportStatus version

[Ryan Brown]

On 09/15/2014 05:33 PM, Clint Byrum wrote:
> Excerpts from Zane Bitter's message of 2014-09-15 09:31:33 -0700:
>> On 14/09/14 11:09, Clint Byrum wrote:
>>> Excerpts from Gauvain Pocentek's message of 2014-09-04 22:29:05 -0700:
 Hi,

 A bit of background: I'm working on the publication of the HOT
 resources reference on docs.openstack.org. This book is mostly
 autogenerated from the heat source code, using the sphinx XML output. To
 avoid publishing several references (one per released version, as is
 done for the OpenStack config-reference), I'd like to add information
 about the support status of each resource (when they appeared, when
 they've been deprecated, and so on).

 So the plan is to use the SupportStatus class and its `version`
 attribute (see https://review.openstack.org/#/c/116443/ ). And the
 question is, what information should the version attribute hold?
 Possibilities include the release code name (Icehouse, Juno), or the
 release version (2014.1, 2014.2). But this wouldn't be useful for users
 of clouds continuously deployed.

   From my documenter point of view, using the code name seems the right
 option, because it fits with the rest of the documentation.

 What do you think would be the best choice from the heat devs POV?
>>>
>>> What we ship in-tree is the standard library for Heat. I think Heat
>>> should not tie things to the release of OpenStack, but only to itself.
>>
>> "Standard Library" implies that everyone has it available, but in 
>> reality operators can (and will, and do) deploy any combination of 
>> resource types that they want.
>>
> 
> Mmk, I guess I was being too optimistic about how homogeneous OpenStack
> clouds might be.

(From Zane's other message)
> 
> I think the first supported release is probably the right information
to add.
> 

I feel like for anything with nonzero upgrade effort (and upgrading your
openstack install takes significantly more than 0 effort units) you can
never assume everyone is running the latest (or even a recent) revision.
That's why projects often host docs versions *way* back.

The SQLAlchemy project hosts docs back to 2012[1] and also has latest[2]
docs that are updated continuously. I think the way to support the most
use cases would be to have docs for each release as well as continue to
have CI update docs.

For a URL structure I could see docs.o.o/developer/heat/latest and
d.o.o/heat/ where  can be either a semver release (2014.2,
etc) or a release name (icehouse, havana, etc). The strategy SQLA and
other projects use is to feature a release date prominently at the top
of the page, so users can look and say "Oh, Juno isn't released yet, so
this feature won't be in my Icehouse cloud".

[1] http://docs.sqlalchemy.org/en/rel_0_6/core/index.html
[2] http://docs.sqlalchemy.org/en/latest/core/index.html


> 
>>> The idea is to simply version the standard library of resources separately
>>> even from the language. Added resources and properties would be minor
>>> bumps, deprecating or removing anything would be a major bump. Users then
>>> just need an API call that allows querying the standard library version.
>>
>> We already have API calls to actually inspect resource types. I don't 
>> think a semantic version number is helpful here, since the different 
>> existing combinations of resources types are not expressible linearly.
>>
>> There's no really good answer here, but the only real answer is making 
>> sure it's easy for people to generate the docs themselves for their 
>> actual deployment.
>>
> 
> That's an interesting idea. By any chance do we have something that
> publishes the docs directly from source tree into swift? Might make it
> easier if we could just do that as part of code pushes for those who run
> clouds from source.
> 
>>> With this scheme, we can provide a gate test that prevents breaking the
>>> rules, and automatically generate the docs still. Doing this would sync
>>> better with continuous deployers who will be running "Juno" well before
>>> there is a "2014.2".
>>
>> Maybe continuous deployers should continuously deploy their own docs? 
>> For any given cloud the only thing that matters is what it supports 
>> right now.
>>
> 
> Thats an interesting idea, but I like what the user wants is to see how
> this cloud is different than the other clouds.
> 
>>> Anyway, Heat largely exists to support portability of apps between
>>> OpenStack clouds. Many many OpenStack clouds don't run one release,
>>> and we don't require them to do so. So tying to the release is, IMO,
>>> a poor coice.
>>
>> The original question was about docs.openstack.org, and in that context 
>> I think tying it to the release version is a good choice, because 
>> that's... how OpenStack is released. Individual clouds, however, really 
>> need to deploy their own docs that document what they actually support.
>>
> 
> Yeah I hadn't thought of that before. I like

Re: [openstack-dev] [Heat] Defining what is a SupportStatus version

[Ryan Brown]

On 09/16/2014 09:49 AM, Ryan Brown wrote:.
> 
> (From Zane's other message)
>> 
>> I think the first supported release is probably the right information
> to add.
>> 
> 
> I feel like for anything with nonzero upgrade effort (and upgrading your
> openstack install takes significantly more than 0 effort units) you can
> never assume everyone is running the latest (or even a recent) revision.
> That's why projects often host docs versions *way* back.
> 
> The SQLAlchemy project hosts docs back to 2012[1] and also has latest[2]
> docs that are updated continuously. I think the way to support the most
> use cases would be to have docs for each release as well as continue to
> have CI update docs.
> 
> For a URL structure I could see docs.o.o/developer/heat/latest and
> d.o.o/heat/ where  can be either a semver release (2014.2,
> etc) or a release name (icehouse, havana, etc). The strategy SQLA and
> other projects use is to feature a release date prominently at the top
> of the page, so users can look and say "Oh, Juno isn't released yet, so
> this feature won't be in my Icehouse cloud".
> 
> [1] http://docs.sqlalchemy.org/en/rel_0_6/core/index.html
> [2] http://docs.sqlalchemy.org/en/latest/core/index.html
> 
> 

Also most projects that use readthedocs.org have a dropdown on every
docs page that link to that page at different releases. I think it would
greatly improve discoverability of documentation for prior releases.

Sorry for doubling up messages,
-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.

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

Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

[Kuvaja, Erno]

> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
> Sent: 16 September 2014 12:40
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
> level
> guidelines
> 
> On 09/16/2014 06:44 AM, Kuvaja, Erno wrote:
> >> -Original Message-
> >> From: Flavio Percoco [mailto:fla...@redhat.com]
> >> Sent: 16 September 2014 10:08
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the
> >> log level guidelines
> >>
> >> On 09/16/2014 01:10 AM, Clint Byrum wrote:
> >>> Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
>  On 09/15/2014 07:00 PM, Mark Washenberger wrote:
> > Hi there logging experts,
> >
> > We've recently had a little disagreement in the glance team about
> > the appropriate log levels for http requests that end up failing
> > due to user errors. An example would be a request to get an image
> > that does not exist, which results in a 404 Not Found request.
> >
> > On one hand, this event is an error, so DEBUG or INFO seem a
> > little too low. On the other hand, this error doesn't generally
> > require any kind of operator investigation or indicate any actual
> > failure of the service, so perhaps it is excessive to log it at WARN or
> ERROR.
> >
> > Please provide feedback to help us resolve this dispute if you
> > feel you
> >> can!
> 
>  My feeling is this is an INFO level. There is really nothing the
>  admin should care about here.
> >>>
> >>> Agree with Sean. INFO are useful for investigations. WARN and ERROR
> >>> are cause for alarm.
> >>
> >> +1 this is what we do in Zaqar as well.
> >>
> >>
> >> --
> >> @flaper87
> >> Flavio Percoco
> >>
> >
> > I think the debate here does not only limit to 404s. By the logging 
> > guidelines
> INFO level messages should not contain any error related messages but
> rather stuff like certain components starting/stopping, config info, etc.
> WARN should not be anything that gets the ops pulled out of bed and so on.
> >
> > Also all information that would be in interest of ops should be logged
> INFO+.
> >
> > Now if we are logging user errors as WARN that makes the environment
> supportable even if the logging has been set as high as WARN cleaning the
> output a lot (as INFO shouldn't contain anything out of order anyways).
> Current situation is that logging at DEBUG level is the only option to get the
> needed information to actually run the services and get the data needed to
> support it as well. If we log user errors on INFO we get one step higher but
> we still have all that clutter like every single request in the logs and if 
> that's
> the direction we want to go, we should revisit our logging guidelines as well.
> >
> > Thus my two euro cents goes towards WARN rather than debug and
> definitely not INFO.
> 
> Part of it is how often you expect things to happen as well. Remember
> glanceclient opperates in the context of "other" processes. When it hits a 404
> in Glance, it's not running in the glance context, it's running in the Nova
> context. Which means it needs to think of itself in that context.
> 
> In that context we got the exception back from Glance, we know the image
> wasn't there. And we know whether or not that's a problem (glanceclient
> actually has no idea if it's a problem or not, we might be checking to make
> sure a thing isn't there, and success for us is the 404).
> 
> So actually, I'm back to Jay on this, it should be DEBUG. Nova (or whoever the
> caller is) can decide if the issue warents something larger than that.
> 
> This is really the biggest issue with logging in the clients, people don't 
> think
> about the context that they are running in.
> 
>   -Sean
> 
> --
> Sean Dague
> http://dague.net
> 

Sean,

I'm not sure if we were specific enough here. Not talking about client but the 
server logging. So how we should log events like client trying to change 
protected properties, access non existing image, create duplicate image IDs, 
etc.

So for example if Nova is trying to access image that does not exist should we 
ignore it on Glance side or when the user tries to do something that does not 
succeed. In my point of view it makes life much easier if we have information 
where the request failed rather than just a wsgi return code or having to run 
the system on DEBUG logging to get that information.

- Erno

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

[openstack-dev] Hyper-V meeting

[Peter Pouliot]

Hi All,

Many of us this week are either swamped or travelling.  Because we do not have 
the numbers, I'm postpoing the meeting until next week.

P


Peter J. Pouliot CISSP
Sr. SDET OpenStack
Microsoft
New England Research & Development Center
1 Memorial Drive
Cambridge, MA 02142
P: 1.(857).4536436
E: ppoul...@microsoft.com

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

Re: [openstack-dev] [neutron][security-groups] Neutron default security groups

[Baohua Yang]

The similar problem has been discussed before.
There is no definitive answer, and currently seems we cannot simply disable
it since G version.
However, we can add some ALLOW rules to bypass the rules inside the
iptables chains.
Hope there be more flexibility to controller the security groups in the
future release.


On Tue, Sep 16, 2014 at 4:00 PM, Fawad Khaliq  wrote:

> Folks,
>
> I have had discussions with some folks individually about this but I would
> like bring this to a broader audience.
>
> I have been playing with security groups and I see the notion of 'default'
> security group seems to create some nuisance/issues.
>
> There are list of things I have noticed so far:
>
>- Tenant for OpenStack services (normally named service/services) also
>ends up having default security group.
>- Port create operation ends up ensuring default security groups for
>all the tenants as this completely seems out of the context of the tenant
>the port operation takes place. (bug?)
>- Race conditions where if system is stressed and Neutron tries to
>ensure the first default security group and in parallel another call comes,
>Neutron ends up trying to create multiple default security groups as the
>checks for duplicate groups are invalidated as soon as the call make past a
>certain point in code.
>- API performance where orchestration chooses to spawn 1000 tenants
>and we see unnecessary overhead.
>- For plugins that use RESTful proxy backends require the backend
>systems to be up at the time neutron starts. [Minor, but affects some
>packaging solutions]
>
>
> To summarize, is there a way to disable default security groups? Expected
> answer is no; can we introduce a way to disable it? If that does not make
> sense, should we go ahead and fix the issues around it?
>
> I am sure some of you must have seen some of these issues and solved them
> already. Please do share how do tackle these issues?
>
> Thanks,
> Fawad Khaliq
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [Nova] What's holding nova development back?

[Sean Dague]

On 09/16/2014 09:39 AM, Jay Pipes wrote:
> On 09/16/2014 04:12 AM, Daniel P. Berrange wrote:
>> On Tue, Sep 16, 2014 at 07:30:26AM +1000, Michael Still wrote:
>>> On Tue, Sep 16, 2014 at 12:30 AM, Russell Bryant 
>>> wrote:
 On 09/15/2014 05:42 AM, Daniel P. Berrange wrote:
> On Sun, Sep 14, 2014 at 07:07:13AM +1000, Michael Still wrote:
>> Just an observation from the last week or so...
>>
>> The biggest problem nova faces at the moment isn't code review
>> latency. Our
>> biggest problem is failing to fix our bugs so that the gate is
>> reliable.
>> The number of rechecks we've done in the last week to try and land
>> code is
>> truly startling.
>
> I consider both problems to be pretty much equally as important. I
> don't
> think solving review latency or test reliabilty in isolation is
> enough to
> save Nova. We need to tackle both problems as a priority. I tried
> to avoid
> getting into my concerns about testing in my mail on review team
> bottlenecks
> since I think we should address the problems independantly / in
> parallel.

 Agreed with this.  I don't think we can afford to ignore either one
 of them.
>>>
>>> Yes, that was my point. I don't mind us debating how to rearrange
>>> hypervisor drivers. However, if we think that will solve all our
>>> problems we are confused.
>>>
>>> So, how do we get people to start taking bugs / gate failures more
>>> seriously?
>>
>> I think we should have formal "Bug squash wednesdays"  (or pick another
>> day). By this I mean that the core reviewers will focus their attention
>> on just reviews that are related to bug fixing. They will also try to
>> work on bugs if they have time and encourage everyone else involved in
>> Nova todo the same. We'd have a team of people in the Nova IRC channel
>> to publicise & co-ordinate bug squashing, perhaps  with a list of top
>> 20 bugs we want to attack this week. I wouldn't focus just on gate bugs
>> here since many a pretty darn hard & so would put off many people. Have
>> a mix of bugs of varying difficulties to point people to. Make this a
>> regular fortnightly or even weekly event which we publicise in advance
>> on mailing lists, etc.
> 
> +1, I've suggested similar in the past.

+1 a weekly event would be great.

I've spent the bulk of the last 2 weeks in the Nova bug tracker, and
it's pretty interesting what's in there. Lots of stuff we should be
fixing. Lots of really old gorp that we should shed because it's not
helping. Also lots of inconsistencies in how triage is happening because
it's not happening regularly enough.

Plus, now that we are at 0 bugs in the New state in Nova, it's actually
kind of sane to stay on top of that, and keep our New state empty. Not
that it fixes everything, but it does prevent a bunch of gorp getting
added to the pile as probably 1/2 - 1/3 of inbound bugs... aren't.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [neutron][security-groups] Neutron default security groups

[Fawad Khaliq]

Hi Boahua,

Thanks for sharing your thoughts. The issues seen are not related to
"access", they are all related to API layer, so having ALLOW all etc does
not fix/workaround the problems I mentioned.

Please do share if you have something more to add.

Fawad Khaliq

On Tue, Sep 16, 2014 at 7:28 PM, Baohua Yang  wrote:

> The similar problem has been discussed before.
> There is no definitive answer, and currently seems we cannot simply
> disable it since G version.
> However, we can add some ALLOW rules to bypass the rules inside the
> iptables chains.
> Hope there be more flexibility to controller the security groups in the
> future release.
>
>
> On Tue, Sep 16, 2014 at 4:00 PM, Fawad Khaliq  wrote:
>
>> Folks,
>>
>> I have had discussions with some folks individually about this but I
>> would like bring this to a broader audience.
>>
>> I have been playing with security groups and I see the notion of
>> 'default' security group seems to create some nuisance/issues.
>>
>> There are list of things I have noticed so far:
>>
>>- Tenant for OpenStack services (normally named service/services)
>>also ends up having default security group.
>>- Port create operation ends up ensuring default security groups for
>>all the tenants as this completely seems out of the context of the tenant
>>the port operation takes place. (bug?)
>>- Race conditions where if system is stressed and Neutron tries to
>>ensure the first default security group and in parallel another call 
>> comes,
>>Neutron ends up trying to create multiple default security groups as the
>>checks for duplicate groups are invalidated as soon as the call make past 
>> a
>>certain point in code.
>>- API performance where orchestration chooses to spawn 1000 tenants
>>and we see unnecessary overhead.
>>- For plugins that use RESTful proxy backends require the backend
>>systems to be up at the time neutron starts. [Minor, but affects some
>>packaging solutions]
>>
>>
>> To summarize, is there a way to disable default security groups? Expected
>> answer is no; can we introduce a way to disable it? If that does not make
>> sense, should we go ahead and fix the issues around it?
>>
>> I am sure some of you must have seen some of these issues and solved them
>> already. Please do share how do tackle these issues?
>>
>> Thanks,
>> Fawad Khaliq
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best wishes!
> Baohua
>
> ___
> 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] [glance][all] Help with interpreting the log level guidelines

[Sean Dague]

On 09/16/2014 10:16 AM, Kuvaja, Erno wrote:
>> -Original Message-
>> From: Sean Dague [mailto:s...@dague.net]
>> Sent: 16 September 2014 12:40
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
>> level
>> guidelines
>>
>> On 09/16/2014 06:44 AM, Kuvaja, Erno wrote:
 -Original Message-
 From: Flavio Percoco [mailto:fla...@redhat.com]
 Sent: 16 September 2014 10:08
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [glance][all] Help with interpreting the
 log level guidelines

 On 09/16/2014 01:10 AM, Clint Byrum wrote:
> Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
>> On 09/15/2014 07:00 PM, Mark Washenberger wrote:
>>> Hi there logging experts,
>>>
>>> We've recently had a little disagreement in the glance team about
>>> the appropriate log levels for http requests that end up failing
>>> due to user errors. An example would be a request to get an image
>>> that does not exist, which results in a 404 Not Found request.
>>>
>>> On one hand, this event is an error, so DEBUG or INFO seem a
>>> little too low. On the other hand, this error doesn't generally
>>> require any kind of operator investigation or indicate any actual
>>> failure of the service, so perhaps it is excessive to log it at WARN or
>> ERROR.
>>>
>>> Please provide feedback to help us resolve this dispute if you
>>> feel you
 can!
>>
>> My feeling is this is an INFO level. There is really nothing the
>> admin should care about here.
>
> Agree with Sean. INFO are useful for investigations. WARN and ERROR
> are cause for alarm.

 +1 this is what we do in Zaqar as well.


 --
 @flaper87
 Flavio Percoco

>>>
>>> I think the debate here does not only limit to 404s. By the logging 
>>> guidelines
>> INFO level messages should not contain any error related messages but
>> rather stuff like certain components starting/stopping, config info, etc.
>> WARN should not be anything that gets the ops pulled out of bed and so on.
>>>
>>> Also all information that would be in interest of ops should be logged
>> INFO+.
>>>
>>> Now if we are logging user errors as WARN that makes the environment
>> supportable even if the logging has been set as high as WARN cleaning the
>> output a lot (as INFO shouldn't contain anything out of order anyways).
>> Current situation is that logging at DEBUG level is the only option to get 
>> the
>> needed information to actually run the services and get the data needed to
>> support it as well. If we log user errors on INFO we get one step higher but
>> we still have all that clutter like every single request in the logs and if 
>> that's
>> the direction we want to go, we should revisit our logging guidelines as 
>> well.
>>>
>>> Thus my two euro cents goes towards WARN rather than debug and
>> definitely not INFO.
>>
>> Part of it is how often you expect things to happen as well. Remember
>> glanceclient opperates in the context of "other" processes. When it hits a 
>> 404
>> in Glance, it's not running in the glance context, it's running in the Nova
>> context. Which means it needs to think of itself in that context.
>>
>> In that context we got the exception back from Glance, we know the image
>> wasn't there. And we know whether or not that's a problem (glanceclient
>> actually has no idea if it's a problem or not, we might be checking to make
>> sure a thing isn't there, and success for us is the 404).
>>
>> So actually, I'm back to Jay on this, it should be DEBUG. Nova (or whoever 
>> the
>> caller is) can decide if the issue warents something larger than that.
>>
>> This is really the biggest issue with logging in the clients, people don't 
>> think
>> about the context that they are running in.
>>
>>  -Sean
>>
>> --
>> Sean Dague
>> http://dague.net
>>
> 
> Sean,
> 
> I'm not sure if we were specific enough here. Not talking about client but 
> the server logging. So how we should log events like client trying to change 
> protected properties, access non existing image, create duplicate image IDs, 
> etc.
> 
> So for example if Nova is trying to access image that does not exist should 
> we ignore it on Glance side or when the user tries to do something that does 
> not succeed. In my point of view it makes life much easier if we have 
> information where the request failed rather than just a wsgi return code or 
> having to run the system on DEBUG logging to get that information.

Glance client throws an ERROR on 404 from Glance server -
http://logs.openstack.org/81/120781/4/check/check-tempest-dsvm-full/90cb640/logs/screen-n-api.txt.gz?level=ERROR

Glance server does not -
http://logs.openstack.org/81/120781/4/check/check-tempest-dsvm-full/90cb640/logs/screen-g-api.txt.gz?level=ERROR

Which is why I assumed this was where the conversatio

Re: [openstack-dev] [zaqar] Juno Performance Testing (Round 2)

[Kurt Griffiths]

Right, graphing those sorts of variables has always been part of our test plan. 
What I’ve done so far was just some pilot tests, and I realize now that I 
wasn’t very clear on that point. I wanted to get a rough idea of where the 
Redis driver sat in case there were any obvious bug fixes that needed to be 
taken care of before performing more extensive testing. As it turns out, I did 
find one bug that has since been fixed.

Regarding latency, saying that it "is not important” is an exaggeration; it is 
definitely important, just not the only thing that is important. I have spoken 
with a lot of prospective Zaqar users since the inception of the project, and 
one of the common threads was that latency needed to be reasonable. For the use 
cases where they see Zaqar delivering a lot of value, requests don't need to be 
as fast as, say, ZMQ, but they do need something that isn’t horribly slow, 
either. They also want HTTP, multi-tenant, auth, durability, etc. The goal is 
to find a reasonable amount of latency given our constraints and also, 
obviously, be able to deliver all that at scale.

In any case, I’ve continue working through the test plan and will be publishing 
further test results shortly.

> graph latency versus number of concurrent active tenants

By tenants do you mean in the sense of OpenStack Tenants/Project-ID's or in  
the sense of “clients/workers”? For the latter case, the pilot tests I’ve done 
so far used multiple clients (though not graphed), but in the former case only 
one “project” was used.

From: Joe Gordon mailto:joe.gord...@gmail.com>>
Reply-To: OpenStack Dev 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, September 12, 2014 at 1:45 PM
To: OpenStack Dev 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [zaqar] Juno Performance Testing (Round 2)

If zaqar is like amazon SQS, then the latency for a single message and the 
throughput for a single tenant is not important. I wouldn't expect anyone who 
has latency sensitive work loads or needs massive throughput to use zaqar, as 
these people wouldn't use SQS either. The consistency of the latency (shouldn't 
change under load) and zaqar's ability to scale horizontally mater much more. 
What I would be great to see some other things benchmarked instead:

* graph latency versus number of concurrent active tenants
* graph latency versus message size
* How throughput scales as you scale up the number of assorted zaqar 
components. If one of the benefits of zaqar is its horizontal scalability, lets 
see it.
* How does this change with message batching?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] No one replying on tempest issue?Please share your experience

[Nikesh Kumar Mahalka]

Hi,
I deployed a juno devstack setup for a cinder volume driver.
I changed cinder.conf file and tempest.conf file for single backend and
restarted cinder services.

Now i ran tempest test as below:
/opt/stack/tempest/run_tempest.sh tempest.api.volume.test_volumes_snapshots

I am getting below output:
 Traceback (most recent call last):
  File "/opt/stack/tempest/tempest/api/volume/test_volumes_snapshots.py",
line 176, in test_volume_from_snapshot
snapshot = self.create_snapshot(self.volume_origin['id'])
  File "/opt/stack/tempest/tempest/api/volume/base.py", line 112, in
create_snapshot
'available')
  File
"/opt/stack/tempest/tempest/services/volume/json/snapshots_client.py", line
126, in wait_for_snapshot_status
value = self._get_snapshot_status(snapshot_id)
  File
"/opt/stack/tempest/tempest/services/volume/json/snapshots_client.py", line
99, in _get_snapshot_status
snapshot_id=snapshot_id)
SnapshotBuildErrorException: Snapshot 6b1eb319-33ef-4357-987a-58eb15549520
failed to build and is in ERROR status


Ran 14 tests in 712.023s

FAILED (failures=1)


Is any one faced such problem?


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

Re: [openstack-dev] Heat dependency visualisation

[Baohua Yang]

Nice work.
We discussed similar work weeks ago.
And the idea is to generate the dot file from a heat template, and then
draw figures from the dot file.

Even in the reversed direction, we can generate a heat template from a dot
based file.

Seems the community are eager to seem some heat template visualization tool.

On Mon, Sep 15, 2014 at 11:24 PM, Alexis Lee  wrote:

> For your amusement,
>
> https://github.com/lxsli/heat-viz
>
> This produces HTML which shows which StructuredDeployments (boxes)
> depends_on each other (bold arrows). It also shows the
> StructuredDeployments which StructuredConfigs (ovals) feed into (normal
> arrows).
>
> Both CFN + HOT format files should be supported. Thanks to Steve Baker
> for the code I nicked, ahem, reused from merge.py.
>
>
> Alexis
> --
> Nova Engineer, HP Cloud.  AKA lealexis, lxsli.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [neutron][security-groups] Neutron default security groups

[Baohua Yang]

Hi fawad
Yes, you're right.
I mentioned that not to answer the exact question, but think to drop some
line around it.
I do hope we can provide the capacity in the API layer, and let the
security group become more intuitive for users.

On Tue, Sep 16, 2014 at 10:45 PM, Fawad Khaliq  wrote:

> Hi Boahua,
>
> Thanks for sharing your thoughts. The issues seen are not related to
> "access", they are all related to API layer, so having ALLOW all etc does
> not fix/workaround the problems I mentioned.
>
> Please do share if you have something more to add.
>
> Fawad Khaliq
>
> On Tue, Sep 16, 2014 at 7:28 PM, Baohua Yang  wrote:
>
>> The similar problem has been discussed before.
>> There is no definitive answer, and currently seems we cannot simply
>> disable it since G version.
>> However, we can add some ALLOW rules to bypass the rules inside the
>> iptables chains.
>> Hope there be more flexibility to controller the security groups in the
>> future release.
>>
>>
>> On Tue, Sep 16, 2014 at 4:00 PM, Fawad Khaliq  wrote:
>>
>>> Folks,
>>>
>>> I have had discussions with some folks individually about this but I
>>> would like bring this to a broader audience.
>>>
>>> I have been playing with security groups and I see the notion of
>>> 'default' security group seems to create some nuisance/issues.
>>>
>>> There are list of things I have noticed so far:
>>>
>>>- Tenant for OpenStack services (normally named service/services)
>>>also ends up having default security group.
>>>- Port create operation ends up ensuring default security groups for
>>>all the tenants as this completely seems out of the context of the tenant
>>>the port operation takes place. (bug?)
>>>- Race conditions where if system is stressed and Neutron tries to
>>>ensure the first default security group and in parallel another call 
>>> comes,
>>>Neutron ends up trying to create multiple default security groups as the
>>>checks for duplicate groups are invalidated as soon as the call make 
>>> past a
>>>certain point in code.
>>>- API performance where orchestration chooses to spawn 1000 tenants
>>>and we see unnecessary overhead.
>>>- For plugins that use RESTful proxy backends require the backend
>>>systems to be up at the time neutron starts. [Minor, but affects some
>>>packaging solutions]
>>>
>>>
>>> To summarize, is there a way to disable default security groups?
>>> Expected answer is no; can we introduce a way to disable it? If that does
>>> not make sense, should we go ahead and fix the issues around it?
>>>
>>> I am sure some of you must have seen some of these issues and solved
>>> them already. Please do share how do tackle these issues?
>>>
>>> Thanks,
>>> Fawad Khaliq
>>>
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Best wishes!
>> Baohua
>>
>> ___
>> 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
>
>


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

[openstack-dev] [zaqar] Juno Performance Testing (Round 3)

[Kurt Griffiths]

Hi crew, as promised I’ve continued to work through the performance test
plan. I’ve started a wiki page for the next batch of tests and results:

https://wiki.openstack.org/wiki/Zaqar/Performance/PubSub/Redis

I am currently running the same tests again with 2x web heads, and will
update the wiki page with them when they finish (it takes a couple hours
to run each batch of tests). Then, I plan to add an additional Redis proc
and run everything again. After that, there are a few other things that we
could do, depending on what everyone wants to see next.

* Run all these tests for producer-consumer (task distribution) workloads
* Tune Redis, uWSGI and see if we can't improves latency, stdev, etc.
* Do a few runs with varying message sizes
* Continue increasing load and adding additional web heads
* Continue increasing load and adding additional redis procs
* Vary number of queues
* Vary number of project-ids
* Vary message batch sizes on post/get/claim

P.S. As mentioned in yesterday’s team meeting, we are starting to work
on integration with Rally as our long-term performance testing solution. I
encourage everyone to get involved and contribute to that project; your
contributions benefit not only Zaqar, but other OS projects as well who
are starting to use Rally to keep an eye on their own services’
performance. Kudos to Boris et al. for all their hard work there.

--Kurt

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

Re: [openstack-dev] [all] OpenStack bootstrapping hour - Friday Sept 19th - 3pm EST

[Kurt Taylor]

On Mon, Sep 15, 2014 at 7:04 PM, Rochelle.RochelleGrober
 wrote:
> +1000
> This is *great*.  Not only for newbies, but refreshers, learning different 
> approaches, putting faces to the signatures, etc.  And Mock best practices is 
> a brilliant starting place for developers.

Yes!

> I'd like to vote for a few others:
> - Development environment (different ones: PyCharms, Eclipse, IDE for Docs, 
> etc)
> - Tracking down a bug: log searching, back tracing, etc.
> - Fixing a bug:  From assigning in Launchpad through clone, fix, git review, 
> etc.
> - Writing an integrated test: setup, data recording/collection/clean tear 
> down.

 - Third-party CI testing and consuming Infrastructure services

> Sorry to have such a big wish list, but for people who learn experientially, 
> this will be immensely useful.
>
> --Rocky
>
> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
> Sent: Monday, September 15, 2014 3:56 PM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [all] OpenStack bootstrapping hour - Friday Sept 
> 19th - 3pm EST

>
> Assuming this turns out to be useful, we're thinking about lots of other
> deep dives. The intent is that these are indepth dives. We as a
> community have learned so many things over the last 4 years, but as
> OpenStack has gotten so large, being familiar with more than a narrow
> slice is hard. This is hopefully a part of the solution to address that.
> As I've told others, if nothing else, I'm looking forward to learning a
> ton in the process.
>
> Final links for the hangout + etherpad will be posted a little later in
> the week. Mostly wanted to make people aware it was coming.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net

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

Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

[Kuvaja, Erno]

> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
> Sent: 16 September 2014 15:56
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
> level
> guidelines
> 
> On 09/16/2014 10:16 AM, Kuvaja, Erno wrote:
> >> -Original Message-
> >> From: Sean Dague [mailto:s...@dague.net]
> >> Sent: 16 September 2014 12:40
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the
> >> log level guidelines
> >>
> >> On 09/16/2014 06:44 AM, Kuvaja, Erno wrote:
>  -Original Message-
>  From: Flavio Percoco [mailto:fla...@redhat.com]
>  Sent: 16 September 2014 10:08
>  To: openstack-dev@lists.openstack.org
>  Subject: Re: [openstack-dev] [glance][all] Help with interpreting
>  the log level guidelines
> 
>  On 09/16/2014 01:10 AM, Clint Byrum wrote:
> > Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
> >> On 09/15/2014 07:00 PM, Mark Washenberger wrote:
> >>> Hi there logging experts,
> >>>
> >>> We've recently had a little disagreement in the glance team
> >>> about the appropriate log levels for http requests that end up
> >>> failing due to user errors. An example would be a request to get
> >>> an image that does not exist, which results in a 404 Not Found
> request.
> >>>
> >>> On one hand, this event is an error, so DEBUG or INFO seem a
> >>> little too low. On the other hand, this error doesn't generally
> >>> require any kind of operator investigation or indicate any
> >>> actual failure of the service, so perhaps it is excessive to log
> >>> it at WARN or
> >> ERROR.
> >>>
> >>> Please provide feedback to help us resolve this dispute if you
> >>> feel you
>  can!
> >>
> >> My feeling is this is an INFO level. There is really nothing the
> >> admin should care about here.
> >
> > Agree with Sean. INFO are useful for investigations. WARN and
> > ERROR are cause for alarm.
> 
>  +1 this is what we do in Zaqar as well.
> 
> 
>  --
>  @flaper87
>  Flavio Percoco
> 
> >>>
> >>> I think the debate here does not only limit to 404s. By the logging
> >>> guidelines
> >> INFO level messages should not contain any error related messages but
> >> rather stuff like certain components starting/stopping, config info, etc.
> >> WARN should not be anything that gets the ops pulled out of bed and so
> on.
> >>>
> >>> Also all information that would be in interest of ops should be
> >>> logged
> >> INFO+.
> >>>
> >>> Now if we are logging user errors as WARN that makes the environment
> >> supportable even if the logging has been set as high as WARN cleaning
> >> the output a lot (as INFO shouldn't contain anything out of order
> anyways).
> >> Current situation is that logging at DEBUG level is the only option
> >> to get the needed information to actually run the services and get
> >> the data needed to support it as well. If we log user errors on INFO
> >> we get one step higher but we still have all that clutter like every
> >> single request in the logs and if that's the direction we want to go, we
> should revisit our logging guidelines as well.
> >>>
> >>> Thus my two euro cents goes towards WARN rather than debug and
> >> definitely not INFO.
> >>
> >> Part of it is how often you expect things to happen as well. Remember
> >> glanceclient opperates in the context of "other" processes. When it
> >> hits a 404 in Glance, it's not running in the glance context, it's
> >> running in the Nova context. Which means it needs to think of itself in
> that context.
> >>
> >> In that context we got the exception back from Glance, we know the
> >> image wasn't there. And we know whether or not that's a problem
> >> (glanceclient actually has no idea if it's a problem or not, we might
> >> be checking to make sure a thing isn't there, and success for us is the 
> >> 404).
> >>
> >> So actually, I'm back to Jay on this, it should be DEBUG. Nova (or
> >> whoever the caller is) can decide if the issue warents something larger
> than that.
> >>
> >> This is really the biggest issue with logging in the clients, people
> >> don't think about the context that they are running in.
> >>
> >>-Sean
> >>
> >> --
> >> Sean Dague
> >> http://dague.net
> >>
> >
> > Sean,
> >
> > I'm not sure if we were specific enough here. Not talking about client but
> the server logging. So how we should log events like client trying to change
> protected properties, access non existing image, create duplicate image IDs,
> etc.
> >
> > So for example if Nova is trying to access image that does not exist should
> we ignore it on Glance side or when the user tries to do something that does
> not succeed. In my point of view it makes life much easier if we have
> information where the request failed rather than just a wsgi return code o

[openstack-dev] [OSSN 0027] Neutron ARP cache poisoning vulnerability

[Nathan Kinder]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Neutron ARP cache poisoning vulnerability
- ---

### Summary ###
The Neutron firewall driver 'iptables_firewall' does not prevent ARP
cache poisoning, as this driver is currently only capable of MAC address
and IP address based anti-spoofing rules. However, ARP filtering
functionality is available in Nova Networking.

### Affected Services / Software ###
Neutron, Grizzly, Havana, Icehouse, Juno

### Discussion ###
In deployments using Nova Networking, the following anti-spoofing rules
are available through the libvirt network filter feature:

- - no-mac-spoofing
- - no-ip-spoofing
- - no-arp-spoofing
- - nova-no-nd-reflection
- - allow-dhcp-server

However, in deployments using Neutron, the 'iptables_firewall' driver
handles only MAC and IP anti-spoofing rules, leaving it vulnerable to
ARP poisoning and associated attacks. This feature disparity is a
security vulnerability, especially on networks shared with other tenants
or services.

ARP poisoning can lead to denial of service attacks as well as man in
the middle attacks that can compromise tenant separation on shared
networks. A malicious host on the shared network can send crafted ARP
packets designed to manipulate the ARP table of another host on the same
network. This manipulation can be engineered such that the malicious
host will receive traffic from the target host in place of the network
gateway. The malicious host has a number of options once traffic has
been intercepted. It may interrogate it for sensitive information,
manipulate if before passing it on to the real gateway, or drop it to
create a denial of service attack.

This can be demonstrated as follows:

- - Create a private network/subnet 10.0.0.0/24
- - Start 2 VMs attached to that private network:
  VM1 IP 10.0.0.3, VM2 IP 10.0.0.4
- - Log on to VM1 and install the ettercap tool (see references)
- - Launch command: 'ettercap -T -w dump -M ARP /10.0.0.4/ // output' on
  VM1. This will cause traffic from VM2 to pass through VM1 before it is
  forwarded on to the gateway.
- - Log on to VM2 and ping any valid internet site, the ping should
  succeed.
- - The ICMP traffic generated by VM2's ping will be visible on VM1.
- - Checking the ARP table on VM2 will show that the MAC address
  associated with the gateway is the MAC address of VM1.

This technique can be used to cause a denial of service attack if VM1
drops packets from VM2 rather than forwarding them on to the gateway.

### Recommended Actions ###
Pay close attention to networks where Neutron-based VLANs are in use.
Install appropriate IDS and traffic monitoring tools with a particular
focus on ARP packet monitoring.

The Neutron development team plan to address this issue in a future
version

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0027
Original LaunchPad Bug : https://bugs.launchpad.net/neutron/+bug/1274034
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
Ettercap: http://ettercap.github.io/ettercap
ARP Poisoning: http://en.wikipedia.org/wiki/ARP_spoofing
   http://www.watchguard.com/infocenter/editorial/135324.asp
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUGGHcAAoJEJa+6E7Ri+EVUpQIAJRVI3GjI/PpAz3fGGOGbIWo
YoYM25S8sprI45aWeJZq2t7d9fHK3vY1Tub6E2gOFqT1iHn1/X/kNBiiZ+D5BfTw
/hwRTR7VG0QousvpoR+OZgnDZ8Ub3OiW2WH5km4tHiV+pMBIW/ktux4yA/NsgG04
01iKXnVcVkTDI5LuPrICfFFWgnlEr18f+bfLqKeQz+TGaLtqBavZSniTcuuFct6h
Dn6bU8zjoGXoCq/5LTU/fxQnnHk3+vf5UoKP+SfEpCZeJs3Drzdc/W/YfhS01o1b
K2tZduPDAX2jKQxi3WYqpq+9Aae5U0AiRHZl08zozGuVhCcGezTkFG81y2c3QBE=
=A7BJ
-END PGP SIGNATURE-

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

Re: [openstack-dev] [OSSN 0020] Disassociating floating IPs does not terminate NAT connections with Neutron L3 agent

[Carl Baldwin]

Hi,

There is current work in review to use conntrack to terminate these
connections [1][2] much like you suggested.  I hope to get this in to
RC1 but it needs another iteration.

For Kilo, I'd like to explore stateless forwarding for floating ips.
Since conntrack is the root of the security issue in the first place,
the idea here is to eliminate it from the floating ip data path
altogether [3].  The patch I have up is really just a placeholder with
some notes on how it might be accomplished.  My hope is that this
stateless NAT for floating ips could ease some of the pressure that
I've observed on conntrack and increase performance.  It needs some
more investigation.

Carl

[1] https://bugs.launchpad.net/neutron/+bug/1334926
[2] https://review.openstack.org/#/c/103475
[3] https://review.openstack.org/#/c/121689/

On Mon, Sep 15, 2014 at 11:46 PM, Martinx - ジェームズ
 wrote:
> Hey stackers,
>
> Let me ask something about this... Why not use Linux Conntrack Table at each
> Tenant Namespace (L3 Router) to detect which connections were
> made/established over a Floating IP ?
>
> Like this, on the Neutron L3 Router:
>
> --
> apt-get install conntrack
>
> ip netns exec qrouter-09b72faa-a5ef-4a52-80b5-1dcbea23b1b6 conntrack -L |
> grep ESTABLISHED
>
> tcp  6 431998 ESTABLISHED src=192.168.3.5 dst=193.16.15.250 sport=36476
> dport=8333 src=193.16.15.250 dst=187.1.93.67 sport=8333 dport=36476
> [ASSURED] mark=0 use=1
> --
>
> Floating IP: 187.1.93.67
> Instance IP: 192.168.3.5
>
> http://conntrack-tools.netfilter.org/manual.html#conntrack
>
> 
>
> Or, as a workaround, right after removing the Floating IP, Neutron might
> insert a temporary firewall rule (for about 5~10 minutes?), to drop the
> connections of that previous "Floating IP + Instance IP couple"... It looks
> really ugly but, at least, it will make sure that nothing will pass right
> after removing a Floating IP... Effectively terminating (dropping) the NAT
> connections after disassociating a Floating IP... ;-)
>
> 
>
> Also, I think that NFTables can bring some light here... I truly believe
> that if OpenStack moves to a "NFTables_Driver", it will be much easier to:
> manage firewall rules, logging, counters, IDS/IPS, atomic replacements of
> rules, even NAT66... All under a single implementation... Maybe with some
> kind of "real-time connection monitoring"... I mean, with NFTables, it
> becomes easier to implement a firewall ruleset with a Intrusion Prevention
> System (IPS), take a look:
>
> https://home.regit.org/2014/02/suricata-and-nftables/
>
> So, if NFTables can make Suricata's life easier, why not give Suricata's
> power to Netutron L3 Router? Starting with a new NFTables_Driver... =)
>
> I'm not an expert on NFTables but, from what I'm seeing, it perfectly fits
> in OpenStack, in fact, NFTables will make OpenStack better.
>
> https://home.regit.org/2014/01/why-you-will-love-nftables/
>
> Best!
> Thiago
>
> On 15 September 2014 20:49, Nathan Kinder  wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Disassociating floating IPs does not terminate NAT connections with
>> Neutron L3 agent
>> - ---
>>
>> ### Summary ###
>> Every virtual instance is automatically assigned a private IP address.
>> You may optionally assign public IP addresses to instances. OpenStack
>> uses the term "floating IP" to refer to an IP address (typically
>> public) that can be dynamically added to a running virtual instance.
>> The Neutron L3 agent uses Network Address Translation (NAT) to assign
>> floating IPs to virtual instances. Floating IPs can be dynamically
>> released from a running virtual instance but any active connections are
>> not terminated with this release as expected when using the Neutron L3
>> agent.
>>
>> ### Affected Services / Software ###
>> Neutron, Icehouse, Havana, Grizzly, Folsom
>>
>> ### Discussion ###
>> When creating a virtual instance, a floating IP address is not
>> allocated by default. After a virtual instance is created, a user can
>> explicitly associate a floating IP address to that instance. Users can
>> create connections to the virtual instance using this floating IP
>> address. Also, this floating IP address can be disassociated from any
>> running instance without shutting that instance down.
>>
>> If a user initiates a connection using the floating IP address, this
>> connection remains alive and accessible even after the floating IP
>> address is released from that instance. This potentially violates
>> restrictive policies which are only being applied to new connections.
>> These policies are ignored for pre-existing connections and the virtual
>> instance remains accessible from the public network.
>>
>> This issue is only known to affect Neutron when using the L3 agent.
>> Nova networking is not affected.
>>
>> ### Recommended Actions ###
>> There is unfortunately no easy way to detect which connections were
>> made over a floating IP address from a virtual instance, as the NAT is
>> perf

Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

[Sean Dague]

On 09/16/2014 12:07 PM, Kuvaja, Erno wrote:
>> -Original Message-
>> From: Sean Dague [mailto:s...@dague.net]
>> Sent: 16 September 2014 15:56
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
>> level
>> guidelines
>>
>> On 09/16/2014 10:16 AM, Kuvaja, Erno wrote:
 -Original Message-
 From: Sean Dague [mailto:s...@dague.net]
 Sent: 16 September 2014 12:40
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [glance][all] Help with interpreting the
 log level guidelines

 On 09/16/2014 06:44 AM, Kuvaja, Erno wrote:
>> -Original Message-
>> From: Flavio Percoco [mailto:fla...@redhat.com]
>> Sent: 16 September 2014 10:08
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [glance][all] Help with interpreting
>> the log level guidelines
>>
>> On 09/16/2014 01:10 AM, Clint Byrum wrote:
>>> Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
 On 09/15/2014 07:00 PM, Mark Washenberger wrote:
> Hi there logging experts,
>
> We've recently had a little disagreement in the glance team
> about the appropriate log levels for http requests that end up
> failing due to user errors. An example would be a request to get
> an image that does not exist, which results in a 404 Not Found
>> request.
>
> On one hand, this event is an error, so DEBUG or INFO seem a
> little too low. On the other hand, this error doesn't generally
> require any kind of operator investigation or indicate any
> actual failure of the service, so perhaps it is excessive to log
> it at WARN or
 ERROR.
>
> Please provide feedback to help us resolve this dispute if you
> feel you
>> can!

 My feeling is this is an INFO level. There is really nothing the
 admin should care about here.
>>>
>>> Agree with Sean. INFO are useful for investigations. WARN and
>>> ERROR are cause for alarm.
>>
>> +1 this is what we do in Zaqar as well.
>>
>>
>> --
>> @flaper87
>> Flavio Percoco
>>
>
> I think the debate here does not only limit to 404s. By the logging
> guidelines
 INFO level messages should not contain any error related messages but
 rather stuff like certain components starting/stopping, config info, etc.
 WARN should not be anything that gets the ops pulled out of bed and so
>> on.
>
> Also all information that would be in interest of ops should be
> logged
 INFO+.
>
> Now if we are logging user errors as WARN that makes the environment
 supportable even if the logging has been set as high as WARN cleaning
 the output a lot (as INFO shouldn't contain anything out of order
>> anyways).
 Current situation is that logging at DEBUG level is the only option
 to get the needed information to actually run the services and get
 the data needed to support it as well. If we log user errors on INFO
 we get one step higher but we still have all that clutter like every
 single request in the logs and if that's the direction we want to go, we
>> should revisit our logging guidelines as well.
>
> Thus my two euro cents goes towards WARN rather than debug and
 definitely not INFO.

 Part of it is how often you expect things to happen as well. Remember
 glanceclient opperates in the context of "other" processes. When it
 hits a 404 in Glance, it's not running in the glance context, it's
 running in the Nova context. Which means it needs to think of itself in
>> that context.

 In that context we got the exception back from Glance, we know the
 image wasn't there. And we know whether or not that's a problem
 (glanceclient actually has no idea if it's a problem or not, we might
 be checking to make sure a thing isn't there, and success for us is the 
 404).

 So actually, I'm back to Jay on this, it should be DEBUG. Nova (or
 whoever the caller is) can decide if the issue warents something larger
>> than that.

 This is really the biggest issue with logging in the clients, people
 don't think about the context that they are running in.

-Sean

 --
 Sean Dague
 http://dague.net

>>>
>>> Sean,
>>>
>>> I'm not sure if we were specific enough here. Not talking about client but
>> the server logging. So how we should log events like client trying to change
>> protected properties, access non existing image, create duplicate image IDs,
>> etc.
>>>
>>> So for example if Nova is trying to access image that does not exist should
>> we ignore it on Glance side or when the user tries to do something that does
>> not succeed. In my point of view it makes life much easier if we have
>> informatio

Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

[Kuvaja, Erno]

> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
> Sent: 16 September 2014 17:31
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
> level
> guidelines
> 
> On 09/16/2014 12:07 PM, Kuvaja, Erno wrote:
> >> -Original Message-
> >> From: Sean Dague [mailto:s...@dague.net]
> >> Sent: 16 September 2014 15:56
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the
> >> log level guidelines
> >>
> >> On 09/16/2014 10:16 AM, Kuvaja, Erno wrote:
>  -Original Message-
>  From: Sean Dague [mailto:s...@dague.net]
>  Sent: 16 September 2014 12:40
>  To: openstack-dev@lists.openstack.org
>  Subject: Re: [openstack-dev] [glance][all] Help with interpreting
>  the log level guidelines
> 
>  On 09/16/2014 06:44 AM, Kuvaja, Erno wrote:
> >> -Original Message-
> >> From: Flavio Percoco [mailto:fla...@redhat.com]
> >> Sent: 16 September 2014 10:08
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [glance][all] Help with interpreting
> >> the log level guidelines
> >>
> >> On 09/16/2014 01:10 AM, Clint Byrum wrote:
> >>> Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
>  On 09/15/2014 07:00 PM, Mark Washenberger wrote:
> > Hi there logging experts,
> >
> > We've recently had a little disagreement in the glance team
> > about the appropriate log levels for http requests that end up
> > failing due to user errors. An example would be a request to
> > get an image that does not exist, which results in a 404 Not
> > Found
> >> request.
> >
> > On one hand, this event is an error, so DEBUG or INFO seem a
> > little too low. On the other hand, this error doesn't
> > generally require any kind of operator investigation or
> > indicate any actual failure of the service, so perhaps it is
> > excessive to log it at WARN or
>  ERROR.
> >
> > Please provide feedback to help us resolve this dispute if you
> > feel you
> >> can!
> 
>  My feeling is this is an INFO level. There is really nothing
>  the admin should care about here.
> >>>
> >>> Agree with Sean. INFO are useful for investigations. WARN and
> >>> ERROR are cause for alarm.
> >>
> >> +1 this is what we do in Zaqar as well.
> >>
> >>
> >> --
> >> @flaper87
> >> Flavio Percoco
> >>
> >
> > I think the debate here does not only limit to 404s. By the
> > logging guidelines
>  INFO level messages should not contain any error related messages
>  but rather stuff like certain components starting/stopping, config info,
> etc.
>  WARN should not be anything that gets the ops pulled out of bed and
>  so
> >> on.
> >
> > Also all information that would be in interest of ops should be
> > logged
>  INFO+.
> >
> > Now if we are logging user errors as WARN that makes the
> > environment
>  supportable even if the logging has been set as high as WARN
>  cleaning the output a lot (as INFO shouldn't contain anything out
>  of order
> >> anyways).
>  Current situation is that logging at DEBUG level is the only option
>  to get the needed information to actually run the services and get
>  the data needed to support it as well. If we log user errors on
>  INFO we get one step higher but we still have all that clutter like
>  every single request in the logs and if that's the direction we
>  want to go, we
> >> should revisit our logging guidelines as well.
> >
> > Thus my two euro cents goes towards WARN rather than debug and
>  definitely not INFO.
> 
>  Part of it is how often you expect things to happen as well.
>  Remember glanceclient opperates in the context of "other"
>  processes. When it hits a 404 in Glance, it's not running in the
>  glance context, it's running in the Nova context. Which means it
>  needs to think of itself in
> >> that context.
> 
>  In that context we got the exception back from Glance, we know the
>  image wasn't there. And we know whether or not that's a problem
>  (glanceclient actually has no idea if it's a problem or not, we
>  might be checking to make sure a thing isn't there, and success for us is
> the 404).
> 
>  So actually, I'm back to Jay on this, it should be DEBUG. Nova (or
>  whoever the caller is) can decide if the issue warents something
>  larger
> >> than that.
> 
>  This is really the biggest issue with logging in the clients,
>  people don't think about the context that they are running in.
> 
>   -Sean
> 
>  --
>  Sean Dague
>  http://dague.net
> 
> >>>

Re: [openstack-dev] [all] [clients] [keystone] lack of retrying tokens leads to overall OpenStack fragility

[Adam Young]

On 09/15/2014 08:28 PM, Nathan Kinder wrote:


On 09/12/2014 12:46 AM, Angus Lees wrote:

On Thu, 11 Sep 2014 03:21:52 PM Steven Hardy wrote:

On Wed, Sep 10, 2014 at 08:46:45PM -0400, Jamie Lennox wrote:

For service to service communication there are two types.
1) using the user's token like nova->cinder. If this token expires there
is really nothing that nova can do except raise 401 and make the client
do it again. 2) using a service user like nova->neutron. This should
allow automatic reauthentication and will be fixed/standardied by
sessions.

(1) is the problem I'm trying to solve in bug #1306294, and (for Heat at
least) there seems to be two solutions, neither of which I particularly
like:

- Require username/password to be passed into the service (something we've
   been trying to banish via migrating to trusts for deferred
   authentication)
- Create a trust, and impersonate the user for the duration of the request,
   or after the token expires until it is completed, using the service user
   credentials and the trust_id.

It's the second one which I'm deliberating over - technically it will work,
and we create the trust anyway (e.g for later use to do autoscaling etc),
but can anyone from the keystone team comment on the legitimacy of the
approach?

Intuitively it seems wrong, but I can't see any other way if we want to
support token-only auth and cope with folks doing stuff which takes 2 hours
with a 1 hour token expiry?

A possible 3rd option is some sort of longer lived, but limited scope
"capability token".

The user would create a capability token that represents "anyone possessing
this token is (eg) allowed to write to swift as $user".  The token could be
created by keystone as a trusted 3rd party or by swift (doesn't matter which),
in response to a request authenticated as $user.  The client then includes
that token in the request *to cinder*, so cinder can pass it back to swift
when doing the writes.
This capability token would be of much longer duration (long enough to
complete the cinder->swift task), which is ok because it is of a much more
limited scope (ideally as fine grained as we can bother implementing).

With UUID tokens, it would even be possible to implement a "one-time
use" sort of token.  Since Keystone needs to be asked to validate a UUID
token, the token could be invalidated by Keystone after the first
verification.  Since the token is limited based off of number of times
of usage, there should be less concerns about a long validity period
(though it would make sense to use something sane still).  This approach
wouldn't be possible with PKI tokens since Keystone is not in the
validation path.

Your idea of passing the "capability token" in the request would work
well with this, as the token only needs to be extracted and used once
instead of being passed from service to service and validated at each
hop (user>cinder->swift in your example).

The idea would be to leave normal tokens with a smaller validity period
(like the current default of an hour), but also allow one-time use
tokens to be requested.


It is dumb to make service get a token just to hand the token back to 
Keystone.


Guang Yee has pushed for years to get a capability into Keystone where 
certain API calls did not require a token, but would instead the 
permission would be based on whatever the users capabilites were at the 
time.


The problem is that "Admin" in the default policy (and hardcoded in V2) 
is definded to mean "User has the role admin on anything"  which is, of 
course, suboptimal (to say the least).


So validating a Token should not require a token.  We could add to the 
request some standard Stanza for saying "Here is the project/domain that 
I want to do this with"  so that we can atleast Keep Keystone's current 
behavior somewhat sane








(I like this option)


A 4th option is to have much longer lived tokens everywhere (long enough for
this backup), but the user is able to expire it early via keystone whenever
they feel it might be compromised (aiui this is exactly how things work now -
we just need to increase the timeout).  Greater exposure to replay attacks,
but if detected they can still be invalidated quickly.

(This is the easiest option, it's basically just formalising what the
operators are already doing)


A 5th option (wow) is to have the end user/client repeatedly push in fresh
tokens during long-running operations (and heat is the uber-example since it
basically wants to impersonate the user forever).  Those tokens would then
need to be refreshed all the way down the stack for any outstanding operations
that might need the new token.

(This or the 4th option seems ugly but unavoidable for "forever" services like
heat.  There has to be some way to invalidate their access if they go rogue,
either by time (and thus needs a refresh mechanism) or by invalidation-via-
keystone (which implies the token lasts forever unless invalidated))

I think Keystone trusts are better

Re: [openstack-dev] No one replying on tempest issue?Please share your experience

[Jay Pipes]

On 09/16/2014 11:10 AM, Nikesh Kumar Mahalka wrote:

Hi,
I deployed a juno devstack setup for a cinder volume driver.
I changed cinder.conf file and tempest.conf file for single backend and
restarted cinder services.

Now i ran tempest test as below:
/opt/stack/tempest/run_tempest.sh tempest.api.volume.test_volumes_snapshots

I am getting below output:
  Traceback (most recent call last):
   File
"/opt/stack/tempest/tempest/api/volume/test_volumes_snapshots.py", line
176, in test_volume_from_snapshot
 snapshot = self.create_snapshot(self.volume_origin['id'])
   File "/opt/stack/tempest/tempest/api/volume/base.py", line 112, in
create_snapshot
 'available')
   File
"/opt/stack/tempest/tempest/services/volume/json/snapshots_client.py",
line 126, in wait_for_snapshot_status
 value = self._get_snapshot_status(snapshot_id)
   File
"/opt/stack/tempest/tempest/services/volume/json/snapshots_client.py",
line 99, in _get_snapshot_status
 snapshot_id=snapshot_id)
SnapshotBuildErrorException: Snapshot
6b1eb319-33ef-4357-987a-58eb15549520 failed to build and is in ERROR status


Ran 14 tests in 712.023s

FAILED (failures=1)


Is any one faced such problem?


Look in the nova-compute and cinder-volume log files for errors.

Best,
-jay


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

Re: [openstack-dev] [zaqar] Juno Performance Testing (Round 3)

[Jay Pipes]

On 09/16/2014 11:23 AM, Kurt Griffiths wrote:

Hi crew, as promised I’ve continued to work through the performance test
plan. I’ve started a wiki page for the next batch of tests and results:

https://wiki.openstack.org/wiki/Zaqar/Performance/PubSub/Redis

I am currently running the same tests again with 2x web heads, and will
update the wiki page with them when they finish (it takes a couple hours
to run each batch of tests). Then, I plan to add an additional Redis proc
and run everything again. After that, there are a few other things that we
could do, depending on what everyone wants to see next.

* Run all these tests for producer-consumer (task distribution) workloads
* Tune Redis, uWSGI and see if we can't improves latency, stdev, etc.
* Do a few runs with varying message sizes
* Continue increasing load and adding additional web heads
* Continue increasing load and adding additional redis procs
* Vary number of queues
* Vary number of project-ids
* Vary message batch sizes on post/get/claim


Don't forget my request to identify the effect of keepalive settings in 
uWSGI :)


Thanks!
-jay


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

Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

[Jay Pipes]

On 09/16/2014 10:16 AM, Kuvaja, Erno wrote:
> In my point of view it makes life

much easier if we have information where the request failed


The request did not fail. The HTTP request succeeded and Glance returned 
a 404 Not Found. If the caller was expecting an image to be there, but 
it wasn't, then it can log the 404 in whatever log level is most 
appropriate.


The point is that DEBUG log level is appropriate for the glanceclient 
logs, since the glanceclient doesn't know if a 404 is something to be 
concerned about or not. To glanceclient, the call succeeded. 
Communication with the Glance API server worked, authentication worked, 
and the server returned successfully stating that the image does not exist.


-jay

> rather

than just a wsgi return code or having to run the system on DEBUG
logging to get that information.

- Erno

___ 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] [Neutron] Allowing specifying object ID in create_* API

[Eugene Nikanorov]

Hi neutrons,

We've been discussing various ways of doing cloud upgrades.

One of the safe and viable solutions seems to be moving existing resources
to a new cloud deployed with new version of openstack.
By saying 'moving' I mean replication of all resources and wiring
everything together in a new cloud.

This solution, while having its obvious drawbacks, is relatively simple,
works through cloud public API and also allows users to move back to their
existing working cloud at any time.

One of the concerns of this approach seems to be the issue with client-side
automatization. E.g. everything that relies on existing cloud data.

Technically speaking, there is no way to fully replicate objects, because
the API of different components, including Neutron, doesn't allow IDs to be
provided at creation time.

Surprisingly, it's purely API limitation; db code support ID being passed
from the API.

So my question is - is this API limitation really critical?
I know getting rid of it will require to take care of some additional
things like DBDuplicateErrors, but is there other reasons to keep it?

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

Re: [openstack-dev] [Cinder][Nova][Oslo] Moving Brick out of Cinder

[Ivan Kolodyazhny]

Hi Stackers!

I'm working on moving Brick out of Cinder for K release.

There're a lot of open questions for now:

   - Should we move it to oslo or somewhere on stackforge?
   - Better architecture of it to fit all Cinder and Nova requirements
   - etc.

Before starting discussion, I've created some proof-of-concept to try it. I
moved Brick to some lib named oslo.storage for testing only. It's only one
of the possible solution to start work on it.

All sources are aviable on GitHub [1], [2].

[1] - I'm not sure that this place and name is good for it, it's just a PoC.

[1] https://github.com/e0ne/oslo.storage
[2] https://github.com/e0ne/cinder/tree/brick - some tests still failed.

Regards,
Ivan Kolodyazhny

On Mon, Sep 8, 2014 at 4:35 PM, Ivan Kolodyazhny  wrote:

> Hi All!
>
> I would to start moving Cinder Brick [1] to oslo as was described on
> Cinder mid-cycle meetup [2]. Unfortunately I missed meetup so I want be
> sure that nobody started it and we are on the same page.
>
> According to the Juno 3 release, there was not enough time to discuss [3]
> on the latest Cinder weekly meeting and I would like to get some feedback
> from the all OpenStack community, so I propose to start this discussion on
> mailing list for all projects.
>
> I anybody didn't started it and it is useful at least for both Nova and
> Cinder I would to start this work according oslo guidelines [4] and
> creating needed blueprints to make it finished until Kilo 1 is over.
>
>
>
> [1] https://wiki.openstack.org/wiki/CinderBrick
> [2] https://etherpad.openstack.org/p/cinder-meetup-summer-2014
> [3]
> http://lists.openstack.org/pipermail/openstack-dev/2014-September/044608.html
> [4] https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary
>
> Regards,
> Ivan Kolodyazhny.
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

[Devananda van der Veen]

On Sep 15, 2014 8:20 AM, "James Slagle"  wrote:
>
> On Mon, Sep 15, 2014 at 7:44 AM, Steven Hardy  wrote:
> > All,
> >
> > Starting this thread as a follow-up to a strongly negative reaction by the
> > Ironic PTL to my patches[1] adding initial Heat->Ironic integration, and
> > subsequent very detailed justification and discussion of why they may be
> > useful in this spec[2].
> >
> > Back in Atlanta, I had some discussions with folks interesting in making
> > "ready state"[3] preparation of bare-metal resources possible when
> > deploying bare-metal nodes via TripleO/Heat/Ironic.
>
> After a cursory reading of the references, it seems there's a couple of 
> issues:
> - are the features to move hardware to a "ready-state" even going to
> be in Ironic proper, whether that means in ironic at all or just in
> contrib.
> - assuming some of the features are there, should Heat have any Ironic
> resources given that Ironic's API is admin-only.
>
> >
> > The initial assumption is that there is some discovery step (either
> > automatic or static generation of a manifest of nodes), that can be input
> > to either Ironic or Heat.
>
> I think it makes a lot of sense to use Heat to do the bulk
> registration of nodes via Ironic. I understand the argument that the
> Ironic API should be "admin-only" a little bit for the non-TripleO
> case, but for TripleO, we only have admins interfacing with the
> Undercloud. The user of a TripleO undercloud is the deployer/operator
> and in some scenarios this may not be the undercloud admin. So,
> talking about TripleO, I don't really buy that the Ironic API is
> admin-only.
>

When I say the ironic API is admin only, I'm speaking to the required
permissions for accessing it. One must be authenticated with keystone
with the "admin" privilege. Borrowing from the ops guide:

" An administrative super user, which has full permissions across all
projects and should be used with great care."

I'm not sure how TripleO is dividing operator and admin in the
undercloud - so I just want to be clear on what you mean when you say
"may not be the undercloud admin". Simply put, to use Ironic in the
undercloud, you must have "admin" privileges in the undercloud -- or
you need to disable Ironic's auth entirely.

> Therefore, why not have some declarative Heat resources for things
> like Ironic nodes, that the deployer can make use of in a Heat
> template to do bulk node registration?
>
> The alternative listed in the spec:
>
> "Don’t implement the resources and rely on scripts which directly
> interact with the Ironic API, prior to any orchestration via Heat."
>
> would just be a bit silly IMO. That goes against one of the main
> drivers of TripleO, which is to use OpenStack wherever possible. Why
> go off and write some other thing that is going to parse a
> json/yaml/csv of nodes and orchestrate a bunch of Ironic api calls?
> Why would it be ok for that other thing to use Ironic's "admin-only"
> API yet claim it's not ok for Heat on the undercloud to do so?
>

Heat has a mission. It's not just a hammer with which to parse
json/yaml/etc into a for loop and throw text at an API. From the wiki:

"... to create a human- and machine-accessible service for managing
the entire lifecycle of infrastructure and applications within
OpenStack clouds."

The resources ironic exposes are not "within OpenStack clouds." They
are _underneath_ the cloud. Actually, they're underneath the
undercloud.

Configuring a node in Ironic is akin to configuring the SAN from which
Cinder provisions volumes. That is clearly a thing which an operator
needs to do -- but are you suggesting that, if my SAN has a REST API,
I should use Heat to configure it?

This is the crux of my objection. I would be surprised if your answer
is "yes, heat should be used to configure my SAN". If you're wondering
why I used that example, it's because folks already asked me if they
can use Ironic to deploy their SAN's management software, perform
firmware upgrades on it, and so on. (I said "no, not today" but it's
an interesting scope discussion for Ironic).

> > Following discovery, but before an undercloud deploying OpenStack onto the
> > nodes, there are a few steps which may be desired, to get the hardware into
> > a state where it's ready and fully optimized for the subsequent deployment:
> >

As others have said already, based on discussions during the Juno
cycle, discovery has not landed, and most of us agree that it is out
of scope.

> > - Updating and aligning firmware to meet requirements of qualification or
> >   site policy
> > - Optimization of BIOS configuration to match workloads the node is
> >   expected to run
> > - Management of machine-local storage, e.g configuring local RAID for
> >   optimal resilience or performance.
> >

These steps are desirable not just the first time a node is added to
ironic, but often subsequently, either between every deployment, or
when the operator changes the role/function that hardware fulfills, or
i

Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

[Devananda van der Veen]

On Mon, Sep 15, 2014 at 9:50 AM, Clint Byrum  wrote:
> Excerpts from Steven Hardy's message of 2014-09-15 04:44:24 -0700:
>>
>>
> First, Ironic is hidden under Nova as far as TripleO is concerned. So
> mucking with the servers underneath Nova during deployment is a difficult
> proposition. Would I look up the Ironic node ID of the nova server,
> and then optimize it for the workload after the workload arrived? Why
> wouldn't I just do that optimization before the deployment?
>

Except, using Ironic to configure a node's hardware probably requires
rebooting that node -- and thus interrupting the workload that was
just deployed onto it, and possibly (if you're rebuilding a RAID)
destroying that instance. Clearly this doesn't make sense.

>> What is required is some tool to take a text definition of the required
>> configuration, turn it into a correctly sequenced series of API calls to
>> Ironic, expose any data associated with those API calls, and declare
>> success or failure on completion.  This is what Heat does.
>>
>
> I'd rather see Ironic define or adopt a narrow scope document format
> that it can consume for bulk loading. Heat is extremely generic, and thus
> carries a ton of complexity for what is probably doable with a CSV file.

Yup. See my previous comments. Heat is not a generic "manipulate this
text file" hammer. That's Perl.

-Devananda

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

Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

[Devananda van der Veen]

On Mon, Sep 15, 2014 at 10:51 AM, Jay Faulkner  wrote:
> Steven,
>
> It's important to note that two of the blueprints you reference:
>
> https://blueprints.launchpad.net/ironic/+spec/drac-raid-mgmt
> https://blueprints.launchpad.net/ironic/+spec/drac-hw-discovery
>
> are both very unlikely to land in Ironic -- these are configuration and 
> discovery pieces that best fit inside a operator-deployed CMDB, rather than 
> Ironic trying to extend its scope significantly to include these type of 
> functions. I expect the scoping or Ironic with regards to hardware 
> discovery/interrogation as well as configuration of hardware (like I will 
> outline below) to be hot topics in Ironic design summit sessions at Paris.
>
> A good way of looking at it is that Ironic is responsible for hardware *at 
> provision time*. Registering the nodes in Ironic, as well as hardware 
> settings/maintenance/etc while a workload is provisioned is left to the 
> operators' CMDB.
>
> This means what Ironic *can* do is modify the configuration of a node at 
> provision time based on information passed down the provisioning pipeline. 
> For instance, if you wanted to configure certain firmware pieces at provision 
> time, you could do something like this:
>
> Nova flavor sets capability:vm_hypervisor in the flavor that maps to the 
> Ironic node. This would map to an Ironic driver that exposes vm_hypervisor as 
> a capability, and upon seeing capability:vm_hypervisor has been requested, 
> could then configure the firmware/BIOS of the machine to 'hypervisor 
> friendly' settings, such as VT bit on and Turbo mode off. You could map 
> multiple different combinations of capabilities as different Ironic flavors, 
> and have them all represent different configurations of the same pool of 
> nodes. So, you end up with two categories of abilities: inherent abilities of 
> the node (such as amount of RAM or CPU installed), and configurable abilities 
> (i.e. things than can be turned on/off at provision time on demand) -- or 
> perhaps, in the future, even things like RAM and CPU will be dynamically 
> provisioned into nodes at provision time.
>


Thanks for the explanation, Jay.

Steven, in response to your question "[what would] just do that
optimization before the deployment?" -- see Jay's example above. This
path has grown out of several discussions we've had over the last two
years, and is closer aligned to what I *thought* TripleO wanted back
when I was more involved in that project.

To paraphrase: Ironic exposes "capabilities" to Nova, and the Nova
scheduler can pick a node based on which capability is requested in
the flavor definition. We don't yet, but are planning to, support
on-demand customization of nodes based on the requested capabilities.
Toggling the VT bit is a canonical example of this -- we should be
able to dynamically update a node's firmware configuration to satisfy
both virtualization and non-virtualization workloads. That's going to
be expressed via Nova flavors and communicated at provision time by
Nova to Ironic. Eventually, I'd like to see everything in that space
(except perhaps RAID topology, since that actually takes a lot of time
to change).

-Devananad

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

Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

[Devananda van der Veen]

On Mon, Sep 15, 2014 at 9:00 AM, Steven Hardy  wrote:
> For example, today, I've been looking at the steps required for driving
> autodiscovery:
>
> https://etherpad.openstack.org/p/Ironic-PoCDiscovery-Juno
>
> Driving this process looks a lot like application orchestration:
>
> 1. Take some input (IPMI credentials and MAC addresses)
> 2. Maybe build an image and ramdisk(could drop credentials in)
> 3. Interact with the Ironic API to register nodes in maintenance mode
> 4. Boot the nodes, monitor state, wait for a signal back containing some
>data obtained during discovery (same as WaitConditions or
>SoftwareDeployment resources in Heat..)
> 5. Shutdown the nodes and mark them ready for use by nova
>

My apologies if the following sounds snarky -- but I think there are a
few misconceptions that need to be cleared up about how and when one
might use Ironic. I also disagree that 1..5 looks like application
orchestration. Step 4 is a workflow, which I'll go into in a bit, but
this doesn't look at all like describing or launching an application
to me.


Step 1 is just parse a text file.

Step 2 should be a prerequisite to doing -anything- with Ironic. Those
images need to be built and loaded in Glance, and the image UUID(s)
need to be set on each Node in Ironic (or on the Nova flavor, if going
that route) after enrollment. Sure, Heat can express this
declaratively (ironic.node.driver_info must contain key:deploy_kernel
with value:), but are you suggesting that Heat build the images,
or just take the UUIDs as input?

Step 3 is, again, just parse a text file

I'm going to make an assumption here [*], because I think step 4 is
misleading. You shouldn't "boot a node" using Ironic -- you do that
through Nova. And you _dont_ get to specify which node you're booting.
You ask Nova to provision an _instance_ on a _flavor_ and it picks an
available node from the pool of nodes that match the request.

Step 5 is a prerequisite for step 4 -- you can't boot a node that is
in maintenance mode, and if the node is not in maintenance mode, Nova
exposes it to clients. That is in fact how you'd boot it in step 4.

[*] I'm assuming you are not planning to re-implement the Nova
"ironic" driver in Heat. Booting a node with Ironic is not just a
matter of making one or two API calls. It's a declarative
transformation involving multiple changes in Ironic's API, and
presumably also some calls to Neutron if you want network access
to/from your node, and polling the resource to see when its state
converges on the requested state. Actually that sounds like exactly
the sort of thing that Heat could drive. But all this is already
implemented in Nova.


-Devananda

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

Re: [openstack-dev] [Nova] What's holding nova development back?

[Joe Gordon]

On Sep 15, 2014 8:31 PM, "Jay Pipes"  wrote:
>
> On 09/15/2014 08:07 PM, Jeremy Stanley wrote:
>>
>> On 2014-09-15 17:59:10 -0400 (-0400), Jay Pipes wrote:
>> [...]
>>>
>>> Sometimes it's pretty hard to determine whether something in the
>>> E-R check page is due to something in the infra scripts, some
>>> transient issue in the upstream CI platform (or part of it), or
>>> actually a bug in one or more of the OpenStack projects.
>>
>> [...]
>>
>> Sounds like an NP-complete problem, but if you manage to solve it
>> let me know and I'll turn it into the first line of triage for Infra
>> bugs. ;)
>
>
> LOL, thanks for making me take the last hour reading Wikipedia pages
about computational complexity theory! :P
>
> No, in all seriousness, I wasn't actually asking anyone to boil the
ocean, mathematically. I think doing a couple things just making the
categorization more obvious (a UI thing, really) and doing some (hopefully
simple?) inspection of some control group of patches that we know do not
introduce any code changes themselves and comparing to another group of
patches that we know *do* introduce code changes to Nova, and then seeing
if there are a set of E-R issues that consistently appear in *both* groups.
That set of E-R issues has a higher likelihood of not being due to Nova,
right?

We use launchpad's affected projects listings on the elastic recheck page
to say what may be causing the bug.  Tagging projects to bugs is a manual
process, but one that works pretty well.

UI: The elastic recheck UI definitely could use some improvements. I am
very poor at writing UIs, so patches welcome!

>
> OK, so perhaps it's not the most scientific or well-thought out plan, but
hey, it's a spark for thought... ;)
>
> 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

[openstack-dev] [all] Release 2.3.8 release of python-neutronclient

[Kyle Mestery]

I'm please to announce the latest release of python-neutronclient,
version 2.3.8. This will be the last release before the Juno release
of OpenStack. The main change we were waiting for was the CLI changes
for L3 HA. In addition, the following changes are a part of this
release:

19527c4 Narrow down except clause
fb83043 Correct Content-Type/Accept management in HTTPClient/SessionClient
b81d650 Allow to specify policy by name in firewall-update
69e7ffc Silence iso8601 debug messages in verbose mode
60e8961 Stop using intersphinx
b6faa32 Updated from global requirements
8a30a0c Replace utils.dumps with jsonutils.dumps
9660c7d Add L3 HA / VRRP support to CLI
a844d19 Improve help strings
e17e81d Isolate tests from HTTP_PROXY, OS_REGION_NAME env vars
54a2d3d Leverage openstack.common.jsonutils
34e3341 Clean-up shell run and run_subcommand methods
48da722 Unify doc-strings format
a71611f Small improve of str2dict function
d9de6b9 neutronclient shows low-level logs in console screen

The release can be found on PyPi here:

https://pypi.python.org/pypi/python-neutronclient

Please report any bugs on the projects Launchpad page here:

https://launchpad.net/python-neutronclient

Thanks!
Kyle

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

Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

[Kuvaja, Erno]

> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: 16 September 2014 18:10
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
> level
> guidelines
> 
> On 09/16/2014 10:16 AM, Kuvaja, Erno wrote:
>  > In my point of view it makes life
> > much easier if we have information where the request failed
> 
> The request did not fail. The HTTP request succeeded and Glance returned a
> 404 Not Found. If the caller was expecting an image to be there, but it 
> wasn't,
> then it can log the 404 in whatever log level is most appropriate.
> 
> The point is that DEBUG log level is appropriate for the glanceclient logs, 
> since
> the glanceclient doesn't know if a 404 is something to be concerned about or
> not. To glanceclient, the call succeeded.
> Communication with the Glance API server worked, authentication worked,
> and the server returned successfully stating that the image does not exist.
> 
> -jay
> 

Still this is not about glanceclient logging. On that discussion I fully agree 
that less is more what comes to logging.

When we try to update an image in the glance code and that fails because the 
image is not there, I do not care where that gets stated to the end user. What 
I care about is that when the user starts asking what happened, I don't get 
called up from the bed because the ops responsible for the service have no 
idea. I also care that the ops does not need to run through million lines of 
debugging logs just because they would not get the info without. The reality is 
after all that even in developer point of view the request did not fail, user 
point of view it did.

We must keep in mind that somewhere out there is bunch of people using these 
services outside of devstack who does not know the code and how it behaves 
internally. They see the log messages if any and need to try to get the answers 
for the people who knows even less about the internals.

- Erno

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

Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

[Devananda van der Veen]

On Mon, Sep 15, 2014 at 1:08 PM, Steven Hardy  wrote:
> On Mon, Sep 15, 2014 at 05:51:43PM +, Jay Faulkner wrote:
>> Steven,
>>
>> It's important to note that two of the blueprints you reference:
>>
>> https://blueprints.launchpad.net/ironic/+spec/drac-raid-mgmt
>> https://blueprints.launchpad.net/ironic/+spec/drac-hw-discovery
>>
>> are both very unlikely to land in Ironic -- these are configuration and 
>> discovery pieces that best fit inside a operator-deployed CMDB, rather than 
>> Ironic trying to extend its scope significantly to include these type of 
>> functions. I expect the scoping or Ironic with regards to hardware 
>> discovery/interrogation as well as configuration of hardware (like I will 
>> outline below) to be hot topics in Ironic design summit sessions at Paris.
>
> Hmm, okay - not sure I really get how a CMDB is going to help you configure
> your RAID arrays in an automated way?
>
> Or are you subscribing to the legacy datacentre model where a sysadmin
> configures a bunch of boxes via whatever method, puts their details into
> the CMDB, then feeds those details into Ironic?
>
>> A good way of looking at it is that Ironic is responsible for hardware *at 
>> provision time*. Registering the nodes in Ironic, as well as hardware 
>> settings/maintenance/etc while a workload is provisioned is left to the 
>> operators' CMDB.
>>
>> This means what Ironic *can* do is modify the configuration of a node at 
>> provision time based on information passed down the provisioning pipeline. 
>> For instance, if you wanted to configure certain firmware pieces at 
>> provision time, you could do something like this:
>>
>> Nova flavor sets capability:vm_hypervisor in the flavor that maps to the 
>> Ironic node. This would map to an Ironic driver that exposes vm_hypervisor 
>> as a capability, and upon seeing capability:vm_hypervisor has been 
>> requested, could then configure the firmware/BIOS of the machine to 
>> 'hypervisor friendly' settings, such as VT bit on and Turbo mode off. You 
>> could map multiple different combinations of capabilities as different 
>> Ironic flavors, and have them all represent different configurations of the 
>> same pool of nodes. So, you end up with two categories of abilities: 
>> inherent abilities of the node (such as amount of RAM or CPU installed), and 
>> configurable abilities (i.e. things than can be turned on/off at provision 
>> time on demand) -- or perhaps, in the future, even things like RAM and CPU 
>> will be dynamically provisioned into nodes at provision time.
>
> So you advocate pushing all the vendor-specific stuff down into various
> Ironic drivers,

... and providing a common abstraction / representation for it. Yes.
That is, after all, what OpenStack has done for compute, storage, and
networking, and what Ironic has set out to do for hardware
provisioning from the beginning.

>  is any of what you describe above possible today?

No. We had other priorities in Juno. It's probably one of the things
we'll prioritize in Kilo.

If you can't wait for Ironic to implement a common abstraction layer
for such functionality, then by all means, implement vendor-native
templates in Heat, but keep in mind that our goal is to move any
functionality which multiple vendors provide into the common API over
time. Vendor passthru is there as an early proving ground for vendors
to add their unique capabilities while we work towards cross-vendor
standards.

-D

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

[openstack-dev] [Neutron][Infra] Moving DVR experimental job to the check queue

[Carl Baldwin]

Hi,

Neutron would like to move the distributed virtual router (DVR)
tempest job, currently in the experimental queue, to the check queue
[1].  It will still be non-voting for the time being.  Could infra
have a look?  We feel that running this on all Neutron patches is
important to maintain the stability of DVR through release.

Carl

[1] https://review.openstack.org/#/c/120603/

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

Re: [openstack-dev] Heat dependency visualisation

[Zane Bitter]

On 16/09/14 02:49, Qiming Teng wrote:

Nice. What would be even nicer is a change to python-heatclient so that
heat resource-list has an option to output in dotfile format.


+1.

It would also be interesting to check if the dependency analysis is
capable of exploding a resource-group.  Say I have a ResourceGroup where
each resource in the group is a Nova server that referencing the same
Neutron security group.  A naive analysis will show that the
ResourceGroup is referencing the security group, but the fact is that
each Nova server is depending on the SecurityGroup individually.


FWIW the "naive analysis" is actually how it works internally 
(dependencies don't cross nested stack boundaries), at least for now.


- ZB


Similarly, it would be interesting to see how this tool is handling
nested stacks.

Regards,
   - Qiming



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

Re: [openstack-dev] [Neutron][Infra] Moving DVR experimental job to the check queue

[Anita Kuno]

On 09/16/2014 02:11 PM, Carl Baldwin wrote:
> Hi,
> 
> Neutron would like to move the distributed virtual router (DVR)
> tempest job, currently in the experimental queue, to the check queue
> [1].  It will still be non-voting for the time being.  Could infra
> have a look?  We feel that running this on all Neutron patches is
> important to maintain the stability of DVR through release.
> 
> Carl
> 
> [1] https://review.openstack.org/#/c/120603/
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
Hi Carl, I am continuing to request core attention on this patch as I
did yesterday.

Let's not set the precedent of using the mailing list to request reviews.

Thanks,
Anita.

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

Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

[Zane Bitter]

On 16/09/14 13:56, Devananda van der Veen wrote:

On Mon, Sep 15, 2014 at 9:00 AM, Steven Hardy  wrote:

For example, today, I've been looking at the steps required for driving
autodiscovery:

https://etherpad.openstack.org/p/Ironic-PoCDiscovery-Juno

Driving this process looks a lot like application orchestration:

1. Take some input (IPMI credentials and MAC addresses)
2. Maybe build an image and ramdisk(could drop credentials in)
3. Interact with the Ironic API to register nodes in maintenance mode
4. Boot the nodes, monitor state, wait for a signal back containing some
data obtained during discovery (same as WaitConditions or
SoftwareDeployment resources in Heat..)
5. Shutdown the nodes and mark them ready for use by nova



My apologies if the following sounds snarky -- but I think there are a
few misconceptions that need to be cleared up about how and when one
might use Ironic. I also disagree that 1..5 looks like application
orchestration. Step 4 is a workflow, which I'll go into in a bit, but
this doesn't look at all like describing or launching an application
to me.


+1 (Although step 3 does sound to me like something that matches Heat's 
scope.)



Step 1 is just parse a text file.

Step 2 should be a prerequisite to doing -anything- with Ironic. Those
images need to be built and loaded in Glance, and the image UUID(s)
need to be set on each Node in Ironic (or on the Nova flavor, if going
that route) after enrollment. Sure, Heat can express this
declaratively (ironic.node.driver_info must contain key:deploy_kernel
with value:), but are you suggesting that Heat build the images,
or just take the UUIDs as input?

Step 3 is, again, just parse a text file

I'm going to make an assumption here [*], because I think step 4 is
misleading. You shouldn't "boot a node" using Ironic -- you do that
through Nova. And you _dont_ get to specify which node you're booting.
You ask Nova to provision an _instance_ on a _flavor_ and it picks an
available node from the pool of nodes that match the request.


I think your assumption is incorrect. Steve is well aware that 
provisioning a bare-metal Ironic server is done through the Nova API. 
What he's suggesting here is that the nodes would be booted - not 
Nova-booted, but booted in the sense of having power physically applied 
- while in maintenance mode in order to do autodiscovery of their 
capabilities, which is presumably hard to do automatically when they're 
turned off. He's also suggesting that Heat could drive this process, 
which I happen to disagree with because it is a workflow not an end 
state. However the main takeaway here is that you guys are talking 
completely past one another, and have been for some time.


cheers,
Zane.


Step 5 is a prerequisite for step 4 -- you can't boot a node that is
in maintenance mode, and if the node is not in maintenance mode, Nova
exposes it to clients. That is in fact how you'd boot it in step 4.

[*] I'm assuming you are not planning to re-implement the Nova
"ironic" driver in Heat. Booting a node with Ironic is not just a
matter of making one or two API calls. It's a declarative
transformation involving multiple changes in Ironic's API, and
presumably also some calls to Neutron if you want network access
to/from your node, and polling the resource to see when its state
converges on the requested state. Actually that sounds like exactly
the sort of thing that Heat could drive. But all this is already
implemented in Nova.


-Devananda

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




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

Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

[Zane Bitter]

On 16/09/14 13:54, Devananda van der Veen wrote:

On Sep 15, 2014 8:20 AM, "James Slagle"  wrote:

>
>On Mon, Sep 15, 2014 at 7:44 AM, Steven Hardy  wrote:

> >
> >The initial assumption is that there is some discovery step (either
> >automatic or static generation of a manifest of nodes), that can be input
> >to either Ironic or Heat.

>
>I think it makes a lot of sense to use Heat to do the bulk
>registration of nodes via Ironic. I understand the argument that the
>Ironic API should be "admin-only" a little bit for the non-TripleO
>case, but for TripleO, we only have admins interfacing with the
>Undercloud. The user of a TripleO undercloud is the deployer/operator
>and in some scenarios this may not be the undercloud admin. So,
>talking about TripleO, I don't really buy that the Ironic API is
>admin-only.
>

When I say the ironic API is admin only, I'm speaking to the required
permissions for accessing it. One must be authenticated with keystone
with the "admin" privilege. Borrowing from the ops guide:


In most contexts "admin only" means that the default policy.json file 
requires the "admin" role in the current project in order to access a 
particular API endpoint. If you are relying on the is_admin flag in the 
user context and not policy.json then it's likely you are Doing Keystone 
Wrong(TM).



" An administrative super user, which has full permissions across all
projects and should be used with great care."

I'm not sure how TripleO is dividing operator and admin in the
undercloud - so I just want to be clear on what you mean when you say
"may not be the undercloud admin". Simply put, to use Ironic in the
undercloud, you must have "admin" privileges in the undercloud -- or
you need to disable Ironic's auth entirely.


TripleO can presumably deploy any policy.json file they like in the 
undercloud. It's not entirely surprising that some operations that might 
are admin-only in an overcloud might need to be available in the 
undercloud to "ordinary" users - who, after all, have permissions to 
create entire overclouds - despite them not being admins of the 
undercloud itself.


cheers,
Zane.

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

Re: [openstack-dev] [zaqar] Juno Performance Testing (Round 3)

[Kurt Griffiths]

Thanks for the reminder! I’ll make note of that. In these tests the
clients are hitting Nginx (which is acting as a load balancer) so I could
try disabling keep-alive there and seeing what happens. So far I just used
the default that was written into the conf when the package was installed
("keepalive_timeout 65;”).

FWIW, I started an etherpad to track a shortlist of ideas:

https://etherpad.openstack.org/p/zaqar-performance-testing


On 9/16/14, 11:58 AM, "Jay Pipes"  wrote:

>On 09/16/2014 11:23 AM, Kurt Griffiths wrote:
>> Hi crew, as promised I’ve continued to work through the performance test
>> plan. I’ve started a wiki page for the next batch of tests and results:
>>
>> https://wiki.openstack.org/wiki/Zaqar/Performance/PubSub/Redis
>>
>> I am currently running the same tests again with 2x web heads, and will
>> update the wiki page with them when they finish (it takes a couple hours
>> to run each batch of tests). Then, I plan to add an additional Redis
>>proc
>> and run everything again. After that, there are a few other things that
>>we
>> could do, depending on what everyone wants to see next.
>>
>> * Run all these tests for producer-consumer (task distribution)
>>workloads
>> * Tune Redis, uWSGI and see if we can't improves latency, stdev, etc.
>> * Do a few runs with varying message sizes
>> * Continue increasing load and adding additional web heads
>> * Continue increasing load and adding additional redis procs
>> * Vary number of queues
>> * Vary number of project-ids
>> * Vary message batch sizes on post/get/claim
>
>Don't forget my request to identify the effect of keepalive settings in
>uWSGI :)
>
>Thanks!
>-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] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

[Devananda van der Veen]

On Tue, Sep 16, 2014 at 11:57 AM, Zane Bitter  wrote:
> On 16/09/14 13:54, Devananda van der Veen wrote:
>>
>> On Sep 15, 2014 8:20 AM, "James Slagle"  wrote:
>>>
>>> >
>>> >On Mon, Sep 15, 2014 at 7:44 AM, Steven Hardy  wrote:

 > >
 > >The initial assumption is that there is some discovery step (either
 > >automatic or static generation of a manifest of nodes), that can be
 > > input
 > >to either Ironic or Heat.
>>>
>>> >
>>> >I think it makes a lot of sense to use Heat to do the bulk
>>> >registration of nodes via Ironic. I understand the argument that the
>>> >Ironic API should be "admin-only" a little bit for the non-TripleO
>>> >case, but for TripleO, we only have admins interfacing with the
>>> >Undercloud. The user of a TripleO undercloud is the deployer/operator
>>> >and in some scenarios this may not be the undercloud admin. So,
>>> >talking about TripleO, I don't really buy that the Ironic API is
>>> >admin-only.
>>> >
>>
>> When I say the ironic API is admin only, I'm speaking to the required
>> permissions for accessing it. One must be authenticated with keystone
>> with the "admin" privilege. Borrowing from the ops guide:
>
>
> In most contexts "admin only" means that the default policy.json file
> requires the "admin" role in the current project in order to access a
> particular API endpoint. If you are relying on the is_admin flag in the user
> context and not policy.json then it's likely you are Doing Keystone
> Wrong(TM).

http://git.openstack.org/cgit/openstack/ironic/tree/etc/ironic/policy.json

There are no per-endpoint policies implemented in Ironic. This was
intentional when we started the project.

Also, there have been recent requests to begin providing read-only
access to certain resources to less-privileged users, so we may, in
Kilo, begin implementing more tunable policies.

>
>> " An administrative super user, which has full permissions across all
>> projects and should be used with great care."
>>
>> I'm not sure how TripleO is dividing operator and admin in the
>> undercloud - so I just want to be clear on what you mean when you say
>> "may not be the undercloud admin". Simply put, to use Ironic in the
>> undercloud, you must have "admin" privileges in the undercloud -- or
>> you need to disable Ironic's auth entirely.
>
>
> TripleO can presumably deploy any policy.json file they like in the
> undercloud. It's not entirely surprising that some operations that might are
> admin-only in an overcloud

Ironic isn't in the overcloud, so I'm not sure how this comparison is
appropriate.

> might need to be available in the undercloud to
> "ordinary" users - who, after all, have permissions to create entire
> overclouds - despite them not being admins of the undercloud itself.

Sure. Such a user, who has access to "create an overcloud", and would
be an admin in the overcloud they deployed, would be a regular user of
the undercloud, and have access to the undercloud Nova to provision
their workload. They would not be an admin in the undercloud, nor
would they have any need to talk directly to Ironic.

-Devananda

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

Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

[Devananda van der Veen]

On Tue, Sep 16, 2014 at 11:44 AM, Zane Bitter  wrote:
> On 16/09/14 13:56, Devananda van der Veen wrote:
>>
>> On Mon, Sep 15, 2014 at 9:00 AM, Steven Hardy  wrote:
>>>
>>> For example, today, I've been looking at the steps required for driving
>>> autodiscovery:
>>>
>>> https://etherpad.openstack.org/p/Ironic-PoCDiscovery-Juno
>>>
>>> Driving this process looks a lot like application orchestration:
>>>
>>> 1. Take some input (IPMI credentials and MAC addresses)
>>> 2. Maybe build an image and ramdisk(could drop credentials in)
>>> 3. Interact with the Ironic API to register nodes in maintenance mode
>>> 4. Boot the nodes, monitor state, wait for a signal back containing some
>>> data obtained during discovery (same as WaitConditions or
>>> SoftwareDeployment resources in Heat..)
>>> 5. Shutdown the nodes and mark them ready for use by nova
>>>
>>
>> My apologies if the following sounds snarky -- but I think there are a
>> few misconceptions that need to be cleared up about how and when one
>> might use Ironic. I also disagree that 1..5 looks like application
>> orchestration. Step 4 is a workflow, which I'll go into in a bit, but
>> this doesn't look at all like describing or launching an application
>> to me.
>
>
> +1 (Although step 3 does sound to me like something that matches Heat's
> scope.)

I think it's a simplistic use case, and Heat supports a lot more
complexity than is necessary to enroll nodes with Ironic.

>
>> Step 1 is just parse a text file.
>>
>> Step 2 should be a prerequisite to doing -anything- with Ironic. Those
>> images need to be built and loaded in Glance, and the image UUID(s)
>> need to be set on each Node in Ironic (or on the Nova flavor, if going
>> that route) after enrollment. Sure, Heat can express this
>> declaratively (ironic.node.driver_info must contain key:deploy_kernel
>> with value:), but are you suggesting that Heat build the images,
>> or just take the UUIDs as input?
>>
>> Step 3 is, again, just parse a text file
>>
>> I'm going to make an assumption here [*], because I think step 4 is
>> misleading. You shouldn't "boot a node" using Ironic -- you do that
>> through Nova. And you _dont_ get to specify which node you're booting.
>> You ask Nova to provision an _instance_ on a _flavor_ and it picks an
>> available node from the pool of nodes that match the request.
>
>
> I think your assumption is incorrect. Steve is well aware that provisioning
> a bare-metal Ironic server is done through the Nova API. What he's
> suggesting here is that the nodes would be booted - not Nova-booted, but
> booted in the sense of having power physically applied - while in
> maintenance mode in order to do autodiscovery of their capabilities,

Except simply applying power doesn't, in itself, accomplish anything
besides causing the machine to power on. Ironic will only prepare the
PXE boot environment when initiating a _deploy_.

> which
> is presumably hard to do automatically when they're turned off.

Vendors often have ways to do this while the power is turned off, eg.
via the OOB management interface.

> He's also
> suggesting that Heat could drive this process, which I happen to disagree
> with because it is a workflow not an end state.

+1

> However the main takeaway
> here is that you guys are talking completely past one another, and have been
> for some time.
>

Perhaps more detail in the expected interactions with Ironic would be
helpful and avoid me making (perhaps incorrect) assumptions.

-D

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

Re: [openstack-dev] [zaqar] Juno Performance Testing (Round 3)

[Kurt Griffiths]

Results are now posted for all workloads for 2x web heads and 1x Redis
proc (Configuration 2). Stats are also available for the write-heavy
workload with 2x webheads and 2x redis procs (Configuration 3). The latter
results look promising, and I suspect the setup could easily handle a
significantly higher load. Multiple load generator boxes would need to be
used (noted on the etherpad).

On 9/16/14, 10:23 AM, "Kurt Griffiths" 
wrote:

>Hi crew, as promised I’ve continued to work through the performance test
>plan. I’ve started a wiki page for the next batch of tests and results:
>
>https://wiki.openstack.org/wiki/Zaqar/Performance/PubSub/Redis
>
>I am currently running the same tests again with 2x web heads, and will
>update the wiki page with them when they finish (it takes a couple hours
>to run each batch of tests). Then, I plan to add an additional Redis proc
>and run everything again.

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

Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

[Zane Bitter]

On 16/09/14 15:24, Devananda van der Veen wrote:

On Tue, Sep 16, 2014 at 11:44 AM, Zane Bitter  wrote:

On 16/09/14 13:56, Devananda van der Veen wrote:


On Mon, Sep 15, 2014 at 9:00 AM, Steven Hardy  wrote:


For example, today, I've been looking at the steps required for driving
autodiscovery:

https://etherpad.openstack.org/p/Ironic-PoCDiscovery-Juno

Driving this process looks a lot like application orchestration:

1. Take some input (IPMI credentials and MAC addresses)
2. Maybe build an image and ramdisk(could drop credentials in)
3. Interact with the Ironic API to register nodes in maintenance mode
4. Boot the nodes, monitor state, wait for a signal back containing some
 data obtained during discovery (same as WaitConditions or
 SoftwareDeployment resources in Heat..)
5. Shutdown the nodes and mark them ready for use by nova



My apologies if the following sounds snarky -- but I think there are a
few misconceptions that need to be cleared up about how and when one
might use Ironic. I also disagree that 1..5 looks like application
orchestration. Step 4 is a workflow, which I'll go into in a bit, but
this doesn't look at all like describing or launching an application
to me.



+1 (Although step 3 does sound to me like something that matches Heat's
scope.)


I think it's a simplistic use case, and Heat supports a lot more
complexity than is necessary to enroll nodes with Ironic.




Step 1 is just parse a text file.

Step 2 should be a prerequisite to doing -anything- with Ironic. Those
images need to be built and loaded in Glance, and the image UUID(s)
need to be set on each Node in Ironic (or on the Nova flavor, if going
that route) after enrollment. Sure, Heat can express this
declaratively (ironic.node.driver_info must contain key:deploy_kernel
with value:), but are you suggesting that Heat build the images,
or just take the UUIDs as input?

Step 3 is, again, just parse a text file

I'm going to make an assumption here [*], because I think step 4 is
misleading. You shouldn't "boot a node" using Ironic -- you do that
through Nova. And you _dont_ get to specify which node you're booting.
You ask Nova to provision an _instance_ on a _flavor_ and it picks an
available node from the pool of nodes that match the request.



I think your assumption is incorrect. Steve is well aware that provisioning
a bare-metal Ironic server is done through the Nova API. What he's
suggesting here is that the nodes would be booted - not Nova-booted, but
booted in the sense of having power physically applied - while in
maintenance mode in order to do autodiscovery of their capabilities,


Except simply applying power doesn't, in itself, accomplish anything
besides causing the machine to power on. Ironic will only prepare the
PXE boot environment when initiating a _deploy_.


From what I gather elsewhere in this thread, the autodiscovery stuff is 
a proposal for the future, not something that exists in Ironic now, and 
that may be the source of the confusion.


In any case, the etherpad linked at the top of this email was written by 
someone in the Ironic team and _clearly_ describes PXE booting a 
"discovery image" in maintenance mode in order to obtain hardware 
information about the box.


cheers,
Zane.


which
is presumably hard to do automatically when they're turned off.


Vendors often have ways to do this while the power is turned off, eg.
via the OOB management interface.


He's also
suggesting that Heat could drive this process, which I happen to disagree
with because it is a workflow not an end state.


+1


However the main takeaway
here is that you guys are talking completely past one another, and have been
for some time.



Perhaps more detail in the expected interactions with Ironic would be
helpful and avoid me making (perhaps incorrect) assumptions.

-D

___
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] Ipset, merge refactor for J?

[Kyle Mestery]

On Tue, Sep 16, 2014 at 7:24 AM, Sean Dague  wrote:
> On 09/16/2014 03:57 AM, Thierry Carrez wrote:
>> Miguel Angel Ajo Pelayo wrote:
>>> During the ipset implementatio, we designed a refactor [1] to cleanup
>>> the firewall driver a bit, and move all the ipset low-level knowledge
>>> down into the  IpsetManager.
>>>
>>> I'd like to see this merged for J, and, it's a bit of an urgent matter
>>> to decide, because we keep adding small changes [2] [3] fruit of the
>>> early testing which break the refactor, and will add extra work which
>>> needs to be refactored too.
>>>
>>> The advantage of merging now, vs in J, is having K & J share a more common
>>> code base, which would help us during bug backports/etc in the future.
>>>
>>> Shihanzhang and I, are happy to see this merge during K, as it doesn't
>>> incur in functional changes, just code blocks are moved from the iptables
>>> firewall driver to IpsetManager, and the corresponding tests are moved too.
>>> [...]
>>
>> IMHO code refactoring should be considered a superfluous change at this
>> point in the cycle. The risk/benefit ratio is too high, and focus should
>> be on bugfixing at this point.
>
> +1.
>
> Hold the refactoring until Kilo.
>
+1

At this point, we should be focusing on bugs which stabilize the
release. Lets hold this for Kilo.

Thanks,
Kyle

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

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

Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

[Devananda van der Veen]

Now that I've replied to individual emails, let me try to summarize my
thoughts on why Heat feels like the wrong tool for the task that I
think you're trying to accomplish. This discussion has been really
helpful for me in understanding why that is, and I think, at a really
high level, it is because I do not believe that a description of a
cloud application should contain any direct references to Ironic's
resource classes. Let me explain why.

Heat is a declarative engine, where its inputs are: the stated desired
state of a complex system, and the actual state of that system. The
actual state might be that no resources have been created yet (so Heat
should create them) or a set of existing resources (which Heat
previously created) that need to be mutated to achieve the desired
state. This maps reasonably well onto the orchestration of launching
an application within a cloud. Great.

Nova, Cinder, Neutron, etc, provide APIs to control resources within a
cloud (instances, storage volumes, IPs, etc). These are the building
blocks of an application that Heat will use.

Ironic provides a declarative API to model physical configuration of
hardware. This doesn't actually correlate to an application in the
cloud, though Nova understands how to map its resource types (flavors
and instances) onto an available pool of hardware. It is conceivable
that Ironic might, at some point in the future, also be able to manage
switch and storage hardware configuration, firmware updates, etc, as
well. We don't today, but more than one interested developer/vendor
has already approached us asking about that.

By adding Ironic resource templates to Heat, you are, in my view,
moving it beyond the ken of "cloud application orchestration" and into
"inventory management", which is a space that has a lot of additional
complexity, and a lot of existing players.

For what it's worth, I acknowledge that this is possible (and I
apologize if my prior arguments made it seem like I didn't understand
that). But just because it can be done, doesn't mean it /should/ be
done.

Thanks for bearing with me as I organized my thoughts on this,
Devananda

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

Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

[Devananda van der Veen]

On Tue, Sep 16, 2014 at 12:42 PM, Zane Bitter  wrote:
> On 16/09/14 15:24, Devananda van der Veen wrote:
>>
>> On Tue, Sep 16, 2014 at 11:44 AM, Zane Bitter  wrote:
>>>
>>> On 16/09/14 13:56, Devananda van der Veen wrote:


 On Mon, Sep 15, 2014 at 9:00 AM, Steven Hardy  wrote:
>
>
> For example, today, I've been looking at the steps required for driving
> autodiscovery:
>
> https://etherpad.openstack.org/p/Ironic-PoCDiscovery-Juno
>
> Driving this process looks a lot like application orchestration:
>
> 1. Take some input (IPMI credentials and MAC addresses)
> 2. Maybe build an image and ramdisk(could drop credentials in)
> 3. Interact with the Ironic API to register nodes in maintenance mode
> 4. Boot the nodes, monitor state, wait for a signal back containing
> some
>  data obtained during discovery (same as WaitConditions or
>  SoftwareDeployment resources in Heat..)
> 5. Shutdown the nodes and mark them ready for use by nova
>

 My apologies if the following sounds snarky -- but I think there are a
 few misconceptions that need to be cleared up about how and when one
 might use Ironic. I also disagree that 1..5 looks like application
 orchestration. Step 4 is a workflow, which I'll go into in a bit, but
 this doesn't look at all like describing or launching an application
 to me.
>>>
>>>
>>>
>>> +1 (Although step 3 does sound to me like something that matches Heat's
>>> scope.)
>>
>>
>> I think it's a simplistic use case, and Heat supports a lot more
>> complexity than is necessary to enroll nodes with Ironic.
>>
>>>
 Step 1 is just parse a text file.

 Step 2 should be a prerequisite to doing -anything- with Ironic. Those
 images need to be built and loaded in Glance, and the image UUID(s)
 need to be set on each Node in Ironic (or on the Nova flavor, if going
 that route) after enrollment. Sure, Heat can express this
 declaratively (ironic.node.driver_info must contain key:deploy_kernel
 with value:), but are you suggesting that Heat build the images,
 or just take the UUIDs as input?

 Step 3 is, again, just parse a text file

 I'm going to make an assumption here [*], because I think step 4 is
 misleading. You shouldn't "boot a node" using Ironic -- you do that
 through Nova. And you _dont_ get to specify which node you're booting.
 You ask Nova to provision an _instance_ on a _flavor_ and it picks an
 available node from the pool of nodes that match the request.
>>>
>>>
>>>
>>> I think your assumption is incorrect. Steve is well aware that
>>> provisioning
>>> a bare-metal Ironic server is done through the Nova API. What he's
>>> suggesting here is that the nodes would be booted - not Nova-booted, but
>>> booted in the sense of having power physically applied - while in
>>> maintenance mode in order to do autodiscovery of their capabilities,
>>
>>
>> Except simply applying power doesn't, in itself, accomplish anything
>> besides causing the machine to power on. Ironic will only prepare the
>> PXE boot environment when initiating a _deploy_.
>
>
> From what I gather elsewhere in this thread, the autodiscovery stuff is a
> proposal for the future, not something that exists in Ironic now, and that
> may be the source of the confusion.
>
> In any case, the etherpad linked at the top of this email was written by
> someone in the Ironic team and _clearly_ describes PXE booting a "discovery
> image" in maintenance mode in order to obtain hardware information about the
> box.
>

Huh. I should have looked at that earlier in the discussion. It is
referring to out-of-tree code whose spec was not approved during Juno.

Apparently, and unfortunately, throughout much of this discussion,
folks have been referring to potential features Ironic might someday
have, whereas I have been focused on the features we actually support
today. That is probably why it seems we are "talking past each other."

-Devananda

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

[openstack-dev] how to debug RPC timeout issues?

[Chris Friesen]

Hi,

I'm running Havana, and I just tried a testcase involving doing six 
simultaneous live-migrations.

It appears that the migrations succeeded, but two of the instances got stuck 
with a status of "MIGRATING" because of RPC timeouts:

2014-09-16 20:35:07.376 12493 INFO nova.notifier [-] processing ERROR 
_post_live_migration
2014-09-16 20:35:07.390 12493 INFO nova.openstack.common.rpc.common [-] 
Connected to AMQP server on 192.168.204.2:5672
2014-09-16 20:35:07.396 12493 ERROR nova.openstack.common.loopingcall [-] in 
fixed duration looping call
2014-09-16 20:35:07.396 12493 TRACE nova.openstack.common.loopingcall Traceback 
(most recent call last):
2014-09-16 20:35:07.396 12493 TRACE nova.openstack.common.loopingcall   File 
"./usr/lib64/python2.7/site-packages/nova/openstack/common/loopingcall.py", 
line 78, in _inner
2014-09-16 20:35:07.396 12493 TRACE nova.openstack.common.loopingcall   File 
"./usr/lib64/python2.7/site-packages/nova/virt/libvirt/driver.py", line 4874, 
in wait_for_live_migration
2014-09-16 20:35:07.396 12493 TRACE nova.openstack.common.loopingcall   File 
"./usr/lib64/python2.7/site-packages/nova/exception.py", line 90, in wrapped
2014-09-16 20:35:07.396 12493 TRACE nova.openstack.common.loopingcall   File 
"./usr/lib64/python2.7/site-packages/nova/exception.py", line 73, in wrapped
2014-09-16 20:35:07.396 12493 TRACE nova.openstack.common.loopingcall   File 
"./usr/lib64/python2.7/site-packages/nova/compute/manager.py", line 4558, in 
_post_live_migration
2014-09-16 20:35:07.396 12493 TRACE nova.openstack.common.loopingcall   File 
"./usr/lib64/python2.7/site-packages/nova/compute/rpcapi.py", line 517, in 
post_live_migration_at_destination
2014-09-16 20:35:07.396 12493 TRACE nova.openstack.common.loopingcall   File 
"./usr/lib64/python2.7/site-packages/nova/rpcclient.py", line 85, in call
2014-09-16 20:35:07.396 12493 TRACE nova.openstack.common.loopingcall   File 
"./usr/lib64/python2.7/site-packages/nova/rpcclient.py", line 63, in _invoke
2014-09-16 20:35:07.396 12493 TRACE nova.openstack.common.loopingcall   File 
"./usr/lib64/python2.7/site-packages/nova/openstack/common/rpc/proxy.py", line 
131, in call
2014-09-16 20:35:07.396 12493 TRACE nova.openstack.common.loopingcall Timeout: 
Timeout while waiting on RPC response - topic: "compute.compute-0", RPC method: 
"post_live_migration_at_destination" info: ""


Looking at the migration destination compute node, I see it in turn getting 
stuck on an RPC timeout:


2014-09-16 20:35:32.216 12510 INFO nova.notifier 
[req-a8389c8d-7e5b-4f08-8669-ce14594e3863 24a43342a5ae4e31bd431aef2d395ebc 
02bf771ab40f4ecea6fe42135c5a09bc] processing ERROR 
post_live_migration_at_destination
2014-09-16 20:35:32.247 12510 INFO nova.openstack.common.rpc.common 
[req-a8389c8d-7e5b-4f08-8669-ce14594e3863 24a43342a5ae4e31bd431aef2d395ebc 
02bf771ab40f4ecea6fe42135c5a09bc] Connected to AMQP server on 192.168.204.2:5672
2014-09-16 20:35:32.248 12510 INFO nova.openstack.common.rpc.common 
[req-2f7bd481-9aed-4d66-97dd-3075407282dd 24a43342a5ae4e31bd431aef2d395ebc 
02bf771ab40f4ecea6fe42135c5a09bc] Connected to AMQP server on 192.168.204.2:5672
2014-09-16 20:35:32.270 12510 ERROR nova.openstack.common.rpc.amqp 
[req-a8389c8d-7e5b-4f08-8669-ce14594e3863 24a43342a5ae4e31bd431aef2d395ebc 
02bf771ab40f4ecea6fe42135c5a09bc] Exception during message handling
2014-09-16 20:35:32.270 12510 TRACE nova.openstack.common.rpc.amqp Traceback 
(most recent call last):
2014-09-16 20:35:32.270 12510 TRACE nova.openstack.common.rpc.amqp   File 
"./usr/lib64/python2.7/site-packages/nova/openstack/common/rpc/amqp.py", line 
466, in _process_data
2014-09-16 20:35:32.270 12510 TRACE nova.openstack.common.rpc.amqp   File 
"./usr/lib64/python2.7/site-packages/nova/openstack/common/rpc/dispatcher.py", 
line 172, in dispatch
2014-09-16 20:35:32.270 12510 TRACE nova.openstack.common.rpc.amqp   File 
"./usr/lib64/python2.7/site-packages/nova/exception.py", line 90, in wrapped
2014-09-16 20:35:32.270 12510 TRACE nova.openstack.common.rpc.amqp   File 
"./usr/lib64/python2.7/site-packages/nova/exception.py", line 73, in wrapped
2014-09-16 20:35:32.270 12510 TRACE nova.openstack.common.rpc.amqp   File 
"./usr/lib64/python2.7/site-packages/nova/compute/manager.py", line 4647, in 
post_live_migration_at_destination
2014-09-16 20:35:32.270 12510 TRACE nova.openstack.common.rpc.amqp   File 
"./usr/lib64/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5065, 
in post_live_migration_at_destination
2014-09-16 20:35:32.270 12510 TRACE nova.openstack.common.rpc.amqp   File 
"./usr/lib64/python2.7/site-packages/nova/virt/libvirt/driver.py", line 3709, 
in to_xml
2014-09-16 20:35:32.270 12510 TRACE nova.openstack.common.rpc.amqp   File 
"./usr/lib64/python2.7/site-packages/nova/virt/libvirt/driver.py", line 3465, 
in get_guest_config
2014-09-16 20:35:32.270 12510 TRACE nova.openstack.common.rpc.amqp   File 
"./usr/lib64/python2.7/site-packages/nova/compute/manager.py", line 383, in 
insta

[openstack-dev] [infra] [manila] Gerrit downtime Friday September 19

[Jeremy Stanley]

The project infrastructure team will be taking the Gerrit service on
review.openstack.org offline briefly from 20:30 to 21:00 UTC this
Friday, September 19 in an effort to move the newly-approved Shared
File Systems program repositories from stackforge into the openstack
namespace. The specific list of projects being moved is:

 * stackforge/manila -> openstack/manila

 * stackforge/python-manilaclient -> openstack/python-manilaclient

We'll follow up with a reply to this thread once the planned work is
complete.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [Cinder][Nova][Oslo] Moving Brick out of Cinder

[Ben Nemec]

Based on my reading of the wiki page about this it sounds like it should
be a sub-project of the Storage program.  While it is targeted for use
by multiple projects, it's pretty specific to interacting with Cinder,
right?  If so, it seems like Oslo wouldn't be a good fit.  We'd just end
up adding all of cinder-core to the project anyway. :-)

-Ben

On 09/16/2014 12:49 PM, Ivan Kolodyazhny wrote:
> Hi Stackers!
> 
> I'm working on moving Brick out of Cinder for K release.
> 
> There're a lot of open questions for now:
> 
>- Should we move it to oslo or somewhere on stackforge?
>- Better architecture of it to fit all Cinder and Nova requirements
>- etc.
> 
> Before starting discussion, I've created some proof-of-concept to try it. I
> moved Brick to some lib named oslo.storage for testing only. It's only one
> of the possible solution to start work on it.
> 
> All sources are aviable on GitHub [1], [2].
> 
> [1] - I'm not sure that this place and name is good for it, it's just a PoC.
> 
> [1] https://github.com/e0ne/oslo.storage
> [2] https://github.com/e0ne/cinder/tree/brick - some tests still failed.
> 
> Regards,
> Ivan Kolodyazhny
> 
> On Mon, Sep 8, 2014 at 4:35 PM, Ivan Kolodyazhny  wrote:
> 
>> Hi All!
>>
>> I would to start moving Cinder Brick [1] to oslo as was described on
>> Cinder mid-cycle meetup [2]. Unfortunately I missed meetup so I want be
>> sure that nobody started it and we are on the same page.
>>
>> According to the Juno 3 release, there was not enough time to discuss [3]
>> on the latest Cinder weekly meeting and I would like to get some feedback
>> from the all OpenStack community, so I propose to start this discussion on
>> mailing list for all projects.
>>
>> I anybody didn't started it and it is useful at least for both Nova and
>> Cinder I would to start this work according oslo guidelines [4] and
>> creating needed blueprints to make it finished until Kilo 1 is over.
>>
>>
>>
>> [1] https://wiki.openstack.org/wiki/CinderBrick
>> [2] https://etherpad.openstack.org/p/cinder-meetup-summer-2014
>> [3]
>> http://lists.openstack.org/pipermail/openstack-dev/2014-September/044608.html
>> [4] https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary
>>
>> Regards,
>> Ivan Kolodyazhny.
>>
> 
> 
> 
> ___
> 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] [Cinder][Nova][Oslo] Moving Brick out of Cinder

[Flavio Percoco]

On 09/16/2014 11:55 PM, Ben Nemec wrote:
> Based on my reading of the wiki page about this it sounds like it should
> be a sub-project of the Storage program.  While it is targeted for use
> by multiple projects, it's pretty specific to interacting with Cinder,
> right?  If so, it seems like Oslo wouldn't be a good fit.  We'd just end
> up adding all of cinder-core to the project anyway. :-)

+1 I think the same arguments and conclusions we had on glance-store
make sense here. I'd probably go with having it under the Block Storage
program.

Flavio

> 
> -Ben
> 
> On 09/16/2014 12:49 PM, Ivan Kolodyazhny wrote:
>> Hi Stackers!
>>
>> I'm working on moving Brick out of Cinder for K release.
>>
>> There're a lot of open questions for now:
>>
>>- Should we move it to oslo or somewhere on stackforge?
>>- Better architecture of it to fit all Cinder and Nova requirements
>>- etc.
>>
>> Before starting discussion, I've created some proof-of-concept to try it. I
>> moved Brick to some lib named oslo.storage for testing only. It's only one
>> of the possible solution to start work on it.
>>
>> All sources are aviable on GitHub [1], [2].
>>
>> [1] - I'm not sure that this place and name is good for it, it's just a PoC.
>>
>> [1] https://github.com/e0ne/oslo.storage
>> [2] https://github.com/e0ne/cinder/tree/brick - some tests still failed.
>>
>> Regards,
>> Ivan Kolodyazhny
>>
>> On Mon, Sep 8, 2014 at 4:35 PM, Ivan Kolodyazhny  wrote:
>>
>>> Hi All!
>>>
>>> I would to start moving Cinder Brick [1] to oslo as was described on
>>> Cinder mid-cycle meetup [2]. Unfortunately I missed meetup so I want be
>>> sure that nobody started it and we are on the same page.
>>>
>>> According to the Juno 3 release, there was not enough time to discuss [3]
>>> on the latest Cinder weekly meeting and I would like to get some feedback
>>> from the all OpenStack community, so I propose to start this discussion on
>>> mailing list for all projects.
>>>
>>> I anybody didn't started it and it is useful at least for both Nova and
>>> Cinder I would to start this work according oslo guidelines [4] and
>>> creating needed blueprints to make it finished until Kilo 1 is over.
>>>
>>>
>>>
>>> [1] https://wiki.openstack.org/wiki/CinderBrick
>>> [2] https://etherpad.openstack.org/p/cinder-meetup-summer-2014
>>> [3]
>>> http://lists.openstack.org/pipermail/openstack-dev/2014-September/044608.html
>>> [4] https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary
>>>
>>> Regards,
>>> Ivan Kolodyazhny.
>>>
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
@flaper87
Flavio Percoco

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

[openstack-dev] [Keystone][Horizon] CORS and Federation

[Adam Young]

Phase one for dealing with Federation can be done with CORS support 
solely for Keystone/Horizon  integration:


1.  Horizon Login page creates Javascript to do AJAX call to Keystone
2.  Keystone generates a token
3.  Javascript reads token out of response and sends it to Horizon.

This should support Kerberos, X509, and Password auth;  the Keystone 
team is discussing how to advertise mechanisms, lets leave the onus on 
us to solve that one and get back in a timely manner.


For Federation, the handshake is a little more complex, and there might 
be a need for some sort of popup window for the user to log in to their 
home SAML provider.  Its several more AJAX calls, but the end effect 
should be the same:  get a standard Keystone token and hand it to Horizon.


This would mean that Horizon would have to validate tokens the same way 
as any other endpoint.  That should not be too hard, but there is a 
little bit of "create a user, get a token, make a call" logic that 
currently lives only in keystonemiddleware/auth_token;  Its a solvable 
problem.


This approach will support the straight Javascript approach that Richard 
Jones discussed;  Keystone behind a proxy will work this way without 
CORS support.  If CORS  can be sorted out for the other services, we can 
do straight Javascript without the Proxy.  I see it as phased approach 
with this being the first phase.






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

Re: [openstack-dev] [neutron] [ironic] support resilient network boot of ironic server

[Jim Rollenhagen]

On Tue, Sep 16, 2014 at 07:09:36AM +, Carlino, Chuck wrote:
> Hi,
> 
> Below is the beginning of a spec I'd like to get into Kilo.  Before
> going into detail, it occurred to me that a basic decision needs to be
> made, so I'd like to get thoughts on the api Alternatives mentioned below.
> 
> Thanks,
> Chuck Carlino (ChuckC)
> 
> ==
> Enable Resilient Network Boot
> ==
> 
> https://blueprints.launchpad.net/neutron/+spec/resilient-network-boot
> 
> Today, if a user deploying workloads via Ironic wants to the server to
> be able
> to network boot in spite of a failure of an interface card, Neutron's DHCP
> service cannot provide an alternate interface card connected to the same
> network with the same IP address.
> 
> We propose to allow resilient boot in ironic configurations by enhancing
> Neutron's api to provide an association between the NICs and the IP address
> and by enhancing Neutron's DHCP service to vend the IP address to any of
> the NICs.
> 
> 
> Problem description
> ===
> 
> Ironic represents compute hardware as Nova instances.  Each instance's
> interface (NIC) to a network is represented by a Neutron port.  A port has a
> single mac address and an IP address that cannot be shared with other ports.
> So neutron cannot configure its DHCP service to serve a single IP address to
> more than 1 mac because it cannot associate multiple macs with an IP.
> 
> 
> Alternatives
> 
> 
> * A port for all instance NICs on the network
> 
>   - requires multiple mac addresses
> 
> * A port per instance NIC
> 
>   - requires relationship between ports (e.g. common subnet)
> 

Thanks for starting this conversation, Chuck; many Ironic folks are also
interested in this. /me adds [ironic] to the subject.

// jim

> 
> ___
> 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] [glance][all] Help with interpreting the log level guidelines

[Jay Pipes]

On 09/16/2014 02:04 PM, Kuvaja, Erno wrote:

-Original Message- From: Jay Pipes
[mailto:jaypi...@gmail.com] Sent: 16 September 2014 18:10 To:
openstack-dev@lists.openstack.org Subject: Re: [openstack-dev]
[glance][all] Help with interpreting the log level guidelines

On 09/16/2014 10:16 AM, Kuvaja, Erno wrote:

In my point of view it makes life much easier if we have
information where the request failed


The request did not fail. The HTTP request succeeded and Glance
returned a 404 Not Found. If the caller was expecting an image to
be there, but it wasn't, then it can log the 404 in whatever log
level is most appropriate.

The point is that DEBUG log level is appropriate for the
glanceclient logs, since the glanceclient doesn't know if a 404 is
something to be concerned about or not. To glanceclient, the call
succeeded. Communication with the Glance API server worked,
authentication worked, and the server returned successfully stating
that the image does not exist.

-jay



Still this is not about glanceclient logging. On that discussion I
fully agree that less is more what comes to logging.

When we try to update an image in the glance code and that fails
because the image is not there, I do not care where that gets stated
to the end user.


Yes you do. If the user understands the error message because it is 
clear (i.e. "You tried to update an image record, but the image was not 
found."), then the ops person does not get a ticket saying "the whole 
system is down, please help me." Instead, they get a ticket saying "why 
does this image no longer exist?"


> What I care about is that when the user starts

asking what happened, I don't get called up from the bed because the
ops responsible for the service have no idea.


Having the glanceclient log a WARN message in the log file if the image 
was not found is not going to help the ops person in the slightest. That 
information is already going to be in the ticket, with the description 
"Why does this image no longer exist?". Having the following in the 
operator logs:


WARN: Image XYZ not found.

is entirely useless to the operator. It offers them no further 
information whatsoever versus what is already in the error message that 
was returned to the user and likely copy/pasted into the help ticket.


> I also care that the

ops does not need to run through million lines of debugging logs just
because they would not get the info without. The reality is after all
that even in developer point of view the request did not fail, user
point of view it did.

We must keep in mind that somewhere out there is bunch of people
using these services outside of devstack who does not know the code
and how it behaves internally.


Yes, I keep that in mind. I was one of them.

> They see the log messages if any and

need to try to get the answers for the people who knows even less
about the internals.


There is a difference between log messages and error messages that are 
returned to the user. You are, IMHO, confusing the two.


-jay

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

Re: [openstack-dev] [Infra] Meeting Tuesday September 16th at 19:00 UTC

[Elizabeth K. Joseph]

On Mon, Sep 15, 2014 at 6:38 AM, Elizabeth K. Joseph
 wrote:
> The OpenStack Infrastructure (Infra) team is hosting our weekly
> meeting on Tuesday September 16th, at 19:00 UTC in #openstack-meeting

Minutes and log from the meeting today available here:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-09-16-19.01.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-09-16-19.01.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-09-16-19.01.log.html

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

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

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

[Gabriel Hurley]

This is generally the right plan. The hard parts are in getting people to 
deploy it correctly and securely, and handling fallback cases for lack of 
browser support, etc.

What we really don't want to do is to encourage people to set 
"Access-Control-Allow-Origin: *" type headers or other such nonsense simply 
because it's too much work to do things correctly. This becomes especially 
challenging for federated clouds.

I would encourage looking at the problem of adding all the necessary headers 
for CORS as an OpenStack-wide issue. Once you figure it out for Keystone, the 
next logical step is to want to make calls from the browser directly to all the 
other service endpoints, and each service is going to have to respond with the 
correct CORS headers ("Access-Control-Allow-Methods" and 
"Access-Control-Allow-Headers" are particularly fun ones for projects like 
Glance or Swift). A common middleware and means of configuring it will go a 
long way to easing user pain and spurring adoption of the new mechanisms. It 
will help the Horizon team substantially in the long run to do it consistently 
and predictably across the stack.

As a side-note, once we're in the realm of handling all this sensitive data 
with the browser as a middleman, encouraging people to configure things like 
CSP is probably also a good idea to make sure we're not loading malicious 
scripts or other resources.

Securing a browser-centric world is a tricky realm... let's make sure we get it 
right. :-)

 - Gabriel

> -Original Message-
> From: Adam Young [mailto:ayo...@redhat.com]
> Sent: Tuesday, September 16, 2014 3:40 PM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [Keystone][Horizon] CORS and Federation
> 
> Phase one for dealing with Federation can be done with CORS support solely
> for Keystone/Horizon  integration:
> 
> 1.  Horizon Login page creates Javascript to do AJAX call to Keystone 2.
> Keystone generates a token 3.  Javascript reads token out of response and
> sends it to Horizon.
> 
> This should support Kerberos, X509, and Password auth;  the Keystone team
> is discussing how to advertise mechanisms, lets leave the onus on us to solve
> that one and get back in a timely manner.
> 
> For Federation, the handshake is a little more complex, and there might be a
> need for some sort of popup window for the user to log in to their home
> SAML provider.  Its several more AJAX calls, but the end effect should be the
> same:  get a standard Keystone token and hand it to Horizon.
> 
> This would mean that Horizon would have to validate tokens the same way
> as any other endpoint.  That should not be too hard, but there is a little 
> bit of
> "create a user, get a token, make a call" logic that currently lives only in
> keystonemiddleware/auth_token;  Its a solvable problem.
> 
> This approach will support the straight Javascript approach that Richard Jones
> discussed;  Keystone behind a proxy will work this way without CORS
> support.  If CORS  can be sorted out for the other services, we can do 
> straight
> Javascript without the Proxy.  I see it as phased approach with this being the
> first phase.
> 
> 
> 
> 
> 
> ___
> 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] [Cinder][Nova][Oslo] Moving Brick out of Cinder

[Walter A. Boring IV]

Originally I wrote the connector side of brick to be the LUN discovery 
shared code between Cinder and Nova.
I tried to make a patch in Havana that would remove do this but it 
didn't make it in.


The upside to brick not making it in Nova is that it has given us some 
time to rethink things a bit.  What I would actually
like to see happen now is to create a new cinder/storage agent instead 
of just a brick library.   The agent would run on every cinder node,
nova node and potentially ironic nodes to do LUN discovery. Duncan and I 
are looking into this for the Kilo release.


The other portion of brick that exists in Cinder today some of the LVM 
code.   This makes a lot of sense to have in an agent as well for
each nova compute node to manage ephemeral storage used for boot disks 
for nova vms.  This would help remove some of the remaining

storage code from nova itself that does this.

Duncan and I will be at the Paris summit.   We would both welcome any 
interest to work on this concept of a new storage agent (which would

contain the existing brick code).


My $0.02,
Walt


On 09/16/2014 11:55 PM, Ben Nemec wrote:

Based on my reading of the wiki page about this it sounds like it should
be a sub-project of the Storage program.  While it is targeted for use
by multiple projects, it's pretty specific to interacting with Cinder,
right?  If so, it seems like Oslo wouldn't be a good fit.  We'd just end
up adding all of cinder-core to the project anyway. :-)

+1 I think the same arguments and conclusions we had on glance-store
make sense here. I'd probably go with having it under the Block Storage
program.

Flavio


-Ben

On 09/16/2014 12:49 PM, Ivan Kolodyazhny wrote:

Hi Stackers!

I'm working on moving Brick out of Cinder for K release.

There're a lot of open questions for now:

- Should we move it to oslo or somewhere on stackforge?
- Better architecture of it to fit all Cinder and Nova requirements
- etc.

Before starting discussion, I've created some proof-of-concept to try it. I
moved Brick to some lib named oslo.storage for testing only. It's only one
of the possible solution to start work on it.

All sources are aviable on GitHub [1], [2].

[1] - I'm not sure that this place and name is good for it, it's just a PoC.

[1] https://github.com/e0ne/oslo.storage
[2] https://github.com/e0ne/cinder/tree/brick - some tests still failed.

Regards,
Ivan Kolodyazhny

On Mon, Sep 8, 2014 at 4:35 PM, Ivan Kolodyazhny  wrote:


Hi All!

I would to start moving Cinder Brick [1] to oslo as was described on
Cinder mid-cycle meetup [2]. Unfortunately I missed meetup so I want be
sure that nobody started it and we are on the same page.

According to the Juno 3 release, there was not enough time to discuss [3]
on the latest Cinder weekly meeting and I would like to get some feedback
from the all OpenStack community, so I propose to start this discussion on
mailing list for all projects.

I anybody didn't started it and it is useful at least for both Nova and
Cinder I would to start this work according oslo guidelines [4] and
creating needed blueprints to make it finished until Kilo 1 is over.



[1] https://wiki.openstack.org/wiki/CinderBrick
[2] https://etherpad.openstack.org/p/cinder-meetup-summer-2014
[3]
http://lists.openstack.org/pipermail/openstack-dev/2014-September/044608.html
[4] https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary

Regards,
Ivan Kolodyazhny.




___
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] [zaqar] Juno Performance Testing (Round 3)

[Kurt Griffiths]

All results have been posted for the 2x web head + 2x redis tests (C3). I
also rearranged the wiki page to make it easier to compare the impact of
adding more capacity on the backend.

In C3, The load generator’s CPUs were fully saturated, while there was
still plenty of headroom on the web heads (~60% remaining CPU capacity)
and redis server instances (50% remaining across 2 procs), based on load
average. Therefore, I think this setup could actually handle a lot more
load than I attempted, and that would be a good followup test.

Keeping in mind that I haven’t spent much time tuning the systems and the
Redis driver still has several opportunities for further optimization, I
think these results so far are a pretty good sign we are on the right
track. I was happy to see that all requests were succeeding and I didn’t
find any race conditions during the tests, so kudos to the team for their
careful coding and reviews!

On 9/16/14, 2:43 PM, "Kurt Griffiths"  wrote:

>Results are now posted for all workloads for 2x web heads and 1x Redis
>proc (Configuration 2). Stats are also available for the write-heavy
>workload with 2x webheads and 2x redis procs (Configuration 3). The latter
>results look promising, and I suspect the setup could easily handle a
>significantly higher load. Multiple load generator boxes would need to be
>used (noted on the etherpad).
>
>On 9/16/14, 10:23 AM, "Kurt Griffiths" 
>wrote:
>
>>Hi crew, as promised I’ve continued to work through the performance test
>>plan. I’ve started a wiki page for the next batch of tests and results:
>>
>>https://wiki.openstack.org/wiki/Zaqar/Performance/PubSub/Redis
>>
>>I am currently running the same tests again with 2x web heads, and will
>>update the wiki page with them when they finish (it takes a couple hours
>>to run each batch of tests). Then, I plan to add an additional Redis proc
>>and run everything again.
>
>___
>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] [Cinder][Nova][Oslo] Moving Brick out of Cinder

[Mathieu Gagné]

On 2014-09-16 7:03 PM, Walter A. Boring IV wrote:


The upside to brick not making it in Nova is that it has given us some
time to rethink things a bit.  What I would actually
like to see happen now is to create a new cinder/storage agent instead
of just a brick library.   The agent would run on every cinder node,
nova node and potentially ironic nodes to do LUN discovery. Duncan and I
are looking into this for the Kilo release.



Thanks for reviving this idea [1] [2] [3]. I wish to say that I like it 
because months ago, we found use cases for it and wished cinder-agent 
was a thing.


One use case we have is the need to rescan an iSCSI target used by a 
Nova instance after an in-use volume has been extended in order to 
reflect its new size at the hypervisor level.


During the implementation, we quickly saw the code duplication hell that 
exists between both Nova and Cinder, all implementing iSCSI management. 
Due to the amount of work required to introduce a cinder-agent and due 
to my inexperience with OpenStack back then, we went down an other path 
instead.


We addressed our needs by introducing a Cinder->Nova interaction through 
custom code in Cinder and an API extension in Nova: Cinder triggers the 
rescan through the Nova API (instead of cinder-agent).


With cinder-agent, Cinder would be able to remotely trigger a rescan of 
the iSCSI target without relying on a custom API extension in Nova. I 
feel this implementation would be much more resilient and reduce code 
duplication in the long term.


I'm sure there is more use cases. This is mine.

[1] https://blueprints.launchpad.net/cinder/+spec/cinder-agent
[2] https://lists.launchpad.net/openstack/msg19825.html
[3] https://etherpad.openstack.org/p/cinder-agent

--
Mathieu

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

Re: [openstack-dev] [neutron][security-groups] Neutron default security groups

[Aaron Rosen]

Hi,

Inline:

On Tue, Sep 16, 2014 at 1:00 AM, Fawad Khaliq  wrote:

> Folks,
>
> I have had discussions with some folks individually about this but I would
> like bring this to a broader audience.
>
> I have been playing with security groups and I see the notion of 'default'
> security group seems to create some nuisance/issues.
>
> There are list of things I have noticed so far:
>
>- Tenant for OpenStack services (normally named service/services) also
>ends up having default security group.
>- Port create operation ends up ensuring default security groups for
>all the tenants as this completely seems out of the context of the tenant
>the port operation takes place. (bug?)
>- Race conditions where if system is stressed and Neutron tries to
>ensure the first default security group and in parallel another call comes,
>Neutron ends up trying to create multiple default security groups as the
>checks for duplicate groups are invalidated as soon as the call make past a
>certain point in code.
>
> Right this is a bug. We should catch this foreign key constraint exception
here and pass as the default security group was already created. We do
something similar here when ports are created as there is a similar race
for ip_allocation.

>
>-
>- API performance where orchestration chooses to spawn 1000 tenants
>and we see unnecessary overhead
>
>
>- For plugins that use RESTful proxy backends require the backend
>systems to be up at the time neutron starts. [Minor, but affects some
>packaging solutions]
>
>
This is probably always a requirement for neutron to work so I don't think
it's related.

>
> To summarize, is there a way to disable default security groups? Expected
> answer is no; can we introduce a way to disable it? If that does not make
> sense, should we go ahead and fix the issues around it?
>

I think we should fix these bugs you pointed out.

>
> I am sure some of you must have seen some of these issues and solved them
> already. Please do share how do tackle these issues?
>
> Thanks,
> Fawad Khaliq
>
>
> ___
> 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] [Keystone][Horizon] CORS and Federation

[Richard Jones]

CORS for all of OpenStack is possible once the oslo middleware lands*, but
as you note it's only one of many elements to be considered when exposing
the APIs to browsers. There is no current support for CSRF protection in
the OpenStack APIs, for example. I believe that sort of functionality
belongs in an intermediary between the APIs and the browser.


Richard

* https://review.openstack.org/#/c/120964/

On 17 September 2014 08:59, Gabriel Hurley 
wrote:

> This is generally the right plan. The hard parts are in getting people to
> deploy it correctly and securely, and handling fallback cases for lack of
> browser support, etc.
>
> What we really don't want to do is to encourage people to set
> "Access-Control-Allow-Origin: *" type headers or other such nonsense simply
> because it's too much work to do things correctly. This becomes especially
> challenging for federated clouds.
>
> I would encourage looking at the problem of adding all the necessary
> headers for CORS as an OpenStack-wide issue. Once you figure it out for
> Keystone, the next logical step is to want to make calls from the browser
> directly to all the other service endpoints, and each service is going to
> have to respond with the correct CORS headers
> ("Access-Control-Allow-Methods" and "Access-Control-Allow-Headers" are
> particularly fun ones for projects like Glance or Swift). A common
> middleware and means of configuring it will go a long way to easing user
> pain and spurring adoption of the new mechanisms. It will help the Horizon
> team substantially in the long run to do it consistently and predictably
> across the stack.
>
> As a side-note, once we're in the realm of handling all this sensitive
> data with the browser as a middleman, encouraging people to configure
> things like CSP is probably also a good idea to make sure we're not loading
> malicious scripts or other resources.
>
> Securing a browser-centric world is a tricky realm... let's make sure we
> get it right. :-)
>
>  - Gabriel
>
> > -Original Message-
> > From: Adam Young [mailto:ayo...@redhat.com]
> > Sent: Tuesday, September 16, 2014 3:40 PM
> > To: OpenStack Development Mailing List
> > Subject: [openstack-dev] [Keystone][Horizon] CORS and Federation
> >
> > Phase one for dealing with Federation can be done with CORS support
> solely
> > for Keystone/Horizon  integration:
> >
> > 1.  Horizon Login page creates Javascript to do AJAX call to Keystone 2.
> > Keystone generates a token 3.  Javascript reads token out of response and
> > sends it to Horizon.
> >
> > This should support Kerberos, X509, and Password auth;  the Keystone team
> > is discussing how to advertise mechanisms, lets leave the onus on us to
> solve
> > that one and get back in a timely manner.
> >
> > For Federation, the handshake is a little more complex, and there might
> be a
> > need for some sort of popup window for the user to log in to their home
> > SAML provider.  Its several more AJAX calls, but the end effect should
> be the
> > same:  get a standard Keystone token and hand it to Horizon.
> >
> > This would mean that Horizon would have to validate tokens the same way
> > as any other endpoint.  That should not be too hard, but there is a
> little bit of
> > "create a user, get a token, make a call" logic that currently lives
> only in
> > keystonemiddleware/auth_token;  Its a solvable problem.
> >
> > This approach will support the straight Javascript approach that Richard
> Jones
> > discussed;  Keystone behind a proxy will work this way without CORS
> > support.  If CORS  can be sorted out for the other services, we can do
> straight
> > Javascript without the Proxy.  I see it as phased approach with this
> being the
> > first phase.
> >
> >
> >
> >
> >
> > ___
> > 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] [neutron][security-groups] Neutron default security groups

[shihanzhang]

As I know there is no a way to disable default security groups, but I think 
this BP can solve this problem:
https://blueprints.launchpad.net/neutron/+spec/default-rules-for-default-security-group



在 2014-09-17 07:44:42，"Aaron Rosen"  写道：

Hi, 


Inline: 


On Tue, Sep 16, 2014 at 1:00 AM, Fawad Khaliq  wrote:

Folks,


I have had discussions with some folks individually about this but I would like 
bring this to a broader audience.


I have been playing with security groups and I see the notion of 'default' 
security group seems to create some nuisance/issues.


There are list of things I have noticed so far:
Tenant for OpenStack services (normally named service/services) also ends up 
having default security group. 
Port create operation ends up ensuring default security groups for all the 
tenants as this completely seems out of the context of the tenant the port 
operation takes place. (bug?) 
Race conditions where if system is stressed and Neutron tries to ensure the 
first default security group and in parallel another call comes, Neutron ends 
up trying to create multiple default security groups as the checks for 
duplicate groups are invalidated as soon as the call make past a certain point 
in code.

Right this is a bug. We should catch this foreign key constraint exception here 
and pass as the default security group was already created. We do something 
similar here when ports are created as there is a similar race for 
ip_allocation. 


API performance where orchestration chooses to spawn 1000 tenants and we see 
unnecessary overhead 
For plugins that use RESTful proxy backends require the backend systems to be 
up at the time neutron starts. [Minor, but affects some packaging solutions]


This is probably always a requirement for neutron to work so I don't think it's 
related. 


To summarize, is there a way to disable default security groups? Expected 
answer is no; can we introduce a way to disable it? If that does not make 
sense, should we go ahead and fix the issues around it? 


I think we should fix these bugs you pointed out.  


I am sure some of you must have seen some of these issues and solved them 
already. Please do share how do tackle these issues?


Thanks,

Fawad Khaliq



___
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] [OSSN 0020] Disassociating floating IPs does not terminate NAT connections with Neutron L3 agent

[shihanzhang]

Now there is already a bug:https://bugs.launchpad.net/neutron/+bug/1334926 for 
this problem, meanwhile the security group also has same problem, I have report 
a bug:
https://bugs.launchpad.net/neutron/+bug/1335375
 






在 2014-09-16 01:46:11，"Martinx - ジェームズ"  写道：

Hey stackers,


Let me ask something about this... Why not use Linux Conntrack Table at each 
Tenant Namespace (L3 Router) to detect which connections were
made/established over a Floating IP ?


Like this, on the Neutron L3 Router:


--
apt-get install conntrack


ip netns exec qrouter-09b72faa-a5ef-4a52-80b5-1dcbea23b1b6 conntrack -L | grep 
ESTABLISHED



tcp  6 431998 ESTABLISHED src=192.168.3.5 dst=193.16.15.250 sport=36476 
dport=8333 src=193.16.15.250 dst=187.1.93.67 sport=8333 dport=36476 [ASSURED] 
mark=0 use=1
--


Floating IP: 187.1.93.67
Instance IP: 192.168.3.5


http://conntrack-tools.netfilter.org/manual.html#conntrack






Or, as a workaround, right after removing the Floating IP, Neutron might insert 
a temporary firewall rule (for about 5~10 minutes?), to drop the connections of 
that previous "Floating IP + Instance IP couple"... It looks really ugly but, 
at least, it will make sure that nothing will pass right after removing a 
Floating IP... Effectively terminating (dropping) the NAT connections after 
disassociating a Floating IP... ;-)





Also, I think that NFTables can bring some light here... I truly believe that 
if OpenStack moves to a "NFTables_Driver", it will be much easier to: manage 
firewall rules, logging, counters, IDS/IPS, atomic replacements of rules, even 
NAT66... All under a single implementation... Maybe with some kind of 
"real-time connection monitoring"... I mean, with NFTables, it becomes easier 
to implement a firewall ruleset with a Intrusion Prevention System (IPS), take 
a look:


https://home.regit.org/2014/02/suricata-and-nftables/



So, if NFTables can make Suricata's life easier, why not give Suricata's power 
to Netutron L3 Router? Starting with a new NFTables_Driver... =)


I'm not an expert on NFTables but, from what I'm seeing, it perfectly fits in 
OpenStack, in fact, NFTables will make OpenStack better.


https://home.regit.org/2014/01/why-you-will-love-nftables/



Best!
Thiago


On 15 September 2014 20:49, Nathan Kinder  wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Disassociating floating IPs does not terminate NAT connections with
Neutron L3 agent
- ---

### Summary ###
Every virtual instance is automatically assigned a private IP address.
You may optionally assign public IP addresses to instances. OpenStack
uses the term "floating IP" to refer to an IP address (typically
public) that can be dynamically added to a running virtual instance.
The Neutron L3 agent uses Network Address Translation (NAT) to assign
floating IPs to virtual instances. Floating IPs can be dynamically
released from a running virtual instance but any active connections are
not terminated with this release as expected when using the Neutron L3
agent.

### Affected Services / Software ###
Neutron, Icehouse, Havana, Grizzly, Folsom

### Discussion ###
When creating a virtual instance, a floating IP address is not
allocated by default. After a virtual instance is created, a user can
explicitly associate a floating IP address to that instance. Users can
create connections to the virtual instance using this floating IP
address. Also, this floating IP address can be disassociated from any
running instance without shutting that instance down.

If a user initiates a connection using the floating IP address, this
connection remains alive and accessible even after the floating IP
address is released from that instance. This potentially violates
restrictive policies which are only being applied to new connections.
These policies are ignored for pre-existing connections and the virtual
instance remains accessible from the public network.

This issue is only known to affect Neutron when using the L3 agent.
Nova networking is not affected.

### Recommended Actions ###
There is unfortunately no easy way to detect which connections were
made over a floating IP address from a virtual instance, as the NAT is
performed at the Neutron router. The only safe way of terminating all
connections made over a floating IP address is to terminate the virtual
instance itself.

The following recommendations should be followed when using the Neutron
L3 agent:

- - Only attach a floating IP address to a virtual instance when that
instance should be accessible from networks outside the cloud.
- - Terminate or stop the instance along with disassociating the floating
IP address to ensure that all connections are closed.

The Neutron development team plans to address this issue in a future
version of Neutron.

### Contacts / References ###
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0020
Original LaunchPad Bug : https://bugs.launchpad.net/neutron/+bug/1334926
OpenStack Security ML : openstack-secur...@l

[openstack-dev] [neutron] DVR Tunnel Design Question

[Steve Wormley]

In our environment using VXLAN/GRE would make it difficult to keep some of
the features we currently offer our customers. So for a while now I've been
looking at the DVR code, blueprints and Google drive docs and other than it
being the way the code was written I can't find anything indicating why a
Tunnel/Overlay network is required for DVR or what problem it was solving.

Basically I'm just trying to see if I missed anything as I look into doing
a VLAN/OVS implementation.

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

Re: [openstack-dev] [neutron] DVR Tunnel Design Question

[龚永生]

I think the VLAN should also be supported later.  The tunnel should not be the 
prerequisite for the DVR feature.
 
 
-- Original --
From:  "Steve Wormley";
Date:  Wed, Sep 17, 2014 10:29 AM
To:  "openstack-dev"; 

Subject:  [openstack-dev] [neutron] DVR Tunnel Design Question

 
In our environment using VXLAN/GRE would make it difficult to keep some of the 
features we currently offer our customers. So for a while now I've been looking 
at the DVR code, blueprints and Google drive docs and other than it being the 
way the code was written I can't find anything indicating why a Tunnel/Overlay 
network is required for DVR or what problem it was solving. 


Basically I'm just trying to see if I missed anything as I look into doing a 
VLAN/OVS implementation.


Thanks,

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

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

[Adam Young]

On 09/16/2014 06:59 PM, Gabriel Hurley wrote:

This is generally the right plan. The hard parts are in getting people to 
deploy it correctly and securely, and handling fallback cases for lack of 
browser support, etc.
Do we really care about Browser support?  I mean, are we really going to 
have to support non-Javascript capable browsers for Horizon?  Are there 
any Browsers with sufficient quality of Javascript support that don't 
also have CORS support?





What we really don't want to do is to encourage people to set 
"Access-Control-Allow-Origin: *" type headers or other such nonsense simply 
because it's too much work to do things correctly. This becomes especially challenging 
for federated clouds.

I was thinking we would have  two common approaches:

1.  User the service catalog.  It implies adding Horizon to the Service 
catalog, but then we know each endpoint, and we can limit CORS to other 
official endpoints.  This is my preferred approach.


2.  Have a DNS Zone for the openstack deployment.  So, the

Access-Control-Allow-Origin: *.openstack.example.com






I would encourage looking at the problem of adding all the necessary headers for CORS as an 
OpenStack-wide issue. Once you figure it out for Keystone, the next logical step is to want to make 
calls from the browser directly to all the other service endpoints, and each service is going to 
have to respond with the correct CORS headers ("Access-Control-Allow-Methods" and 
"Access-Control-Allow-Headers" are particularly fun ones for projects like Glance or 
Swift). A common middleware and means of configuring it will go a long way to easing user pain and 
spurring adoption of the new mechanisms. It will help the Horizon team substantially in the long 
run to do it consistently and predictably across the stack.

As a side-note, once we're in the realm of handling all this sensitive data 
with the browser as a middleman, encouraging people to configure things like 
CSP is probably also a good idea to make sure we're not loading malicious 
scripts or other resources.


Yes.   I think this is an obvious cross-project track session for the 
Summit.




Securing a browser-centric world is a tricky realm... let's make sure we get it 
right. :-)
Agreed.  I think this is one topic that will benefit from serious 
upfront effort.


  - Gabriel


-Original Message-
From: Adam Young [mailto:ayo...@redhat.com]
Sent: Tuesday, September 16, 2014 3:40 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Keystone][Horizon] CORS and Federation

Phase one for dealing with Federation can be done with CORS support solely
for Keystone/Horizon  integration:

1.  Horizon Login page creates Javascript to do AJAX call to Keystone 2.
Keystone generates a token 3.  Javascript reads token out of response and
sends it to Horizon.

This should support Kerberos, X509, and Password auth;  the Keystone team
is discussing how to advertise mechanisms, lets leave the onus on us to solve
that one and get back in a timely manner.

For Federation, the handshake is a little more complex, and there might be a
need for some sort of popup window for the user to log in to their home
SAML provider.  Its several more AJAX calls, but the end effect should be the
same:  get a standard Keystone token and hand it to Horizon.

This would mean that Horizon would have to validate tokens the same way
as any other endpoint.  That should not be too hard, but there is a little bit 
of
"create a user, get a token, make a call" logic that currently lives only in
keystonemiddleware/auth_token;  Its a solvable problem.

This approach will support the straight Javascript approach that Richard Jones
discussed;  Keystone behind a proxy will work this way without CORS
support.  If CORS  can be sorted out for the other services, we can do straight
Javascript without the Proxy.  I see it as phased approach with this being the
first phase.





___
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] [Keystone][Horizon] CORS and Federation

[Adam Young]

On 09/16/2014 08:56 PM, Richard Jones wrote:
CORS for all of OpenStack is possible once the oslo middleware lands*, 
but as you note it's only one of many elements to be considered when 
exposing the APIs to browsers. There is no current support for CSRF 
protection in the OpenStack APIs, for example. I believe that sort of 
functionality belongs in an intermediary between the APIs and the browser.


Typically, CSRF is done by writing a customer header.  Why wouldn't the 
-X-Auth-Token header qualify?  Its not a cookie, automatically added.  
So, CORS support would be necesary for horizon to send the token on a 
request to Nova, but no other site would be able to do that.  No?





Richard

* https://review.openstack.org/#/c/120964/

On 17 September 2014 08:59, Gabriel Hurley > wrote:


This is generally the right plan. The hard parts are in getting
people to deploy it correctly and securely, and handling fallback
cases for lack of browser support, etc.

What we really don't want to do is to encourage people to set
"Access-Control-Allow-Origin: *" type headers or other such
nonsense simply because it's too much work to do things correctly.
This becomes especially challenging for federated clouds.

I would encourage looking at the problem of adding all the
necessary headers for CORS as an OpenStack-wide issue. Once you
figure it out for Keystone, the next logical step is to want to
make calls from the browser directly to all the other service
endpoints, and each service is going to have to respond with the
correct CORS headers ("Access-Control-Allow-Methods" and
"Access-Control-Allow-Headers" are particularly fun ones for
projects like Glance or Swift). A common middleware and means of
configuring it will go a long way to easing user pain and spurring
adoption of the new mechanisms. It will help the Horizon team
substantially in the long run to do it consistently and
predictably across the stack.

As a side-note, once we're in the realm of handling all this
sensitive data with the browser as a middleman, encouraging people
to configure things like CSP is probably also a good idea to make
sure we're not loading malicious scripts or other resources.

Securing a browser-centric world is a tricky realm... let's make
sure we get it right. :-)

 - Gabriel

> -Original Message-
> From: Adam Young [mailto:ayo...@redhat.com
]
> Sent: Tuesday, September 16, 2014 3:40 PM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [Keystone][Horizon] CORS and Federation
>
> Phase one for dealing with Federation can be done with CORS
support solely
> for Keystone/Horizon  integration:
>
> 1.  Horizon Login page creates Javascript to do AJAX call to
Keystone 2.
> Keystone generates a token 3.  Javascript reads token out of
response and
> sends it to Horizon.
>
> This should support Kerberos, X509, and Password auth;  the
Keystone team
> is discussing how to advertise mechanisms, lets leave the onus
on us to solve
> that one and get back in a timely manner.
>
> For Federation, the handshake is a little more complex, and
there might be a
> need for some sort of popup window for the user to log in to
their home
> SAML provider.  Its several more AJAX calls, but the end effect
should be the
> same:  get a standard Keystone token and hand it to Horizon.
>
> This would mean that Horizon would have to validate tokens the
same way
> as any other endpoint.  That should not be too hard, but there
is a little bit of
> "create a user, get a token, make a call" logic that currently
lives only in
> keystonemiddleware/auth_token;  Its a solvable problem.
>
> This approach will support the straight Javascript approach that
Richard Jones
> discussed;  Keystone behind a proxy will work this way without CORS
> support.  If CORS  can be sorted out for the other services, we
can do straight
> Javascript without the Proxy.  I see it as phased approach with
this being the
> first phase.
>
>
>
>
>
> ___
> 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] [Ceilometer] Adding Dina Belova to ceilometer-core

[gordon chung]

> Dina has been doing a great work and has been very helpful during the
> Juno cycle and her help is very valuable. She's been doing a lot of> reviews 
> and has been very active in our community.+1cheers,
gord

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

[openstack-dev] DVR meeting cancelled for Sept 17th 2014

[Vasudevan, Swaminathan (PNB Roseville)]

Hi Folks,
Neutron DVR meeting will be cancelled on Sept 17th 2014.
We will resume next week.


Swaminathan Vasudevan
Systems Software Engineer (TC)


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


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