Re: [openstack-dev] [watcher] Stepping down as Watcher spec core

[Joe Cropper]

Antoine,

It’s been a pleasure getting to work alongside you in the open source 
community.  Your leadership was paramount to the project and I wish you all the 
best in your next chapter!

Best,
Joe (jwcroppe)


> On Aug 15, 2017, at 1:26 PM, Susanne Balle  wrote:
> 
> Thanks for all the hard work. best of luck, 
> 
> Susanne
> 
> On Fri, Jul 21, 2017 at 3:48 AM, Чадин Александр (Alexander Chadin) 
> mailto:a.cha...@servionica.ru>> wrote:
> Antoine,
> 
> Congratulations to the new step of your life!
> You’ve set high level of project management and this is big honour to me to 
> fit it.
> Hope to see you in Vancouver!
> 
> Best Regards,
> _
> Alexander Chadin
> OpenStack Developer
> 
>> On 21 Jul 2017, at 03:44, Hidekazu Nakamura > > wrote:
>> 
>> Hi Antoine,
>> 
>> I am grateful for your support from my starting contributing to Watcher.
>> Thanks to you I am contributing to Watcher actively now. 
>> 
>> I wish you live a happy life and a successful career.
>> 
>> Hidekazu Nakamura
>> 
>> 
>>> -Original Message-
>>> From: Antoine Cabot [mailto:antoinecabo...@gmail.com 
>>> ]
>>> Sent: Thursday, July 20, 2017 6:35 AM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> >> >
>>> Subject: [openstack-dev] [watcher] Stepping down as Watcher spec core
>>> 
>>> Hey guys,
>>> 
>>> It's been a long time since the last summit and our last discussions !
>>> I hope Watcher is going well and you are getting more traction
>>> everyday in the OpenStack community !
>>> 
>>> As you may guess, my last 2 months have been very busy with my
>>> relocation in Vancouver with my family. After 8 weeks of active job
>>> search in the cloud industry here in Vancouver, I've got a Senior
>>> Product Manager position at Parsable, a start-up leading the Industry
>>> 4.0 revolution. I will continue to deal with very large customers but
>>> in different industries (Oil & Gas, Manufacturing...) to build the
>>> best possible product, leveraging cloud and mobile technologies.
>>> 
>>> It was a great pleasure to lead the Watcher initiative from its
>>> infancy to the OpenStack Big Tent and be able to work with all of you.
>>> I hope to be part of another open source community in the near future
>>> but now, due to my new attributions, I need to step down as a core
>>> contributor to Watcher specs. Feel free to reach me in any case if I
>>> still hold restricted rights on launchpad or anywhere else.
>>> 
>>> I hope to see you all in Vancouver next year for the summit and be
>>> part of the traditional Watcher dinner (I will try to find the best
>>> place for you guys).
>>> 
>>> Cheers,
>>> 
>>> Antoine
>>> 
>>> __
>>> 
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org 
>>> ?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
>> ?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Watcher] Nominating Prudhvi Rao Shedimbi to Watcher Core

[Joe Cropper]

+1 !

> On Feb 14, 2017, at 4:05 AM, Vincent FRANÇOISE  
> wrote:
> 
> Team,
> 
> I would like to promote Prudhvi Rao Shedimbi to the core team. He's done
> a great work in reviewing many patchsets[1] and I believe that he has a
> good vision of Watcher as a whole.
> 
> I think he would make an excellent addition to the team.
> 
> Please vote
> 
> [1] http://stackalytics.com/report/contribution/watcher/90
> 
> Vincent FRANCOISE
> B<>COM
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [watcher] Nominate Prashanth Hari as core for watcher-specs

[Joe Cropper]

+1

> On Aug 16, 2016, at 11:59 AM, Jean-Émile DARTOIS 
>  wrote:
> 
> +1
> 
> Jean-Emile
> DARTOIS
> 
> {P} Software Engineer
> Cloud Computing
> 
> {T} +33 (0) 2 56 35 8260
> {W} www.b-com.com
> 
> 
> De : Antoine Cabot 
> Envoyé : mardi 16 août 2016 16:57
> À : OpenStack Development Mailing List (not for usage questions)
> Objet : [openstack-dev] [watcher] Nominate Prashanth Hari as core for   
> watcher-specs
> 
> Hi Watcher team,
> 
> I'd like to nominate Prashanth Hari as core contributor for watcher-specs.
> As a potential end-user for Watcher, Prashanth gave us a lot of good
> feedback since the Mitaka release.
> Please vote for his candidacy.
> 
> Antoine
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [watcher] Stepping down from core

[Joe Cropper]

Thanks Taylor… thanks so much for your contributions!

Best,
Joe

> On Aug 3, 2016, at 11:32 AM, Taylor D Peoples  wrote:
> 
> Hi all,
> 
> I'm stepping down from Watcher core and will be leaving the OpenStack 
> community to pursue other opportunities.
> 
> I wasn't able to contribute to Watcher anywhere near the amount that I was 
> hoping, but I have enjoyed the little that I was able to contribute.
> 
> Good luck to the Watcher team going forward.
> 
> 
> Best,
> Taylor Peoples
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [watcher] Mascot final choice

[Joe Cropper]

+2 to Jellyfish!

> On Jul 28, 2016, at 4:08 PM, Antoine Cabot  wrote:
> 
> Hi Watcher team,
> 
> Last week during the mid-cycle, we came up with a list of possible mascots 
> for Watcher. The only one which is in conflict with other projects is the 
> bee. 
> So we have this final list :
> 1. Jellyfish
> 2. Eagle
> 3. Hammerhead shark
> 
> I'm going to confirm jellyfish as the Watcher mascot by EOW except if any 
> contributor is against this choice. Please let me know.
> 
> Antoine
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [watcher] Watcher meetings in Austin

[Joe Cropper]

Hi Watcher team,

Resending this in case folks missed it.

Thanks,

Joe (jwcroppe)


> On Apr 22, 2016, at 4:37 AM, Antoine Cabot  wrote:
> 
> Hi Watcher team,
> 
> We will have a couple of meetings next week to discuss Watcher
> achievements during the Mitaka cycle and define priorities for Newton.
> 
> Meetings will be held in the developer lounge in Austin
> https://wiki.openstack.org/wiki/Design_Summit/Newton/Etherpads#Watcher
> 
> A proposed open agenda is available
> https://etherpad.openstack.org/p/watcher-newton-design-session
> 
> If you want to meet with Watcher team and discuss your use cases,
> feel free to join us and add your discussion topic to the agenda.
> 
> Thanks,
> 
> Antoine (acabot)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Watcher] Nominating Vincent Francoise to Watcher Core

[Joe Cropper]

+1

> On Feb 17, 2016, at 8:05 AM, David TARDIVEL  wrote:
> 
> Team,
> 
> I’d like to promote Vincent Francoise to the core team. Vincent's done a 
> great work
> on code reviewing and has proposed a lot of patchsets. He is currently the 
> most active 
> non-core reviewer on Watcher project, and today, he has a very good vision of 
> Watcher. 
> I think he would make an excellent addition to the team.
> 
> Please vote
> 
> David TARDIVEL
> b<>COM
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [watcher] Travel logistics for mid-cycle in Austin

[Joe Cropper]

Hi Watcher Team,

For those of you attending the Watcher mid-cycle next week in Austin 
(Tue-Thurs), please take a quick look at the travel details [1] — particularly 
the bit about where to “check in” every day once you arrive to the IBM campus.

As another FYI, light breakfast foods, lunch and an afternoon snack will be 
served daily.

Looking forward to seeing everyone next week!

[1] 
https://wiki.openstack.org/wiki/Watcher_mitaka_mid-cycle_meetup_agenda#Travel

Thanks,
Joe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] [watcher] New project: Watcher

[Joe Cropper]

> On Nov 2, 2015, at 4:50 AM, Thierry Carrez  wrote:
> 
> Antoine CABOT wrote:
>> We are pleased to introduce Watcher, a new project in the OpenStack 
>> ecosystem. We believe that a "resource optimization" service in an 
>> OpenStack-based cloud is a crucial component that has been missing to 
>> date and we have started working towards filling that gap.
>> 
>> OpenStack Watcher provides a flexible and scalable resource 
>> optimization service for multi-tenant OpenStack-based clouds. 
>> [...]
> 
> Please note that this project is not an official OpenStack project yet.
> In particular, it's not been approved by the Technical Committee to join
> the "big tent" yet, and it was actually never proposed there.
> 
> If you intend to propose this new project for inclusion, please propose
> an openstack/governance change to that effect. You can find the current
> project requirements at:
> 
> http://governance.openstack.org/reference/new-projects-requirements.html
> 
> In the mean time, please refrain from calling your project "OpenStack
> Watcher". Thanks in advance!

