Re: [openstack-dev] [blazar] about reservation

[Masahito MUROI]

Hello Jaze,

In general, Blazar ensures its instance scheduling by a combination of 
its flavor or scheduler hint and Nova scheduler filter.


In case of the instance reservation, a instance with the flavor is 
scheduled to a reserved slot on a specific hypervisor. Please see the 
spec page for the details.


https://docs.openstack.org/blazar/latest/specs/pike/new-instance-reservation.html

best regards,
Masahito

On 2018/09/06 16:52, Jaze Lee wrote:

Hello,
I view the source code and do not find the check logic for
reservation a instance. It just create a lease, and nova just create a
flavor.
How do we ensure the resource is really reserved for us?
We put the host into a new aggregate? and nobody except blazar will use
the host?





__
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][searchlight][designate][telemetry][mistral][blazar][watcher][masakari]Possible deprecation of Nova's legacy notification interface

[Masahito MUROI]

Thanks for the notification!

Blazar has already support the versioned notification. It consumes the 
service.update type notification internally. And I checked the feature 
works only with the versioned one.


best regards,
Masahito

On 2018/08/09 18:41, Balázs Gibizer wrote:

Dear Nova notification consumers!


The Nova team made progress with the new versioned notification 
interface [1] and it is almost reached feature parity [2] with the 
legacy, unversioned one. So Nova team will discuss on the upcoming PTG 
the deprecation of the legacy interface. There is a list of projects (we 
know of) consuming the legacy interface and we would like to know if any 
of these projects plan to switch over to the new interface in the 
foreseeable future so we can make a well informed decision about the 
deprecation.



* Searchlight [3] - it is in maintenance mode so I guess the answer is no
* Designate [4]
* Telemetry [5]
* Mistral [6]
* Blazar [7]
* Watcher [8] - it seems Watcher uses both legacy and versioned nova 
notifications

* Masakari - I'm not sure Masakari depends on nova notifications or not

Cheers,
gibi

[1] https://docs.openstack.org/nova/latest/reference/notifications.html
[2] http://burndown.peermore.com/nova-notification/

[3] 
https://github.com/openstack/searchlight/blob/master/searchlight/elasticsearch/plugins/nova/notification_handler.py 

[4] 
https://github.com/openstack/designate/blob/master/designate/notification_handler/nova.py 

[5] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/pipeline/data/event_definitions.yaml#L2 

[6] 
https://github.com/openstack/mistral/blob/master/etc/event_definitions.yml.sample#L2 

[7] 
https://github.com/openstack/blazar/blob/5526ed1f9b74d23b5881a5f73b70776ba9732da4/doc/source/user/compute-host-monitor.rst 

[8] 
https://github.com/openstack/watcher/blob/master/watcher/decision_engine/model/notification/nova.py#L335 






__
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] [Blazar] Stein etherpad

[Masahito MUROI]

Hi Blazar folks,

I prepared the etherpad page for the Stein PTG.

https://etherpad.openstack.org/p/blazar-ptg-stein


best regards,
Masahito


__
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] [Blazar] PTL non candidacy

[Masahito MUROI]

Hi Blazar folks,

I just want to announce that I'm not running the PTL for the Stein 
cycle. I have been running this position from the Ocata cycle when we 
revived the project.  We've been done lots of successful activities in 
the last 4 cycles.


I think it's time to change the position to someone else to move the 
Blazar project further forward. I'll still be around the project and try 
to make the Blazar project great.


Thanks for lots of your supports.

best regards,
Masahito


__
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] [Blazar] Next IRC meeting is canceled

[Masahito MUROI]

Hi Blazar folks,

As we discussed in the last meeting, the next weekly meeting is canceled 
because most of members are out of town next week.


The next regular meeting is on 8th May.

best regards,
Masahito


__
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] [Blazar] skip weekly meeting

[Masahito MUROI]

Hi Blazar folks,

As we talked in last meeting, this weekly meeting is skipped because 
most of the team members are out of office.


best regards,
Masahito


__
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] [Blazar] Nominating Bertrand Souville to Blazar core

[Masahito MUROI]

Hi Blazar folks,

I'd like to nominate Bertrand Souville to blazar core team. He has been 
involved in the project since the Ocata release. He has worked on NFV 
usecase, gap analysis and feedback in OPNFV and ETSI NFV as well as in 
Blazar itself.  Additionally, he has reviewed not only Blazar repository 
but Blazar related repository with nice long-term perspective.


I believe he would make the project much nicer.

best regards,
Masahito


__
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] [Blazar] skip next weekly meeting

[Masahito MUROI]

Dear Blazar folks,

We had a great discussion in the Dublin PTG. Unfortunately, most of 
members are still stuck in Dublin because of heavy snow and will not be 
able to back their home by the meeting.


So let's skip the next weekly meeting on 6th March.

best regards,
Masahito


__
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] [blazar] [Release-job-failures] Release of openstack/blazar-nova failed

[Masahito MUROI]

Hi Sean,

Thanks. I push the patch to fix the issue.  Do I need an additional 
patch that tags blazar-nova 1.0.1 as I did to blazarclient?


https://review.openstack.org/#/c/539433/

best regards,
Masahito

On 2018/01/31 7:40, Sean McGinnis wrote:

There was a failure with releasing blazar-nova. It would appear this has a
dependency on nova, but nova is not in the required-projects. This will need to
be corrected before we can complete the blazar-nova release.

http://logs.openstack.org/ed/ed4afab27ae0a030a775059936da80f7f01eb2f6/release/release-openstack-python/821c969/job-output.txt.gz#_2018-01-30_22_06_50_103665

- Forwarded message from z...@openstack.org -

Date: Tue, 30 Jan 2018 22:11:42 +
From: z...@openstack.org
To: release-job-failu...@lists.openstack.org
Subject: [Release-job-failures] Release of openstack/blazar-nova failed
Reply-To: openstack-dev@lists.openstack.org

Build failed.

- release-openstack-python 
http://logs.openstack.org/ed/ed4afab27ae0a030a775059936da80f7f01eb2f6/release/release-openstack-python/821c969/
 : FAILURE in 3m 45s
- announce-release announce-release : SKIPPED
- propose-update-constraints propose-update-constraints : SKIPPED

___
Release-job-failures mailing list
release-job-failu...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

- End forwarded message -

__
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] [requirements][Blazar] FFE - add python-blazarclient in global-requirements

[Masahito MUROI]

Hi requirements team,

This is a FFE request for adding python-blazarclient to 
global-requirements.txt.  Blazar team had release problems for updating 
the blazarclient to pypo.


Luckily, the problems are fixed and the client is published at pypi this 
morning.


1. https://review.openstack.org/#/c/539126/

best regards,
Masahito


__
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] [blazar][release] release job configuration issues

[Masahito MUROI]

Thanks for the help.

I've already pushed patches for updating the release job of 
blazar-nova[1] and blazar-dashboard[2]. The two patches are under review 
now and added as Depends-On links.



1. https://review.openstack.org/#/c/538182/
2. https://review.openstack.org/#/c/538185/

best regards,
Masahito



On 2018/01/30 9:27, Doug Hellmann wrote:

Both blazar-dashboard and blazar-nova have configuration issues blocking
their release and the release team needs input from the blazar team to
resolve the problems.

The validation output for blazar-dashboard [2] shows that the repo is
being treated as a horizon plugin but it is configured to use the
release-openstack-server jobs. We think the correct way to resolve this
is to update project-config to use publish-to-pypi-horizon. However, if
horizon is not needed then project-config should be updated to use
publish-to-pypi and the release-type in [1] should be updated to
"python-pypi".

The validation output for blazar-nova shows a similar problem [4]. In
this case, we think the correct solution is to change project-config so
that the repo uses publish-to-pypi instead of release-openstack-server.

Please update those settings and update the release requests with
Depends-On links to the project-config patches so we can process the
releases.

Doug

[1] https://review.openstack.org/#/c/538175/
[2] 
http://logs.openstack.org/75/538175/3/check/openstack-tox-validate/7ed5005/tox/validate-request-results.log
[3] https://review.openstack.org/#/c/538139/
[4] 
http://logs.openstack.org/39/538139/5/check/openstack-tox-validate/05a7503/tox/validate-request-results.log

__
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] [blazar][release] we need a new blazar client release

[Masahito MUROI]

Hi Doug,

Thanks for the info and fixes. I pushed a patch for blazar client 1.0.1 
release[1].


1. https://review.openstack.org/538368

best regards,
Masahito

On 2018/01/27 6:44, Doug Hellmann wrote:

Excerpts from Doug Hellmann's message of 2018-01-26 16:41:23 -0500:

The PyPI service is now validating package metadata more strictly, and
the classifier values for python-blazarclient do not pass the validation
checks. This means the 1.0.0 package we built cannot be uploaded to
PyPI [1].

The fix will take several steps.

1. dmsimard has proposed [2] to master to fix the classifiers.

2. However, since the repository has
already been branched for queens we will also need to backport
that fix to stable/queens.  David has proposed that backport in
[3].

3. There are 2 other patches in stable/queens that need to be
approved as well [4].

4. After they are all merged we can release 1.0.1 from the stable/queens
branch using the SHA for the merge commit created when [3] lands.

So, blazar team, please approve all of those patches and then propose a
new 1.0.1 release quickly.

Doug

[1] 
http://logs.openstack.org/1d/1d46185bf1e0c18f69038adedd37cf6f6eaf06ab/release/release-openstack-python/13aa058/ara/result/26cee65c-b3cd-4267-9a03-1fe45be043d4/
[2] https://review.openstack.org/538340 Remove commas in setup.cfg package 
classifiers
[3] https://review.openstack.org/538343
[4] 
https://review.openstack.org/#/q/status:open+project:openstack/python-blazarclient+branch:stable/queens


