Re: [openstack-dev] [all] We're combining the lists!

[Robert Collins]

On Sat, 10 Nov 2018 at 07:15, Jeremy Stanley  wrote:
>
> REMINDER: The openstack, openstack-dev, openstack-sigs and
> openstack-operators mailing lists (to which this is being sent) will
> be replaced by a new openstack-disc...@lists.openstack.org mailing
> list. The new list is open for subscriptions[0] now, but is not yet
> accepting posts until Monday November 19 and it's strongly
> recommended to subscribe before that date so as not to miss any
> messages posted there. The old lists will be configured to no longer
> accept posts starting on Monday December 3, but in the interim posts
> to the old lists will also get copied to the new list so it's safe
> to unsubscribe from them any time after the 19th and not miss any
> messages. See my previous notice[1] for details.
>
> For those wondering, we have 207 subscribers so far on
> openstack-discuss with a little over a week to go before it will be
> put into use (and less than a month before the old lists are closed
> down for good).

There don't seem to be any topics defined for -discuss yet, I hope
there will be, as I'm certainly not in a position of enough bandwidth
to handle everything *stack related.

I'd suggest one for each previously list, at minimum.

-Rob

__
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] [tripleo] TripleO CI Summary: Sprint 21

[Rafael Folco]

Greetings,

The TripleO CI team has just completed Sprint 21 (Oct-18 thru Nov-07).
The following is a summary of completed work during this sprint cycle:

   -

   Created an initial base Standalone job for Fedora 28.
   -

   Added initial support for installing Tempest rpm in
   openstack-ansible_os-tempest.
   -

   Started running project specific tempest tests against puppet-projects
   in tripleo-standalone gates.
   -

   Added initial support to python-tempestconf on
   openstack-ansible_os-tempest.
   -

   Prepared grounds to make all required variables for the zuulv3 workflow
   available for the reproducer.


The sprint task board for CI team has moved from Trello to Taiga [1]. The
Ruck and Rover notes for this sprint has been tracked in the etherpad [2].

The planned work for the next sprint focuses in iterating on the upstream
standalone job for Fedora 28 to bring it to completion. This includes
moving the multinode scenarios to the standalone jobs. The team continues
to work on the reproducer, enabling Tempest coverage in puppet-* projects,
and preparing a CI environment for OVB.

The Ruck and Rover for this sprint are Gabriele Cerami (panda) and Chandan
Kumar (chkumar). Please direct questions or queries to them regarding CI
status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on
their nick.

Thanks,

Folco

[1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/sprint-21-175

[2] https://review.rdoproject.org/etherpad/p/ruckrover-sprint21
__
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-operators] [all] We're combining the lists!

[Jeremy Stanley]

REMINDER: The openstack, openstack-dev, openstack-sigs and
openstack-operators mailing lists (to which this is being sent) will
be replaced by a new openstack-disc...@lists.openstack.org mailing
list. The new list is open for subscriptions[0] now, but is not yet
accepting posts until Monday November 19 and it's strongly
recommended to subscribe before that date so as not to miss any
messages posted there. The old lists will be configured to no longer
accept posts starting on Monday December 3, but in the interim posts
to the old lists will also get copied to the new list so it's safe
to unsubscribe from them any time after the 19th and not miss any
messages. See my previous notice[1] for details.

For those wondering, we have 207 subscribers so far on
openstack-discuss with a little over a week to go before it will be
put into use (and less than a month before the old lists are closed
down for good).