No problem, Thierry!  Our apologies for the terminology hiccup.  We do intent 
to propose it as part of the “big tent” in the coming months—the project’s wiki 
and source code repository were just recently configured on openstack.org and 
we’re actively working on the checklist of items you referenced.  :-)

Regards,
Joe (jwcroppe)

> 
> -- 
> Thierry Carrez (ttx)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] questions about nova compute monitors extensions

[Joe Cropper]

The new framework does indeed support user-defined monitors.  You just extend 
whatever monitor’d like (e.g., nova.compute.monitors.cpu.virt_driver.Monitor) 
and add your customized logic.  And since the new framework uses 
stevedore-based extension points, you just need to be sure to add the 
appropriate entry to your project’s setup.py file (or entry_points.txt in your 
egg) so that stevedore can load them properly.

Hope this helps!

Thanks,
Joe
> On Sep 10, 2015, at 2:52 AM, Hou Gang HG Liu  wrote:
> 
> Hi all, 
> 
> I notice nova compute monitor now only tries to load monitors with namespace 
> "nova.compute.monitors.cpu", and only one monitor in one namespace can be 
> enabled( 
> https://review.openstack.org/#/c/209499/6/nova/compute/monitors/__init__.py 
> ).
>  
> 
> Is there a plan to make MonitorHandler.NAMESPACES configurable or just hard 
> code constraint as it is now? And how to make compute monitor support user 
> defined as it was? 
> 
> Thanks! 
> B.R 
> 
> Hougang Liu （刘侯刚） 
> Developer - IBM Platform Resource Scheduler   
>   Attachment.gif> 
> Systems and Technology Group 
> 
> Mobile: 86-13519121974 | Phone: 86-29-68797023 | Tie-Line: 87023  
>  陕西省西安市高新六路42号中清大厦3层
> E-mail: liuh...@cn.ibm.com
>  Xian, Shaanxi Province 710075, 
> China
> 
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Intended behavior for instance.host on reschedule?

[Joe Cropper]

Logged a bug [1] and submitted a fix [2].  Review away!

[1] https://bugs.launchpad.net/nova/+bug/1427944
[2] https://review.openstack.org/#/c/161069/

- Joe


> On Mar 3, 2015, at 4:42 PM, Jay Pipes  wrote:
> 
> On 03/03/2015 06:55 AM, Joe Cropper wrote:
>>> On Mar 3, 2015, at 8:34 AM, Vishvananda Ishaya
>>>  wrote:
>>> 
>>> I’m pretty sure it has always done this: leave the host set on the
>>> final scheduling attempt. I agree that this could be cleared which
>>> would free up room for future scheduling attempts.
>> 
>> Thanks Vish for the comment.  Do we know if this is an intended
>> feature or would we consider this a bug?  It seems like we could free
>> this up, as you said, to allow room for additional VMs, especially
>> since we know it didn’t successfully deploy anyway?
> 
> Seems like a bug to me. Feel free to create one in Launchpad and we'll get on 
> it.
> 
> Best,
> -jay
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Intended behavior for instance.host on reschedule?

[Joe Cropper]

> On Mar 3, 2015, at 8:34 AM, Vishvananda Ishaya  wrote:
> 
> I’m pretty sure it has always done this: leave the host set on the final 
> scheduling attempt. I agree that this could be cleared which would free up 
> room for future scheduling attempts.
> 

Thanks Vish for the comment.  Do we know if this is an intended feature or 
would we consider this a bug?  It seems like we could free this up, as you 
said, to allow room for additional VMs, especially since we know it didn’t 
successfully deploy anyway?

> Vish
> 
> On Mar 3, 2015, at 12:15 AM, Joe Cropper  wrote:
> 
>> Hi Folks,
>> 
>> I was wondering if anyone can comment on the intended behavior of how 
>> instance.host is supported to be set during reschedule operations.  For 
>> example, take this scenario:
>> 
>> 1. Assume an environment with a single host… call it host-1
>> 2. Deploy a VM, but force an exception in the spawn path somewhere to 
>> simulate some "hypervisor error”
>> 3. The scheduler correctly attempts to reschedule the VM, and ultimately 
>> ends up (correctly) with a NoValidHost error because there was only 1 host
>> 4. However, the instance.host (e.g., [nova show ]) is still showing 
>> ‘host-1’ — is this the expected behavior?
>> 
>> It seems like perhaps the claim should be reverted (read: instance.host 
>> nulled out) when we take the exception path during spawn in step #2 above, 
>> but maybe I’m overlooking something?  This behavior was observed on a Kilo 
>> base from a couple weeks ago, FWIW.
>> 
>> Thoughts/comments?
>> 
>> Thanks,
>> Joe
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Intended behavior for instance.host on reschedule?

[Joe Cropper]

Hi Folks,

I was wondering if anyone can comment on the intended behavior of how 
instance.host is supported to be set during reschedule operations.  For 
example, take this scenario:

1. Assume an environment with a single host… call it host-1
2. Deploy a VM, but force an exception in the spawn path somewhere to simulate 
some "hypervisor error”
3. The scheduler correctly attempts to reschedule the VM, and ultimately ends 
up (correctly) with a NoValidHost error because there was only 1 host
4. However, the instance.host (e.g., [nova show ]) is still showing 
‘host-1’ — is this the expected behavior?

It seems like perhaps the claim should be reverted (read: instance.host nulled 
out) when we take the exception path during spawn in step #2 above, but maybe 
I’m overlooking something?  This behavior was observed on a Kilo base from a 
couple weeks ago, FWIW.

Thoughts/comments?

Thanks,
Joe
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Question about force_host skip filters

[Joe Cropper]

+1 to using a filter property to indicate whether the filter needs to be run on 
force_hosts.  As others have said, there are certain cases that need to be 
checked even if the admin is trying to intentionally place a VM somewhere such 
that we can fail early vs. letting the hypervisor blow up on the request in the 
future (i.e., to help prevent the user from stepping on their own toes).  :-)

Along these lines—dare I bring up the topic of providing an enhanced mechanism 
to determine which filter(s) contributed to NoValidHost exceptions?  Do others 
ever hear about operators getting this, and then having no idea why a VM deploy 
failed?  This is likely another thread, but thought I’d pose it here to see if 
we think this might be a potential blueprint as well.

- Joe

> On Feb 17, 2015, at 10:20 AM, Nikola Đipanov  wrote:
> 
> On 02/17/2015 04:59 PM, Chris Friesen wrote:
>> On 02/16/2015 01:17 AM, Nikola Đipanov wrote:
>>> On 02/14/2015 08:25 AM, Alex Xu wrote:
>> 
 Agree with Nikola, the claim already checking that. And instance booting
 must be failed if there isn't pci device. But I still think it should go
 through the filters, because in the future we may move the claim into
 the scheduler. And we needn't any new options, I didn't see there is any
 behavior changed.
 
>>> 
>>> I think that it's not as simple as just re-running all the filters. When
>>> we want to force a host - there are certain things we may want to
>>> disregard (like aggregates? affinity?) that the admin de-facto overrides
>>> by saying they want a specific host, and there are things we definitely
>>> need to re-run to set the limits and for the request to even make sense
>>> (like NUMA, PCI, maybe some others).
>>> 
>>> So what I am thinking is that we need a subset of filters that we flag
>>> as - "we need to re-run this even for force-host", and then run them on
>>> every request.
>> 
>> Yeah, that makes sense.  Also, I think that flag should be an attribute
>> of the filter itself, so that people adding new filters don't need to
>> also add the filter to a list somewhere.
>> 
> 
> This is basically what I had in mind - definitely a filter property!
> 
> N.
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] review closure for nova blueprint review.openstack.org/#/c/140133/

[Joe Cropper]

Prefixing subject with [nova] so folks’ mail rules catch this.

- Joe

> On Jan 5, 2015, at 1:47 PM, Kenneth Burger  wrote:
> 
> Hi, I am trying to get approval on this nova blueprint, 
> https://review.openstack.org/#/c/140133/ 
> .   There was a +2 from Michael 
> Still ( twice in prior patches ) and a +1 from Jay Bryant from a cinder 
> perspective.The only changes from the patches receiving the +2  was 
> related to a directory change of the spec location in the repository.   
> 
> Is it still possible to get approval for this blueprint?
> 
> Thanks,
> Ken Burger
> 
> ___
> 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] Evacuate instance which in server group with affinity policy

