Re: [openstack-dev] Mixed service version CI testing

2017-12-27 Thread Curtis
On Tue, Dec 19, 2017 at 10:58 AM, Matt Riedemann <mriede...@gmail.com> wrote:
> During discussion in the TC channel today [1], we got talking about how
> there is a perception that you must upgrade all of the services together for
> anything to work, at least the 'core' services like
> keystone/nova/cinder/neutron/glance - although maybe that's really just
> nova/cinder/neutron?
>
> Anyway, I posit that the services are not as tightly coupled as some people
> assume they are, at least not since kilo era when microversions started
> happening in nova.
>
> However, with the way we do CI testing, and release everything together, the
> perception is there that all things must go together to work.
>
> In our current upgrade job, we upgrade everything to N except the
> nova-compute service, that remains at N-1 to test rolling upgrades of your
> computes and to make sure guests are unaffected by the upgrade of the
> control plane.
>
> I asked if it would be valuable to our users (mostly ops for this right?) if
> we had an upgrade job where everything *except* nova were upgraded. If
> that's how the majority of people are doing upgrades anyway it seems we
> should make sure that works.
>
> I figure leaving nova at N-1 makes more sense because nova depends on the
> other services (keystone/glance/cinder/neutron) and is likely the harder /
> slower upgrade if you're going to do rolling upgrades of your compute nodes.
>
> This type of job would not run on nova changes on the master branch, since
> those changes would not be exercised in this type of environment. So we'd
> run this on master branch changes to
> keystone/cinder/glance/neutron/trove/designate/etc.
>
> Does that make sense? Would this be valuable at all? Or should the opposite
> be tested where we upgrade nova to N and leave all of the dependent services
> at N-1?
>
> Really looking for operator community feedback here.

I'd def like to see something like this.

Thanks,
Curtis.

>
> [1]
> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-19.log.html#t2017-12-19T15:14:15
>
> --
>
> Thanks,
>
> Matt
>
> __
> 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



-- 
Blog: serverascode.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


Re: [openstack-dev] [trove][all][tc] A proposal to rearchitect Trove

2017-06-19 Thread Curtis
lt for not paying close
attention, but we should be able to create VMs for a tenant that are
not managed by the tenant but that could be billed to them in some
fashion. At least that's my opinion.

> - The CI should test all databases that are considered to be ‘supported’
> without excessive use of resources in the gate; better code modularization
> will help determine the tests which can safely be skipped in testing changes
>
> - Clusters should be first class citizens not an afterthought, single
> instance databases may be the ‘special case’, not the other way around

Definitely agree on that. Cluster first model.

>
> - The project must provide guest images (or at least complete tooling for
> deployers to build these); while the project can’t distribute operating
> systems and database software, the current deployment model merely impedes
> adoption
>
> - Clusters spanning OpenStack deployments are a real thing that must be
> supported
>

I'm curious as to how this will be done. This is a requirement in
NFV-land as well for other services. Would be very powerful and is
needed in other areas.

Thanks,
Curtis.

> This might sound harsh, that isn’t the intent. Each of these is the
> consequence of one or more perfectly rational decisions. Some of those
> decisions have had unintended consequences, and others were made knowing
> that we would be incurring some technical debt; debt we have not had the
> time or resources to address. Fixing all these is not impossible, it just
> takes the dedication of resources by the community.
>
> I do not have a complete design for what the new Trove would look like. For
> example, I don’t know how we will interact with other projects (like Heat).
> Many questions remain to be explored and answered.
>
> Would it suffice to just use the existing Heat resources and build templates
> around those, or will it be better to implement custom Trove resources and
> then orchestrate things based on those resources?
>
> Would Trove implement the workflows required for multi-stage database
> operations by itself, or would it rely on some other project (say Mistral)
> for this? Is Mistral really a workflow service, or just cron on steroids? I
> don’t know the answer but I would like to find out.
>
> While we don’t have the answers to these questions, I think this is a
> conversation that we must have, one that we must decide on, and then as a
> community commit the resources required to make a Trove v2 which delivers on
> the mission of the project; “To provide scalable and reliable Cloud Database
> as a Service provisioning functionality for both relational and
> non-relational database engines, and to continue to improve its
> fully-featured and extensible open source framework.”[2]
>
> Thanks,
>
> -amrith
>
>
> [1] https://www.openstack.org/assets/survey/April2017SurveyReport.pdf
> [2] https://wiki.openstack.org/wiki/Trove#Mission_Statement
>
>
>
> __
> 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
>