In order to speed things along, I'm going to go ahead and use my release
manager ACLs to approve those stable branch changes. So please approve
the one on master so your next release there won't have the same issue.

Doug

__
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] [Blazar] Rocky PTG planning

[Masahito MUROI]

Hi all,

The PTG is coming in next month. It's good time to start to listing 
topics we discuss now.


Feel free to write down your ideas on the etherpad[1].

1. https://etherpad.openstack.org/p/blazar-ptg-rocky

best regards,
Masahito


__
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] [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

[Masahito MUROI]

Hi Gerg0 and Jay,

Thanks for the replay. I just mentioned the privilege for MANO/NFVO and 
what they can do with the privilege as Jay said.


IMO, MANO/NFVO needs the admin privileges for some operations, e.g. 
creating a new tenant/project for a new VNFM or migrating a VM for 
failure recovery.


best regards,
Masahito


On 2017/12/12 2:41, Csatari, Gergely (Nokia - HU/Budapest) wrote:

Hi Jay,

Okay. Thanks for the clarification. Makes sense.

Random-thinking:
Maybe the best would be to have a privilege level what covers the needs of 
MANO/NFVO, but still not full admin privileges. Do you think is this possible?

Br,
Gerg0

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Monday, December 11, 2017 4:41 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [etsinfv][gap-04][blazar]: Clarification on the 
scope of the capacity query

On 12/11/2017 07:24 AM, Csatari, Gergely (Nokia - HU/Budapest) wrote:

Hi Masahito,

Thanks for the answer.
Some clarification questions. You mention that the NFVO works as both an user 
and an admin for the cloud. Is this becouse the resource usage per user info is 
more for cloud operators while the resource usage per tenant / per resource 
provider is more for cloud users?

The solution you described is valid for the capacity per tenant case if I 
understand right. Is this correct?


I think he is more referring to the fact that the MANO/NFVO service user must 
have administrative privileges in order to, for example, spawn new instances in 
multiple projects/tenants and communicate with the control plane to do things 
like adjust quotas, etc.

Best,
-jay

__
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




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539


__
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] [etsinfv][gap-04][blazar]: Clarification on the scope of the capacity query

[Masahito MUROI]

Hi Gerg0,

I added some comments for GAP-04. It looks like NFVO works as an tenant 
user and an operator. IMHO, NFVO could calculate the capacity of the cloud.


best regards,
Masahito


On 2017/12/06 22:10, Csatari, Gergely (Nokia - HU/Budapest) wrote:

Hi,

During the Forum session about the ETSI NFV Gaps I received a request to 
clarify the scope of the capacity query mentioned in [GAP-04] with ETSI NFV.


The advice is that it should be possible to get the capacity of an 
OpenStack tenant, an user and a resource provider. This is because the 
NFVO might use different tenants and even different users to manage the 
resources in the OpenStack instances.


Any comments are welcome, also if you need more clarification on the 
gaps listed in [1] do not hesitate to contact me.


Br,

Gerg0

[1]: 
https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-explained




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

[Masahito MUROI]

Hi Blazar folks,

Blazar team skips the next weekly meeting since some of us will join the 
Sydney Summit.


best regards,
Masahito


__
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] [Blazar] Team mascot idea

[Masahito MUROI]

Hi Blazar folks,

As we discussed the topic in the last meeting, we're gathering an idea 
for the project mascot[1].


Current ideas are following fours. If you have or come into mind another 
idea, please replay this mail.  We'll decided the candidacy at the next 
meeting.


- house mouse
- squirrel
- shrike
- blazar


1. https://www.openstack.org/project-mascots

best regards,
Masahito


__
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] [Blazar] Blazar is now an official OpenStack project

[Masahito MUROI]

Hello everyone,


I'd like to announce the great news; Blazar[1], Resource Reservation 
Service, was accepted into the official project last week.


First of all, thank you so much from the bottom of my heart to everyone 
who has joined previous Blazar's activities and current Blazar's 
activities.  I believe the all activities push the project status forwards.


We have a weekly IRC meeting[2] to discuss features, implement and 
review codes. We're improving Blazar project actively now. So if you 
have an interest to Blazar, we welcome everyone to join Blazar project.



1. https://wiki.openstack.org/wiki/Blazar
2. http://eavesdrop.openstack.org/#Blazar_Team_Meeting

best regards,
Masahito


__
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] [Blazar] PTG recap

[Masahito MUROI]

Hi all,

This is a summary of Queens PTG discussion for Blazar. We had lots of 
items in the meeting. So I write down main topics in the mail. If you're 
interested in all items, please see the queens PTG etherpad page[1].


Priorities for Queens cycle
---

We discussed our team priorities for Queens cycle. The main themes for 
the release are resiliency and manageability.  For resiliency, Blazar 
will support a recovering feature from reserved resource failure and 
atomic API transactions. For manageability, Blazar will follow some 
community wide goals and will be refactored about its plugins.


If you'd like to see more details, please go to the etherpad page[2].

API for querying resource usage/availability
--

This is an usability improvement feature. It enables users to query how 
many/how much/how long they can reserve a specific resource/time. 
Blazar supports APIs which provide reservations CRUD operation for users 
now. So users don't have a way to check how many resources are available 
at a specific time window. By the API, users can query how many 
resources are available at a specific time.



Resource Monitoring
---

This is a kind of resource failure recovery mechanism in Blazar. Blazar 
doesn't react reserved resource failures now. For instance, if a 
hypervisor which is reserved by an user for future usage goes down, 
Blazar doesn't re-assign a new hypervisor for the user's reservation. 
By the resource monitoring feature, Blazar will manage reservations well 
against unexpected failures.



Preemptible instance


This topic is one of discussions in Nova team[3] and Blazar team was 
involved in the discussion.  Blazar is one of possibilities for "reaper" 
service in the topic since Blazar has a time base reaping feature in 
instance reservation feature of Blazar.  So Blazar team has interest to 
support the feature.



1. https://etherpad.openstack.org/p/blazar-ptg-queens
2. https://launchpad.net/blazar/+milestone/0.4.0
3. 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122258.html



best regards,
Masahito


__
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] [Blazar] Schedule for Denver virtual PTG

[Masahito MUROI]

Dear Blazar folks,

The room for physical attendances are changed. The new room is Pikes 
Peak on the third floor.


best regards,
Masahito

On 2017/09/06 15:57, Masahito MUROI wrote:

Dear Blazar folks,

As we discussed in previous weekly meetings, Blazar team will have 
virtual PTG meetup for Queens cycle because some of core members can't 
come there.  The schedule and topics is available in the etherpad page[1]


For the attendances of the PTG, the team reserves a room for the 
discussion. So if you have an interest for the project, let's join the 
meeting.


1. https://etherpad.openstack.org/p/blazar-ptg-queens

best regards,
Masahito


__
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] [Blazar] skip weekly meeting

[Masahito MUROI]

Hi Blazar folks,

Blazar team skips the weekly meeting this week because of PTG week. The 
team has virtual meetup in the week instead of the ordinary meeting.


https://etherpad.openstack.org/p/blazar-ptg-queens

best regards,
Masahito


__
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] [Blazar] Schedule for Denver virtual PTG

[Masahito MUROI]

Dear Blazar folks,

As we discussed in previous weekly meetings, Blazar team will have 
virtual PTG meetup for Queens cycle because some of core members can't 
come there.  The schedule and topics is available in the etherpad page[1]


For the attendances of the PTG, the team reserves a room for the 
discussion. So if you have an interest for the project, let's join the 
meeting.


1. https://etherpad.openstack.org/p/blazar-ptg-queens

best regards,
Masahito


__
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] [Blazar] Blazar 0.3.0 (pike) released

[Masahito MUROI]

Hello everyone,

A new release of Blazar project for Pike cycle was released last week. 
The release is tagged with 0.3.0 tag in each Blazar's repository.


The quick summary of the release is following:

* support the new instance reservation
* support horizon dashboard
* support fine-grained API for reservations


Blazar teams did lots of activities in the cycle. You can see the list 
of all implemented BPs and fixed bugs in the Pike cycle at the launchpad 
page[1].


1. https://launchpad.net/blazar/0.x.0/0.3.0

best regards,
Masahito


__
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] [Blazar] PTL Candidacy for Queens

[Masahito MUROI]

Dear everyone,

I'd like to announce my candidacy as Blazar PTL for the Queens release 
cycle.


I served as PTL for the Blazar project during Pike cycle. And I would 
like to continue to do in the next cycle.


During the Pike cycle, the Blazar team made tons of progress for 
resolving feedback by operators as well as implementing the Blazar 
features and bug fixes.  The team has made v1 API more manageable for 
users, implemented Horizon plugin and the instance reservation support. 
The big improvement was supported by the development cycle between 
operators and developers.


In the Queens cycle I'd like to focus on the following things:

- Blazar's Features: improving resiliency and user experience

The Blazar started to support 2 types of reservation, host reservation 
and instance reservation, from Pike release.  The two reservation 
features are motivated by real users. In the real deployment, resiliency 
is one of key points for the reservation service.


Additionally, the team mainly focused on server-side developments during 
the last two cycle. The development made the blazar server and its 
features stable. So it's good time to improve the user experience of the 
stable feature in the next cycle.


- Community: Encouraging the team to be more diverse

The team's activities in the Pike cycle become 1.5 times bigger than the 
Ocata cycle. Beside the big growth, most of the activities were done by 
the team members who revived the project since the Barcelona Summit.


Different perspectives from people who have different backgrounds and 
demands make good developments in the next or later release. So I'd like 
to encourage more people to join this team.



best regards,
Masahito



__
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] [Blazar] review meeting date for Pike release

[Masahito MUROI]

Hi Blazar folks,