[Joe Cropper]

This is another great example of a use case in which these blueprints [1, 2] 
would be handy.  They didn’t make the clip line for Kilo, but we’ll try again 
for L.  I personally don’t think the scheduler should have “special case” rules 
about when/when not to apply affinity policies, as that could be confusing for 
administrators.  It would be simple to just remove it from the group, thereby 
allowing the administrator to rebuild the VM anywhere s/he wants… and then 
re-add the VM to the group once the environment is operational once again.

[1] https://review.openstack.org/#/c/136487/
[2] https://review.openstack.org/#/c/139272/

- Joe

On Dec 21, 2014, at 8:36 PM, Lingxian Kong  wrote:

> 2014-12-22 9:21 GMT+08:00 Alex Xu :
>> 
>> 
>> 2014-12-22 9:01 GMT+08:00 Lingxian Kong :
>>> 
> 
>>> 
>>> but what if the compute node is back to normal? There will be
>>> instances in the same server group with affinity policy, but located
>>> in different hosts.
>>> 
>> 
>> If operator decide to evacuate the instance from the failed host, we should
>> fence the failed host first.
> 
> Yes, actually. I mean the recommandation or prerequisite should be
> emphasized somewhere, e.g. the Operation Guide, otherwise it'll make
> things more confused. But the issue you are working around is indeed a
> problem we should solve.
> 
> -- 
> Regards!
> ---
> Lingxian Kong
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [qa] host aggregate's availability zone

[Joe Cropper]

Did you enable the AvailabilityZoneFilter in nova.conf that the scheduler uses? 
 And enable the FilterScheduler?  These are two common issues related to this.

- Joe

> On Dec 21, 2014, at 10:28 AM, Danny Choi (dannchoi)  
> wrote:
> 
> Hi,
> 
> I have a multi-node setup with 2 compute hosts, qa5 and qa6.
> 
> I created 2 host-aggregate, each with its own availability zone, and assigned 
> one compute host:
> 
> localadmin@qa4:~/devstack$ nova aggregate-details host-aggregate-zone-1
> ++---+---+---+--+
> | Id | Name  | Availability Zone | Hosts | Metadata   
>   |
> ++---+---+---+--+
> | 9  | host-aggregate-zone-1 | az-1  | 'qa5' | 
> 'availability_zone=az-1' |
> ++---+---+---+--+
> localadmin@qa4:~/devstack$ nova aggregate-details host-aggregate-zone-2
> ++---+---+---+--+
> | Id | Name  | Availability Zone | Hosts | Metadata   
>   |
> ++---+---+---+--+
> | 10 | host-aggregate-zone-2 | az-2  | 'qa6' | 
> 'availability_zone=az-2' |
> ++---+---+---+—+
> 
> My intent is to control at which compute host to launch a VM via the 
> host-aggregate’s availability-zone parameter.
> 
> To test, for vm-1, I specify --availiability-zone=az-1, and 
> --availiability-zone=az-2 for vm-2:
> 
> localadmin@qa4:~/devstack$ nova boot --image cirros-0.3.2-x86_64-uec --flavor 
> 1 --nic net-id=5da9d715-19fd-47c7-9710-e395b5b90442 --availability-zone az-1 
> vm-1
> +--++
> | Property | Value
>   |
> +--++
> | OS-DCF:diskConfig| MANUAL   
>   |
> | OS-EXT-AZ:availability_zone  | nova 
>   |
> | OS-EXT-SRV-ATTR:host | -
>   |
> | OS-EXT-SRV-ATTR:hypervisor_hostname  | -
>   |
> | OS-EXT-SRV-ATTR:instance_name| instance-0066
>   |
> | OS-EXT-STS:power_state   | 0
>   |
> | OS-EXT-STS:task_state| -
>   |
> | OS-EXT-STS:vm_state  | building 
>   |
> | OS-SRV-USG:launched_at   | -
>   |
> | OS-SRV-USG:terminated_at | -
>   |
> | accessIPv4   |  
>   |
> | accessIPv6   |  
>   |
> | adminPass| kxot3ZBZcBH6 
>   |
> | config_drive |  
>   |
> | created  | 2014-12-21T15:59:03Z 
>   |
> | flavor   | m1.tiny (1)  
>   |
> | hostId   |  
>   |
> | id   | 854acae9-b718-4ea5-bc28-e0bc46378b60 
>   |
> | image| cirros-0.3.2-x86_64-uec 
> (61409a53-305c-4022-978b-06e55052875b) |
> | key_name | -
>   |
> | metadata | {}   
>   |
> | name | vm-1 
>   |
> | os-extended-volumes:volumes_attached | []   
>   |
> | progress | 0
>   |
> | security_groups  | default  
>   |
> | status   | BUILD 

Re: [openstack-dev] [All] Maintenance mode in OpenStack during patching/upgrades

[Joe Cropper]

I’m glad to see this topic getting some focus once again.  :-)

>From several of the administrators I talk with, when they think of putting a 
>host into maintenance mode, the common requests I hear are:

1. Don’t schedule more VMs to the host
2. Provide an optional way to automatically migrate all (usually active) VMs 
off the host so that users’ workloads remain “unaffected” by the maintenance 
operation

#1 can easily be achieved, as has been mentioned several times, by simply 
disabling the compute service.  However, #2 involves a little more work, 
although certainly possible using all the operations provided by nova today 
(e.g., live migration, etc.).  I believe these types of discussions have come 
up several times over the past several OpenStack releases—certainly since 
Grizzly (i.e., when I started watching this space).

It seems that the general direction is to have the type of workflow needed for 
#2 outside of nova (which is certainly a valid stance).  To that end, it would 
be fairly straightforward to build some code that logically sits on top of 
nova, that when entering maintenance:

1. Prevents VMs from being scheduled to the host;
2. Maintains state about the maintenance operation (e.g., not in maintenance, 
migrations in progress, in maintenance, or error);
3. Provides mechanisms to, upon entering maintenance, dictates which VMs 
(active, all, none) to migrate and provides some throttling capabilities to 
prevent hundreds of parallel migrations on densely packed hosts (all done via a 
REST API).

If anyone has additional questions, comments, or would like to discuss some 
options, please let me know.  If interested, upon request, I could even share a 
video of how such cases might work.  :-)  My colleagues and I have given these 
use cases a lot of thought and consideration and I’d love to talk more about 
them (perhaps a small session in Paris would be possible).

- Joe

On Oct 17, 2014, at 4:18 AM, John Garbutt  wrote:

> On 17 October 2014 02:28, Matt Riedemann  wrote:
>> 
>> 
>> On 10/16/2014 7:26 PM, Christopher Aedo wrote:
>>> 
>>> On Tue, Sep 9, 2014 at 2:19 PM, Mike Scherbakov
>>>  wrote:
> 
> On Tue, Sep 9, 2014 at 6:02 PM, Clint Byrum  wrote:
 
 The idea is not simply deny or hang requests from clients, but provide
 them
 "we are in maintenance mode, retry in X seconds"
 
> You probably would want 'nova host-servers-migrate '
 
 yeah for migrations - but as far as I understand, it doesn't help with
 disabling this host in scheduler - there is can be a chance that some
 workloads will be scheduled to the host.
>>> 
>>> 
>>> Regarding putting a compute host in maintenance mode using "nova
>>> host-update --maintenance enable", it looks like the blueprint and
>>> associated commits were abandoned a year and a half ago:
>>> https://blueprints.launchpad.net/nova/+spec/host-maintenance
>>> 
>>> It seems that "nova service-disable  nova-compute" effectively
>>> prevents the scheduler from trying to send new work there.  Is this
>>> the best approach to use right now if you want to pull a compute host
>>> out of an environment before migrating VMs off?
>>> 
>>> I agree with Tim and Mike that having something respond "down for
>>> maintenance" rather than ignore or hang would be really valuable.  But
>>> it also looks like that hasn't gotten much traction in the past -
>>> anyone feel like they'd be in support of reviving the notion of
>>> "maintenance mode"?
>>> 
>>> -Christopher
>>> 
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>> 
>> host-maintenance-mode is definitely a thing in nova compute via the os-hosts
>> API extension and the --maintenance parameter, the compute manager code is
>> here [1].  The thing is the only in-tree virt driver that implements it is
>> xenapi, and I believe when you put the host in maintenance mode it's
>> supposed to automatically evacuate the instances to some other host, but you
>> can't target the other host or tell the driver, from the API, which
>> instances you want to evacuate, e.g. all, none, running only, etc.
>> 
>> [1]
>> http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py?id=2014.2#n3990
> 
> We should certainly make that more generic. It doesn't update the VM
> state, so its really only admin focused in its current form.
> 
> The XenAPI logic only works when using XenServer pools with shared NFS
> storage, if my memory serves me correctly. Honestly, its a bit of code
> I have planned on removing, along with the rest of the pool support.
> 
> In terms of requiring DB downtime in Nova, the current efforts are
> focusing on avoiding downtime all together, via expand/contract style
> migrations, with a little help from objects to avoid data migrations.
> 
> That doesn't mean maintenance mode if not useful for other things,
> 

