[Openstack-operators] [tc][qa][all]Potential New Interoperability Programs: The Current Thinking

[Mark Voelker]

Hi Everyone,

Happy Friday!  There have been a number of discussions (at the PTG, at 
OpenStack Summit, in Interop WG and Board of Directors meetings, etc) over the 
past several months about the possibility of creating new interoperability 
programs in addition to the existing OpenStack Powered program administered by 
the Interop Working Group (formerly the DefCore Committee).  In particular, 
lately there have been a lot of discussions recently [1] about where to put 
tests associated with trademark programs with respect to some existing TC 
guidance [2] and community goals for Queens [3].  Although these potential new 
programs have been discussed in a number of places, it’s a little hard to keep 
tabs on where we’re at with them unless you’re actively following the Interop 
WG.  Given the recent discussions on openstack-dev, I thought it might be 
useful to try and brain dump our current thinking on what these new programs 
might look like into a document somewhere that people could point at in 
discussions rather than discussing abstracts and working off memories from 
prior meetings.  To that end, I took a first stab at it this week which you can 
find here:

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

Needless to say this is just a draft to try to get some of the ideas out of 
neurons and on to electrons, so please don’t take it to be firm 
consensus—rather consider it a draft of what we’re currently thinking and an 
invitation to collaborate.  I expect that other members of the Interop Working 
Group will be leaving comments in Gerrit as we hash through this, and we’d love 
to have input from other folks in the community as well.  These programs 
potentially touch a lot of you (in fact, almost all of you) in some way or 
another, so we’re happy to hear your input as we work on evolving the interop 
programs.  Quite a lot has happened over the past couple of years, so we hope 
this will help folks understand where we came from and think about whether we 
want to make changes going forward.  

By the way, for those of you who might find an HTML-rendered document easier to 
read, click on the "gate-interop-docs-ubuntu-xenial” link in the comments left 
by Jenkins and then on “Extension Programs - Current Direction”.  Thanks, and 
have a great weekend!

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#117657
[2] 
https://governance.openstack.org/tc/resolutions/20160504-defcore-test-location.html
[3] https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html

At Your Service,

Mark T. Voelker
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [keystone][defcore][refstack] Removal of the v2.0 API

[Mark Voelker]

> On Mar 1, 2017, at 6:01 PM, Rodrigo Duarte  wrote:
> 
> On Wed, Mar 1, 2017 at 7:10 PM, Lance Bragstad  wrote:
> During the PTG, Morgan mentioned that there was the possibility of keystone 
> removing the v2.0 API [0]. This thread is a follow up from that discussion to 
> make sure we loop in the right people and do everything by the books.
> 
> The result of the session [1] listed the following work items: 
> - Figure out how we can test the removal and make the job voting (does the 
> v3-only job count for this)?
> 
> We have two v3-only jobs, one only runs keystone's tempest plugin tests - 
> which are specific to federation (it configures a federated environment using 
> mod_shib) - and another one (non-voting) that runs tempest, I believe the 
> later can be a good way to initially validate the v2.0 removal.
>  
> - Reach out to defcore and refstack communities about removing v2.0 (which is 
> partially what this thread is doing)

Yup, we actually talked a bit about this in the past couple of weeks.  I’ve 
CC'd Luz who is playing point on capabilities scoring for the 2017.08 Guideline 
for Identity to make extra sure she’s aware. =)

At Your Service,

Mark T. Voelker
InteropWG Co-chair

> 
> Outside of this thread, what else do we have to do from a defcore perspective 
> to make this happen?
> 
> Thanks for the time!
> 
> [0] https://review.openstack.org/#/c/437667/
> [1] https://etherpad.openstack.org/p/pike-ptg-keystone-deprecations
> 
> __
> 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
> 
> 
> 
> 
> -- 
> Rodrigo Duarte Sousa
> Senior Quality Engineer @ Red Hat
> MSc in Computer Science
> http://rodrigods.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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Next Ops Midcycle NYC August 25-26

[Mark Voelker]

Hi Folks,

A quick update on this: today’s the last day of earlybird pricing for OpenStack 
East, so if you’d like to attend both events I’d encourage you to register now 
(it’s only $99 for the next ~7 hours):

https://www.eventbrite.com/e/openstack-east-tickets-22413148330?ref=ebtnebregn

If you can’t register today, some good news: I spoke with the conference 
organizers and it looks like we’ll be able to get some sort of discount code 
for folks who are attending the Ops Midcycle and also want to attend OpenStack 
East!  We’re still working out logistics, so bear with me—I’ll send along some 
more info when I have it.

At Your Service,

Mark T. Voelker



