date:20140416

So, I'm glad there's interest in doing this. I would encourage folks
who are interested in attending to please add their names to the
etherpad, and to suggest locations there as well. We'll try to
converge on those over the coming weeks. Also, as pointed out by ttx,
we should hold off an settling on a date until the Juno release
schedule is set in stone so we don't accidentally pick a milestone
week.

Thanks,
Kyle

On Wed, Apr 16, 2014 at 2:23 AM, Edgar Magana Perdomo (eperdomo)
 wrote:
> Great initiative.
> I added my name and also which location will work better, I would suggest
> all developers interested on this meeting to do the same.
>
> Edgar
>
> On 4/15/14, 6:54 PM, "Kyle Mestery"  wrote:
>
>>Folks:
>>
>>Given all the talk of mid-cycle meetings, I'd like to propose that we
>>do one for Neutron as well. Mark and I talked about this over the past
>>few months, and I've mentioned this to a few other people as well. I
>>think it would be ideal to get everyone together in the July
>>timeframe, but I'd like to hear from others on dates. I've setup an
>>etherpad to track the discussion here [1]. Can people weigh in on
>>which week works for them? If there are events happening on those
>>weeks which would preclude people from attending, I'd also like to
>>hear that. I have a proposed location and sponsor, but I'm open to
>>hearing other options as well if the proposed location doesn't work
>>for anyone.
>>
>>Thanks!
>>Kyle
>>
>>[1] https://etherpad.openstack.org/p/neutron-juno-mid-cycle-meeting
>>
>>___
>>OpenStack-dev mailing list
>>OpenStack-dev@lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [nova] unit tests method

2014-04-16 Thread Jay Pipes

On Wed, 2014-04-16 at 14:55 +0800, Chen CH Ji wrote:
> Hi 
> There are 3 types of unit test existing now (stub, mox
> and mock)
> Several code reviewers suggest to use mock instead of
> using the other 2 and I am following it, but I want to know where can
> I find the suggestion and guide line?

Hi Kevin!

So, there are only two unit testing methods -- mock and mox. stubs are
part of the mox-style way of doing things.

My general rules of thumb when doing reviews in Nova are these:

1) For new unit tests, use mock
2) Don't mix mock and mox in a single test method
3) When modifying existing unit tests, unless rewriting the test method
almost entirely, stick with whatever is used already (mock or mox)

Best,
-jay


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

[openstack-dev] [Nova][blueprint] Accelerate the booting process of a number of vms via VMThunder

2014-04-16 Thread yongquan Fu

Dear all,



 We would like to present an extension to the vm-booting functionality of
Nova when a number of homogeneous vms need to be launched at the same time.



The motivation for our work is to increase the speed of provisioning vms
for large-scale scientific computing and big data processing. In that case,
we often need to boot tens and hundreds virtual machine instances at the
same time.


Currently, under the Openstack, we found that creating a large number
of virtual machine instances is very time-consuming. The reason is the
booting procedure is a centralized operation that involve performance
bottlenecks. Before a virtual machine can be actually started, OpenStack
either copy the image file (swift) or attach the image volume (cinder) from
storage server to compute node via network. Booting a single VM need to
read a large amount of image data from the image storage server. So
creating a large number of virtual machine instances would cause a
significant workload on the servers. The servers become quite busy even
unavailable during the deployment phase. It would consume a very long time
before the whole virtual machine cluster useable.



  Our extension is based on our work on vmThunder, a novel mechanism
accelerating the deployment of large number virtual machine instances. It
is written in Python, can be integrated with OpenStack easily. VMThunder
addresses the problem described above by following improvements: on-demand
transferring (network attached storage), compute node caching, P2P
transferring and prefetching. VMThunder is a scalable and cost-effective
accelerator for bulk provisioning of virtual machines.



  We hope to receive your feedbacks. Any comments are extremely welcome.
Thanks in advance.



PS:



VMThunder enhanced nova blueprint:
https://blueprints.launchpad.net/nova/+spec/thunderboost

 VMThunder standalone project: https://launchpad.net/vmthunder;

 VMThunder prototype: https://github.com/lihuiba/VMThunder

 VMThunder etherpad: https://etherpad.openstack.org/p/vmThunder

 VMThunder portal: http://www.vmthunder.org/

VMThunder paper: http://www.computer.org/csdl/trans/td/preprint/06719385.pdf



  Regards



  vmThunder development group

  PDL

  National University of Defense Technology
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Neutron BP review process for Juno

I think the problem is that your spec should be at the toplevel of the
juno directory, and that's why the UT is failing. Can you move your
spec up a level, including the image? You can create a spec images
directory to put them in there and reference it in the spec as well if
you want.

On Tue, Apr 15, 2014 at 11:48 PM, Sumit Naiksatam
 wrote:
> What's the convention for adding images to the patch? The following
> directory structure seemed logical to me (but the current UT will not
> allow it):
>
> specs/juno//.rst
> specs/juno//images/.png
>
> Thanks,
> ~Sumit.
>
>
>
> On Tue, Apr 15, 2014 at 3:35 PM, Carl Baldwin  wrote:
>> +1.  I think we'll like this process better.  I hope to have some of
>> the first blueprints to propose to the new repository very soon.
>>
>> On Tue, Apr 15, 2014 at 4:07 PM, Kyle Mestery  
>> wrote:
>>> Given the success the Nova team has had in handling reviews using
>>> their new nova-specs gerrit repository, I think it makes a lot of
>>> sense for Neutron to do the same. With this in mind, I've added
>>> instructions to the BP wiki [1] for how to do. Going forward in Juno,
>>> this is how Neutron BPs will be handled by the Neutron core team. If
>>> you are currently working on a BP or code for Juno which is attached
>>> to a BP, please file the BP using the process here [1].
>>>
>>> Given this is our first attempt at using this for reviews, I
>>> anticipate there may be a few hiccups along the way. Please reply on
>>> this thread or reach out in #openstack-neutron and we'll sort through
>>> whatever issues we find.
>>>
>>> Thanks!
>>> Kyle
>>>
>>> [1] https://wiki.openstack.org/wiki/Blueprints#Neutron
>>>
>>> ___
>>> 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] computed package names?

2014-04-16 Thread Qiming Teng

In the case of yum or apt package installation, I would recommend to
give OS::Heat::CloudConfig a try, instead of sticking to cfn-init.

The function you proposed (Fn::MemberListToMap) actually brings us back
to the previous discussion whether a mapping section is really needed in
the native HOT template.   My understanding was that people are more 
inclined to use provider templates for this kind of varieties or 
flexibilities.

I am still feeling that we need a simple, intuitive, declarative way to
specify maps/dicts for convenience.  Provider templates, IMHO, are too
heavy-weight for this.  However, for keys, I don't know whether it is a
good idea to make it a variable.

Regards,
  Qiming

On Tue, Apr 15, 2014 at 06:15:36PM -0400, Mike Spreitzer wrote:
> Mike Spreitzer/Watson/IBM@IBMUS wrote on 04/15/2014 05:59:50 PM:
> 
> > Yes, I can see how OS::Heat::Init makes sense.  But is this just the
> > first thing on a long list?  Would it be better to have a static 
> > intrinsic that is like Python's dict(iterable of 
> > iterable)->dictionary function? 
> 
> .. and I see now that we do: Fn::MemberListToMap

> ___
> 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] Neutron BP review process for Juno

2014-04-16 Thread Salvatore Orlando

if the image you're adding is a diagram, I would think about asciiflow.comfirst!


On 16 April 2014 15:09, Kyle Mestery  wrote:

> I think the problem is that your spec should be at the toplevel of the
> juno directory, and that's why the UT is failing. Can you move your
> spec up a level, including the image? You can create a spec images
> directory to put them in there and reference it in the spec as well if
> you want.
>
> On Tue, Apr 15, 2014 at 11:48 PM, Sumit Naiksatam
>  wrote:
> > What's the convention for adding images to the patch? The following
> > directory structure seemed logical to me (but the current UT will not
> > allow it):
> >
> > specs/juno//.rst
> > specs/juno//images/.png
> >
> > Thanks,
> > ~Sumit.
> >
> >
> >
> > On Tue, Apr 15, 2014 at 3:35 PM, Carl Baldwin 
> wrote:
> >> +1.  I think we'll like this process better.  I hope to have some of
> >> the first blueprints to propose to the new repository very soon.
> >>
> >> On Tue, Apr 15, 2014 at 4:07 PM, Kyle Mestery <
> mest...@noironetworks.com> wrote:
> >>> Given the success the Nova team has had in handling reviews using
> >>> their new nova-specs gerrit repository, I think it makes a lot of
> >>> sense for Neutron to do the same. With this in mind, I've added
> >>> instructions to the BP wiki [1] for how to do. Going forward in Juno,
> >>> this is how Neutron BPs will be handled by the Neutron core team. If
> >>> you are currently working on a BP or code for Juno which is attached
> >>> to a BP, please file the BP using the process here [1].
> >>>
> >>> Given this is our first attempt at using this for reviews, I
> >>> anticipate there may be a few hiccups along the way. Please reply on
> >>> this thread or reach out in #openstack-neutron and we'll sort through
> >>> whatever issues we find.
> >>>
> >>> Thanks!
> >>> Kyle
> >>>
> >>> [1] https://wiki.openstack.org/wiki/Blueprints#Neutron
> >>>
> >>> ___
> >>> 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] [neutron] Neutron Mid-Cycle Meeting

2014-04-16 Thread Thierry Carrez

Kyle Mestery wrote:
> So, I'm glad there's interest in doing this. I would encourage folks
> who are interested in attending to please add their names to the
> etherpad, and to suggest locations there as well. We'll try to
> converge on those over the coming weeks. Also, as pointed out by ttx,
> we should hold off an settling on a date until the Juno release
> schedule is set in stone so we don't accidentally pick a milestone
> week.

We'll discuss the options at the summit, but here is a rough view:

- juno-1 is likely to be June 12 or June 19
- juno-2 could be July 17, July 24 or July 31 (trying to avoid July 24
which is OSCON week)
- juno-3 / feature freeze would be September 4

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [heat] computed package names?

2014-04-16 Thread Qiming Teng


+1 on porting the templates.

What I would suggest also is to restructure the heat-templates directory
layout.  Most of the templates are not so different between OS distros.
Besides this, what the heat-templates project really helps is that the
templates are the best teaching materials for new users.  Having them
stored in sub-directories named by the OS distro is confusing.

Maybe we can consider organize them like what we did for the test cases:

  - most templates are no more than demonstrating only one or two 
features;
  - a template may have a variant only when the changes needed for
running on another OS distro are significant;
  - in template comments, the author is expected to record on which
distros it has been tested;
  - there could be template groups that can be placed into a dedicated
subdirectory -- the templates/scripts are supposed to be used 
together

BTW, did I missed the conclusion from the 'heatr' discussion?

Regards,
  Qiming

