[openstack-dev] [Docs] Changes for OpenStack API guides

[Smigiel, Dariusz]

Hello Anne,
I'm working on "moving to Keystone v3 API" spec for Neutron [1].
HenryG mentioned, that in next release or so, there will be change how to 
describe changes connected to API [2].
In spec I'm mentioning, that some changes are required to Networking API v2 
[3], so would like to know, how it supposed to be handled.

If you could point me to some place where I can find extra info about changes, 
It would be very helpful.

Thanks,
Dariusz (dasm) Smigiel

[1] https://review.openstack.org/#/c/257362/
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-January/083670.html
[3] http://developer.openstack.org/api-ref-networking-v2.html

__
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] Team meeting on Tuesday 1400UTC

[Smigiel, Dariusz]

Mondays 21UTC and Tuesdays 14UTC are OK for me, so personally I do not have 
problem to attend both meetings, but I know that for someone one or another can 
be in the middle of night.
In this case, would be good to again have bi-weekly to allow attendance at 
least once per two weeks.

+1 for Kyle's suggestion about different chairs and restoration of abandoned 
meetings on Tuesdays.

-- 
 Dariusz (dasm) Smigiel
 Intel Technology Poland


> -Original Message-
> From: Vikram Choudhary [mailto:viks...@gmail.com]
> Sent: Wednesday, January 20, 2016 6:00 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC
> 
> +1 for Kyle's suggestion
> 
> Thanks
> Vikram
> 
> On Wed, Jan 20, 2016 at 2:40 AM, Martin Hickey   > wrote:
> 
> 
>   Hi,
> 
>   +1 for me on Kyle's suggestion.
> 
>   Regards,
>   Martin
> 
>   Kyle Mestery ---19/01/2016 16:39:05---On Tue, Jan 19, 2016 at 10:14
> AM, Ihar Hrachyshka mailto:ihrac...@redhat.com>
> > wrote: > Rossella Sblendido
> 
>   From: Kyle Mestery   >
>   To: "OpenStack Development Mailing List (not for usage questions)"
> mailto:openstack-
> d...@lists.openstack.org> >
>   Date: 19/01/2016 16:39
>   Subject: Re: [openstack-dev] [Neutron] Team meeting on Tuesday
> 1400UTC
> 
> 
> 
> 
> 
> 
> 
>   On Tue, Jan 19, 2016 at 10:14 AM, Ihar Hrachyshka
> mailto:ihrac...@redhat.com> > wrote:
>   > Rossella Sblendido   > wrote:
>   >
>   >>
>   >>
>   >> On 01/19/2016 04:36 PM, Miguel Angel Ajo Pelayo wrote:
>   >>>
>   >>> Thinking of this, I had another idea, a bit raw yet.
>   >>>
>   >>> But how does it sound to have two meetings a week, one in a
> EU/ASIA
>   >>> friendlier
>   >>> timezone, and another for USA/AU (current one), with different
> chairs.
>   >>>
>   >>> We don't impose unnatural-working hours (too early, too late for
> family,
>   >>> etc..)
>   >>> to anyone, we encourage gathering as a community (may be
> split by
>   >>> timezones, but
>   >>> it feels more human and faster than ML conversations..) and also
> people
>   >>> able
>   >>> to make to both, could serve as bridges for both meetings.
>   >>>
>   >>>
>   >>> Thoughts?
>   >>
>   >>
>   >> I think that is what Kyle was proposing and if I am not wrong that's
> what
>   >> they do in nova.
>   >
>   >
>   > My understanding is that Kyle proposed to switch back to bi-weekly
>   > alternating meetings, and have a separate chair for each.
>   >
>   > I think Kyle’s suggestion is wiser since it won’t leave the community
> split
>   > into two separate parts, and it won’t waste two hours each week
> where we
>   > could make it with just one.
>   >
>   Yes, I was proposing two bi-weekly meetings with different chairs.
> We
>   could even have kept the existing schedule and just had a different
>   chair for the 1400UTC meeting on Tuesday.
> 
>   > Ihar
>   >

__
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] changing in neutron code