> On Jun 22, 2016, at 2:16 PM, Mark Voelker <mvoel...@vmware.com> wrote:
> 
> It would definitely be cool to have more ops folks attend both events.  I’d 
> be happy to check in with the rest of the organizers and see if there’s a 
> possibility of working something out.
> 
> At Your Service,
> 
> Mark T. Voelker
> 
> 
> 
>> On Jun 22, 2016, at 12:27 PM, David Medberry <openst...@medberry.net> wrote:
>> 
>> Would be sweet if that offer could be extended at least a week as we go 
>> through the corp travel process. OTOH, $99 is almost cheap enough to buy and 
>> not care I'll be doing that I guess.
>> 
>> On Wed, Jun 22, 2016 at 9:44 AM, Matt Jarvis <matt.jar...@datacentred.co.uk> 
>> wrote:
>> Hi Mark
>> 
>> Given we've not got the Eventbrite for the Ops Meetup live yet, is there any 
>> chance you could extend the early bird pricing or give operators who may be 
>> travelling for the Ops Meetup a discount code ? I suspect there may be quite 
>> a lot of interest for those travelling some distance. 
>> 
>> Matt
>> 
>> On 22 June 2016 at 14:58, Mark Voelker <mvoel...@vmware.com> wrote:
>> Hi Ops,
>> 
>> FYI for those that may not be aware, that’s also the week of OpenStack East. 
>>  OpenStack East runs August 23-24 also in New York City (about ~15-20 
>> minutes away from Civic Hall by MTA at the Playstation Theater).  If you’re 
>> coming to town for the Ops Midcycle, you may want to make a week of it.  
>> Earlybird pricing for OpenStack East is still available but prices increase 
>> tomorrow:
>> 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openstackeast.com_=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc=Pouk4RdhAp3O0-4z088jjeJcdTHWxG2QEHGPaCapbAg=pst_dGQnf8jOAggeotgW1NJGzEAbCpWryQ7tNon78IM=
>>  
>> 
>> At Your Service,
>> 
>> Mark T. Voelker
>> (wearer of many hats, one of which is OpenStack East steering committee 
>> member)
>> 
>> 
>> 
>>> On Jun 21, 2016, at 11:36 AM, Jonathan D. Proulx <j...@csail.mit.edu> wrote:
>>> 
>>> Hi All,
>>> 
>>> The Ops Meetups Team has selected[1] New York City as the location of the
>>> next mid-cycle meetup on August 25 and 26 2016 at Civic Hall[2]
>>> 
>>> Many thanks to Bloomberg for sponsoring the location.  And thanks to
>>> BestBuy as well for their offer of the Seattle location.  The choice
>>> was very close and hopefully their offer will stand for our next North
>>> American meet-up.
>>> 
>>> There's quite a bit of work to do to make this all happen in the
>>> next couple of months so it's still a great time to join the Ops
>>> Meetups Team[3] and help out.
>>> 
>>> -Jon
>>> 
>>> --
>>> 
>>> [1] 
>>> http://eavesdrop.openstack.org/meetings/ops_meetups_team/2016/ops_meetups_team.2016-06-21-14.02.html
>>> [2] 
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__civichall.org_about-2Dcivic-2Dhall_=CwICAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc=oAH-SSZ6EFikpmcyUpbf3984kyPBIuLJKkQadC6CKUw=36Kl-0b4WBC06xaYXo0V5AM2lHzvjhL48bBV48cz2is=
>>> [3] https://wiki.openstack.org/wiki/Ops_Meetups_Team
>>> 
>>> 
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
>> 
>> DataCentred Limited registered in England and Wales no. 05611763
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
>> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

Re: [Openstack-operators] Next Ops Midcycle NYC August 25-26

[Mark Voelker]

It would definitely be cool to have more ops folks attend both events.  I’d be 
happy to check in with the rest of the organizers and see if there’s a 
possibility of working something out.

At Your Service,

Mark T. Voelker