As we discussed in the last weekly meeting, the team has a patch review 
meeting for Pike release.  In the meeting the team reviews patches 
targeting to Pike release is ready to merge or not. And if not, we 
decide what's needed to fix before merge.


The meeting date is 9am on 8/3 and 8/7 (Option) at #openstack-blazar 
channel.


best regards,
Masahito


__
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] [Blazar] skip weekly meeting

[Masahito MUROI]

Hi Blazar folks,

Based on the discussion on previous meeting, Today's weekly meeting is 
skipped because some of core member can't join the meeting.


best regards,
Masahito


__
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] [Blazar] Skip weekly meeting

[Masahito MUROI]

Hi Blazar folks,

Based on the discussion in last meeting, the team will not have the 
weekly meeting this week because most of the members are out of town.


Next meeting is planed to be 20th Jun.

best regards,
Masahito


__
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] [tc][Blazar] steps to big-tent project

[Masahito MUROI]

Dear TC team,

Blazar team is thinking to push a request about adding Blazar project 
into the OpenStack BigTent.


Based on documents in the governance repository[1], what the team is 
required to do for the request is just adding project's definition to 
references/projects.yaml. Is there another thing to do as Blazar team?


1. https://github.com/openstack/governance


best regards,
Masahito



__
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] [Blazar] Boston Summit Recap

[Masahito MUROI]

Hi everyone,

Blazar team had some meetings, a forum and a presentation at Boston  
summit last week.  This mail is a quick summary of the activities. If  
more details are needed, please check links listed at the bottom of this  
mail.


* Blazar team meetings

Blazar team had 2 meetings [1], one was for Blazar internal features and  
another was for collaborations with PlacementAPI team.  Both meetings  
were well successful by all of the team members.


At internal features meeting, we reached work items for all topics  
covered in the meetings.  All items will start soon, but if you have an  
interest and want to pick up an item to join the team activities, feel  
free to pick and start one of the items.


At collaborations meeting, we showed feature visions of each team as  
well as how both teams can collaborate with the API.  As a result of the  
discussion, we agreed to why and how blazar use PlacementAPI.


* Forum session

The advanced instance scheduling[2] was one of forum sessions related to  
Blazar project.  At the session, there were two topics, pre-emptable  
instances and reservations.  Based on the discussion, requests were  
shown for "reservation" and the team tries to solve the problem.


* Project update track

Blazar team had project update track[3] in general session. We  
appreciate a chance to have the track for PWG and the foundation. In the  
session, we talked overview of Blazar project, key enhancements in Ocata  
and key enhancements for Pike.



1. https://etherpad.openstack.org/p/blazar-boston-summit
2. https://etherpad.openstack.org/p/BOS-forum-advanced-instance-scheduling
3. https://www.openstack.org/videos/boston-2017/project-update-blazar

best regards,
Masahito


__
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] [Blazar] Meeting time slots in Boston

[Masahito MUROI]

Hi all,

I reserved hacking rooms, Hynes, MR 109, for both meetings.  I'm looking 
forward to seeing you all in Boston!


https://ethercalc.openstack.org/Boston_Forum_Hacking_Rooms

best regards,
Masahito

On 2017/04/21 13:41, Masahito MUROI wrote:

Hi all,

Thanks for choosing time slots!  Based on the table of Doodle, I'd like
to pick following two slots for Blazar team meeting.

1. 1pm-4pm on Monday for Blazar's internal features
2. 9am-10am or 11am on Thursday for discussions with PlacementAPI team

The first meeting will focus on Blazar's internal features, roadmap and
etc.  1pm-2pm is also Lunch time. So it could start as lunch meeting.

In the second slot, we plan to discuss with PlacementAPI team. Summit
would have breakout rooms or tables as usual.  We'll gather one of these
and discuss concerns and/or usecases of collaboration with PlacementAPI.


best regards,
Masahito


On 2017/04/18 13:21, Masahito MUROI wrote:

Hi Blazar folks,

I created doodle[1] to decide our meeting time slots in Boston summit.
Please check slots you can join the meeting by Thursday.  I'll decide
the slots on this Friday.

Additionally, I'd like to ask you to write down how many hours we have
the meeting in comments of the page.

1. http://doodle.com/poll/a7pccnhqsuk9tax7

best regards,
Masahito


__

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






--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539


__
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] [Blazar] Meeting time slots in Boston

[Masahito MUROI]

Hi all,

Thanks for choosing time slots!  Based on the table of Doodle, I'd like 
to pick following two slots for Blazar team meeting.


1. 1pm-4pm on Monday for Blazar's internal features
2. 9am-10am or 11am on Thursday for discussions with PlacementAPI team

The first meeting will focus on Blazar's internal features, roadmap and 
etc.  1pm-2pm is also Lunch time. So it could start as lunch meeting.


In the second slot, we plan to discuss with PlacementAPI team. Summit 
would have breakout rooms or tables as usual.  We'll gather one of these 
and discuss concerns and/or usecases of collaboration with PlacementAPI.



best regards,
Masahito


On 2017/04/18 13:21, Masahito MUROI wrote:

Hi Blazar folks,

I created doodle[1] to decide our meeting time slots in Boston summit.
Please check slots you can join the meeting by Thursday.  I'll decide
the slots on this Friday.

Additionally, I'd like to ask you to write down how many hours we have
the meeting in comments of the page.

1. http://doodle.com/poll/a7pccnhqsuk9tax7

best regards,
Masahito


__
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



--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539


__
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] [Blazar] Meeting time slots in Boston

[Masahito MUROI]

Hi Blazar folks,

I created doodle[1] to decide our meeting time slots in Boston summit.  
Please check slots you can join the meeting by Thursday.  I'll decide  
the slots on this Friday.


Additionally, I'd like to ask you to write down how many hours we have  
the meeting in comments of the page.


1. http://doodle.com/poll/a7pccnhqsuk9tax7

best regards,
Masahito


__
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] [scientific] Resource reservation requirements (Blazar) - Forum session

[Masahito MUROI]

onsume
   resources on the compute hosts that are "reserved" by this paying
   customer at some date in the future? i.e. Spot instances that can be
   killed off as necessary by the reservation system to free
resources to
   meet its reservation schedule?

   > The are a couple of problems with putting this outside of Nova
though.
   > The main issue is that pre-emptible/spot type instances can't be
   > accommodated within the on-demand cloud capacity.

   Correct. The reservation system needs complete control over a
subset of
   resource providers to be used for these spot instances. It would
be like
   a hotel reservation system being used for a motel where cars could
   simply pull up to a room with a vacant sign outside the door. The
   reservation system would never be able to work on accurate data
unless
   some part of the motel's rooms were carved out for reservation
system to
   use and cars to not pull up and take.

>  You could have the
   > reservation system implementing this feature, but that would
then put
   > other scheduling constraints on the cloud in order to be effective
   > (e.g., there would need to be automation changing the size of the
   > on-demand capacity so that the maximum pre-emptible capacity was
   > always available). The other issue (admittedly minor, but still a
   > consideration) is that it's another service - personally I'd
love to
   > see Nova support these advanced use-cases directly.

   Welcome to the world of microservices. :)

   -jay

   ___
   OpenStack-operators mailing list
   OpenStack-operators@lists.openstack.org
<mailto:OpenStack-operators@lists.openstack.org>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators




___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
<mailto:OpenStack-operators@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators




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



--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



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

[openstack-dev] [Blazar] tempest gate job failure

[Masahito MUROI]

Hi blazar team,

Tempest gate job is now activated by the patch[1], but now it's always  
fails because of syntax error in the tempest job. I'm sorry to brake  
reviews.


I'm also pushing the patch[2] to fix the problem. If you have time,  
please take a look for the patch.


1. https://review.openstack.org/#/c/452635/
2. https://review.openstack.org/#/c/455683/

best regards,
Masahito



__
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] [Blazar] new instance reservation overview

[Masahito MUROI]

Hi Blazar folks,

I drafted overview of new instance reservation [1]. It contains  
motivation and basic idea of the reservation, short-term goal and  
long-term goal.


It's just a draft and entry points for the discussion. We would also  
discuss some reservations things based on the etherpad at Boston Forum.  
So feel free to add your comments.


1. https://etherpad.openstack.org/p/new-instance-reservation

best regards,
Masahito



__
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] [scientific] Resource reservation requirements (Blazar) - Forum session

[Masahito MUROI]

Hi all,

I'm late to the discussion.

Some of members in Blazar's team have an interest from NFV side for the 
resource reservation.  So we have one usecase that telecom operators 
want to reserve instance slots at a specific time window because of 
expected workload increasing.


I'm thinking the challenge of current Blazar is how to realize two 
demands, one from scientific group and another from NFV, for the 
resource reservation.


On 2017/04/05 2:21, Jay Pipes wrote:
> On 04/03/2017 06:07 PM, Blair Bethwaite wrote:
>> Hi Jay,
>>
>> On 4 April 2017 at 00:20, Jay Pipes  wrote:
>>> However, implementing the above in any useful fashion requires that
>>> Blazar
>>> be placed *above* Nova and essentially that the cloud operator 
turns off

