[openstack-dev] [neutron][ml2] How to get compute host details

[Harshada Kakad]

Hi All,

I am developing ml2 driver and I want compute host details while creation
of ports. I mean to say is, I have multi node setup and when I launch VM I
want to get deatils on which compute node does this VM got launced while
creation of ports. Can anyone please help me on this.

Thanks in Advance.

-- 
*Regards,*
*Harshada Kakad*
**
*Sr. Software Engineer*
*C3/101, Saudamini Complex, Right Bhusari Colony, Paud Road, Pune – 411013,
India*
*Mobile-9689187388*
*Email-Id : harshada.ka...@izeltech.com *
*website : www.izeltech.com *

-- 
*Disclaimer*
The information contained in this e-mail and any attachment(s) to this 
message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information of Izel 
Technologies Pvt. Ltd. If you are not the intended recipient, you are 
notified that any review, use, any form of reproduction, dissemination, 
copying, disclosure, modification, distribution and/or publication of this 
e-mail message, contents or its attachment(s) is strictly prohibited and 
you are requested to notify us the same immediately by e-mail and delete 
this mail immediately. Izel Technologies Pvt. Ltd accepts no liability for 
virus infected e-mail or errors or omissions or consequences which may 
arise as a result of this e-mail transmission.
*End of Disclaimer*
__
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] [Product] [all][log] Openstack HTTP error codes

[Christopher Yeoh]

On Sun, Feb 1, 2015 at 2:57 AM, Sean Dague  wrote:

> On 01/31/2015 05:24 AM, Duncan Thomas wrote:
> > Hi
> >
> > This discussion came up at the cinder mid-cycle last week too,
> > specifically in the context of 'Can we change the details text in an
> > existing error, or is that an unacceptable API change'.
> >
> > I have to second security / operational concerns about exposing too much
> > granularity of failure in these error codes.
> >
> > For cases where there is something wrong with the request (item out of
> > range, invalid names, feature not supported, etc) I totally agree that
> > we should have good, clear, parsable response, and standardisation would
> > be good. Having some fixed part of the response (whether a numeric code
> > or, as I tend to prefer, a CamelCaseDescription so that I don't have to
> > go look it up) and a human readable description section that is subject
> > to change seems sensible.
> >
> > What I would rather not see is leakage of information when something
> > internal to the cloud goes wrong, that the tenant can do nothing
> > against. We certainly shouldn't be leaking internal implementation
> > details like vendor details - that is what request IDs and logs are for.
> > The whole point of the cloud, to me, is that separation between the
> > things a tenant controls (what they want done) and what the cloud
> > provider controls (the details of how the work is done).
> >
> > For example, if a create volume request fails because cinder-scheduler
> > has crashed, all the tenant should get back is 'Things are broken, try
> > again later or pass request id 1234-5678-abcd-def0 to the cloud admin'.
> > They should need to or even be allowed to care about the details of the
> > failure, it is not their domain.
>
> Sure, the value really is in determining things that are under the
> client's control to do differently. A concrete one is a multi hypervisor
> cloud with 2 hypervisors (say kvm and docker). The volume attach
> operation to a docker instance (which presumably is a separate set of
> instance types) can't work. The user should be told that that can't work
> with this instance_type if they try it.
>
> That's actually user correctable information. And doesn't require a
> ticket to move forward.
>
> I also think we could have a detail level knob, because I expect the
> level of information exposure might be considered different in public
> cloud use case vs. a private cloud at an org level or a private cloud at
> a dept level.
>
>
That could turn into a major compatibility issue if what we returned could
(and
probably would between public/private) change between clouds? If we want to
encourage
people to parse this sort of thing I think we need to settle on whether we
send the
information back or not for everyone.


> -Sean
>
> >
> >
> >
> > On 30 January 2015 at 02:34, Rochelle Grober  > > wrote:
> >
> > Hi folks!
> >
> > Changed the tags a bit because this is a discussion for all projects
> > and dovetails with logging rationalization/standards/
> >
> > At the Paris summit, we had a number of session on logging that kept
> > circling back to Error Codes.  But, these codes would not be http
> > codes, rather, as others have pointed out, codes related to the
> > calling entities and referring entities and the actions that
> > happened or didn’t.  Format suggestions were gathered from the
> > Operators and from some senior developers.  The Logging Working
> > Group is planning to put forth a spec for discussion on formats and
> > standards before the Ops mid-cycle meetup.
> >
> > Working from a Glance proposal on error codes:
> > https://review.openstack.org/#/c/127482/ and discussions with
> > operators and devs, we have a strawman to propose.  We also have a
> > number of requirements from Ops and some Devs.
> >
> > Here is the basic idea:
> >
> > Code for logs would have four segments:
> > Project Vendor/Component  Error
> > Catalog number Criticality
> > Def [A-Z] [A-Z] [A-Z]   -
> > [{0-9}|{A-Z}][A-Z] - [-]-   [0-9]
> > Ex.  CIN-   NA-
> >   0001-
> >2
> > Cinder   NetApp
> >   driver error no
> >   Criticality
> > Ex.  GLA-  0A-
> >0051
> >  3
> > Glance  Api
> >error no
> >  Criticality
> > Three letters for project,  Either a two letter vendor code or a
> > number and letter for 0+letter for internal component of project
> > (like API=0A, Controller =0C, etc),  four d