> On Jun 22, 2016, at 12:27 PM, David Medberry <openst...@medberry.net> wrote:
> 
> Would be sweet if that offer could be extended at least a week as we go 
> through the corp travel process. OTOH, $99 is almost cheap enough to buy and 
> not care I'll be doing that I guess.
> 
> On Wed, Jun 22, 2016 at 9:44 AM, Matt Jarvis <matt.jar...@datacentred.co.uk> 
> wrote:
> Hi Mark
> 
> Given we've not got the Eventbrite for the Ops Meetup live yet, is there any 
> chance you could extend the early bird pricing or give operators who may be 
> travelling for the Ops Meetup a discount code ? I suspect there may be quite 
> a lot of interest for those travelling some distance. 
> 
> Matt
> 
> On 22 June 2016 at 14:58, Mark Voelker <mvoel...@vmware.com> wrote:
> Hi Ops,
> 
> FYI for those that may not be aware, that’s also the week of OpenStack East.  
> OpenStack East runs August 23-24 also in New York City (about ~15-20 minutes 
> away from Civic Hall by MTA at the Playstation Theater).  If you’re coming to 
> town for the Ops Midcycle, you may want to make a week of it.  Earlybird 
> pricing for OpenStack East is still available but prices increase tomorrow:
> 
> http://www.openstackeast.com/
> 
> At Your Service,
> 
> Mark T. Voelker
> (wearer of many hats, one of which is OpenStack East steering committee 
> member)
> 
> 
> 
> > On Jun 21, 2016, at 11:36 AM, Jonathan D. Proulx <j...@csail.mit.edu> wrote:
> >
> > Hi All,
> >
> > The Ops Meetups Team has selected[1] New York City as the location of the
> > next mid-cycle meetup on August 25 and 26 2016 at Civic Hall[2]
> >
> > Many thanks to Bloomberg for sponsoring the location.  And thanks to
> > BestBuy as well for their offer of the Seattle location.  The choice
> > was very close and hopefully their offer will stand for our next North
> > American meet-up.
> >
> > There's quite a bit of work to do to make this all happen in the
> > next couple of months so it's still a great time to join the Ops
> > Meetups Team[3] and help out.
> >
> > -Jon
> >
> > --
> >
> > [1] 
> > http://eavesdrop.openstack.org/meetings/ops_meetups_team/2016/ops_meetups_team.2016-06-21-14.02.html
> > [2] 
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__civichall.org_about-2Dcivic-2Dhall_=CwICAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Q8IhPU-EIzbG5YDx5LYO7zEJpGZykn7RwFg-UTPWvDc=oAH-SSZ6EFikpmcyUpbf3984kyPBIuLJKkQadC6CKUw=36Kl-0b4WBC06xaYXo0V5AM2lHzvjhL48bBV48cz2is=
> > [3] https://wiki.openstack.org/wiki/Ops_Meetups_Team
> >
> >
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> 
> DataCentred Limited registered in England and Wales no. 05611763
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> 

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

Re: [Openstack-operators] vmware nsx 6

[Mark Voelker]

> On Feb 18, 2016, at 3:08 AM, Ignazio Cassano <ignaziocass...@gmail.com> wrote:
> 
> Hi Mark, I forgot another question for you: do you know when nsx with mh 
> support will be released ? 

I’m afraid I’m absolutely terrible with public release dates—I’d suggest a 
quick chat with your account rep instead. =)

> Regards
> Ignazio
> 
> Il 18/Feb/2016 08:28 AM, "Ignazio Cassano" <ignaziocass...@gmail.com> ha 
> scritto:
> >
> > Many thanks, Mark.
> > We are going to test this solution following your instructions and if we 
> > find problems some problems we will contact you.

Sure thing, glad to be of assistance!

At Your Service,

Mark T. Voelker