[Smigiel, Dariusz]

Hey Atif,
Welcome to the Community.
If you do not know where to start, I'd suggest to read this wiki page [1].
Because you've mentioned Neutron, you can join #openstack-neutron channel on 
Freenode and talk to other people there.
Kilo release is currently considered stable, so just bugfix are allowed to be 
sent there, to prevent from regression problems. If you wanna get more info 
about this, talk to Stable Team [2]
In case of testing your changes, you can do this by running tox, write some 
unittests, integration tests and of course check if you're changes are OK, by 
deploying in testing cloud. [3]

If you have more questions, feel free to use Ask Openstack [4]

[1] https://wiki.openstack.org/wiki/How_To_Contribute
[2] https://wiki.openstack.org/wiki/Meetings/StableTeam
[3] https://wiki.openstack.org/wiki/Network/Testing
[4] https://ask.openstack.org/en/questions/

Regards,
 Dariusz (dasm) Smigiel
 Intel Technology Poland

> 
> Hi All,
> 
> I am a newbie in an Open Stack developers community. I want to do some
> modification in Devstack/kilo neutron part. Can anyone guide me how to test
> the modification in the code part.
> 
> (1) Should I need to define my own module/class.
> (2) Can I add some def in neutron code.
> 
> and Importantly, How to test that my code is working or not?
> 
> Suggestions are highly appreciated and welcome. Really need to get help.
> 
> A.
> 
> 


__
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][Neutron][Nova][devstack] Keystone v3 with "old" clients

[Smigiel, Dariusz]

Hey,
Thanks for responses.

Michal your suggestion helped solve my problem.
Akihiro, thanks for this info. Didn't know about os-client but it seems to be 
very powerful. Great tool!

Henrique, yes. Right now I have no problems with keystone v3.

Best regards,
Dariusz (dasm) Smigiel
Intel Technology Poland


> -Original Message-
> From: Henrique Truta [mailto:henriquecostatr...@gmail.com]
> Sent: Thursday, January 14, 2016 1:10 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Keystone][Neutron][Nova][devstack]
> Keystone v3 with "old" clients
> 
> Hi, Did exporting the variables solve your problem? I'm working on improving
> the support of v3 in devstack, like the openrc you've mentioned.
> 
> 
> Em qui, 14 de jan de 2016 às 06:50, Akihiro Motoki  <mailto:amot...@gmail.com> > escreveu:
> 
> 
>   devstack creates /etc/openstack/clouds.yaml (os-client-config
>   configuraiton files) which specifies to use keystone v3.
>   neutronclient supports os-client-config and keystoneauth which
> handles
>   the difference of keystone API.
>   Note that clouds.yaml is very convenient way to use OpenStack CLI
> [1].
> 
>   As Michal commented, you can also use OS_PROJECT_DOMAIN_xx
> and OS_USER_DOMAIN_xx
>   for keystone v3 API.
> 
>   [1] http://docs.openstack.org/developer/python-
> neutronclient/usage/cli.html#using-with-os-client-config
> 
>   Akihiro
> 
>   2016-01-14 18:13 GMT+09:00 Michal Rostecki
> mailto:mroste...@mirantis.com> >:
>   > On 01/12/2016 02:10 PM, Smigiel, Dariusz wrote:
>   >>
>   >> Hello,
>   >> I'm trying to gather all the info necessary to migrate to keystone
> v3 in
>   >> Neutron.
>   >> When I've started to looking through possible problems with
> clients, it
>   >> occurred that 'neutron' and 'nova' clients do not want to operate
> with
>   >> Keystone v3.
>   >> For keystone client, it's explicit written, that this version is
>   >> deprecated and not supported, so it's not working with Keystone
> API v3. But
>   >> for nova and neutron, there is nothing.
>   >> I didn't see any place where I can find info, that "old" clients
> shouldn't
>   >> be used with Keystone API v3.
>   >>
>   >> Am I doing something wrong?
>   >>
>   >> http://paste.openstack.org/show/483568/
>   >>
>   >
>   > Hi,
>   >
>   > Looks like you're missing OS_PROJECT_DOMAIN_ID and
> OS_USER_DOMAIN_ID env
>   > variables, needed for Keystone v3.
>   >
>   > Unfortunately, I don't see them in devstack's openrc[1]. Maybe it's
> a good
>   > moment to add them here.
>   >
>   > [1] https://github.com/openstack-
> dev/devstack/blob/master/openrc
>   >
>   > Cheers,
>   > Michal
>   >
>   >
>   >
__
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] [Keystone][Neutron][Nova] Keystone v3 with "old" clients