On Wed, Apr 16, 2014 at 11:54:51AM +0200, Thomas Spatzier wrote:
> > From: Steven Dake 
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > 
> > Date: 16/04/2014 01:43
> > Subject: Re: [openstack-dev] [heat] computed package names?
> >
> > On 04/15/2014 03:45 PM, Zane Bitter wrote:
> > > On 15/04/14 17:59, Mike Spreitzer wrote:
> > >> Clint Byrum  wrote on 04/15/2014 05:17:21 PM:
> > >>  > Excerpts from Zane Bitter's message of 2014-04-15 13:32:30 -0700:
> > >>  >
> > >>  > > FWIW, in the short term I'm not aware of any issue with
> installing
> > >>  > > mariadb in Fedora 17/18, provided that mysql is not installed
> > >> first. And
> > >>  > > in fact they're both EOL anyway, so we should probably migrate
> > >> all the
> > >>  > > templates to Fedora 20 and mariadb.
> > >>  >
> >
> > The last time I tried F17 images, the database installation step failed
> > miserably because of problems in the base distribution.
> >
> > >>  > +1 for that.
> > >>
> > >> I count 22 templates in heat-templates that are written to support
> > >> Fedora, Ubuntu, and RHEL; is MariaDB available in those?  I do not see
> > >> it in Ubuntu 12.10, for example.
> > >
> > > I imagine it's a problem for RHEL (can RHEL 7 just get released
> > > already?). Ubuntu is not an issue though, unless they have adopted yum
> > > while I was not looking.
> > >
> > > Checking a random sample, they only includes "yum" and "systemd"
> > > sections (no "apt" or "sysvinit") in the metadata, so the purported
> > > support for Ubuntu 10.04 is just due to copy-paste and isn't actually
> > > implemented.
> > >
> > > There is, I thought, one template that does actually support Ubuntu.
> > > Stuff in the "F17" directory is there for a reason.
> > >
> > The only rational reason for having the F17 directory is because nobody
> > has done the work of porting these templates to F20.  That work needs to
> > be done before we can remove the F17 directory permanently :)
> 
> +1 on porting existing templates to current distros. And it would be even
> better to start using some of the new features like software config.
> I have actually started on a WordPress example that uses software config
> and should be to post this for review soon.
> 
> Regards,
> Thomas
> 
> >
> > Regards,
> > -steve
> >
> > > - ZB
> > >
 


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

Re: [openstack-dev] [neutron] Neutron BP review process for Juno

Actually, +1 to that Salvatore! I've found asciiflow.com to be superb
for these types of things.

On Wed, Apr 16, 2014 at 8:39 AM, Salvatore Orlando  wrote:
> if the image you're adding is a diagram, I would think about asciiflow.com
> first!
>
>
> On 16 April 2014 15:09, Kyle Mestery  wrote:
>>
>> I think the problem is that your spec should be at the toplevel of the
>> juno directory, and that's why the UT is failing. Can you move your
>> spec up a level, including the image? You can create a spec images
>> directory to put them in there and reference it in the spec as well if
>> you want.
>>
>> On Tue, Apr 15, 2014 at 11:48 PM, Sumit Naiksatam
>>  wrote:
>> > What's the convention for adding images to the patch? The following
>> > directory structure seemed logical to me (but the current UT will not
>> > allow it):
>> >
>> > specs/juno//.rst
>> > specs/juno//images/.png
>> >
>> > Thanks,
>> > ~Sumit.
>> >
>> >
>> >
>> > On Tue, Apr 15, 2014 at 3:35 PM, Carl Baldwin 
>> > wrote:
>> >> +1.  I think we'll like this process better.  I hope to have some of
>> >> the first blueprints to propose to the new repository very soon.
>> >>
>> >> On Tue, Apr 15, 2014 at 4:07 PM, Kyle Mestery
>> >>  wrote:
>> >>> Given the success the Nova team has had in handling reviews using
>> >>> their new nova-specs gerrit repository, I think it makes a lot of
>> >>> sense for Neutron to do the same. With this in mind, I've added
>> >>> instructions to the BP wiki [1] for how to do. Going forward in Juno,
>> >>> this is how Neutron BPs will be handled by the Neutron core team. If
>> >>> you are currently working on a BP or code for Juno which is attached
>> >>> to a BP, please file the BP using the process here [1].
>> >>>
>> >>> Given this is our first attempt at using this for reviews, I
>> >>> anticipate there may be a few hiccups along the way. Please reply on
>> >>> this thread or reach out in #openstack-neutron and we'll sort through
>> >>> whatever issues we find.
>> >>>
>> >>> Thanks!
>> >>> Kyle
>> >>>
>> >>> [1] https://wiki.openstack.org/wiki/Blueprints#Neutron
>> >>>
>> >>> ___
>> >>> 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] [neutron] Neutron BP review process for Juno

On 04/16/2014 09:39 AM, Salvatore Orlando wrote:
> if the image you're adding is a diagram, I would think about
> asciiflow.com  first!

In all seriousness, I think that's a very nice solution for simple
diagrams.  :-)

For other diagrams, I wonder if it makes sense to just upload them to
the wiki and include links to them from the spec using the image directive.

-- 
Russell Bryant

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

Re: [openstack-dev] [Nova] nova-specs

2014-04-16 Thread Christopher Lefelhocz

I love that we are getting feedback from deployers/operations/etc.  Thanks
to all who have spoken up in support from that perspective.

On 4/16/14 4:02 AM, "Day, Phil"  wrote:

>> 
>They are intended to be high level designs rather than low level designs,
>so no they don't have to include all of the implementation details.
>
>On the other hand they should provided not only the info required to
>decide that the feature is worth implementing, but also enough details so
>that the reviewers can agree on the overall design approach (to avoid
>churn late in the implementation review) and cover a number of other
>areas that can and should be considered before the implementation starts
>but seem too often get overlooked and are quite hard to dig back out from
>the code (like what is the impact going to be on an system that's already
>running).   The template is specifically set up to try and prompt the
>submitter to think about these issues, and I think that brings a huge
>amount of value to this stage.  At the moment I'm seeing a number of
>sections being answered as "None" when really this seems to be "don't
>know" or "didn't think about that" - and I'm thinking that we should ask
>for a simple one-line justification of why there is no impact.

There may be some consistency work needed.  I spent some time/text in
justification around no security impact in a spec.  I was guided
specifically that None was a better statement.

Christopher


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

[openstack-dev] [openstack][nova][specs] Where to store images used in the spec

2014-04-16 Thread Balázs Gibizer

Hi,

I've just uploaded a new BP proposal to gerrit  
https://review.openstack.org/#/c/87978,  but the gate failed as I included an 
image along with the .rst file in my patch. What is the good place to store the 
images that are used in the specs?

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

[openstack-dev] [heat][mistral] Mistral agenda item for Heat community meeting on Apr 17

2014-04-16 Thread Renat Akhmerov

Hi,

Can we include action item “Heat/Mistral collaboration” into the agenda of 
tomorrow’s Heat community meeting? I’d like to take a few minutes and discuss 
this a little bit. If you think it’s not a suitable time/way to discuss it 
please let me know your preferences.

Thanks

Renat Akhmerov
@ Mirantis Inc.




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

Re: [openstack-dev] [TripleO] [Tuskar] Undercloud Ceilometer

2014-04-16 Thread Ladislav Smola

No response so far, but -1 on the image element for making Ceilometer 
optional.


OK, so what about having variable in devtest_variables: USE_TRIPLEO_UI.

It would add Undercloud Ceilometer, Tuskar-UI and Horizon. And Overcloud
SNMPd.

Defaulted to USE_TRIPLEO_UI=1 so we have UI stuff in CI.

How does it sound?


On 04/14/2014 01:31 PM, Ladislav Smola wrote:

Hello,

I am planning to add Ceilometer to Undercloud as default. Since 
Tuskar-UI uses
it as primary source of metering samples and Tuskar should be in 
Undercloud

as default, it made sense to me.

So is my assumption correct or there are some reasons not to do this?

Here are the reviews, that are adding working Undercloud Ceilometer:
https://review.openstack.org/#/c/86915/
https://review.openstack.org/#/c/86917/  (depends on the template change)
https://review.openstack.org/#/c/87215/

Configuration for automatic obtaining of stats from all Overcloud 
nodes via.

SNMP will follow soon.

Thanks,
Ladislav


___
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] Neutron Mid-Cycle Meeting

2014-04-16 Thread Collins, Sean

I just want to quickly caution about having these meetings in person
since not everyone will be able to attend - the summits are probably
where we will have the most Neutron developers able to attend.

It's not that I oppose the idea - but there must be adequate facilities
for people to attend and participate remotely - and that they are not
considered an afterthought.

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

Re: [openstack-dev] [Nova] nova-specs

2014-04-16 Thread Dan Smith

> There may be some consistency work needed.  I spent some time/text in
> justification around no security impact in a spec.  I was guided
> specifically that None was a better statement.

I think you're referring to me. What I said was, you went into a lot of
depth explaining why there was no security impact for things that I felt
were fairly common.

That said, even in code reviews, you're going to get opinions from lots
of different people, and they're not all going to match up 100%. That's
okay, and to be expected, IMHO. It's obviously desirable for us to have
a core (and drivers) team that all have roughly the same opinion on what
is suitable and not, but expecting total consistency is not realistic or
necessary, I think.

Remember that just because someone -1s a patch, doesn't mean that every
single comment they made was -1 worthy on its own. Often times I will -1
for a spelling mistake and then make a bunch of other purely-opinion
comments which don't necessarily need to change.

--Dan


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

Re: [openstack-dev] [Nova] nova-specs

On 04/16/2014 10:13 AM, Christopher Lefelhocz wrote:
> I love that we are getting feedback from deployers/operations/etc.  Thanks
> to all who have spoken up in support from that perspective.
> 
> On 4/16/14 4:02 AM, "Day, Phil"  wrote:
> 
>>>
>> They are intended to be high level designs rather than low level designs,
>> so no they don't have to include all of the implementation details.
>>
>> On the other hand they should provided not only the info required to
>> decide that the feature is worth implementing, but also enough details so
>> that the reviewers can agree on the overall design approach (to avoid
>> churn late in the implementation review) and cover a number of other
>> areas that can and should be considered before the implementation starts
>> but seem too often get overlooked and are quite hard to dig back out from
>> the code (like what is the impact going to be on an system that's already
>> running).   The template is specifically set up to try and prompt the
>> submitter to think about these issues, and I think that brings a huge
>> amount of value to this stage.  At the moment I'm seeing a number of
>> sections being answered as "None" when really this seems to be "don't
>> know" or "didn't think about that" - and I'm thinking that we should ask
>> for a simple one-line justification of why there is no impact.
> 
> There may be some consistency work needed.  I spent some time/text in
> justification around no security impact in a spec.  I was guided
> specifically that None was a better statement.

Yes, consistency is definitely something important that we should work
toward continuously.

For code review, we have a wiki page where we try to gather common
things to look for (lots still to capture, of course):

https://wiki.openstack.org/wiki/ReviewChecklist

For blueprints, we captured review criteria last cycle on this page:

https://wiki.openstack.org/wiki/Blueprints#Blueprint_Review_Criteria

But that's quite high level compared to what we have now.  I think the
best guide for consistency is all of the text we have in the template.


http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/template.rst

Hopefully we'll get better about how we use this guidance as we get more
experience reviewing against it.  Another consistency area we need to
keep an eye on is how these processes and critera are evolving in each
project.  The *-specs processes have evolved quickly, and we should try
to make sure we're not doing this drastically differently across projects.

-- 
Russell Bryant

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

[openstack-dev] [Devstack] [IPv6]

2014-04-16 Thread Robert Li (baoli)

Hi folks,

If you want to use IPv6 with devstack, Check this out
https://review.openstack.org/87987. The commit message has all the details
on how to use it.

thanks,
Robert


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

Re: [openstack-dev] [openstack][nova][specs] Where to store images used in the spec

On 04/16/2014 10:31 AM, Balázs Gibizer wrote:
> Hi,
> 
>  
> 
> I’ve just uploaded a new BP proposal to gerrit
>  https://review.openstack.org/#/c/87978,  but the gate failed as I
> included an image along with the .rst file in my patch. What is the good
> place to store the images that are used in the specs?

That just came up in a Neutron thread:

http://lists.openstack.org/pipermail/openstack-dev/2014-April/032885.html

My opinion for now is:

1) For simple diagrams, try to just use inline ascii.  Try asciiflow.com
for help making a simple ascii diagram.

