Re: [Openstack] Is it possible to use Xenserver with two virtual machines as Compute Node and Network node to set up openstack + neutron network?

2014-12-11 Thread Matt Van Winkle 
Yes, for what it's worth, we manage all our public cloud regions with instances 
running on XenServer in a small private cloud.  That small installation is 
managed by Vms manually created on a small number of XenServer machines.  This 
includes Quantum and Melange nodes (although we hope to move them to Neutorn 
soon).

Additionally – our compute nodes run in production as a VM on each XenServer 
hypervisor.  It doubles the overhead from a "node" standpoint, but provides a 
lot of advantages.

Thanks!
Matt

From: Bob Ball mailto:bob.b...@citrix.com>>
Date: Thursday, December 11, 2014 4:39 AM
To: dhanesh1212121212 mailto:dhanesh1...@gmail.com>>, 
"openstack@lists.openstack.org" 
mailto:openstack@lists.openstack.org>>
Subject: Re: [Openstack] Is it possible to use Xenserver with two virtual 
machines as Compute Node and Network node to set up openstack + neutron network?

Hi Dhanesh,

Yes, this should be possible – there is no additional coupling between the 
compute node and the network node when running with XenServer and as such they 
can easily be running as two separate virtual machines.

In terms of the setup, you might want to look at 
http://blogs.citrix.com/2013/06/14/openstack-networking-quantum-on-xenserver-from-notworking-to-networking/
 which has a useful deployment diagram and should help explain what can be 
separated in which way.

Bob

From: dhanesh1212121212 [mailto:dhanesh1...@gmail.com]
Sent: 11 December 2014 08:07
To: openstack@lists.openstack.org
Subject: [Openstack] Is it possible to use Xenserver with two virtual machines 
as Compute Node and Network node to set up openstack + neutron network?

Hi All,


Is it possible to use Xenserver with  two virtual machines as Compute Node and 
Network node?
Will it effect the performance? or the set up in any ways?



Regards,
Dhanesh M.
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Bringing focus to the Operators and Users at the next summit

2013-12-23 Thread Matt Van Winkle 
Good points Mark.  And to several of the other comments made this weekend, I 
think that mid-cycle is indeed better.  Not only does it avoid the cram-packed 
design summit, it allows those of us with access to Core/key developers in our 
own organizations to help push change after the user/operators have collected 
their thoughts and leading up to the next summit.

Also, whether in conjunction with other non-Openstack conferences or not, these 
chats don't have to be a single event – we could have a few mid-cycle 
conversations based on region or user type.  It would just require some extra 
co-ordination, correlation, etc, but if we are generating outputs like a 
weighted priority list, etc, we'll have solved for a lot of these things anyway.

Thanks!
Matt

From: Mark Collier mailto:m...@collierclan.net>>
Date: Monday, December 23, 2013 7:29 AM
To: Sean Dague mailto:s...@dague.net>>
Cc: "openstack@lists.openstack.org" 
mailto:openstack@lists.openstack.org>>
Subject: Re: [Openstack] Bringing focus to the Operators and Users at the next 
summit


Thanks Sean. You and Thierry have made great points on this thread that I think 
give people more insight into the process and timing required to really impact 
the releases.

I've fallen into the trap many times of thinking we can solve any problem in 
the world during the 10 days a year we are all together, but in the end its 
only 10 days. No matter how you organize them, they don't any get longer.

So +1 for some activities well before the summit to gather input. I think Tim's 
suggestion makes a ton of sense.

IMHO we should also avoid the trap of thinking that for gatherings to be 
valuable "everyone has to be there". That's what leads back to thinking the 
summit weeks are the answer to everything. As Tim said, it's quite likely 
operators are experiencing a lot of the same pain points, so what is needed is 
critical mass and action, not every known user in one room (unrealistic). 
Perhaps with some online components where operators that couldn't make a meetup 
can weigh in (and give a weighted priority to a list?)



On Dec 23, 2013 6:35 AM, "Sean Dague" mailto:s...@dague.net>> 
wrote:
On 12/22/2013 12:49 PM, rob_hirschf...@dell.com 
wrote:
> I’d like to repeat a suggestion at the Design Summit wrap up – it’s a
> bit different, so patience…
>
>
>
> My suggestion was to insert a day “break” into the four day Design
> Summit for users/operations.  Effectively, we’d have a four day design
> summit with Monday+Tuesday  - break for user/ops conf –
> Thursday+Friday.  This would allow the developers and PTLs to join in
> the conference parts of the summit without needed a distinct event.
> The regular non-design conference could be held Tuesday-Thursday so
> there’s a specific overlap day when 100% of the community would be together.
>
>
>
> I felt like this allows ideas from the summit to be socialized with
> users/operator before we commit to them.  I also felt that it makes the
> developers more accessible.  Finally, it creates a break/reflection from
> the intensity of the design.
>
>
>
> To recap, 4 day design, 3 day user/ops conference spanning 5 days.