-- 
Blog: serverascode.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


Re: [openstack-dev] [Keystone] Cockroachdb for Keystone Multi-master

2017-05-18 Thread Curtis
On Thu, May 18, 2017 at 4:13 PM, Adrian Turjak <adri...@catalyst.net.nz> wrote:
> Hello fellow OpenStackers,
>
> For the last while I've been looking at options for multi-region
> multi-master Keystone, as well as multi-master for other services I've
> been developing and one thing that always came up was there aren't many
> truly good options for a true multi-master backend. Recently I've been
> looking at Cockroachdb and while I haven't had the chance to do any
> testing I'm curious if anyone else has looked into it. It sounds like
> the perfect solution, and if it can be proved to be stable enough it
> could solve a lot of problems.
>
> So, specifically in the realm of Keystone, since we are using sqlalchemy
> we already have Postgresql support, and since Cockroachdb does talk
> Postgres it shouldn't be too hard to back Keystone with it. At that
> stage you have a Keystone DB that could be multi-region, multi-master,
> consistent, and mostly impervious to disaster. Is that not the holy
> grail for a service like Keystone? Combine that with fernet tokens and
> suddenly Keystone becomes a service you can't really kill, and can
> mostly forget about.
>
> I'm welcome to being called mad, but I am curious if anyone has looked
> at this. I'm likely to do some tests at some stage regarding this,
> because I'm hoping this is the solution I've been hoping to find for
> quite a long time.

I was going to take a look at this a bit myself, just try it out. I
can't completely speak for the Fog/Edge/Massively Distributed working
group in OpenStack, but I feel like this might be something they look
into.

For standard multi-site I don't know how much it would help, say if
you only had a couple or three clouds, but more than that maybe this
starts to make sense. Also running Galera has gotten easier but still
not that easy.

I had thought that the OpenStack community was deprecating Postgres
support though, so that could make things a bit harder here (I might
be wrong about this).

Thanks,
Curtis.

>
> Further reading:
> https://www.cockroachlabs.com/
> https://github.com/cockroachdb/cockroach
> https://www.cockroachlabs.com/docs/build-a-python-app-with-cockroachdb-sqlalchemy.html
>
> Cheers,
> - Adrian Turjak
>
>
> __
> 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



-- 
Blog: serverascode.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


Re: [openstack-dev] [neutron][networking-l2gw] openstack vtep setup missing docs

2017-04-04 Thread Curtis
On Tue, Apr 4, 2017 at 8:53 AM, Saverio Proto <saverio.pr...@switch.ch> wrote:
> Hello Armando,
>
> I managed to implement the L2GW setup purely in software, without an
> hardware appliance.

Nice! That is very interesting. I will take a look at the work you've done here.

Thanks,
Curtis.

>
> I documented in the README file, please look at this review
> https://review.openstack.org/453209
>
> I have a question: do we have a name for this node where the actually
> bridging happens between a VXLAN tenant network and a physical L2 network ?
> Is it okay to call it the l2gw node ?
>
> The l2gw plugin it self runs on the controller, so also the
> neutron-l2gw-plugin agent runs on the controller.
>
> I think it necessary to clarify this naming, because before trying the
> software I did the mistake of thinking that the neutron-l2gw-agent had
> to run on the switch where the actual briding happens.
>
> thank you
>
> Saverio
>
>
>
>
> On 30/03/17 18:40, Armando M. wrote:
>>
>>
>> On 30 March 2017 at 08:47, Saverio Proto <saverio.pr...@switch.ch
>> <mailto:saverio.pr...@switch.ch>> wrote:
>>
>> Hello,
>>
>> I am trying to use the neutron l2gw plugin, but I am not using a bare
>> metal switch to bridge.
>>
>> I am using a server with Openvswitch.
>>
>>
>> I am not aware of any effort to implement L2GW purely in software, in
>> fact this was one key missing pieces that prevented the project to have
>> CI solely dealt with the upstream infra resources. Perhaps OVN may come
>> to the rescue here, I recall at some point the team was looking at the
>> L2GW API.
>>
>> Thanks,
>> Armando
>>
>>
>>
>> Following this documentation:
>>
>> http://networkop.co.uk/blog/2016/05/21/neutron-l2gw/
>> <http://networkop.co.uk/blog/2016/05/21/neutron-l2gw/>
>>
>> At one point there is this command:
>>
>> sudo vtep-bootstrap L5 10.0.0.5 192.168.91.21 --no_encryption
>>
>> This vtep-bootstrap is specific for Cumulux Linux
>>
>> Anybody has documentation with normal vtep-ctl commands ?
>>
>> So far on the Ubuntu server I did the following:
>>
>> apt-get install openvswitch-vtep
>> ovsdb-tool create /etc/openvswitch/vtep.db
>> /usr/share/openvswitch/vtep.ovsschema
>>
>> Anyone has more complete documentation ?
>>
>> I did not understand if the vtep-openvswitch controlled by the l2gw
>> plugin will make vxlan tunnels to all the compute nodes, to bridge the
>> tenant network with a physical l2 network ? Or all this traffic has to
>> pass to the network node also because the vtep openvswitch is not able
>> to talk to the compute nodes ?
>>
>> thank you
>>
>> Saverio
>>
>>
>> --
>> SWITCH
>> Saverio Proto, Peta Solutions
>> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
>> phone +41 44 268 15 15, direct +41 44 268 1573
>> saverio.pr...@switch.ch <mailto:saverio.pr...@switch.ch>,
>> http://www.switch.ch
>>
>> http://www.switch.ch/stories
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> <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
>>
>
>
> --
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 15, direct +41 44 268 1573
> saverio.pr...@switch.ch, http://www.switch.ch
>
> http://www.switch.ch/stories
>
> __
> 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