2) If you really need an image, I think we have two options:

   a) host it on the wiki and inline it using the 'image' directive
  with a link to the image hosted on the wiki.  Then we don't
  have to deal with managing images in the repo and it's easy
  to view the image while doing a spec review.

   b) Allow images in nova-specs, perhaps in a subdirectory with
  the same name as the spec as a new convention.  The benefit
  is the images are more guaranteed to stay static with the
  spec, as it was during review.  The downside is it's more of
  a pain to review, IMO.

Thoughts?

-- 
Russell Bryant

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

Re: [openstack-dev] [Nova] nova-specs

2014-04-16 Thread Matt Van Winkle

On 4/16/14 10:00 AM, "Dan Smith"  wrote:

>
>Remember that just because someone -1s a patch, doesn't mean that every
>single comment they made was -1 worthy on its own. Often times I will -1
>for a spelling mistake and then make a bunch of other purely-opinion
>comments which don't necessarily need to change.

Precisely.  Being very new to the review process (only jumped in when
nova-specs came along), I end up making most of my comments as +0's unless
I'm very confident I can see a major issue with the blueprint, etc.  I
still want to make the point I'm after or ask the questions for sure, but
don't want to inadvertently impede progress if I am off base.  I'm sure
that will change over time as I get more comfortable with more of the nova
underpinnings, but I do wonder if this is advice that should go to any
"new" folks to the review process.  After all, we are hoping to get more
and more.

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

Thanks!
Matt

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

Re: [openstack-dev] [heat][mistral] Mistral agenda item for Heat community meeting on Apr 17

2014-04-16 Thread Zane Bitter


On 16/04/14 10:29, Renat Akhmerov wrote:

Can we include action item “Heat/Mistral collaboration” into the agenda of 
tomorrow’s Heat community meeting? I’d like to take a few minutes and discuss 
this a little bit. If you think it’s not a suitable time/way to discuss it 
please let me know your preferences.


I added it to today's agenda, but for future reference: the agenda is a 
wiki[1] and anyone is welcome to add stuff to it :)


cheers,
Zane.

[1] https://wiki.openstack.org/wiki/Meetings/HeatAgenda

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

[openstack-dev] [python-openstacksdk] Minutes from 15 April Meeting

2014-04-16 Thread Brian Curtin

Minutes: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-04-15-19.00.html

Minutes (text):
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-04-15-19.00.txt

Log: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-04-15-19.00.log.html

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

Re: [openstack-dev] [heat] computed package names?

2014-04-16 Thread Zane Bitter


On 16/04/14 05:53, Thomas Spatzier wrote:

IMO, it would be desirable to not have things like yum or apt appear in the
template explicitly. For many packages it seems like at least the top level
package names (not including distro specific versioning strings) are equal
across distros so when specified in a template it should be possible for a
software deployment hook (which can be distro specific) to figure out how
to install the package.


I think this thread demonstrates the opposite: package names can be 
different even among closely-related distributions (Fedora vs. RHEL) - 
or even versions of the same distribution (Fedora 17 vs. 18). And while 
Ubuntu is derived from Debian (and thus most apt packages are likely to 
share package names), there's no reason whatsoever to expect e.g. 
OpenSUSE to have the same package names as Fedora, despite both being 
based on RPM.


Brian Aker once suggested to me a scheme based on the path to the thing 
you want installed: e.g. you request /usr/bin/httpd and the agent uses 
"yum provides" or the apt equivalent to install the appropriate package. 
That's an idea that might work better, although paths are by no means 
standardised across distros either.


In any event, though, my impression is that we are trying to get out of 
the cfn-init business as much as possible and leave the task to some 
combination of custom images, software config and configuration 
management. Hopefully someone will correct me if that impression is 
inaccurate...


cheers,
Zane.

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

[openstack-dev] [heat] [heat-templates] [qa] [tempest] Questions about images

Many of the templates in the heat-templates project have built-in 
expectations of image names; here is an example excerpt:

F18: {'32': F18-i386-cfntools, '64': F18-x86_64-cfntools}
F17: {'32': F17-i386-cfntools, '64': F17-x86_64-cfntools}
U10: {'32': U10-i386-cfntools, '64': U10-x86_64-cfntools}
RHEL-6.1: {'32': rhel61-i386-cfntools, '64': rhel61-x86_64-cfntools}
RHEL-6.2: {'32': rhel62-i386-cfntools, '64': rhel62-x86_64-cfntools}
RHEL-6.3: {'32': rhel63-i386-cfntools, '64': rhel63-x86_64-cfntools}

>From where should a user get these images?  I have discovered --- I do not 
even remember how --- that there are some images with names like those in 
http://fedorapeople.org/groups/heat/prebuilt-jeos-images/ .  Is that the 
right source?  Is that documented anywhere?

That directory contains only Fedora images.  From where are we expected to 
get the Ubuntu and RHEL images?

That directory does not contain Fedora 20 images.  Should they be added? I 
am willing to do the work if that is the right thing to do; how would I 
create those images?

Do we still need to build special images?  Recent releases of Ubuntu and 
Fedora have cloud-init built in; I assume the same is true for RHEL.

What are good date-independent URLs for recent Fedora releases?  Steve 
Hardy has mentioned http://cloud.fedoraproject.org/fedora-20.x86_64.qcow2 
(and the obvious parallels for release 19 and for 32 bits also exist); I 
know of no other date-independent URLs for Fedora 19 and 20.

For releases that have cloud-init built in, should the templates expect 
image names that are derived in the obvious way from the date-independent 
URL?

http://fedorapeople.org/groups/heat/prebuilt-jeos-images/F19-x86_64-cfntools.qcow2
 
seems to be broken; I get failures every time I try to use it.  Has 
anybody had success with it?  Following is an example failure I found in 
nova-compute.log:

2014-04-16 11:18:02.503 ERROR nova.compute.manager 
[req-b7328d4e-4816-4ab4-ab56-bea856808745 a32cb99086d74eebb46dda1fb9e2c18a 
a79c9abf0e6b4794b6d9c4ee09275902] [instance: 
c975ece9-efc4-450d-9c66-5804b17a5f14] Error: ['Traceback (most recent call 
last):\n', '  File 
"/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 864, in 
_run_instance\nset_access_ip=set_access_ip)\n', '  File 
"/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 1123, in 
_spawn\nLOG.exception(_(\'Instance failed to spawn\'), 
instance=instance)\n', '  File "/usr/lib/python2.7/contextlib.py", line 
24, in __exit__\nself.gen.next()\n', '  File 
"/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 1119, in 
_spawn\nblock_device_info)\n', '  File 
"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 1524, 
in spawn\nadmin_pass=admin_password)\n', '  File 
"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 1809, 
in _create_image\nproject_id=instance[\'project_id\'])\n', '  File 
"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/imagebackend.py", line 
158, in cache\n*args, **kwargs)\n', '  File 
"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/imagebackend.py", line 
259, in create_image\nprepare_template(target=base, *args, 
**kwargs)\n', '  File 
"/usr/lib/python2.7/dist-packages/nova/openstack/common/lockutils.py", 
line 228, in inner\nretval = f(*args, **kwargs)\n', '  File 
"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/imagebackend.py", line 
146, in call_if_not_exists\nfetch_func(target=target, *args, 
**kwargs)\n', '  File 
"/usr/lib/python2.7/dist-packages/nova/virt/libvirt/utils.py", line 597, 
in fetch_image\nimages.fetch_to_raw(context, image_id, target, 
user_id, project_id)\n', '  File 
"/usr/lib/python2.7/dist-packages/nova/virt/images.py", line 227, in 
fetch_to_raw\nconvert_image(path_tmp, staged, \'raw\')\n', '  File 
"/usr/lib/python2.7/dist-packages/nova/virt/images.py", line 190, in 
convert_image\nutils.execute(*cmd, run_as_root=run_as_root)\n', ' File 
"/usr/lib/python2.7/dist-packages/nova/utils.py", line 239, in execute\n  
cmd=\' \'.join(cmd))\n', "ProcessExecutionError: Unexpected error while 
running command.\nCommand: qemu-img convert -O raw 
/openstack/nova/instances/_base/bb53856c59a6da7fecda0201357e155fdd23f075.part 
/openstack/nova/instances/_base/bb53856c59a6da7fecda0201357e155fdd23f075.converted\nExit
 
code: 1\nStdout: ''\nStderr: 'qemu-img: error while reading sector 
7397376: Input/output error\\n'\n"]

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

[openstack-dev] Seeking interest in an open Content Delivery Network (CDN) API

2014-04-16 Thread Amit Gandhi

OpenStack,

Our team is currently seeking partners who share an interest and
enthusiasm for exploring the possibility of Content Delivery Network (CDN)
capabilities within the open ecosystem. Our desire is to create a unified
and open API that leverages existing CDN providers in an open
source-friendly way.
 

Today, there are a large number of CDN providers who offer similar CDN
capabilities with widely-differing APIs. Applications built around these
current CDN offerings are usually locked into that vendor.  Changing a CDN
provider typically requires significant software and operational changes
on the part of the application developer.

We would like to start a dialog with other organizations and individuals
in the community that would like to work together to solve this common
problem.  We would like to identify the community needs and flesh out the
features of an open CDN API that supports multiple CDN providers.

Together, we can build an offering that helps remove vendor lock in to
existing CDN providers.

When the time is right, this team of interested parties can determine
where this project should live (e.g. OpenStack), or find the ecosystem
that makes the most sense.

We are looking for contributors from the community.  Please contact me
directly for an initial conversation on your needs and interest.  I will
then set up a community brainstorming session on IRC and we can also
discuss it at the Atlanta OpenStack Summit.


Thanks,

Amit Gandhi
Rackspace  Atlanta


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

Re: [openstack-dev] [neutron] Neutron BP review process for Juno

2014-04-16 Thread Solly Ross

Additionally, storing lots of binary blobs in a Git repo is sub-optimal,
as the repo size ballons very quickly.  Storing images on the Wiki, or
elsewhere that has stable image hosting, is a much better solution, IMHO
(but try asciiflow or asciiflow traditional first!).

Best Regards,
Solly Ross

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

Sent: Wednesday, April 16, 2014 9:52:09 AM
Subject: Re: [openstack-dev] [neutron] Neutron BP review process for Juno

Actually, +1 to that Salvatore! I've found asciiflow.com to be superb
for these types of things.

On Wed, Apr 16, 2014 at 8:39 AM, Salvatore Orlando  wrote:
> if the image you're adding is a diagram, I would think about asciiflow.com
> first!
>
>
> On 16 April 2014 15:09, Kyle Mestery  wrote:
>>
>> I think the problem is that your spec should be at the toplevel of the
>> juno directory, and that's why the UT is failing. Can you move your
>> spec up a level, including the image? You can create a spec images
>> directory to put them in there and reference it in the spec as well if
>> you want.
>>
>> On Tue, Apr 15, 2014 at 11:48 PM, Sumit Naiksatam
>>  wrote:
>> > What's the convention for adding images to the patch? The following
>> > directory structure seemed logical to me (but the current UT will not
>> > allow it):
>> >
>> > specs/juno//.rst
>> > specs/juno//images/.png
>> >
>> > Thanks,
>> > ~Sumit.
>> >
>> >
>> >
>> > On Tue, Apr 15, 2014 at 3:35 PM, Carl Baldwin 
>> > wrote:
>> >> +1.  I think we'll like this process better.  I hope to have some of
>> >> the first blueprints to propose to the new repository very soon.
>> >>
>> >> On Tue, Apr 15, 2014 at 4:07 PM, Kyle Mestery
>> >>  wrote:
>> >>> Given the success the Nova team has had in handling reviews using
>> >>> their new nova-specs gerrit repository, I think it makes a lot of
>> >>> sense for Neutron to do the same. With this in mind, I've added
>> >>> instructions to the BP wiki [1] for how to do. Going forward in Juno,
>> >>> this is how Neutron BPs will be handled by the Neutron core team. If
>> >>> you are currently working on a BP or code for Juno which is attached
>> >>> to a BP, please file the BP using the process here [1].
>> >>>
>> >>> Given this is our first attempt at using this for reviews, I
>> >>> anticipate there may be a few hiccups along the way. Please reply on
>> >>> this thread or reach out in #openstack-neutron and we'll sort through
>> >>> whatever issues we find.
>> >>>
>> >>> Thanks!
>> >>> Kyle
>> >>>
>> >>> [1] https://wiki.openstack.org/wiki/Blueprints#Neutron
>> >>>
>> >>> ___
>> >>> 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] computed package names?

