Re: [openstack-dev] [MagnetoDB] Andrey Ostapenko core nomination

[isviridov]

My congratulations to Andrey!
Welcome on board!

Cheers,
Ilya



26.12.2014 16:52, Dmitriy Ukhlov пишет:
> Andrey is very active contributor, good team player and very helps us at
> previous development cycle. +1 from my side.
> 
> On Fri, Dec 26, 2014 at 4:16 PM, isviridov  > wrote:
> 
> Hello stackers and magnetians,
> 
> I suggest nominating Andrey Ostapenko [1] to MagnetoDB cores.
> 
> During last months he has made huge contribution to MagnetoDB [2]
> Andrey drives Tempest and python-magnetodbclient successfully.
> 
> Please rise your hands.
> 
> Thank you,
> Ilya Sviridov
> 
> [1] http://stackalytics.com/report/users/aostapenko
> [2] http://stackalytics.com/report/contribution/magnetodb/90
> 
> 
> 
> 
> 
> -- 
> Best regards,
> Dmitriy Ukhlov
> Mirantis Inc.



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

[openstack-dev] [Nova] should 'ip address' be retrived when decribe host?

[Lingxian Kong]

Hi Stackers:

As for now, we can get the 'host name', 'service' and 'availability
zone' of a host through the CLI command 'nova host-list'. But as a
programmer who communicates with OpenStack using its API, I want to
get the host ip address, in order to perform some other actions in my
program.

And what I know is, the ip address of a host is populated in the
'compute_nodes' table of the database, during the 'update available
resource' periodic task.

So, is it possible of the community to support it in the future?

I apologize if the topic was once covered and I missed it.

-- 
Regards!
---
Lingxian Kong

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

Re: [openstack-dev] [Nova] should 'ip address' be retrived when decribe host?

[Jay Pipes]

On 12/29/2014 06:51 AM, Lingxian Kong wrote:

Hi Stackers:

As for now, we can get the 'host name', 'service' and 'availability
zone' of a host through the CLI command 'nova host-list'. But as a
programmer who communicates with OpenStack using its API, I want to
get the host ip address, in order to perform some other actions in my
program.

And what I know is, the ip address of a host is populated in the
'compute_nodes' table of the database, during the 'update available
resource' periodic task.

So, is it possible of the community to support it in the future?

I apologize if the topic was once covered and I missed it.


Hi!

I see no real technical reason this could not be done. It would require 
waiting until all of the API microversioning bits are done, and a 
micro-increment of the API, along with minimal changes of code in the 
hosts extension to return the host_ip field from the 
nova.objects.ComputeNode objects returned to the HostController object.


Are you interested in working on such a feature? I would be happy to 
guide you through the process of making a blueprint and submitting code 
if you'd like. Just find me on IRC #openstack-nova. My IRC nick is jaypipes.


Best,
-jay

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

Re: [openstack-dev] [Nova] should 'ip address' be retrived when decribe host?

[Jay Lau]

Does "nova hypervisor-show" help? It already include the host ip address.

2014-12-29 21:26 GMT+08:00 Jay Pipes :

> On 12/29/2014 06:51 AM, Lingxian Kong wrote:
>
>> Hi Stackers:
>>
>> As for now, we can get the 'host name', 'service' and 'availability
>> zone' of a host through the CLI command 'nova host-list'. But as a
>> programmer who communicates with OpenStack using its API, I want to
>> get the host ip address, in order to perform some other actions in my
>> program.
>>
>> And what I know is, the ip address of a host is populated in the
>> 'compute_nodes' table of the database, during the 'update available
>> resource' periodic task.
>>
>> So, is it possible of the community to support it in the future?
>>
>> I apologize if the topic was once covered and I missed it.
>>
>
> Hi!
>
> I see no real technical reason this could not be done. It would require
> waiting until all of the API microversioning bits are done, and a
> micro-increment of the API, along with minimal changes of code in the hosts
> extension to return the host_ip field from the nova.objects.ComputeNode
> objects returned to the HostController object.
>
> Are you interested in working on such a feature? I would be happy to guide
> you through the process of making a blueprint and submitting code if you'd
> like. Just find me on IRC #openstack-nova. My IRC nick is jaypipes.
>
> Best,
> -jay
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,

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

