[openstack-dev] [openstack][ironic] Event processing for async task improvement

[Yuriy Zveryanskyy]

Hi.

There is state rollback mechanism in ironic if conductor work thread can
not be started for change provision state via API. And looks like we need
the same for
cleaning [1].
This mechanism can not be clearly integrated with provision state
notifications,
in the start -> (end or error) scheme imlemented for async task error is
"permanent" externally visible error like provision error, cleaning error,
there is no FSM event that triggered this rollback etc. Due to these
reasons current implementation of provision state notifications is
overcomplex and potentially raceable [2].
I propose do not change provision state until work thread is started. RFC
7231 does not require any type of "sync start" [3].
All needed changes look like internal refactoring, no changes visible from
external world.
Details:
- remove all callback related parameters from process_event() method. This
is not
breaking change because these parameters should be only used for conductor
and not for drivers;
- add event and related parameter to spawn_after() method. This method
should only process event on the FSM and does not apply state changes to
the node
object and DB;
- add new method post_process_event() (apply_states?) to task manager.
Create
a decorator that calls this method using task instance from args before main
function. Not needed to add this decorator in the code manually to each
function,
callback functions can be decorated inside task manager;
- remove hooks function for provision and cleaning, logging and last error
setting
can be done inside task manager.

Have a nice time on the Summit.
Note that I'm on PTO until Oct 31.

[1] https://bugs.launchpad.net/ironic/+bug/1635619
[2] https://review.openstack.org/#/c/348437/
[3] https://tools.ietf.org/html/rfc7231#section-6.3.3

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

Re: [openstack-dev] [all][tc] "production line" changes to multiple projects

[Matt Riedemann]

On 10/22/2016 6:52 AM, Amrith Kumar wrote:

Is there something we can do about the “production line” changes like



https://review.openstack.org/#/q/Update+.gitignore+to+ignore+.idea+of+PyCharm



These kinds of changes, and this is by no means the only one, are aimed
at bringing ‘standardization’ to all OpenStack projects. Unfortunately,
when all projects don’t agree with the attempt at standardization, we
end up with a lack of standardization across OpenStack.



How do we go about handling these kinds of changes that are causing a
fair amount of churn with little real benefit? Is there anything we can
do or is the best recommendation that projects just grin and bear it?



-amrith



__
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



Love and hugs is probably the only solution.

Obviously different projects have different degrees of strictness on 
their .gitignore file.


As pointed out in another thread by you for something related, I can't 
remember exactly what that one was about but it was an unnecessary 
global change, the best you can probably do right now is education in 
the code review about why you disagree with the change.


I'm not sure if hacking runs on .gitignore files but it seems you could 
make that happen, and then add a rule to hacking, either in your project 
or globally, to fail pep8 if there are editor-specific files added to 
.gitignore.


--

Thanks,

Matt Riedemann


__
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] [sahara] draft logo & sneak peek

[Vitaly Gridnev]

Hi team,
I just received a draft version of our project logo, using the mascot we
selected together. A final version (and some cool swag) will be ready for
us before the Project Team Gathering in February. Before they make our logo
final, they want to be sure we're happy with our mascot.

We can discuss any concerns in Barcelona and you can also provide direct
feedback to the designers: http://tinyurl.com/OSmascot  Logo feedback is
due Friday, Nov. 11. To get a sense of how ours stacks up to others, check
out this sneak preview of several dozen draft logos from our community:
https://youtu.be/JmMTCWyY8Y4

-- 
Best Regards,
Vitaly Gridnev,
Project Technical Lead of OpenStack DataProcessing Program (Sahara)
Mirantis, Inc
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] "production line" changes to multiple projects

[ZZelle]

Hi,

Project .gitignore should specify untracked files related only to the
project and developers should specify in their local .gitignore untracked
files related to the way they develop.

It seems to be git-scm[1] recommandation:

*Patterns which a user wants Git to ignore in all situations (e.g., backup
or temporary files generated by the user’s editor of choice) generally go
into a file specified by core.excludesFile in the user’s ~/.gitconfig. Its
default value is $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either
not set or empty, $HOME/.config/git/ignore is used instead.*


Cedric/ZZelle@IRC

[1] https://git-scm.com/docs/gitignore




On Sat, Oct 22, 2016 at 1:52 PM, Amrith Kumar  wrote:

> Is there something we can do about the “production line” changes like
>
>
>
> https://review.openstack.org/#/q/Update+.gitignore+to+
> ignore+.idea+of+PyCharm
>
>
>
> These kinds of changes, and this is by no means the only one, are aimed at
> bringing ‘standardization’ to all OpenStack projects. Unfortunately, when
> all projects don’t agree with the attempt at standardization, we end up
> with a lack of standardization across OpenStack.
>
>
>
> How do we go about handling these kinds of changes that are causing a fair
> amount of churn with little real benefit? Is there anything we can do or is
> the best recommendation that projects just grin and bear it?
>
>
>
> -amrith
>
> __
> 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] [all][tc] "production line" changes to multiple projects

[Amrith Kumar]

Is there something we can do about the "production line" changes like 

 

https://review.openstack.org/#/q/Update+.gitignore+to+ignore+.idea+of+PyChar
m

 

These kinds of changes, and this is by no means the only one, are aimed at
bringing 'standardization' to all OpenStack projects. Unfortunately, when
all projects don't agree with the attempt at standardization, we end up with
a lack of standardization across OpenStack.

 

How do we go about handling these kinds of changes that are causing a fair
amount of churn with little real benefit? Is there anything we can do or is
the best recommendation that projects just grin and bear it?

 

-amrith 



smime.p7s
Description: S/MIME cryptographic 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] [new][meteos] New project: Meteos

[Hiroyuki Eguchi]

Hi Jeremy.

> I recommend reviewing http://docs.openstack.org/project-team-guide/
> and http://docs.openstack.org/infra/manual/ for more information on how our 
> developer community operates.


Thank you for valuable information.

I will check that out.

Thanks.

---
Hiroyuki Eguchi

-Original Message-
From: Jeremy Stanley [mailto:fu...@yuggoth.org] 
Sent: Friday, October 21, 2016 11:00 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [new][meteos] New project: Meteos

On 2016-10-21 02:21:00 + (+), Hiroyuki Eguchi wrote:
[...]
> The goal of this project is to be a Big Tent project.
> 
> For that, I plan to release the initial version in github by end of 
> this year.
[...]
> Everyone can participate in this project as a user, developer, 
> reviewer in the same way as another OpenStack projects.
[...]

OpenStack projects aren't developed on Github, only mirrored to it.
I recommend reviewing http://docs.openstack.org/project-team-guide/
and http://docs.openstack.org/infra/manual/ for more information on how our 
developer community operates.

Thanks for wanting to get involved in OpenStack!
--
Jeremy Stanley

__
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] [heat][zaqar][telemetry] Subscribing to events

[Thomas Herve]

Hi all,

One of my long time goal since I started contributing to OpenStack is
to try to remove polling where I can. With Zaqar WebSocket support, we
now have a transport available for users to connect to, and where we
can push notifications. We already leveraged that in Heat [1], so that
you can manipulate a stack and you'll be notified when its status
changes.

Still, not everyone uses Heat, and under the hood it still polls for
you. We should be able to use the various notifications that projects
publish to push similar events. Ceilometer already consumes those
notifications and try to make them somewhat consumable [2].

The missing piece is something that bridges Ceilometer and Zaqar. I
wrote a small service [3] which provide a simple API, so that you can
say "Subscribe to those events and send them to this queue". The data
flow looks like this:

Service (Nova, Neutron) -> Notification -> Ceilometer -> Bridge ->
Zaqar -> User.

This way, you'll get a Zaqar message per event, with some filtering
done by the bridge service. It's far from being ideal, as the
notification format is a endless topic of conversation, but I hope
that if we start using it things will move further. I also hope I can
get some feedback on the approach.

One question is whether we want to skip the subscription phase, and
simply makes all those events available to users at a known place (for
example, all events in the Zaqar queue events-queue, or maybe all Nova
events in the compute-events-queue). That pushes filtering to the
user, but it also simplifies the bootstrap phase.

Anyway, I wanted to send this before the summit so that people
interested can come talk to me.

Thanks,

-- 
Thomas

[1] 
http://docs.openstack.org/developer/heat/template_guide/environment.html#retrieving-events

[2] 
http://docs.openstack.org/developer/ceilometer/events.html#events-from-notifications

[3] https://github.com/therve/nabu

__
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