> > Regards
> > Ignazio
> >
> > 2016-02-17 20:45 GMT+01:00 Mark Voelker <mvoel...@vmware.com>:
> >>
> >> Hi Ignazio,
> >>
> >> Sure, NSXv 6.2.1 is usable for a VMware region [1].  Source for the driver 
> >> is here [2]:
> >>
> >> http://git.openstack.org/cgit/openstack/vmware-nsx/tree/?h=stable/liberty
> >>
> >> The blogs I pointed to earlier should give you a good feel for the basic 
> >> architecture and services.  Configuration-wise, you’ll want to set 
> >> “core_plugin" to “vmware_nsx.neutron.plugins.vmware.plugin.NsxVPlugin” and 
> >> “service_plugins” should include 
> >> “neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPlugin,vmware_nsx.neutron.services.l2gateway.plugin.NSxL2GatewayPlugin”.
> >>  in your neutron.conf file and then configure the plugin options.  Most of 
> >> what you’ll need is found here:
> >>
> >> http://git.openstack.org/cgit/openstack/vmware-nsx/tree/etc/nsx.ini?h=stable/liberty
> >>
> >> You’ll want to set “nsx_l2gw_driver" to 
> >> "vmware_nsx.neutron.services.l2gateway/nsx_v_driver.NsxvL2GatewayDriver" 
> >> in line 49 since you’re using NSXv.  Then fill in the NSXv plugin 
> >> configuration options in the [nsxv] section in lines 61-181, and you may 
> >> optionally want to tinker with the [nsx_sync] section in lines 239-276. 
> >> You can ignore most of the rest as it mostly pertains to the NSX-mh and 
> >> DVS plugins.  If it’s useful I can send you some sample configs from one 
> >> of my lab setups; just let me know!
> >>
> >> [1] For a bit more info on the various plugins available for NSX-mh, NSXv, 
> >> and DVS see https://wiki.openstack.org/wiki/Neutron/VMware_NSX_plugins
> >>
> >> [2] More specifically for you since you’re using NSXv, the NSXv plugin 
> >> code is in: 
> >> http://git.openstack.org/cgit/openstack/vmware-nsx/tree/vmware_nsx/plugins/nsx_v?h=stable/liberty
> >>
> >> At Your Service,
> >>
> >> Mark T. Voelker
> >>
> >>
> >>
> >> > On Feb 17, 2016, at 10:30 AM, Ignazio Cassano <ignaziocass...@gmail.com> 
> >> > wrote:
> >> >
> >> > Hi Mark, many thanks for your help.
> >> > We are not using vmware VIO, but we are using openstack liberty 
> >> > community edition with a Region for vmware nsx.
> >> > If you read the following link:
> >> >
> >> > http://docs.openstack.org/admin-guide-cloud/networking_config-agents.html
> >> >
> >> > you can see the following instructions:
> >> >   • Use the NSX Administrator Guide to add the node as a Hypervisor 
> >> > by using the NSX Manager GUI. Even if your forwarding node has no VMs 
> >> > and is only used for services agents like neutron-dhcp-agent or 
> >> > neutron-lbaas-agent, it should still be added to NSX as a Hypervisor.
> >> > On  nsx 6.2.1 GUI there isn't any section to add the node as a 
> >> > Hypervisor, probably because this document is related to a NSX multi 
> >> > hypervisor version.
> >> >
> >> > So the question is: must we wait for a new nsx multi hypervisor version 
> >> > or we can use the current nsx version ?
> >> >
> >> > Best Regards
> >> >
> >> > Ignazio
> >> >
> >> >
> >> >
> >> >
> >> > 2016-02-17 14:51 GMT+01:00 Mark Voelker <mvoel...@vmware.com>:
> >> > Hi Ignazio,
> >> >
> >> > I have. =)  Drop me a note and let me know what you need; we’ll be happy 
> >> > to help.  For a general background, this is a good place to start:
> >> >
> >> > http://blogs.vmware.com/openstack/openstack-networking-with-vmware-nsx-part-1/
>

Re: [Openstack-operators] vmware nsx 6

[Mark Voelker]

Hi Ignazio,

I have. =)  Drop me a note and let me know what you need; we’ll be happy to 
help.  For a general background, this is a good place to start:

http://blogs.vmware.com/openstack/openstack-networking-with-vmware-nsx-part-1/

http://blogs.vmware.com/openstack/openstack-networking-with-vmware-nsx-part-2/

http://blogs.vmware.com/openstack/openstack-networking-with-vmware-nsx-part-3/

There’s also useful information in the config guides:

http://docs.openstack.org/kilo/config-reference/content/networking-plugin-nsx.html

At Your Service,

Mark T. Voelker



> On Feb 17, 2016, at 2:43 AM, Ignazio Cassano  wrote:
> 
> Hi all,
> I would like to know if someone have configured openstack neutron with vmware
> nsx 6. I found old documentation about it.
> Regards
> Ignazio
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

Re: [Openstack-operators] [openstack-dev] [cinder] [all] The future of Cinder API v1

[Mark Voelker]

Mark T. Voelker



> On Sep 29, 2015, at 12:36 PM, Matt Fischer  wrote:
> 
> 
> 
> I agree with John Griffith. I don't have any empirical evidences to back
> my "feelings" on that one but it's true that we weren't enable to enable
> Cinder v2 until now.
> 
> Which makes me wonder: When can we actually deprecate an API version? I
> *feel* we are fast to jump on the deprecation when the replacement isn't
> 100% ready yet for several versions.
> 
> --
> Mathieu
> 
> 
> I don't think it's too much to ask that versions can't be deprecated until 
> the new version is 100% working, passing all tests, and the clients (at least 
> python-xxxclients) can handle it without issues. Ideally I'd like to also 
> throw in the criteria that devstack, rally, tempest, and other services are 
> all using and exercising the new API.
> 
> I agree that things feel rushed.


FWIW, the TC recently created an assert:follows-standard-deprecation tag.  Ivan 
linked to a thread in which Thierry asked for input on it, but FYI the final 
language as it was approved last week [1] is a bit different than originally 
proposed.  It now requires one release plus 3 linear months of 
deprecated-but-still-present-in-the-tree as a minimum, and recommends at least 
two full stable releases for significant features (an entire API version would 
undoubtedly fall into that bucket).  It also requires that a migration path 
will be documented.  However to Matt’s point, it doesn’t contain any language 
that says specific things like:

In the case of major API version deprecation:
* $oldversion and $newversion must both work with [cinder|nova|whatever]client 
and openstackclient during the deprecation period.
* It must be possible to run $oldversion and $newversion concurrently on the 
servers to ensure end users don’t have to switch overnight. 
* Devstack uses $newversion by default.
* $newversion works in Tempest/Rally/whatever else.

What it *does* do is require that a thread be started here on 
openstack-operators [2] so that operators can provide feedback.  I would hope 
that feedback like “I can’t get clients to use it so please don’t remove it 
yet” would be taken into account by projects, which seems to be exactly what’s 
happening in this case with Cinder v1.  =)

I’d hazard a guess that the TC would be interested in hearing about whether you 
think that plan is a reasonable one (and given that TC election season is upon 
us, candidates for the TC probably would too).

[1] https://review.openstack.org/#/c/207467/
[2] 
http://git.openstack.org/cgit/openstack/governance/tree/reference/tags/assert_follows-standard-deprecation.rst#n59

At Your Service,

Mark T. Voelker


>  
> 
> __
> 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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [cinder] [all] The future of Cinder API v1

[Mark Voelker]

FWIW, the most popular client libraries in the last user survey[1] other than 
OpenStack’s own clients were: libcloud (48 respondents), jClouds (36 
respondents), Fog (34 respondents), php-opencloud (21 respondents), DeltaCloud 
(which has been retired by Apache and hasn’t seen a commit in two years, but 17 
respondents are still using it), pkgcloud (15 respondents), and OpenStack.NET 
(14 respondents).  Of those:

* libcloud appears to support the nova-volume API but not the cinder API: 
https://github.com/apache/libcloud/blob/trunk/libcloud/compute/drivers/openstack.py#L251

* jClouds appears to support only the v1 API: 
https://github.com/jclouds/jclouds/tree/jclouds-1.9.1/apis/openstack-cinder/src/main/java/org/jclouds

* Fog also appears to only support the v1 API: 
https://github.com/fog/fog/blob/master/lib/fog/openstack/volume.rb#L99

* php-opencloud appears to only support the v1 API: 
https://php-opencloud.readthedocs.org/en/latest/services/volume/index.html

* DeltaCloud I honestly haven’t looked at since it’s thoroughly dead, but I 
can’t imagine it supports v2.

* pkgcloud has beta-level support for Cinder but I think it’s v1 (may be 
mistaken): https://github.com/pkgcloud/pkgcloud/#block-storagebeta and 
https://github.com/pkgcloud/pkgcloud/tree/master/lib/pkgcloud/openstack/blockstorage

* OpenStack.NET does appear to support v2: 
http://www.openstacknetsdk.org/docs/html/T_net_openstack_Core_Providers_IBlockStorageProvider.htm