Re: [openstack-dev] [Openstack] Need help in validating CPU Pinning feature

[Steve Gordon]

- Original Message -
> From: "Srinivasa Rao Ragolu" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> ,
> 
> Hi Steve,
> 
> Thank you so much for your reply and detailed steps to go forward.
> 
> I am using devstack setup and nova master commit. As I could not able to
> see CPUPinningFilter implementation in source, I have used
> NUMATopologyFilter.
> 
> But same problem exists. I could not able to see any vcpupin in the guest
> xml. Please see the section of vcpu from xml below.
> 
> 
> http://openstack.org/xmlns/libvirt/nova/1.0";>
>   
>   test_pinning
>   2014-12-29 07:30:04
>   
> 2048
> 20
> 0
> 0
> 2
>   
>   
> admin
>  uuid="4904cdf59c254546981f577351b818de">admin
>   
>   
> 
>   
>   2097152
>   2097152
>   2
> 
> Kindly suggest me which branch of NOVA I need to take to validated pinning
> feature. Alse let me know CPUPinningFilter is required to validate pinning
> feature?

There are still a few outstanding patches, e.g. see:

https://review.openstack.org/#/q/topic:bp/virt-driver-cpu-pinning,n,z

Thanks,

Steve

> On Sat, Dec 27, 2014 at 4:37 AM, Steve Gordon  wrote:
> 
> > - Original Message -
> > > From: "Srinivasa Rao Ragolu" 
> > > To: "joejiang" 
> > >
> > > Hi Joejing,
> > >
> > > Thanks for quick reply. Above xml is getting generated fine if I set
> > > "vcpu_pin_set=1-12" in /etc/nova/nova.conf.
> > >
> > > But how to pin each vcpu with pcpu something like below
> > >
> > > 
> > >
> > >
> > >
> > >
> > > 
> > >
> > >
> > > One more questions is Are Numa nodes are compulsory for pin each vcpu to
> > > pcpu?
> >
> > The specification for the CPU pinning functionality recently implemented
> > in Nova is here:
> >
> >
> > http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/virt-driver-cpu-pinning.html
> >
> > Note that exact vCPU to pCPU pinning is not exposed to the user as this
> > would require them to have direct knowledge of the host pCPU layout.
> > Instead they request that the instance receive "dedicated" CPU resourcing
> > and Nova handles allocation of pCPUs and pinning of vCPUs to them.
> >
> > Example usage:
> >
> > * Create a host aggregate and add set metadata on it to indicate it is to
> > be used for pinning, 'pinned' is used for the example but any key value can
> > be used. The same key must used be used in later steps though::
> >
> > $ nova aggregate-create cpu_pinning
> > $ nova aggregate-set-metadata 1 pinned=true
> >
> >   NB: For aggregates/flavors that wont be dedicated set pinned=false.
> >
> > * Set all existing flavors to avoid this aggregate::
> >
> > $ for FLAVOR in `nova flavor-list | cut -f 2 -d ' ' | grep -o [0-9]*`;
> > do nova flavor-key ${FLAVOR} set
> > "aggregate_instance_extra_specs:pinned"="false"; done
> >
> > * Create flavor that has extra spec "hw:cpu_policy" set to "dedicated". In
> > this example it is created with ID of 6, 2048 MB of RAM, 20 GB drive, and 2
> > vCPUs::
> >
> > $ nova flavor-create pinned.medium 6 2048 20 2
> > $ nova flavor-key 6 set "hw:cpu_policy"="dedicated"
> >
> > * Set the flavor to require the aggregate set aside for dedicated pinning
> > of guests::
> >
> > $ nova flavor-key 6 set "aggregate_instance_extra_specs:pinned"="true"
> >
> > * Add a compute host to the created aggregate (see nova host-list to get
> > the host name(s))::
> >
> > $ nova aggregate-add-host 1 my_packstack_host_name
> >
> > * Add the AggregateInstanceExtraSpecsFilter and CPUPinningFilter filters
> > to the scheduler_default_filters in /etc/nova.conf::
> >
> > scheduler_default_filters =
> > RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,
> >
> > ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,
> >
> > AggregateInstanceExtraSpecsFilter,CPUPinningFilter
> >
> >   NB: On Kilo code base I believe the filter is NUMATopologyFilter
> >
> > * Restart the scheduler::
> >
> > # systemctl restart openstack-nova-scheduler
> >
> > * After the above - with a normal (non-admin user) try to boot an instance
> > with the newly created flavor::
> >
> > $ nova boot --image fedora --flavor 6 test_pinning
> >
> > * Confirm the instance has succesfully booted and that it's vCPU's are
> > pinned to _a single_ host CPU by observing
> >   the  element of the generated domain XML::
> >
> > # virsh list
> >  IdName   State
> > 
> >  2 instance-0001  running
> > # virsh dumpxml instance-0001
> > ...
> > 2
> >   
> > 
> > 
> > 
> >
> >
> > -Steve
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> 