-- 
Blog: serverascode.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-dev] [tricircle] Example EVPN question/use-case

2017-02-07 Thread Curtis
Hi,

I'm not sure if this is useful at all, but there is a blog post [1]
from one of the people behind the PacketPushers podcast regarding
connecting two OpenStack clouds with a EVPN. They are wondering how to
do it.

They want to connect an NSX based cloud with a OpenContrail based
cloud and do it at very high speeds. Interesting use case, real world.

Thanks,
Curtis.

[1]: 
http://etherealmind.com/help-wanted-stitching-a-federated-sdn-on-openstack-with-evpn/

__
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] [Openstack-operators] Large Contributing OpenStack Operators working group?

2017-02-02 Thread Curtis
On Thu, Feb 2, 2017 at 1:14 PM, Jay Pipes <jaypi...@gmail.com> wrote:
> Hi,
>
> I was told about this group today. I have a few questions. Hopefully someone
> from this team can illuminate me with some answers.
>
> 1) What is the purpose of this group? The wiki states that the team "aims to
> define the use cases and identify and prioritise the requirements which are
> needed to deploy, manage, and run services on top of OpenStack. This work
> includes identifying functional gaps, creating blueprints, submitting and
> reviewing patches to the relevant OpenStack projects, contributing to
> working those items, tracking their completion."
>
> What is the difference between the LCOO and the following existing working
> groups?
>
>  * Large Deployment Team
>  * Massively Distributed Team
>  * Product Working Group
>  * Telco/NFV Working Group

I just wanted to add one thing here, and that is that the Telco/NFV
Working Group you mention above is really the Operators Telecom/NFV
Working Group, which is not the same group that had existed before,
and is meant to have an OpenStack Operators perspective. We have been
having some good meetings recently, and some of what we are hoping to
do is bring together various communities, eg. OpenStack Operators,
telecoms, OPNFV, and others, and act as a sort of bridge, as well as
actually generate some useful artifacts, though likely not any code
other than what we might get into something like osops.

The LCOO seems different to me b/c they will have actual human
resources to put into developing code. Or at least that is my
impression of what they are doing. I do think they should try to
adhere to more of the OpenStack community guidelines, eg. IRC and
such, but I was also recently on a 8 hour conference call with a
telecom; they love their conference calls. ;)

Thanks,
Curtis.

>
> 2) According to the wiki page, only companies that are "Multi-Cloud
> Operator[s] and/or Network Service Provider[s]" are welcome in this team.
> Why is the team called "Large Contributing OpenStack Operators" if it's only
> for Telcos? Further, if this is truly only for Telcos, why isn't the
> Telco/NFV working group appropriate?
>
> 3) Under the "Guiding principles" section of the above wiki, the top
> principle is "Align with the OpenStack Foundation". If this is the case, why
> did the group move its content to the closed Atlassian Confuence platform?
> Why does the group have a set of separate Slack channels instead of using
> the OpenStack mailing lists and IRC channels? Why is the OPNFV Jira used for
> tracking work items for the LCOO agenda?
>
> See https://wiki.openstack.org/wiki/Gluon/Tasks-Ocata for examples.
>
> 4) I see a lot of agenda items around projects like Gluon, Craton, Watcher,
> and Blazar. I don't see any concrete ideas about talking with the developers
> of the key infrastructure services that OpenStack is built around. How does
> the LCOO plan on reaching out to the developers of the long-standing
> OpenStack projects like Nova, Neutron, Cinder, and Keystone to drive their
> shared agenda?
>
> Thanks for reading and (hopefully) answering.
>
> -jay
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
Blog: serverascode.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