Zane Bitter  wrote on 04/16/2014 11:39:56 AM:

> In any event, though, my impression is that we are trying to get out of 
> the cfn-init business as much as possible and leave the task to some 
> combination of custom images, software config and configuration 
> management. Hopefully someone will correct me if that impression is 
> inaccurate...

The circle is now complete.

I set out to exercise the new software config work.  I decided I would try 
to write software components and deployments to accomplish what is done in 
one of the templates found in heat-templates.  I wanted to try a 
two-server WordPress example.  I wanted to test the existing template.  I 
found they were all using outdated images.  I thought I would update an 
existing template --- which already appeared to allow a choice between 
many operating system releases --- to add support for something recent.

I sent some questions about images under separate cover.  Answers to those 
would break today's circle.

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

Re: [openstack-dev] [all] Branchless Tempest QA Spec - final draft

2014-04-16 Thread Jaume Devesa

Hi Sean,

for what I understood, we will need a new feature flag for each new
feature, and a feature flag (default to false) for each deprecated one. My
concern is: since the goal is make tempest a confident tool to test any
installation and not and 'tempest.conf' will not be auto-generated from any
tool as devstack does, wouldn't be too hard to prepare a tempest.conf file
with so many feature flags to enable and disable?

Maybe I am simplifying too much, but wouldn't be enough with a pair of
functions decorators like

@new
@deprecated

Then, in tempest.conf it could be a flag to say which OpenStack
installation are you testing:

installation = [icehouse|juno]

if you choose Juno, tests with @new decorator will be executed and tests
with @deprecated will be skipped.
If you choose Icehouse, tests with @new decorator will be skipped, and
tests with @deprecated will be executed

I am missing some obvious case that make this approach a nonsense?

Regards,
jaume

On 14 April 2014 15:21, Sean Dague  wrote:

> As we're coming up on the stable/icehouse release the QA team is looking
> pretty positive at no longer branching Tempest. The QA Spec draft for
> this is here -
>
> http://docs-draft.openstack.org/77/86577/2/check/gate-qa-specs-docs/3f84796/doc/build/html/specs/branchless-tempest.html
> and hopefully address a lot of the questions we've seen so far.
>
> Additional comments are welcome on the review -
> https://review.openstack.org/#/c/86577/
> or as responses on this ML thread.
>
> -Sean
>
> --
> Sean Dague
> Samsung Research America
> s...@dague.net / sean.da...@samsung.com
> 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] [Openstack] About advice for Contribution

2014-04-16 Thread Solly Ross

If you start contributing to Nova, my advice would be to start small -- find a 
part of Nova
that you get to know well, and then branch out.  Nova is a large project with 
complex paths
through the code (RPC vs REST API vs normal method calling), so it can take a 
bit of time to
get used to.

You could also take a look at Oslo -- it's component-agnostic and the different 
parts tend to
be a bit smaller than the other components.

Hope this helps, and good luck!  We're always glad to have new contributors!

Best Regards,
Solly Ross

- Original Message -
From: "Mayur Patil" 
To: "Openstack Users" , "Openstack Developer" 

Sent: Wednesday, April 16, 2014 3:27:24 AM
Subject: [openstack-dev] [Openstack] About advice for Contribution

Howdy All, 

I need a small advice. I am working from last two years on Eucalyptus. 

Recently, switched to Openstack and trying to contribute to Code-Base. 

My skills are: 

- I have good understanding of private Cloud 

- Total beginner in Python but somewhat good at Java 

Except SWIFT & NEUTRON , I am clear with other components concepts. 

so which project/component should I study to get started for Openstack 

Development ? 

Seeking for guidance, 

Thanks ! 
-- 
Cheers, 
Mayur S. Patil, 
Pune. 

Contact : 




___
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] Vagrant Devstack projects - time to consolidate?

2014-04-16 Thread Collins, Sean

On Tue, Apr 15, 2014 at 04:30:53PM EDT, Joe Gordon wrote:
> One of my biggest issues with running devstack in vagrant is how slow
> it is

The vagrant_devstack project (github.com/bcwaldon/vagrant_devstack) has
some Chef recipes to cache pip and apt - so it's only the first run that
is slow, and rebuilds are sped up.

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

Re: [openstack-dev] [neutron] Neutron Mid-Cycle Meeting

2014-04-16 Thread Fawad Khaliq

+1 to Sean

Fawad Khaliq
(m) +1 408.966.2214


On Wed, Apr 16, 2014 at 7:54 AM, Collins, Sean <
sean_colli...@cable.comcast.com> wrote:

> I just want to quickly caution about having these meetings in person
> since not everyone will be able to attend - the summits are probably
> where we will have the most Neutron developers able to attend.
>
> It's not that I oppose the idea - but there must be adequate facilities
> for people to attend and participate remotely - and that they are not
> considered an afterthought.
>
> --
> Sean M. Collins
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] nova-specs

2014-04-16 Thread Christopher Lefelhocz

On 4/16/14 10:00 AM, "Dan Smith"  wrote:

>> There may be some consistency work needed.  I spent some time/text in
>> justification around no security impact in a spec.  I was guided
>> specifically that None was a better statement.
>
>I think you're referring to me. What I said was, you went into a lot of
>depth explaining why there was no security impact for things that I felt
>were fairly common.

Yeah, agreed.  As I responded, it has more to do with working in
environments where security always needed to be answered (regardless of
triviality).  "None" wasn't acceptable.  The template to my reading didn't
really guide in this regard.  I may have missed something though.

>
>That said, even in code reviews, you're going to get opinions from lots
>of different people, and they're not all going to match up 100%. That's
>okay, and to be expected, IMHO. It's obviously desirable for us to have
>a core (and drivers) team that all have roughly the same opinion on what
>is suitable and not, but expecting total consistency is not realistic or
>necessary, I think.

I'm not asking for 100% consistency.  I'm just raising it since it seems
to be early in the process change and want to work out these kinds of
things.  If it turns out to be an outlier then great.

Perhaps a better way for me to say it, is we should be on the lookout
given the process is new for consistency concerns.  It's probably too
idealistic, but I would rather have a 1-3 spec review cycle rather
especially for the smaller features.  That's my main concern with having
some consistency moving forward.  That's also on the developer side.  If
they have the tools to generate the spec correct the first go-around it
helps everyone.

>
>Remember that just because someone -1s a patch, doesn't mean that every
>single comment they made was -1 worthy on its own. Often times I will -1
>for a spelling mistake and then make a bunch of other purely-opinion
>comments which don't necessarily need to change.

Sure, but I also take -1s seriously and try to address them as best I can.
 Even if they are purely-opinion.

Christopher

>
>--Dan
>
>
>___
>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] [openstack][nova][specs] Where to store images used in the spec

2014-04-16 Thread Balázs Gibizer

Thanks for the pointer to the Neutron thread. After reading it through
I decided to move the image to wiki.

Thanks,
Gibi

-Original Message-
From: Russell Bryant [mailto:rbry...@redhat.com] 
Sent: Wednesday, April 16, 2014 5:09 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [openstack][nova][specs] Where to store images 
used in the spec

On 04/16/2014 10:31 AM, Balázs Gibizer wrote:
> Hi,
> 
>  
> 
> I've just uploaded a new BP proposal to gerrit  
> https://review.openstack.org/#/c/87978,  but the gate failed as I 
> included an image along with the .rst file in my patch. What is the 
> good place to store the images that are used in the specs?

That just came up in a Neutron thread:

http://lists.openstack.org/pipermail/openstack-dev/2014-April/032885.html

My opinion for now is:

1) For simple diagrams, try to just use inline ascii.  Try asciiflow.com for 
help making a simple ascii diagram.

2) If you really need an image, I think we have two options:

   a) host it on the wiki and inline it using the 'image' directive
  with a link to the image hosted on the wiki.  Then we don't
  have to deal with managing images in the repo and it's easy
  to view the image while doing a spec review.

   b) Allow images in nova-specs, perhaps in a subdirectory with
  the same name as the spec as a new convention.  The benefit
  is the images are more guaranteed to stay static with the
  spec, as it was during review.  The downside is it's more of
  a pain to review, IMO.

Thoughts?

--
Russell Bryant

___
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] API list operations are not fast as they could because they're dumb

2014-04-16 Thread Salvatore Orlando

Checking whether a policy used for visibility depends on an attribute value
is possible. I just don't think it's right.
For instance, one could define the following policies:

"the_funny_one": "field:networks:name=Funny"
"get_network:provider:physical_network": "rule:admin_only or
rule:the_funny_one"

And cause provider network details to be shown to everyone if the name of
the network was "Funny".
While this is clearly a dumb example, the problem I have with it is that it
will produce list results which basically are not tables, meaning that each
row might potentially have a different set of columns.
I wanted to go to further and just remove all attribute visibility policies
from policy.json. Attribute access level would have been defined in the
attribute map. However this might have broken some existing deployments, so
I think unfortunately it's not the case to do this change.

Finally, since I did not see any opposition to the proposed approach, I'm
going to smooth out the patch I linked and propose it to gerrit.

Salvatore


On 13 April 2014 21:49, Eugene Nikanorov  wrote:

> Hi Salvatore,
>
> > For this reason I am thinking we should what technically is a simple
> change: use policy checks determine the list of attributes to show only
> once for list response, and then re-use that list for the whole response.
>
> I'm +1 to this idea.
> Also, would it be too difficult to have some insight into set of policy
> rules and see, if there are any rules that apply per attribute value of
> given resource? If no - use simplified approach, if yes - fallback to
> existing slow one.
> Wouldn't it both speedup most of operations while preserving existing
> deployments?
>
> Thanks,
> Eugene.
>
>
> On Wed, Apr 9, 2014 at 2:16 AM, Salvatore Orlando wrote:
>
>> I have been recently investigating reports of slowness for list responses
>> in the Neutron API.
>> This was first reported in [1], and then recently was observed with both
>> the ML2 and the NSX plugins.
>>  The root cause of this issues is that a policy engine check is performed
>> for every attribute of every resource returned in a response.
>> When tenant grow to a lot of ports, or when the API is executed with
>> admin credentials without filters, this might become a non-negligible scale
>> issue.
>> This issue is mostly due to three factors:
>> 1) A log statement printing a line in the log for every attribute for
>> which no policy criterion is defined; this has been treated with [2]
>> 2) The fact that for every check neutron currently checks whether cached
>> policy rules are still valid [3]
>> 3) The fact that anyway Neutron perform really a lot of policy checks
>> whether it should not
>>
>> Despite the improvements [2] and [3] (mostly [2]), neutron for a list
>> operation still spends for post-plugin operations (ie: policy checks) abotu
>> 50% of the time it spends in the plugin.
>> Solving this problem is not difficult, but it might require changes which
>> are worth of a discussion on the mailing list.
>> Up to the Havana release policy checks were performed in the plugin; this
>> basically made responses dependent on plugin implementation and was
>> terrible for API compatibility and portability; we took care of that with
>> [4], which moved all policy checks to the API layer. However for one fix
>> that we fixed, another thing was broken (*)
>>
>> The API layer for list responses puts every item through policy checks to
>> see which should not be visible to the user at all, which is fine.
>> However it also puts every attribute through a policy check to exclude
>> those which should not be visible to the user, such as provider attributes
>> for regular users.
>> Doing this for every resource might make sense if an attribute should be
>> visible or not according to the data in the resource itself.
>> For instance a policy that shows port binding attributes could be defined
>> for all the ports whose name is "ernest".
>> This might appear as great flexibility, but does it make any sense at all?
>> Does it make sense that an API list operation return a set of attributes
>> for some items and  a different one for others?
>> I think not.
>>
>> For this reason I am thinking we should what technically is a simple
>> change: use policy cghecks determine the list of attributes to show only
>> once for list response, and then re-use that list for the whole response.
>> The limitation here is that we should not have 'attribute-level' policies
>> (**) which rely on the resource value.
>> I think this limitation is fair. If you like the approach I have some
>> code here: http://paste.openstack.org/show/75371/
>>
>> And this leads me to the second part of the discussion I'd like to start.
>> The policy engine currently allows me to start a neutron server where,
>> for instance, port binding are visible by admins only, and another neutron
>> server where any user can see them.
>> This kind of makes the API not really portable, as people programming
>> against th