[Smigiel, Dariusz]

Hello,
I'm trying to gather all the info necessary to migrate to keystone v3 in 
Neutron.
When I've started to looking through possible problems with clients, it 
occurred that 'neutron' and 'nova' clients do not want to operate with Keystone 
v3.
For keystone client, it's explicit written, that this version is deprecated and 
not supported, so it's not working with Keystone API v3. But for nova and 
neutron, there is nothing.
I didn't see any place where I can find info, that "old" clients shouldn't be 
used with Keystone API v3.

Am I doing something wrong?

http://paste.openstack.org/show/483568/

-- 
 Dariusz (dasm) Smigiel
 Intel Technology Poland



__
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] Heads up for decomposed plugin break

[Smigiel, Dariusz]

> 
> Hi,
> At the moment private methods are used all over the place. Examples for
> this are the address pairs and the security groups. If you do a grep of the 
> ML2
> plugin you will see these innocent private methods being used.
> The end goal would be for us to have these as public methods.
> Thanks
> Gary
> 

OK, get it. But just wanted to know, what is the outcome from email discussion.
Do we need to match changed/removed private methods with deprecation warning,
or just modify and tell plugins: "deal with it" :)

BR,
Dariusz (dasm) Smigiel

> 
> 
> 
> On 1/12/16, 11:52 AM, "Smigiel, Dariusz"  wrote:
> 
> >
> >
> >> Doug Wiegley  wrote:
> >> >
> >> >
> >> >> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka 
> >> wrote:
> >> >>
> >> >> Sean M. Collins  wrote:
> >> >>
> >> >>>> On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote:
> >> >>>>> On Fri, 8 Jan 2016, Gary Kotton wrote:
> >> >>>>>
> >> >>>>> The commit
> >> >>>>> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com
> >> >>>>> _openstack_neutron_commit_5d53dfb8d64186-
> 2D&d=BQICAg&c=Sqcl0Ez6
> >> >>>>> M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-
> uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8Y
> >> >>>>> Teq9N3-
> diTlNj4GyNc&m=JeGcqDfJO3uBpHFJtMpFdfKGvUvygEhoI7bztB14S9
> >> >>>>> w&s=6QRgfZxiJsf6Mgon-2G_2DUSuUWXKQED2HH38t_TGz8&e=
> >> >>>>> b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins
> >> >>>>> that make use of the method _get_tenant_id_for_create
> >> >>>>
> >> >>>> Just out of curiosity, is it not standard practice that a plugin
> >> >>>> shouldn't use a private method?
> >> >>>
> >> >>> +1 - hopefully decomposed plugins will audit their code and look
> >> >>> +for
> >> >>> other calls to private methods.
> >> >>
> >> >> The fact that it broke *aas repos too suggests that we were not
> >> >> showing a proper example to those decomposed. I think it can be
> >> >> reasonable to restore the method until N, with a deprecation
> >> >> message, as Garry suggested in his patch. Especially since there
> >> >> is no actual burden to keep the method for another cycle.
> >> >
> >> > The neutron community has been really lax about enforcing private
> >> methods.
> >> > And while we should absolutely reverse that trend, likely we should
> >> > give some warning. I agree with not going whole hog on that until N.
> >> >
> >> > I'd suggest putting in a debtcollector reference when putting the
> >> > method
> >> back.
> >>
> >> Done. https://review.openstack.org/265315
> >
> >
> >Do we have any consensus about treating private methods? Any general
> tips about it, or every time should it be left for author decision?
> >
> >Should we use deprecation warning for all refactored private methods,
> treating it as "API" and rewriting underneath code?
> >
> >Thanks, Dariusz (dasm) Smigiel
> >