[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
-- 
Jeremy Stanley


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

Re: [Openstack] [all] We're combining the lists!

[Jeremy Stanley]

REMINDER: The openstack, openstack-dev, openstack-sigs and
openstack-operators mailing lists (to which this is being sent) will
be replaced by a new openstack-disc...@lists.openstack.org mailing
list. The new list is open for subscriptions[0] now, but is not yet
accepting posts until Monday November 19 and it's strongly
recommended to subscribe before that date so as not to miss any
messages posted there. The old lists will be configured to no longer
accept posts starting on Monday December 3, but in the interim posts
to the old lists will also get copied to the new list so it's safe
to unsubscribe from them any time after the 19th and not miss any
messages. See my previous notice[1] for details.

For those wondering, we have 207 subscribers so far on
openstack-discuss with a little over a week to go before it will be
put into use (and less than a month before the old lists are closed
down for good).

[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
___
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-dev] [manila] [contribute]

[Leni Kadali Mutungi]

Hi all

Thanks Sofia, Tom and Goutham for responding. Will checkout all the 
links you've shared.


On 11/9/18 12:32 PM, Tom Barron wrote:

On 08/11/18 11:07 -0300, Sofia Enriquez wrote:

Hi Leni, welcome!

1) Devstack[1] plays a *main *role in the development workflow.
It's an easier way to get a full environment to work in Manila, we use it
every day. I recommend you to use it in a VM.
You can find many tutorials about how to use Devstack, I just let you one
[2]


Nice blog/guide, Sofia!  I'll just add [4] as a followup for anyone 
particularly wanting to install devstack with manila and a cephfs with 
nfs back end.




2) I can't find *low-hanging-fruit* bugs in Manila. However,
good-first-bugs are tagged as *low-hanging-fruit *for example, 
cinder's[3]


And Goutham followed up with some manila low-hanging-fruit too. Thanks, 
Goutham!




Today at *15:00 UTC *It's  Weekly Manila Team Meeting at IRC (channel
#openstack-meeting-alt) on Freenode.


And as we may have mentioned, you can ask questions on irc [5] [6]
#openstack-manila any time.  Ask even if no one is responding right 
then, most of us have bouncers and will see and get back to you.


-- Tom Barron

[4] https://github.com/tombarron/vagrant-libvirt-devstack

[5] https://docs.openstack.org/contributors/common/irc.html

[6] https://docs.openstack.org/infra/manual/irc.html



Have fun!
Sofia
irc: enriquetaso
[1]
https://docs.openstack.org/zun/latest/contributor/quickstart.html#exercising-the-services-using-devstack 


[2]
https://enriquetaso.wordpress.com/2016/05/07/installing-devstack-on-a-vagrant-virtual-machine/ 


[3] https://bugs.launchpad.net/cinder/+bugs?field.tag=low-hanging-fruit

On Thu, Nov 8, 2018 at 7:41 AM Leni Kadali Mutungi 


wrote:


Hi Tom

Thanks for the warm welcome. I've gone through the material and I would
like to understand a few things:

1. What's the role of devstack in the development workflow?
2. Where can I find good-first-bugs? A bug that is simple to do
(relatively ;)) and allows me to practice what I've read up on in
Developer's Guide. I looked through the manila bugs on Launchpad but I
didn't see anything marked easy or good-first-bug or its equivalent for
manila. I am a bit unfamiliar with Launchpad so that may have played a
role :).

Your guidance is appreciated.

On 10/19/18 5:55 PM, Tom Barron wrote:
> On 19/10/18 15:27 +0300, Leni Kadali Mutungi wrote:
>> Hi all.
>>
>> I've downloaded the manila project from GitHub as a zip file, 
unpacked

>> it and have run `git fetch --depth=1` and been progressively running
>> `git fetch --deepen=5` to get the commit history I need. For future
>> reference, would a shallow clone e.g. `git clone depth=1` be 
enough to

>> start working on the project or should one have the full commit
>> history of the project?
>>
>> --
>> -- Kind regards,
>> Leni Kadali Mutungi
>
> Hi Leni,
>
> First I'd like to extend a warm welcome to you as a new manila project
> contributor!  We have some contributor/developer documentation [1] 
that
> you may find useful. If you find any gaps or misinformation, we 
will be

> happy to work with you to address these.  In addition to this email
> list, the #openstack-manila IRC channel on freenode is a good place to
> ask questions.  Many of us run irc bouncers so we'll see the question
> even if we're not looking right when it is asked.  Finally, we have a
> meeting most weeks on Thursdays at 1500UTC in 
#openstack-meeting-alt --

> agendas are posted here [2].  Also, here is our work-plan for the
> current Stein development cycle [3].
>
> Now for your question about shallow clones.  I hope others who know 
more

> will chime in but here are my thoughts ...
>
> Although having the full commit history for the project is useful, 
it is