Re: [openstack-dev] [Nova][blueprint] Accelerate the booting process of a number of vms via VMThunder

2014-04-16 Thread Zhi Yan Liu

Hello Yongquan Fu,

My thoughts:

1. Currently Nova has already supported image caching mechanism. It
could caches the image on compute host which VM had provisioning from
it before, and next provisioning (boot same image) doesn't need to
transfer it again only if cache-manger clear it up.
2. P2P transferring and prefacing is something that still based on
copy mechanism, IMHO, zero-copy approach is better, even
transferring/prefacing could be optimized by such approach. (I have
not check "on-demand transferring" of VMThunder, but it is a kind of
transferring as well, at last from its literal meaning).
And btw, IMO, we have two ways can go follow zero-copy idea:
a. when Nova and Glance use same backend storage, we could use storage
special CoW/snapshot approach to prepare VM disk instead of
copy/transferring image bits (through HTTP/network or local copy).
b. without "unified" storage, we could attach volume/LUN to compute
node from backend storage as a base image, then do such CoW/snapshot
on it to prepare root/ephemeral disk of VM. This way just like
boot-from-volume but different is that we do CoW/snapshot on Nova side
instead of Cinder/storage side.

For option #a, we have already got some progress:
https://blueprints.launchpad.net/nova/+spec/image-multiple-location
https://blueprints.launchpad.net/nova/+spec/rbd-clone-image-handler
https://blueprints.launchpad.net/nova/+spec/vmware-clone-image-handler

Under #b approach, my former experience from our previous similar
Cloud deployment (not OpenStack) was that: under 2 PC server storage
nodes (general *local SAS disk*, without any storage backend) +
2-way/multi-path iSCSI + 1G network bandwidth, we can provisioning 500
VMs in a minute.

For vmThunder topic I think it sounds a good idea, IMO P2P, prefacing
is one of optimized approach for image transferring valuably.

zhiyan

On Wed, Apr 16, 2014 at 9:14 PM, yongquan Fu  wrote:
>
> Dear all,
>
>
>
>  We would like to present an extension to the vm-booting functionality of
> Nova when a number of homogeneous vms need to be launched at the same time.
>
>
>
> The motivation for our work is to increase the speed of provisioning vms for
> large-scale scientific computing and big data processing. In that case, we
> often need to boot tens and hundreds virtual machine instances at the same
> time.
>
>
> Currently, under the Openstack, we found that creating a large number of
> virtual machine instances is very time-consuming. The reason is the booting
> procedure is a centralized operation that involve performance bottlenecks.
> Before a virtual machine can be actually started, OpenStack either copy the
> image file (swift) or attach the image volume (cinder) from storage server
> to compute node via network. Booting a single VM need to read a large amount
> of image data from the image storage server. So creating a large number of
> virtual machine instances would cause a significant workload on the servers.
> The servers become quite busy even unavailable during the deployment phase.
> It would consume a very long time before the whole virtual machine cluster
> useable.
>
>
>
>   Our extension is based on our work on vmThunder, a novel mechanism
> accelerating the deployment of large number virtual machine instances. It is
> written in Python, can be integrated with OpenStack easily. VMThunder
> addresses the problem described above by following improvements: on-demand
> transferring (network attached storage), compute node caching, P2P
> transferring and prefetching. VMThunder is a scalable and cost-effective
> accelerator for bulk provisioning of virtual machines.
>
>
>
>   We hope to receive your feedbacks. Any comments are extremely welcome.
> Thanks in advance.
>
>
>
> PS:
>
>
>
> VMThunder enhanced nova blueprint:
> https://blueprints.launchpad.net/nova/+spec/thunderboost
>
>  VMThunder standalone project: https://launchpad.net/vmthunder;
>
>  VMThunder prototype: https://github.com/lihuiba/VMThunder
>
>  VMThunder etherpad: https://etherpad.openstack.org/p/vmThunder
>
>  VMThunder portal: http://www.vmthunder.org/
>
> VMThunder paper: http://www.computer.org/csdl/trans/td/preprint/06719385.pdf
>
>
>
>   Regards
>
>
>
>   vmThunder development group
>
>   PDL
>
>   National University of Defense Technology
>
>
> ___
> 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] Neutron BP review process for Juno

2014-04-16 Thread trinath.soman...@freescale.com

Hi Mestery

With respect to the new BP review process, can we start submitting the BPs in 
the review system and in the launchpad. 

Since, BP is a thought process of the developer either for core dev or for 
vendor specific dev,
can you give some light on how the review process of the BP can be ?

asciiflow.com is a best tool for showing the pictorial representation of the BP 
work. Thank you for the link..

Were there any variations in general code review processes.

-
Trinath


From: Kyle Mestery 
Sent: Wednesday, April 16, 2014 7:22 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Neutron BP review process for Juno

Actually, +1 to that Salvatore! I've found asciiflow.com to be superb
for these types of things.

On Wed, Apr 16, 2014 at 8:39 AM, Salvatore Orlando  wrote:
> if the image you're adding is a diagram, I would think about asciiflow.com
> first!
>
>
> On 16 April 2014 15:09, Kyle Mestery  wrote:
>>
>> I think the problem is that your spec should be at the toplevel of the
>> juno directory, and that's why the UT is failing. Can you move your
>> spec up a level, including the image? You can create a spec images
>> directory to put them in there and reference it in the spec as well if
>> you want.
>>
>> On Tue, Apr 15, 2014 at 11:48 PM, Sumit Naiksatam
>>  wrote:
>> > What's the convention for adding images to the patch? The following
>> > directory structure seemed logical to me (but the current UT will not
>> > allow it):
>> >
>> > specs/juno//.rst
>> > specs/juno//images/.png
>> >
>> > Thanks,
>> > ~Sumit.
>> >
>> >
>> >
>> > On Tue, Apr 15, 2014 at 3:35 PM, Carl Baldwin 
>> > wrote:
>> >> +1.  I think we'll like this process better.  I hope to have some of
>> >> the first blueprints to propose to the new repository very soon.
>> >>
>> >> On Tue, Apr 15, 2014 at 4:07 PM, Kyle Mestery
>> >>  wrote:
>> >>> Given the success the Nova team has had in handling reviews using
>> >>> their new nova-specs gerrit repository, I think it makes a lot of
>> >>> sense for Neutron to do the same. With this in mind, I've added
>> >>> instructions to the BP wiki [1] for how to do. Going forward in Juno,
>> >>> this is how Neutron BPs will be handled by the Neutron core team. If
>> >>> you are currently working on a BP or code for Juno which is attached
>> >>> to a BP, please file the BP using the process here [1].
>> >>>
>> >>> Given this is our first attempt at using this for reviews, I
>> >>> anticipate there may be a few hiccups along the way. Please reply on
>> >>> this thread or reach out in #openstack-neutron and we'll sort through
>> >>> whatever issues we find.
>> >>>
>> >>> Thanks!
>> >>> Kyle
>> >>>
>> >>> [1] https://wiki.openstack.org/wiki/Blueprints#Neutron
>> >>>
>> >>> ___
>> >>> 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] [nova] unit tests method

2014-04-16 Thread Ben Nemec


On 04/16/2014 08:11 AM, Jay Pipes wrote:

On Wed, 2014-04-16 at 14:55 +0800, Chen CH Ji wrote:

Hi
 There are 3 types of unit test existing now (stub, mox
and mock)
 Several code reviewers suggest to use mock instead of
using the other 2 and I am following it, but I want to know where can
I find the suggestion and guide line?


Hi Kevin!

So, there are only two unit testing methods -- mock and mox. stubs are
part of the mox-style way of doing things.

My general rules of thumb when doing reviews in Nova are these:

1) For new unit tests, use mock
2) Don't mix mock and mox in a single test method
3) When modifying existing unit tests, unless rewriting the test method
almost entirely, stick with whatever is used already (mock or mox)

Best,
-jay


These points are also documented here: 
https://wiki.openstack.org/wiki/ReviewChecklist (see point 4 under the 
Common Review Checklist)


-Ben


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

Re: [openstack-dev] [Openstack] About advice for Contribution

2014-04-16 Thread Mayur Patil

Thanks Solly for Guidance.

I also hope to get familiar with NOVA internals soon.

Thanks !

On Wed, Apr 16, 2014 at 9:20 PM, Solly Ross  wrote:

> If you start contributing to Nova, my advice would be to start small --
> find a part of Nova
> that you get to know well, and then branch out.  Nova is a large project
> with complex paths
> through the code (RPC vs REST API vs normal method calling), so it can
> take a bit of time to
> get used to.
>
> You could also take a look at Oslo -- it's component-agnostic and the
> different parts tend to
> be a bit smaller than the other components.
>
> Hope this helps, and good luck!  We're always glad to have new
> contributors!
>
> Best Regards,
> Solly Ross
>
> - Original Message -
> From: "Mayur Patil" 
> To: "Openstack Users" , "Openstack
> Developer" 
> Sent: Wednesday, April 16, 2014 3:27:24 AM
> Subject: [openstack-dev] [Openstack] About advice for Contribution
>
> Howdy All,
>
> I need a small advice. I am working from last two years on Eucalyptus.
>
> Recently, switched to Openstack and trying to contribute to Code-Base.
>
> My skills are:
>
> - I have good understanding of private Cloud
>
> - Total beginner in Python but somewhat good at Java
>
> Except SWIFT & NEUTRON , I am clear with other components concepts.
>
> so which project/component should I study to get started for Openstack
>
> Development ?
>
> Seeking for guidance,
>

*-- *

*Cheers,Mayur* S. Patil,
Pune.

Contact :
  




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

Re: [openstack-dev] [Nova] nova-specs

2014-04-16 Thread Dan Smith

> I'm not asking for 100% consistency.  I'm just raising it since it seems
> to be early in the process change and want to work out these kinds of
> things.  If it turns out to be an outlier then great.

Sure, and the spec reviewers are learning in this process as well. It
takes a certain amount of us seeing what other reviewers think is
reasonable and not before we establish a baseline. I'm sure that after
we've done this for a cycle or two, things will look a lot more
consistent :)

--Dan

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

[openstack-dev] open question about keystone-configuration

2014-04-16 Thread Wang, Min


Hello there,

My name is Min Wang, and I am working in HP cloud compute team. I got a 
question regarding keystone configuration and need guidance.