Re: [openstack-dev] [neutron] Confusion around the complexity

2017-01-12 Thread Curtis
On Thu, Jan 12, 2017 at 3:46 PM, Joshua Harlow <harlo...@fastmail.com> wrote:
> So I don't want to start to much of a flame-war and am really just trying to
> understand things that may be beyond me (so treat me nicely, ha).
>
> The basic question that I've been wondering revolves around the following
> kind of 'thought experiment' that asks something along the lines of:
>
> """
> If I am a user of openstack, say I'm an iphone developer, trying to get my
> 'game' and associated 'game APIs' setup in a manner that is HA (say fronted
> by a load-balancer), using my custom image, secure and visible to either an
> intranet or to the large internet then what is the steps I would have to do
> when interacting with openstack to accomplish this and what would the
> provider of openstack have to give to me as endpoints to make this possible.
> """
>

Presumably this is a public OpenStack cloud? If so...

It's been a while since I worked at a public OpenStack cloud, but most
I would imagine will auto create a tenant network and router (if they
can afford the public IPv4s for the router :)) and then when a user
creates an instance it just ends up on that initial "default" tenant
network. This is usually left to the public cloud to implement during
their customer on-boarding process. That is assuming the public cloud
is allowing tenant "private" networks, which not all would do. There
are other models.

Now, a load balancer, if that is required, is different and bit harder
if you mean one that is managed by the OpenStack cloud, as opposed to
a user creating their own LB instance.

Perhaps what you are really thinking about is the simplicity of a more
"VPS" like interface, ala Digital Ocean (and now somewhat mimicked by
AWS with uh, LightSail I think). I've always thought it would perhaps
be a nice project in OpenStack to do a simple VPS style interface.

Thanks,
Curtis.

> One of the obvious ones is nova and glance, and the API and usage there
> feels pretty straightforward as is (isn't really relevant to this
> conversation anyway). The one that feels bulky and confusing (at least for
> me) is the things I'd have to do in neutron to create and/or select
> networks, create and/or select subnets, create and/or select ports and
> so-on...
>
> As a supposed iphone developer (dev/ops, yadayada) just trying to get
> his/her game to market why would I really want to know about selecting
> networks, create and/or selecting subnets, create and/or selecting ports and
> so-on...
>
> It may just be how it is, but I'd like to at least ask if others are really
> happy with the interactions/steps (I guess we could/maybe we should ask
> similar questions around various other projects as well?); if I'm just an
> outlier that's ok, at least I asked :-P
>
> -Josh
>
> __
> 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



-- 
Blog: serverascode.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


Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

2016-08-29 Thread Curtis
On Mon, Aug 29, 2016 at 2:15 PM, Joshua Harlow <harlo...@fastmail.com> wrote:
> Curtis wrote:
>>
>> On Mon, Aug 29, 2016 at 1:27 PM, gordon chung<g...@live.ca>  wrote:
>>>
>>> just to clarify, what 'innovation' do you believe is required to enable
>>> you
>>> to build on top of OpenStack. what are the feature gaps you are
>>> proposing?
>>> let's avoid defining "the cloud" since that will give you 1000 different
>>> answers if you ask 1000 different people.*
>>
>>
>> One idea I hear fairly often is having a couple of hypervisors in say
>> a single store or some other customer premise, but not wanting to also
>> run an OpenStack control plane there. If we are talking about a
>> hypervisor level, not some other unknown but smaller IoTs...uh thing,
>> does that make more sense from a OpenStack + vCPE context? Or do some
>> think that is out of scope for OpenStack's mission as well?
>>
>> Thanks,
>> Curtis.
>>
>
> 
>
> So is that like making a customer premise have the equivalent of dumb
> terminals (maybe we can call them 'semi-smart' terminals) where those things
> basically can be remote controlled (aka the VMs on them can be upgraded or
> downgraded or deleted or ...) by the corporate (or other) entity that is
> controlling those terminals?
>
> If that's the case, then I don't exactly call that a cloud (in my classical
> sense), but more of a software delivery (and remote-control) strategy (and
> using nova to do this for u?).
>
> But then I don't know all the 3 or 4 letter acronyms so who knows, I might
> be incorrect with the above assumption :-P