>>> access to Nova's  POST /servers API call for regular users. Because
>>> if not,
>>> the information that Blazar acts upon can be simply circumvented by
>>> any user
>>> at any time.
>>
>> That's something of an oversimplification. A reservation system
>> outside of Nova could manipulate Nova host-aggregates to "cordon off"
>> infrastructure from on-demand access (I believe Blazar already uses
>> this approach), and it's not much of a jump to imagine operators being
>> able to twiddle the available reserved capacity in a finite cloud so
>> that reserved capacity can be offered to the subset of users/projects
>> that need (or perhaps have paid for) it.
>
> Sure, I'm following you up until here.
>
>> Such a reservation system would even be able to backfill capacity
>> between reservations. At the end of the reservation the system
>> cleans-up any remaining instances and preps for the next
>> reservation.
>
> By "backfill capacity between reservations", do you mean consume
> resources on the compute hosts that are "reserved" by this paying
> customer at some date in the future? i.e. Spot instances that can be
> killed off as necessary by the reservation system to free resources to
> meet its reservation schedule?
>
>> The are a couple of problems with putting this outside of Nova though.
>> The main issue is that pre-emptible/spot type instances can't be
>> accommodated within the on-demand cloud capacity.
>
> Correct. The reservation system needs complete control over a subset of
> resource providers to be used for these spot instances. It would be like
> a hotel reservation system being used for a motel where cars could
> simply pull up to a room with a vacant sign outside the door. The
> reservation system would never be able to work on accurate data unless
> some part of the motel's rooms were carved out for reservation system to
> use and cars to not pull up and take.
I agree the reservation system looks like hotel reservation system. But 
Blazar provides a reservation system like a block reservation. Operators 
defines a pool used for the future reservation requests. Then they give 
id or something to an user when the user requests a reservation. The 
user creates their resource with the id and it could be located inside 
of the block reservation only if the user consumes the reservation in 
the specified time window.


Of course, as you mentioned above, regular users could creates a 
resource and it could violate the reservation assumptions.  IIRC, 
however, same situation could happen in other projects, for instance 
Heat's stack.


What Blazar does is creating/configuring aggregations or other things 
that drive resources of regular users to be scheduled to outside of the 
block reservation.  Or regular users can create their resources with a 
special flag and the resources could be located inside of the block 
reservation. But operators can't ensure the resources remains until the 
users say 'delete the resources' because Blazar could clean-up the 
resources before others reservation starts.


>
>>  You could have the
>> reservation system implementing this feature, but that would then put
>> other scheduling constraints on the cloud in order to be effective
>> (e.g., there would need to be automation changing the size of the
>> on-demand capacity so that the maximum pre-emptible capacity was
>> always available). The other issue (admittedly minor, but still a
>> consideration) is that it's another service - personally I'd love to
>> see Nova support these advanced use-cases directly.
>
> Welcome to the world of microservices. :)
>
> -jay

best regards,
Masahito




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

Re: [OpenStack-Infra] [gerrit] Fais to apply the change in project-config to gerrit

[Masahito MUROI]

Hi Jeremy,

I can see the "Create Branch" button on gerrit now.  Thanks for clear 
details of what happened in infra side.


best regards,
Masahito

On 2017/04/03 22:56, Jeremy Stanley wrote:

On 2017-04-03 16:35:58 +0900 (+0900), Masahito MUROI wrote:

I've pushed the change[1] to project-config repo and it's already been
merged. However, the change fails to be applied to gerrit board. I heard the
reason of the failure is some bugs happend in infra.


It looks applied to me at this point. We corrected some recent
regressions introduced by a new caching implementation in the
manage-projects script which applies those ACLs, and it looks like
your change merged on March 10 when this was definitely still a
problem:

https://review.openstack.org/442940

The change seems to have finally been pushed into Gerrit last
Thursday:


https://review.openstack.org/gitweb?p=openstack/blazar.git;a=commitdiff;h=c72744a

...which is when Monty reran our manage-projects script with a
cleared cache:


http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-03-30.log.html#t2017-03-30T15:25:35


Where should I track or report the failure? I couldn't fine the launchpad.

[...]

Task and defect tracking for Infra deliverables are managed on
storyboard.openstack.org, for example openstack-infra/project-config
is:

https://storyboard.openstack.org/#!/project/731

But in this case the issue is (we think) already solved, so I
wouldn't bother filing a defect report about it at this point.





___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] [gerrit] Fais to apply the change in project-config to gerrit

[Masahito MUROI]

Hello infra team,

I've pushed the change[1] to project-config repo and it's already been  
merged. However, the change fails to be applied to gerrit board. I heard  
the reason of the failure is some bugs happend in infra.


Where should I track or report the failure? I couldn't fine the launchpad.

1.  
https://github.com/openstack-infra/project-config/blob/master/gerrit/acls/openstack/blazar.config#L3


best regards,
Masahito



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] Create Branch Access Rights to blazar-release team

[Masahito MUROI]

Dear infra team,

I'd like to add create branch access rights to blazar-release team. I've  
added "create" config option in blazar.config[1], but the change doesn't  
reflect gerrit configuration[2].


Should I need additional changes to somewhere?

1.  
https://github.com/openstack-infra/project-config/blob/master/gerrit/acls/openstack/blazar.config#L3

2. https://review.openstack.org/#/admin/projects/openstack/blazar,access

best regards,
Masahito



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Request to add initial blazar-release team member

[Masahito MUROI]

Thanks Ian

On 2017/03/08 18:21, Ian Wienand wrote:

On 03/08/2017 03:45 PM, Masahito MUROI wrote:

This is a request mail to add me into blazar-release team[1] as an
initial member of the team.


Done

Thanks

-i








___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] Request to add initial blazar-release team member

[Masahito MUROI]

Dear infra team,

This is a request mail to add me into blazar-release team[1] as an  
initial member of the team.


I'm working on Blazar Project as PTL and this team would like to release  
Ocata stable branch and add the release tag. Unfortunately, the  
blazar-release team doesn't has any member.


1. https://review.openstack.org/#/admin/groups/356,members

--
best regards,
Masahito



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[openstack-dev] [Blazar] Skip IRC meeting

[Masahito MUROI]

Some of us are in PTG, then we decided we'll skip the weekly meeting  
this week.


best regards,
Masahito



__
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] [Congress] PTG Friday activities

[Masahito MUROI]

Hi Eric,

Both looks interesting, so I'm ok for either.  If I need to pick one of 
them, I prefer the Aquarium.


Masahito

On 2017/02/16 8:06, Eric K wrote:

Hi all,

Here are some options (thinrichs originally suggested) we could consider
for a Friday daytime outing for those interested.

Anyone interested?
Any other ideas?

Georgia Aquarium
- 1st or 2nd largest aquarium in the world.
- #1 on tripAdvisor
- $31.95+tax/adult (advanced online purchase)
http://www.georgiaaquarium.org
https://www.tripadvisor.com/Attraction_Review-g60898-d588792-Reviews-Georgia_Aquarium-Atlanta_Georgia.html

Atlanta Botanical Garden
- #3 on tripAdvisor
- $21.95+tax/adult
http://atlantabg.org
https://www.tripadvisor.com/Attraction_Review-g60898-d104713-Reviews-Atlanta_Botanical_Garden-Atlanta_Georgia.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




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
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] [Blazar] bug list before next release

[Masahito MUROI]

Hi Hiroaki,

> I have a question about namespace migration.
> Do we completely remove climate namespace from blazar repo?
IMO, we should remain climate namespace at least one release cycle. 
Someone could have their own plugin for blazar with climate namespace. 
If it remains in next one cycle, they can convert their plugin to blazar 
namespace without a big pain.


best regards,
Masahito

On 2017/02/08 17:18, Hiroaki Kobayashi wrote:

Hi Masahito

Thank you for listing tasks for Blazar 0.2.0 release.

I have a question about namespace migration.
Do we completely remove climate namespace from blazar repo?

If so, I want to add one more task "Remove climate namespace from
blazar-nova repo" because namespace has been already migrated to blazar
but climate namespace still existed in blazar-nova repo.

Best regards,
Hiroaki

On 29/02/08 11:59, Masahito MUROI wrote:

Hello Blazar folks,

I listed all tasks needed to do by 0.2.0 release. Let's pick up bugs and
don't forget to add you as an Assignee.

https://launchpad.net/blazar/+milestone/0.2.0

best regards,
Masahito



__

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

[openstack-dev] [Blazar] bug list before next release

[Masahito MUROI]

Hello Blazar folks,

I listed all tasks needed to do by 0.2.0 release. Let's pick up bugs and  
don't forget to add you as an Assignee.


https://launchpad.net/blazar/+milestone/0.2.0

best regards,
Masahito



__
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] [Blazar] PTL Candidacy for Pike

[Masahito MUROI]

Hi everyone,

This is my candidacy as Blazar PTL for Pike release cycle. I'm pleased  
to announce the self-nomination since some developers got gathered for  
re-activate Blazar project in Barcelona summit, then we've started  
current activities.


First of all, I'd like to thanks all developers involved in previous  
Blazar activities. If the great activities are nothing, we need to think  
of our goal from scratch and can't move forward fast we have now.


We all have concrete usecase and demands using Blazar in production even  
if the current activities have started from few months ago. I try to  
move forward the activities and realize our requirements by Blazar  
coming from different technical areas, if elected.


For achieving the goal I'd like to focus on the following in Pike cycle:

* Blazar's Features: Making host reservation feature stable and also  
starting to support another resources


The current main activity is making host reservation feature stable  
since all of us needs it at least. I'm sure we'll achieve it in next  
cycle because of recent active discussion and activity.


In addition to the host reservation, I'd like to start supporting  
reservation of another resource for our usecase. I'd think the goal is  
more challenging and difficult than host one, but I believe the team can  
achieve it since all of this team members has great knowledge and skills.


* Community: Encouraging diversity to this team

The latest activities have been started by few members. It causes this  
team looks less diversity.


I'd like to encourage more people to join this team. Encourage meaning  
for increasing its user as well as developers. I believe it gives Blazar  
more useful features and moves this team forwards.


* Blazar's position: Encouraging Blazar to be in BigTents

Blazar project is now out of BigTents project. The motivation of this  
team is making OpenStack more useful by Blazar for each demands or some  
problems. Becoming one of BigTents project is an easy way to share  
solutions to others who have same demands or problems.