Re: [openstack-dev] [MagnetoDB] Andrey Ostapenko core nomination

[Charles Wang]

Congrats Andrey, well deserved.

On 12/26/14, 9:16 AM, "isviridov"  wrote:

>Hello stackers and magnetians,
>
>I suggest nominating Andrey Ostapenko [1] to MagnetoDB cores.
>
>During last months he has made huge contribution to MagnetoDB [2]
>Andrey drives Tempest and python-magnetodbclient successfully.
>
>Please rise your hands.
>
>Thank you,
>Ilya Sviridov
>
>[1] http://stackalytics.com/report/users/aostapenko
>[2] http://stackalytics.com/report/contribution/magnetodb/90
>
>


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

[openstack-dev] [qa] tempest stable/icehouse builds are broken

[David Kranz]

Some kind of regression has caused stable/icehouse builds to fail, and 
hence prevents any code from merging in tempest. This is being tracked 
at https://bugs.launchpad.net/python-heatclient/+bug/1405579. Jeremy 
(fungi) provided a hacky work-around here 
https://review.openstack.org/#/c/144347/ which I hope can soon be +A by 
a tempest core until there is some better fix.


 -David

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

Re: [openstack-dev] [Openstack-operators] The state of nova-network to neutron migration

[Anita Kuno]

On 12/24/2014 04:07 AM, Oleg Bondarev wrote:
> On Mon, Dec 22, 2014 at 10:08 PM, Anita Kuno  wrote:
>>
>> On 12/22/2014 01:32 PM, Joe Gordon wrote:
>>> On Fri, Dec 19, 2014 at 9:28 AM, Kyle Mestery 
>> wrote:
>>>
 On Fri, Dec 19, 2014 at 10:59 AM, Anita Kuno 