Now, it’s anyone’s guess as to whether or not users of those client libraries 
actually try to use them for volume operations or not (anecdotally I know a few 
clouds I help support are using client libraries that only support v1), and 
some users might well be using more than one library or mixing in code they 
wrote themselves.  But most of the above that support cinder do seem to rely on 
v1.  Some management tools also appear to still rely on the v1 API (such as 
RightScale: 
http://docs.rightscale.com/clouds/openstack/openstack_config_prereqs.html ).  
From that perspective it might be useful to keep it around a while longer and 
disable it by default.  Personally I’d probably lean that way, especially given 
that folks here on the ops list are still reporting problems too.

That said, v1 has been deprecated since Juno, and the Juno release notes said 
it was going to be removed [2], so there’s a case to be made that there’s been 
plenty of fair warning too I suppose.

[1] 
http://superuser.openstack.org/articles/openstack-application-developers-share-insights
[2] https://wiki.openstack.org/wiki/ReleaseNotes/Juno#Upgrade_Notes_7

At Your Service,

Mark T. Voelker



> On Sep 28, 2015, at 7:17 PM, Sam Morrison  wrote:
> 
> Yeah we’re still using v1 as the clients that are packaged with most distros 
> don’t support v2 easily.
> 
> Eg. with Ubuntu Trusty they have version 1.1.1, I just updated our “volume” 
> endpoint to point to v2 (we have a volumev2 endpoint too) and the client 
> breaks.
> 
> $ cinder list
> ERROR: OpenStack Block Storage API version is set to 1 but you are accessing 
> a 2 endpoint. Change its value through --os-volume-api-version or 
> env[OS_VOLUME_API_VERSION].
> 
> Sam
> 
> 
>> On 29 Sep 2015, at 8:34 am, Matt Fischer  wrote:
>> 
>> Yes, people are probably still using it. Last time I tried to use V2 it 
>> didn't work because the clients were broken, and then it went back on the 
>> bottom of my to do list. Is this mess fixed?
>> 
>> http://lists.openstack.org/pipermail/openstack-operators/2015-February/006366.html
>> 
>> On Mon, Sep 28, 2015 at 4:25 PM, Ivan Kolodyazhny  wrote:
>> Hi all,
>> 
>> As you may know, we've got 2 APIs in Cinder: v1 and v2. Cinder v2 API was 
>> introduced in Grizzly and v1 API is deprecated since Juno.
>> 
>> After [1] is merged, Cinder API v1 is disabled in gates by default. We've 
>> got a filed bug [2] to remove Cinder v1 API at all.
>> 
>> 
>> According to Deprecation Policy [3] looks like we are OK to remote it. But I 
>> would like to ask Cinder API users if any still use API v1.
>> Should we remove it at all Mitaka release or just disable by default in the 
>> cinder.conf?
>> 
>> AFAIR, only Rally doesn't support API v2 now and I'm going to implement it 
>> asap.
>> 
>> [1] https://review.openstack.org/194726 
>> [2] https://bugs.launchpad.net/cinder/+bug/1467589
>> [3] 
>> http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html
>> 
>> Regards,
>> Ivan Kolodyazhny
>> 
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
>> 
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> 

Re: [Openstack-operators] nova-neutron with vsphere

[Mark Voelker]

Miko,

There’s a VDS driver for Neutron in addition to the NSX one that you might want 
to have a look at if you haven’t already.  Some notes on that here (these are 
from the admin guides for the VMware Integrated OpenStack distribution as it 
does a pretty good job of describing the requirements, architecture, and 
limitations of the VDS driver, but the driver itself is open source and can be 
used by anyone):

http://pubs.vmware.com/integrated-openstack-2/index.jsp#com.vmware.openstack.install.doc/GUID-98D92A0C-E568-4380-A9AA-7AE9A59E360E.html

VDS obviously won’t work for the KVM compute hosts though.  A fairly 
widely-used tactic if you don’t want to use an SDN or overlay based solution 
for spanning multiple hypervisors is to separate the hypervisor hosts into 
separate regions (which have distinct API endpoints and can therefore have 
services configured completely differently if you so desire).  If you’re not 
familiar with the concept of regions, have a look here:

http://docs.openstack.org/openstack-ops/content/scaling.html

Note that if you go that route users need to target one region or the other 
when making API calls since they are distinct API endpoints.  

At Your Service,

Mark T. Voelker



> On Sep 24, 2015, at 5:01 AM, Miko Bello  wrote:
> 
> Hi Folks,
> i would like to know if anybody has tried to implement a neutron solution 
> with vsphere without using NSX-like solutions.
> I mean, my lab environment is composed of :
> 
>  - 1 network node ( neutron )
>  - 1 controller node
>  - 2 compute node ( kvm)
>  - 1 compute node linked to a cluster vsphere 6.0
>  
> i tried, without success ;( to deploy an instance on vsphere node with a 
> network configuration of type VLAN; ( obviously, in this configuration,i have 
> not the ambition of a ovs solution type :)  )
> so my questions are: it's' possible to implement a network neutron solution 
> of type VLAN ? if yes how can i do?
> Thanks in advantage.
> Miko Bello
> 
>  
> 
> 
> 
> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

Re: [Openstack-operators] nova-neutron with vsphere

[Mark Voelker]

Yes: as the document there notes, the VDS driver uses provider networks (which 
in Neutron are created by the admin rather than the tenant and basically map 
neutron networks to VLANs in the physical datacenter network) and therefore 
punt L3 operations to the datacenter network.

At Your Service,

Mark T. Voelker



> On Sep 24, 2015, at 12:14 PM, Federico Michele Facca 
> <federico.fa...@create-net.org> wrote:
> 
> As early mentioned this week, Mark's option is a valid alternative (separate 
> regions). @ Mark, I wonder if this excpert from your pointer is still valid:
> 
> "VDS-based networking has limitations, including the inability of tenants to 
> create their own private L2 networks, and the inability to deliver L3 and 
> higher networking services such as virtual routers, security groups, and 
> floating IPs. 
> If such features are important for your VMware Integrated OpenStack 
> deployment, consider using NSX-V for Neutron networking."
> 
> In case I think people should be aware of this before going for this option.
> 
> Br,
> Federico
> 
> --
> Future Internet is closer than you think!
> http://www.fiware.org
> 
> Official Mirantis partner for OpenStack Training
> https://www.create-net.org/community/openstack-training
> 
> -- 
> Dr. Federico M. Facca
> 
> CREATE-NET
> Via alla Cascata 56/D
> 38123 Povo Trento (Italy)
> 
> P  +39 0461 312471
> M +39 334 6049758
> E  federico.fa...@create-net.org
> T @chicco785
> W  www.create-net.org
> 
> On Thu, Sep 24, 2015 at 5:58 PM, Mark Voelker <mvoel...@vmware.com> wrote:
> Miko,
> 
> There’s a VDS driver for Neutron in addition to the NSX one that you might 
> want to have a look at if you haven’t already.  Some notes on that here 
> (these are from the admin guides for the VMware Integrated OpenStack 
> distribution as it does a pretty good job of describing the requirements, 
> architecture, and limitations of the VDS driver, but the driver itself is 
> open source and can be used by anyone):
> 
> http://pubs.vmware.com/integrated-openstack-2/index.jsp#com.vmware.openstack.install.doc/GUID-98D92A0C-E568-4380-A9AA-7AE9A59E360E.html
> 
> VDS obviously won’t work for the KVM compute hosts though.  A fairly 
> widely-used tactic if you don’t want to use an SDN or overlay based solution 
> for spanning multiple hypervisors is to separate the hypervisor hosts into 
> separate regions (which have distinct API endpoints and can therefore have 
> services configured completely differently if you so desire).  If you’re not 
> familiar with the concept of regions, have a look here:
> 
> http://docs.openstack.org/openstack-ops/content/scaling.html
> 
> Note that if you go that route users need to target one region or the other 
> when making API calls since they are distinct API endpoints.
> 
> At Your Service,
> 
> Mark T. Voelker
> 
> 
> 
> > On Sep 24, 2015, at 5:01 AM, Miko Bello <openst...@mikebeauty.com> wrote:
> >
> > Hi Folks,
> > i would like to know if anybody has tried to implement a neutron solution 
> > with vsphere without using NSX-like solutions.
> > I mean, my lab environment is composed of :
> >
> >  - 1 network node ( neutron )
> >  - 1 controller node
> >  - 2 compute node ( kvm)
> >  - 1 compute node linked to a cluster vsphere 6.0
> >
> > i tried, without success ;( to deploy an instance on vsphere node with a 
> > network configuration of type VLAN; ( obviously, in this configuration,i 
> > have not the ambition of a ovs solution type :)  )
> > so my questions are: it's' possible to implement a network neutron solution 
> > of type VLAN ? if yes how can i do?
> > Thanks in advantage.
> > Miko Bello
> >
> >
> >
> >
> >
> >
> >
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 

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