Re: [openstack-dev] [Nova] Automatic evacuate

[Joe Cropper]

I've been thinking a lot about these use cases too. As was previously 
suggested, I think a session in Paris in this topic would be immensely 
beneficial. Is there somewhere we can officially log a room or some such for 
further discussion?

- Joe

> On Oct 15, 2014, at 9:04 PM, Russell Bryant  wrote:
> 
>> On 10/15/2014 05:07 PM, Florian Haas wrote:
>> On Wed, Oct 15, 2014 at 10:03 PM, Russell Bryant  wrote:
 Am I making sense?
>>> 
>>> Yep, the downside is just that you need to provide a new set of flavors
>>> for "ha" vs "non-ha".  A benefit though is that it's a way to support it
>>> today without *any* changes to OpenStack.
>> 
>> Users are already very used to defining new flavors. Nova itself
>> wouldn't even need to define those; if the vendor's deployment tools
>> defined them it would be just fine.
> 
> Yes, I know Nova wouldn't need to define it.  I was saying I didn't like
> that it was required at all.
> 
>>> This seems like the kind of thing we should also figure out how to offer
>>> on a per-guest basis without needing a new set of flavors.  That's why I
>>> also listed the server tagging functionality as another possible solution.
>> 
>> This still doesn't do away with the requirement to reliably detect
>> node failure, and to fence misbehaving nodes. Detecting that a node
>> has failed, and fencing it if unsure, is a prerequisite for any
>> recovery action. So you need Corosync/Pacemaker anyway.
> 
> Obviously, yes.  My post covered all of that directly ... the tagging
> bit was just additional input into the recovery operation.
> 
>> Note also that when using an approach where you have physically
>> clustered nodes, but you are also running non-HA VMs on those, then
>> the user must understand that the following applies:
>> 
>> (1) If your guest is marked HA, then it will automatically recover on
>> node failure, but
>> (2) if your guest is *not* marked HA, then it will go down with the
>> node not only if it fails, but also if it is fenced.
>> 
>> So a non-HA guest on an HA node group actually has a slightly
>> *greater* chance of going down than a non-HA guest on a non-HA host.
>> (And let's not get into "don't use fencing then"; we all know why
>> that's a bad idea.)
>> 
>> Which is why I think it makes sense to just distinguish between
>> HA-capable and non-HA-capable hosts, and have the user decide whether
>> they want HA or non-HA guests simply by assigning them to the
>> appropriate host aggregates.
> 
> Very good point.  I hadn't considered that.
> 
> -- 
> 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] Server Groups - remove VM from group?

[Joe Cropper]

I would be a little wary about the DB level locking for stuff like that — it’s 
certainly doable, but also comes at the expense of things behaving 
ever-so-slightly different from DBMS to DBMS.  Perhaps there are multiple 
“logical efforts” here—i.e., adding some APIs and cleaning up existing code.

In any case, I’ve started a blueprint on this [1] and we can continue iterating 
in the nova-spec once kilo opens up.  Thanks all for the good discussion on 
this thus far.

[1] https://blueprints.launchpad.net/nova/+spec/dynamic-server-groups

- Joe
On Sep 11, 2014, at 5:04 PM, Chris Friesen  wrote:

> On 09/11/2014 03:01 PM, Jay Pipes wrote:
>> On 09/11/2014 04:51 PM, Matt Riedemann wrote:
>>> On 9/10/2014 6:00 PM, Russell Bryant wrote:
>>>> On 09/10/2014 06:46 PM, Joe Cropper wrote:
>>>>> Hmm, not sure I follow the concern, Russell.  How is that any different
>>>>> from putting a VM into the group when it’s booted as is done today?
>>>>>  This simply defers the ‘group insertion time’ to some time after
>>>>> initial the VM’s been spawned, so I’m not sure this creates anymore
>>>>> race
>>>>> conditions than what’s already there [1].
>>>>> 
>>>>> [1] Sure, the to-be-added VM could be in the midst of a migration or
>>>>> something, but that would be pretty simple to check make sure its task
>>>>> state is None or some such.
>>>> 
>>>> The way this works at boot is already a nasty hack.  It does policy
>>>> checking in the scheduler, and then has to re-do some policy checking at
>>>> launch time on the compute node.  I'm afraid of making this any worse.
>>>> In any case, it's probably better to discuss this in the context of a
>>>> more detailed design proposal.
>>>> 
>>> 
>>> This [1] is the hack you're referring to right?
>>> 
>>> [1]
>>> http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py?id=2014.2.b3#n1297
>>> 
>> 
>> That's the hack *I* had in the back of my mind.
> 
> I think that's the only boot hack related to server groups.
> 
> I was thinking that it should be possible to deal with the race more cleanly 
> by recording the selected compute node in the database at the time of 
> scheduling.  As it stands, the host is implicitly encoded in the compute node 
> to which we send the boot request and nobody else knows about it.
> 
> Chris
> 
> 
> ___
> 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] Server Groups - remove VM from group?

[Joe Cropper]

Great to hear.  I started a blueprint for this [1].  More detail can be added 
once the kilo nova-specs directory is created… for now, I’ve tried to put some 
fairly detailed notes on the blueprint’s description.

[1] https://blueprints.launchpad.net/nova/+spec/dynamic-server-groups

- Joe
On Sep 11, 2014, at 2:11 AM, Sylvain Bauza  wrote:

> 
> Le 11/09/2014 01:10, Joe Cropper a écrit :
>> Agreed - I’ll draft up a formal proposal in the next week or two and we can 
>> focus the discussion there. Thanks for the feedback - this provides a good 
>> framework for implementation considerations.
> 
> Count me on it, I'm interested in discussing the next stage.
> 
> When preparing the scheduler split, I just discovered it was unnecessary to 
> keep the instance groups setup in the scheduler, because it was creating 
> dependencies to other Nova objects that the Scheduler doesn't necessarly need 
> to handle.
> I proposed accordingly a patch for moving the logic to the conductor instead, 
> see the proposal here :
> https://review.openstack.org/110043
> 
> Reviews are welcome of course.
> 
> -Sylvain
> 
> 
>> - Joe
>> On Sep 10, 2014, at 6:00 PM, Russell Bryant  wrote:
>> 
>>> On 09/10/2014 06:46 PM, Joe Cropper wrote:
>>>> Hmm, not sure I follow the concern, Russell.  How is that any different
>>>> from putting a VM into the group when it’s booted as is done today?
>>>> This simply defers the ‘group insertion time’ to some time after
>>>> initial the VM’s been spawned, so I’m not sure this creates anymore race
>>>> conditions than what’s already there [1].
>>>> 
>>>> [1] Sure, the to-be-added VM could be in the midst of a migration or
>>>> something, but that would be pretty simple to check make sure its task
>>>> state is None or some such.
>>> The way this works at boot is already a nasty hack.  It does policy
>>> checking in the scheduler, and then has to re-do some policy checking at
>>> launch time on the compute node.  I'm afraid of making this any worse.
>>> In any case, it's probably better to discuss this in the context of a
>>> more detailed design proposal.
>>> 
>>> -- 
>>> 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
> 
> 
> ___
> 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 for Kilo?

[Joe Cropper]

Thanks!  Exactly what I was looking for.

On Sep 11, 2014, at 12:38 AM, Russell Bryant  wrote:

> On 09/11/2014 01:32 AM, Joe Cropper wrote:
>> Hi Folks,
>> 
>> Just wondering if the nova-specs master branch will have a ‘kilo’
>> directory created soon for Kilo proposals? I have a few things I’d like
>> to submit, just looking for the proper home.
> 
> There's some more info on that here:
> 
> http://lists.openstack.org/pipermail/openstack-dev/2014-August/044431.html
> 
> -- 
> 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