>> wrote:
>
> Rather than waste your time making excuses let me state where we are
>> and
> where I would like to get to, also sharing my thoughts about how you
>> can
> get involved if you want to see this happen as badly as I have been
>> told
> you do.
>
> Where we are:
> * a great deal of foundation work has been accomplished to achieve
> parity with nova-network and neutron to the extent that those involved
> are ready for migration plans to be formulated and be put in place
> * a summit session happened with notes and intentions[0]
> * people took responsibility and promptly got swamped with other
> responsibilities
> * spec deadlines arose and in neutron's case have passed
> * currently a neutron spec [1] is a work in progress (and it needs
> significant work still) and a nova spec is required and doesn't have a
> first draft or a champion
>
> Where I would like to get to:
> * I need people in addition to Oleg Bondarev to be available to
>> help
> come up with ideas and words to describe them to create the specs in a
> very short amount of time (Oleg is doing great work and is a fabulous
> person, yay Oleg, he just can't do this alone)
> * specifically I need a contact on the nova side of this complex
> problem, similar to Oleg on the neutron side
> * we need to have a way for people involved with this effort to
>> find
> each other, talk to each other and track progress
> * we need to have representation at both nova and neutron weekly
> meetings to communicate status and needs
>
> We are at K-2 and our current status is insufficient to expect this
>> work
> will be accomplished by the end of K-3. I will be championing this
>> work,
> in whatever state, so at least it doesn't fall off the map. If you
>> would
> like to help this effort please get in contact. I will be thinking of
> ways to further this work and will be communicating to those who
> identify as affected by these decisions in the most effective methods
>> of
> which I am capable.
>
> Thank you to all who have gotten us as far as well have gotten in this
> effort, it has been a long haul and you have all done great work. Let's
> keep going and finish this.
>
> Thank you,
> Anita.
>
> Thank you for volunteering to drive this effort Anita, I am very happy
 about this. I support you 100%.

 I'd like to point out that we really need a point of contact on the nova
 side, similar to Oleg on the Neutron side. IMHO, this is step 1 here to
 continue moving this forward.

>>>
>>> At the summit the nova team marked the nova-network to neutron migration
>> as
>>> a priority [0], so we are collectively interested in seeing this happen
>> and
>>> want to help in any way possible.   With regard to a nova point of
>> contact,
>>> anyone in nova-specs-core should work, that way we can cover more time
>>> zones.
>>>
>>> From what I can gather the first step is to finish fleshing out the first
>>> spec [1], and it sounds like it would be good to get a few nova-cores
>>> reviewing it as well.
>>>
>>>
>>>
>>>
>>> [0]
>>>
>> http://specs.openstack.org/openstack/nova-specs/priorities/kilo-priorities.html
>>> [1] https://review.openstack.org/#/c/142456/
>>>
>>>
>> Wonderful, thank you for the support Joe.
>>
>> It appears that we need to have a regular weekly meeting to track
>> progress in an archived manner.
>>
>> I know there was one meeting November but I don't know what it was
>> called so so far I can't find the logs for that.
>>
> 
> It wasn't official, we just gathered together on #novamigration. Attaching
> the log here.
> 
Ah, that would explain why I couldn't find the log. Thanks for the
attachment.
> 
>> So if those affected by this issue can identify what time (UTC please,
>> don't tell me what time zone you are in it is too hard to guess what UTC
>> time you are available) and day of the week you are available for a
>> meeting I'll create one and we can start talking to each other.
>>
>> I need to avoid Monday 1500 and 2100 UTC, Tuesday 0800 UTC, 1400 UTC and
>> 1900 - 2200 UTC, Wednesdays 1500 - 1700 UTC, Thursdays 1400 and 2100 UTC.
>>
> 
> I'm available each weekday 0700-1600 UTC, 1700-1800 UTC is also acceptable.
> 
> Thanks,
> Oleg
Wonderful, thank you Oleg. We will aim for a meeting time in this range.
I also understand holidays in Russia start on January 1 and go until the
11th or the 12th, I'm guessing this includes you.

Thanks,
Anita.
> 
> 
>>
>> Thanks,
>> Anita.
>>

 Thanks,
 Kyle


> [0] https://etherpad.openst

Re: [openstack-dev] [infra] [storyboard] Nominating Yolanda Robla for StoryBoard Core

[Anita Kuno]

On 12/24/2014 03:58 AM, Ricardo Carrillo Cruz wrote:
> Big +1 from me :-).
> 
> Yolanda is an amazing engineer, both frontend and backend.
> As Michael said, she's not only been doing Storyboard but a bunch of other
> infra stuff that will be beneficial for the project.
> 
> Regards!
> 
> 2014-12-24 0:38 GMT+01:00 Zaro :
> 
>> +1
>>
>> On Tue, Dec 23, 2014 at 2:34 PM, Michael Krotscheck 
>> wrote:
>>
>>> Hello everyone!
>>>
>>> StoryBoard is the much anticipated successor to Launchpad, and is a
>>> component of the Infrastructure Program. The storyboard-core group is
>>> intended to be a superset of the infra-core group, with additional
>>> reviewers who specialize in the field.
>>>
>>> Yolanda has been working on StoryBoard ever since the Atlanta Summit, and
>>> has provided a diligent and cautious voice to our development effort. She
>>> has consistently provided feedback on our reviews, and is neither afraid of
>>> asking for clarification, nor of providing constructive criticism. In
>>> return, she has been nothing but gracious and responsive when improvements
>>> were suggested to her own submissions.
>>>
>>> Furthermore, Yolanda has been quite active in the infrastructure team as
>>> a whole, and provides valuable context for us in the greater realm of infra.
>>>
>>> Please respond within this thread with either supporting commentary, or
>>> concerns about her promotion. Since many western countries are currently
>>> celebrating holidays, the review period will remain open until January 9th.
>>> If the consensus is positive, we will promote her then!
>>>
>>> Thanks,
>>>
>>> Michael
>>>
>>>
>>> References:
>>>
>>> https://review.openstack.org/#/q/reviewer:%22yolanda.robla+%253Cinfo%2540ysoft.biz%253E%22,n,z
>>>
>>> http://stackalytics.com/?user_id=yolanda.robla&metric=marks
>>>
+1 for Yolanda for core reviewer for StoryBoard.