So I am following the instruction in this pdf file: 
http://docs.openstack.org/havana/install-guide/install/apt/openstack-install-guide-apt-havana.pdf
When I type these command line in the vm, I got errors, which I don’t know how 
to solve
First, create a tenant for an administrative user and a tenant for other 
OpenStack services
to use.
# keystone tenant-create --name=admin --description="Admin Tenant"
# keystone tenant-create --name=service --description="Service Tenant"

The following is what I got:

openstack@ubuntu:~$  keystone tenant-create --name=admin --description="Admin 
Tenant"
An unexpected error prevented the server from fulfilling your request. 
(ProgrammingError) (1146, "Table 'keystone.token' doesn't exist") 'SELECT 
token.id AS token_id, token.expires AS token_expires, token.extra AS 
token_extra, token.valid AS token_valid, token.user_id AS token_user_id, 
token.trust_id AS token_trust_id \nFROM token \nWHERE token.id = %s' 
('75c91af688178897bcdb',) (HTTP 500)

openstack@ubuntu:~$ sudo keystone tenant-create --name=admin 
--description="Admin Tenant"
Expecting an auth URL via either --os-auth-url or env[OS_AUTH_URL]

All of the steps above these command lines got good result,I am not sure where 
is the error source.

Best Regards and Many thanks!

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

Re: [openstack-dev] [openstack][nova][specs] Where to store images used in the spec

On 04/16/2014 12:00 PM, Balázs Gibizer wrote:
> Thanks for the pointer to the Neutron thread. After reading it through
> I decided to move the image to wiki.

OK.  I think your diagram is probably doable in ascii, though.  :-)

-- 
Russell Bryant

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

Re: [openstack-dev] open question about keystone-configuration

2014-04-16 Thread Adam Young


On 04/16/2014 12:15 PM, Wang, Min wrote:


Hello there,

My name is Min Wang, and I am working in HP cloud compute team. I got 
a question regarding keystone configuration and need guidance.


So I am following the instruction in this pdf file: 
http://docs.openstack.org/havana/install-guide/install/apt/openstack-install-guide-apt-havana.pdf


When I type these command line in the vm, I got errors, which I don't 
know how to solve


First, create a tenant for an administrative user and a tenant for 
other OpenStack services


to use.

# keystone tenant-create --name=admin --description="Admin Tenant"

# keystone tenant-create --name=service --description="Service Tenant"

The following is what I got:

openstack@ubuntu:~$  keystone tenant-create --name=admin 
--description="Admin Tenant"


An unexpected error prevented the server from fulfilling your request. 
(ProgrammingError) (1146, "Table 'keystone.token' doesn't exist") 
'SELECT token.id AS token_id, token.expires AS token_expires, 
token.extra AS token_extra, token.valid AS token_valid, token.user_id 
AS token_user_id, token.trust_id AS token_trust_id \nFROM token 
\nWHERE token.id = %s' ('75c91af688178897bcdb',) (HTTP 500)




Did you run keystone_manage db_sync?  You can confirm with 
keystone_manage db_version


openstack@ubuntu:~$ sudo keystone tenant-create --name=admin 
--description="Admin Tenant"


Expecting an auth URL via either --os-auth-url or env[OS_AUTH_URL]

All of the steps above these command lines got good result,I am not 
sure where is the error source.


Best Regards and Many thanks!



___
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] computed package names?

2014-04-16 Thread Fox, Kevin M

Different distro's move the binaries and services too. ubuntu/debian does:
/usr/sbin/apache2, not httpd. The service is also named apache2, not httpd.

So, I think distro specific sets of packages are somewhat unavoidable.

Now, this use case might be a good case for supporting:
https://blueprints.launchpad.net/heat/+spec/intrinsics
https://blueprints.launchpad.net/heat/+spec/aws-novalue

Amazon finally caved in and implemented these. I think heat needs them too.

Is it possible to implement those with the new plugin function framework? If 
so, I might be willing to take a stab at it if I can find a bit of time.

Thanks,
Kevin

From: Zane Bitter [zbit...@redhat.com]
Sent: Wednesday, April 16, 2014 8:39 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat] computed package names?

On 16/04/14 05:53, Thomas Spatzier wrote:
> IMO, it would be desirable to not have things like yum or apt appear in the
> template explicitly. For many packages it seems like at least the top level
> package names (not including distro specific versioning strings) are equal
> across distros so when specified in a template it should be possible for a
> software deployment hook (which can be distro specific) to figure out how
> to install the package.

I think this thread demonstrates the opposite: package names can be
different even among closely-related distributions (Fedora vs. RHEL) -
or even versions of the same distribution (Fedora 17 vs. 18). And while
Ubuntu is derived from Debian (and thus most apt packages are likely to
share package names), there's no reason whatsoever to expect e.g.
OpenSUSE to have the same package names as Fedora, despite both being
based on RPM.

Brian Aker once suggested to me a scheme based on the path to the thing
you want installed: e.g. you request /usr/bin/httpd and the agent uses
"yum provides" or the apt equivalent to install the appropriate package.
That's an idea that might work better, although paths are by no means
standardised across distros either.

In any event, though, my impression is that we are trying to get out of
the cfn-init business as much as possible and leave the task to some
combination of custom images, software config and configuration
management. Hopefully someone will correct me if that impression is
inaccurate...

cheers,
Zane.

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

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

Re: [openstack-dev] [Openstack] open question about keystone-configuration

2014-04-16 Thread Mayur Patil

Hi Min Wang,

  This is error might be due to permission problem you *must run *these
commands from root.

  The command *  openssh rand -hex 10*

  will create the token which you have to put in
/etc/keystone/keystone.conf in admin section.

  the mentioned command

  # export OS_SERVICE_TOKEN=
  # export OS_SERVICE_ENDPOINT=http://controller:35357/v2.0

 by executing this command as root you will not the error again.

 Hope this helps !

 Thanks !

-- 

*Cheers,Mayur* S. Patil,
Pune.

Contact :
  




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

Re: [openstack-dev] [openstack][nova][specs] Where to store images used in the spec

2014-04-16 Thread Kevin Benton

The only downside to putting it on the wiki is that it no longer has a
shared fate with the specification in the repo. If someone deletes it or
replaces it on the wiki, information for the spec is lost. External
connectivity is also required just to view a template as well.




On Wed, Apr 16, 2014 at 8:09 AM, Russell Bryant  wrote:

> On 04/16/2014 10:31 AM, Balázs Gibizer wrote:
> > Hi,
> >
> >
> >
> > I’ve just uploaded a new BP proposal to gerrit
> >  https://review.openstack.org/#/c/87978,  but the gate failed as I
> > included an image along with the .rst file in my patch. What is the good
> > place to store the images that are used in the specs?
>
> That just came up in a Neutron thread:
>
> http://lists.openstack.org/pipermail/openstack-dev/2014-April/032885.html
>
> My opinion for now is:
>
> 1) For simple diagrams, try to just use inline ascii.  Try asciiflow.com
> for help making a simple ascii diagram.
>
> 2) If you really need an image, I think we have two options:
>
>a) host it on the wiki and inline it using the 'image' directive
>   with a link to the image hosted on the wiki.  Then we don't
>   have to deal with managing images in the repo and it's easy
>   to view the image while doing a spec review.
>
>b) Allow images in nova-specs, perhaps in a subdirectory with
>   the same name as the spec as a new convention.  The benefit
>   is the images are more guaranteed to stay static with the
>   spec, as it was during review.  The downside is it's more of
>   a pain to review, IMO.
>
> Thoughts?
>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [Devstack] [IPv6]

2014-04-16 Thread Martinx - ジェームズ

Awesome!! I'll check this today! Tks!


On 16 April 2014 12:03, Robert Li (baoli)  wrote:

> Hi folks,
>
> If you want to use IPv6 with devstack, Check this out
> https://review.openstack.org/87987. The commit message has all the details
> on how to use it.
>
> thanks,
> Robert
>
>
> ___
> 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] Hyper-V CI is broken

2014-04-16 Thread Joe Gordon

On Wed, Apr 16, 2014 at 6:04 AM, Peter Pouliot wrote:

>  Hey Joe,
>
>  In response to your question around our plans.I will gladly shed
> some light in that area.
>
>  I apologize for the delayed response as I was waiting to confirm
> information prior to responding.
>
>  To start we have been stabilizing what we have in place today, and are
> in the process of adding additional checks and tests below tempest to
> ensure we do not put Python modules in place that will break our tempest
> runs.
>
>  Additionally we are in the process of moving to a complete build from
> source  of the entire python stack for hyper-v nodes in the tempest runs.
> Today we have a partial source configuration using Python public binaries
> for Windows as a the starting point with only some of the required modules
> being provided by binaries and others being built on the fly.
>
>  From a hardware perspective we have implemented plans and are currently
> in the hardware acquisition phase of building out a completely new
> deployment of the CI on hardware that is magnitudes above what we are
> currently using.   This new deployment will be hosted in an Official MS
> Datacenter and have hardware supported by onsite techs.
>
>  The timeline for the physical provisioning to be completed will be
> sometime this May/June.   Because we are making such a progression forward
> in both physical compute power (*200 Azure Quality hosts*) and networking
> infrastructure (*Multiple 10G/1G Interfaces per host*) we are going to
> take some time optimizing the deployment so that we can achieve the most
> stable and performant Tempest run. I am optimistic that the new deployment
> will be operational sometime between the J2 and J3 timeframe.
>
>  This is the *Short Term Plan*.
>
>  Longer Term is still in development and I will share more about it once
> details are finalized.
>
>  Please feel free to reach out directly if you have any questions.
>


Thanks for your response, I am glad to see you guys are making good
progress. setting up a reliable CI system is definitely not trivial.



>
>  Best,
>
>  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
>
>
>   From: Joe Gordon 
> Reply-To: "openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, April 1, 2014 at 4:02 PM
> To: "openstack-dev@lists.openstack.org"  >
> Subject: Re: [openstack-dev] Hyper-V CI is broken
>
>
>
>
> On Tue, Apr 1, 2014 at 11:51 AM, Alessandro Pilotti <
> apilo...@cloudbasesolutions.com> wrote:
>
>> Hi Joe,
>>
>>  We have issues with Nova resize that we are troubleshooting. If we
>> don’t find the root cause by today we’ll temporarily skip the resize tests.
>>
>
>  How long has resize been broken for? Is there a bug for it? Can we skip
> resize for now and add that bug to the known issues for icehouse. That way
> we can say hyper-v is working for everything but resize as apposed to the
> current status..
>
>
>>
>>  Thanks,
>>
>>  Alessandro
>>
>>
>>
>>
>>   On 01 Apr 2014, at 21:27, Joe Gordon  wrote:
>>
>>Hi Hyper-V CI maintainers,
>> CC: openstack-dev
>>
>>  As per [0] Hyper-V CI is failing 100% of the time, what are the
>> blockers in making this work again? are there any outstanding nova patches
>> that will fix this? We would like to hyper-v working in icehouse, and if
>> not we will be forced to add a note saying it doesn't work to the icehouse
>> release notes [1].
>>
>>
>>  [0] http://www.rcbops.com/gerrit/reports/nova-cireport.html
>> [1] https://wiki.openstack.org/wiki/ReleaseNotes/Havana#Known_Issues_2
>>   ___
>> 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] Neutron BP review process for Juno

On Wed, Apr 16, 2014 at 11:05 AM, trinath.soman...@freescale.com
 wrote:
> Hi Mestery
>
> With respect to the new BP review process, can we start submitting the BPs in 
> the review system and in the launchpad.
>
Yes, the repository is open and in fact we have our first review
posted already [1].

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