> certainly possible to get started with a shallow clone of the project.
> That said, I'm not sure if the space and download-time/bandwidth gains
> are going to be that significant because once you have the 
workspace you

> will want to run unit tests, pep8, etc. using tox as explained in the
> developer documentation mentioned earlier.   That will download 
virtual

> environments for manila's dependencies in your workspace (under .tox
> directory) that dwarf the space used for manila proper.
>
> $ git clone --depth=1 g...@github.com:openstack/manila.git 
shallow-manila

> Cloning into 'shallow-manila'...
> ...
> $ git clone g...@github.com:openstack/manila.git deep-manila
> Cloning into 'deep-manila'...
> ...
> $ du -sh shallow-manila deep-manila/
> 20M    shallow-manila
> 35M    deep-manila/
>
> But after we run tox inside shallow-manila and deep-manila we see:
>
> $ du -sh shallow-manila deep-manila/
> 589M    shallow-manila
> 603M    deep-manila/
>
> Similarly, you are likely to want to run devstack locally and that 
will

> clone the repositories for the other openstack components you need and
> the savings from shallow clones won't be that significant relative to
> the total needed.
>
> Happy developing!
>
> 

Re: [openstack-dev] [all] We're combining the lists!

[Jeremy Stanley]

REMINDER: The openstack, openstack-dev, openstack-sigs and
openstack-operators mailing lists (to which this is being sent) will
be replaced by a new openstack-disc...@lists.openstack.org mailing
list. The new list is open for subscriptions[0] now, but is not yet
accepting posts until Monday November 19 and it's strongly
recommended to subscribe before that date so as not to miss any
messages posted there. The old lists will be configured to no longer
accept posts starting on Monday December 3, but in the interim posts
to the old lists will also get copied to the new list so it's safe
to unsubscribe from them any time after the 19th and not miss any
messages. See my previous notice[1] for details.

For those wondering, we have 207 subscribers so far on
openstack-discuss with a little over a week to go before it will be
put into use (and less than a month before the old lists are closed
down for good).

[0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [cyborg] [weekly-meeting] No Weekly Meeting Next week

[Li Liu]

Hi Team,

There is no weekly meeting for the week of Nov 12th due to the OpenStack
Summit.

-- 
Thank you

Regards

Li
__
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] [TripleO] No meeting next week for the security squad

[Juan Antonio Osorio Robles]

There will be no meeting for the security squad next Tuesday 13th of November 
since there's the
OpenStack summit.


Best Regards


__
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] [TripleO] No weekly meeting next week

[Juan Antonio Osorio Robles]

There will be no meeting next Tuesday 13th of November since there's the
OpenStack summit.


Best Regards


__
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][cinder] about unified limits

[Lance Bragstad]

Sending a follow up here since there has been some movement on this
recently.

There is a nova specification up for review that goes through the work to
consume unified limits out of keystone [0]. John and Jay have also been
working through the oslo.limit integration, which is forcing us to think
about the interface. There are a few patches up that take different
approaches [1][2].

If anyone is still interested in helping out with this work, please don't
hesitate to reach out.

[0] https://review.openstack.org/#/c/602201/
[1] https://review.openstack.org/#/c/615180/
[2]
https://review.openstack.org/#/q/project:openstack/oslo.limit+status:open

On Tue, Sep 11, 2018 at 8:10 AM Lance Bragstad  wrote:

> Extra eyes on the API would be appreciated. We're also close to the point
> where we can start incorporating oslo.limit into services, so preparing
> those changes might be useful, too.
>
> One of the outcomes from yesterday's session was that Jay and Mel (from
> nova) were going to work out some examples we could use to finish up the
> enforcement code in oslo.limit. Helping out with that or picking it up
> would certainly help move the ball forward in nova.
>
>
>
>
> On Tue, Sep 11, 2018 at 1:15 AM Jaze Lee  wrote:
>
>> I recommend li...@unitedstack.com to join in to help to work forward.
>> May be first we should the keystone unified limits api really ok or
>> something else ?
>>
>> Lance Bragstad  于2018年9月8日周六 上午2:35写道：
>> >
>> > That would be great! I can break down the work a little bit to help
>> describe where we are at with different parts of the initiative. Hopefully
>> it will be useful for your colleagues in case they haven't been closely
>> following the effort.
>> >
>> > # keystone
>> >
>> > Based on the initial note in this thread, I'm sure you're aware of
>> keystone's status with respect to unified limits. But to recap, the initial
>> implementation landed in Queens and targeted flat enforcement [0]. During
>> the Rocky PTG we sat down with other services and a few operators to
>> explain the current status in keystone and if either developers or
>> operators had feedback on the API specifically. Notes were captured in
>> etherpad [1]. We spent the Rocky cycle fixing usability issues with the API
>> [2] and implementing support for a hierarchical enforcement model [3].
>> >
>> > At this point keystone is ready for services to start consuming the
>> unified limits work. The unified limits API is still marked as stable and
>> it will likely stay that way until we have at least one project using
>> unified limits. We can use that as an opportunity to do a final flush of
>> any changes that need to be made to the API before fully supporting it. The
>> keystone team expects that to be a quick transition, as we don't want to
>> keep the API hanging in an experimental state. It's really just a safe
>> guard to make sure we have the opportunity to use it in another service
>> before fully committing to the API. Ultimately, we don't want to
>> prematurely mark the API as supported when other services aren't even using
>> it yet, and then realize it has issues that could have been fixed prior to
>> the adoption phase.
>> >
>> > # oslo.limit
>> >
>> > In parallel with the keystone work, we created a new library to aid
>> services in consuming limits. Currently, the sole purpose of oslo.limit is
>> to abstract project and project hierarchy information away from the
>> service, so that services don't have to reimplement client code to
>> understand project trees, which could arguably become complex and lead to
>> inconsistencies in u-x across services.
>> >
>> > Ideally, a service should be able to pass some relatively basic
>> information to oslo.limit and expect an answer on whether or not usage for
>> that claim is valid. For example, here is a project ID, resource name, and
>> resource quantity, tell me if this project is over it's associated limit or
>> default limit.
>> >
>> > We're currently working on implementing the enforcement bits of
>> oslo.limit, which requires making API calls to keystone in order to
>> retrieve the deployed enforcement model, limit information, and project
>> hierarchies. Then it needs to reason about those things and calculate usage
>> from the service in order to determine if the request claim is valid or
>> not. There are patches up for this work, and reviews are always welcome [4].
>> >
>> > Note that we haven't released oslo.limit yet, but once the basic
>> enforcement described above is implemented we will. Then services can
>> officially pull it into their code as a dependency and we can work out
>> remaining bugs in both keystone and oslo.limit. Once we're confident in
>> both the API and the library, we'll bump oslo.limit to version 1.0 at the
>> same time we graduate the unified limits API from "experimental" to
>> "supported". Note that oslo libraries <1.0 are considered experimental,
>> which fits nicely with the unified limit API being experimental as we 

[openstack-dev] [keystone] Keystone Team Update - Week of 5 November 2018

[Colleen Murphy]

# Keystone Team Update - Week of 5 November 2018

## News

### Community Goals Status

Python3-first[1]: completed
Upgrade status check[2]: scaffolding is completed but we don't have actual 
checks yet
Mutable config[3] (goal from last cycle): review in progress but needs work

[1] https://governance.openstack.org/tc/goals/stein/python3-first.html
[2] https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html
[3] 
https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html

### Berlin Summit

The Berlin summit is next week so we won't be holding the weekly meeting or 
office hours. As mentioned last week, we a few keystone-related forum sessions 
and talks:

* Operator feedback 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22792/keystone-operator-feedback
* Keystone as an Identity Provider Proxy - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22791/keystone-as-an-identity-provider-proxy
* Keystone project update - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22728/keystone-project-updates
* Keystone project onboarding - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22727/keystone-project-onboarding
* Deletion of project and project resources - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22784/deletion-of-project-and-project-resources
* Enforcing quota consistently with Unified Limits - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22557/enforcing-quota-consistently-with-unified-limits
* Towards an Open Cloud Exchange - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22320/towards-an-open-cloud-exchange
* Pushing keystone over the edge - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22044/pushing-keystone-over-the-edge
* A seamlessly federated multi-cloud - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22607/a-seamlessly-federated-multi-cloud
* OpenStack policy 101 - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/21977/openstack-policy-101
* Dynamic policy for OpenStack with Open Policy Agent - 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/21976/dynamic-policy-for-openstack-with-open-policy-agent
* Identity integration between OpenStack and Kubernetes -  
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22123/identity-integration-between-openstack-and-kubernetes