>From a brief look, it seems like vCPE is more along the lines of the
customer having a "thin" device on their premise and their (now
virtual) network functions, eg. firewall, live in the providers data
center over a private link created by that thin device. So having a
hypervisor on a customer premise is probably not what most telecoms
would consider vCPE [1].

But in my (limited) example, I'm not talking about managing that thin
device, I am thinking of a hypervisor or two instead in a customer
premise, or remote location, that is controlled by some (magic?)
remote nova, and yeah, would have access to glance, etc, to deploy
instances, basically as a way of avoiding running an OpenStack control
plane there. But not so much in the way of managing upgrades of the
software on that virtual machine on that hypervisor or anything, just
acting as IaaS.

Thanks,
Curtis.

[1]: Pg. 48 - 
http://innovation.verizon.com/content/dam/vic/PDF/Verizon_SDN-NFV_Reference_Architecture.pdf


>
> -Josh
>
>
>
>
> __
> 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



-- 
Blog: serverascode.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


Re: [openstack-dev] [all][massively distributed][architecture]Coordination between actions/WGs

2016-08-29 Thread Curtis
On Mon, Aug 29, 2016 at 1:27 PM, gordon chung <g...@live.ca> wrote:
> just to clarify, what 'innovation' do you believe is required to enable you
> to build on top of OpenStack. what are the feature gaps you are proposing?
> let's avoid defining "the cloud" since that will give you 1000 different
> answers if you ask 1000 different people.*

One idea I hear fairly often is having a couple of hypervisors in say
a single store or some other customer premise, but not wanting to also
run an OpenStack control plane there. If we are talking about a
hypervisor level, not some other unknown but smaller IoTs...uh thing,
does that make more sense from a OpenStack + vCPE context? Or do some
think that is out of scope for OpenStack's mission as well?

Thanks,
Curtis.

>
> * actually you'll get 100 answers and the rest will say: "i don't know."
>
>
> On 29/08/16 12:23 PM, HU, BIN wrote:
>
> Please see inline [BH526R].
>
> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Monday, August 29, 2016 3:48 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][massively
> distributed][architecture]Coordination between actions/WGs
>
> On 08/27/2016 11:16 AM, HU, BIN wrote:
>
> The challenge in OpenStack is how to enable the innovation built on top of
> OpenStack.
>
> No, that's not the challenge for OpenStack.
>
> That's like saying the challenge for gasoline is how to enable the
> innovation of a jet engine.
>
> [BH526R] True. 87 gas or diesel certainly cannot be used in any jet engine.
> While Jet A-1 and Jet B fuel are widely used for jet engine today,
> innovation of a new generation of jet engine may require an innovation of
> new type of aviation fuel.
>
> So telco use cases is not only the innovation built on top of
> OpenStack. Instead, telco use cases, e.g. Gluon (NFV networking), vCPE
> Cloud, Mobile Cloud, Mobile Edge Cloud, brings the needed requirement
> for innovation in OpenStack itself. If OpenStack don't address those
> basic requirements,
>
> That's the thing, Bin, those are *not* "basic" requirements. The Telco vCPE
> and Mobile "Edge cloud" (hint: not a cloud) use cases are asking for
> fundamental architectural and design changes to the foundational components
> of OpenStack. Instead of Nova being designed to manage a bunch of hardware
> in a relatively close location (i.e. a datacenter or multiple datacenters),
> vCPE is asking for Nova to transform itself into a micro-agent that can be
> run on an Apple Watch and do things in resource-constrained environments
> that it was never built to do.
>
> [BH526R] So we have 2 choices here - either to explicitly exclude telco
> requirement from OpenStack, and clearly indicate that telco needs to work on
> its own "telco stack"; or to allow telco to innovate within OpenStack
> through perhaps a new type of "telco nova" and/or "telco Neutron". Which way
> do you suggest?
>
> And, honestly, I have no idea what Gluon is trying to do. Ian sent me some
> information a while ago on it. I read it. I still have no idea what Gluon is
> trying to accomplish other than essentially bypassing Neutron entirely.
> That's not "innovation". That's subterfuge.
>
> [BH526R] Thank you for recognizing you don't know Gluon. Certainly the
> perception of "bypassing Neutron entirely" is incorrect. You are very
> welcome to join our project and meeting so that you can understand more of
> what Gluon is. We are also happy to set up specific meetings with you to
> discuss it too. Just let me know which way prefer. We are looking for you to
> participate in Gluon project and meeting.
>
> [BH526R] On the other hand, I also try to understand why "bypassing Neutron
> entirely" is not an innovation. Neutron is not perfect. (I don't mean Gluon
> here, but) if there is an innovation that can replace Neutron entirely,
> everyone should be happy. Just like automobile bypassed carriage wagon
> entirely.
>
> the innovation will never happen on top of OpenStack.
>
> Sure it will. AT and BT and other Telcos just need to write their own
> software that runs their proprietary vCPE software distribution mechanism,
> that's all. The OpenStack community shouldn't be relied upon to create
> software that isn't applicable to general cloud computing and cloud
> management platforms.
>
> [BH526R] If I understand correctly, this suggestion excludes telco from
> OpenStack entirely. That's fine.
>
> An example is - self-driving car is built on top of many technologies, such
> as sensor/camera, AI, maps, middleware etc. All innovations in each
> technology (sensor/camera, AI, map, etc.) bring togethe