__
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] Team meeting on Tuesday 1400UTC

[Smigiel, Dariusz]

> On 2016/01/12 7:14, Armando M. wrote:
>   On 11 January 2016 at 13:54, Hirofumi Ichihara
> mailto:ichihara.hirof...@lab.ntt.co.jp> >
> wrote:
>   On 2016/01/12 5:14, Armando M. wrote:
>   On 11 January 2016 at 12:04, Carl Baldwin <
>  c...@ecbaldwin.net
>  > wrote:
> 
> 
>   What do we do?  My calendar was set up
> with the sane bi-weekly thing
>   and it shows the meeting for tomorrow.  The
> last word from our
>   fearless leader is that we'll have it today.  
> So,
> I'll be there today
>   unless instructed otherwise.
> 
>   The ics file now seems to reset the cadence
> beginning today at 2100
>   and next Tuesday, the 19th, at 1400.  I guess
> we should either hold
>   the meeting today and reset the cadence or
> fix the ics file.
> 
> 
> 
> 
>   This is what I would like to do now:
> 
>   https://review.openstack.org/#/c/266019
> 
>   I personally haven't seen that much of an attendance
> difference anyway, and at this point, it'll simplify our lives and avoid grief
> going forward.
> 
>   I like it.
> 
>   However, we have gathered from all over the world because
> neutron is big project. Should we have the choice so that more people get
> attendance opportunity?
> 
> 
>   This time, the return to the normal schedule was a disaster, plus
> every time we switch to daylight savings, or every time there's a holiday
> break/summit we have twice the chances to screw up if we keep the bi-
> weekly schedule.
> 
>   If I go and look at the logs [1] I don't have hard evidence that the bi-
> weekly schedule does indeed help the attendance of friendlier timezones,
> so I wonder...what's the point?
> 
> You're right. My reply was just general opinion. I think that most regular 
> folks
> probably attend both days now. I actually do as well.
> 
> I was worried that sometimes there are developers who introduce his bug or
> ask core to review although they usually don't attend. However, we have
> openstack-neutron channel for it.
> 
> 

In this case, we have Today's meeting, and from now on, just one weekly at 
Mondays 2100 UTC?

Dariusz (dasm) Smigiel

__
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] Heads up for decomposed plugin break

[Smigiel, Dariusz]

> Doug Wiegley  wrote:
> >
> >
> >> On Jan 11, 2016, at 2:42 AM, Ihar Hrachyshka 
> wrote:
> >>
> >> Sean M. Collins  wrote:
> >>
>  On Fri, Jan 08, 2016 at 07:50:47AM PST, Chris Dent wrote:
> > On Fri, 8 Jan 2016, Gary Kotton wrote:
> >
> > The commit
> > https://github.com/openstack/neutron/commit/5d53dfb8d64186-
> > b5b1d2f356fbff8f222e15d1b2 may break the decomposed plugins that
> > make use of the method _get_tenant_id_for_create
> 
>  Just out of curiosity, is it not standard practice that a plugin
>  shouldn't use a private method?
> >>>
> >>> +1 - hopefully decomposed plugins will audit their code and look for
> >>> other calls to private methods.
> >>
> >> The fact that it broke *aas repos too suggests that we were not
> >> showing a proper example to those decomposed. I think it can be
> >> reasonable to restore the method until N, with a deprecation message,
> >> as Garry suggested in his patch. Especially since there is no actual
> >> burden to keep the method for another cycle.
> >
> > The neutron community has been really lax about enforcing private
> methods.
> > And while we should absolutely reverse that trend, likely we should
> > give some warning. I agree with not going whole hog on that until N.
> >
> > I'd suggest putting in a debtcollector reference when putting the method
> back.
> 
> Done. https://review.openstack.org/265315


Do we have any consensus about treating private methods? Any general tips about 
it, or every time should it be left for author decision?

Should we use deprecation warning for all refactored private methods, treating 
it as "API" and rewriting underneath code?