Re: [Openstack-operators] openstack vmware

[Mark Voelker]

Ignazio,

> I know there is a nova driver for vmware.
> I' like to know if glance, heat, ceilometer etc etc work with vmware.


There are VMware drivers for Nova, Neutron (NSX and DVS, though the latter 
supports far fewer features), Neutron LBaaS, Cinder, and Glance.  Heat and 
Ceilometer also work fine.  You can find configuration guides here:

http://docs.openstack.org/kilo/config-reference/content/vmware-vmdk-driver.html

http://docs.openstack.org/kilo/config-reference/content/vmware.html

http://docs.openstack.org/kilo/config-reference/content/vmware-glance-backend.html

http://docs.openstack.org/kilo/config-reference/content/networking-plugin-vmware.html

http://docs.openstack.org/kilo/config-reference/content/networking-plugin-nsx.html

> As far is neutron is concerned, in a scenario where there are kvm and vmware 
> nodes, must I have an nsx multihypervisor solution ?
> Must I insall nsx componenents on kvm nodes (a modified ovs version  for kvm) 
> ?
> On vmware must I install the vmware nsx or the multihypervisor version ?

Not necessarily.  A common tactic for dealing with differing hypervisors (or 
for that matter, different networking or perhaps even storage solutions) is to 
deploy them into two separate regions: one for KVM and one for ESX.  If you’re 
not familiar with the regions concept in OpenStack, have a look here:

http://docs.openstack.org/openstack-ops/content/scaling.html

Essentially since these are separate API endpoints, you can have very different 
capabilities in each without having to worry about mixing and matching 
solutions.  So essentially you might have one region with ESX hypervisors, NSX 
for vSphere networking, and vSAN (or any other VMDK storage) for storage.  In 
the other region you might have KVM hypervisors with OVS for networking and NFS 
for storage.  Be aware that users must target their API calls to one region or 
the other though (since they are separate endpoints), and logical networks 
typically won’t stretch between regions.  Regions are often thought of as a 
construct for geographically diverse datacenters, but also work well as a means 
of segregation within a single DC.