Re: [openstack-dev] [Openstack-operators] [gnocchi] profiling and benchmarking 2.1.x

2016-06-25 Thread Curtis
On Fri, Jun 24, 2016 at 2:09 PM, gordon chung <g...@live.ca> wrote:
> hi,
>
> i realised i didn't post this beyond IRC, so here are some initial
> numbers for some performance/benchmarking i did on Gnocchi.
>
> http://www.slideshare.net/GordonChung/gnocchi-profiling-21x
>
> as a headsup, the data above is using Ceph and with pretty much a
> default configuration. i'm currently doing more tests to see how it
> works if you actually start turning some knobs on Ceph (spoiler: it gets
> better).

Thanks Gordon. I will definitely take a look through your slides.
Looking forward to what test results you get when you start turning
some knobs.

Thanks,
Curtis.

>
> cheers,
>
> --
> gord
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
Blog: serverascode.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


Re: [openstack-dev] [openstack-ansible] OpenVSwitch support

2016-03-29 Thread Curtis
On Tue, Mar 29, 2016 at 8:13 AM, Truman, Travis
<travis_tru...@cable.comcast.com> wrote:
> Curtis,
>
> Please take a look at https://review.openstack.org/#/c/298765/ as its
> probably a good place to start digging into OVS.
>

Perfect, thanks, am looking into it now. :)

Thanks,
Curtis.

> Travis Truman
> IRC: automagically
>
> On 3/24/16, 12:37 PM, "Curtis" <serverasc...@gmail.com> wrote:
>
>>OK thanks everyone. I will put on my learnening hat and start digging
>>into this.
>>
>>Thanks,
>>Curtis.
>>
>>On Thu, Mar 24, 2016 at 10:07 AM, Truman, Travis
>><travis_tru...@cable.comcast.com> wrote:
>>> Michael Gugino and I were going to work on OVS and I believe we both got
>>> sidetracked. I¹ll echo Kevin¹s offer to help out where possible, but at
>>> the moment, I¹ve been tied up with other items.
>>>
>>> On 3/24/16, 11:55 AM, "Kevin Carter" <kevin.car...@rackspace.com> wrote:
>>>
>>>>I believe the OVS bits are being worked on, however I don't remember by
>>>>whom and I don't know the current state of the work. Personally, I'd
>>>>welcome the addition of other neutron plugin options and if you have
>>>>time
>>>>to work on any of those bits I'd be happy to help out where I can and
>>>>review the PRs.
>>>>
>>>>--
>>>>
>>>>Kevin Carter
>>>>IRC: cloudnull
>>>>
>>>>
>>>>
>>>>From: Curtis <serverasc...@gmail.com>
>>>>Sent: Thursday, March 24, 2016 10:33 AM
>>>>To: OpenStack Development Mailing List (not for usage questions)
>>>>Subject: [openstack-dev] [openstack-ansible] OpenVSwitch support
>>>>
>>>>Hi,
>>>>
>>>>I'm in the process of building OPNFV style labs [1]. I'd prefer to
>>>>manage these labs with openstack-ansible, but I will need things like
>>>>OpenVSwitch.
>>>>
>>>>I know there was talk of supporting OVS in some fashion [2] but I'm
>>>>wondering what the current status or thinking is. If it's desirable by
>>>>the community to add OpenVSwitch support, and potentially other OPNFV
>>>>related features, I have time to contribute to work on them (as best I
>>>>can, at any rate).
>>>>
>>>>Let me know what you think,
>>>>Curtis.
>>>>
>>>>[1]: https://www.opnfv.org/
>>>>[2]: https://etherpad.openstack.org/p/osa-neutron-dvr
>>>>
>>>>
>>>>__
>>>>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
>>
>>
>>
>>--
>>Blog: serverascode.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