Thanks, Dariusz (dasm) Smigiel

__
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] Fwd: [Neutron] Team meeting this Monday at 2100 UTC

[Smigiel, Dariusz]

> -Original Message-
> From: Kevin Benton [mailto:blak...@gmail.com]
> 
> I liked using the meeting for it because it was a nice way for everyone to get
> a snapshot of where each thing was at.

+1
The idea of discussing everything on meeting is very good.
Everyone interested is  on the same page.

Cheers,
Darek Smigiel (dasm)
ITP

> 
> On Dec 7, 2015 3:14 PM, "Armando M."   > wrote:
> 
> 
>   Hi neutrinos,
> 
>   During today's meeting [1] we went through the outstanding
> blueprints, but we only managed to look at a little over half of them.
> 
>   Would you guys like to continue the conversation during next week's
> meeting or shall we ask for people's status updates offline? An update on
> the BP's whiteboard like done in [2] would suffice.
> 
>   Cheers,
>   Armando
> 
>   [1]
> http://eavesdrop.openstack.org/meetings/networking/2015/networking.20
> 15-12-07-21.00.html
>   [2] https://blueprints.launchpad.net/neutron/+spec/external-dns-
> resolution
> 
>   -- Forwarded message --
>   From: Armando M.   >
>   Date: 4 December 2015 at 12:50
>   Subject: [Neutron] Team meeting this Monday at 2100 UTC
>   To: "OpenStack Development Mailing List (not for usage questions)"
> mailto:openstack-
> d...@lists.openstack.org> >
> 
> 
> 
>   Hi neutrinos,
> 
>   A kind reminder for next week's meeting.
> 
>   Being the meeting right after the milestone was cut, I'd like to take
> most of the hour to talk about blueprints/specs, i.e. the beefy workload that
> has merged, and has yet to merge.
> 
>   We'll be brief on announcements and bugs, and skip the other
> sections, docs and open agenda. More details on [1].
> 
>   We'll run this specially focussed meetings throughout the release,
> and we'll have meetings focussed on Docs and Bugs alone too in the future.
> Stay tuned.
> 
>   Cheers,
>   Armando
> 
>   [1] https://wiki.openstack.org/wiki/Network/Meetings
> 
__
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] Rename tenant to project: discussion

[Smigiel, Dariusz]

Thanks guys for all the feedback.
I'm happy we elaborated some plan for this topic.

-- 
 Dariusz Smigiel
 Intel Technology Poland