> Since, BP is a thought process of the developer either for core dev or for 
> vendor specific dev,
> can you give some light on how the review process of the BP can be ?
>
Hopefully the documentation on this process is mostly clear here [2].
For the actual review, we hope to get through these as they are filed.
I'm thinking of adding an item to the weekly neutron meeting agenda to
cover BPs, especially early in the Juno cycle. This way we can at
least highlight them so people are aware and we can discuss any major
issues once a week.

[2] https://wiki.openstack.org/wiki/Blueprints#Neutron

> asciiflow.com is a best tool for showing the pictorial representation of the 
> BP work. Thank you for the link..
>
> Were there any variations in general code review processes.
>
It should be effectively the same. Reviews can +2/+1/0/-1/-2, and once
we get consensus and multiple +2 votes, we can then +A (approve) the
BP. At that point, I'll schedule for inclusion into a Juno milestone
in LP.

Thanks!
Kyle

> -
> Trinath
>
> 
> From: Kyle Mestery 
> Sent: Wednesday, April 16, 2014 7:22 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] Neutron BP review process for Juno
>
> Actually, +1 to that Salvatore! I've found asciiflow.com to be superb
> for these types of things.
>
> On Wed, Apr 16, 2014 at 8:39 AM, Salvatore Orlando  
> wrote:
>> if the image you're adding is a diagram, I would think about asciiflow.com
>> first!
>>
>>
>> On 16 April 2014 15:09, Kyle Mestery  wrote:
>>>
>>> I think the problem is that your spec should be at the toplevel of the
>>> juno directory, and that's why the UT is failing. Can you move your
>>> spec up a level, including the image? You can create a spec images
>>> directory to put them in there and reference it in the spec as well if
>>> you want.
>>>
>>> On Tue, Apr 15, 2014 at 11:48 PM, Sumit Naiksatam
>>>  wrote:
>>> > What's the convention for adding images to the patch? The following
>>> > directory structure seemed logical to me (but the current UT will not
>>> > allow it):
>>> >
>>> > specs/juno//.rst
>>> > specs/juno//images/.png
>>> >
>>> > Thanks,
>>> > ~Sumit.
>>> >
>>> >
>>> >
>>> > On Tue, Apr 15, 2014 at 3:35 PM, Carl Baldwin 
>>> > wrote:
>>> >> +1.  I think we'll like this process better.  I hope to have some of
>>> >> the first blueprints to propose to the new repository very soon.
>>> >>
>>> >> On Tue, Apr 15, 2014 at 4:07 PM, Kyle Mestery
>>> >>  wrote:
>>> >>> Given the success the Nova team has had in handling reviews using
>>> >>> their new nova-specs gerrit repository, I think it makes a lot of
>>> >>> sense for Neutron to do the same. With this in mind, I've added
>>> >>> instructions to the BP wiki [1] for how to do. Going forward in Juno,
>>> >>> this is how Neutron BPs will be handled by the Neutron core team. If
>>> >>> you are currently working on a BP or code for Juno which is attached
>>> >>> to a BP, please file the BP using the process here [1].
>>> >>>
>>> >>> Given this is our first attempt at using this for reviews, I
>>> >>> anticipate there may be a few hiccups along the way. Please reply on
>>> >>> this thread or reach out in #openstack-neutron and we'll sort through
>>> >>> whatever issues we find.
>>> >>>
>>> >>> Thanks!
>>> >>> Kyle
>>> >>>
>>> >>> [1] https://wiki.openstack.org/wiki/Blueprints#Neutron
>>> >>>
>>> >>> ___
>>> >>> 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] TC Candidacy

2014-04-16 Thread Sergey Lukjanov

Hi folks,

I'd like to announce my candidacy for the TC.

I have been actively involved in OpenStack for about last two years,
and before that I was in observer mode since Diablo timeframe. I’m PTL
of OpenStack Data Processing program (Sahara project) from its very
beginning. Additionally, I’m the core reviewer in the OpenStack
Infrastructure team. I have contributions to different OpenStack
projects including Oslo, Swift, Nova client, Hacking, Pbr, Jeepyb,
Zuul and etc., you can find more info here [1].

My main focus in OpenStack is to enrich the portfolio of services it
provides with platform-level functionality, making it easier to use
for application developers and encouraging faster and larger adoption
of OpenStack platform. In addition to OpenStack I have contributed to
other open source projects including Twitter Storm [2] and Kotlin [3].

I see OpenStack not just an IaaS, but a great community, huge
ecosystem of extremely fast growing projects integrated with each
other to provide one consistent cloud platform. And here I see an
opportunity to enhance ecosystem further by creating integration
framework with other open source initiatives and their communities.
Integration with Apache Hadoop community through Sahara project is an
example. Sahara has been successfully graduated from the incubation by
OpenStack Technical Committee decision in the mid March to become a
part of integrated Juno release.

As a TC member I would like to bring additional expertise to the Big
Data in the OpenStack context and help to build a great and innovative
platform. In Icehouse I was participating in the formalisation of the
requirements for the incubation and graduation (as much, as it was
possible for non-TC member). That’s why I’d like to continue working
on it as I have a successful experience of growing project from
scratch to integration in present days. So, the goal of my TC
membership is to continue working on the OpenStack to help it grow
further and to make it as friendly and clear for newcomer projects and
contributors as possible.

[1] http://www.stackalytics.com/?release=all&user_id=slukjanov
[2] http://storm-project.net
[3] http://kotlin.jetbrains.org

-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Mirantis Inc.

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

Re: [openstack-dev] [openstack][nova][specs] Where to store images used in the spec

On 04/16/2014 12:42 PM, Kevin Benton wrote:
> The only downside to putting it on the wiki is that it no longer has a
> shared fate with the specification in the repo. If someone deletes it or
> replaces it on the wiki, information for the spec is lost. External
> connectivity is also required just to view a template as well.

Yeah, that's right. I'd honestly really prefer simple ascii diagrams in
almost all cases anyway.  Requiring an external diagram should be a rare
exception, not the rule, IMO.

-- 
Russell Bryant

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

Re: [openstack-dev] [heat] [heat-templates] [qa] [tempest] Questions about images

2014-04-16 Thread Steven Hardy

Hi Mike,

On Wed, Apr 16, 2014 at 11:39:59AM -0400, Mike Spreitzer wrote:
> Many of the templates in the heat-templates project have built-in 
> expectations of image names; here is an example excerpt:
> 
> F18: {'32': F18-i386-cfntools, '64': F18-x86_64-cfntools}
> F17: {'32': F17-i386-cfntools, '64': F17-x86_64-cfntools}
> U10: {'32': U10-i386-cfntools, '64': U10-x86_64-cfntools}
> RHEL-6.1: {'32': rhel61-i386-cfntools, '64': rhel61-x86_64-cfntools}
> RHEL-6.2: {'32': rhel62-i386-cfntools, '64': rhel62-x86_64-cfntools}
> RHEL-6.3: {'32': rhel63-i386-cfntools, '64': rhel63-x86_64-cfntools}
> 
> From where should a user get these images?  I have discovered --- I do not 
> even remember how --- that there are some images with names like those in 
> http://fedorapeople.org/groups/heat/prebuilt-jeos-images/ .  Is that the 
> right source?  Is that documented anywhere?

The list of images in the templates is a historical thing - IMO if the
template is in a distro-specific sub-directory, it should only specify the
version related to the directory, e.g "F20", they should not have a list
like you reference.

Those images you link are mostly legacy and deprecated (F17 and F18 are
very EOL), so while that link _was_ documented, it's not anymore:

http://docs.openstack.org/developer/heat/getting_started/on_devstack.html

As you have identified, we've got a lot of outdated stuff in the template
repo, everything needs to be re-tested and moved to the current stable
Fedora release, e.g F20. Help appreciated!

There are more Fedora examples than for other distros, just because that's
what a lot of the contributing developers were most regularly using.  If
folks can contribute better examples for other images, then great :)

One thing to mention however, IMO we want to focus on providing plenty of
good template usage examples, i.e to supplement the documentation and allow
folks to build their own templates, not necessarily the most universally
compatible templates (multi-distro compatibility==template complexity).

> That directory contains only Fedora images.  From where are we expected to 
> get the Ubuntu and RHEL images?

The top level docs cover this:

http://docs.openstack.org/image-guide/content/ch_obtaining_images.html

Maybe we need some docs addition which explains the optional requirement
for heat-cfntools.

> That directory does not contain Fedora 20 images.  Should they be added? I 
> am willing to do the work if that is the right thing to do; how would I 
> create those images?

No, happily heat-cfntools is now included in the official Fedora cloud
image, so you can just download that :)

http://cloud.fedoraproject.org/fedora-20.x86_64.qcow2

> Do we still need to build special images?  Recent releases of Ubuntu and 
> Fedora have cloud-init built in; I assume the same is true for RHEL.

cloud-init was not the reason for the special images, a lot of templates
originally expected heat-cfntools to be in the image (a lot still do).

If you write your templates to avoid using the heat-cfntools agents, it's
perfectly possible to use a generic image, provided it contains cloud-init
(which all of the distributor provided cloud images do AFAIK).

See, for example the *Native examples:

https://github.com/openstack/heat-templates/blob/master/hot/F20/WordPress_Native.yaml

> What are good date-independent URLs for recent Fedora releases?  Steve 
> Hardy has mentioned http://cloud.fedoraproject.org/fedora-20.x86_64.qcow2 
> (and the obvious parallels for release 19 and for 32 bits also exist); I 
> know of no other date-independent URLs for Fedora 19 and 20.

http://fedoraproject.org/en/get-fedora#clouds

Everyone should use the official F20 cloud image unless they have a
specific reason not to (assuming they want to use Fedora).

> For releases that have cloud-init built in, should the templates expect 
> image names that are derived in the obvious way from the date-independent 
> URL?

We should use the default name that devstack uses in glance, IMO, e.g

"fedora-20.x86_64"

I guess that is derived from the URL, so yes :)

> http://fedorapeople.org/groups/heat/prebuilt-jeos-images/F19-x86_64-cfntools.qcow2
>  
> seems to be broken; I get failures every time I try to use it.  Has 
> anybody had success with it?  Following is an example failure I found in 

It worked last time I used it, but I reccomend just using the F20 image,
I've been using that every day for weeks and it works fine.

The error looks like you have a corrupt or incomplete image FWIW.

Steve

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

Re: [openstack-dev] [openstack][nova][specs] Where to store images used in the spec

On 04/16/2014 12:55 PM, Russell Bryant wrote:
> On 04/16/2014 12:42 PM, Kevin Benton wrote:
>> The only downside to putting it on the wiki is that it no longer has a
>> shared fate with the specification in the repo. If someone deletes it or
>> replaces it on the wiki, information for the spec is lost. External
>> connectivity is also required just to view a template as well.
> 
> Yeah, that's right. I'd honestly really prefer simple ascii diagrams in
> almost all cases anyway.  Requiring an external diagram should be a rare
> exception, not the rule, IMO.
> 

After some additional discussion on this topic on IRC, I really think we
should start by requiring diagrams in ASCII and see if that becomes
overly painful.

Proposed update to the template regarding this topic here:
https://review.openstack.org/88028

-- 
Russell Bryant

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

Re: [openstack-dev] [neutron] Neutron BP review process for Juno

On 04/16/2014 09:51 AM, Russell Bryant wrote:
> On 04/16/2014 09:39 AM, Salvatore Orlando wrote:
>> if the image you're adding is a diagram, I would think about
>> asciiflow.com  first!
> 
> In all seriousness, I think that's a very nice solution for simple
> diagrams.  :-)
> 
> For other diagrams, I wonder if it makes sense to just upload them to
> the wiki and include links to them from the spec using the image directive.
> 

Another thread got started on this topic for Nova.

I put up a proposal to require ASCII digrams for nova-specs here:

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

-- 
Russell Bryant

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

Re: [openstack-dev] [nova] unit tests method