best regards,
Masahito



__
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] [Blazar] Meeting in PTG

[Masahito MUROI]

Hi Blazar folks,

Blazar team is thinking of whether having a meeting in PTG or not. IIRC,  
most of the team members is also a member of another team. So if  
someones are in PTG and has free time slot, we could have blazar team  
meeting in PTG.


Of cause, we don't have official rooms and time slots in PTG. So the  
meeting would be short and like ad-hock meeting style. But we could have  
good progress in there.


Does anyone in the team plan to go PTG? And should we have meeting in  
PTG?  Please let me know your ideas.


best regards,
Masahito



__
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] [Blazar] Blazar weekly teem meeting starts again

[Masahito MUROI]

Hi Stackers,

I'm happy to announce it in openstack-dev ML that weekly Blazar team  
meeting is going to start again from 6th Dec.


Some of folks who are interested in resource reservation feature met  
together in Barcelona summit and agreed to re-start the project. As a  
first step for resurrecting the project, we'll start team activity from  
now on.


Following are meeting details. The meeting info[1] is now in review  
status, so if it's not merged by the time, we will use #openstack-blazar  
for the first meeting. Feel free to join it!!


Meeting days: Tuesday 9:00am UTC
Meeting channel: #openstack-meeting-alt

1. https://review.openstack.org/#/c/406667/

best regards,
Masahito



__
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] [Congress] PTG planning

[Masahito MUROI]

Thanks summarizing it, Eric.

Combination of 1. and 2. looks good.

Basically, we'll have work sessions in PTG for next release. Other teams 
and operator could come, so it's easy for Congress team to discuss 
anything with them.


Then if needed, we can have unofficial work session of Congress team at 
summit instead of mid-cycle. We don't need to consider hosts and 
location. Additionally, we could meet Congress user who has a 
presentation and nice usecase but doesn't contribute actively.


best regards,
Masahito

On 2016/10/06 16:53, Thierry Carrez wrote:

Good summary. It is true that for small-to-medium sized teams (which did
not routinely organize midcycles), there is a tough choice to make.

See a couple of remarks inline:

Eric K wrote:

Here are some of our choices as a team, as well as some first thoughts on
pros and cons:

1. Do work sessions at PTGs; no organized work sessions at summits.
Pro: schedule lines up wit beginning of dev cycle
Pro: work room available
Pro: easy to collaborate with other teams
Con: extra travel for those who will continue to attend summit.


+Pro: PTGs are organized in cheaper locations and closer to the center
of mass of contributors, hopefully making it less costly to travel to
overall
+Pro: More team time (for Congress: 2-3 days instead 2-3 hours) for a
better return on travel investment


2. Unofficial work session at summits; no work sessions at PTGs.
Pro: For people who would be going to the summits anyway, this option
reduces travel.
Con: probably no official work room available.
Con: happens at the middle of a dev cycle

3. Separately organize work sessions in the style of past mid-cycle
sprints; no work sessions at any of the official openstack events.
Pro: we can choose schedule and location
Con: harder to collaborate with other teams


+Con: extra travel for those who will continue to attend summit




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
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] [Congress] Default devstack deployment config

[Masahito MUROI]

Hi Congress folks,

I'm in favor of single process for devstack default. It's easy to check
logs and tests its feature.

best regards,
Masahito

On 2016/09/13 11:00, Tim Hinrichs wrote:

I'd agree with a single process version of Congress for devstack.  I'd
say we should even do that for Newton.

Tim

On Mon, Sep 12, 2016 at 6:34 PM Eric K <ekcs.openst...@gmail.com
<mailto:ekcs.openst...@gmail.com>> wrote:

Hi all,

I want to get people’s thoughts regarding what we should set as
default devstack deployment config for Ocata.
At the moment, it is set to deploy three processes: API, policy, and
datasource-drivers.

I see some potential arguments against that:

 1. For most users installing via devstack, running Congress in
three processes bring little benefit, but rather a more complex
and less stable user experience. (Even if our code is perfect,
rabbitMQ will timeout every now and then)
 2. It’s not clear that we want to officially support separating the
API from the policy engine at this point. The supported
deployment options for HAHT do not need it.

The main argument I see for deploying three processes by default is
that we may get more bug reports regarding the multi-process
deployment that way.

Our main options for devstack default are:
1. Single-process Congress (with in-mem transport).
2. Two-process Congress API+Policy, datasource-drivers. (other
breakdowns between two processes are also possible)
3. Three-process Congress.

In the end, I think it’s a trade-off: potentially getting more bug
reports from users, at the expense of a more complex and less
polished user experience that could make a poor first impression.
What does everyone think?

Personally, I slightly favor defaulting to single process Congress
because from a typical devstack user’s perspective, there is little
reason to run separate processes. In addition, because it is the
first time we’re releasing our complete architecture overhaul to the
wild, and it may be a good to default to the least complex
deployment for the first cycle of the new architecture.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://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




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
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] [Congress] Enabling Remote Debugging

[Masahito MUROI]

Hi Aimee,

Thanks let us know.

I don't think it has a big impact to the current architecture and 
user/dev. So it seems to be good to report it as a bug and target the 
fix to N-release.


best regards,
Masahito

On 2016/09/02 10:10, Eric K wrote:

Hi Aimee,

Thanks for digging into it!

Here¹s my understanding of our conventions (and I¹m happy to hear from
others).

a. If you think it¹s just a straightforward change with zero to minimal
impact on architecture, users, and devs, then it makes sense to file a bug
or just submit a patch.
b. If you think it warrants deeper discussion in terms of design, impact,
etc., then the process is to create a spec and associated blueprint. See
this wiki for more details:
https://wiki.openstack.org/wiki/Blueprints#Spec_.2B_Blueprints_lifecycle

In case (b), the change should target the O-cycle because we¹re past
feature-freeze in N.
In case (a), it may make sense to get it in during the N-cycle if it has
minimal impact and will help us in the N-cycle QA process.

My guess is we¹re in case (a) because we can make sure changes have no
impact without a special flag. But I¹d also like to understand a little
better the impact of eventlet.monkey_patch(thread=False) as done in the
Keystone patch (https://review.openstack.org/#/c/18404/3/bin/keystone-all).

Enjoy the time holidays!

On 9/1/16, 11:45 AM, "Aimee Ukasick" <aimeeu.opensou...@gmail.com> wrote:


HI all - I've been trying to configure remote debugging with PyCharm
and DevStack. It looks like some tiny modifications need to be made to
the Congress code (3-4 files) to support remote debugging via pydevd.

As far as I can tell, support has been added to Keystone, Glance,
Nova, and Manilla (and I'm sure others).

Keystone patch: https://review.openstack.org/#/c/18404/3
Glance patch: https://review.openstack.org/#/c/18748/5

I think it would be very beneficial to support remote debugging, and
I'm willing to implement the changes needed. Should I create a bug for
this or draft a blueprint?

I'm out of office 2-5 Sept for the US Labor Day holiday, so I could
start on this on 6 Sept.

As always, I appreciate all your comments.

Thanks.

aimee

irc:aimeeu

__
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





--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
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] [congress] Spec for congress.conf

[Masahito MUROI]

Hi Bryan,


On 2016/05/28 2:52, Bryan Sullivan wrote:

Masahito,

Sorry, I'm not quite clear on the guidance. Sounds like you're saying
all options will be defaulted by Oslo.config if not set in the
congress.conf file. That's OK, if I understood.

you're right.



It's clear to me that some will be deployment-specific.

But what I am asking is where is the spec for:
- what congress.conf fields are supported i.e. defined for possible
setting in a release

Your generated congress.conf has a list of all supported config fields.


- which fields are mandatory to be set (or Congress will simply not work)
- which fields are not mandatory, but must be set for some specific
purpose, which right now is unclear
Without deployment-specific configs, IIRC what you need to change from 
default only is "drivers" fields to run Congress with default setting.




I'm hoping the answer isn't "go look at the code"! That won't work for
end-users, who are looking to use Congress but not decipher the
meaning/importance of specific fields from the code.

I guess your generated config has the purpose of each config fields.

If you expect the spec means documents like [1], unfortunately Congress 
doesn't have these kind of document now.


[1] http://docs.openstack.org/mitaka/config-reference/

best regards,
Masahito



Thanks,
Bryan Sullivan


From: muroi.masah...@lab.ntt.co.jp
Date: Fri, 27 May 2016 15:40:31 +0900
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [congress] Spec for congress.conf

Hi Bryan,

Oslo.config that Congress uses to manage config sets each fields to
default value if you don't specify your configured values in
congress.conf. In that meaning, all config is option/required.

In my experience, config values differing from each deployment, like ip
address and so on, have to be configured, but others might be configured
when you want Congress to run with different behaviors.

best regard,
Masahito

On 2016/05/27 3:36, SULLIVAN, BRYAN L wrote:
> Hi Congress team,
>
>
>
> Quick question for anyone. Is there a spec for fields in congress.conf
> file? As of Liberty this has to be tox-generated but I need to know
> which conf values are required vs optional. The generated sample output
> doesn't clarify that. This is for the Puppet Module and JuJu Charm I am
> developing with the help of RedHat and Canonical in OPNFV. I should have
> Congress installed by default (for the RDO and JuJu installers) in the
> OPNFV Colorado release in the next couple of weeks, and the
> congress.conf file settings are an open question. The Puppet module will
> also be used to create a Fuel plugin for installation.
>
>
>
> Thanks,
>
> Bryan Sullivan | AT
>
>
>
>
>
>

__

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


--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
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




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
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] [congress] Spec for congress.conf

[Masahito MUROI]

Hi Bryan,

Oslo.config that Congress uses to manage config sets each fields to 
default value if you don't specify your configured values in 
congress.conf. In that meaning, all config is option/required.