> On 12/04/2015 04:26 PM, Armando M. wrote:
> >
> >
> > On 4 December 2015 at 10:02, Kevin Benton  > <mailto:blak...@gmail.com>> wrote:
> >
> > So obviously the stuff in the client can be updated since most of
> > that is user-facing. However, on the server side maybe we can start
> > out by keeping all of the internal code and DB tables the same. Then
> > all we need to worry about is the API translation code to start.
> >
> > Once our public-facing stuff is done, we can just start the
> > transition to project_id internally at our own pace and in much less
> > invasive chunks.
> >
> >
> > This plan is sensible, and kudos to Dariusz to take it on...this is no
> > small feat of engineering and it won't be the effort of a
> > single...we're all here to help. Let me state the obvious and remind
> > that this is not a mechanical search and replace effort. We gotta be
> > extra careful to support both terms in the process.
> >
> > To sum it up I see the following steps:
> >
> > 1) Make or figure out how the server can talk to the v3 API - which is
> > bug 1503428. If Monty is unable to tackle it soon, I am sure he'll be
> > happy to hand it back and Darius, perhaps, can take over
> 
> I will hack on this next week - sorry for the delay so far. I'd love to do a 
> first
> rough pass and then get Darius to look at it and tell me where I'm insane.
> 
> > This will ensure that if for whatever reason v2 gets pulled out
> > tomorrow (not gonna happen, but still), we're not left high and dry.
> > To achieve this, I think we don't invasively need to change tenant id
> > with project id, but only where it's key to get/validate a token.
> 
> ++
> 
> > 2) Start from the client to allow to handle both project_id and tenant_id.
> >
> > The server must be enhanced to be able to convert project_id to
> > tenant_id on the fly. The change should be relatively limited in a few
> > places, like where the request come in. At this time nothing else is
> > required to change in the server.
> 
>  From an auth perspective, keystoneauth will handle both tenant and project
> as auth parameters (and I've got a patch coming to neutronclient to help get
> that all fleshed out too)
> 
>  From the server/api side and client lib side where people are passing in
> tenant_ids to neutron resources because it's important to associate a
> resource with a tenant/project - I think this is a GREAT plan, and thank you
> for doing it this way. As a consumer of your API, I neither want to have to
> change my code to the new version, or write new code using the old version
> (thus perpetuating the move in history)
> 
> I would suggest/request if there is a way (and this might be _terrible_ to
> mark tenant_id in the _docs_ as either hidden or deprecated, so that new
> users don't write new code using it - but of course we should continue to
> accept tenant_id until the end of time because of how much we love our
> users.
> 
> > 3) Tackle the data model.
> >
> > I wonder if we could leverage some sqlalchemy magic to support both
> > project_id and tenant_id in the db logic, seamlesslysomething
> > worth investigating (zzzeek may be of help here). The sooner we start
> > here, the sooner we catch and fix breakages
> >
> > 4) Tackle the codebase sweep.
> >
> > As for projects that use neutron and use the internal APIs, I can't
> > see a clean way of handling the bw compat if not by sprinkling
> > decorators that will take the signature of all the affected methods
> > and convert the tenant_id, but we could definitely explore how this would
> look like.
> 
> Yah. That one is going to be yuck. I'm happy to hand people beer ... :)
> >
> > On Thu, Dec 3, 2015 at 10:25 AM, Smigiel, Dariusz
> > mailto:dariusz.smig...@intel.com>> wrote:
> >
> > Hey Neutrinos (thanks armax for this word :),
> > Keystone is planning to deprecate V2 API (again :). This time in
> > Mitaka [6], and probably forever. It will stay at least four
> > releases, but we need to decide, how to conquer problem of
> > renaming...
> > And more important: consider if it's a problem for Neutron?
> >
> > I'm looking at blueprint [1] about renaming all occurrences of
> > 'tenant' to 'project', and

Re: [openstack-dev] [Neutron] Bug deputy process

[Smigiel, Dariusz]

> From: Kyle Mestery [mailto:mest...@mestery.com] 
[...]
> One concern I have is ensuring we rotate people, because it does take some 
> time, and if the same handful of rotate, they will burn out. So I actively 
> encourage more people to volunteer, you don't even have to be a Neutron core 
> reviewer to do this!

Kyle, didn't know that not only core reviewers can do deputy. I thought that 
only selected group of users have an access to bug triaging.
Another thing, probably the best users who know how bug is complicated or 
important, are cores.

If you have any tips or tricks to do proper deputy, I'm in.

> Thanks!
> Kyle

Thanks, Darek Smigiel (dasm)
ITP
__
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] Rename tenant to project: discussion

[Smigiel, Dariusz]

Hey Neutrinos (thanks armax for this word :),
Keystone is planning to deprecate V2 API (again :). This time in Mitaka [6], 
and probably forever. It will stay at least four releases, but we need to 
decide, how to conquer problem of renaming... 
And more important: consider if it's a problem for Neutron?

I'm looking at blueprint [1] about renaming all occurrences of 'tenant' to 
'project', and trying to find out all the details.
First attempt to solve this problem was raised in November 2013 [4][5] but 
unfortunately, no one finished it. Although Keystone V3 API is already 
supported in Neutron client [2], there are still some unknowns about Neutron 
server side. Monty Taylor is trying to address necessary (if any) changes [3].

Findings:
I've focused on two projects: python-neutronclient and neutron.
grep found 429 occurrences of 'tenant' in Client while Server has 3021 of it. 
Some of them are just documentation and docstrings, but there are a lot of 
places, where variables are tangled: defined in DB, used in server, accessed by 
client. Most of places are just internal usages. The only thing where I've 
found 'public' information about tenants is 'help' command in neutron client.