Re: [openstack-dev] [api][nova] Openstack HTTP error codes

[Ken'ichi Ohmichi]

2015-01-30 18:13 GMT+09:00 Simon Pasquier :
> On Fri, Jan 30, 2015 at 3:05 AM, Kenichi Oomichi 
> wrote:
>>
>> > -Original Message-
>> > From: Roman Podoliaka [mailto:rpodoly...@mirantis.com]
>> > Sent: Friday, January 30, 2015 2:12 AM
>> > To: OpenStack Development Mailing List (not for usage questions)
>> > Subject: Re: [openstack-dev] [api][nova] Openstack HTTP error codes
>> >
>> > Hi Anne,
>> >
>> > I think Eugeniya refers to a problem, that we can't really distinguish
>> > between two different  badRequest (400) errors (e.g. wrong security
>> > group name vs wrong key pair name when starting an instance), unless
>> > we parse the error description, which might be error prone.
>>
>> Yeah, current Nova v2 API (not v2.1 API) returns inconsistent messages
>> in badRequest responses, because these messages are implemented at many
>> places. But Nova v2.1 API can return consistent messages in most cases
>> because its input validation framework generates messages
>> automatically[1].
>
>
> When you say "most cases", you mean JSON schema validation only, right?
> IIUC, this won't apply to the errors described by the OP such as invalid key
> name, unknown security group, ...

Yeah, right.
I implied that in "most cases" and I have one patch[1] for covering them.
By the patch, the sample messages also will be based on the same
format and be consistent.
The other choice we have is CamelCase exception as the fist mail, that
also is interesting.

Thanks
Ken Ohmichi

---
[1]: https://review.openstack.org/#/c/151954

__
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 Foundation] Finding people to work on the EC2 API in Nova

[Michael Still]

So, its exciting to me that we seem to developing more forward
momentum here. I personally think the way forward is a staged
transition from the in-nova EC2 API to the stackforge project, with
testing added to ensure that we are feature complete between the two.
I note that Soren disagrees with me here, but that's ok -- I'd like to
see us work through that as a team based on the merits.

So... It sounds like we have an EC2 sub team forming. How do we get
that group meeting to come up with a transition plan?

Michael

On Sun, Feb 1, 2015 at 4:12 AM, Davanum Srinivas  wrote:
> Alex,
>
> Very cool. thanks.
>
> -- dims
>
> On Sat, Jan 31, 2015 at 1:04 AM, Alexandre Levine
>  wrote:
>> Davanum,
>>
>> Now that the picture with the both EC2 API solutions has cleared up a bit, I
>> can say yes, we'll be adding the tempest tests and doing devstack
>> integration.
>>
>> Best regards,
>>   Alex Levine
>>
>> On 1/31/15 2:21 AM, Davanum Srinivas wrote:
>>>
>>> Alexandre, Randy,
>>>
>>> Are there plans afoot to add support to switch on stackforge/ec2-api
>>> in devstack? add tempest tests etc? CI Would go a long way in
>>> alleviating concerns i think.
>>>
>>> thanks,
>>> dims
>>>
>>> On Fri, Jan 30, 2015 at 1:24 PM, Bias, Randy  wrote:

 As you know we have been driving forward on the stack forge project and
 it¹s our intention to continue to support it over time, plus reinvigorate
 the GCE APIs when that makes sense. So we¹re supportive of deprecating
 from Nova to focus on EC2 API in Nova.  I also think it¹s good for these
 APIs to be able to iterate outside of the standard release cycle.



 --Randy

 VP, Technology, EMC Corporation
 Formerly Founder & CEO, Cloudscaling (now a part of EMC)
 +1 (415) 787-2253 [google voice]
 TWITTER: twitter.com/randybias
 LINKEDIN: linkedin.com/in/randybias
 ASSISTANT: ren...@emc.com






 On 1/29/15, 4:01 PM, "Michael Still"  wrote:

> Hi,
>
> as you might have read on openstack-dev, the Nova EC2 API
> implementation is in a pretty sad state. I wont repeat all of those
> details here -- you can read the thread on openstack-dev for detail.
>
> However, we got here because no one is maintaining the code in Nova
> for the EC2 API. This is despite repeated calls over the last 18
> months (at least).
>
> So, does the Foundation have a role here? The Nova team has failed to
> find someone to help us resolve these issues. Can the board perhaps
> find resources as the representatives of some of the largest
> contributors to OpenStack? Could the Foundation employ someone to help
> us our here?
>
> I suspect the correct plan is to work on getting the stackforge
> replacement finished, and ensuring that it is feature compatible with
> the Nova implementation. However, I don't want to preempt the design
> process -- there might be other ways forward here.
>
> I feel that a continued discussion which just repeats the last 18
> months wont actually fix the situation -- its time to "break out" of
> that mode and find other ways to try and get someone working on this
> problem.
>
> Thoughts welcome.
>
> Michael
>
> --
> Rackspace Australia
>
> ___
> Foundation mailing list
> foundat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation



 __
 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
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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



-- 
Rackspace Australia

__
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] [Cinder][nova] Cinder backend for ephemeral disks?

[Michael Still]

It looks like this was never re-proposed for Kilo. I am open to it
being proposed for L* when that release opens for specs soon, but we
need a developer to be advocating for it.

Michael

On Sun, Feb 1, 2015 at 5:22 PM, Adam Lawson  wrote:
> Question, looks like this spec was abandoned , hard to tell if it is being
> addressed elsewhere? Good idea that received a -2 then ultimately abandoned
> sure to juno freeze I think.
>
> https://blueprints.launchpad.net/nova/+spec/nova-ephemeral-cinder
>
>
> __
> 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
>



-- 
Rackspace Australia

__
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] [Product] [all][log] Openstack HTTP error codes

[Morgan Fainberg]

Putting on my "sorry-but-it-is-my-job-to-get-in-your-way" hat (aka security), 
let's be careful how generous we are with the user and data we hand back. It 
should give enough information to be useful but no more. I don't want to see us 
opened to weird attack vectors because we're exposing internal state too 
generously. 

In short let's aim for a slow roll of extra info in, and evaluate each data 
point we expose (about a failure) before we do so. Knowing more about a failure 
is important for our users. Allowing easy access to information that could be 
used to attack / increase impact of a DOS could be bad. 

I think we can do it but it is important to not swing the pendulum too far the 
other direction too fast (give too much info all of a sudden). 

--Morgan

Sent via mobile

> On Jan 31, 2015, at 08:57, James E. Blair  wrote:
> 
> Sean Dague  writes:
> 
>>> On 01/31/2015 05:24 AM, Duncan Thomas wrote:
>>> What I would rather not see is leakage of information when something
>>> internal to the cloud goes wrong, that the tenant can do nothing
>>> against. We certainly shouldn't be leaking internal implementation
>>> details like vendor details - that is what request IDs and logs are for.
>>> The whole point of the cloud, to me, is that separation between the
>>> things a tenant controls (what they want done) and what the cloud
>>> provider controls (the details of how the work is done).
>> 
>> Sure, the value really is in determining things that are under the
>> client's control to do differently. A concrete one is a multi hypervisor
>> cloud with 2 hypervisors (say kvm and docker). The volume attach
>> operation to a docker instance (which presumably is a separate set of
>> instance types) can't work. The user should be told that that can't work
>> with this instance_type if they try it.
> 
> I agree that we should find the right balance.  Some anecdata from
> infra-as-a-user: we have seen OpenStack sometimes unable to allocate a
> public IP address for our servers when we cycle them too quickly with
> nodepool.  That shows up as an opaque error for us, and it's only by
> chatting with the operators that we know what's going on, yet, there
> might be things we can do to reduce the occurrence (like rebuild nodes
> instead of destroying them; delay before creating again; etc.).
> 
> So I would suggest that when we search for the sweet spot of how much
> detail to include, we be somewhat generous with the user, who after all,
> is likely to be technically competent and frustrated if they are
> replacing systems that they can control and diagnose with a black box
> that has a habit of saying "no" at random times for no discernible
> reason.
> 
> -Jim
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] contribute

[Christopher Aedo]

Assaf, really good advice for getting started here.