Honestly I'd be pretty -1 on that idea. There is a certain momentum that
builds inside the design summit sessions that 2 hard context switches
like that would really hurt. If you've ever spent time in the Nova track
you can see this in spades.

I think one of the missing things for folks that don't spend all their
time in Design Summit is realizing that DS is really the *middle* of the
conversation, not that start of one. I actually think this is where
folks new to design summit tend to flail a little be in their sessions.
My goals for design summit, and my tracks, were set weeks in advance,
and there was very little new here, it was mostly about working through
the sticky details on things we largely were already working on, and
exposing some of that work to a wider audience which drags in new
volunteers. So the User / Ops day at Summit is far too late to impact
that release cycle.

That interaction needs to come 3+ weeks before Design Summit to be
effective on that cycle. Because if it's later than that, it's just too
much to digest at a point where the plates are already overflowing. The
key developers are already about 200% booked at Summits at this point,
which is actually why *more* OpenStack PTLs spoke at LinuxCon NA this
year than at OpenStack Summit HK. For instance, I only wandered out side
of Design Summit twice, when I was on stage. And I didn't even get a
chance to go to any of the public parties, as I was booked every single
night at summit - weeks in advance.

So I think that all those folks are pretty open to getting more engaged
with Users / Ops (I know I am), but the existing Summit structure isn't
going to allow that. Making people 250% booked at Summit isn't going to
really be a successful way to handle this.

I'm far m

Re: [Openstack] Bringing focus to the Operators and Users at the next summit

2013-12-21 Thread Matt Van Winkle 
I'm torn.  I get the benefit of trying to do this at another event when a lot 
of folks will be there anyway, but at the same time, I think there are some 
pretty significant discussions we need to have, as operators, if we want to 
push Openstack to be what it can be.  If that's the case, I don’t' know that 
trying to fit a few talks, sessions or other short visits inside another event 
is going to do it justice.

>From the pain of large deploys, to the inability to run some services in a 
>redundant fashion to the lack of maintaining state when services restart, 
>there are a lot of areas we, as users, can give feedback to the TC and the 
>developers that will help make this product a viable competitor to other cloud 
>offerings (like EC2) out there.  It's not there right now, at least at scale, 
>and I think it's up to us to change the trend of development/thought from that 
>of building a cool private cloud technology to scaling the product to 10's of 
>thousands, 100's of thousands or millions of nodes.  A lot needs to be done to 
>make that happen.

Anyway, I think to accurately hash out the things we like to see for all this, 
we should find a time that we can get together for a couple days and discuss it 
all in detail without trying to stay focused on material from another 
conference.  That's my $.02 at least.  I'll gladly do what ever, but wanted to 
challenge this current thread about attaching this effort to another event a 
little.

Thanks a ton!
Matt

From: Sriram Subramanian mailto:sri...@sriramhere.com>>
Date: Saturday, December 21, 2013 4:17 PM
To: Clint Byrum mailto:cl...@fewbar.com>>
Cc: openstack 
mailto:openstack@lists.openstack.org>>
Subject: Re: [Openstack] Bringing focus to the Operators and Users at the next 
summit

OSCON  2014 is AFTER next OpenStack Summit - 
July 20 - 24, 2014.

SCALE is probably doable, with WIP proposals 
are due only on Jan 2nd.

-Sriram


On Sat, Dec 21, 2013 at 12:53 PM, Clint Byrum 
mailto:cl...@fewbar.com>> wrote:
Excerpts from Matthew Ray's message of 2013-12-20 20:22:20 -0800:
> Perhaps we could try to co-locate a future Operators mini-summit with
> FOSDEM or SCALE (February) and/or OSCON (July)? Events like those are
> conveniently scheduled between November and April and likely to already
> have OpenStack-related developers/deployers planning on attending. The
> logistics might not work for February, but we should start planning for the
> future.
>

OSCON is an ideal venue for this. Certainly we should approach the
organizers immediately as I'm sure plans are already solidifying.

For SCALE I think we may be too late, as the CFP has closed and it is
just 2 months away.

We're all busy, is there anybody who can step up and drive this?

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : 
openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack



--
Thanks,
-Sriram
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Bringing focus to the Operators and Users at the next summit