Suggested plan for conquer:
1. First step would be to deal with neutronclient. It's much smaller amount of 
code to look through, update all places and be successful :)
2. Bigger challenge will be to change server side code. I'd suggest to start 
with renaming db columns. It affects a lot of places, so when finished should 
significantly lower number of remained "tenants".
3. Deal with all other places.

Pros:
- variable names unification in OpenStack code base. Someone needs to start 
this job.
- one way to describe the same thing, instead of: tenant/account/project. 
Helpful, especially for newcomers.
- alignment with Keystone V3 API

Cons:
- A. Lot. Of. Work.
- dealing with DB migrations
- about 2-4 weeks of work for every part of code. Additional, a lot of 
patchsets to be reviewed.

What do you think about this? About proposed way of dealing with all changes?
Is this change necessary?
Did I forget about something?

I'll be grateful for any kind of feedback.

Thanks,
 Dariusz Smigiel (dasm)
 Intel Technology Poland

[1] https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project
[2] 
https://blueprints.launchpad.net/python-neutronclient/+spec/keystone-api-v3-support
[3] https://bugs.launchpad.net/neutron/+bug/1503428
[4] http://lists.openstack.org/pipermail/openstack-dev/2013-November/020457.html
[5] http://lists.openstack.org/pipermail/openstack-dev/2013-December/021083.html
[6] http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.htm

__
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][Infra] "gate-neutron-lbaasv1-dsvm-api" blocking patch merge

[Smigiel, Dariusz]

> 
> On 04/11/15 12:48, Mohan Kumar wrote:
> > Hi,
> >
> > Jenkins blocking patch merge due to "
> > gate-neutron-lbaasv1-dsvm-api
> >  dsvm-
> api/f631adf/>"
> >
> >
> failures which is unrelated to patch-set changes .
> >
> > Patch: https://review.openstack.org/#/c/237896/
> >
> > Please help to resolve this issue .
> >
> 
> It's a known issue: https://launchpad.net/bugs/1512937
> 
> There is already a lbaas patch for that:
> https://review.openstack.org/#/c/241481/
> 
> Ihar

It's currently merged, so in next ~30 minutes should be fixed.

-- 
 Dariusz Smigiel
 Intel Technology Poland


__
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] [kolla] Proposal for changing 1600UTC meeting to 1700 UTC

[Smigiel, Dariusz]

> Folks,
> 
> Several people have messaged me from EMEA timezones that 1600UTC fits right 
> into the middle of their family life (ferrying kids from school and what-not) 
> and 1700UTC while not perfect, would be a better fit time-wise.
> 
> For all people that intend to attend the 1600 UTC, could I get your feedback 
> on this thread if a change of the 1600UTC timeslot to 1700UTC would be 
> acceptable?  If it wouldn't be acceptable, please chime in as well.
> 
> Thanks
> -steve

+1
It suits me.

-- 
 Dariusz Smigiel
 Intel Technology Poland

__
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] [TripleO] Consistent variable documentation for diskimage-builder elements

[Smigiel, Dariusz]

> Excerpts from Dan Prince's message of 2015-04-13 14:07:28 -0700:
> > On Tue, 2015-04-07 at 21:06 +, Gregory Haynes wrote:
> > > Hello,
> > >
> > > Id like to propse a standard for consistently documenting our
> > > diskimage-builder elements. I have pushed a review which transforms
> > > the apt-sources element to this format[1][2]. Essentially, id like
> > > to move in the direction of making all our element README.rst's
> > > contain a sub section called Environment Vairables with a Definition
> > > List[3] where each entry is the environment variable. Under that
> > > environment variable we will have a field list[4] with Required,
> > > Default, Description, and optionally Example.
> > >
> > > The goal here is that rather than users being presented with a wall
> > > of text that they need to dig through to remember the name of a
> > > variable, there is a quick way for them to get the information they
> > > need. It also should help us to remember to document the vital bits
> > > of information for each vairable we use.
> > >
> > > Thoughts?
> >
> > I like the direction of the cleanup. +2
> >
> > I do wonder who we'll enforce consistency in making sure future
> > changes adhere to the new format. It would be nice to have a CI check
> > on these things so people don't constantly need to debate the correct
> > syntax, etc.
> 
> I agree Dan, which is why I'd like to make sure these are machine readable
> and consistent. I think it would actually make sense to make our argument
> isolation efforts utilize this format, as that would make sure that these are
> consistent with the code as well.
> 