-- 
Blog: serverascode.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


Re: [openstack-dev] [openstack-ansible] OpenVSwitch support

2016-03-24 Thread Curtis
OK thanks everyone. I will put on my learnening hat and start digging into this.

Thanks,
Curtis.

On Thu, Mar 24, 2016 at 10:07 AM, Truman, Travis
<travis_tru...@cable.comcast.com> wrote:
> Michael Gugino and I were going to work on OVS and I believe we both got
> sidetracked. I¹ll echo Kevin¹s offer to help out where possible, but at
> the moment, I¹ve been tied up with other items.
>
> On 3/24/16, 11:55 AM, "Kevin Carter" <kevin.car...@rackspace.com> wrote:
>
>>I believe the OVS bits are being worked on, however I don't remember by
>>whom and I don't know the current state of the work. Personally, I'd
>>welcome the addition of other neutron plugin options and if you have time
>>to work on any of those bits I'd be happy to help out where I can and
>>review the PRs.
>>
>>--
>>
>>Kevin Carter
>>IRC: cloudnull
>>
>>
>>
>>From: Curtis <serverasc...@gmail.com>
>>Sent: Thursday, March 24, 2016 10:33 AM
>>To: OpenStack Development Mailing List (not for usage questions)
>>Subject: [openstack-dev] [openstack-ansible] OpenVSwitch support
>>
>>Hi,
>>
>>I'm in the process of building OPNFV style labs [1]. I'd prefer to
>>manage these labs with openstack-ansible, but I will need things like
>>OpenVSwitch.
>>
>>I know there was talk of supporting OVS in some fashion [2] but I'm
>>wondering what the current status or thinking is. If it's desirable by
>>the community to add OpenVSwitch support, and potentially other OPNFV
>>related features, I have time to contribute to work on them (as best I
>>can, at any rate).
>>
>>Let me know what you think,
>>Curtis.
>>
>>[1]: https://www.opnfv.org/
>>[2]: https://etherpad.openstack.org/p/osa-neutron-dvr
>>
>>__
>>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



-- 
Blog: serverascode.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-dev] [openstack-ansible] OpenVSwitch support

2016-03-24 Thread Curtis
Hi,

I'm in the process of building OPNFV style labs [1]. I'd prefer to
manage these labs with openstack-ansible, but I will need things like
OpenVSwitch.

I know there was talk of supporting OVS in some fashion [2] but I'm
wondering what the current status or thinking is. If it's desirable by
the community to add OpenVSwitch support, and potentially other OPNFV
related features, I have time to contribute to work on them (as best I
can, at any rate).

Let me know what you think,
Curtis.

[1]: https://www.opnfv.org/
[2]: https://etherpad.openstack.org/p/osa-neutron-dvr

__
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] [openstack-ansible] Mid Cycle Sprint

2015-12-14 Thread Curtis
FYI it looks like Ansible Fest London is Feb 18th.