[openstack-dev] [nova] nova-specs for Kilo?

[Joe Cropper]

Hi Folks,

Just wondering if the nova-specs master branch will have a ‘kilo’ directory 
created soon for Kilo proposals?  I have a few things I’d like to submit, just 
looking for the proper home.

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

Re: [openstack-dev] [nova] Server Groups - remove VM from group?

[Joe Cropper]

Agreed - I’ll draft up a formal proposal in the next week or two and we can 
focus the discussion there.  Thanks for the feedback - this provides a good 
framework for implementation considerations.

- Joe
On Sep 10, 2014, at 6:00 PM, Russell Bryant  wrote:

> On 09/10/2014 06:46 PM, Joe Cropper wrote:
>> Hmm, not sure I follow the concern, Russell.  How is that any different
>> from putting a VM into the group when it’s booted as is done today?
>> This simply defers the ‘group insertion time’ to some time after
>> initial the VM’s been spawned, so I’m not sure this creates anymore race
>> conditions than what’s already there [1].
>> 
>> [1] Sure, the to-be-added VM could be in the midst of a migration or
>> something, but that would be pretty simple to check make sure its task
>> state is None or some such.
> 
> The way this works at boot is already a nasty hack.  It does policy
> checking in the scheduler, and then has to re-do some policy checking at
> launch time on the compute node.  I'm afraid of making this any worse.
> In any case, it's probably better to discuss this in the context of a
> more detailed design proposal.
> 
> -- 
> 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] Server Groups - remove VM from group?

[Joe Cropper]

+1, Chris.

I think the key thing here is that such race conditions can already happen if 
timed just right, unless there’s been some additional checks put in place in 
the compute API layer since I last scanned the code.  We could even look at 
some x-process locking mechanisms as well if we think that’s necessary.

Overall, this seems like a feasible, fairly minor enhancement--that wouldn’t 
make us any worse off than we are today (perhaps address some existing race 
conditions), all whilst providing a large improvement to the overall usability 
of the server groups.  :-)

- Joe
On Sep 10, 2014, at 5:54 PM, Chris Friesen  wrote:

> On 09/10/2014 04:16 PM, Russell Bryant wrote:
>> 
>> 
>>> On Sep 10, 2014, at 2:03 PM, Joe Cropper 
>>> wrote:
>>> 
>>> I would like to craft up a blueprint proposal for Kilo to add two
>>> simple extensions to the existing server group APIs that I believe
>>> will make them infinitely more usable in any ‘real world’ scenario.
>>> I’ll put more details in the proposal, but in a nutshell:
>>> 
>>> 1. Adding a VM to a server group Only allow it to succeed if its
>>> policy wouldn’t be violated by the addition of the VM
>>> 
>> 
>> I'm not sure that determining this at the time of the API request is
>> possible due to the parallel and async nature of the system. I'd love
>> to hear ideas on how you think this might be done, but I'm really not
>> optimistic and would rather just not go down this road.
> 
> I can see a possible race against another instance booting into the group, or 
> another already-running instance being added to the group.  I think the 
> solution is to do the update as an atomic database transaction.
> 
> It seems like it should be possible to create a database operation that does 
> the following in a single transaction:
> --look up the hosts for the instances in the group
> --check that the scheduler policy would be satisfied (at least for the basic 
> affinity/anti-affinity policies)
> --add the instance to the group
> 
> Chris
> 
> ___
> 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] Server Groups - remove VM from group?

[Joe Cropper]

Hmm, not sure I follow the concern, Russell.  How is that any different from 
putting a VM into the group when it’s booted as is done today?  This simply 
defers the ‘group insertion time’ to some time after initial the VM’s been 
spawned, so I’m not sure this creates anymore race conditions than what’s 
already there [1].

[1] Sure, the to-be-added VM could be in the midst of a migration or something, 
but that would be pretty simple to check make sure its task state is None or 
some such.

- Joe
On Sep 10, 2014, at 5:16 PM, Russell Bryant  wrote:

> 
> 
>> On Sep 10, 2014, at 2:03 PM, Joe Cropper  wrote:
>> 
>> I agree, Chris.  I think a number of folks put in a lot of really great work 
>> into the existing server groups and there has been a lot of interest on 
>> their usage, especially given that the scheduler already has some constructs 
>> in place to piggyback on them.
>> 
>> I would like to craft up a blueprint proposal for Kilo to add two simple 
>> extensions to the existing server group APIs that I believe will make them 
>> infinitely more usable in any ‘real world’ scenario.  I’ll put more details 
>> in the proposal, but in a nutshell:
>> 
>> 1. Adding a VM to a server group
>> Only allow it to succeed if its policy wouldn’t be violated by the addition 
>> of the VM
>> 
> 
> I'm not sure that determining this at the time of the API request is possible 
> due to the parallel and async nature of the system. I'd love to hear ideas on 
> how you think this might be done, but I'm really not optimistic and would 
> rather just not go down this road. 
> 
>> 2. Removing a VM from a server group
>> Just allow it
>> 
>> I think this would round out the support that’s there and really allow us to 
>> capitalize on the hard work everyone’s already put into them.
>> 
>> - Joe
>> 
>>> On Aug 26, 2014, at 6:39 PM, Chris Friesen  
>>> wrote:
>>> 
>>>> On 08/25/2014 11:25 AM, Joe Cropper wrote:
>>>> I was thinking something simple such as only allowing the add
>>>> operation to succeed IFF no policies are found to be in violation...
>>>> and then nova wouldn't need to get into all the complexities you
>>>> mention?
>>> 
>>> Personally I would be in favour of this...nothing fancy, just add it if it 
>>> already meets all the criteria.  This is basically just a database 
>>> operation so I would hope we could make it reliable in the face of 
>>> simultaneous things going on with the instance.
>>> 
>>>> And remove would be fairly straightforward as well since no
>>>> constraints would need to be checked.
>>> 
>>> Agreed.
>>> 
>>> Chris
>>> 
>>> ___
>>> 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] Server Groups - remove VM from group?

[Joe Cropper]

I agree, Chris.  I think a number of folks put in a lot of really great work 
into the existing server groups and there has been a lot of interest on their 
usage, especially given that the scheduler already has some constructs in place 
to piggyback on them.

I would like to craft up a blueprint proposal for Kilo to add two simple 
extensions to the existing server group APIs that I believe will make them 
infinitely more usable in any ‘real world’ scenario.  I’ll put more details in 
the proposal, but in a nutshell:

1. Adding a VM to a server group
Only allow it to succeed if its policy wouldn’t be violated by the addition of 
the VM

2. Removing a VM from a server group
Just allow it

I think this would round out the support that’s there and really allow us to 
capitalize on the hard work everyone’s already put into them.

- Joe

On Aug 26, 2014, at 6:39 PM, Chris Friesen  wrote:

> On 08/25/2014 11:25 AM, Joe Cropper wrote:
>> I was thinking something simple such as only allowing the add
>> operation to succeed IFF no policies are found to be in violation...
>> and then nova wouldn't need to get into all the complexities you
>> mention?
> 
> Personally I would be in favour of this...nothing fancy, just add it if it 
> already meets all the criteria.  This is basically just a database operation 
> so I would hope we could make it reliable in the face of simultaneous things 
> going on with the instance.
> 
>> And remove would be fairly straightforward as well since no
>> constraints would need to be checked.
> 
> Agreed.
> 
> Chris
> 
> ___
> 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] Feature freeze + Juno-3 milestone candidates available

[Joe Cropper]

Thanks, ttx.

If there’s anyone that can do a final review on 
https://review.openstack.org/#/c/118535/ — would be much appreciated and I’m 
happy to llet the i18n folks know once it merges.

- Joe

On Sep 6, 2014, at 9:36 AM, Thierry Carrez  wrote:

> In that precise case, given how early it is in the freeze, I think
> giving a quick heads-up to the -i18n team/list should be enough :) Also
> /adding/ a string is not as disruptive to their work as modifying a
> potentially-already-translated one.
> 
> Joe Cropper wrote:
>> +1 to what Jay said.
>> 
>> I’m not sure whether the string freeze applies to bugs, but the defect
>> that Matt mentioned (for which I authored the fix) adds a string, albeit
>> to fix a bug.  Hoping it’s more desirable to have an untranslated
>> correct message than a translated incorrect message.  :-)
>> 
>> - Joe
>> On Sep 5, 2014, at 3:41 PM, Jay Bryant > <mailto:jsbry...@electronicjungle.net>> wrote:
>> 
>>> Matt,
>>> 
>>> I don't think that is the right solution.
>>> 
>>> If the string changes I think the only problem is it won't be
>>> translated if it is thrown.   That is better than breaking the coding
>>> standard imho.
>>> 
>>> Jay
>>> 
>>> On Sep 5, 2014 3:30 PM, "Matt Riedemann" >> <mailto:mrie...@linux.vnet.ibm.com>> wrote:
>>> 
>>> 
>>> 
>>>On 9/5/2014 5:10 AM, Thierry Carrez wrote:
>>> 
>>>Hi everyone,
>>> 
>>>We just hit feature freeze[1], so please do not approve
>>>changes that add
>>>features or new configuration options unless those have been
>>>granted a
>>>feature freeze exception.
>>> 
>>>This is also string freeze[2], so you should avoid changing
>>>translatable
>>>strings. If you have to modify a translatable string, you
>>>should give a
>>>heads-up to the I18N team.
>>> 
>>>Finally, this is also DepFreeze[3], so you should avoid adding new
>>>dependencies (bumping oslo or openstack client libraries is OK
>>>until
>>>RC1). If you have a new dependency to add, raise a thread on
>>>openstack-dev about it.
>>> 
>>>The juno-3 development milestone was tagged, it contains more
>>>than 135
>>>features and 760 bugfixes added since the juno-2 milestone 6
>>>weeks ago
>>>(not even counting the Oslo libraries in the mix). You can
>>>find the full
>>>list of new features and fixed bugs, as well as tarball
>>>downloads, at:
>>> 
>>>https://launchpad.net/__keystone/juno/juno-3
>>><https://launchpad.net/keystone/juno/juno-3>
>>>https://launchpad.net/glance/__juno/juno-3
>>><https://launchpad.net/glance/juno/juno-3>
>>>https://launchpad.net/nova/__juno/juno-3
>>><https://launchpad.net/nova/juno/juno-3>
>>>https://launchpad.net/horizon/__juno/juno-3
>>><https://launchpad.net/horizon/juno/juno-3>
>>>https://launchpad.net/neutron/__juno/juno-3
>>><https://launchpad.net/neutron/juno/juno-3>
>>>https://launchpad.net/cinder/__juno/juno-3
>>><https://launchpad.net/cinder/juno/juno-3>
>>>https://launchpad.net/__ceilometer/juno/juno-3
>>><https://launchpad.net/ceilometer/juno/juno-3>
>>>https://launchpad.net/heat/__juno/juno-3
>>><https://launchpad.net/heat/juno/juno-3>
>>>https://launchpad.net/trove/__juno/juno-3
>>><https://launchpad.net/trove/juno/juno-3>
>>>https://launchpad.net/sahara/__juno/juno-3
>>><https://launchpad.net/sahara/juno/juno-3>
>>> 
>>>Many thanks to all the PTLs and release management liaisons
>>>who made us
>>>reach this important milestone in the Juno development cycle.
>>>Thanks in
>>>particular to John Garbutt, who keeps on doing an amazing job
>>>at the
>>>impossible task of keeping the Nova ship straight in troubled
>>>waters
>>>while we head toward the Juno release port.
>>> 
>>>Regards,
>>> 
>>>[1] https://wiki.openstack.org/__wiki/

Re: [openstack-dev] Feature freeze + Juno-3 milestone candidates available

[Joe Cropper]

+1 to what Jay said.

I’m not sure whether the string freeze applies to bugs, but the defect that 
Matt mentioned (for which I authored the fix) adds a string, albeit to fix a 
bug.  Hoping it’s more desirable to have an untranslated correct message than a 
translated incorrect message.  :-)

- Joe
On Sep 5, 2014, at 3:41 PM, Jay Bryant  wrote:

> Matt,
> 
> I don't think that is the right solution.
> 
> If the string changes I think the only problem is it won't be translated if 
> it is thrown.   That is better than breaking the coding standard imho.
> 
> Jay
> 
> On Sep 5, 2014 3:30 PM, "Matt Riedemann"  wrote:
> 
> 
> On 9/5/2014 5:10 AM, Thierry Carrez wrote:
> Hi everyone,
> 
> We just hit feature freeze[1], so please do not approve changes that add
> features or new configuration options unless those have been granted a
> feature freeze exception.
> 
> This is also string freeze[2], so you should avoid changing translatable
> strings. If you have to modify a translatable string, you should give a
> heads-up to the I18N team.
> 
> Finally, this is also DepFreeze[3], so you should avoid adding new
> dependencies (bumping oslo or openstack client libraries is OK until
> RC1). If you have a new dependency to add, raise a thread on
> openstack-dev about it.
> 
> The juno-3 development milestone was tagged, it contains more than 135
> features and 760 bugfixes added since the juno-2 milestone 6 weeks ago
> (not even counting the Oslo libraries in the mix). You can find the full
> list of new features and fixed bugs, as well as tarball downloads, at:
> 
> https://launchpad.net/keystone/juno/juno-3
> https://launchpad.net/glance/juno/juno-3
> https://launchpad.net/nova/juno/juno-3
> https://launchpad.net/horizon/juno/juno-3
> https://launchpad.net/neutron/juno/juno-3
> https://launchpad.net/cinder/juno/juno-3
> https://launchpad.net/ceilometer/juno/juno-3
> https://launchpad.net/heat/juno/juno-3
> https://launchpad.net/trove/juno/juno-3
> https://launchpad.net/sahara/juno/juno-3
> 
> Many thanks to all the PTLs and release management liaisons who made us
> reach this important milestone in the Juno development cycle. Thanks in
> particular to John Garbutt, who keeps on doing an amazing job at the
> impossible task of keeping the Nova ship straight in troubled waters
> while we head toward the Juno release port.
> 
> Regards,
> 
> [1] https://wiki.openstack.org/wiki/FeatureFreeze
> [2] https://wiki.openstack.org/wiki/StringFreeze
> [3] https://wiki.openstack.org/wiki/DepFreeze
> 
> 
> I should probably know this, but at least I'm asking first. :)
> 
> Here is an example of a new translatable user-facing error message [1].
> 
> From the StringFreeze wiki, I'm not sure if this is small or large.
> 
> Would a compromise to get this in be to drop the _() so it's just a string 
> and not a message?
> 
> Maybe I should just shut-up and email the openstack-i18n mailing list [2].
> 
> [1] https://review.openstack.org/#/c/118535/
> [2] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> ___
> 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] Call for review w.r.t. scheduler being passed requested networks

[Joe Cropper]

Hi Stackers,

I was wondering if I could get a few folks to look at
https://review.openstack.org/#/c/118010/ -- basically with the switch
to conductor having a bigger role in the deployment process (and
lessening the scheduler's role), the scheduler lost the ability to
look at the networks being requested for the initial deployment
(unless I'm missing something, which could be the case).

This patch aims to 'fix' that.  Comments are welcomed.

Thanks,
Joe

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

Re: [openstack-dev] [nova] Suggestion that Fix to logic of diskfilter

[Joe Cropper]

You're always welcome to submit a patch for a valid bug. Just put:

Closes-Bug: #

At the bottom of the commit message to link the change set to the bug.  :)

- Joe

> On Aug 25, 2014, at 9:44 PM, Jae Sang Lee  wrote:
> 
> Hi, all.
> 
> Diskfilter based on host disk usage, it check between usable host disk size 
> and requested vm disk size.
> But when create a VM with boot volume, Diskfilter has filtered a host 
> although a VM doesn't use host disk. 
> (Usually ISCSI volume could be attached)
> 
> So I have filed following defect to fix the logic that doesn't check when a 
> VM created with boot volume.
> https://bugs.launchpad.net/nova/+bug/1358566
> 
> Could anyone please let me know whether I can fix this for Juno? 
> 
> 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] [nova] Server Groups - remove VM from group?

[Joe Cropper]

> Even something like this is a lot more complicated than it sounds due to
the fact that several operations can be happening in parallel.

That's fair, but I was thinking that the 'add existing' VM is fairly
close in behavior to 'add new' VM to the group, less of course any
parallel operations happening on the VM itself.

> I think we just need to draw a line for Nova that just doesn't include this
functionality.