## Open Specs

Stein specs: https://bit.ly/2Pi6dGj

Ongoing specs: https://bit.ly/2OyDLTh

## Recently Merged Changes

Search query: https://bit.ly/2pquOwT

We merged 34 changes this week.

## Changes that need Attention

Search query: https://bit.ly/2RLApdA

There are 40 changes that are passing CI, not in merge conflict, have no 
negative reviews and aren't proposed by bots.

## Bugs

This week we opened 4 new bugs and closed 3.

Bugs opened (4) 
Bug #1801873 (keystone:Undecided) opened by Izak A Eygelaar 
https://bugs.launchpad.net/keystone/+bug/1801873 
Bug #1802035 (keystone:Undecided) opened by Joshua Cornutt 
https://bugs.launchpad.net/keystone/+bug/1802035 
Bug #1802136 (keystone:Undecided) opened by Simon Reinkemeier 
https://bugs.launchpad.net/keystone/+bug/1802136 
Bug #1802357 (oslo.policy:Undecided) opened by Alfredo Moralejo 
https://bugs.launchpad.net/oslo.policy/+bug/1802357 

Bugs fixed (3) 
Bug #1800124 (keystone:Critical) fixed by Morgan Fainberg 
https://bugs.launchpad.net/keystone/+bug/1800124 
Bug #1797584 (keystonemiddleware:Medium) fixed by Michael Johnson 
https://bugs.launchpad.net/keystonemiddleware/+bug/1797584
Bug #1361743 (keystonemiddleware:Wishlist) fixed by Morgan Fainberg 
https://bugs.launchpad.net/keystonemiddleware/+bug/1361743

## Milestone Outlook

https://releases.openstack.org/stein/schedule.html

## Help with this newsletter

Help contribute to this newsletter by editing the etherpad: 
https://etherpad.openstack.org/p/keystone-team-newsletter
Dashboard generated using gerrit-dash-creator and 
https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

__
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][neutron-release] feature/graphql branch rebase

[Jeremy Stanley]

On 2018-11-09 16:35:22 +1100 (+1100), Gilles Dubreuil wrote:
> Could you please provide permission [1] to upload commit merges?
> 
> I'm getting the following error after merging HEAD:
> 
> $ git review -R feature/graphql
> remote:
> remote: Processing changes: refs: 1
> remote: Processing changes: refs: 1, done
> To ssh://review.openstack.org:29418/openstack/neutron.git
>  ! [remote rejected]   HEAD -> refs/publish/feature/graphql/bug/1802101
> (you are not allowed to upload merges)
> error: failed to push some refs to
> 'ssh://q-1ille...@review.openstack.org:29418/openstack/neutron.git'
[...]

Per openstack/neutron's ACL[*] you need to be made a member of the
neutron-release group in Gerrit[**]. (This permission is tightly
controlled to avoid people accidentally pushing merge commits, which
is all too easy if you're not careful to keep your branches clean.)

[*] 
https://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/neutron.config
[**] https://review.openstack.org/#/admin/groups/neutron-release
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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] [Tacker] Redundancy VNFFG module in tacker

[Nguyễn Trí Hải]

This is the document how to contribute to Tacker:

https://docs.openstack.org/tacker/latest/contributor/index.html

On Fri, Nov 9, 2018, 4:50 PM 백호성  wrote:

> Dear tacker project members,
>
> Hello. I am Hosung Baek and Ph.D.student at Korea Univ.
>
> I am interested in the VNFFG feature in Tacker project, and I want to
> develop the "Redundancy VNFFG module" in tacker.
>
> As far as I know. it is difficult to apply the VNFFG configuration where
> there is low loss requirement such as DetNet and URLLC.
>
> Because there is no module for reliable VNFFG.
>
> The module to be developed is described as follows.
>
> It is a function to construct a disjoint VNFFG by adding redundancy VNFFG
> module to the tacker VNFFG feature and to transmit the data to two disjoint
> paths.
>
> To implement this module, two VNFFGs must be configured for one network
> service and the function to remove redundant packets in two different paths
> is required.
>
> I want to develop this module and contribute this to tacker project.
>
> So could you tell me the contribution process in OpenStack tacker project
> if possible?
>
> Yours sincerely,
>
> Hosung Baek.
>
> __
> 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
>
-- 