2013-12-20 Thread Matt Van Winkle 
Hey Tim and company,
I'm in!  I'd love to share the joys and pains of trying to deploy Openstack on 
thousands of nodes and get a common voice for the summit – especially from a 
public cloud perspective.  How can I (and I'm sure others here) help?

Thanks!
Matt

From: Anne Gentle mailto:a...@openstack.org>>
Date: Friday, December 20, 2013 3:21 PM
To: Tim Bell mailto:tim.b...@cern.ch>>
Cc: "mailto:openstack@lists.openstack.org>>" 
mailto:openstack@lists.openstack.org>>
Subject: Re: [Openstack] Bringing focus to the Operators and Users at the next 
summit

This is a fantastic idea. What can the TC do to help out?

Anne


On Fri, Dec 20, 2013 at 1:46 PM, Tim Bell 
mailto:tim.b...@cern.ch>> wrote:

How about we do a mid-summit user/operator boot camp (like the programs do, 
i.e. February or so) where:

- we get some operators and users (i.e. those that run and those that consume) 
OpenStack together
- we describe our pain points (as Tom would say curse/desk-slam/white-board)
- we prepare a set of blueprints and corresponding representatives to explain 
them to the development community
- we identify cross-project issues and take them to the TC

My experience is that there is significant overlap between us all so it is not 
necessary to have everyone there, especially if we solicit input before through 
the ambassadors etc.

Tim

On 20 Dec 2013, at 07:55, Tristan Goode 
mailto:tris...@aptira.com>> wrote:

> I guess the simplest meaning is "all those that are not committing code to
> the OpenStack code base"? :D
>
>
>> -Original Message-
>> From: Everett Toews 
>> [mailto:everett.to...@rackspace.com]
>> Sent: Wednesday, 18 December 2013 1:54 AM
>> To: Tristan Goode
>> Cc: Tom Fifield; 
>> mailto:openstack@lists.openstack.org>>
>> Subject: Re: [Openstack] Bringing focus to the Operators and Users at
> the next
>> summit
>>
>> Hi Tristan,
>>
>> Can you clarify what you meant by Users in your subject line?
>>
>> I took it to mean application developers (i.e. the developers writing
> applications on
>> top of OpenStack) and possibly application operators (i.e. the operators
> deploying
>> applications on top of OpenStack). They seem to have gotten lost in the
> discussion
>> here.
>>
>> Ultimately, OpenStack is being built for them. As I believe was your
> original intent,
>> they need a voice in such a forum too. I realize that even less
> application developers
>> are likely to attend the summit than operators.
>>
>> However we still need to encourage their involvement and make a place
> for them.
>> We also need to encourage operators to gather feedback from their
> application
>> developers about their experiences developer on top of OpenStack as I'm
> sure the
>> operations folk get an occasional ear full from them. ;)
>>
>> Thanks,
>> Everett
>>
>> P.S. Just to be clear...because we have a lot of overlapping
> terminology.
>>
>> application developers = the developers writing applications on top of
> OpenStack
>> application operators = the operators deploying applications on top of
> OpenStack
>> [OpenStack] developers = the developers writing OpenStack [OpenStack]
> operators
>> = the developers deploying OpenStack
>>
>>
>> On Dec 17, 2013, at 3:24 AM, Tristan Goode wrote:
>>
>>> Perfect stated Tom. Thank you.
>>>
 -Original Message-
 From: Tom Fifield [mailto:t...@openstack.org]
 Sent: Tuesday, 17 December 2013 11:23 AM
 To: openstack@lists.openstack.org
 Subject: Re: [Openstack] Bringing focus to the Operators and Users at
>>> the next
 summit

 On 17/12/13 02:55, Tim Bell wrote:
>
>
> Specifying something as a bug needs to determine things like 'what
> component should this be addressed in' and describing the desired
> behaviour. Many of the comments from the survey describe the pain
> points, rather than the solutions. Upgrading is difficult, no
> mechanism to auto restart VMs on other hypervisors, monitoring
> frameworks, inconsistent options in command line tools and APIs, .
> equally, missing functional gaps do not fall well into the bug
> system.
>
>
>
> I have received the feedback from operators when raising issues that
> they get the response 'contributions are welcome'. Running an
> openstack cloud can be non-trivial, especially the big ones, and
> there is a need to appreciate that this effort is a significant part
> of the OpenStack community effort (along with the blogs, the
> documentation updates, the summit presentations).
>
>
>
> I personally have a different proposal to Tristan (although I like
> his). my proposal is that each program should have a session
> dedicated to user/operator needs at the start.  Between the UC, the
> volunteers to look at the survey comments and the user group
> ambassadors, we should be able to put together a se