Once you've absorbed the workings of the project you're interested in
contributing to, take a look here for guidelines on how to submit code
for review: https://wiki.openstack.org/wiki/How_To_Contribute

Also linked from that wiki page are more details on the actual workflow:
http://docs.openstack.org/infra/manual/developers.html#development-workflow

IRC is a great place to get quick help if you get stuck too, so don't
be shy.  Welcome to OpenStack!

-Christopher

On Sun, Feb 1, 2015 at 6:45 AM, Assaf Muller  wrote:
>
>
> - Original Message -
>> hello folks,
>> myself shailendra, i am willing to contribute in openstack. i am final year
>> student of B.Tech and have sufficient skills to do some here. plz guide me
>>
>
> Take a look at the different OpenStack projects. Is there a field you're more
> interested in? Compute, networking, storage, etc? Do you have a background
> in any of these fields?
>
> If you've found something that looks nice, I'd start by setting up devstack
> and reading up all of the documentation of that project. Once you 
> kind-of-sort-of
> understand *what* is that project supposed to be doing, and you've played with
> a devstack installation sufficiently to your liking (You can create a VM,
> you understand most major portions of the UI and what's everything supposed
> to be doing. i.e. what's a router and what's a volume) I would start looking
> at your project's code. You can find the project's IRC channel and ask if
> there are any good beginner bugs. You can look for bugs tagged with low 
> hanging
> fruit. You can help with the project's testing efforts (Add coverage, add
> functional tests, add tests in Tempest).
>
> Good luck!
>
>> thanks
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [nova][libvirt] RFC: ensuring live migration ends

[Robert Collins]

On 31 January 2015 at 05:47, Daniel P. Berrange  wrote:
> In working on a recent Nova migration bug
>
>   https://bugs.launchpad.net/nova/+bug/1414065
>
> I had cause to refactor the way the nova libvirt driver monitors live
> migration completion/failure/progress. This refactor has opened the
> door for doing more intelligent active management of the live migration
> process.
...
> What kind of things would be the biggest win from Operators' or tenants'
> POV ?

Awesome. Couple thoughts from my perspective. Firstly, there's a bunch
of situation dependent tuning. One thing Crowbar does really nicely is
that you specify the host layout in broad abstract terms - e.g. 'first
10G network link' and so on : some of your settings above like whether
to compress page are going to be heavily dependent on the bandwidth
available (I doubt that compression is a win on a 100G link for
instance, and would be suspect at 10G even). So it would be nice if
there was a single dial or two to set and Nova would auto-calculate
good defaults from that (with appropriate overrides being available).

Operationally avoiding trouble is better than being able to fix it, so
I quite like the idea of defaulting the auto-converge option on, or
perhaps making it controllable via flavours, so that operators can
offer (and identify!) those particularly performance sensitive
workloads rather than having to guess which instances are special and
which aren't.

Being able to cancel the migration would be good. Relatedly being able
to restart nova-compute while a migration is going on would be good
(or put differently, a migration happening shouldn't prevent a deploy
of Nova code: interlocks like that make continuous deployment much
harder).

If we can't already, I'd like as a user to be able to see that the
migration is happening (allows diagnosis of transient issues during
the migration). Some ops folk may want to hide that of course.

I'm not sure that automatically rolling back after N minutes makes
sense : if the impact on the cluster is significant then 1 minute vs
10 doesn't instrinsically matter: what matters more is preventing too
many concurrent migrations, so that would be another feature that I
don't think we have yet: don't allow more than some N inbound and M
outbound live migrations to a compute host at any time, to prevent IO
storms. We may want to log with NOTIFICATION migrations that are still
progressing but appear to be having trouble completing. And of course
an admin API to query all migrations in progress to allow API driven
health checks by monitoring tools - which gives the power to manage
things to admins without us having to write a probably-too-simple
config interface.

HTH,
Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [nova][libvirt] RFC: ensuring live migration ends

[Noel Burton-Krahn]

Thanks for bringing this up, Daniel.  I don't think it makes sense to have
a timeout on live migration, but operators should be able to cancel it,
just like any other unbounded long-running process.  For example, there's
no timeout on file transfers, but they need an interface report progress
and to cancel them.  That would imply an option to cancel evacuation too.

--
Noel


On Fri, Jan 30, 2015 at 8:47 AM, Daniel P. Berrange 
wrote:

> In working on a recent Nova migration bug
>
>   https://bugs.launchpad.net/nova/+bug/1414065
>
> I had cause to refactor the way the nova libvirt driver monitors live
> migration completion/failure/progress. This refactor has opened the
> door for doing more intelligent active management of the live migration
> process.
>
> As it stands today, we launch live migration, with a possible bandwidth
> limit applied and just pray that it succeeds eventually. It might take
> until the end of the universe and we'll happily wait that long. This is
> pretty dumb really and I think we really ought to do better. The problem
> is that I'm not really sure what "better" should mean, except for ensuring
> it doesn't run forever.
>
> As a demo, I pushed a quick proof of concept showing how we could easily
> just abort live migration after say 10 minutes
>
>   https://review.openstack.org/#/c/151665/
>
> There are a number of possible things to consider though...
>
> First how to detect when live migration isn't going to succeeed.
>
>  - Could do a crude timeout, eg allow 10 minutes to succeeed or else.
>
>  - Look at data transfer stats (memory transferred, memory remaining to
>transfer, disk transferred, disk remaining to transfer) to determine
>if it is making forward progress.
>
>  - Leave it upto the admin / user to decided if it has gone long enough
>
> The first is easy, while the second is harder but probably more reliable
> and useful for users.
>
> Second is a question of what todo when it looks to be failing
>
>  - Cancel the migration - leave it running on source. Not good if the
>admin is trying to evacuate a host.
>
>  - Pause the VM - make it complete as non-live migration. Not good if
>the guest workload doesn't like being paused
>
>  - Increase the bandwidth permitted. There is a built-in rate limit in
>QEMU overridable via nova.conf. Could argue that the admin should just
>set their desired limit in nova.conf and be done with it, but perhaps
>there's a case for increasing it in special circumstances. eg emergency
>evacuate of host it is better to waste bandwidth & complete the job,
>but for non-urgent scenarios better to limit bandwidth & accept failure
> ?
>
>  - Increase the maximum downtime permitted. This is the small time window
>when the guest switches from source to dest. To small and it'll never
>switch, too large and it'll suffer unacceptable interuption.
>
> We could do some of these things automatically based on some policy
> or leave them upto the cloud admin/tenant user via new APIs
>
> Third there's question of other QEMU features we could make use of to
> stop problems in the first place
>
>  - Auto-converge flag - if you set this QEMU throttles back the CPUs
>so the guest cannot dirty ram pages as quickly. This is nicer than
>pausing CPUs altogether, but could still be an issue for guests
>which have strong performance requirements
>
>  - Page compression flag - if you set this QEMU does compression of
>pages to reduce data that has to be sent. This is basically trading
>off network bandwidth vs CPU burn. Probably a win unless you are
>already highly overcomit on CPU on the host
>
> Fourth there's a question of whether we should give the tenant user or
> cloud admin further APIs for influencing migration
>
>  - Add an explicit API for cancelling migration ?
>
>  - Add APIs for setting tunables like downtime, bandwidth on the fly ?
>
>  - Or drive some of the tunables like downtime, bandwidth, or policies
>like cancel vs paused from flavour or image metadata properties ?
>
>  - Allow operations like evacuate to specify a live migration policy
>eg switch non-live migrate after 5 minutes ?
>
> The current code is so crude and there's a hell of alot of options we
> can take. I'm just not sure which is the best direction for us to go
> in.
>
> What kind of things would be the biggest win from Operators' or tenants'
> POV ?
>
> Regards,
> Daniel
> --
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org  -o- http://virt-manager.org
> :|
> |: http://autobuild.org   -o- http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
> :|
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>

Re: [openstack-dev] contribute

[Assaf Muller]

- Original Message -
> hello folks,
> myself shailendra, i am willing to contribute in openstack. i am final year
> student of B.Tech and have sufficient skills to do some here. plz guide me
> 

Take a look at the different OpenStack projects. Is there a field you're more
interested in? Compute, networking, storage, etc? Do you have a background
in any of these fields?

If you've found something that looks nice, I'd start by setting up devstack
and reading up all of the documentation of that project. Once you 
kind-of-sort-of
understand *what* is that project supposed to be doing, and you've played with
a devstack installation sufficiently to your liking (You can create a VM,
you understand most major portions of the UI and what's everything supposed
to be doing. i.e. what's a router and what's a volume) I would start looking
at your project's code. You can find the project's IRC channel and ask if
there are any good beginner bugs. You can look for bugs tagged with low hanging
fruit. You can help with the project's testing efforts (Add coverage, add
functional tests, add tests in Tempest).

Good luck!

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

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

[openstack-dev] contribute

[shailendra acharya]

hello folks,
   myself shailendra, i am willing to contribute in openstack.
i am final year student of B.Tech and have sufficient skills to do some
here. plz guide me

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