At the risk of being accused of advertising on a mailer alias (=p), since you 
appear to have an interest in the VMware hypervisor and network stack you may 
want to have a look at the VMware Integrated OpenStack distribution:

http://www.vmware.com/products/openstack/

Other distributions (including I believe Mirantis and HP) also offer support 
for VMware underpinnings:

http://docs.hpcloud.com/#commercial/GA1/1.1commercial.install-GA-esx.html
https://www.mirantis.com/partners/mirantis-technology-partners/mirantis-partners-vmware/

At Your Service,

Mark T. Voelker



> On Sep 21, 2015, at 1:44 PM, Ignazio Cassano  wrote:
> 
> We would like to provide cloud infrastracture  multi hypervosor with sdn, 
> multi tenancy, orchestration and self provisioning.
> I think openstack with kvm is a good  start point but we have  hunderds 
> applications on vmware.
> A good compromise could be kvm and vmware with openstack but I am not sure it 
> is a good idea because vmware seems to me limited in this scenario.
> 
> Il giorno 21/set/2015 19:18, "Federico Michele Facca" 
>  ha scritto:
> there is no a proper answer to your question (expecially if you don't provide 
> a bit of a context :) i.e. 
> what are you trying to achieve? what are your constraints?)
> 
> In general, I doubt you can do many of the things you can do with OpenStack 
> using vCenter, and probably also with vCloud... (and the other way around, 
> there are things you can do with vCloud, you cannot do today with OpenStack) 
> on the other hand, by pluging vCenter in OpenStack you can do many things 
> that only vCenter can't achieve :)
> 
> 
> 
> On Mon, Sep 21, 2015 at 7:02 PM, Ignazio Cassano  
> wrote:
> Many thanks Federico...
> So the question is: why should I use openstack with vmware ?
> Il giorno 21/set/2015 18:34, "Federico Michele Facca" 
>  ha scritto:
> Hi Ignazio,
> I am not the greatest expert in my team on the topic, so there my be some 
> mistakes (anyone feel free to correct :)), read my reply inline
> 
> On Mon, Sep 21, 2015 at 6:02 PM, Ignazio Cassano  
> wrote:
> Hi all, I' would like to know which openstack community edition components 
> work with vmware.
> I know there is a nova driver for vmware.
> 
> 
> correct, basically it will act as a "proxy" toward vCenter
>  
> I' like to know if glance, heat, ceilometer etc etc work with vmware.
> 
> AFAIK Heat as no real dependency, so no issue. Ceilometer, we haven't tested, 
> but any implementation may reflect the fact that OS services for VMWare are 
> proxies (i.e. it will see whatever is on the other side like a huge compute 
> or a huge cinder)
> 
> About glance you may have some limitations, since it supports so far 

Re: [Openstack-operators] OpenSource ELK configurations

[Mark Voelker]

Sounds like a fine thing to point people to…thanks Joe.

https://github.com/osops/tools-logging/pull/3

At Your Service,

Mark T. Voelker


 On May 27, 2015, at 1:12 PM, Joe Gordon joe.gord...@gmail.com wrote:
 
 
 
 On Mon, May 18, 2015 at 3:11 PM, Tom Fifield t...@openstack.org wrote:
 There's some stuff in the osops repo:
 
 https://github.com/osops/tools-logging
 
 Please contribute if you can!
 
 Regards,
 
 Tom
 
 
 On 18/05/15 14:56, Anand Kumar Sankaran wrote:
 Hi all
 
 Is there a set of open source ELK configurations available?  (log stash
 filters, templates, kibana dashboards).  I see a github repository from
 Godaddy, wondering if there is a standard set that is used.
 
 OpenStack has an ELK stack running at logstash.openstack.org to help debug 
 test jobs.
 
 The logstash filters can be found at: 
 http://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/templates/logstash/indexer.conf.erb
  
 
 Thanks.
 
 —
 anand
 
 
 ___
 OpenStack-operators mailing list
 OpenStack-operators@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 
 
 ___
 OpenStack-operators mailing list
 OpenStack-operators@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 
 ___
 OpenStack-operators mailing list
 OpenStack-operators@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Openstack-operators] FYI: Rabbit Heartbeat Patch Landed

[Mark Voelker]

At the Operator’s midcycle meetup in Philadelphia recently there was a lot of 
operator interest[1] in the idea behind this patch:

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

Operators may want to take note that it merged yesterday.  Happy testing!


[1] See bottom of https://etherpad.openstack.org/p/PHL-ops-rabbit-queue

At Your Service,

Mark T. Voelker
OpenStack Architect


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