If that's our general direction, no problem.  I'm just thinking about
this from a user's perspective; this would be very difficult for any
administrator to use in its current form because you essentially can't
make a mistake in the group management--any mistake results in you
having to essentially delete the VM and start over, which is a pretty
major usability issue IMO, at least in terms of most production
environments.

Don't get me wrong, I think server groups have a lot of interesting
use cases (I actually would really like to use them) in their current
form and I think as a starting point, this is great.  But I think
without some of these added flexibilities, I think it would be very
challenging for any IT administrator to use them--hence why I'm
exploring adding some additional functionality; I'm even happy to help
implement this, if we can get any type of concurrence on the subject.
:-)

- Joe

On Mon, Aug 25, 2014 at 12:58 PM, Russell Bryant  wrote:
> On 08/25/2014 01:25 PM, Joe Cropper wrote:
>> I was thinking something simple such as only allowing the add operation to 
>> succeed IFF no policies are found to be in violation... and then nova 
>> wouldn't need to get into all the complexities you mention?
>
> Even something like this is a lot more complicated than it sounds due to
> the fact that several operations can be happening in parallel.  I think
> we just need to draw a line for Nova that just doesn't include this
> functionality.
>
>> And remove would be fairly straightforward as well since no constraints 
>> would need to be checked.
>
> Right, remove is straight forward, but seems a bit odd to have without
> add.  I'm not sure there's much value to it.
>
> --
> 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] Server Groups - remove VM from group?

[Joe Cropper]

I was thinking something simple such as only allowing the add operation to 
succeed IFF no policies are found to be in violation... and then nova wouldn't 
need to get into all the complexities you mention?

And remove would be fairly straightforward as well since no constraints would 
need to be checked. 

Thoughts?

Thanks,
Joe

> On Aug 25, 2014, at 12:10 PM, Russell Bryant  wrote:
> 
>> On 08/25/2014 12:56 PM, Joe Cropper wrote:
>> That was indeed a rather long (and insightful) thread on the topic.
>> It sounds like there are still some healthy discussions worth having
>> on the subject -- either exploring your [potentially superseding]
>> proposal, or minimally rounding out the existing server group API to
>> support "add existing VM" [1] and "remove VM" -- I think these would
>> make it a lot more usable (I'm thinking of the poor cloud
>> administrator that makes a mistake when they boot an instance and
>> either forgets to put it in a group or puts it in the wrong group --
>> it's square 1 for them)?
>> 
>> Is this queued up as a discussion point for Paris?  If so, count me in!
> 
> Adding a VM is far from trivial and is why we ripped it out before
> merging.  That implies a potential reshuffling of a bunch of existing
> VMs.  Consider an affinity group of instances A and B and then you add
> running instance C to that group.  What do you expect to happen?  Live
> migrate C to the host running A and B?  What if there isn't room?
> Reschedule all 3 to find a host and live migrate all of them?  This kind
> of orchestration is a good bit outside of the scope of what's done
> inside of Nova today.
> 
> -- 
> 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] Server Groups - remove VM from group?

[Joe Cropper]

That was indeed a rather long (and insightful) thread on the topic.
It sounds like there are still some healthy discussions worth having
on the subject -- either exploring your [potentially superseding]
proposal, or minimally rounding out the existing server group API to
support "add existing VM" [1] and "remove VM" -- I think these would
make it a lot more usable (I'm thinking of the poor cloud
administrator that makes a mistake when they boot an instance and
either forgets to put it in a group or puts it in the wrong group --
it's square 1 for them)?

Is this queued up as a discussion point for Paris?  If so, count me in!

Thanks,
Joe

On Mon, Aug 25, 2014 at 11:08 AM, Jay Pipes  wrote:
> On 08/25/2014 11:31 AM, Joe Cropper wrote:
>>
>> Thanks Jay.  Those are the same types of questions I was pondering as
>> well when debating how someone might use this.  I think what we have
>> is fine for a first pass, but that's what I was poking at... whether
>> some of the abilities to add/remove members dynamically could exist
>> (e.g., I no longer want this VM to have an anti-affinity policy
>> relative to the others, etc.).
>
>
> I guess what I was getting at is that I think the whole interface is flawed
> and it's not worth putting in the effort to make it slightly less flawed.
>
> Best,
> -jay
>
>
>> - Joe
>>
>> On Mon, Aug 25, 2014 at 10:16 AM, Jay Pipes  wrote:
>>>
>>> On 08/25/2014 11:10 AM, Joe Cropper wrote:
>>>>
>>>>
>>>> Hello,
>>>>
>>>> Is our long-term vision to allow a VMs to be dynamically added/removed
>>>> from a group?  That is, unless I'm overlooking something, it appears
>>>> that you can only add a VM to a server group at VM boot time and
>>>> effectively remove it by deleting the VM?
>>>>
>>>> Just curious if this was a design point, or merely an approach at a
>>>> staged implementation [that might welcome some additions]?  :)
>>>
>>>
>>>
>>> See here:
>>>
>>> http://lists.openstack.org/pipermail/openstack-dev/2014-April/033746.html
>>>
>>> If I had my druthers, I would revert the whole extension.
>>>
>>> -jay
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev 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] Server Groups - remove VM from group?

[Joe Cropper]

Thanks Jay.  Those are the same types of questions I was pondering as
well when debating how someone might use this.  I think what we have
is fine for a first pass, but that's what I was poking at... whether
some of the abilities to add/remove members dynamically could exist
(e.g., I no longer want this VM to have an anti-affinity policy
relative to the others, etc.).

- Joe

On Mon, Aug 25, 2014 at 10:16 AM, Jay Pipes  wrote:
> On 08/25/2014 11:10 AM, Joe Cropper wrote:
>>
>> Hello,
>>
>> Is our long-term vision to allow a VMs to be dynamically added/removed
>> from a group?  That is, unless I'm overlooking something, it appears
>> that you can only add a VM to a server group at VM boot time and
>> effectively remove it by deleting the VM?
>>
>> Just curious if this was a design point, or merely an approach at a
>> staged implementation [that might welcome some additions]?  :)
>
>
> See here:
>
> http://lists.openstack.org/pipermail/openstack-dev/2014-April/033746.html
>
> If I had my druthers, I would revert the whole extension.
>
> -jay
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [nova] Server Groups - remove VM from group?

[Joe Cropper]

Hello,

Is our long-term vision to allow a VMs to be dynamically added/removed
from a group?  That is, unless I'm overlooking something, it appears
that you can only add a VM to a server group at VM boot time and
effectively remove it by deleting the VM?

Just curious if this was a design point, or merely an approach at a
staged implementation [that might welcome some additions]?  :)

Thanks,
Joe

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

[openstack-dev] [nova] Server Group API: add 'action' to authorizer?

[Joe Cropper]

Hi Folks,

Would anyone be opposed to adding the 'action' checking to the v2/v3
authorizers?  This would allow administrators more fine-grained
control over  who can read vs. create/update/delete server groups.

Thoughts?

If folks are supportive, I'd be happy to add this... but not sure if
we'd treat this as a 'bug' or whether there is a blueprint under which
this could be done?

Thanks,
Joe

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

Re: [openstack-dev] [nova] Arbitrary "extra specs" for compute nodes?

[Joe Cropper]

On Mon, Jun 9, 2014 at 12:56 PM, Jay Pipes  wrote:
> On 06/09/2014 01:38 PM, Joe Cropper wrote:
>>
>> On Mon, Jun 9, 2014 at 5:17 AM, Day, Phil  wrote:
>>>
>>> Hi Joe,
>>>
>>>
>>>
>>> Can you give some examples of what that data would be used for ?
>>
>>
>> Sure!  For example, in the PowerKVM world, hosts can be dynamically
>> configured to run in split-core processor mode.  This setting can be
>> dynamically changed and it'd be nice to allow the driver to track this
>> somehow -- and it probably doesn't warrant its own explicit field in
>> compute_node.  Likewise, PowerKVM also has a concept of the maximum
>> SMT level in which its guests can run (which can also vary dynamically
>> based on the split-core setting) and it would also be nice to tie such
>> settings to the compute node.
>
>
> That information is typically stored in the compute_node.cpu_info field.
>
>
>> Overall, this would give folks writing compute drivers the ability to
>> attach the "extra spec" style data to a compute node for a variety of
>> purposes -- two simple examples provided above, but there are many
>> more.  :-)
>
>
> If it's something that the driver can discover on its own and that the
> driver can/should use in determining the capabilities that the hypervisor
> offers, then at this point, I believe compute_node.cpu_info is the place to
> put that information. It's probably worth renaming the cpu_info field to
> just "capabilities" instead, to be more generic and indicate that it's a
> place the driver stores discoverable capability information about the
> node...