In my experience, config values differing from each deployment, like ip 
address and so on, have to be configured, but others might be configured 
when you want Congress to run with different behaviors.


best regard,
Masahito

On 2016/05/27 3:36, SULLIVAN, BRYAN L wrote:

Hi Congress team,



Quick question for anyone. Is there a spec for fields in congress.conf
file? As of Liberty this has to be tox-generated but I need to know
which conf values are required vs optional. The generated sample output
doesn't clarify that. This is for the Puppet Module and JuJu Charm I am
developing with the help of RedHat and Canonical in OPNFV. I should have
Congress installed by default (for the RDO and JuJu installers) in the
OPNFV Colorado release in the next couple of weeks, and the
congress.conf file settings are an open question. The Puppet module will
also be used to create a Fuel plugin for installation.



Thanks,

Bryan Sullivan | AT





__
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




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
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] [Congress] Nominating Anusha Ramineni and Eric Kao for core reviewer

[Masahito MUROI]

+1.

On 2016/05/14 9:16, Tim Hinrichs wrote:

Hi all,

I'm writing to nominate Anusha Ramineni and Eric Kao as Congress core
reviewers.  Both Anusha and Eric have been active and consistent
contributors in terms of code, reviewing, and interacting with the
community since September--for all of Mitaka and a few months before that.

Anusha was so active in Mitaka that she committed more code than the
other core reviewers, and wrote the 2nd most reviews over all.  She took
on stable-maintenance, is the first person to fix gate breakages, and
manages to keep Congress synchronized with the rest of the OpenStack
projects we depend on.  She's taken on numerous tasks in migrating to
our new distributed architecture, especially around the API.  She
manages to write honest yet kind reviews, and has discussions at the
same level as the rest of the cores.

Eric also committed more code in Mitaka than the other core reviewers.
He has demonstrated his ability to design and implement solutions and
work well with the community through the review process.  In particular,
he completed the Congress migration to Python3 (including dealing with
the antlr grammar), worked through difficult problems with the new
distributed architecture (e.g. message sequencing, test-nondeterminism),
and is now designing an HA deployment architecture.  His reviews and
responses are both thoughtful and thorough and engages in discussions at
the same level as the rest of the core team.

Anusha and Eric: it's great working with you both!

Tim




__
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




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
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] [vitrage] [congress] Vitrage-Congress Collaboration

[Masahito MUROI]

Hi Alexey,

Thanks for clarified! I understood your use-case.

Anyway, as Tim mentioned before, implementing Vitrage driver seems to be 
a good first step to integrate both.


best regards,
Masahito

On 2016/05/10 20:00, Weyl, Alexey (Nokia - IL) wrote:

Hi Masahito,

In addition, I wanted to add that the reason Congress needs to get the data 
from Vitrage by a pushing mechanism and not via polling, is so there won't be a 
delay from when the event occurs and when Congress receives it. Using polling, 
it will take a number of seconds (the polling interval time, 30 seconds by 
default) until Congress will receive the data.

The reason of course why we need it, is to make the whole process work much 
faster, and be consistent with other projects such as OPNFV Doctor (that wants 
events to happen in less than 1 second).

Alexey


-Original Message-
From: Weyl, Alexey (Nokia - IL) [mailto:alexey.w...@nokia.com]
Sent: Tuesday, May 10, 2016 1:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress
Collaboration

Hi Masahito,

Thanks for your question.

There are two main reasons why we need to get alarms from Vitrage
initially.

First, there are alarms that Vitrage generates ("deduced alarms") based
on its user-defined templates and topology. Also, there are alarms that
come from external sources outside of OpenStack, which Aodh and other
projects do not hold. This information could also be valuable for
Congress regardless of the RCA functionality.

Second, since Vitrage retrieves alarms from multiple sources, the RCA
API takes as input the Vitrage-Id of the alarm. To know what that ID
is, you will need to first get the Alarms from Vitrage.

Does this make sense? Would there be a different flow you think could
work?

Best Regards,
Alexey


-Original Message-----
From: Masahito MUROI [mailto:muroi.masah...@lab.ntt.co.jp]
Sent: Tuesday, May 10, 2016 11:00 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress
Collaboration

Hi Alexey,

This use case sounds interesting. To be clarified it, I have a
question.

On 2016/05/10 0:17, Weyl, Alexey (Nokia - IL) wrote:

Hi Tim,

I agree – creating a datasource from Vitrage to Congress is the
first step, and we should have some concrete use case in mind to
help guide this process.

The most straightforward use case I would suggest is when there is

a

problem on an instance that is caused by some problem on the
physical host. Then:

·Vitrage will notify about an alarm on the instance, which Congress
will receive


Why does Congress need to receive the alarm?  DataSouce Driver pulls
data from Vitrage, so it looks like Congress should only pull the
cause of the failure from Vitrage.

Best regards,
Masahito


·Congress can then call the Vitrage RCA API. The response will

state

that the cause of the instance alarm is the host alarm.

·Congress policy can define that in such a case, the instance

should

be migrated to (or healed on) a different physical host

Does this seem like a good first step for you?

Thanks,

Alexey

*From:*Tim Hinrichs [mailto:t...@styra.com]
*Sent:* Saturday, May 07, 2016 2:43 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [vitrage] [congress] Vitrage-

Congress

Collaboration

Hi Alexey,

Thanks for the overview of how you see a Congress-Vitrage
integration being valuable.

I'd imagine that the right first step in this integration would be
creating a new datasource driver within Congress to pull data from
Vitrage.  It doesn't need to pull all the data in your list to
start, but enough so that we can try writing policy over that data.
It's helpful to have a policy in mind that you want to write and
then set up the datasource driver to grab enough of the Vitrage

data

to write that policy.  Here are the relevant docs.

Datasource drivers

http://docs.openstack.org/developer/congress/cloudservices.html

Writing policy

http://docs.openstack.org/developer/congress/policy.html

Let me know if you have any questions,

Tim

On Wed, May 4, 2016 at 11:51 PM Weyl, Alexey (Nokia - IL)
<alexey.w...@nokia.com <mailto:alexey.w...@nokia.com>> wrote:

Hi to all Vitrage and Congress contributors,

We had a good introduction meeting in Austin and we (Vitrage)

think

that we can have a good collaboration between the projects.

Vitrage, as an Openstack Root Cause Analysis (RCA) Engine,
builds

a

topology graph of all the entities in the system (physical,

virtual

and application) from different datasources. It thus can enrich
Congress by providing more data about what is happening in the
system. Additionally, the Vitrage RCA and deduce alarms &

states

mechanism can enhance the visibility of faults and how they
inter-relate.  By using this information Congress could then

execute

different

Re: [openstack-dev] [vitrage] [congress] Vitrage-Congress Collaboration

[Masahito MUROI]

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




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
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] [Doc] place to add API reference

[Masahito MUROI]

Thanks Andreas, I'll check the work and do that.

best regards,
Masahito

On 2016/04/15 16:38, Andreas Jaeger wrote:

On 04/15/2016 08:14 AM, Masahito MUROI wrote:

Hi Doc team folks,

Congress team plans to add API reference into [1] instead of [2] to
follow official documentation project. But I found the design session
about a API docs style[3].

For now, is it ok to add API reference [1], or should we wait the
decision about style of API reference repository?

1. http://developer.openstack.org/api-ref.html
2. http://docs.openstack.org/developer/congress/
3.
https://www.openstack.org/summit/austin-2016/summit-schedule/events/9479?goback=1




See the work that is done by Sean Dague and Anne Gentle for nova and
follow this setup:
http://lists.openstack.org/pipermail/openstack-dev/2016-April/092234.html

There have been a couple more emails in the last months on this topic

Also, there's a spec:
http://specs.openstack.org/openstack/docs-specs/specs/mitaka/app-guides-mitaka-vision.html


so, you should do this in your own repository, set up proper jobs - and
then publish to developer.openstack.org

Andreas


--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
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] [Congress]Authorization mechanisms for each user

[Masahito MUROI]

Hi Yuki,

This sounds interesting. AFAIK, there is no similar use-case you mentioned.

On 2016/04/15 10:13, Yuki Nisiwaki wrote:

Hi openstacker working on congress.

I want to implement the authorization mechanisms for each user, not role
base.
For example, User A can change security group, But User B can’t change
security group like IAM feature of AWS.

In order to achieve it,
I’m considering whether can I utilize Congress feature.
I am thinking somehow that I can achieve it by following step.
1. create policy for each user with datalog in congress
2. prepare the wsgi filter for each project that works confirming
authorization of each user to Congress.
Could you clarify your usecase? I think it can be done by roles and 
modifying policy.json. If you assume A and B are under some conditions, 
what kind of condition do you want to use?


btw, I added [Congress] prefix in the subject.



I think this use-case is very popular and there is someone who think
same thing.
But There is no information about it in any website (blog, presentation
in summit).
So why is there anyone who achieve it?
or does this approach have anxious point?
If you are interested in this approach or think same thing, I want to
know it.


Best regards

Yuki Nishiwaki
NTT Communitions
Technology development
Cloud Core Technology Unit


__
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



best regards,
Masahito


--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
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] [Doc] place to add API reference

[Masahito MUROI]

Hi Doc team folks,

Congress team plans to add API reference into [1] instead of [2] to
follow official documentation project. But I found the design session
about a API docs style[3].

For now, is it ok to add API reference [1], or should we wait the
decision about style of API reference repository?

1. http://developer.openstack.org/api-ref.html
2. http://docs.openstack.org/developer/congress/
3.
https://www.openstack.org/summit/austin-2016/summit-schedule/events/9479?goback=1

best regard,
Masahito

-- 
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
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] [Congress] Guide for all reactive policy options? (execute[...])