Anita.
>>>
>>> ___
>>> 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] [nova] No team meeting this week

[Michael Still]

I assume people generally take new years day off...

Cheers,
Michael

-- 
Rackspace Australia

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

[openstack-dev] [Ironic] mid-cycle details

[Devananda van der Veen]

Hi folks!

tldr; If you will be attending the midcycle sprint in Grenoble the week of
Feb 3rd, please sign up HERE

.

Long version...

Before the holidays, I was behind in gathering and sharing information
about our midcycle sprint, which makes me even further behind now so
I've finally got those details to share with y'all! Also, I have some
thoughts / concerns, which I've shared in a separate email -- please go
read it.

Dates: Feb 3 - 5 (Tue - Thu) with a half day for those sticking around on
Friday, Feb 6th.

Location:
  Hewlett Packard Centre de Compétences
  5 Avenue Raymond Chanas
  38320 Eybens
  Grenoble, France

Grenoble is flat and fairly easy to get around, both by tram and by car.
The easiest airport to travel through is Lyon, and it is about an hour's
drive by car from the airport to Grenoble. (Also, it's a beautiful drive in
the countryside - I recommend it!)

I have previously stayed at the Mercure Centre Alpotel [1], and while not
the closest hotel (it's about 10 minutes by car or 25 minutes by tram to
HP's campus) it is within walking distance to the city center. I'll be
staying there again. There are also hotels around the Expo center, which is
just a few blocks from the HP campus, such as [2]. I have not arranged any
group rates at these hotels, but the city has plenty of availability and
this isn't peak travel season so rates are quite reasonable.

The weather forecast [3] will probably be chilly (around 45F or 7C during
the day), likely overcast with some rain, but probably not snowing in the
city. We'll be within easy driving distance of the Alps, so if you plan to
go exploring outside the city (ski trip, anyone?) dress for snow.

Regards,
Devananda



[1]
Hotel Mercure Grenoble Centre Alpotel
12 Boulevard Maréchal Joffre
38000 Grenoble
France

[2]
Park & Suites Elegance Grenoble Alpexpo
1 Avenue d'Innsbruck
38100 Grenoble
France

[3]
https://weatherspark.com/averages/32103/2/Grenoble-Rhone-Alpes-France
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ironic] thoughts on the midcycle