As already suggested in my previous email [1], we could consider rest_lint [2]

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-April/060907.html
[2] https://pypi.python.org/pypi/restructuredtext_lint/0.4.0

Any thoughts?

--
Dariusz Smigiel
Intel Technology Poland

__
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] [TripleO] Consistent variable documentation for diskimage-builder elements

[Smigiel, Dariusz]

> Hello,
> 
> Id like to propse a standard for consistently documenting our diskimage-
> builder elements. I have pushed a review which transforms the apt-sources
> element to this format[1][2]. Essentially, id like to move in the direction of
> making all our element README.rst's contain a sub section called
> Environment Vairables with a Definition List[3] where each entry is the
> environment variable. Under that environment variable we will have a field
> list[4] with Required, Default, Description, and optionally Example.
> 
> The goal here is that rather than users being presented with a wall of text
> that they need to dig through to remember the name of a variable, there is a
> quick way for them to get the information they need. It also should help us
> to remember to document the vital bits of information for each vairable we
> use.
> 
> Thoughts?
> 
> Cheers,
> Greg
> 
> 1 - https://review.openstack.org/#/c/171320/
> 2 - http://docs-draft.openstack.org/20/171320/1/check/gate-diskimage-
> builder-docs/d3bdf04//doc/build/html/elements/apt-sources/README.html
> 3 - http://docutils.sourceforge.net/docs/user/rst/quickref.html#definition-
> lists
> 4 - http://docutils.sourceforge.net/docs/user/rst/quickref.html#field-lists

Looks very promising.
Are you planning to add some kind of lint[1] to RST and force formatting or 
based on common sense for all developers involved?
One minor thing: would be nice to have permalinks to Variables.

In general, it's more readable and understandable compared to previous version.
+1 from me :)

[1] https://pypi.python.org/pypi/restructuredtext_lint/0.4.0

--
Dariusz Smigiel
Intel Technology Poland

__
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] [TripleO] QuintupleO Overview

[Smigiel, Dariusz]

> On 17 March 2015 at 09:30, Ben Nemec 
> wrote:
> > So I've successfully done a deployment to a QuintupleO environment. \o/
> 
> \o/
> 

Great news! Congrats!

@Ben, are you planning to keep it up-to-date or create repo with README?
I would also like to be involved in "TripleO wasn't confusing enough, let's add 
another layer" [1] ;) so maybe this is good start.

[1] http://blog.nemebean.com/content/quintupleo-status-update



__
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] [devstack] pip wheel' requires the 'wheel' package

[Smigiel, Dariusz]

From: yuntong [mailto:yuntong...@gmail.com]
Sent: Monday, March 2, 2015 7:35 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [devstack] pip wheel' requires the 'wheel' package

Hello,
I got an error when try to ./stack.sh as:
2015-03-02 05:58:20.692 | net.ipv4.ip_local_reserved_ports = 35357,35358
2015-03-02 05:58:20.959 | New python executable in tmp-venv-NoMO/bin/python
2015-03-02 05:58:22.056 | Installing setuptools, pip...done.
2015-03-02 05:58:22.581 | ERROR: 'pip wheel' requires the 'wheel' package. To 
fix this, run: pip install wheel

After pip install wheel, got same error.
In [2]: wheel.__path__
Out[2]: ['/usr/local/lib/python2.7/dist-packages/wheel']
In [5]: pip.__path__
Out[5]: ['/usr/local/lib/python2.7/dist-packages/pip']

$ which python
/usr/bin/python

As above, the wheel can be imported successfully,
any hints ?

Thanks.

Did you try pip install –upgrade wheel ?
__
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