[Masahito MUROI]

Hi Bryan,

You can see neutron driver's action with 'openstack congress datasource 
actions show' command.  It shows all execution method supported by 
neutronclient.


btw, the prefix of reaction policy rule is datasource *name*. If you 
initialize openstack like devstack, the datasource name for neutron is 
not neutron but neutronv2.


best regard,
Masahito

On 2016/04/12 14:27, Bryan Sullivan wrote:

Hi Congress team,

I'm trying to develop tests for the reactive policy features of
Congress. I have one such test working, shown at
https://git.opnfv.org/cgit/copper/tree/tests/adhoc/dmz01.sh, which
applies the following rule for pausing a server when there has been an
error in server placement (in a hypothetical "dmz" network environment):
|
"execute[nova:servers.pause(id)] :-
||dmz_placement_error(id),
||nova:servers(id,status='ACTIVE')"

I'm also trying to develop a similar test for deletion of a subnet that
has been defined in a reserved subnet space. But I can't figure out how
to specify the action. I'm currently trying things like:

"execute[neutron:delete_subnet(x)] :- reserved_subnet_error(x)"
or
|||"execute[neutron:subnet.delete(x)] :- reserved_subnet_error(x)"

|Where "reserved_subnet_error" is a table created by matching an
allocated subnet against a list of reserved subnets (e.g. for admin
purposes, and not intended to be made available to VMs).

To help me develop such tests, it would be good to know a complete list
of the "execute" action supported in Liberty (for all services). But I
only see a reference to the nova example above in the docs. I've looked
thru the code for neutron actions but can't find anywhere that a
complete set of supported actions is described, or the syntax for
invoking them in an execute rule.

Any pointers to where I should look (even in the code) is much appreciated.|

Thanks,
Bryan Sullivan


__
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




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
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] [Congress] Push Type Driver implementation

[Masahito MUROI]

/review.openstack.org/294348

$ curl -g -i -X PUT
http://localhost:1789/v1/data-sources/push/tables/data/rows -H
"User-Agent: python-congressclient" -H "Content-Type:
application/json" -H "Accept: application/json" -d '[[1]]'
HTTP/1.1 404 Not Found
Content-Type: application/json; charset=UTF-8
Content-Length: 102
X-Openstack-Request-Id: req-23432974-b107-4657-9bbc-c2e05fd25a98
Date: Thu, 17 Mar 2016 21:13:03 GMT

{"error": {"message": "Not Found::Datasource not found push",
"error_data": null, "error_code": 404}}

Masahito: do you know what the Datasource Not Found problem is? If
not, could you look into it? I ran into it with the Doctor Driver too.

Tim


On Thu, Mar 17, 2016 at 2:31 AM Masahito MUROI
<muroi.masah...@lab.ntt.co.jp <mailto:muroi.masah...@lab.ntt.co.jp>>
wrote:

Hi folks,

This[1] is the driver I mentioned at meeting. It is used for OPNFV
Doctor[2]. So I plan to push it into master in Newton release, since
feature freeze for Mitaka was passed and the schema of its
translator is
    under the discussion.

If it's worth to push it in current release to test push driver,
I don't
mind doing it.

[1]

https://github.com/muroi/congress/blob/doctor-poc/congress/datasources/doctor_driver.py
[2] https://wiki.opnfv.org/doctor

--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://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




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
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] [Congress] Push Type Driver implementation

[Masahito MUROI]

Hi folks,

This[1] is the driver I mentioned at meeting. It is used for OPNFV
Doctor[2]. So I plan to push it into master in Newton release, since
feature freeze for Mitaka was passed and the schema of its translator is
under the discussion.

If it's worth to push it in current release to test push driver, I don't
mind doing it.

[1]
https://github.com/muroi/congress/blob/doctor-poc/congress/datasources/doctor_driver.py
[2] https://wiki.opnfv.org/doctor

-- 
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
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] [Congress] congressclient checks

[Masahito MUROI]

Hi folks,

I checked whether python-congressclient works well or not for M release.
Within my QA for the client, it seems to functionally work well for all
existing API.

Bugs[1][2] I found are only about help messages and output format. So it
means there would be no critical bugs for new release.

1. https://bugs.launchpad.net/python-congressclient/+bug/1550467
2. https://bugs.launchpad.net/python-congressclient/+bug/1552212

best regards,
Masahito

-- 
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
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] [Congress] Issue with glancev2 datasource driver

[Masahito MUROI]

Hi Bryan,

Could you show me debug log of the command using following command? When 
I check the command in my stable/liberty, it works well.


$ openstack congress datasource row list glancev2 images --debug

And if the setting for the driver is valid, it would show you logs about 
glance driver pulling image list from glance itself.


On 2016/02/24 6:01, Bryan Sullivan wrote:

I’m running into an issue with the rows provided by the glancev2 driver
for congress. There are images defined in glance (see below) but no rows
are being returned by congress. Any idea why this might be happening?

Below I query Openstack directly, then try to get the same data thru
congress. I am using the stable/liberty branch, installed yesterday.
This is on the OPNFV Brahmaputra release (not devstack), and most other
congress datasources and functions are working as expected.

Thanks for your help!

Bryan Sullivan | AT

opnfv@jumphost:~/git/python-congressclient$ openstack image list

+--+-+

| ID | Name |

+--+-+

| 98705491-edda-4645-a413-129502190d56 | cirros-0.3.3-x86_64-dmz |

| 59cf60e8-e0ce-48b1-b081-6325c1e1c52b | cirros-0.3.3-x86_64 |

+--+-+

opnfv@jumphost:~/git/python-congressclient$ openstack congress
datasource row list glancev2 images

opnfv@jumphost:~/git/python-congressclient$



__
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




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
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] [Congress] Nominating Masahito for core

[Masahito MUROI]

Thank you folks. I'm glad to be a part of this team and community, and 
appreciate all supports from you.


On 2016/02/17 12:10, Anusha Ramineni wrote:

+1

Best Regards,
Anusha

On 17 February 2016 at 00:59, Peter Balland <pball...@vmware.com
<mailto:pball...@vmware.com>> wrote:

+1

From: Tim Hinrichs <t...@styra.com <mailto:t...@styra.com>>
Reply-To: "OpenStack Development Mailing List (not for usage
questions)" <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, February 16, 2016 at 11:15 AM
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Congress] Nominating Masahito for core

Hi all,

I'm writing to nominate Masahito Muroi for the Congress core
team.  He's been a consistent contributor for the entirety of
Liberty and Mitaka, both in terms of code contributions and
reviews.  In addition to volunteering for bug fixes and
blueprints, he initiated and carried out the design and
implementation of a new class of datasource driver that allows
external datasources to push data into Congress.  He has also
been instrumental in migrating Congress to its new distributed
architecture.

Tim


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://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




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539



__
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] 答复: [congress]role in Congress

[Masahito MUROI]

Hi Yali,

I'm not sure which your concern is about UI by Horizon or for a policy 
in Congress.


On 2015/11/30 16:27, zhangyali (D) wrote:

Hi Tim,

In the implementation of Congress UI, I have realized that we need to
add role assignment. In many systems and cases, RBAC (Role-Based Access
Control) is an vital function which are beneficial to the division of work.

I think we should have “admin” and “tenant” user at least.  The admin
user could define predicates or complicated relations used in the
violations, and tenant user could just use the predicates defined by
admin user.

A typical example is that, the owner of network connected to VM should
be in the same group with the owner of this VM. In this example,
same_group is a predicates or complicated relations. It should be
I think this depends on how admin writes policy and what service works 
as Congress datasource. If admin want to adopt the policy to specific 
tenant, user or group, admin writes an additional policy to affect them 
by the policy.




defined by admin user. And this predicate could be used by any tenant
user. In this way, some typical or common predicates could be defined in
a individual admin board, and other tenant user could choose which one
to use.
On the other hand, this mentions about which user has permission to edit 
and to see a policy by Horizon.


best regard,
Masahito



Yali

*发件人:*Tim Hinrichs [mailto:t...@styra.com]
*发送时间:*2015年11月30日10:37
*收件人:*zhangyali (D); OpenStack Development Mailing List (not for
usage questions)
*主题:*Re: [openstack-dev][congress]role in Congress

Hi Yali,

We didn't discuss role assignment for service users in Tokyo.  Could you
explain a bit more what you need?

Tim

On Sun, Nov 29, 2015 at 7:33 PM zhangyali (D) <zhangyali...@huawei.com
<mailto:zhangyali...@huawei.com>> wrote:

Hi Tim and All,

I remember there is a topic named “role assignment for service
users”in the Tokyo Summit. Since I have not heard any message of
this topic. Does anyone could contribute some information for me? I
think it is vital for my design of Congress UI in horizon. Thanks a lot!

Best Regards,

Yali



__
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




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539，FAX: +81-422-59-2699



__
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] [oslo] fake driver doesn't work with multi topics

[Masahito MUROI]

Thanks Flavio. I'll report it in launchpad.

best regard,
Masahito

On 2015/11/27 3:00, Flavio Percoco wrote:

On 26/11/15 10:40 +0900, Masahito MUROI wrote:

Hi oslo.message folks,

We are trying to use oslo_message's fake driver [1] for our testing.
However, the driver doesn't seem to work with multi topics. Is this
behavior expected or a bug?


mmh, I'd say it's not. It's very likely this fake driver was not
updated to support that. Any chance you can file a bug for it?

Thanks,
Flavio



best regard,
Masahito


--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539，FAX: +81-422-59-2699



__

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




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539，FAX: +81-422-59-2699



__
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] [oslo] fake driver doesn't work with multi topics

[Masahito MUROI]

Hi oslo.message folks,

We are trying to use oslo_message's fake driver [1] for our testing.
However, the driver doesn't seem to work with multi topics. Is this
behavior expected or a bug?