On Thu, Dec 10, 2015 at 1:29 PM, Amy Marrich  wrote:
> I'd be game to join in if it's in San Antonio. While I'd love to go to
> London I don't think I'd make.
>
> Like Major I'd like to see some doc work.
>
> Amy Marrich
> 
> From: Jesse Pretorius 
> Sent: Wednesday, December 9, 2015 6:45:56 AM
> To: openstack-dev@lists.openstack.org;
> openstack-operat...@lists.openstack.org
> Subject: [openstack-dev] [openstack-ansible] Mid Cycle Sprint
>
> Hi everyone,
>
> At the Mitaka design summit in Tokyo we had some corridor discussions about
> doing a mid-cycle meetup for the purpose of continuing some design
> discussions and doing some specific sprint work.
>
> ***
> I'd like indications of who would like to attend and what
> locations/dates/topics/sprints would be of interest to you.
> ***
>
> For guidance/background I've put some notes together below:
>
> Location
> 
> We have contributors, deployers and downstream consumers across the globe so
> picking a venue is difficult. Rackspace have facilities in the UK (Hayes,
> West London) and in the US (San Antonio) and are happy for us to make use of
> them.
>
> Dates
> -
> Most of the mid-cycles for upstream OpenStack projects are being held in
> January. The Operators mid-cycle is on February 15-16.
>
> As I feel that it's important that we're all as involved as possible in
> these events, I would suggest that we schedule ours after the Operators
> mid-cycle.
>
> It strikes me that it may be useful to do our mid-cycle immediately after
> the Ops mid-cycle, and do it in the UK. This may help to optimise travel for
> many of us.
>
> Format
> --
> The format of the summit is really for us to choose, but typically they're
> formatted along the lines of something like this:
>
> Day 1: Big group discussions similar in format to sessions at the design
> summit.
>
> Day 2: Collaborative code reviews, usually performed on a projector, where
> the goal is to merge things that day (if a review needs more than a single
> iteration, we skip it. If a review needs small revisions, we do them on the
> spot).
>
> Day 3: Small group / pair programming.
>
> Topics
> --
> Some topics/sprints that come to mind that we could explore/do are:
>  - Install Guide Documentation Improvement [1]
>  - Development Documentation Improvement (best practises, testing, how to
> develop a new role, etc)
>  - Upgrade Framework [2]
>  - Multi-OS Support [3]
>
> [1] https://etherpad.openstack.org/p/oa-install-docs
> [2] https://etherpad.openstack.org/p/openstack-ansible-upgrade-framework
> [3] https://etherpad.openstack.org/p/openstack-ansible-multi-os-support
>
> --
> Jesse Pretorius
> IRC: odyssey4me
>
> __
> 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
>



-- 
Blog: serverascode.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


Re: [openstack-dev] [Openstack-operators] [openstack-ansible] Mid Cycle Sprint

2015-12-09 Thread Curtis
On Wed, Dec 9, 2015 at 5:45 AM, Jesse Pretorius
 wrote:
> Hi everyone,
>
> At the Mitaka design summit in Tokyo we had some corridor discussions about
> doing a mid-cycle meetup for the purpose of continuing some design
> discussions and doing some specific sprint work.
>
> ***
> I'd like indications of who would like to attend and what
> locations/dates/topics/sprints would be of interest to you.
> ***
>

I'd like to get more involved in openstack-ansible. I'll be going to
the operators mid-cycle in Feb, so could stay later and attend in West
London. However, I could likely make it to San Antonio as well. Not
sure if that helps but I will definitely try to attend where ever it
occurs.

Thanks.

> For guidance/background I've put some notes together below:
>
> Location
> 
> We have contributors, deployers and downstream consumers across the globe so
> picking a venue is difficult. Rackspace have facilities in the UK (Hayes,
> West London) and in the US (San Antonio) and are happy for us to make use of
> them.
>
> Dates
> -
> Most of the mid-cycles for upstream OpenStack projects are being held in
> January. The Operators mid-cycle is on February 15-16.
>
> As I feel that it's important that we're all as involved as possible in
> these events, I would suggest that we schedule ours after the Operators
> mid-cycle.
>
> It strikes me that it may be useful to do our mid-cycle immediately after
> the Ops mid-cycle, and do it in the UK. This may help to optimise travel for
> many of us.
>
> Format
> --
> The format of the summit is really for us to choose, but typically they're
> formatted along the lines of something like this:
>
> Day 1: Big group discussions similar in format to sessions at the design
> summit.
>
> Day 2: Collaborative code reviews, usually performed on a projector, where
> the goal is to merge things that day (if a review needs more than a single
> iteration, we skip it. If a review needs small revisions, we do them on the
> spot).
>
> Day 3: Small group / pair programming.
>
> Topics
> --
> Some topics/sprints that come to mind that we could explore/do are:
>  - Install Guide Documentation Improvement [1]
>  - Development Documentation Improvement (best practises, testing, how to
> develop a new role, etc)
>  - Upgrade Framework [2]
>  - Multi-OS Support [3]
>
> [1] https://etherpad.openstack.org/p/oa-install-docs
> [2] https://etherpad.openstack.org/p/openstack-ansible-upgrade-framework
> [3] https://etherpad.openstack.org/p/openstack-ansible-multi-os-support
>
> --
> Jesse Pretorius
> IRC: odyssey4me
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
Blog: serverascode.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