Thanks, that's a great point!  While that's fair for those items that
are self-discoverable for the driver that also are cpu_info'ish in
nature, there are also some additional use cases I should mention.
Imagine some higher level projects [above nova] want to associate
arbitrary bits of information with the compute host for
project-specific uses.  For example, suppose I have an orchestration
project that does coordinated live migrations and I want to put some
specific restrictions on the # of concurrent migrations that should
occur for the respective compute node (and let the end-user adjust
these values).  Having it directly associated with the compute node in
nova gives us some nice ways to keep data consistency.  I think this
would be a great way to gain some additional parity with some of the
other nova structures such as flavors' extra_specs and instances'
metadata/system_metadata.

Thanks,
Joe

>
> Now, for *user-defined* taxonomies, I'm a big fan of simple string tagging,
> as is proposed for the server instance model in this spec:
>
> https://review.openstack.org/#/c/91444/
>
> Best,
> jay
>
>
>>>
>>>
>>>
>>> It sounds on the face of it that what you’re looking for is pretty
>>> similar
>>> to what Extensible Resource Tracker sets out to do
>>> (https://review.openstack.org/#/c/86050
>>> https://review.openstack.org/#/c/71557)
>>
>>
>> Thanks for pointing this out.  I actually ran across these while I was
>> searching the code to see what might already exist in this space.
>> Actually, the compute node 'stats' was always a first guess, but these
>> are clearly heavily reserved for the resource tracker and wind up
>> getting purged/deleted over time since the 'extra specs' I reference
>> above aren't necessarily tied to the spawning/deleting of instances.
>> In other words, they're not really consumable resources, per-se.
>> Unless I'm overlooking a way (perhaps I am) to use this
>> extensible-resource-tracker blueprint for arbitrary key-value pairs
>> **not** related to instances, I think we need something additional?
>>
>> I'd happily create a new blueprint for this as well.
>>
>>>
>>>
>>>
>>> Phil
>>>
>>>
>>>
>>> From: Joe Cropper [mailto:cropper@gmail.com]
>>> Sent: 07 June 2014 07:30
>>> To: openstack-dev@lists.openstack.org
>>> Subject: [openstack-dev] Arbitrary "extra specs" for compute nodes?
>>>
>>>
>>>
>>> Hi Folks,
>>>
>>> I was wondering if there was any such mechanism in the compute node
>>> structure to hold arbitrary key-value pairs, similar to flavors'
>>> "extra_specs" concept?
>>>
>>> It appears there are entries for things like pci_stats, stats and
>>> recently
>>> added extra_resources -- but these all tend to ha

Re: [openstack-dev] [nova] Arbitrary "extra specs" for compute nodes?

[Joe Cropper]

On Mon, Jun 9, 2014 at 5:17 AM, Day, Phil  wrote:
> Hi Joe,
>
>
>
> Can you give some examples of what that data would be used for ?

Sure!  For example, in the PowerKVM world, hosts can be dynamically
configured to run in split-core processor mode.  This setting can be
dynamically changed and it'd be nice to allow the driver to track this
somehow -- and it probably doesn't warrant its own explicit field in
compute_node.  Likewise, PowerKVM also has a concept of the maximum
SMT level in which its guests can run (which can also vary dynamically
based on the split-core setting) and it would also be nice to tie such
settings to the compute node.

Overall, this would give folks writing compute drivers the ability to
attach the "extra spec" style data to a compute node for a variety of
purposes -- two simple examples provided above, but there are many
more.  :-)

>
>
>
> It sounds on the face of it that what you’re looking for is pretty similar
> to what Extensible Resource Tracker sets out to do
> (https://review.openstack.org/#/c/86050
> https://review.openstack.org/#/c/71557)

Thanks for pointing this out.  I actually ran across these while I was
searching the code to see what might already exist in this space.
Actually, the compute node 'stats' was always a first guess, but these
are clearly heavily reserved for the resource tracker and wind up
getting purged/deleted over time since the 'extra specs' I reference
above aren't necessarily tied to the spawning/deleting of instances.
In other words, they're not really consumable resources, per-se.
Unless I'm overlooking a way (perhaps I am) to use this
extensible-resource-tracker blueprint for arbitrary key-value pairs
**not** related to instances, I think we need something additional?

I'd happily create a new blueprint for this as well.

>
>
>
> Phil
>
>
>
> From: Joe Cropper [mailto:cropper@gmail.com]
> Sent: 07 June 2014 07:30
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] Arbitrary "extra specs" for compute nodes?
>
>
>
> Hi Folks,
>
> I was wondering if there was any such mechanism in the compute node
> structure to hold arbitrary key-value pairs, similar to flavors'
> "extra_specs" concept?
>
> It appears there are entries for things like pci_stats, stats and recently
> added extra_resources -- but these all tend to have more specific usages vs.
> just arbitrary data that may want to be maintained about the compute node
> over the course of its lifetime.
>
> Unless I'm overlooking an existing construct for this, would this be
> something that folks would welcome a Juno blueprint for--i.e., adding
> extra_specs style column with a JSON-formatted string that could be loaded
> as a dict of key-value pairs?
>
> Thoughts?
>
> Thanks,
>
> Joe
>
>
> ___
> 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] Arbitrary "extra specs" for compute nodes?

[Joe Cropper]

On Mon, Jun 9, 2014 at 10:07 AM, Chris Friesen
 wrote:
> On 06/07/2014 12:30 AM, Joe Cropper wrote:
>>
>> Hi Folks,
>>
>> I was wondering if there was any such mechanism in the compute node
>> structure to hold arbitrary key-value pairs, similar to flavors'
>> "extra_specs" concept?
>>
>> It appears there are entries for things like pci_stats, stats and
>> recently added extra_resources -- but these all tend to have more
>> specific usages vs. just arbitrary data that may want to be maintained
>> about the compute node over the course of its lifetime.
>>
>> Unless I'm overlooking an existing construct for this, would this be
>> something that folks would welcome a Juno blueprint for--i.e., adding
>> extra_specs style column with a JSON-formatted string that could be
>> loaded as a dict of key-value pairs?
>
>
> If nothing else, you could put the compute node in a host aggregate and
> assign metadata to it.

Yeah, I recognize this could be done, but I think that would be using
the host aggregate metadata a little too loosely since the metadata
I'm after is really tied explicitly to the compute node.  This would
present too many challenges when someone would want to use host
aggregates and the compute node-specific metadata.

>
> Chris
>
> ___
> 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] Proposal: Move CPU and memory allocation ratio out of scheduler

[Joe Cropper]

There may also be specific software entitlement issues that make it useful
to deterministically know which host your VM will be placed on.  This can
be quite common in large organizations that have certain software that can
be tied to certain hardware or hardware with certain # of CPU capacity, etc.

Regards,
Joe


On Mon, Jun 9, 2014 at 11:32 AM, Chris Friesen 
wrote:

> On 06/09/2014 07:59 AM, Jay Pipes wrote:
>
>> On 06/06/2014 08:07 AM, Murray, Paul (HP Cloud) wrote:
>>
>>> Forcing an instance to a specific host is very useful for the
>>> operator - it fulfills a valid use case for monitoring and testing
>>> purposes.
>>>
>>
>> Pray tell, what is that valid use case?
>>
>
> I find it useful for setting up specific testcases when trying to validate
> thingsput *this* instance on *this* host, put *those* instances on
> *those* hosts, now pull the power plug on *this* host...etc.
>
> I wouldn't expect the typical openstack end-user to need it though.
>
> Chris
>
> ___
> 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] Arbitrary "extra specs" for compute nodes?

[Joe Cropper]

Hi Folks,

I was wondering if there was any such mechanism in the compute node
structure to hold arbitrary key-value pairs, similar to flavors'
"extra_specs" concept?

It appears there are entries for things like pci_stats, stats and recently
added extra_resources -- but these all tend to have more specific usages
vs. just arbitrary data that may want to be maintained about the compute
node over the course of its lifetime.

Unless I'm overlooking an existing construct for this, would this be
something that folks would welcome a Juno blueprint for--i.e., adding
extra_specs style column with a JSON-formatted string that could be loaded
as a dict of key-value pairs?

Thoughts?

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