2014-04-16 Thread Jay Pipes

On Wed, 2014-04-16 at 11:05 -0500, Ben Nemec wrote:
> On 04/16/2014 08:11 AM, Jay Pipes wrote:
> > On Wed, 2014-04-16 at 14:55 +0800, Chen CH Ji wrote:
> >> Hi
> >>  There are 3 types of unit test existing now (stub, mox
> >> and mock)
> >>  Several code reviewers suggest to use mock instead of
> >> using the other 2 and I am following it, but I want to know where can
> >> I find the suggestion and guide line?
> >
> > Hi Kevin!
> >
> > So, there are only two unit testing methods -- mock and mox. stubs are
> > part of the mox-style way of doing things.
> >
> > My general rules of thumb when doing reviews in Nova are these:
> >
> > 1) For new unit tests, use mock
> > 2) Don't mix mock and mox in a single test method
> > 3) When modifying existing unit tests, unless rewriting the test method
> > almost entirely, stick with whatever is used already (mock or mox)
> >
> > Best,
> > -jay
> 
> These points are also documented here: 
> https://wiki.openstack.org/wiki/ReviewChecklist (see point 4 under the 
> Common Review Checklist)

Oooh, thx Ben. I wasn't aware of that link. Some great information in
there.

Best,
-jay


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

Re: [openstack-dev] [neutron] Neutron BP review process for Juno

On Wed, Apr 16, 2014 at 12:23 PM, Russell Bryant  wrote:
> On 04/16/2014 09:51 AM, Russell Bryant wrote:
>> On 04/16/2014 09:39 AM, Salvatore Orlando wrote:
>>> if the image you're adding is a diagram, I would think about
>>> asciiflow.com  first!
>>
>> In all seriousness, I think that's a very nice solution for simple
>> diagrams.  :-)
>>
>> For other diagrams, I wonder if it makes sense to just upload them to
>> the wiki and include links to them from the spec using the image directive.
>>
>
> Another thread got started on this topic for Nova.
>
> I put up a proposal to require ASCII digrams for nova-specs here:
>
> https://review.openstack.org/#/c/88028/
>
Great idea! I've done the same for neutron-specs here:

https://review.openstack.org/88037


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

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

Re: [openstack-dev] [Nova] nova-specs

2014-04-16 Thread Jiang, Yunhong

> single comment they made was -1 worthy on its own. Often times I will -1
> for a spelling mistake and then make a bunch of other purely-opinion
> comments which don't necessarily need to change.

Do we really want to -1 for spelling mistake in nova-specs? This is really a 
bad news for non-native speaker like me because I'm really not sensitive to the 
spelling even after checking again and again. (Of course I can point out any 
spelling wrong in Chinese very quickly).

The major concern of the -1 on spelling is, seems nova-drive and nova-cores 
will not check a patch/spec at all if it's -1 already. Thus -1 on spelling will 
delay the review, especially if the nova-drive member and the author is in 
different time zone.

Would it be better to -1 mainly for design issue, and comments on spelling 
error w/o -1? After all, nova-spec is different with a nova patch.

Thanks
--jyh


> 
> --Dan
> 
> 
> ___
> 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][LBaaS] Requirements and API revision progress

2014-04-16 Thread Carlos Garza

On Apr 14, 2014, at 8:20 PM, Stephen Balukoff
mailto:sbaluk...@bluebox.net>> wrote:

Hello y'all!

Over the last few months, I feel like we've seen a renewed vigor for
participation in making the LBaaS project successful. After the (still
unresolved) object model discussion started in January, based on feedback we
were getting from Neutron core developers (mainly Mark McClain, from what I
understand) this was followed up by a requirements discussion, a use cases
discussion, and as of the last weekly IRC meeting, I think there are people in
this group now working on proposals for API revision. We've coordinated this
using various documents, and I think the ones that have carried the most weight
are:

* Object model revision summary as started by Eugene:
https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion

(Feedback from core was the 'load balancer' object was an implementation
detail. I think most people on this project don't think so, but it's clear more
work was needed here.)

* Requirements document as started by Jorge:
https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements

(Feedback was that requirements needed to be stated in the form of user or
operator requirements, and not in the form of what a load balancer should do,
per se.)

* Samuel then created this google document to describe several use cases from
the user's point of view:
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing

* And to prioritize what features are needed, Jorge started this document to
collect operator feature usage data (with current load balancer deployments,
presumably outside of OpenStack, since Neutron LBaaS doesn't presently have
many of these features):
https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc&usp=sharing

(Feedback on this is that everyone agrees the legacy API is really confusing,
and that a clean break for the API for Juno is probably prudent, possibly
preserving some backward compatibility with a versioned API. Further, it was
clear we needed an example of what the new API should look like.)

There are also these proposal documents for L7 and SSL functionality,
presumably on hold until either the API draft being made is closer to reality,
or until we come to an agreement on the required changes to the object model
the proposals imply:
https://wiki.openstack.org/wiki/Neutron/LBaaS/l7
https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL

So! On this front:

1. Does is make sense to keep filling out use cases in Samuel's document above?
I can think of several more use cases that our customers actually use on our
current deployments which aren't considered in the 8 cases in Samuel's document
thus far. Plus nobody has create any use cases from the cloud operator
perspective yet.

We have been using the document when discussing our API proposal. The use
cases had some surprising implications for our api proposal which we had to
rethink. Particularly the L7 URL routing use case #7

As far as operator requirements I know our team is advocating a management API
that is separate from the public api (Separate meaning regular users can reach
its endpoint) but still apart of the CORE codebase.

2. It looks like we've started to get real-world data on Load Balancer features
in use in the real world. If you've not added your organization's data, please
be sure to do so soon so we can make informed decisions about product
direction. On this front, when will we be making these decisions?

Would it be prudent to make these decisions at the Atlanta summit or
thereafter.

3. Jorge-- I know an action item from the last meeting was to draft a revision
of the API (probably starting from something similar to the Atlas API). Have
you had a chance to get started on this, and are you open for collaboration on
this document at this time? Alternatively, I'd be happy to take a stab at it
this week (though I'm not very familiar with the Atlas API-- so my proposal
might not look all that similar).

Our team, (Jorge's team) are investigating the API from the perspective of
supporting Single Loadbalancer creation calls that is still compatible with the
ability to create separate components such as vips pools ssl confs and
lasteltly making a call that joins them to a loadbalancer. We wanted to iron
out some of the gotcha's we've been encountering before we presented the
proposals. Most recently we are looking at how allowing inplace object creation
which Im calling "literals" vs the ability to create parent objects with the
ids of previously created objects. I'll let brandon logan follow uo on this
later on today. We are still in meetings right now about the API.

|What format or template should we be following to create the API
documentation? (I see this here:
http://docs.openstack.org/api/openstack-network/2.0/content/ch_preface.html
but this seems like it mig

Re: [openstack-dev] [Nova] nova-specs

2014-04-16 Thread Dan Smith

> Do we really want to -1 for spelling mistake in nova-specs?

I do, yes. These documents are intended to be read by deployers and
future developers. I think it's really important that they're useful in
that regard.

> This is really a bad news for non-native speaker like me because I'm 
> really not sensitive to the spelling even after checking again and 
> again.

Well, I certainly understand it can be frustrating. When I do it, I
provide the proper spelling in my comment, and I think I've been
generally pretty responsive to re-reviewing things quickly when it was
just a spelling error. Usually, however, there is something else to go
wrong with the -1 so it needs to be respun anyway.

--Dan

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

Re: [openstack-dev] [heat] [heat-templates] [qa] [tempest] Questions about images

Steven Hardy  wrote answers to most of my questions.

To clarify, my concern about URLs and image names is not so much for the 
sake of a person browsing/writing but rather because I want programs, 
scripts, templates, and config files (e.g., localrc for DevStack) to all 
play nice together (e.g., not require a user to rename any images or hack 
any templates).  I think Steve was thinking along the same lines when he 
reiterated the URL he uses in localrc and wrote:

> We should use the default name that devstack uses in glance, IMO, e.g
> 
> "fedora-20.x86_64"

Steve also referred to /hot/F20/WordPress_Native.yaml in heat-templates. 
That template is a counter-example: for the image_id parameter it says

  - allowed_values: [ Fedora-i386-20-20131211.1-sda, 
Fedora-x86_64-20-20131211.1-sda ]

I'm going to assume that Steve and others agree that the allowed values 
constraint in this and similar templates should be revised to follow the 
pattern exemplified by "fedora-20.x84_64".  Or should it be liberalized to 
not be so prescriptive?  I'll go even a step further and say that there 
should be a default value and it should be the 64-bit value (I am thinking 
ahead to automating testing of heat-templates).

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

Re: [openstack-dev] [heat] [heat-templates] [qa] [tempest] Questions about images

Steven Hardy  wrote on 04/16/2014 01:05:14 PM:

> On Wed, Apr 16, 2014 at 11:39:59AM -0400, Mike Spreitzer wrote:

> > http://fedorapeople.org/groups/heat/prebuilt-jeos-images/F19-
> x86_64-cfntools.qcow2 
> > seems to be broken; I get failures every time I try to use it.  Has 
> > anybody had success with it?  Following is an example failure I found 
in 
> 
> It worked last time I used it, but I reccomend just using the F20 image,
> I've been using that every day for weeks and it works fine.
> 
> The error looks like you have a corrupt or incomplete image FWIW.

I have fetched that image several times, into several different OpenStack 
clouds.  I get a failure every time.  It is 19 not 20, BTW.  But I think 
it is moot, I agree with the recommendation to use an image straight from 
Fedora.

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

Re: [openstack-dev] TC Candidacy

2014-04-16 Thread Anita Kuno

confirmed

On 04/16/2014 12:47 PM, Sergey Lukjanov wrote:
> Hi folks,
> 
> I'd like to announce my candidacy for the TC.
> 
> I have been actively involved in OpenStack for about last two years,
> and before that I was in observer mode since Diablo timeframe. I’m PTL
> of OpenStack Data Processing program (Sahara project) from its very
> beginning. Additionally, I’m the core reviewer in the OpenStack
> Infrastructure team. I have contributions to different OpenStack
> projects including Oslo, Swift, Nova client, Hacking, Pbr, Jeepyb,
> Zuul and etc., you can find more info here [1].
> 
> My main focus in OpenStack is to enrich the portfolio of services it
> provides with platform-level functionality, making it easier to use
> for application developers and encouraging faster and larger adoption
> of OpenStack platform. In addition to OpenStack I have contributed to
> other open source projects including Twitter Storm [2] and Kotlin [3].
> 
> I see OpenStack not just an IaaS, but a great community, huge
> ecosystem of extremely fast growing projects integrated with each
> other to provide one consistent cloud platform. And here I see an
> opportunity to enhance ecosystem further by creating integration
> framework with other open source initiatives and their communities.
> Integration with Apache Hadoop community through Sahara project is an
> example. Sahara has been successfully graduated from the incubation by
> OpenStack Technical Committee decision in the mid March to become a
> part of integrated Juno release.
> 
> As a TC member I would like to bring additional expertise to the Big
> Data in the OpenStack context and help to build a great and innovative
> platform. In Icehouse I was participating in the formalisation of the
> requirements for the incubation and graduation (as much, as it was
> possible for non-TC member). That’s why I’d like to continue working
> on it as I have a successful experience of growing project from
> scratch to integration in present days. So, the goal of my TC
> membership is to continue working on the OpenStack to help it grow
> further and to make it as friendly and clear for newcomer projects and
> contributors as possible.
> 
> [1] http://www.stackalytics.com/?release=all&user_id=slukjanov
> [2] http://storm-project.net
> [3] http://kotlin.jetbrains.org
> 


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

Re: [openstack-dev] [Nova] nova-specs