best regard,
Masahito


-- 
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539，FAX: +81-422-59-2699



__
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] [Congress] Congress social night

[Masahito MUROI]

The time and the restaurant is decided. Almost of us seems to prefer
'before the official event', so we'll get a light meal at the izakaya
and then go to the event.

Time: 5:30pm-6:30pm 28,Oct
Location: tsukada nojyo (塚田農場 品川高輪口店)
https://goo.gl/maps/cfbCQs8R2R12

It costs roughly ~2,000 Japanese Yen depending on how many you drink or
eat. Note that we have no sponsors.

City buses leave from near the restaurant to the event site, so I plan
to use the bus which costs 210 Japanese Yen. Or we'll ride official
buses if the number is bigger than I expected.

Sorry, to officially announce the details late.


On 2015/10/23 11:19, Masahito MUROI wrote:
> I updated the available quantity. If you give it up because of
> 'sold-out', please try it again!
> 
> 
> On 2015/10/23 5:42, Peter Balland wrote:
>> Hi,
>>
>> I tried to register, but the link said the event was sold out.  I am
>> planning on attending.
>>
>> Thanks,
>>
>> - Peter
>>
>> On 10/21/15, 7:21 PM, "Masahito MUROI" <muroi.masah...@lab.ntt.co.jp>
>> wrote:
>>
>>> Hi Congress folks,
>>>
>>> Congress team plans to get-together on Wednesday night to be acquainted.
>>>
>>> If you are interested, please fill out quick RSVP [1] by the end of the
>>> week since I want to know a roughly estimated head count. If the number
>>> is big, I'll book sports bar, Japanese style bar called "Izakaya" or
>>> somewhere. The place and the time will depend on how many people want to
>>> go since there is official events on Wednesday night.
>>>
>>> 1.
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.eventbrite.com_e_c
>>> ongress-2Dteam-2Ddinner-2Din-2Dtokyo-2Dsuumit-2Dtickets-2D19199371838=BQ
>>> ICJg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=zlP7bph5MvLMIU5tJQ_-2
>>> AcEk-35kD-YRDosa2Aww1E=8xdrau-62ty8A5qoxqDMw2a0ZHAItjr-ya3vD8o03sQ=W96
>>> JYhfc5cZcRv6DiBGgYVU3CNEMJAgikLNzzhw05fg=
>>>
>>> best regard,
>>> masahito
>>>
>>> -- 
>>> 室井 雅仁(Masahito MUROI)
>>> Software Innovation Center, NTT
>>> Tel: +81-422-59-4539，FAX: +81-422-59-2699
>>>
>>>
>>> __
>>> 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
>>
>>
> 
> 


-- 
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539，FAX: +81-422-59-2699


__
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] [Congress] Congress social night

[Masahito MUROI]

Hi Congress folks,

Congress team plans to get-together on Wednesday night to be acquainted.

If you are interested, please fill out quick RSVP [1] by the end of the
week since I want to know a roughly estimated head count. If the number
is big, I'll book sports bar, Japanese style bar called "Izakaya" or
somewhere. The place and the time will depend on how many people want to
go since there is official events on Wednesday night.

1.
http://www.eventbrite.com/e/congress-team-dinner-in-tokyo-suumit-tickets-19199371838

best regard,
masahito

-- 
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539，FAX: +81-422-59-2699


__
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] [Congress] Need reviews of bp rpc-for-dse

[Masahito MUROI]

Hi Yingxin,

I think moving Congress from dse to rpc is a good idea.

Congress team will discuss its scalability in mid cycle sprint[1], [2]. 
I guess using rpc is one of key item for congress to get the ability. 
Why don't you join the meetup?


[1] https://wiki.openstack.org/wiki/Sprints/CongressLibertySprint
[2] 
http://www.eventbrite.com/e/congress-liberty-midcycle-sprint-tickets-17654731778


best regard,
masa

On 2015/07/23 16:07, Cheng, Yingxin wrote:

Hi all,


I have some thoughts about congress dse improvement after having read the code 
for several days.

Please refer to 
bp/rpc-for-dsehttps://blueprints.launchpad.net/congress/+spec/rpc-for-dse, 
its idea is to implement RPC in deepsix. Congress can benefit from lower-coupling 
between dse services. And the steps towards oslo-messaging integration can be milder 
too.

Eager to learn everything from Community. Anything wrong, please kindly point 
it out.


Thank you
Yingxin



__
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




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539，FAX: +81-422-59-2699


__
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] [Congress] New IRC meeting time

[Masahito MUROI]

I'm happy to see that.

btw, is the day on Tuesday?

best regard,
masa

On 2015/07/15 9:52, Zhou, Zhenzan wrote:

Glad to see this change.
Thanks for the supporting for developers in Asia☺

BR
Zhou Zhenzan

From: Tim Hinrichs [mailto:t...@styra.com]
Sent: Wednesday, July 15, 2015 02:14
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Congress] New IRC meeting time

To better accommodate the active contributors, we're moving our IRC meeting to

2300 UTC = 4p Pacific = 7p Eastern
#openstack-meeting-3

Hope to see you there!
Tim



__
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




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539，FAX: +81-422-59-2699


__
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] [Congress] hosts table of nova datasource driver

[Masahito MUROI]

Hi, congress folks

I'm new to congress and I'd like to use hosts table of nova datasource
driver in my usecase.  I, however, found out the hosts table is
commented out in current master.  Is there any reason to comment out it?
or will it be removed from an official datasource in the future?

best regard,
masa

-- 
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539


__
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] logging to syslog and log file with different levels

[Masahito MUROI]

I'm not sure if Python can distribute logs both into file and syslog 
based on its level but syslog has an ability to do it. So how about 
using syslog as nova-compute logging and changing the output by the syslog?


We are using the solution to change actions by logging levels.

regard,
Masa

On 2015/02/27 6:31, Gustavo Randich wrote:

Hi,

Is it possible to configure nova-compute logging with INFO level in
nova-compute.log and WARN level to syslog?

I couldn't play with options in /etc/nova/logging.conf, because of the
folowing problems:

- folsom: when I use log_config=/etc/nova/logging.conf, the following
error is raised:
No handlers could be found for logger nova

- icehouse: when I use log_config_append=/etc/nova/logging.conf, this
error is raised:
internal error: could not initialize domain event timer

Thanks!



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




--
Masahito MUROI
Software Innovation Center, NTT
Tel: +81-422-59-4539，FAX: +81-422-59-2699


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

Re: [Openstack-operators] How to handle updates of public images?

[Masahito MUROI]

We're using image member to share images instead of public images 
because we can share different images with same name for others, and 
when updating images we replace members of the existing image to new 
one. Then, we delete the old image when all vms using it are deleted on 
hypervisors.


This operation doesn't increase public image list.

Masa

On 2015/02/06 6:42, Belmiro Moreira wrote:

We don't delete public images from Glance because it breaks
migrate/resize and block live migration. Not tested with upstream Kilo,
though.
As consequence, our public image list has been growing over time...

In order to manage image releases we use glance image properties to
tag them.

Some relevant reviews:
https://review.openstack.org/#/c/150337/
https://review.openstack.org/#/c/90321/

Belmiro
CERN

On Thu, Feb 5, 2015 at 8:16 PM, Kris G. Lindgren klindg...@godaddy.com
mailto:klindg...@godaddy.com wrote:

In the case of a raw backed qcow2 image (pretty sure that¹s the default)
the instances root disk as seen inside the vm is made up of changes made
on the instance disk (qcow2 layer) + the base image (raw).  Also,
remember
that as currently coded a resize migration will almost always be a
migrate.  However, since the vm is successfully running on the old
compute
node it *should* be a trivial change that if the backing image is no
longer available via glance - copy that over to the new host as well.


Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.




On 2/5/15, 11:55 AM, Clint Byrum cl...@fewbar.com
mailto:cl...@fewbar.com wrote:

 Excerpts from George Shuklin's message of 2015-02-05 05:09:51 -0800:
  Hello everyone.
 
  We are updating our public images regularly (to provide them to
  customers in up-to-date state). But there is a problem: If some
 instance
  starts from image it becomes 'used'. That means:
  * That image is used as _base for nova
  * If instance is reverted this image is used to recreate
instance's disk
  * If instance is rescued this image is used as rescue base
  * It is redownloaded during resize/migration (on a new compute node)
 
 
 Some thoughts:
 
 * All of the operations described should be operating on an image
ID. So
 the other suggestions of renaming seems the right way to go. Ubuntu
 14.04 becomes Ubuntu 14.04 02052015 and the ID remains in the
system
 for a while. If something inside Nova doesn't work with IDs, it seems
 like a bug.
 
 * rebuild, revert, rescue, and resize, are all very _not_ cloud things
 that increase the complexity of Nova. Perhaps we should all reconsider
 their usefulness and encourage our users to spin up new resources, use
 volumes and/or backup/restore methods, and then tear down old
instances.
 
 One way to encourage them is to make it clear that these
operations will
 only work for X amount of time before old versions images will be
removed.
 So if you spin up Ubuntu 14.04 today, reverts and resizes and rescues
 are only guaranteed to work for 6 months. Then aggressively clean up 
 6 month old image ids. To make this practical, you might even require
 a role, something like reverter, rescuer, resizer and only allow
 those roles to do these operations, and then before purging images,
 notify those users in those roles of instances they won't be able to
 resize/rescue/revert anymore.
 
 It also makes no sense to me why migrating an instance requires its
 original image. The instance root disk is all that should matter.
 
 ___
 OpenStack-operators mailing list
 OpenStack-operators@lists.openstack.org
mailto:OpenStack-operators@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
mailto:OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators




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




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539，FAX: +81-422-59-2699


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