*Nguyen Tri Hai  */ Ph.D. Student

ANDA Lab., Soongsil Univ., Seoul, South Korea
__
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] [manila] [contribute]

[Tom Barron]

On 08/11/18 11:07 -0300, Sofia Enriquez wrote:

Hi Leni, welcome!

1) Devstack[1] plays a *main *role in the development workflow.
It's an easier way to get a full environment to work in Manila, we use it
every day. I recommend you to use it in a VM.
You can find many tutorials about how to use Devstack, I just let you one
[2]


Nice blog/guide, Sofia!  I'll just add [4] as a followup for anyone 
particularly wanting to install devstack with manila and a cephfs with 
nfs back end.




2) I can't find *low-hanging-fruit* bugs in Manila. However,
good-first-bugs are tagged as *low-hanging-fruit *for example, cinder's[3]


And Goutham followed up with some manila low-hanging-fruit too.  
Thanks, Goutham!




Today at *15:00 UTC *It's  Weekly Manila Team Meeting at IRC (channel
#openstack-meeting-alt) on Freenode.


And as we may have mentioned, you can ask questions on irc [5] [6]
#openstack-manila any time.  Ask even if no one is responding right 
then, most of us have bouncers and will see and get back to you.


-- Tom Barron

[4] https://github.com/tombarron/vagrant-libvirt-devstack

[5] https://docs.openstack.org/contributors/common/irc.html

[6] https://docs.openstack.org/infra/manual/irc.html



Have fun!
Sofia
irc: enriquetaso
[1]
https://docs.openstack.org/zun/latest/contributor/quickstart.html#exercising-the-services-using-devstack
[2]
https://enriquetaso.wordpress.com/2016/05/07/installing-devstack-on-a-vagrant-virtual-machine/
[3] https://bugs.launchpad.net/cinder/+bugs?field.tag=low-hanging-fruit

On Thu, Nov 8, 2018 at 7:41 AM Leni Kadali Mutungi 
wrote:


Hi Tom

Thanks for the warm welcome. I've gone through the material and I would
like to understand a few things:

1. What's the role of devstack in the development workflow?
2. Where can I find good-first-bugs? A bug that is simple to do
(relatively ;)) and allows me to practice what I've read up on in
Developer's Guide. I looked through the manila bugs on Launchpad but I
didn't see anything marked easy or good-first-bug or its equivalent for
manila. I am a bit unfamiliar with Launchpad so that may have played a
role :).

Your guidance is appreciated.