[Devananda van der Veen]

I'm sending the details of the midcycle in a separate email. Before you
reply that you won't be able to make it, I'd like to share some thoughts /
concerns.

In the last few weeks, several people who I previously thought would attend
told me that they can't. By my informal count, it looks like we will have
at most 5 of our 10 core reviewers in attendance. I don't think we should
cancel based on that, but it does mean that we need to set our expectations
accordingly.

Assuming that we will be lacking about half the core team, I think it will
be more practical as a focused sprint, rather than a planning & design
meeting. While that's a break from precedent, planning should be happening
via the spec review process *anyway*. Also, we already have a larger back
log of specs and work than we had this time last cycle, but with the same
size review team. Rather than adding to our backlog, I would like us to use
this gathering to burn through some specs and land some code.

That being said, I'd also like to put forth this idea: if we had a second
gathering (with the same focus on writing code) the following week (let's
say, Feb 11 - 13) in the SF Bay area -- who would attend? Would we be able
to get the "other half" of the core team together and get more work done?
Is this a good idea?

OK. That's enough of my musing for now...

Once again, if you will be attending the midcycle sprint in Grenoble the
week of Feb 3rd, please sign up HERE

.

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

Re: [openstack-dev] [Ironic] thoughts on the midcycle

[Michael Davies]

On Tue, Dec 30, 2014 at 9:15 AM, Devananda van der Veen <
devananda@gmail.com> wrote:

> [snip]
> That being said, I'd also like to put forth this idea: if we had a second
> gathering (with the same focus on writing code) the following week (let's
> say, Feb 11 - 13) in the SF Bay area -- who would attend? Would we be able
> to get the "other half" of the core team together and get more work done?
> Is this a good idea?
>

Just like to register my interest here - the time to get to SFO from AU is
quite a bit less than Grenoble, so is something I would try to possibly
make happen.
-- 
Michael Davies   mich...@the-davies.net
Rackspace Australia
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] thoughts on the midcycle

[Jim Rollenhagen]

On Mon, Dec 29, 2014 at 10:45:57PM +, Devananda van der Veen wrote:
> I'm sending the details of the midcycle in a separate email. Before you
> reply that you won't be able to make it, I'd like to share some thoughts /
> concerns.
> 
> In the last few weeks, several people who I previously thought would attend
> told me that they can't. By my informal count, it looks like we will have
> at most 5 of our 10 core reviewers in attendance. I don't think we should
> cancel based on that, but it does mean that we need to set our expectations
> accordingly.
> 
> Assuming that we will be lacking about half the core team, I think it will
> be more practical as a focused sprint, rather than a planning & design
> meeting. While that's a break from precedent, planning should be happening
> via the spec review process *anyway*. Also, we already have a larger back
> log of specs and work than we had this time last cycle, but with the same
> size review team. Rather than adding to our backlog, I would like us to use
> this gathering to burn through some specs and land some code.
> 
> That being said, I'd also like to put forth this idea: if we had a second
> gathering (with the same focus on writing code) the following week (let's
> say, Feb 11 - 13) in the SF Bay area -- who would attend? Would we be able
> to get the "other half" of the core team together and get more work done?
> Is this a good idea?
> 

I'm +1 on a Bay Area meetup; however, if it happens I likely won't be
making the Grenoble meetup. There's a slim chance I can do both. I'd
like to figure this out ASAP so I can book travel at a reasonable price.

A second meetup certainly can't be bad; I'm sure we can get a ton of
work done with the folks that I assume would attend. :)

// jim

> OK. That's enough of my musing for now...
> 
> Once again, if you will be attending the midcycle sprint in Grenoble the
> week of Feb 3rd, please sign up HERE
> 
> .
> 
> Regards,
> Devananda

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


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

[openstack-dev] [Neutron][ML2] - canceling this week's ML2 meeting

[Sukhdev Kapur]