On 10/19/18 5:55 PM, Tom Barron wrote:
> On 19/10/18 15:27 +0300, Leni Kadali Mutungi wrote:
>> Hi all.
>>
>> I've downloaded the manila project from GitHub as a zip file, unpacked
>> it and have run `git fetch --depth=1` and been progressively running
>> `git fetch --deepen=5` to get the commit history I need. For future
>> reference, would a shallow clone e.g. `git clone depth=1` be enough to
>> start working on the project or should one have the full commit
>> history of the project?
>>
>> --
>> -- Kind regards,
>> Leni Kadali Mutungi
>
> Hi Leni,
>
> First I'd like to extend a warm welcome to you as a new manila project
> contributor!  We have some contributor/developer documentation [1] that
> you may find useful. If you find any gaps or misinformation, we will be
> happy to work with you to address these.  In addition to this email
> list, the #openstack-manila IRC channel on freenode is a good place to
> ask questions.  Many of us run irc bouncers so we'll see the question
> even if we're not looking right when it is asked.  Finally, we have a
> meeting most weeks on Thursdays at 1500UTC in #openstack-meeting-alt --
> agendas are posted here [2].  Also, here is our work-plan for the
> current Stein development cycle [3].
>
> Now for your question about shallow clones.  I hope others who know more
> will chime in but here are my thoughts ...
>
> Although having the full commit history for the project is useful, it is
> certainly possible to get started with a shallow clone of the project.
> That said, I'm not sure if the space and download-time/bandwidth gains
> are going to be that significant because once you have the workspace you
> will want to run unit tests, pep8, etc. using tox as explained in the
> developer documentation mentioned earlier.   That will download virtual
> environments for manila's dependencies in your workspace (under .tox
> directory) that dwarf the space used for manila proper.
>
> $ git clone --depth=1 g...@github.com:openstack/manila.git shallow-manila
> Cloning into 'shallow-manila'...
> ...
> $ git clone g...@github.com:openstack/manila.git deep-manila
> Cloning into 'deep-manila'...
> ...
> $ du -sh shallow-manila deep-manila/
> 20Mshallow-manila
> 35Mdeep-manila/
>
> But after we run tox inside shallow-manila and deep-manila we see:
>
> $ du -sh shallow-manila deep-manila/
> 589Mshallow-manila
> 603Mdeep-manila/
>
> Similarly, you are likely to want to run devstack locally and that will
> clone the repositories for the other openstack components you need and
> the savings from shallow clones won't be that significant relative to
> the total needed.
>
> Happy developing!
>
> -- Tom Barron (Manila PTL) irc: tbarron
>
> [1] https://docs.openstack.org/manila/rocky/contributor/index.html
> [2] https://wiki.openstack.org/wiki/Manila/Meetings
> [3] 

Re: [openstack-dev] [Tacker] Redundancy VNFFG module in tacker

[Trinh Nguyen]

Hi Hosung,

Here are a couple suggestions you can follow.

1. You can first follow the OpenStack contributor guidelines and set up the
needed accounts [1].
2. After you have the launchpad account,  register a blueprint for your
feature in Tacker's launchpad [2].
3. Clone the Tacker Specs repository to your local dev environment [3].
Write a spec (detail about your feature, implementation plan, etc.) for
your feature. Commit. and then 'git review' to push your spec to Gerrit [4]
for the Tacker team to review and comment.
4. After the spec has been approved by the core reviewers and Tacker's PTL,
you can start working on the implementation the same way when you write the
spec:

   - Clone the needed repositories (tacker, python-tackerclient, or
   tacker-horizon) to your local dev environment
   - Make changes
   - Commit and review
   - Wait for other to comments and refine your changes.

You can join the Tacker's IRC chat channel (#tacker) to talk to other
Tacker developers.

Hope that will help.

[1]
https://docs.openstack.org/contributors/code-and-documentation/index.html
[2] https://blueprints.launchpad.net/tacker
[3] https://github.com/openstack/tacker-specs
[4] http://review.openstack.org

On Fri, Nov 9, 2018 at 4:50 PM 백호성  wrote:

> Dear tacker project members,
>
> Hello. I am Hosung Baek and Ph.D.student at Korea Univ.
>
> I am interested in the VNFFG feature in Tacker project, and I want to
> develop the "Redundancy VNFFG module" in tacker.
>
> As far as I know. it is difficult to apply the VNFFG configuration where
> there is low loss requirement such as DetNet and URLLC.
>
> Because there is no module for reliable VNFFG.
>
> The module to be developed is described as follows.
>
> It is a function to construct a disjoint VNFFG by adding redundancy VNFFG
> module to the tacker VNFFG feature and to transmit the data to two disjoint
> paths.
>
> To implement this module, two VNFFGs must be configured for one network
> service and the function to remove redundant packets in two different paths
> is required.
>
> I want to develop this module and contribute this to tacker project.
>
> So could you tell me the contribution process in OpenStack tacker project
> if possible?
>
> Yours sincerely,
>
> Hosung Baek.
>
> __
> 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
>


-- 
*Trinh Nguyen*
*www.edlab.xyz *
__
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] [neutron] CI meeting on 13.11.2018 cancelled

[Slawomir Kaplonski]

Hi,

Due to summit in Berlin Neutron CI meeting on 13.11.2018 is cancelled. Next 
meeting will be as usual on 20.11.2018.

— 
Slawek Kaplonski
Senior software engineer
Red Hat


__
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