Dear fellow ML2'ers,

In sprit of holidays, Bob and I decided to cancel this week's ML2 meeting.
We will resume our meetings from January 7th onwards.

Happy New Year to you and your loved ones.

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

[openstack-dev] [Neutron] CI configure for neutron ML2 mechanism driver

[thanh le giang]

Hi all

According to this tutorial
http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/,
I have setup CI system successfully. Now, I wonder if Our CI system need to
run tempest test against network with real our device or just need run our
unit test ?

Any advice is appreciated.

Thanks and Regards

-- 
L.G.Thanh

Email: legiangt...@gmail.com 
lgth...@fit.hcmus.edu.vn
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Keystone] reminder no meeting this week

[Morgan Fainberg]

This is just a reminder there will be no meeting this week for Keystone. 

Have a great New Years!
--Morgan

Sent via mobile

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

Re: [openstack-dev] [Nova] should 'ip address' be retrived when decribe host?

[Lingxian Kong]

Thanks, Jay Pipes and Jay Lau, for your reply!

Just as what Jay Lau said, 'nova hypervisor-show '
indeed returns host ip address, and there are more other information
included than 'nova host-describe '. I feel a little
confused about the 'host' and 'hypervisor', what's the difference
between them? For cloud operator, maybe 'host' is more usefull and
intuitive for management than 'hypervisor'. From the implementation
perspective, both 'compute_nodes' and 'services' database tables are
used for them. Should them be combined for more common use cases?

2014-12-29 21:40 GMT+08:00 Jay Lau :
> Does "nova hypervisor-show" help? It already include the host ip address.
>
> 2014-12-29 21:26 GMT+08:00 Jay Pipes :
>>
>> On 12/29/2014 06:51 AM, Lingxian Kong wrote:
>>>
>>> Hi Stackers:
>>>
>>> As for now, we can get the 'host name', 'service' and 'availability
>>> zone' of a host through the CLI command 'nova host-list'. But as a
>>> programmer who communicates with OpenStack using its API, I want to
>>> get the host ip address, in order to perform some other actions in my
>>> program.
>>>
>>> And what I know is, the ip address of a host is populated in the
>>> 'compute_nodes' table of the database, during the 'update available
>>> resource' periodic task.
>>>
>>> So, is it possible of the community to support it in the future?
>>>
>>> I apologize if the topic was once covered and I missed it.
>>
>>
>> Hi!
>>
>> I see no real technical reason this could not be done. It would require
>> waiting until all of the API microversioning bits are done, and a
>> micro-increment of the API, along with minimal changes of code in the hosts
>> extension to return the host_ip field from the nova.objects.ComputeNode
>> objects returned to the HostController object.
>>
>> Are you interested in working on such a feature? I would be happy to guide
>> you through the process of making a blueprint and submitting code if you'd
>> like. Just find me on IRC #openstack-nova. My IRC nick is jaypipes.
>>
>> Best,
>> -jay
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Thanks,
>
> Jay
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
---
Lingxian Kong

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

[openstack-dev] check-grenade-dsvm-ironic-sideways failing, blocking much code

[Adam Gandelman]

Heads up here since IRC seems to be crickets this week...

Fallout from newer pip's creation and usage of ~/.cache is still biting the
sideways ironic grenade job:

https://bugs.launchpad.net/ironic/+bug/1405626

This is blocking patches to ironic, nova, devstack, tempest, grenade master
+ stable/juno.  master's main tempest job was broken by the same issue
during the holiday, and fixed with some patches to devstack.  Those need to
be backported to stable/juno devstack and grenade (via a functions-common
sync), but two remaining patches are wedged and cannot merge without the
other:

https://review.openstack.org/#/c/144352/
https://review.openstack.org/#/c/144374/

I've proposed temporary workaround to devstack-gate, which will hopefully
allow those two to backport:

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

If anyone has a minute while they switch from eggnog to champagne, it would
be appreciated!

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